Scali wrote:
The biggest problem is that EGA has an entirely different memory layout. So the quick-and-dirty way would be to have the Tandy/PCjr code write to a temporary buffer in system memory, and then periodically convert the framebuffer on-the-fly to the EGA ram.
Actually, the Tandy/PCjr graphics system already uses the first 128KB of the conventional memory as shared memory, which would be a regular region of RAM in a regular PC compatible system. So that temporary buffer is already there, right?
Doable, but would require some hacking. Also it won't be too fast, so probably not that suitable for action games.
Agreed. But then again, the only 16-color Tandy/PCjr compatible games that did not yet support EGA are very old non-demanding games, which often already run too fast on a 286 system or a "turbo XT" clone. So the slowdown of such an emulator might actually cancel that out nicely.
Writing an optimized converter/mapper in assembly code that converts the pixel encoding on the fly as it copies the memory from the lower 128KB RAM to the EGA video memory would be the way to go. But assuming a typical game resolution of 320x200 and a frame rate of 60Hz, the algorithm would have to be capable of copying and converting 3840000 pixels per second with 16 colors of data each. At 4 bits per pixel, that would be 1.8MB per second to read the Tandy graphics from the lower RAM plus 1.8MB per second to write to EGA memory plus some computational effort to do the necessary conversion in between and of course remaining CPU time to run the actual game. That's pretty hefty indeed. It would probably require a later era PC to pull off such emulation at acceptable speeds. Did I make any mistake with these calculations?
If there was a way to convert partial screen updates on the fly, this could be done more efficiently. But if a game writes Tandy/PCjr graphics directly to memory, there's no way to tell what parts of the screen get updated and when. It's not like each changed pixel or set of pixels triggers an interrupt or anything, right?
I wonder... Would it have been possible for a graphics card manufacturer to design an EGA or VGA card that could use the DMA controller to access the lower 128KB RAM and access the location of the Tandy/PCjr graphics buffer that way? Would that have been a way to release a graphics card with Tandy/PCjr graphics compatibility? By combining that with a 3-voice Tandy/PCjr-compatible sound chip, it would perhaps have been possible to sell Tandy 100 compatibility on a single card for regular PC clones. 🤣 I know, accessing RAM through DMA is still slower than memory-mapped I/O, but it would still be a lot faster than software emulatoin, right? I know, this is probably a crazy idea. 😉
If anybody here knows of a more creative and/or feasible way to implement Trandy/PCjr emulation on an EGA/VGA system, I'm all ears. 😀
Having a properly optimized EGA renderer would require completely rewriting the graphics code for a game. Again, doable in theory, but a lot more work.
Yeah, and it would require a custom patch for each individual game. But given that there are not that many such games, that might perhaps be a more feasible alternative.