• Please review our updated Terms and Rules here

True CGA vs VGA card in CGA mode

First of all, every single Med-Res mode appear zig-zaged on the display (kind of flickering). Some spesiffic color combinations gives a totally washed-out picture. The only thing not flickering was the bars in the Horizontal retrace test.

I would expect this of composite output; I did not test with one, so it is very likely that some (most?) of the color combinations produce a bad picture.

Someday I'll add proper composite color monitor support to the program, but for now, assume the program is only relevant for RGB monitors.

Hi-Res mode appear fine, but compleetely without color.

Again, I'd expect that from composite output.

In the snow test, snow seemd to appear all over the screen, not just below the text.

Well THAT's odd. I was somewhat proud of that code; it specifically monitors horizontal retrace and doesn't start the snow test until after 16 scanlines of the display area have gone by. Do the horizontal colored bars work? That uses the same code. It is extremely strange for one to work and the other to not work...

The adapter changed to 80*25 after one test was run.

Yes, that's part of the reset procedure; when I exit a test, I call the BIOS 80x25 init to get everything back to a sane value (this is intentional, for better recovery on clones). You said this was on a real IBM CGA -- how were you running it otherwise? 40-column mode?

The only test not working as CGA (except the Snow test) was the Interlached test. Instead of one set of big letters filling the screen, the display is divided into 2 parts (horizontally on the middle) and the same text appear both on the upper part and the lower part. Is this actually how the Interlached mode should be?

No; see the example video for what it is supposed to look like.
 
As I got my A Drive working, I finally got to test the program. Now it reports it corectly as an Intel 8088. However, the machine-type is still 'unknown'.

My detection code essentially does two things (it does more, but these are the basics):

