Jr. testers needed.

[deathshadow60]

I'm closing in on finishing of my retrochallenge "winter warmup" -- or at least my original stated goals. (I kicked it into overdrive today)... but need some people to test out my code.

You can read up on what I'm doing on my blog:
http://my.opera.com/deathshadow/blog

... and download the demo here:
http://www.cutcodedown.com/retroChallenge/winter2011/demo16r1.rar

Which includes all the code too.

Basically it's the "undocumented" 160x100 16 color CGA graphics mode, rewritten for proper support of the EGA and VGA cards. I've added a command line parameter (/vgaSafe) to implement the old method (as done by Jeffery Silverton) of VGA support as a few laptop displays bomb with my technique of also reprogramming the CRTC for real 640x200 "mode 3" -- wondering if I need to put the effort in to providing the same fall-back for EGA, or if I got it right.

While I'm interested in knowing how the EGA handles it and 64k systems, I figured this would be the place to ask about how it works (or doesn't) on the Jr. I'm using my own keyboard code instead of calling the BIOS, but was unsure if the Jr's BIOS data area is even compatible -- so it could be even the keyboard doesn't work. If so I'll add the BIOS calls back in. I don't expect video-wise the Jr. would behave all that differently from my Tandy 1K HX since we are just talking about using a tweaked version of the CGA 80x25 text mode.

So If anyone here would be willing to test that it would be GREATLY appreciated. Oh, and for the morbidly curious on modern computers - being that it's 16 bit DOS code that also reprograms the CRTC DIRECTLY I advise against trying to run it in Windows -- though I've tested it extensively inside DOSBOX where it works just fine. (though it has an annoying 'lag' on mode setting due to the redraw delay)

Tomorrow I get to start working on the sprite engine -- though this is just stage 1 of my project -- stage two is where the real fun begins; screwing around with the 8253 PIT... and Stage 3, well... that's my big surprise. (which I'm hoping to have done by end of month, though no promises)

[Brutman]

I should be able to do some testing for you. I don't think I've ever seen the 160x100 display mode - what is the advantage over the 160x200 display mode?

I'm assuming that it's not setting the 6845 registers in a nasty way. Also, have you tested this on a Jr yet? Some of the register locations are different, so if you have not consulted the port map this might be a dead end.

[CommodoreJohn]

I should be able to do some testing for you. I don't think I've ever seen the 160x100 display mode - what is the advantage over the 160x200 display mode?

If it's the mode I think he's talking about, it's a CGA text-mode hack, so the advantage is that it provides a 16-color bitmap mode on CGA hardware, and one that works on RGBI monitors instead of just composite like the "color composite 640x200" hack.

[Vorticon]

It works great with no issues with the keyboard. My set up is a PCjr with V20 cpu, 640K RAM and the Tandy video modification. I wonder if any issues will arise without the latter, although the demo did state that CGA was detected.

[deathshadow60]

I should be able to do some testing for you. I don't think I've ever seen the 160x100 display mode - what is the advantage over the 160x200 display mode?

CommodoreJohn hit it on the head -- the 160x100 mode also works on a regular CGA card because it only needs 16K of video memory to work -- as opposed to 160x200 that takes 32k (which the CGA doesn't have).

For the most part it's just 80x25 text mode where you 'trick' the CRTC into thinking all characters are only two scanlines high -- so only the first two scanlines of each text character is shown. Nets you an 80x100 character display. You fill the screen with either one of the half-filled block characters (codes 0xDD or 0xDE) -- which puts half the character as filled and half showing the background -- background color becomes one pixel, foreground color becomes the other netting you 160 pixels across.

It's actually kind-of a sad state of affairs on the old PC's -- There is actually no reason a standard CGA couldn't have provided 320x200 16 color -- that's only 16k of RAM use and the 6845 can do that mode, but to save on card costs they didn't double-buffer the RAM meaning you had to interleave the pages for no snow in graphics mode, basically disabling half the on-board RAM in graphics mode. Really in terms of video hardware that's the ONLY difference between the Tandy/PcJr and a regular CGA card...

Though I remember back in the day a buddy of mine triple-piggy-backed another 16k on a CGA card to allow the same 160x200 mode as the Jr/Tandy.]

I'm assuming that it's not setting the 6845 registers in a nasty way. Also, have you tested this on a Jr yet? Some of the register locations are different, so if you have not consulted the port map this might be a dead end.

Only ports I'm playing with are 0x3D4/0x3D5 in terms of the video, which the Jr. does support... well, and port 0x60/0x61 for the keyboard and port 0x20 for acknowledging ISR's.

It works great with no issues with the keyboard. My set up is a PCjr with V20 cpu, 640K RAM and the Tandy video modification. I wonder if any issues will arise without the latter, although the demo did state that CGA was detected.

Wait, did it say CGA or PcJr? If the former, then I have a bug somewhere.

-- edit -- found the bug, should be looking for $FD as the Jr's code, not $0F.