A while ago I purchased an Apple (Video7) Extended 80col RGB (aka AppleColor) card on eBay for using the card with an enhanced Apple //e PAL. For quite a while, I did not have a good way of displaying the output of the card, as today's monitors are incompatible with the horizontal frequency of the video signal.
After some success in performing the "Marcorlandi modification" on a breadboard and adding an LM1881 sync splitter and the GBS-8200 for "upconverting" the HSync for VGA, I recently discovered the (fantastic) RGBtoHDMI project. I got the Raspberry Pi Zero, and soldered the SMD components on the RGBtoHDMI PCB as well as the PC (CGA) buffer board, as the TTL output of the RGB card is quite similar to CGA with its RGB+intensity bits, just CSync instead of separate HSync and VSync.
I was pleasantly surprised that basically everything worked out of the box. I only had to select the right color palette (Laser128) and now I have a perfect image on an HDMI monitor.
Then, I discovered the first issue: bit flips and other memory issues in the extended memory. The bit flips were easy to spot in 80col mode and also easy to identify as the LSB. (Of course, when exchanging the DRAM chips on the card, the last one of the four "corners" was the right one...). The Apple //e Diagnostics 2.1 still reported memory issues on the card, so I exchanged some more DRAM until all tests passed.
Now, here's the strange behaviour that I cannot explain with my limited knowledge on DHGR:
- All "standard" GR and HGR modes work perfectly fine with the all the right colors and everything.
- 80col b/w TEXT mode also works fine.
- b/w DHGR works fine as well.
- No issues at all when using the Video7 RGB card demo disk -- all features, text and graphics modes come out exactly as they should with correct resolution, color.
But now, when using software making use of color DHGR, I get the same behaviour: it looks as if I only get "striped" 140x192 black-and-white images, sometimes also 40col text ends up in funny, random-looking colors.
I was not able to find anything on the net except something that was called "AN3 softswitch conditioning" on an AppleWin discussion, where the AN3 $C05E / $C05F has to be toggled several times in order to switch the graphics mode. This is also documented in Chapter 6 of the card manual. Could it be that a standard (non-RevA) Apple //e does not need this procedure for color DHGR output via composite video, but the RGB card does? I faintly remember one comment on the net when somebody said colors worked fine using some other RGB card only when running the same program for a second time.
Maybe I also overlooked something obvious? Thanks for any helpful comments on where to look for the source of this behaviour? (and please correct me if it should actually be normal...)
I did find a composite monitor to attach in parallel to check my assumption of the different behaviour of the RGB card vs. the onboard composite video out. And indeed, the composite monitor shows the correct (color) image, whereas the RGB card only shows the patterned black-and-white image.
Looks like software would have had to be adapted to the RGB card to actually work. I assumed that this would have been the case, as it was an Apple product, but then probably it was never sold in high enough numbers...