1. Try the graceful method using Int 15/AH=C0h (GET CONFIGURATION (XT >1986/1/10) and see what comes back. The original PC is supposed to honor this, and return something like:

Code:
FFh    *       *       04/24/81        PC (original)
FFh    *       *       10/19/81        PC (some bugfixes)
FFh    *       *       10/27/82        PC (HD, 640K, EGA support)
FEh    *       *       08/16/82        PC XT
FEh    *       *       11/08/82        PC XT and Portable

...etc. So I have a section of code that deals with that:

Code:
$FF00 : If BiosDate = '04/24/81' Then
                EndString := ConCat (EndString, 'PC-0 (16k Motherboard)')
              Else If BiosDate = '10/19/81' Then
                  EndString := ConCat (EndString, 'PC-1 (64k Motherboard)')
                Else If BiosDate = '08/16/82' Then
                    EndString := ConCat (EndString, 'PC, XT/XT-370 (256k Motherboard)')
                  Else If BiosDate = '10/27/82' Then
                    EndString := ConCat (EndString, 'PC, XT/XT-370 (256k Motherboard)');

2. If nothing comes back, we have to hit the machine ID byte. I use this code:

Code:
Case Mem[$FFFF:$000E] Of
  $FF : EndString := ConCat (EndString, 'PC');
  $FE : EndString := ConCat (EndString, 'PC/XT');
  $FD : EndString := ConCat (EndString, 'PCJr');
  $FC : EndString := ConCat (EndString, 'PC/AT');
  $FB : EndString := ConCat (EndString, 'PC/XT');
  $FA : EndString := ConCat (EndString, 'PS/2 Model 30');
  $F9 : EndString := ConCat (EndString, 'PS/2 Convertible');
  $F8 : EndString := ConCat (EndString, 'PS/2 Model 90/95?');
  $9A : EndString := ConCat (EndString, 'Compaq XT or Compaq Plus');
  $2D : EndString := ConCat (EndString, 'Compaq PC or Compaq Deskpro');
  $30 : EndString := ConCat (EndString, 'Sperry PC');
  $E9 : EndString := ConCat (EndString, 'Peacock XT');
Else
  EndString := 'unknown, ID : ' + Hex (xWord1, 4);
End;

So I'm not sure why your system isn't getting detected as something.

Tell me again EXACTLY what system you have, and I will write a custom program for you that will spit out what values it says the bios date, system configuration results, machine ID results, etc. You can run that program, and then I'll analyze it and alter my code so that it is properly detected. I'm especially curious what byte is at $FFFF:$000E on your system.
 
My detection code essentially does two things (it does more, but these are the basics):

1. Try the graceful method using Int 15/AH=C0h (GET CONFIGURATION (XT >1986/1/10) and see what comes back. The original PC is supposed to honor this, and return something like:

Code:
FFh    *       *       04/24/81        PC (original)
FFh    *       *       10/19/81        PC (some bugfixes)
FFh    *       *       10/27/82        PC (HD, 640K, EGA support)
FEh    *       *       08/16/82        PC XT
FEh    *       *       11/08/82        PC XT and Portable

...etc. So I have a section of code that deals with that:

Code:
$FF00 : If BiosDate = '04/24/81' Then
                EndString := ConCat (EndString, 'PC-0 (16k Motherboard)')
              Else If BiosDate = '10/19/81' Then
                  EndString := ConCat (EndString, 'PC-1 (64k Motherboard)')
                Else If BiosDate = '08/16/82' Then
                    EndString := ConCat (EndString, 'PC, XT/XT-370 (256k Motherboard)')
                  Else If BiosDate = '10/27/82' Then
                    EndString := ConCat (EndString, 'PC, XT/XT-370 (256k Motherboard)');

2. If nothing comes back, we have to hit the machine ID byte. I use this code:

Code:
Case Mem[$FFFF:$000E] Of
  $FF : EndString := ConCat (EndString, 'PC');
  $FE : EndString := ConCat (EndString, 'PC/XT');
  $FD : EndString := ConCat (EndString, 'PCJr');
  $FC : EndString := ConCat (EndString, 'PC/AT');
  $FB : EndString := ConCat (EndString, 'PC/XT');
  $FA : EndString := ConCat (EndString, 'PS/2 Model 30');
  $F9 : EndString := ConCat (EndString, 'PS/2 Convertible');
  $F8 : EndString := ConCat (EndString, 'PS/2 Model 90/95?');
  $9A : EndString := ConCat (EndString, 'Compaq XT or Compaq Plus');
  $2D : EndString := ConCat (EndString, 'Compaq PC or Compaq Deskpro');
  $30 : EndString := ConCat (EndString, 'Sperry PC');
  $E9 : EndString := ConCat (EndString, 'Peacock XT');
Else
  EndString := 'unknown, ID : ' + Hex (xWord1, 4);
End;

So I'm not sure why your system isn't getting detected as something.

Tell me again EXACTLY what system you have, and I will write a custom program for you that will spit out what values it says the bios date, system configuration results, machine ID results, etc. You can run that program, and then I'll analyze it and alter my code so that it is properly detected. I'm especially curious what byte is at $FFFF:$000E on your system.

That's strange. The byte at the adress in my XT is $FE, and that should return as a XT. However, it just said "machine type: unknown", not "machine type: unknown, ID : $##" as of I remember.
 
Well THAT's odd. I was somewhat proud of that code; it specifically monitors horizontal retrace and doesn't start the snow test until after 16 scanlines of the display area have gone by. Do the horizontal colored bars work? That uses the same code. It is extremely strange for one to work and the other to not work...
It might ave been the flickering too, it was really difficult to se anything clear because of all the zig-zagging.

If I'm lucky, I'll soon get a 5153. Somebody I know got one, and they don't need it anymore. I hope it works.

Yes, that's part of the reset procedure; when I exit a test, I call the BIOS 80x25 init to get everything back to a sane value (this is intentional, for better recovery on clones). You said this was on a real IBM CGA -- how were you running it otherwise? 40-column mode?



No; see the example video for what it is supposed to look like.

Didn't the readme say that Interlaced mode was broken with a real CGA card? I'm kindof confused because if it is broken on the real GCA card, what should it actually look like if it worked?
 
It might ave been the flickering too, it was really difficult to se anything clear because of all the zig-zagging.
Try adjusting the controls on your monitor. Many composite monitors and TV sets will distort the image -- turning straight lines into diagonal ones -- if you turn the brightness and contrast ("picture" on a TV set) up too high (or leave them at the normal settings for watching TV).

IIRC, this is because the CGA board puts out a composite signal of 1.0 Vpp (volts peak-to-peak), which is brighter than the standard of 0.7 Vpp for video sources like VCRs, DVD players, etc. So, you have to turn down the brightness on your monitor or TV set to compensate.

Didn't the readme say that Interlaced mode was broken with a real CGA card? I'm kindof confused because if it is broken on the real GCA card, what should it actually look like if it worked?
The three lines of text at the top of the screen should be half the normal height, and the text below it in large block letters ("Interlaced mode on. Press key to exit.") should fit the screen and should be flickering quite madly.

If the large block text spills off the bottom edge of the screen or wraps around, and isn't flickering, then you are not seeing interlaced mode.
 
Try adjusting the controls on your monitor. Many composite monitors and TV sets will distort the image -- turning straight lines into diagonal ones -- if you turn the brightness and contrast ("picture" on a TV set) up too high (or leave them at the normal settings for watching TV).

IIRC, this is because the CGA board puts out a composite signal of 1.0 Vpp (volts peak-to-peak), which is brighter than the standard of 0.7 Vpp for video sources like VCRs, DVD players, etc. So, you have to turn down the brightness on your monitor or TV set to compensate.
That's problably why the ATI card handled composite bether than the CGA card. Maybe the ATI uses a sligtly lower voltage.
 
Didn't the readme say that Interlaced mode was broken with a real CGA card? I'm kindof confused because if it is broken on the real GCA card, what should it actually look like if it worked?

When I wrote "broken" I meant that the second scanline was not offset one scanline downward. This means both scanlines appear in the same physical space, which is not a typical interlaced display.

I guess "broken" is a bad choice of words; I think "not implemented properly" is better.
 
I'll check my code for errors then.

I found an error, but it's not related to your issue.

Could you do me a favor? On your machine, run debug and type the following at the "-" prompt:

Code:
a (enter)
mov ah,c0 (enter)
int 15 (enter)
int 20 (enter)
(enter again)
g 0104 (enter)

...and there should be a register display that looks like this:

Code:
-g 0104

AX=0000  [B]BX=E73C[/B]  CX=0000  DX=0000  SP=FFEE  BP=0000  SI=0000  DI=0000
DS=0B3A  [B]ES=F000[/B]  SS=0B3A  CS=0B3A  IP=0104   NV UP EI PL NZ AC PE [B]NC[/B]
0B3A:0104 CD20          INT     20

Record what the bolded values are. I then need you to dump RAM at the location pointed to by ES:BX, with a range extending five bytes past BX, like this (you would use your own values as reported by ES and BX obviously):

Code:
d [B]F000[/B]:[B]E73C[/B],E740 (enter)

Let me know what the output of both the register dump and memory dump is, and I'll be able to get to the bottom of what your machine is reporting and why I'm not detecting it.
 
I found an error, but it's not related to your issue.

Could you do me a favor? On your machine, run debug and type the following at the "-" prompt:

Code:
a (enter)
mov ah,c0 (enter)
int 15 (enter)
int 20 (enter)
(enter again)
g 0104 (enter)

...and there should be a register display that looks like this:

Code:
-g 0104

AX=0000  [B]BX=E73C[/B]  CX=0000  DX=0000  SP=FFEE  BP=0000  SI=0000  DI=0000
DS=0B3A  [B]ES=F000[/B]  SS=0B3A  CS=0B3A  IP=0104   NV UP EI PL NZ AC PE [B]NC[/B]
0B3A:0104 CD20          INT     20

Record what the bolded values are. I then need you to dump RAM at the location pointed to by ES:BX, with a range extending five bytes past BX, like this (you would use your own values as reported by ES and BX obviously):

Code:
d [B]F000[/B]:[B]E73C[/B],E740 (enter)

Let me know what the output of both the register dump and memory dump is, and I'll be able to get to the bottom of what your machine is reporting and why I'm not detecting it.

As said, my XT got the early revision BIOS, and Int 15h on my machine gives a dummy return.

The routine run at Int15h in my XT is simply:
Code:
STC
MOV AH,86H
RET 2

According to the IBM TechRef.
 
Not to go too off topic, but I brought out my soldering iron to solder two pins to the jumper pads at P3 on my IBM CGA card. I then capped those pins with a jumper and saw the thin-font for the first time outside of Trixter's program on real hardware.
 
Not to go too off topic, but I brought out my soldering iron to solder two pins to the jumper pads at P3 on my IBM CGA card. I then capped those pins with a jumper and saw the thin-font for the first time outside of Trixter's program on real hardware.

Heh, I bet only a handful of people in the world have done that. :)

As you probably know, the thin font was not normally used because it was hard to see on a TV screen. That's also why the C64 used a thick font instead of the thin text used on the PET and VIC-20.

It's even more weird that the MDA's character ROM includes both CGA fonts.
 
Heh, I bet only a handful of people in the world have done that. :)

