VOGONS


Reply 80 of 112, by Neville

User metadata
Rank Oldbie
Rank
Oldbie

Yes, DOSBox rocks. Once Windows XP got rid of DOS I though a great deal of my childhood was gone. Glad to see there are plenty of DOS gaming enthusiasts around.

My last test has been a true relic, Julius Erwing and Larry Bird Go One-on-One (PC Booter). As of DOSBox SVN r4067, CGA Composite and PCjr support are fine, but the Tandy option shows garbled graphics and sound.

3rRE6KC.png

Plain CGA (That's what you get under DOSBox v0.74 when choosing machine=pcjr)

mQHLXiJ.png?1

CGA Composite (DOSBox v0.74 with machine=cga)

voiiTH6.png

PCjr mode (as seen in SVN r4067)

zXKucyW.png

Tandy mode (as seen in v0.74 and SVN r4067)

EDIT: I'm told the Tandy issues are not an emulation issue, but a result of using a cracked disk image.

Reply 81 of 112, by Neville

User metadata
Rank Oldbie
Rank
Oldbie

Again with Tandy woes... "The Sentinel" won't work under Tandy mode. You get to select Tandy graphics at the beginning, but then screen goes blue while music plays, and no proper graphics are shown. Could be my copy, of course. Can anyone try their version and see if they can reach in-game?

EDIT: Tried with PCem as well... same result. Methinks I have an incomplete copy.

Reply 82 of 112, by digger

User metadata
Rank Oldbie
Rank
Oldbie
liqmat wrote:

You can add Ghostbusters to your list. It looks like Ghostbusters 2 supported EGA mode, but the first Ghostbusters was only 16 color on the PCjr and Tandy from what I can tell. If you boot Ghostbusters on an EGA machine it displays CGA colors.

Interestingly, Ghostbusters II kind of repeated history that way. 🤣 I remember starting up Ghostbusters II on one of the 8086-based IBM PS/2 Model 30 machines that we had back in high school. To my surprise and disappointment, the game would only run in CGA 4-color mode, since MCGA was a subset of VGA that lacked EGA compatibility among other things. I found it weird back then, since I had also tried Indiana Jones and the Last Crusade on one of those machines, which did run in its full 16 color glory. That was of course because some 16-color games would support 320x200 256 color mode (a.k.a. Mode 13h), just so they could display 16 simultaneous colors on MCGA systems. Unfortunately, Ghostbusters II was not one of those games.

It makes me wonder, though: how feasible would it be to write EGA patches for games that support 16 colors only in PCJr, Tandy, and/or CGA Composite mode? Trying to write MCGA patches for both EGA-only and PCJr/Tandy-only 16-color games might also be a fun project, even though it would benefit only the few IBM PS/2 models that had MCGA graphics. Also, those systems could be upgraded with VGA cards anyway, which would allow the original MCGA monitors to also work in EGA 320x200 16-color mode. The same cannot be said for PCJr/Tandy graphics.

I know patching such games to show their 16 colors in EGA mode wouldn't be trivial, due to the considerable difference in which graphics is mapped to video memory. But hey, that makes it all the more challenging, right? 😉

Bonus points if we could combine these EGA patches to enable PCJr/Tandy sound as well, for those who have a Lo-tech Tandy Compatible Sound Adapter installed. And perhaps also a variant that reroutes the PCJr/Tandy sound to a TNDLPT device on the parallel port. That would unlock the full potential of those games on other systems and allow a lot more DOS PCs to play those games as they were originally designed. 😀

And finally, Plantronics-patches for those few PC clones that supported 16-color 320x200 Plantronics Colorplus mode would also be an interesting project, albeit a quite obscure one. After all, no game ever supported that mode as far as I know, and it would be fun to have games finally support those systems to their full ability.

Reply 84 of 112, by Scali

User metadata
Rank l33t
Rank
l33t
digger wrote:

It makes me wonder, though: how feasible would it be to write EGA patches for games that support 16 colors only in PCJr, Tandy, and/or CGA Composite mode?

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.
Doable, but would require some hacking. Also it won't be too fast, so probably not that suitable for action games.

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.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 85 of 112, by digger

User metadata
Rank Oldbie
Rank
Oldbie
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.

Reply 86 of 112, by Scali

User metadata
Rank l33t
Rank
l33t
digger wrote:

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?

Not necessarily.
PCjr uses a remapping scheme, where the B800-area is mapped to a 32k block in the first 128k (the last block by default).
So it depends on whether the game writes to B800 or to the actual address.
Tandy always places the video ram at the end of the conventional memory, which can be more than 128k.

But it shouldn't be too hard to patch B800 or whathever other address to another buffer if necessary.

digger wrote:

Did I make any mistake with these calculations?

Well there are various other intricacies, like the write speed of EGA memory, the manipulation of bitplanes and write masks, and the additional CPU overhead of converting the data. But yea, in general trying to do it at 60 Hz is going to be somewhat unrealistic.

digger wrote:

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?

No... unless you'd use a 386 to virtualize the memory, but that overhead would be very high as well, so it'd probably wouldn't improve things much.

digger wrote:

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?

I think it would be easier to just 'sniff' the ISA bus for any memory writes directly and just 'mirror' the memory directly.
But that should be possible I suppose.

digger wrote:

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.

It would be the most 'oldskool' approach at least 😀
Also, it might makes these games accessible even to low-end 8088 machines.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 87 of 112, by NewRisingSun

User metadata
Rank Oldbie
Rank
Oldbie
Scali wrote:

PCjr uses a remapping scheme, where the B8000h-area is mapped to a 32k block in the first 128k (the last block by default).

The Tandy 1000 does that. Unfortunately, the PCjr only maps 16 KiB to B8000h, so one has to use the 10000h/18000h area directly for 320x200x16 color mode.

Many VGA cards allow the internal registers to be set up in a mode that will display Tandy/PCjr 16-color mode data natively (provided that the B800 area is used and not the 1800/9800 area). It involves setting all registers except those of the attribute controller to 256 color mode and the attribute controller to 16 color mode. This takes advantage of the fact that 256-color mode on the IBM VGA chipset itself was implemented in a hacky way, basically by making the attribute controller wait for two 4-bit nibbles on every pixel instead of just one. Additionally, setting both bits 0 and 1 of CRTC register 17h replicates the four 8 KiB bank-layout of the Tandy/PCjr 16-color modes.

Being a bit of a hack a highly customized video mode, this method is somewhat unstable across the range of VGA cards because ...

  • ... some cards are highly integrated to eliminate redundant register bits (redundant in normal operation, at least), so that setting the attribute controller to a different mode than all the other chips is not possible;
  • ... some cards do not fully implement CRTC register 17h bits 0 and 1, or only bit 0, or only in some modes;
  • ... whether the attribute controller receives the high or the low nibble first is undefined in the VGA specification and so varies across cards. If it receives the low nibble first, which is unsuitable for Tandy 16-color mode, one can additionally set the Data Rotate register (3CFh index 03h) to 04h. But that will only correct write accesses and will return the wrong result on read accesses, noticeable on games using a mouse pointer.

Reply 88 of 112, by digger

User metadata
Rank Oldbie
Rank
Oldbie

That's a fascinating hack, NewRisingSun! 😀 Do you know of any utilities that actually existed back in the day to implement Tandy 16-color emulation on VGA systems in such a manner? And how many of the Tandy/PCJr-only 16 color games would support this, considering the B800 area limitation you mentioned? The first 16 color PC games would have catered to the PCJr systems in particular, since the Tandy 1000 systems appeared later. So I guess that would make this less likely to work on pre-EGA 16 color PC games.

Reply 89 of 112, by NewRisingSun

User metadata
Rank Oldbie
Rank
Oldbie

No, I cooked it up myself. Nobody used it for anything, likely because it's a hit-and-miss between VGA cards. I have successfully tried it on the Matrix Millennium G200 and the Trident TVGA 8900. The Matrox required using the Data Rotate register, while the Trident did not. It did not work at all on some Nvidia PCI card I tried. I would like to try it on an original IBM VGA chipset, preferably as the on-board chipset of an IBM PS/2, or at least using the original IBM PS/2 Display Adapter (which is the confusing name of the original ISA VGA card by IBM).

digger wrote:

And how many of the Tandy/PCJr-only 16 color games would support this, considering the B800 area limitation you mentioned?

No PCjr game directly, but several Tandy 1000 games such as King's Quest (Tandy 1000 version) do use the B8000h area. The thing is that changing one segment address is much easier than porting a whole graphics library from packed pixel to planar, as one would have to do when converting from PCjr/Tandy to EGA.

Reply 91 of 112, by digger

User metadata
Rank Oldbie
Rank
Oldbie
dr.zeissler wrote:

I would be more interested the other way round.
Patching EGA Games to work with tandy.

Were there many 16-color games that supported EGA, but not Tandy/PCjr in 16-color mode?

Reply 93 of 112, by Scali

User metadata
Rank l33t
Rank
l33t
NewRisingSun wrote:

Not that many, but important ones, like Commander Keen. 😀

There's a 16-colour CGA composite one now though 😀
I suspect that works quite well on Tandy.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 95 of 112, by Scali

User metadata
Rank l33t
Rank
l33t
NewRisingSun wrote:

Not with 320x200x16 color graphics, just with CGA-composite-displayed-as-RGB graphics. So it works, but not "well". 😢

Tandy has composite output, doesn't it?
Anyway I was thinking of performance in terms of "works quite well".
Most Tandy machines would be 8088 or other low-end CPUs. Since there is no scrolling hardware support on Tandy/PCjr, scrolling a CGA screen is hard enough. Not to mention that Keen uses a clever system with multiple system-memory buffers.
Changing from 160x200 composite to 320x200x16 would require twice the memory for all the buffers, and the game would likely no longer fit in 640k that way. Not to mention that it also requires twice the memory bandwidth and CPU power to move all that memory around.
(EGA has 256k of onboard memory, using a completely different approach to scrolling).

However, I believe there is an (undocumented?) 160x200 RGB 16-colour mode possible on Tandy/PCjr? I suppose (with the graphics re-done), the game could be made to work in that mode with similar performance to the CGA composite one. My guess is that the composite version would look better though, giving that low resolution a softer, less pixely look, and also some nicer colours than the rather harsh RGB ones.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 96 of 112, by NewRisingSun

User metadata
Rank Oldbie
Rank
Oldbie
Scali wrote:

Tandy has composite output, doesn't it?

Only the earlier models do. The SL, TL, and RL ones do not. And the ones that do have a different phase offset than the CGA, so the colors of composite CGA look wrong and would need to be reassigned. Generally, the composite output was largely unused by Tandy 1000 users, so a Tandy 1000-targeted program is always expected to provide good RGBI output.

Scali wrote:

Since there is no scrolling hardware support on Tandy/PCjr,

You can hardware-scroll vertically on all models after the original 1000, including the EX/SX/TX/HX, SL/TL/RL. Horizontal scrolling is a problem indeed, at least from what we know about the 6845.

Scali wrote:

However, I believe there is an (undocumented?) 160x200 RGB 16-colour mode possible on Tandy/PCjr?

It's very much documented. BIOS Mode 8. 😀

Reply 97 of 112, by VileR

User metadata
Rank l33t
Rank
l33t

Someone has already made this "hack of a hack" and converted composite Keen 4 to 16-color RGB for Tandy 1000:

https://www.youtube.com/watch?v=GDm538gpBW8

Rather "chunkier", as one could expect. No download link though.

[ WEB ] - [ BLOG ] - [ TUBE ] - [ CODE ]

Reply 99 of 112, by Neville

User metadata
Rank Oldbie
Rank
Oldbie
VileRancour wrote:

Someone has already made this "hack of a hack" and converted composite Keen 4 to 16-color RGB for Tandy 1000:

https://www.youtube.com/watch?v=GDm538gpBW8

Rather "chunkier", as one could expect. No download link though.

Turns out the author uploaded it to GitHub: https://github.com/kubilus1/keen4t