VOGONS


First post, by videogamer555

User metadata
Rank Member
Rank
Member

I'm trying to use the http://www.osdever.net/FreeVGA/vga/graphreg.htm#06 register's memory map select field, and the http://www.osdever.net/FreeVGA/vga/seqreg.htm#04 register's external memory available bit, in order to boost the available amount of VRAM (emulated VRAM in the case of DosBox) in graphics mode 0xE (16 colors with 640x200 resolution), in write-mode 2 (as set in yet another register) to give me the ability to write pixels in a bit-packed way (opposite the normal planar way the mode operates, as it normally uses write-mode 0). But it's giving me a problem. This gives me 2 pixels per byte, and a width of 640 pixels, and a height of 200 pixels,which means a total of 64000 bytes exactly (which means I shouldn't even need to expand the memory region, but I tried to just because it wasn't working with the normal 64KBytes of VRAM). But it stops drawing after only 32768 bytes. I took a screenshot and in Photoshop (after resizing it vertically with nearest-neighbor method to half height, due to DosBox doubling the pixel height, so as to be able to count the individual pixels) I counted the number of complete lines of pixels and multiplied by 640 and added to that the number of pixels on the partial line. I then divided by 2 to get the number of bytes. There's no reason for it to stop after only 32768 bytes. In 320x200 256 color mode (mode 13h) I have no problem writing all 64000 bytes of data. But DosBox seems to be imposing an artificial limit of 32768 bytes in 640x200 16 color mode. I don't think real hardware would behave like this. In fact even EGA (old EGA hardware, not just VGA in EGA mode) could theoretically go up to a 640x400 16 color mode with extended VRAM installed (to bring VRAM up to 128KBytes, as each pixel only occupies half a byte). Though you couldn't access it with any of the INT 10h graphics modes, by messing with the graphics card registers, if you had enough VRAM, you could theoretically get such a 640x400 16 color graphics mode on EGA hardware. Yet DosBox isn't even doing 640x200 16 color mode properly, at least not when its registers are set to use write-mode 2 (a method of writing pixels in a bit-packed way, instead of a bit-planar way).

Reply 2 of 4, by videogamer555

User metadata
Rank Member
Rank
Member
ViTi95 wrote on 2022-02-01, 23:48:

Maybe you can try with DosBox-X or PCem, both are better than DosBox.

I was just hoping to know if in DosBox official version, if this is a known intentional "feature" for it to have this limit of 64KBytes of VRAM? Or is this actually a bug? I know that Dosbox is only meant for games, but I was thinking some games probably use larger amount of memory for graphics, so I wonder why >64KB isn't supported.

Last edited by videogamer555 on 2022-02-02, 17:14. Edited 1 time in total.

Reply 3 of 4, by ViTi95

User metadata
Rank Member
Rank
Member

One thing I discovered trying new graphics modes and ideas for FastDoom is that you can't rely on DosBox emulation, it's not up to the task. PCem behaves better, but still misses some quirks from real hardware. Just try on real hardware.

For example I developed an Hercules 640x200 mode that worked fine on both emulators, but trying on real hardware it failed miserably.

https://www.youtube.com/@viti95

Reply 4 of 4, by videogamer555

User metadata
Rank Member
Rank
Member
ViTi95 wrote on 2022-02-02, 14:37:

One thing I discovered trying new graphics modes and ideas for FastDoom is that you can't rely on DosBox emulation, it's not up to the task. PCem behaves better, but still misses some quirks from real hardware. Just try on real hardware.

For example I developed an Hercules 640x200 mode that worked fine on both emulators, but trying on real hardware it failed miserably.