As you probably know, the thin font was not normally used because it was hard to see on a TV screen. That's also why the C64 used a thick font instead of the thin text used on the PET and VIC-20.
I heard about the thin-font trick over a decade ago on CompuServe's PC Hardware Forum and tried it back then. Allegedly, some CGA boards conveniently came with the pins already installed, so you could just pop on a jumper to get the thin font. However, all the ones I've seen just have the solder pads.

I used the thin font for some time and while at first it's great to just have something different to look at, in the long run the standard thick font is simply more readable on a color monitor. Even a good RGB monitor like the IBM 5153 or Tandy CM-11 just isn't sharp enough to do the thin font justice. I'd only recommend using the thin font with a monochrome composite monitor, like the built-in display in the IBM Portable PC.

It's even more weird that the MDA's character ROM includes both CGA fonts.
There is long-running folklore of some MDA boards having support for color output as 8-color RGB (no Intensity signal) at the standard MDA frequency and refresh rate, with circuit traces going to the Red, Green, and Blue pins of the video output connector. Even though I have a Mitsubishi multi-frequency color RGB monitor which is capable of displaying MDA video, I can't confirm this because my own MDA board does not contain this vestigal color circuitry. Read more about it (and about other MDA weirdness) here:

http://www.seasip.info/VintagePC/mda.html
 
