• Please review our updated Terms and Rules here

True CGA vs VGA card in CGA mode

One small gripe: in the disclaimer, "any damage that may occur during it's use" should read "...during its use." Just like "his," "hers," "yours," and "ours," the possessive "its" does not use an apostrophe. ;)

An oversight. :) This will be fixed in the final version.

Thanks for the test results!
 
One curious glitch with v0.4: although it runs fine on my old Tandy (8086 without coprocessor), on my Compaq PIII-600 it crashes with "Runtime error 200 at 04C7:0091", while v0.3 worked fine on it. :confused: Not much of a loss, though, since modern-era Super VGA fails most of the tests miserably, anyway. :p

That's a timing bug that I have been lazy in fixing permanently. I'll make sure that it's fixed in the final version so that you can run the tool on modern machines.
 
A few more test results:

Zenith SupersPORT laptop (7.16 MHz 80C88) via its CGA RGB output:
* No 160x100 "graphics" mode (it just displays whole characters)
* No top/bottom or strikethrough cursor shapes (other shapes work OK)
* No 90x30 text mode (the lines just wrap around)
* No interlaced mode
* No display positioning

On its internal LCD screen, some of the color combinations are rendered invisible due to the translation to simulated grayscales (it's actually a monochrome LCD, and it flickers the pixels on and off at different rates to mimic different shades of "supertwist" blue!), but it does display the "bouncing background bars" 320x200 demo on the LCD, which was a pleasant surprise.

My CompuAdd 810 (one of the last XT clones, with a 9.54 MHz NEC V20 and onboard high-density 1.44 MB floppy controller, IDE-XT controller, and DS1287 real-time clock) passes all tests with its onboard CGA except for interlaced mode.

Just for giggles, I'm going to disable the CompuAdd's onboard video and stick in my original IBM CGA board, just to see what interlaced mode really looks like -- assuming it's not going to explode any more capacitors when I turn the power on! :eek:
 
If you open up your machine and your CPU does NOT say 80c88 on the top of it, I would like to know, as I was very proud of that piece of code and expect it to work properly.
I got this one:
L_Intel-P8088.jpg

(This is not my CPU, but it is exactly the same of everything but the serial number)

Maybe Intel fixed the bug in later CPU's... Mine is made around 1985.

I got another one with a '81 copyright date instead of a '83 copyright date, but that isn't installed in any computer at the time.
 
Last edited:
Maybe Intel fixed the bug in later CPU's... Mine is made around 1985.

I got another one with a '81 copyright date instead of a '83 copyright date, but that isn't installed in any computer at the time.
Intel kept fixing bugs in the 8088 every few years. The oldest IBM PCs (with only 64K on the motherboard) came with the original 1978 or 1979 version of the 8088, which is supposed to have some rather large bug in it. Wikipedia says "8086/8088 CPUs produced prior to 1982 had a severe interrupt bug. IBM provided an upgrade free of charge to affected PCs."
 
* No 160x100 "graphics" mode (it just displays whole characters)

That's a shame; there were some really neat graphics possible with that mode.

* No 90x30 text mode (the lines just wrap around)
* No interlaced mode
* No display positioning

I would expect that with an LCD, actually.

it does display the "bouncing background bars" 320x200 demo on the LCD, which was a pleasant surprise.

Agreed :) (Not all the tests are that flashy, but being a democoder I couldn't resist)

Just for giggles, I'm going to disable the CompuAdd's onboard video and stick in my original IBM CGA board, just to see what interlaced mode really looks like -- assuming it's not going to explode any more capacitors when I turn the power on! :eek:

If they do, it won't be my fault! :) As for interlaced mode, it looks somewhat horrible on a real 5153 RGB monitor. I am told it looks better on a composite monitor but I haven't hooked one up to try yet.
 
Intel kept fixing bugs in the 8088 every few years. The oldest IBM PCs (with only 64K on the motherboard) came with the original 1978 or 1979 version of the 8088, which is supposed to have some rather large bug in it. Wikipedia says "8086/8088 CPUs produced prior to 1982 had a severe interrupt bug. IBM provided an upgrade free of charge to affected PCs."

I knew about the interrupt bug (I believe it's that interrupts are mistakenly enabled during a push/pop/mov of SS, which can corrupt the stack if an interrupt occurs before the push/pop/mov is done), but that's not what I use to determine CPU type because I couldn't find a definite date on when they fixed it. It's also not something that can be exploited as far as I know, as I can't see a way to trigger an interrupt at an exact cycle.

Fixing the rep ES: lods bug happened when they switched to the CMOS manufacturing process, so that's what I use. If your chip is marked past 1983, it is an 80c88/80c86 even if it's not marked.

At least, that is what I am led to believe. If someone has more definitive info, let me know...
 
Amstrad PC1512 (8MHz 80c86)

  • Read: 194 KB/s
  • Write: 204 KB/s
  • Interleaved read: 165 KB/s
  • Interleaved write: 166 KB/s
  • The cyan/red/white test fails; the PC1512 only does cyan/red/white if bit 5 of the colour control register is 0, whereas on a real CGA it doesn't matter what this bit is.
  • The font is different.
  • There is no snow.
  • In the retrace detect test, the bars are barely visible at the bottom of the screen.
  • The 90x30 test, interlace test, and retrace test all fail, owing to incomplete emulation of the MC6845.
 
Well then that's quite UNexpected :)
I guess the thinking is that since you can switch between LCD and RGB/composite output at any time, they restrict the RGB/composite to only things that the LCD can physically accomodate -- so no repositioning, no expanded text rows/columns, etc. But it would be nice if they at least made 160x100 "graphics" mode work, especially since it's supposed to be "CGA" video and a good number of CGA games used that mode.

I do recall using a Heath/Zenith 8088 desktop computer with its standard CGA video, however, and everything worked fine, including interlaced mode -- perhaps one of the few clones to implement it. It looked just like this, and even had electronic key click through the speaker -- a nice touch.

955AUTHOR-pcxt.jpg
 
Amstrad PC1512 (8MHz 80c86)

[*]Read: 194 KB/s
[*]Write: 204 KB/s

Wow, slower than actual CGA. Even the PCjr's display memory isn't that slow.

[*]The cyan/red/white test fails; the PC1512 only does cyan/red/white if bit 5 of the colour control register is 0, whereas on a real CGA it doesn't matter what this bit is.

But the second-to-last palette test does clear bit five. Here's the actual code (edited for brevity):

Code:
  m6845_mode_ctl=$3d8; {mode control register}
    {relevant bits}
    c_fast_char_clock=1; {use 160 bytes per line instead of 80; REQUIRED for 80x25 mode, otherwise 40x25 mode}
    c_graphics_enable=2; {otherwise, text mode}
    c_blackandwhite_enable=4; {otherwise, color signal}
    c_videosignal_enable=8; {otherwise, NO VIDEO SIGNAL}
    c_640x200_enable=16; {otherwise, 320x200}
    c_blinking_text=32; {otherwise, all background colors enabled}
  m6845_color_sel=$3d9; {color select register}
    {relevant bits}
    c_blue=1;
    c_green=2;
    c_red=4;
    c_bright=8;
    c_alternate_intensity=16; {alt. intens. colors in graphics mode}
    c_paletteCMW=32; {otherwise, red/green/yellow palette}

(snip)

Procedure m6845_SetMode(modeflags:byte);assembler;
asm
  mov dx,m6845_mode_ctl
  mov al,modeflags
  out dx,al
end;

procedure m6845_SetColor(c:byte);assembler;
asm
  mov dx,m6845_color_sel
  mov al,c
  out dx,al
end;

(snip)

  m6845_SetColor(c_paletteCMW);
  smsg:='This is cyan/magenta/white (low). '#13; BIOSWriteStr(smsg); PauseUser;

  m6845_SetColor(c_paletteCMW+c_alternate_intensity);
  smsg:='This is cyan/magenta/white (high).'#13; BIOSWriteStr(smsg); PauseUser;

  m6845_SetColor(0);
  smsg:='This is green/red/yellow (low).   '#13; BIOSWriteStr(smsg); PauseUser;

  m6845_SetColor(c_alternate_intensity);
  smsg:='This is green/red/yellow (high).  '#13; BIOSWriteStr(smsg); PauseUser;

  m6845_SetColor(c_paletteCMW);  
m6845_Setmode(c_graphics_enable+c_videosignal_enable+c_blackandwhite_enable);
  smsg:='This is cyan/red/white (low).     '#13; BIOSWriteStr(smsg); PauseUser;

  m6845_SetColor(c_paletteCMW+c_alternate_intensity);
  smsg:='This is cyan/red/white (high).    '#13; BIOSWriteStr(smsg); PauseUser;

So it should have worked on the PC1512, right? What am I missing?

[*]In the retrace detect test, the bars are barely visible at the bottom of the screen.

That is also very surprising. I draw the bars by monitoring horizontal retrace obviously, and I start drawing only after waiting for the start of the display cycle. The fact that the bars are at the bottom is very confusing...

[*] The 90x30 test, interlace test, and retrace test all fail, owing to incomplete emulation of the MC6845.

Thanks for the report. I think I'll collect these reports and put them on the website when I get the final version out tonight along with the reference video. I knew some clones had odd emulation, but I didn't know some would be off in the ways that they are.
 
I do recall using a Heath/Zenith 8088 desktop computer with its standard CGA video, however, and everything worked fine, including interlaced mode -- perhaps one of the few clones to implement it. It looked just like this, and even had electronic key click through the speaker -- a nice touch.

I remember a friend's 286 like that. The speed and keyclick were adjustable via a keyboard combo using the ctrl- and stuff on the numeric keypad, if memory serves.
 
Hey Jim, I tried your program and it works just fine in my IBM PC 5150, although:

The mouse cursor tends to get lost after running a test.

The System ID utility needs work. It says my system type is "unknown" and that I have an 80C88 in my machine.
 
Hey Jim, I tried your program and it works just fine in my IBM PC 5150, although:

The mouse cursor tends to get lost after running a test.

The System ID utility needs work. It says my system type is "unknown" and that I have an 80C88 in my machine.

The mouse cursor is a bug I've noted in the docs. I don't plan on fixing it until I attach a mouse to my dev machine. To be honest, I plan on disabling mouse support from the GUI routines altogether since it's not needed.

As for the system ID routines, if I can't reproduce the bug, I can't fix it... I have only one 5150 with the first rev bios, which I'm assuming you're running, but mine isn't fully operational yet. Did it at least find the BIOS copyright string ok?

I'm uploading a reference video; once it's done and linked to from the website, I'll make a final post somewhere.
 
But the second-to-last palette test does clear bit five.
Looks like it's setting it to me:
Code:
  m6845_SetColor([B]c_paletteCMW[/B]);  
  m6845_Setmode(c_graphics_enable+c_videosignal_enable+c_blackandwhite_enable);
  smsg:='This is cyan/red/white (low).     '#13; BIOSWriteStr(smsg); PauseUser;

  m6845_SetColor([B]c_paletteCMW[/B]+c_alternate_intensity);
  smsg:='This is cyan/red/white (high).    '#13; BIOSWriteStr(smsg); PauseUser;
 
As for the system ID routines, if I can't reproduce the bug, I can't fix it... I have only one 5150 with the first rev bios, which I'm assuming you're running, but mine isn't fully operational yet. Did it at least find the BIOS copyright string ok?

Yes, the BIOS copyright string was displayed fine. I use the third IBM PC 5150 BIOS, 10/27/82. My 8088 is an NEC model, but is clearly not marked as an 80C88, assuming that one could be installed in the slot.
 
Looks like it's setting it to me:
Code:
  m6845_SetColor([B]c_paletteCMW[/B]);  
  m6845_Setmode(c_graphics_enable+c_videosignal_enable+c_blackandwhite_enable);
  smsg:='This is cyan/red/white (low).     '#13; BIOSWriteStr(smsg); PauseUser;

  m6845_SetColor([B]c_paletteCMW[/B]+c_alternate_intensity);
  smsg:='This is cyan/red/white (high).    '#13; BIOSWriteStr(smsg); PauseUser;

Whoops, I was assuming you were referring to the fifth bit instead of bit #5 (counting from 0). You're right; sorry about that.

I thought about changing it, but then changed my mind as it is a more accurate test if it is left alone, as it flushes out the incompatibility with the PC1512.
 
Back
Top