But then there's the issue of copying it to a disk and then moving the disk to a different physical PC and waiting for its long bios mem test bootup (old PCs had less RAM, but were slower so running the bootup memory test could take a full minute). Best to try on an emulator that tries to actually emulate ALL of the features of REAL vintage computers (register by register, port by port, address by address, EVERYTHING), so that such an emulator could be used in a software development environment on a modern PC, to develop software for vintage PCs, and you could be certain that what you saw in the emulator is what would actually happen on the real vintage PC. I mean someone could actually sell such software to people who really were hardcore collectors of vintage computers, and wanted to write real software for those computers, but using a modern PC to write the software instead of writing it on the vintage PC (for the simple reason of the fact that the vintage PCs are so slow, that the compilers are thus slow, and thus software development is slowed). But it's not just for the convenience of a faster software development cycle. It's also for safety. Older PCs, could be given commands that would DAMAGE THE HARDWARE, especially with CRT monitors. The electronics in a CRT monitor could be fried by directly setting some of the CRT control registers on a graphics card to certain values because the monitors would blindly take whatever sync signals they got and try to use them. A modern emulator as part of a dedicated software development suite for developing vintage applications, could be designed to warn you of an instruction your software sent that would damage real hardware on a vintage PC.

As such, instead of just being a DOS emulator, or even a generic PC emulator, such an emulator would allow you to select a computer by make and model from a database of real vintage PCs. But for that you need highly precise and accurate info. The extensive process the emulator's writer would need to undergo would involve reading both user and service manuals to find documented and (previously not publicly documented, by tracking down copies of these antique paper documents from former company employes) specs on the computers (and associated compatible expansion cards and compatible peripherals) and all of their internal components. Any important specs that couldn't be found in any documents, would be measured directly with things multimeters and even oscilloscopes and logic analyzers directly on the circuits of the devices while running various software written to test the device's specs. The BIOS ROMs themselves should be dumped (with permission from the companies, permission I'm sure they would have no problem giving you as those BIOSes are no longer of commercial value to the manufacturers of those outdated PCs). This is needed to get guarantied real-hardware accurate operation of the emulator. The database could contain a wide variety of old PCs that had been so documented by the emulator's maker, including IBM PC, IBM AT, IBM XT, as well as various other models of old Intel CPU based PCs from other companies like Gateway, Compaq, Leading Edge, etc. The emulator should only allow you to select the expansion cards (such as an EGA card or CGA card) that would be compatible with the computer you selected, and likewise the peripherals you want to use (like IBM CGA monitor, IBM EGA monitor, RCA TV, Zenith TV, floppy drive, harddrive, etc) should only be able to be selected if the motherboard of the computer you selected and/or an expansion card you had selected, would support that accessory. Different manufacturers of monitors and TVs have different circuits and thus can handle signals that are out-of-spec better than others. Those should be carefully documented and tested (yes some TVs and monitors will get fried in the course of reverse engineering them, so the tester should have 2 or 3 of each model he wants to test under various operating conditions) so that the emulator can be programmed with a way to warn you when your software attempts to send a signal that would damage real hardware.

Regarding CPU speed, this should be something emulated too. A PC with a 6MHz CPU clock speed should be emulated with a delay loop to simulate the real CPU speed, so that each emulated byte of the code is clocked into the emulated CPU at the same speed it would be in real life. To determine the duration of the delay loop, a benchmark should be run by the emulator to see how much it will need to compensate for the speed of the host system CPU (a test that should only take a couple seconds to run). It should use a separate thread to measure the host CPU speed, and run the test about once every minute, as modern CPUs can actually CHANGE THEIR SPEED AUTOMATICALLY based on the amount of demand being placed on them by the software that is running on the system. Therefore, this benchmark should be run periodically and the duration of the delay loop should be adjusted based on the results from each benchmark. For a Host CPU with automatic speed changing, the emulator will need automatic delay loop changing to compensate. Also real disk drives on old PCs took quite some time to read, and this delay per sector read from the disk should be set to match the actual reading speed of the real drive that you selected to use in the emulator.

Obviously something this EXTENSIVELY researched and developed, is going to be a commercial product, not free or open source. And I would certainly be willing to pay quite a bit of money to get such a high accuracy vintage PC emulator.