There is long-running folklore of some MDA boards having support for color output as 8-color RGB (no Intensity signal) at the standard MDA frequency and refresh rate, with circuit traces going to the Red, Green, and Blue pins of the video output connector. Even though I have a Mitsubishi multi-frequency color RGB monitor which is capable of displaying MDA video, I can't confirm this because my own MDA board does not contain this vestigal color circuitry. Read more about it (and about other MDA weirdness) here:

http://www.seasip.info/VintagePC/mda.html

I recall when I got my 5150 with MDA being very puzzled about the circuitry on it. Traces that went nowhere; seemingly unnecessary logic on board. Really, the package count on it is way too high for what it really is. My only guess is that it was shoved out the door before the design could be optimized.
 
I have heard IBM wanted to make a combo color and MDA card, but did not have time to finsh the dual design in such a short one year timeline for the entire system.

I recall when I got my 5150 with MDA being very puzzled about the circuitry on it. Traces that went nowhere; seemingly unnecessary logic on board. Really, the package count on it is way too high for what it really is. My only guess is that it was shoved out the door before the design could be optimized.
 
I heard about the thin-font trick over a decade ago on CompuServe's PC Hardware Forum and tried it back then. Allegedly, some CGA boards conveniently came with the pins already installed, so you could just pop on a jumper to get the thin font. However, all the ones I've seen just have the solder pads.

Mine included.

There is long-running folklore of some MDA boards having support for color output as 8-color RGB (no Intensity signal) at the standard MDA frequency and refresh rate, with circuit traces going to the Red, Green, and Blue pins of the video output connector. Even though I have a Mitsubishi multi-frequency color RGB monitor which is capable of displaying MDA video, I can't confirm this because my own MDA board does not contain this vestigal color circuitry. Read more about it (and about other MDA weirdness) here:

Chuck is right that the MDA has way more circuitry than is necessary for monochrome text and a printer port. Heck, the Hercules has a lower chip count, and also fits everything onto a 3/4 length card, rather than a full-length one.

I could very well believe that IBM's original intention was for a single card that did both monochrome and color.
 
As said, my XT got the early revision BIOS, and Int 15h on my machine gives a dummy return.

The routine run at Int15h in my XT is simply:
Code:
STC
MOV AH,86H
RET 2

That'll do it :)

New version is 0.5a at http://www.oldskool.org/pc/cgacomp and it should report your system properly. I also added Tandy 1000 detection logic and also reduced memory requirements such that it should run on a 128KB machine quite comfortably.

Unless bugs are found, I plan to be done with this. Next two projects coming up are 1. that benchmarking/comparison program I keep threatening to write (going over my detection code was a nice refresher), and 2. a substantial rewrite of MONOTONE to make the program more practical and support the Tandy/PCjr chip.
 
I could very well believe that IBM's original intention was for a single card that did both monochrome and color.
That's what Compaq did a year later on their original Portable: hi-res mono text and CGA-compatible color graphics, on the same video board -- and a neat little dual-res monitor to go along with it, which could handle both scan rates without getting fried.

But remember, IBM was reusing a lot of parts from the System/23 DataMaster in the PC, most noticeably the keyboard and the expansion bus slot design. I haven't found info to confirm this, but it is likely that the MDA specs were a direct copy of the DataMaster's internal display, with the addition of what we can guess was a project to add color capability that seems to have been 50% to 60% complete at the time it was cancelled in favor of a separate CGA board.

And speaking of unfinished projects, I've heard that the aforementioned Compaq Portable "I" has pinouts on its motherboard for a cassette port that was ultimately never implemented.
 
Last edited:
And speaking of unfinished projects, I've heard that the aforementioned Compaq Portable "I" has pinouts on its motherboard for a cassette port that was ultimately never implemented.

They probably were going to, but then said "Hey wait a minute, why are we adding a cassette port? Nobody uses that!" :p

It was a moot point anyway since IBM owned the license for cassette BASIC, and so no one else could include it in their machines.
 
They probably were going to, but then said "Hey wait a minute, why are we adding a cassette port? Nobody uses that!" :p

It was a moot point anyway since IBM owned the license for cassette BASIC, and so no one else could include it in their machines.

Oh, I'm sure M$ would have sold licenses for a machine-specific cassette BASIC to other vendors...in fact, they did...to everybody!

--T
 
Back
Top