PDA

View Full Version : True CGA vs VGA card in CGA mode



QuantumII
January 5th, 2009, 04:23 AM
Hi all

Is there any performance differences between a true CGA card and a 8-bit VGA card running CGA graphics ?

per
January 5th, 2009, 04:55 AM
If it has switches so it oculd be toggeled to CGA mode on startup, it would operate as a CGA, and there would be no differences unless the card is of lower quality and price.

However, if it's configured as VGA on startup, it might have some problems with certain CGA graphics modes.

patscc
January 5th, 2009, 09:00 AM
Well, they typically live at different addresses in the pc's address space.
0A0000-0AFFFF VGA/EGA Video Memory
0B0000-0B0FFF Monochrome Video Memory
0B8000-0BFFFF CGA

patscc

QuantumII
January 5th, 2009, 11:52 AM
Well, they typically live at different addresses in the pc's address space.
0A0000-0AFFFF VGA/EGA Video Memory
0B0000-0B0FFF Monochrome Video Memory
0B8000-0BFFFF CGA

patscc

Okay. I was thinking more along the line: If I run a game in CGA on a VGA card or run it on a true CGA card, will there be any noticeable performance differences ?

I talk simple games, like Alley Cat :-)

per
January 5th, 2009, 12:09 PM
Okay. I was thinking more along the line: If I run a game in CGA on a VGA card or run it on a true CGA card, will there be any noticeable performance differences ?

I talk simple games, like Alley Cat :-)

I have had some problems with that. Often, the VGA is toggeled into wrong video modes, ant it doesn't really support some of the special modes of the CGA, like some of the CGA's graphics mode, like morecolors and the BG/red/cyan/white palette.

See the attachement of running Flightsimulator 2.13 (Booter) on a VGA in VGA mode and VGA in CGA mode. Note that "Signal Error" alert in the upper right courner on one of the pictures, hence, NOT recomended on CRT monitors.

Fallo
January 5th, 2009, 04:32 PM
I have had some problems with that. Often, the VGA is toggeled into wrong video modes, ant it doesn't really support some of the special modes of the CGA, like some of the CGA's graphics mode, like morecolors and the BG/red/cyan/white palette.

See the attachement of running Flightsimulator 2.13 (Booter) on a VGA in VGA mode and VGA in CGA mode. Note that "Signal Error" alert in the upper right courner on one of the pictures, hence, NOT recomended on CRT monitors.

Galaxian is one game I know that does this. It works on some VGA monitors, but on others the picture loses sync.

Moon Patrol always locks up about 7 seconds into the game (Demonlord noted this on his site). Both of these games have some kind of problem with VGA, but I'm not sure what.

VGA is BIOS compatible with CGA, but not register compatible. At least 60% of CGA software works on VGA, but the other 30% either partially or completely fails. This can be caused by any of the following:

*Setting video modes or color palettes by writing directly to the registers

*Using the 160x100 pseudographics mode

*Raster interrupts

*Tweaking the 6845 registers to produce effects like screen shaking

QuantumII
January 5th, 2009, 11:33 PM
I have had some problems with that. Often, the VGA is toggeled into wrong video modes, ant it doesn't really support some of the special modes of the CGA, like some of the CGA's graphics mode, like morecolors and the BG/red/cyan/white palette.

See the attachement of running Flightsimulator 2.13 (Booter) on a VGA in VGA mode and VGA in CGA mode. Note that "Signal Error" alert in the upper right courner on one of the pictures, hence, NOT recomended on CRT monitors.

Yeah, I tried FS on VGA, and it was just like your picture.. Say, did you boot the game from a floppy or did you run the fs.com file ?

per
January 6th, 2009, 12:05 AM
Yeah, I tried FS on VGA, and it was just like your picture.. Say, did you boot the game from a floppy or did you run the fs.com file ?

I booted from a floppy (from retrogade, that one got no hidden message on it).

You say you got a CGA with a RCA jack. If you got a monitor/TV capable of displaying NTSC, you could connect it to the CGA. FS is a lot better in composite than RGBI.

Chuck(G)
January 6th, 2009, 10:01 AM
How about a CGA with a scan converter box (as discussed on other threads?). I assume the idea is to use a VGA monitor.

QuantumII
January 6th, 2009, 12:53 PM
How about a CGA with a scan converter box (as discussed on other threads?). I assume the idea is to use a VGA monitor.

Yes, if I cannot get a CGA monitor within reasonable time (I'm an impatient guy sometimes) I'll get one of those.. They could be nice to have anyway :-)

QuantumII
January 11th, 2009, 11:14 AM
Hi

Today I did some tests (True CGA card VS VGA Card in CGA mode)

Results: The true CGA card was faster and the graphics was smoother.

Alley Cat is choppy when running ona VGA card (Many items on screen, bad performance)

When using a true CGA card is was running along just fine, regardless of the items on screen etc etc..

How come ? Anyone seen it before ?

per
January 11th, 2009, 11:46 AM
Hi

Today I did some tests (True CGA card VS VGA Card in CGA mode)

Results: The true CGA card was faster and the graphics was smoother.

Alley Cat is choppy when running ona VGA card (Many items on screen, bad performance)

When using a true CGA card is was running along just fine, regardless of the items on screen etc etc..

How come ? Anyone seen it before ?

The VGA's ability to emulate CGA isn't 100% perfect. my guess it that it varys from card to card. Also VGA uses other registers, so if the program does low-level stuff (IN/OUTs), then it might write to other registers than it is supposed to. Another cause can be that the version program you're using is modified for newer computers (most unlikely).

QuantumII
January 11th, 2009, 02:22 PM
The VGA's ability to emulate CGA isn't 100% perfect. my guess it that it varys from card to card. Also VGA uses other registers, so if the program does low-level stuff (IN/OUTs), then it might write to other registers than it is supposed to. Another cause can be that the version program you're using is modified for newer computers (most unlikely).

Okay. I think it's because _some_ emulation are taking place, native CGA will have better performance. The 4.77Mhz is not that much, and the hardware overhead of doing the emulating affects the performance for programs written for pure CGA.

Of course, on newer PC's this is not noticeable (I tried) but the IBM's limited speed in combination with the above is the reason (I think)

I have now bought an original IBM CGA card off eBay. I will use that instead when I a) Get an IBM 5153 or b) Get a cga-to-vga converter or c) get an LCD with composite in..

I think option b is most likely right now, but I will continue to hunt for an IBM 5153.

patscc
January 11th, 2009, 04:35 PM
I seem to remember having to twiddle with timings when writing CGA code to minimize snow. That might be why some games look odd on VGA-emulated CGA, since I don't think you get the CGA snow problem on VGA cards. Although I certainly could be wrong.

patscc

Fallo
January 12th, 2009, 10:22 AM
Okay. I think it's because _some_ emulation are taking place, native CGA will have better performance. The 4.77Mhz is not that much, and the hardware overhead of doing the emulating affects the performance for programs written for pure CGA.

I've run CGA games on my 386 with the turbo off, and I don't notice any performance problems. Alley Cat doesn't use any weird video tricks either, so there's no real difference between running it on a CGA or a VGA card (you do have to run it at 4.77Mhz to hear the digitized sound effects, though).


I have now bought an original IBM CGA card off eBay. I will use that instead when I a) Get an IBM 5153 or b) Get a cga-to-vga converter or c) get an LCD with composite in..

I have a CGA card too, but I don't yet have a working 5150 or XT to put it in.

QuantumII
January 12th, 2009, 10:28 AM
I've run CGA games on my 386 with the turbo off, and I don't notice any performance problems. Alley Cat doesn't use any weird video tricks either, so there's no real difference between running it on a CGA or a VGA card (you do have to run it at 4.77Mhz to hear the digitized sound effects, though).



I have a CGA card too, but I don't yet have a working 5150 or XT to put it in.

The difference is there, trust me :)

Regarding the 5150:
Ebay has a few listed now, but it's not exactly mint condition units...

Fallo
January 12th, 2009, 12:03 PM
The difference is there, trust me :)

Regarding the 5150:
Ebay has a few listed now, but it's not exactly mint condition units...

That's usually the case. About two weeks ago, there was one 5150 on there that was a real scream. The seller's description was simply "IBM 5150", accompanied by one picture of the computer. There were no images of the back or the inside, and no information as to whether the computer worked or not, what cards were in it, or if it was a 16k-64k or a 64k-256k model. As you can well imagine, the auction ended without any takers.

QuantumII
January 12th, 2009, 12:49 PM
That's usually the case. About two weeks ago, there was one 5150 on there that was a real scream. The seller's description was simply "IBM 5150", accompanied by one picture of the computer. There were no images of the back or the inside, and no information as to whether the computer worked or not, what cards were in it, or if it was a 16k-64k or a 64k-256k model. As you can well imagine, the auction ended without any takers.

Hehe yeah, I know the kind. When the tools cannot even take proper pictures or try to describe the item they don't want it to get sold. (usually such items are also overpriced)

hargle
January 12th, 2009, 01:26 PM
I've found this thread to be really interesting, especially the differences noted in both alley cat and FS.

I'm wondering if someone (trixter perhaps?) could put together a small program/benchmark program to help us quickly and easily know the differences between true CGA and VGA, and that could then help us figure out what the best VGA card is to use on our machines. I have a half dozen ISA VGA cards and I have no idea which one might give me the best CGA performance for the buck.

QuantumII
January 12th, 2009, 01:32 PM
I've found this thread to be really interesting, especially the differences noted in both alley cat and FS.

I'm wondering if someone (trixter perhaps?) could put together a small program/benchmark program to help us quickly and easily know the differences between true CGA and VGA, and that could then help us figure out what the best VGA card is to use on our machines. I have a half dozen ISA VGA cards and I have no idea which one might give me the best CGA performance for the buck.

Second that. Such an utility would be very useful. This also allows us to check the difference between different CGA cards as well :-)

QuantumII
January 12th, 2009, 01:39 PM
I've run CGA games on my 386 with the turbo off, and I don't notice any performance problems. Alley Cat doesn't use any weird video tricks either, so there's no real difference between running it on a CGA or a VGA card (you do have to run it at 4.77Mhz to hear the digitized sound effects, though).




Heh, a 386 is a bit faster than an XT you know ;) The (small) hardware overhead is probably not noticeable on a 386.

Fallo
January 12th, 2009, 01:52 PM
Heh, a 386 is a bit faster than an XT you know ;) The (small) hardware overhead is probably not noticeable on a 386.

If you're curious, it's a 386SX/20 with a 16-bit Oak VGA card. It has an AMI BIOS that lets you set the turbo off speed to 4, 6, 8, or 10 Mhz.

per
January 12th, 2009, 01:59 PM
If you're curious, it's a 386SX/20 with a 16-bit Oak VGA card.

Do you know if it is using OTI-67 chipset, and if it is the wide or narrow version of the card?

The problem migh just be something as simple as the card is not optimalized when running in an 8-bit ISA slot.

Could you try to move the card to an 8-bit ISA slot?

QuantumII
January 12th, 2009, 02:10 PM
Do you know if it is using OTI-67 chipset, and if it is the wide or narrow version of the card?

The problem migh just be something as simple as the card is not optimalized when running in an 8-bit ISA slot.

Could you try to move the card to an 8-bit ISA slot?

Yes, I agree with that.

Fallo: Can you try ?

Fallo
January 12th, 2009, 03:21 PM
Do you know if it is using OTI-67 chipset, and if it is the wide or narrow version of the card?

It's like this one:

http://cgi.ebay.com/Oak-Tech-OTIVGA-16-bit-VGA-Card_W0QQitemZ200241571278QQcmdZViewItemQQptZLH_De faultDomain_0?_trksid=p3286.m20.l1116


Could you try to move the card to an 8-bit ISA slot?

Alas, this 386 has no 8-bit slots. If it did, I would have tried out my CGA card a long time ago (it won't fit in a 16-bit slot because of the overhang).

per
January 12th, 2009, 10:14 PM
It's like this one:

http://cgi.ebay.com/Oak-Tech-OTIVGA-16-bit-VGA-Card_W0QQitemZ200241571278QQcmdZViewItemQQptZLH_De faultDomain_0?_trksid=p3286.m20.l1116



Alas, this 386 has no 8-bit slots. If it did, I would have tried out my CGA card a long time ago (it won't fit in a 16-bit slot because of the overhang).

you can try to mask of the upper 16-bit parts so only the lower 8-bit part can communicate with the computer. Masking-tape is fine here because it is easy to remove afterwards.

Fallo
January 12th, 2009, 11:02 PM
you can try to mask of the upper 16-bit parts so only the lower 8-bit part can communicate with the computer. Masking-tape is fine here because it is easy to remove afterwards.

There is one other way: I can put my Hercules card in the 386. As you may know, using a monochrome and a 16-bit VGA card in the same PC will cause the latter to slow down to 8-bit speed (owing to the ISA bus's architecture).

patscc
January 13th, 2009, 08:16 AM
Fallo said...slow down to 8-bit speed

How would that work, then ? There was no support for autoconfiguration on ISA.
ISA also ran at the system clock speed. This was changed in later boards where, as was pointed out, you could select the ISA bus speed, but there's nothing in the spec that allows the speed to be negotiated by the card talking to the board.
On 16-bit ISA, the card could request 8 or 16 bit transfers from the DMA, but this was on a
card-by-card basis & transfer-by-transfer basis, not system wide.
Some DMA channels were defined a s 8-bit, others 16-bit, which caused problems.
Slapping a 8-bit card onto a 16-bit bus could cause problems, but any slowdown isn't due the bus magically deciding to run at a slower speed, or to suddenly force all other card into 8 bits if a 8 bit card is present.
Of course, I might be remembering something incorrectly, or phrasing something badly, so if Fallo has any references for the
slow down to 8-bit speed I wouldn't mind reading up on it.

patscc

Fallo
January 13th, 2009, 10:56 AM
How would that work, then ? There was no support for autoconfiguration on ISA.
ISA also ran at the system clock speed. This was changed in later boards where, as was pointed out, you could select the ISA bus speed, but there's nothing in the spec that allows the speed to be negotiated by the card talking to the board.

It's because the ISA bus decodes memory in 128k blocks. If an 8 and 16-bit card are using memory within the same block (as monochrome and VGA do), the 16-bit card will slow down. This does not affect VESA or PCI VGA cards (obviously since they're not on the ISA bus).

QuantumII
January 13th, 2009, 11:24 AM
It's because the ISA bus decodes memory in 128k blocks. If an 8 and 16-bit card are using memory within the same block (as monochrome and VGA do), the 16-bit card will slow down. This does not affect VESA or PCI VGA cards (obviously since they're not on the ISA bus).

Good to know. But anyway..

Does anybody here have an XT and both a VGA card and a CGA card so that they can compare the performance ? Use Alley Cat as a benchmark. The slowdown when the dog appears is very noticeable, and also when swimming in the fish tank.

First try it with the VGA card, second replace the card with a CGA (native) adapter, and try again. :cool:

patscc
January 13th, 2009, 11:46 AM
Fallo saidIt's because the ISA bus decodes memory in 128k blocks
The bus itself doesn't do any, nor specify any kind of paging.
Are you thinking of DMA transfers ?
DMA Channels 1, 2 and 3 use up to 64k frames.
DMA Channels 5, 6 and 7 use up to 128k frames.

This can cause problems, I agree. I guess I'll have to think about it some and perhaps try it out with a Herc & VGA on a 386 board, 'cause I'm just not seeing the 16-bit card running using only 64 k frames. But it's been a while since I've played around with this.

patscc

Trixter
January 14th, 2009, 02:22 PM
I seem to remember having to twiddle with timings when writing CGA code to minimize snow. That might be why some games look odd on VGA-emulated CGA, since I don't think you get the CGA snow problem on VGA cards. Although I certainly could be wrong.


Only the original IBM CGA card and very close compatibles (like the display board in an AT&T PC 6300 or Olivetti M24) have snow when writing to 80-column textmode. All other cards don't have this problem.

Trixter
January 14th, 2009, 02:27 PM
It's because the ISA bus decodes memory in 128k blocks. If an 8 and 16-bit card are using memory within the same block (as monochrome and VGA do), the 16-bit card will slow down. This does not affect VESA or PCI VGA cards (obviously since they're not on the ISA bus).

VGA and MDA do not use memory that crosses a common page boundary. VGA uses a000-afff and b800-bbff. MDA uses b000-b7ff.

Trixter
January 14th, 2009, 02:32 PM
I've found this thread to be really interesting, especially the differences noted in both alley cat and FS.

I'm wondering if someone (trixter perhaps?) could put together a small program/benchmark program to help us quickly and easily know the differences between true CGA and VGA, and that could then help us figure out what the best VGA card is to use on our machines. I have a half dozen ISA VGA cards and I have no idea which one might give me the best CGA performance for the buck.

I suppose I could do that. It would be good practice to learn a new interface library I've been wanting to try out anyway. It will take me about a week, since I'll also need to produce a reference video so that you guys can see what I see on my original hardware.

QuantumII
January 14th, 2009, 03:05 PM
I suppose I could do that. It would be good practice to learn a new interface library I've been wanting to try out anyway. It will take me about a week, since I'll also need to produce a reference video so that you guys can see what I see on my original hardware.

Cool! If you do that, it would be a very nice utility for us to have :-) Sign me up as a beta tester:cool:

Fallo
January 14th, 2009, 08:27 PM
VGA and MDA do not use memory that crosses a common page boundary. VGA uses a000-afff and b800-bbff. MDA uses b000-b7ff.

What I meant was that VGA and MDA use memory within the same 128k block (A000-BFFF). I invite anyone here to put a monochrome and ISA VGA card in the same computer and see the reduced performance of the latter.

Trixter
January 15th, 2009, 10:23 AM
What I meant was that VGA and MDA use memory within the same 128k block (A000-BFFF). I invite anyone here to put a monochrome and ISA VGA card in the same computer and see the reduced performance of the latter.

...in a computer with 16-bit slots. In our PCs/XTs, with 8-bit slots, plugging both in does not make the VGA go slower. And I still think you're confusing bus memory access with DMA transfers, but I'm not willing to pull out the techref and study it for an hour to debate the point.

In any case, when I write the benchmark, I'll be sure to include an interleaved instruction-memory test (like multiple STOSWs) as well as a memory-only test (REP STOSW) just so any perceived difference will be noticeable, both in the same 128K block as well as outside of it.

per
January 15th, 2009, 10:45 AM
...in a computer with 16-bit slots. In our PCs/XTs, with 8-bit slots, plugging both in does not make the VGA go slower. And I still think you're confusing bus memory access with DMA transfers, but I'm not willing to pull out the techref and study it for an hour to debate the point.

I don't think it is neither of therse either. My guess is that the routine in the BIOS extension on the VGA uses more code than the one in the PC/XT BIOS (whitch is rather slow itself), making it so slow on the 4.77MHz 8088 that the game will have delays and graphics problems.

Trixter
January 15th, 2009, 10:46 AM
Since the BIOS is not used for graphics operations, this is incorrect :-) The BIOS is only used for setting new modes and stuff. Once a game is running, it writes directly to video memory, which is what the OP was talking about.

per
January 15th, 2009, 10:50 AM
Since the BIOS is not used for graphics operations, this is incorrect :-) The BIOS is only used for setting new modes and stuff. Once a game is running, it writes directly to video memory, which is what the OP was talking about.

Ah.. I've only done programming for text-output (the BIOS or DOS routines are heavily used if you don't want to make your own routines there), so I really don't know how to do graphics (yet..).

Maybe it should be like that, and you won't notice on an RGB monitor because of the refresh rates and phosphore type, anyway, I don't know how serve the graphic problems are, but's only a guess.

*Edit*
If we just can't seem to find any sollution, maybe disassembling the Alley-Cat disk could reveal anything... Maybe it does low-level stuff that puts the VGA in some kind of low-preformance mode...

Fallo
January 15th, 2009, 11:15 AM
...in a computer with 16-bit slots. In our PCs/XTs, with 8-bit slots, plugging both in does not make the VGA go slower.

Which was exactly my point.

After searching some old posts on Google Groups, I think I've found the answer. If a 16-bit VGA card tries to access the A000-BFFF block when MDA is present, the MEMCS16 signal (used to request 16-bit memory transfers) can't be activated. There were actually programs written to force the VGA into 16-bit mode, but then the MDA card wouldn't work.

QuantumII
January 15th, 2009, 11:18 AM
Ah.. I've only done programming for text-output (the BIOS or DOS routines are heavily used if you don't want to make your own routines there), so I really don't know how to do graphics (yet..).

Maybe it should be like that, and you won't notice on an RGB monitor because of the refresh rates and phosphore type, anyway, I don't know how serve the graphic problems are, but's only a guess.

*Edit*
If we just can't seem to find any sollution, maybe disassembling the Alley-Cat disk could reveal anything... Maybe it does low-level stuff that puts the VGA in some kind of low-preformance mode...

It's not just Alley Cat. That was just an example. It's Larry 1, Street Rod, Accolade Grand Prix , Zaxxon, 3-Demon etc etc.. It's in general bad CGA performance. This was tested on two different VGA cards, with the same results.

With a true CGA adapter, the games was performing as normal.

per
January 15th, 2009, 11:29 AM
It's not just Alley Cat. That was just an example. It's Larry 1, Street Rod, Accolade Grand Prix , Zaxxon, 3-Demon etc etc.. It's in general bad CGA performance. This was tested on two different VGA cards, with the same results.

With a true CGA adapter, the games was performing as normal.

Then it's after my point of view, the 40% low level incompabilities between CGA and VGA that's causing troubble.

Exactly what is wrong with the graphics.

hargle
January 15th, 2009, 11:36 AM
I suppose I could do that. It would be good practice to learn a new interface library I've been wanting to try out anyway. It will take me about a week, since I'll also need to produce a reference video so that you guys can see what I see on my original hardware.

The video can probably wait-I think there are enough of us here who have original hardware too, unless you've got some wack CGA card you're using, but I think a lot of us have true blue CGA cards and will be running the benchmark on true blue machines.

I'd think that you could just provide the card's make and model # and the output benchmark results in a text file, the rest of us could do the same with our machines and then start finding the best VGA card out there. I know for certain that I'll be running this test on every video card I have.

FWIW, there's an old benchmark called Speed200.exe
http://www.articannex.ws/dos/utils/SPEED200.EXE
that did some video benchmarking along with CPU tests.
No idea what it really does though or if it would show the differences we want.

QuantumII
January 15th, 2009, 01:40 PM
Then it's after my point of view, the 40% low level incompabilities between CGA and VGA that's causing troubble.

Exactly what is wrong with the graphics.

It's choppy,like when trying to run Crysis on a low-end computer.

When a lot is moving on the screen at once, it's slowing down and the graphics stutters.

Here are some examples:

Alley Cat on VGA: In the alley, you can run around at full speed but then one of the cats poke their head out of the garbage bin, it slows down.

When the dog come it slows down, and when it attacks you, it slows down even more.

When you dive in the fish-tank, the minigame is not playable (many fish moving around)


Alley Cat on true CGA: Everything works fine, no slow-downs.


The graphics look just fine, they are just choppy and slow.

Fallo
January 15th, 2009, 03:29 PM
When you dive in the fish-tank, the minigame is not playable (many fish moving around)

Yep, the fish tank is the one level I've never been able to complete. On an unrelated note, Alley Cat also claims to support a joystick, but for whatever reason it won't detect my 386's game port.

Returning to the main discussion, Alley Cat was always choppy, but I assumed that it was due to the programming, not a video issue. Some CGA games I've tried run screamingly fast (at 4.77 Mhz, believe it or not). Shamus actually gets faster the more enemies are on screen, and Defender is every bit as unforgiving as the arcade game.

per
January 16th, 2009, 01:54 AM
It's choppy,like when trying to run Crysis on a low-end computer.

When a lot is moving on the screen at once, it's slowing down and the graphics stutters.

Here are some examples:

Alley Cat on VGA: In the alley, you can run around at full speed but then one of the cats poke their head out of the garbage bin, it slows down.

When the dog come it slows down, and when it attacks you, it slows down even more.

When you dive in the fish-tank, the minigame is not playable (many fish moving around)


Alley Cat on true CGA: Everything works fine, no slow-downs.


The graphics look just fine, they are just choppy and slow.

Maybe VGA cards are generating wait-states somehow to use system resources... I don't know since I don't got schematics.

Trixter
January 18th, 2009, 05:50 PM
I'd think that you could just provide the card's make and model # and the output benchmark results in a text file, the rest of us could do the same with our machines and then start finding the best VGA card out there. I know for certain that I'll be running this test on every video card I have.


Well, to keep the scope in check, I was going to write a CGA compatibility tester. Meaning, I would exercise CGA in every possible way as a compatibility test, and yes some memory benchmarks with speeds reported would be part of that, but I wasn't going to make this a benchmarking program. Hope that's okay.

I should have it finished in the next five days or so; getting over a respiratory infection that has had me bedridden for a week.

Trixter
January 18th, 2009, 06:12 PM
On an unrelated note, Alley Cat also claims to support a joystick, but for whatever reason it won't detect my 386's game port.


All joystick support is polled due to the way joystick ports were implemented, so if your port is returning higher/faster values than the programmer expected, it would not be detected. This is why Kraft (and others) made "speed-adjustable" joystick cards.

Reading the joystick values from the BIOS returns relatively stable values, but that wasn't implemented until around 1985, so you can't rely on it being there; that, and it's really slow (about 8 results a second) so most people just polled the port themselves. Using a tight loop produces the most accurate and fine results, but is speed-dependent; using the timer produces consistent results but may interfere with other code. I've got example code that does all three if anyone is interested.

Fallo
January 18th, 2009, 08:08 PM
All joystick support is polled due to the way joystick ports were implemented, so if your port is returning higher/faster values than the programmer expected, it would not be detected. This is why Kraft (and others) made "speed-adjustable" joystick cards.

My 386's game port is on a multifunction I/O card with serial, parallel, floppy, and IDE. Alley Cat was probably developed on a machine with the original IBM Game Control Adapter, which may work a bit differently.


Reading the joystick values from the BIOS returns relatively stable values, but that wasn't implemented until around 1985, so you can't rely on it being there; that, and it's really slow (about 8 results a second) so most people just polled the port themselves.

You mean INT 15h function 84h. Only 286+ machines have that, so almost all games read the port directly.

Trixter
January 19th, 2009, 08:23 PM
You mean INT 15h function 84h. Only 286+ machines have that, so almost all games read the port directly.

Not 286+, my 5160 has it -- but I have the last XT BIOS produced by IBM. My BIOS date is 1/10/86 (has a copyright string of COPR. IBM 1986)

per
January 19th, 2009, 10:17 PM
Not 286+, my 5160 has it -- but I have the last XT BIOS produced by IBM. My BIOS date is 1/10/86 (has a copyright string of COPR. IBM 1986)

It's not present in my XT (first revision of the IBM XT BIOS). However, mine got only a dummy return for accidentily called casette I/O (CF=on, AH=86H).

Trixter
January 24th, 2009, 09:58 PM
The video can probably wait-I think there are enough of us here who have original hardware too, unless you've got some wack CGA card you're using, but I think a lot of us have true blue CGA cards and will be running the benchmark on true blue machines.

I'd think that you could just provide the card's make and model # and the output benchmark results in a text file, the rest of us could do the same with our machines and then start finding the best VGA card out there. I know for certain that I'll be running this test on every video card I have.


Well, like everything I do, I don't do it lightly. I've begun work on this and have the follow features frameworked already:

Adapter memory speed benchmarks:
- Interleaved opcode/adapter memory read benchmark
- Interleaved opcode/adapter memory write benchmark
- Adapter Memory-only read benchmark
- Adapter Memory-only write benchmark

Color Select and Mode Control Register tests:
- Border/Overscan color
- Medium-res graphics background color
- High-res graphics foreground color
- Palette display (all six medium-res palettes)

Textmode manipulation:
- 40-column test
- Textmode highcolor background (ie. disable blink)
- Textmode cursor manipulation
- CGA "snow" anomoly
- Font display (simulated via 40-col mode)

Monitor Calibration:
- Brightness calibration
- Contrast calibration
- Moire pattern (high-res horiz/vert/50%)
- Display of 16 colors

MC6845 CRTC programming:
- Horizontal retrace demo
- Vertical retrace detection
- custom text mode (90x30)
- 160x100 text tweakmode
- custom graphics mode (256x200, 160x200, 320x100)

The speed benchmarking is done, as is the CGA Snow detection. I was hoping to add some more tests before releasing it, but since the benchmarking stuff is done, I'm willing to send out a work-in-progress version. Any interest?

Fallo
January 24th, 2009, 11:16 PM
MC6845 CRTC programming:
- Horizontal retrace demo
- Vertical retrace detection
- custom text mode (90x30)
- 160x100 text tweakmode
- custom graphics mode (256x200, 160x200, 320x100)


Sounds good. Try this BASIC program (snagged from an old book on PC graphics). You'll have to reset the computer after running it.

5 '80x100 graphics
10 goto 400
20 screen 1:width 80:screen 0:key off
30 out &h3d0,4: out &h3d1,127
40 out &h3d0,5: out &h3d1,6
50 out &h3d0,6: out &h3d1,100
60 out &h3d0,7: out &h3d1,112
80 out &h3d0,8: out &h3d1,0
90 out &h3d0,9: out &h3d1,1
100 for j=1 to 100:next j
110 out &h3d9,2
120 for j=1 to 10:next j
130 def seg=&hb800
140 return
150 m=160*y+2*x+1
160 poke m,16*c
170 return
400 gosub 20
405 'color bars
410 for c=0 to 15
420 for x=4*c+8 to 4*c+11
430 for y=10 to 15
440 gosub 150
450 next y
460 next x
470 next c
500 'draw lines
530 c=1
540 y=20
550 for x=0 to 79
560 gosub 150
570 next x
580 c=4
590 y=99
600 for x=0 to 79
610 gosub 150
620 next x
630 c=2

Trixter
January 25th, 2009, 01:07 AM
I appreciate the listing, but I've already got a better display/routines than that :-)

I finished up most of the textmode manipulation tests tonight; I might have this entire thing done sooner than I thought.

per
January 25th, 2009, 02:27 AM
I appreciate the listing, but I've already got a better display/routines than that :-)

I finished up most of the textmode manipulation tests tonight; I might have this entire thing done sooner than I thought.

Do you plan to add some tests of the extended Plantonics (IIRC, it's the same as PCjr/Tandy1000) Graphics, or the 200*640 16-color mode found in ATI CGA-clones?

QuantumII
January 25th, 2009, 03:07 AM
The speed benchmarking is done, as is the CGA Snow detection. I was hoping to add some more tests before releasing it, but since the benchmarking stuff is done, I'm willing to send out a work-in-progress version. Any interest?

Yeah, that would be nice. Can you PM me the link, or post it here for everyone to try ?

I am going to try it on the VGA adapter first, then on the original IBM CGA adapter when I have that up and running.

Trixter
January 25th, 2009, 12:08 PM
Do you plan to add some tests of the extended Plantonics (IIRC, it's the same as PCjr/Tandy1000) Graphics, or the 200*640 16-color mode found in ATI CGA-clones?

I was not planning on it, no. While I have a slightly extended CGA to test with (AT&T 6300, has 32K of RAM and can do 640x400), I don't have a plantronics or other extended CGA to test with. So, the goal is currently to test every aspect of a real IBM CGA.

The only stuff not going into the first version of the tool are the lightpen interface (no hardware to test with), composite color (lack of time and I don't want to drag out a composite monitor right now), and the interlaced support of the motorola 6845 character generator (because IBM didn't implement it properly and while I can generate signals with it, no program in the world uses it so it's not worth testing).

Fallo
January 25th, 2009, 01:33 PM
The only stuff not going into the first version of the tool are the lightpen interface (no hardware to test with), composite color (lack of time and I don't want to drag out a composite monitor right now), and the interlaced support of the motorola 6845 character generator (because IBM didn't implement it properly and while I can generate signals with it, no program in the world uses it so it's not worth testing).

The book I got the BASIC listing from also had a program that demonstrates using the interlace mode. It's very flickery, especially on a composite display. They note in the book that "IBM does not support this mode, so they have not tried to tune the adapter to work cleanly with it."

They also had a monochrome version which I tried on my 5151 and Hercules. That one is flicker-free, but because monochrome text mode can only use 4k of memory, it fills up just the center of the screen, leaving the edges empty.

Trixter
January 25th, 2009, 05:27 PM
I would love to see this wonder book of yours -- what is the title?

I also would definitely like to see the interlaced listing, because that's the only thing I have not been able to see any use for. You would think that you can use interlaced mode to get 400 interlaced lines, but when I do it, I just get alternating pages on the same 200 lines (which makes interlaced mode worthless). Working with Andrew Jenner, we determined that IBM did not implement the interlaced functionality properly.

If you can reprint the interlaced listing I would appreciate it...!

Fallo
January 25th, 2009, 08:32 PM
I would love to see this wonder book of yours -- what is the title?

"Graphics Primer for the IBM PC".


I also would definitely like to see the interlaced listing, because that's the only thing I have not been able to see any use for. You would think that you can use interlaced mode to get 400 interlaced lines, but when I do it, I just get alternating pages on the same 200 lines (which makes interlaced mode worthless). Working with Andrew Jenner, we determined that IBM did not implement the interlaced functionality properly.

It's just a short program that turns the interlace mode on and fills the screen with As. You will also get some snow since it's writing directly to the video memory in 80-column text mode. There's four different settings for the interlace register. A value of 0 or 2 just produces a noninterlaced picture. 1 (probably what you tried) causes both pages to repeat the same information, and 3 produces a proper 400-line display.

5 'interlaced text
10 screen 0,0
20 width 80
30 cls
40 out &h3d0,8: out &h3d1,3
50 def seg=&hb800
60 for i=3 to 49
70 for j=0 to 79
80 poke 160*i+2*j,65
90 next j
100 next i

Trixter
January 25th, 2009, 10:05 PM
Thanks for the listing. This confirms what I saw in my own tests -- the card is interlacing memory/output, but the 5153 monitor displays the even and odd scanlines in the same 200 lines. A traditional interlaced mode would display the odd scanlines offset by half a scanline, but the way IBM CGA/5153 implements it, both 200 lines of information display in the same place.

To me, that says "broken implementation". The 30Hz flicker is tolerable, but mashing the visual information into the same space is not.

Still, I guess I can't completely call it "complete" until I support it, so I'll add something in there for interlaced testing, even if it is useless.

Speaking of which, I've completed the memory benchmarks, color select register tests, textmode manipulation tests, and am halfway through the monitor calibration tests. I think I'm ready for people to start testing it; please grab it at http://www.oldskool.org/pc/cgacomp and let me know any feedback, if any.

Fallo
January 25th, 2009, 11:16 PM
Thanks for the listing. This confirms what I saw in my own tests -- the card is interlacing memory/output, but the 5153 monitor displays the even and odd scanlines in the same 200 lines. A traditional interlaced mode would display the odd scanlines offset by half a scanline, but the way IBM CGA/5153 implements it, both 200 lines of information display in the same place.

The book has a screenshot of the program running, but it looks like they were using a green-screen composite monitor. Probably the 5153's fixed frequency is the reason it doesn't work.

QuantumII
January 25th, 2009, 11:24 PM
Thanks for the listing. This confirms what I saw in my own tests -- the card is interlacing memory/output, but the 5153 monitor displays the even and odd scanlines in the same 200 lines. A traditional interlaced mode would display the odd scanlines offset by half a scanline, but the way IBM CGA/5153 implements it, both 200 lines of information display in the same place.

To me, that says "broken implementation". The 30Hz flicker is tolerable, but mashing the visual information into the same space is not.

Still, I guess I can't completely call it "complete" until I support it, so I'll add something in there for interlaced testing, even if it is useless.

Speaking of which, I've completed the memory benchmarks, color select register tests, textmode manipulation tests, and am halfway through the monitor calibration tests. I think I'm ready for people to start testing it; please grab it at http://www.oldskool.org/pc/cgacomp and let me know any feedback, if any.


I've downloaded it now and started it in Dosbox at work just to look at the UI etc etc. It looks very nice, and when I get home today I'll try it on the XT with the VGA card and post the results

Trixter
January 26th, 2009, 11:18 AM
"Graphics Primer for the IBM PC".


I've ordered a copy of this, thanks :-)

QuantumII
January 26th, 2009, 12:10 PM
Here's my results from the XT with the VGA adapter (Sorry for the mess, I made it on the 200LX when running the tests on the XT)

Block memory read speed:
378kb/s

Write:
457kb/s

Interleaved Opcode/Memory read:
214 kb/s
Write:
234 kb/s

Color select register:
Medium-res: cyan, Does not cycle

High-res: white, Does not cycle

Medium-res palettes:
cyan,magenta,white , Does not cycle


Textmode manipulation:
40-column: OK
Textmode highcolor backgrounds: OK
Cursor: Regular OK, Upside-down OK, Full block OK, Top and bottom dual: NO
Striketrough: NO, Back to regular, OK

Trixter
January 26th, 2009, 12:22 PM
So your VGA has faster memory speeds than CGA. This means that any programs that run slower are doing so for a different reason. VGA has a vertical refresh rate of 70Hz for 200-line modes; real CGA is 60. That might be one cause. I didn't have a chance to add that test yet.

Many early VGA adapters have programs you can run to "force" the card into behaving like CGA. I remember having one of those for an early ATI card that came with it in the package. It switched into the 8x8 font and all the CGA tricks (third palette, 160x100, etc.) worked. You had to run the utility again to get full VGA functionality back. Do you have a similar utility for your card?

I will try to add the rest of the tests tonight and do another release. I will also add a check to see if you are deliberately running the program on a non-CGA card :-)

It's interesting to note that your VGA card RAM is faster than CGA, but it is not 4x as fast -- that means running MCGA/VGA 320x200@256 games will be significantly slower than CGA, despite the RAM speed difference (because 256-color mode is 4x the memory to sling around). Your "sweet spot" for running games on that system is probably EGA 320x200@16 mode.

QuantumII
January 26th, 2009, 12:26 PM
So your VGA has faster memory speeds than CGA. This means that any programs that run slower are doing so for a different reason. VGA has a vertical refresh rate of 70Hz for 200-line modes; real CGA is 60. That might be one cause. I didn't have a chance to add that test yet.

Many early VGA adapters have programs you can run to "force" the card into behaving like CGA. I remember having one of those for an early ATI card that came with it in the package. It switched into the 8x8 font and all the CGA tricks (third palette, 160x100, etc.) worked. You had to run the utility again to get full VGA functionality back. Do you have a similar utility for your card?

I will try to add the rest of the tests tonight and do another release. I will also add a check to see if you are deliberately running the program on a non-CGA card :-)

No, I have no utils for the card. I have an original IBM CGA adapter as well (Just got it) and I'll try your program again when I have a monitor to hook it up to.

How come the colors didn't cycle in the different tests ?

Trixter
January 26th, 2009, 12:48 PM
How come the colors didn't cycle in the different tests ?

Because the port used to do that on CGA does something different on VGA. And VGA handles border color with a different port, and both border color and background color are handled with palette entries instead of RGBI combinations.

Try to identify your card and find that utility! :-)

Fallo
January 26th, 2009, 12:48 PM
I've ordered a copy of this, thanks :-)

Have fun with that. Since it's from 1983, only CGA and monochrome are covered. The program listings are all BASIC, no assembly language. It's notable that they make absolutely no mention of the 5153. Judging from the screenshots in the book, they were using entirely composite monitors.

This was actually part of a series of "Primer" books (though all by different authors), covering BASIC, Pascal, and assembly language. My local library used to have the assembly one, which had this nifty little utility that would dump the entire first megabyte of memory and show you what locations had stuff in them and what was empty.

hargle
January 26th, 2009, 01:01 PM
Try to identify your card and find that utility! :-)

It might be a neat addition to your program to paw through the option rom @ c000 and see if there are any ASCII strings in there you could dump out to help with identification and BIOS revisions.

Disclaimer: I haven't tried it yet, you might already be doing that.

QuantumII
January 26th, 2009, 02:03 PM
Because the port used to do that on CGA does something different on VGA. And VGA handles border color with a different port, and both border color and background color are handled with palette entries instead of RGBI combinations.

Try to identify your card and find that utility! :-)

Yes,I will try that. I think it's this card (http://th99.dyndns.org/v/M-O/50115.htm)

Trixter
January 26th, 2009, 03:07 PM
It might be a neat addition to your program to paw through the option rom @ c000 and see if there are any ASCII strings in there you could dump out to help with identification and BIOS revisions.


I have a detection library I can employ to do this. This will increase the .exe to a whopping 140K though (I'm ashamed it's as big as it is, I'm using the Turbo Object Toolkit because I didn't want to spend weeks writing user interface code).

Oh well, might as well go for broke. I'll try to make sure it runs in 192KB so that it can run on 256KB machines and higher.

I'm very tired but I will try to work on it tonight. Because it's fun.

Trixter
January 28th, 2009, 06:53 AM
Yes,I will try that. I think it's this card (http://th99.dyndns.org/v/M-O/50115.htm)

Last night I added my detection libraries to the cga compatibility tester, and part of them is VGA card detection. Maybe that can help you determine the chipset used and might be able to find the "force cga" utility if it exists.

(Unfortunately, adding them added another 70K to the .exe -- the program is in danger of not running on a 256KB machine; if it bugs me, I'll try to alter the program to use an overlay system)

per
January 28th, 2009, 09:14 AM
As of drivers, I could only find drivers for Windows 3.1x. I don't know if they'll work, but if you plan to use the card in a computer running Windows 3.1, those drivers might come in handy. There is some new drivers and some older. The older ones requires manual windows installation, and the new ones comes with it's own installer.

However, I do only have the ability to upload the old one.

QuantumII
January 28th, 2009, 02:41 PM
Last night I added my detection libraries to the cga compatibility tester, and part of them is VGA card detection. Maybe that can help you determine the chipset used and might be able to find the "force cga" utility if it exists.

(Unfortunately, adding them added another 70K to the .exe -- the program is in danger of not running on a 256KB machine; if it bugs me, I'll try to alter the program to use an overlay system)

Nice! I'll try it tomorrow on my XT and see what it reports.

Per: Thanks for the drivers. I'll look at them tomorrow as well.

Fallo
January 28th, 2009, 10:05 PM
Alley Cat on true CGA: Everything works fine, no slow-downs.


The graphics look just fine, they are just choppy and slow.

One other thing I might add. When I run VGA games, the animation is perfectly smooth and glassy. You're saying that CGA games are supposed to be like that on the real thing, correct?

QuantumII
January 29th, 2009, 03:09 AM
One other thing I might add. When I run VGA games, the animation is perfectly smooth and glassy. You're saying that CGA games are supposed to be like that on the real thing, correct?

Yes, That's true.

Trixter
January 29th, 2009, 08:47 AM
One other thing I might add. When I run VGA games, the animation is perfectly smooth and glassy. You're saying that CGA games are supposed to be like that on the real thing, correct?

"Glassy"?

When I make a video of what the compatibility tester is supposed to look like, I'll make a video of Alley Cat as well for comparison.

QuantumII
January 29th, 2009, 08:52 AM
"Glassy"?

When I make a video of what the compatibility tester is supposed to look like, I'll make a video of Alley Cat as well for comparison.

Very nice :-)

Fallo
January 29th, 2009, 03:06 PM
"Glassy"?

Well, maybe not the best choice of words, but you know what I mean.

I once read a review of the PC version of Archon which said (among other things) that it had jerky animation compared to the C64 and Amiga versions. The guy that wrote the review in all probability never played it on a real CGA card.

Trixter
January 29th, 2009, 07:14 PM
Well, maybe not the best choice of words, but you know what I mean.

Actually, I don't know what you mean, which is why I asked :) What do you mean by "glassy"? Do you mean that the motion is very smooth without any jerky movement or jumps?



I once read a review of the PC version of Archon which said (among other things) that it had jerky animation compared to the C64 and Amiga versions. The guy that wrote the review in all probability never played it on a real CGA card.

No, he's right, it is jerky.

The smoothness of any game has to do with how well it is programmed. I've seen smooth 60Hz animation on a CGA card (ie. great) and I've seen juddery animation on EGA (ie. terrible) so it all depends on how good the programmer was.

Working on the hardest part tonight of the CGA tester -- M6845 register tests. I will include an interlaced test :-) Hopefully I will have it ready tonight or tomorrow night.

Fallo
January 29th, 2009, 09:15 PM
Actually, I don't know what you mean, which is why I asked :) What do you mean by "glassy"? Do you mean that the motion is very smooth without any jerky movement or jumps?

Yes, that's it.


No, he's right, it is jerky.

The smoothness of any game has to do with how well it is programmed. I've seen smooth 60Hz animation on a CGA card (ie. great) and I've seen juddery animation on EGA (ie. terrible) so it all depends on how good the programmer was.

If you ask me, the reviewer was exaggerating. Archon is one of the better games I've seen for smoothness of animation, if not as good as the C64 and Amiga versions (keeping in mind that those both had hardware sprites).

per
January 29th, 2009, 10:27 PM
(sorry if I get a little off-topic here)
While we're on the topic of jerky animations, I would like to make a comment about Microsoft Flight-Simulator 4.

It seems like it runs jerked on very slow systems.
at higher processor speeds, the animations smooths out (almost compleetely at about 25-50MHz).
However, if the processor speed is too high (say somewhere above 500MHz), the game slows awfully down.

I guess this has something to do with how the timing routines in the simulator are programmed.

Fallo
January 29th, 2009, 11:38 PM
(sorry if I get a little off-topic here)
While we're on the topic of jerky animations, I would like to make a comment about Microsoft Flight-Simulator 4.

It seems like it runs jerked on very slow systems.

at higher processor speeds, the animations smooths out (almost compleetely at about 25-50MHz).
However, if the processor speed is too high (say somewhere above 500MHz), the game slows awfully down.

I guess this has something to do with how the timing routines in the simulator are programmed.

How about California Raisins? The PC version of this game displays a startup message saying "Adjusting for CPU speed...". What's cute is that if the system is faster than about 16 Mhz, it then displays a message saying "Wow, that's some computer you have there!". I guess in 1987, the fastest PC available was a 16 Mhz 386. Because of the timing routine CR uses, it actually runs slower at speeds above 16 Mhz than it does at 4.77 Mhz.

Trixter
January 30th, 2009, 05:55 PM
New version ready for testing:

http://www.oldskool.org/pc/cgacomp/

I would appreciate some test/bug reports :-) especially for the video card detection since I put a lot of time into it (I grabbed VGA stuff from a library, but the cga/mda/hercules/+/incolor/ega code is mind).

If I get a few favorable test reports, I will make a final version and more importantly a reference video so that people can see what a 100% IBM CGA does in response to the tester.

vwestlife
January 30th, 2009, 08:42 PM
New version ready for testing:
Drat! It says "Numeric co-processor required." :( Neither of my two Tandys (original 1000 and 1000RL), which are really my ideal CGA machines, even have an 8087 socket at all, while my CompuAdd 810 and Zenith SupersPORT both have the socket but no chip. I think my IBM PC has an 8087 installed, but it's currently awaiting blown capacitor replacements on both the motherboard and the original IBM CGA board. :eek: Oh well...

I tried it on my Compaq PIII with modern-era onboard Super VGA video, and it failed most of the tests miserably. Even things that I know VGA is capable of doing, such as border colors and high-intensity background colors, didn't work. I guess the registers just don't match up with CGA.

QuantumII
January 31st, 2009, 11:10 AM
Drat! It says "Numeric co-processor required." :(

If this is true, then I cannot use the tool either. My XT has no co-processor..

per
January 31st, 2009, 01:02 PM
Here is the test results from my XT using an ATI "Small Wonder" Graphics Solution Version 2 hooked up to an IBM 5151 monitor emulating CGA:


Video RAM Read: 303 Kb/s
Video RAM Write: 304 Kb/s
Video RAM Interl. OpCode Read: 179 Kb/s
Video RAM Interl. OpCode Write: 184 Kb/s
----------

Overscan: Failed, no overscan
Med.Res. Background: Ok
Hi.Res. Foreground: Ok
Med.Res. Graphics Palettes: Ok*


*(not really easy to spot any differences due to output converted to shades of green)
----------

40 Columns textmode: Ok
Textmode Hi-Color Backgrounds: Ok
Textmode Cursors: Failed, no change at all
CGA Snow: Failed, nice and clear black area
Textmode 8*8 font: Not 100% similar, but difficult to spot any differences

----------
Calibration works just fine
----------

Vertical retrace: 49,19 Hz (due outputing to an IBM 5151)
Horizontal retrace: Ok
Textmode Row reprogramming: Ok
Textmode Row/Column reprogramming: First screen Ok, but failed on second screen, some of the picture appear ghostish and inverted behind the main picture (I guess I should not try that test again)
Interlached text: Unsure, the text appear as BIG letters filling the screen below normal letters.
Dipslay positioning: Didn't see that one :crazy: , and therefore not tested

----------
Hardware detection [actual facts]:

Machine type: Unknown [IBM PC/XT]
CPU: Intel 80C88 [8088]
CPU Speed: 5 MHz [~4.77 MHz]
Video Adapter: CGA [MGA/CGA Clone]
BIOS: 1501512 Corp. IBM 1981 (11/08/82, Rev. 244) [First rev. IBM 5160 PC/XT BIOS]

Trixter
January 31st, 2009, 03:48 PM
Drat! It says "Numeric co-processor required."


Dammit! I knew I forgot something! I'll try to get a new version uploaded that doesn't require one.



I tried it on my Compaq PIII with modern-era onboard Super VGA video, and it failed most of the tests miserably. Even things that I know VGA is capable of doing, such as border colors and high-intensity background colors, didn't work. I guess the registers just don't match up with CGA.

They don't match up at all (the same regs are used for completely different functions). So the moniker "CGA compatibility tool" is accurate :)

Trixter
January 31st, 2009, 04:01 PM
Here is the test results from my XT using an ATI "Small Wonder" Graphics Solution Version 2 hooked up to an IBM 5151 monitor emulating CGA:


This is fascinating, especially since it detected as CGA. Some things are clearly wrong (50Hz output, because of the monitor), some things are better than real CGA (memory speeds), and others are enhanced/fixed (no snow).

The fact that it detects as CGA but has a 50Hz refresh rate might cause a handful of games (California Games, Super Zaxxon, others) that used tricks to not work.



Textmode Row/Column reprogramming: First screen Ok, but failed on second screen, some of the picture appear ghostish and inverted behind the main picture (I guess I should not try that test again)


Correct, do NOT do that test again. That's the most "dangerous" test in the suite, although it doesn't hurt my 5153. That test was designed for RGB monitors, not monochrome -- I might put an additional warning in there.

Working on a version that doesn't use a mathco, should be uploaded in less than an hour.

Trixter
January 31st, 2009, 05:09 PM
If this is true, then I cannot use the tool either. My XT has no co-processor..

Okay, I've fixed this. It should work on systems without a mathco now. You can get version 0.3 from http://www.oldskool.org/pc/cgacomp/ . Test away! :-)

I just realized I forgot to implement one of the tests: The start address register. I will add that to version 0.4 in a few days as I'm currently sick with a bronchial infection. Once that's done, and I'm not coughing up a lung, I'll make a video of it in action and then post the final version along with the source code.

vwestlife
January 31st, 2009, 09:32 PM
Okay, I've fixed this. It should work on systems without a mathco now. You can get version 0.3 from http://www.oldskool.org/pc/cgacomp/ . Test away! :-)
I tried, but it still complains about needing a co-processor, at least on my Tandy 1000RL. :(

Trixter
February 1st, 2009, 10:50 AM
Okay, I'll have to rip out my coprocessor to duplicate the bug and find it. Sorry about this.

per
February 1st, 2009, 11:05 AM
This is fascinating, especially since it detected as CGA. Some things are clearly wrong (50Hz output, because of the monitor), some things are better than real CGA (memory speeds), and others are enhanced/fixed (no snow).

The fact that it detects as CGA but has a 50Hz refresh rate might cause a handful of games (California Games, Super Zaxxon, others) that used tricks to not work.

I think that the stuff that's incompatible is because of it's set to emulate CGA for a 5151, and because of that, using the MDA font and the fixed MDA refresh-rates.

It might be more CGA compatible (like supporting stuff like overscan and reprogrammable Row/Column stuff) if it is set to emulate CGA for a 5153.


Correct, do NOT do that test again. That's the most "dangerous" test in the suite, although it doesn't hurt my 5153. That test was designed for RGB monitors, not monochrome -- I might put an additional warning in there.

Working on a version that doesn't use a mathco, should be uploaded in less than an hour.
The monitor still works ;) , but I know that it takes about nothing to fry a monitor.

However, the card actually does support reprogrammable Row/Column stuff in text-mode, but they are activated another way than the CGA ones are activated.



Anyways, my 8087 does at least work, but why does it report my 8088 as an 80C88?

Trixter
February 1st, 2009, 01:42 PM
Okay, NOW I've fixed this. I use some mathco tricks in the detection code, so for systems without an 8087 I linked in an 8087 emulator. It should work on systems without a mathco now. Version 0.4 is at http://www.oldskool.org/pc/cgacomp/ . *Now* test away :-)

Trixter
February 1st, 2009, 01:54 PM
It might be more CGA compatible (like supporting stuff like overscan and reprogrammable Row/Column stuff) if it is set to emulate CGA for a 5153.


Indeed, it should be perfect.



The monitor still works ;) , but I know that it takes about nothing to fry a monitor.


What usually fries a monochrome monitor is trying to drive it faster than it is meant to be driven. I don't drive it faster, I just try to display more in the visible area. So although the test gives you a scare, it is still somewhat safe.


Anyways, my 8087 does at least work, but why does it report my 8088 as an 80C88?

Because it is an 80C88, the later 8088 with the CMOS static design. More info here: http://en.wikipedia.org/wiki/Intel_8088

The code in particular checks for a true 8088 by seeing if it suffers from the rep es: lodsb bug. If it doesn't have the bug, then it is either an NEC V20 or an 80c88 where they fixed it. I then differentiate between the NEC and the 80c88 by trying to do an undocumented instruction (AAD with an operand of 16 instead of 10) and if it fails, it's an nec; if succeeds, it's an 80c88. I then further check to see if it's an 80x88 vs. 80x86 by measuring the size of the prefetch queue via self-modifying code.

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.

vwestlife
February 1st, 2009, 02:34 PM
Okay, NOW I've fixed this. I use some mathco tricks in the detection code, so for systems without an 8087 I linked in an 8087 emulator. It should work on systems without a mathco now. Version 0.4 is at http://www.oldskool.org/pc/cgacomp/ . *Now* test away :-)
Now it works! :) My Tandy 1000RL passed all the tests with flying colors, except for interlaced mode, which it seems to ignore entirely. With some adjustment of my CM-11's controls, I was even able to get the full 90x30 text mode visible on the screen.

One peculiarity is that Tandy modified the text mode font on quite a few characters, versus IBM's CGA font. For example, Tandy displays the capital letter O as more squared-off and the number 0 as more rounded with a dot in the middle, while IBM's font displays capital O as more rounded and number 0 as more blocky with a slash through it. Nonetheless, this doesn't seem to cause any problems with any programs I've ever used, and even the fact that Tandy extends the CGA text mode to 225 lines of resolution -- adding an extra blank line between each row of text for better readability, so the bottom of a "g" won't touch the top of a "T" in the row below it, for example -- doesn't seem to cause any problems, either.

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. ;)

JohnElliott
February 1st, 2009, 02:56 PM
I tried it on the two XTs I happen to have set up at the moment: an IBM 3270 PC and a Compaq Deskpro. On the Compaq I did the tests twice, once with the monitor set for hi-res text mode and once with it set for standard CGA-resolution text mode.

3270 PC:

Read: 341 Kb/s
Write: 403 Kb/s
Interleaved read: 206 Kb/s
Interleaved write: 214 Kb/s

Numerous weirdnesses in the other tests, of course, since it has no 40-column mode, only 8 colours, selecting the red/cyan/white palette clears video RAM, and so on. And one test (I think it was the snow test) appeared to lock up completely.

Compaq (hi-res mode):

Read: 394 Kb/s
Write: 443 Kb/s
Interleaved read: 248 Kb/s
Interleaved write: 278 Kb/s

Nearly all tests in this mode passed, though the cursor shapes were a bit odd because characters are 14 lines high not 8. Interlacing, overscan, 90x30 and so on were fine, though of course the refresh rate was ~50Hz not ~60Hz. Colours were, of course, all green.

Compaq (lo-res mode):

Read: 379 Kb/s
Write: 417 Kb/s
Interleaved read: 242 Kb/s
Interleaved write: 280 Kb/s

Colours, again, were all green.

vwestlife
February 1st, 2009, 03:24 PM
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

Trixter
February 1st, 2009, 06:12 PM
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!

Trixter
February 1st, 2009, 06:18 PM
Compaq (lo-res mode):

Read: 379 Kb/s
Write: 417 Kb/s
Interleaved read: 242 Kb/s
Interleaved write: 280 Kb/s

Colours, again, were all green.

Were the cursor shapes okay in "low-res" mode? Just curious.

Trixter
February 1st, 2009, 06:20 PM
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.

vwestlife
February 1st, 2009, 08:55 PM
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:

per
February 1st, 2009, 10:27 PM
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:
http://www.cpu-world.com/CPUs/8088/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.

JohnElliott
February 1st, 2009, 11:35 PM
Were the cursor shapes okay in "low-res" mode? Just curious.

They were.

vwestlife
February 2nd, 2009, 04:52 AM
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."

Trixter
February 2nd, 2009, 08:03 AM
* 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.

Trixter
February 2nd, 2009, 08:41 AM
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...

vwestlife
February 2nd, 2009, 11:57 AM
I would expect that with an LCD, actually.
But it doesn't support those things even on the external RGB/composite output, not just on the internal LCD.

JohnElliott
February 2nd, 2009, 12:18 PM
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 (http://www.seasip.info/AmstradXT/Images/pc1512us.xbm) 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.

Trixter
February 2nd, 2009, 01:07 PM
But it doesn't support those things even on the external RGB/composite output, not just on the internal LCD.

Well then that's quite UNexpected :-)

vwestlife
February 2nd, 2009, 01:34 PM
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.

http://www.micro-examples.com/pics/955AUTHOR-pcxt.jpg

Trixter
February 2nd, 2009, 01:59 PM
Amstrad PC1512 (8MHz 80c86)

[quote]
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):




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_enab le+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.

Trixter
February 2nd, 2009, 02:01 PM
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.

Great Hierophant
February 2nd, 2009, 09:24 PM
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.

Trixter
February 2nd, 2009, 10:29 PM
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.

JohnElliott
February 3rd, 2009, 01:42 AM
But the second-to-last palette test does clear bit five.

Looks like it's setting it to me:


m6845_SetColor(c_paletteCMW);
m6845_Setmode(c_graphics_enable+c_videosignal_enab le+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;

Great Hierophant
February 3rd, 2009, 06:59 AM
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.

Trixter
February 3rd, 2009, 08:44 AM
Looks like it's setting it to me:


m6845_SetColor(c_paletteCMW);
m6845_Setmode(c_graphics_enable+c_videosignal_enab le+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;

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.

Trixter
February 3rd, 2009, 08:50 AM
My 8088 is an NEC model, but is clearly not marked as an 80C88, assuming that one could be installed in the slot.

It is my understanding that all NEC 8088s use the later CMOS design.

Trixter
February 3rd, 2009, 09:18 AM
Okay, the final version 0.4 of the CGA compatibility tester is here:

http://www.oldskool.org/pc/cgacomp

I updated the webpage to include a link to the reference video (http://www.archive.org/details/CGACompatibilityReferenceVideo), as well as a streaming version. The video doesn't go over every single test, only the most demanding/incompatible ones, but it should be sufficient for those wondering what the "strikethrough" cursor, CGA snow, the horizontal retrace tests, etc. should look like.

I patched it to work on any speed machine, so you can run it on Pentiums if you so desire :) And it no longer requires a mathcoprocessor.

The buggy mouse support will be removed in a future version if I get around to it (it's not my GUI library and I don't want to troubleshoot mouse support if I don't have a mouse on the dev machine).

Great Hierophant
February 3rd, 2009, 10:48 AM
It is my understanding that all NEC 8088s use the later CMOS design.

Interesting, I never knew that. I have an Intel 8088 which I will test tonight. Lets see whether it is CMOS or not.

JohnElliott
February 3rd, 2009, 12:09 PM
Found a couple more CGA-esque machines:

Amstrad PPC640 (8MHz V30):
This can display on its internal LCD or on a CGA monitor, so I tested on both. It also has a mechanism whereby attempts to reprogram the CRTC cause a non-maskable interrupt and the BIOS gets to tinker with the values written, so it's possible that some tests failed not because of hardware issues but because the BIOS is getting in on the act.

Read: 349 KB/s
Write: 355 Kb/s
Interleaved read: 303 Kb/s
Interleaved write: 305 Kb/s
Colour tests, obviously, only work on the colour monitor.
Different font. (http://www.seasip.info/AmstradXT/Images/cga3.xbm)
Retrace is 44.72Hz for LCD, 60.41Hz for CRT.
The 90x30 mode does not work. LCD goes blank, CRT has scrambled display.
No interlaced mode
The positioning test does nothing.

HP 200LX (6MHz 80186):
(This has an LCD and no apparent provision for an external monitor).

Read: 957 KB/s
Write: 1168 KB/s
Interleaved read: 329 KB/s
Interleaved write: 376 KB/s
No colour, so couldn't do the colour tests.
The dual-line and strikethrough cursors do not appear.
Different font. (http://www.seasip.info/VintagePC/hp200lx.xbm)
Contrast: Some colour combinations not readable on the LCD, but there's no provision to adjust it.
Retrace is 91.09Hz
No 90x30 mode, interlace or positioning.

Trixter
February 3rd, 2009, 02:37 PM
That is really fascinating stuff (the clones triggering an NMI for writing to the m6845, and the LCD having a 45Hz refresh)! I'm also surprised the hp palmtop had video memory nearly three times faster than CGA -- yet interleaving memory reads with CPU instructions is almost totally crippling... and a 90Hz (!!) refresh rate? That's insane. Really amazing what you can learn 25+ years after the fact.

Now I'm thinking it's time for me to pull out my GRiD 1520 (internal LCD) and my AT&T PC 6300 (used 25KHz horiz. 400-line mode) to see what they do...

vwestlife
February 3rd, 2009, 04:21 PM
That is really fascinating stuff (the clones triggering an NMI for writing to the m6845, and the LCD having a 45Hz refresh)! I'm also surprised the hp palmtop had video memory nearly three times faster than CGA -- yet interleaving memory reads with CPU instructions is almost totally crippling... and a 90Hz (!!) refresh rate? That's insane. Really amazing what you can learn 25+ years after the fact.
With its 8086 running at 9.54 MHz, my Tandy 1000RL scored block read 761 kb/s, block write 1006 kb/s, interleaved read 360 kb/s, and block write 362 kb/s. Setting the onboard 16-bit video to either 0 or 1 wait state(s) did not change these scores. As you'd expect from a member of the Tandy 1000 family, it system RAM for the video (it has 768K RAM installed: 640K for DOS and 128K for video).

Even at the same clock speed (NEC V20 @ 9.54 MHz), my CompuAdd 810's 8-bit onboard CGA video didn't do nearly as well: block read 512 kb/s, block write 714 kb/s, interleaved read 338 kb/s, and interleaved write 341 kb/s. I guess the 8086's 16-bit external data path really makes the improvement on the Tandy. The HP 200LX uses an 80186, so it probably has 16-bit video, as well.

per
February 3rd, 2009, 11:02 PM
Okay, the final version 0.4 of the CGA compatibility tester is here:

http://www.oldskool.org/pc/cgacomp

I updated the webpage to include a link to the reference video (http://www.archive.org/details/CGACompatibilityReferenceVideo), as well as a streaming version. The video doesn't go over every single test, only the most demanding/incompatible ones, but it should be sufficient for those wondering what the "strikethrough" cursor, CGA snow, the horizontal retrace tests, etc. should look like.

I patched it to work on any speed machine, so you can run it on Pentiums if you so desire :) And it no longer requires a mathcoprocessor.

The buggy mouse support will be removed in a future version if I get around to it (it's not my GUI library and I don't want to troubleshoot mouse support if I don't have a mouse on the dev machine).

Ok. Interlached text mode works for me then.

JohnElliott
February 4th, 2009, 04:47 AM
That is really fascinating stuff (the clones triggering an NMI for writing to the m6845, and the LCD having a 45Hz refresh)!

If you want more detail about the NMI thing, it's in the PPC technical manual (http://www.seasip.info/AmstradXT/ppctech/section1.html#1.11.5.4).

per
February 10th, 2009, 12:20 PM
Ok. Interlached text mode works for me then.

No, that's worng.
A detail I didn't see was that the original text before Interlached mode turned on got compressed and only the upper parts are visible. This doesn't happen with my card, however, big letters does appear, but only the upper left part is vissible because of the size of the letters.

Another funny thing is the Horizontal retrace bit test. The bars does appear, but they goes up and down on only the upper half of the display (only behind the texted area to be spesiffic), not the whole display pattern as in the video!

---

Talking of IBM character sets, the CGA/MDA got "", "", "" and "", however, "" and "" is missing! How the @ did my IBM MDA card manage to produce that letter??? (Not that the letter is almost never used since I operate the computer in english, but it's kind of weird when I'm thinking of it. It got an IBM Character ROM, so it isn't re-fonted.)

It is also funny that the keyboard got the modern Norwegian layout, but the english (Shift-)layout avalible by pressing 'AltGr+(Shift+)key'. The english layout is also printed to the right of the keys where it differ from the norwegian. I have honnestly never seen that on Norwegian post-AT keyboards, and that's a shame since it is 10 times easier to use if you don't got the ability to force the PC to the Norwegian keyboard layout (example: clean-boot).

Chuck(G)
February 10th, 2009, 02:12 PM
NTalking of IBM character sets, the CGA/MDA got "", "", "" and "", however, "" and "" is missing! How the @ did my IBM MDA card manage to produce that letter??? (Not that the letter is almost never used since I operate the computer in english, but it's kind of weird when I'm thinking of it. It got an IBM Character ROM, so it isn't re-fonted.)

I don't know what's done for lower-case "", but the uppercase variety is probably the code for the number 0 (zero). Now, if the ROM had a code for "Щ", I'd be surprised...

vwestlife
February 10th, 2009, 02:24 PM
Talking of IBM character sets, the CGA/MDA got "", "", "" and "", however, "" and "" is missing! How the @ did my IBM MDA card manage to produce that letter??? (Not that the letter is almost never used since I operate the computer in english, but it's kind of weird when I'm thinking of it. It got an IBM Character ROM, so it isn't re-fonted.)
Different countries got different character sets in ROM depending on their local language. When in doubt of what character set you're using, consult a standard U.S. character set table and see if it matches up.

vwestlife
February 10th, 2009, 05:57 PM
Here are some of my snapshots of running CGA_Comp on a true-blue original IBM 5150 PC with the IBM CGA board, hooked up to a Tandy CM-11 RGB monitor and a trusty old Amdek Color-I composite monitor.

The PC's Intel 8088 chip (1983 revision date) is incorrectly shown as an "80C88".
http://i44.tinypic.com/9jekqa.jpg

Maximum snow.
http://i43.tinypic.com/11ah2xt.jpg

Bouncing color bars on the RGB monitor.
http://i41.tinypic.com/2s1w58h.jpg

Bouncing color bars on the composite monitor (too bright for the camera; the colors in real life are fine, not washed-out).
http://i41.tinypic.com/8x8lti.jpg

Interlaced mode on the composite monitor is not any more readable than on the RGB monitor. Still, I'm amazed that pseudo-80x50 text is intelligible at all on a color composite monitor (glorified tunerless TV set) with 240 lines of resolution (manufacturer's spec).
http://i40.tinypic.com/205ylh.jpg

Trixter
February 10th, 2009, 07:23 PM
The PC's Intel 8088 chip (1983 revision date) is incorrectly shown as an "80C88".


If it's made after 1981, it actually is an 80c88, marked or not. They fixed the bug I test for when they went to the new manufacturing process. I believe the bug I test for is on all CPUs marked 1978 to 1981. Here's the code:



mov cx,2 ; test if following instruction will be
; repeated twice.
db 0F3h,26h,0ACh ; rep es: lodsb
jcxz Yes ; intel non-CMOS chips do not care of rep
jmp Nope ; before segment prefix override, NEC and
; CMOS-tech ones does.


I have a couple of friends I can ask from that time period; I'll ask and see if I can lock down specific dates and manufacturing processes.



Interlaced mode on the composite monitor is not any more readable than on the RGB monitor. Still, I'm amazed that pseudo-80x50 text is intelligible at all on a color composite monitor (glorified tunerless TV set) with 240 lines of resolution (manufacturer's spec).


Warms my heart that you tested this and provided a screenshot :-) Thanks!

I did eventually find the code that used an 8087 and removed it; doing so removed the 8087 emulator I needed to use and reduces memory requirements by 10K. Which means it should run on a 128K machine a little more comfortably. When I release the source, I'll update the binary as well.

vwestlife
February 10th, 2009, 10:11 PM
If it's made after 1981, it actually is an 80c88, marked or not. They fixed the bug I test for when they went to the new manufacturing process.
As far as I can tell from some quick research, the 8088 did not switch to the fully static CMOS design except in the specifically designated 80C88 version, which also featured reduced power consumption and the ability to clock down to zero MHz for sleep mode. The standard 8088 used NMOS, while the faster 8088-2 and 8088-1 used HMOS and later HMOS-II ("N-channel depletion load silicon gate technology," as they explained it). HMOS-III was used for the 8086 series.

Terry Yager
February 10th, 2009, 10:33 PM
OK, at the risk of sounding extremely st00pit...what's HMOS (& HMOS-II)? I know, google's s'pozed to be my friend, but it's been quite uncooperative for me lately...

--T

Trixter
February 11th, 2009, 12:28 AM
As far as I can tell from some quick research, the 8088 did not switch to the fully static CMOS design except in the specifically designated 80C88 version, which also featured reduced power consumption and the ability to clock down to zero MHz for sleep mode. The standard 8088 used NMOS, while the faster 8088-2 and 8088-1 used HMOS and later HMOS-II ("N-channel depletion load silicon gate technology," as they explained it). HMOS-III was used for the 8086 series.

Were you able to find out what year they switched to the CMOS static design?

I've also got some feelers out for more info; if I find something definitive, I'll post here and/or change my detection routines :)

per
February 11th, 2009, 02:07 AM
Were you able to find out what year they switched to the CMOS static design?

I've also got some feelers out for more info; if I find something definitive, I'll post here and/or change my detection routines :)

Maybe we could manually toggle the 8284A clock generator to see if it single-steps! The non-static version doesn't work quite well below 2 MHz.

Trixter
February 11th, 2009, 07:18 AM
Maybe we could manually toggle the 8284A clock generator to see if it single-steps! The non-static version doesn't work quite well below 2 MHz.

I think that would be a tad difficult to do in software :-)

per
February 11th, 2009, 07:34 AM
I think that would be a tad difficult to do in software :-)
yeah, unless your CPU got superpowers, but the problability for that is one to infinity (or zero) :D .


I was thinking of more to confirm if '83 dated 8088's does or does not use the all static design or not...

Trixter
February 12th, 2009, 10:30 AM
Were you able to find out what year they switched to the CMOS static design?

I've also got some feelers out for more info; if I find something definitive, I'll post here and/or change my detection routines :)

It's me, I screwed up! But in my defense, my information was wrong. I have learned that the earlier 8088s only exhibit the REP bug if an interrupt fires off during the REP. The earlier CPUs don't resume; the later ones do. So I need to change this:



mov cx,2 ; test if following instruction will be
; repeated twice.
db 0F3h,26h,0ACh ; rep es: lodsb
jcxz Yes ; intel non-CMOS chips do not care of rep
jmp Nope ; before segment prefix override, NEC and
; CMOS-tech ones does.


...to this:



mov cx,f000 ; need a longer count to
; guarantee it will be interrupted
db 0F3h,26h,0ACh ; rep es: lodsb
jcxz Yes
jmp Nope


I will make the change tonight, recompile (no more 8087 code, finally), and update the binary on the website and let you know. I would love for you to test to see if you get a different answer.

(BTW, here is a wealth of detection information, for anyone who hits this post in a google search looking for code to detect CPU type: http://groups.google.com/group/comp.lang.asm.x86/msg/f23bbe43c62df209?hl=en Those guys have really helped me out in the past, they're great.)

Chuck(G)
February 12th, 2009, 10:57 AM
I didn't understand what you were talking about; I knew about the interrupt business (it's been well-documented for quite some time) and was surprised when you mentioned the multiple prefix thing outside of the context of interrupts.

Also, didn't the very early 8088's have a bug where interrupts weren't masked for the next instruction after a MOV SS? I think Intel offered replacements for those.

per
February 12th, 2009, 11:42 AM
http://groups.google.com/group/comp.lang.asm.x86/msg/f23bbe43c62df209?hl=en
It's clear that Rod P. don't know me well, but that's off-topic and shouldn't be discussed here. (Please! Anybody! provide him Th (http://www.cpu-world.com/CPUs/8088/Intel-P8088.html)is (http://www.cpu-world.com/CPUs/8088/L_Intel-P8088.jpg) link. :onfire: )


I will be testing this weekend. Then I can try the repositioning and scrolling tests too.

I'm still curious why the bars on the Horizontal retrace bit will only move on the upper part of the screen im my cause.

A smal CGA-related question: Is the composite out connector on a CGA adapter compaitble with the yellow RCA-jack input on most modern TV's? If it is, then I'm thinking of putting back both my MDA and CGA card in my XT. Maybe, maybe not or maybe i'll put in a Hercules instead of the MDA, it would be really cool if I got a 5153 for my CGA adapter too, but I don't plan to pay mutch for shipping by the time right now...

Fallo
February 12th, 2009, 02:00 PM
A smal CGA-related question: Is the composite out connector on a CGA adapter compaitble with the yellow RCA-jack input on most modern TV's?

Of course. The RCA input on TVs is for all intents and purposes the same as using a color composite monitor.


If it is, then I'm thinking of putting back both my MDA and CGA card in my XT. Maybe, maybe not or maybe i'll put in a Hercules instead of the MDA.

Good idea, just keep in mind that some software uses B800 in Hercules mode, and as such doesn't cooperate with color cards.

patscc
February 12th, 2009, 02:08 PM
As long as the board delivers the proper standard, i.e. NTSC or PAL, depending on your location and TV. it should work.
patscc

per
February 12th, 2009, 02:16 PM
As long as the board delivers the proper standard, i.e. NTSC or PAL, depending on your location and TV. it should work.
patscc

We got a brand new 32" LCD TV (no scan lines? what's inbetween each row of pixels then?? And how is the filckering???), it does at least handle PAL, but I guess it'll handle NTSC too.

vwestlife
February 12th, 2009, 03:09 PM
(BTW, here is a wealth of detection information, for anyone who hits this post in a google search looking for code to detect CPU type: http://groups.google.com/group/comp.lang.asm.x86/msg/f23bbe43c62df209?hl=en Those guys have really helped me out in the past, they're great.)
Since Rod P. seems so insistent on proving that my 8088 doesn't exist, here's a photo of it in situ...

http://i41.tinypic.com/73kx6v.jpg

Here's the date tag on the back of the PC's case -- it is a very late model, from January 7th, 1986 (it looks like "83", but the presence of RAM chips soldered into the motherboard dated "8514" rules out it being 1/7/83 or even 1/7/85).

http://i43.tinypic.com/eskpx2.jpg

...and the serial number:

http://i42.tinypic.com/21lo4dz.jpg

Trixter
February 12th, 2009, 03:11 PM
We got a brand new 32" LCD TV (no scan lines? what's inbetween each row of pixels then?? And how is the filckering???), it does at least handle PAL, but I guess it'll handle NTSC too.

I wrote the CGA compatibility tester for RGB monitors -- I have no idea at all what some of the tests will do on a TV. The 90x30 textmode might cause rolling; the horizontal retrace bars will most likely cause a lot of flicker and shake.

I will put it on the todo list to hook up a composite monitor and add routines for that to the program. Maybe this weekend.

New version should be ready in about 4 hours to test...



Also, didn't the very early 8088's have a bug where interrupts weren't masked for the next instruction after a MOV SS? I think Intel offered replacements for those.


They do, and based on some of those aforementioned links, I think I can whip up some detection code for those too. Only problem is, I am pretty sure I don't have one of the buggy CPUs, so I have no way to test the code... maybe in my Rev b 5150. I'll have to check.

Trixter
February 12th, 2009, 03:12 PM
Since Rod P. seems so insistent on proving that my 8088 doesn't exist, here's a photo of it in situ...


Oh, I wouldn't worry about him, he was just trying to help me. When I get my new detection code in the program 4 hours from now, I'm sure all will be made clear :-)

vwestlife
February 12th, 2009, 03:27 PM
They do, and based on some of those aforementioned links, I think I can whip up some detection code for those too. Only problem is, I am pretty sure I don't have one of the buggy CPUs, so I have no way to test the code... maybe in my Rev b 5150. I'll have to check.
I have the original 1978 8088 chip in my older PC with only 64K on the motherboard... but I haven't turned it on in years and I fear blown capacitor(s) if I just plug it in and flip the switch, so I'll have to go through my restoration procedure to help avoid that if possible.

Plus it has the MDA board installed, too, which making running CGA_Comp on it rather pointless. :)

vwestlife
February 13th, 2009, 08:02 PM
Well, instead of messing around with the old PC, I dusted off my original Tandy 1000 -- with 4.77 MHz AMD 8088, ROM 01.00.00, 640K RAM with DMA on expansion card (no DMA on the motherboard, just like the PCjr), and onboard Tandy CGA video which steals video memory from main system RAM.

Results: Block memory read 398 kb/s, block write 454 kb/s, interleaved read 227 kb/s, interleaved write 214 kb/s. Everything works, including interlaced mode, although with interesting results:

http://i42.tinypic.com/2503xx4.jpg

The sticker on the bottom side of the keyboard says "Radio Shack TRS-80 Service Contract, Exp. Date 6-30-86". :)

Fallo
February 13th, 2009, 08:20 PM
Results: Block memory read 398 kb/s, block write 454 kb/s, interleaved read 227 kb/s, interleaved write 214 kb/s. Everything works, including interlaced mode, although with interesting results:

The doubled text you got in interlace mode may simply be the result of the Tandy 1000's 8x9 font. Assuming you're using the Tandy version of DOS, you can set it to 8x8 text by typing MODE 200 at the DOS prompt.

per
February 14th, 2009, 04:46 AM
I wrote the CGA compatibility tester for RGB monitors -- I have no idea at all what some of the tests will do on a TV. The 90x30 textmode might cause rolling; the horizontal retrace bars will most likely cause a lot of flicker and shake.

I will put it on the todo list to hook up a composite monitor and add routines for that to the program. Maybe this weekend.

New version should be ready in about 4 hours to test...

I can't see any differences from the version currently online and the eariler v0.4...

vwestlife
February 14th, 2009, 04:10 PM
The doubled text you got in interlace mode may simply be the result of the Tandy 1000's 8x9 font. Assuming you're using the Tandy version of DOS, you can set it to 8x8 text by typing MODE 200 at the DOS prompt.
OK, that did the trick! So, the original Tandy CGA is 100% compatible with IBM CGA, minus the snow and plus the extra graphics modes... now if only the Tandy keyboard was nearly that compatible as well! Games like "BRICKS" are completely unplayable due to the different scan codes and lack of a Scroll Lock key. There are various TSRs to remap the keys, but the only real solution is to get a later 1000-series model with the standard keyboard layout (but then you lose interlaced mode support and composite output, so you can't win them all!).

Fallo
February 14th, 2009, 06:19 PM
OK, that did the trick! So, the original Tandy CGA is 100% compatible with IBM CGA, minus the snow and plus the extra graphics modes... now if only the Tandy keyboard was nearly that compatible as well! Games like "BRICKS" are completely unplayable due to the different scan codes and lack of a Scroll Lock key.

On the Tandy keyboards, you use ALT+BREAK instead of Scroll Lock. Apparently you can't use the numeric keypad with games that read the keyboard directly (Dig Dug, Alley Cat, Jumpman etc.) because of the different scan codes. I would guess you use the normal arrow keys with those.


There are various TSRs to remap the keys

Such as KEYCNVRT.SYS, which was supplied with Tandy DOS. That still won't work with anything that reads the keyboard directly.

Anyone here want to try Alley Cat or something on a Tandy and see if it has keyboard problems?

Trixter
February 15th, 2009, 12:21 AM
I can't see any differences from the version currently online and the eariler v0.4...

Sorry, I ran into Real Life(tm) issues. The new version is up, it's version 0.5 and has fixed 8087 and 8088 detection code. It now reports 8088 properly, and 80c88 properly.

HOWEVER, I need someone to test on NEC V20/30, because all that code is related (I check for buggy cpu first, then if working, I check for nec). If anyone has an NEC chip and can give it a quick check, I'd appreciate it.

I also added Hercules detection code -- ie. if you have a Hercules, it should actually tell you that you have one and which model. If anyone has a Hercules (or better, an HGC+ or InColor), I'd love a test on that to see if it works.

I stumbled across a procedure to detect very early buggy 8088s that enable interrupts after SS is changed. I may try to implement that, but I'll save that work for the benchmarking program I keep threatening to write...

Trixter
February 15th, 2009, 12:23 AM
Results: Block memory read 398 kb/s, block write 454 kb/s, interleaved read 227 kb/s, interleaved write 214 kb/s.

That's interesting in that writing to video memory is faster than on real CGA. I would have expected it to be slower (the PCjr certainly was). That might explain why Tandy 16-color graphics wasn't terribly slower than CGA.

per
February 15th, 2009, 12:43 AM
I also added Hercules detection code -- ie. if you have a Hercules, it should actually tell you that you have one and which model. If anyone has a Hercules (or better, an HGC+ or InColor), I'd love a test on that to see if it works.
I own a HGC+ but it's in Stocholm :( , and we don't plan to go there for a while.

I'll test it right away with my card in both MGA and HGC mode.

per
February 15th, 2009, 05:14 AM
Sorry, I ran into Real Life(tm) issues. The new version is up, it's version 0.5 and has fixed 8087 and 8088 detection code. It now reports 8088 properly, and 80c88 properly.

HOWEVER, I need someone to test on NEC V20/30, because all that code is related (I check for buggy cpu first, then if working, I check for nec). If anyone has an NEC chip and can give it a quick check, I'd appreciate it.

I also added Hercules detection code -- ie. if you have a Hercules, it should actually tell you that you have one and which model. If anyone has a Hercules (or better, an HGC+ or InColor), I'd love a test on that to see if it works.

I stumbled across a procedure to detect very early buggy 8088s that enable interrupts after SS is changed. I may try to implement that, but I'll save that work for the benchmarking program I keep threatening to write...
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'.

vwestlife
February 15th, 2009, 09:32 AM
That's interesting in that writing to video memory is faster than on real CGA. I would have expected it to be slower (the PCjr certainly was). That might explain why Tandy 16-color graphics wasn't terribly slower than CGA.
This is on a 1000 with the Tandy memory expansion board, which adds DMA. On a base 1000 with only the 128K on the motherboard, there is no DMA, which slows things down a lot, just like on a PCjr.

I tried CGA_Comp 0.5 on my CompuAdd 810 set to Hercules mode. It reports a "PC/XT" with a NEC V20 (correct) at "9 MHz" (actually 9.54 MHz, to be exact) and with "MDA" video. The CGA snow, vertical retrace detect, horizontal retrace detect, and start address reprogramming tests all lock up the machine, but all the other tests at least go through and return you back to the menu, even if their results are not relevant or visible on MDA/Hercules.

per
February 15th, 2009, 10:12 AM
I did some testing of my real CGA card attached to our 32" TV. The computer was booted in 40*25 Textmode.

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.

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

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

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

----------

I also tried the ATI card with my TV:
Med-Res textmodes does work fine, however, some of the color combinations (also in grphics mode) gives washed-out picture (as with my real CGA). a few color combinations of Med-Res graphics gives also slightly zig-zag flickering.

Hi-Res appear without color.

This time, different cursors works, and overscan is present and working.

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?

Another note is that, somehow, text before each test appeard on half left of the screen as 40*25 textmode but displayed in 80*25 textmode.

Trixter
February 15th, 2009, 08:46 PM
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.

Trixter
February 15th, 2009, 09:13 PM
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:



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:



$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:



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.

per
February 15th, 2009, 10:24 PM
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:



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:



$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:



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.

per
February 15th, 2009, 11:56 PM
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?

vwestlife
February 16th, 2009, 08:32 AM
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.

per
February 16th, 2009, 11:18 AM
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.

Trixter
February 16th, 2009, 06:53 PM
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.

I'll check my code for errors then.

Trixter
February 16th, 2009, 08:11 PM
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.

Trixter
February 16th, 2009, 09:56 PM
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:



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:



-g 0104

AX=0000 BX=E73C CX=0000 DX=0000 SP=FFEE BP=0000 SI=0000 DI=0000
DS=0B3A ES=F000 SS=0B3A CS=0B3A IP=0104 NV UP EI PL NZ AC PE NC
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):



d F000:E73C,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.

per
February 16th, 2009, 10:22 PM
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:



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:



-g 0104

AX=0000 BX=E73C CX=0000 DX=0000 SP=FFEE BP=0000 SI=0000 DI=0000
DS=0B3A ES=F000 SS=0B3A CS=0B3A IP=0104 NV UP EI PL NZ AC PE NC
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):



d F000:E73C,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:


STC
MOV AH,86H
RET 2


According to the IBM TechRef.

Great Hierophant
February 17th, 2009, 05:54 PM
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.

Fallo
February 17th, 2009, 06:18 PM
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.

vwestlife
February 17th, 2009, 07:44 PM
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

Chuck(G)
February 17th, 2009, 08:35 PM
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.

frozenfire75i
February 17th, 2009, 08:40 PM
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.

Fallo
February 17th, 2009, 09:12 PM
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.

Trixter
February 17th, 2009, 09:56 PM
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:


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 (http://www.oldskool.org/pc/MONOTONE) to make the program more practical and support the Tandy/PCjr chip.

vwestlife
February 17th, 2009, 10:17 PM
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.

Fallo
February 17th, 2009, 10:40 PM
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.

Terry Yager
February 17th, 2009, 10:47 PM
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

per
February 17th, 2009, 11:15 PM
It's even more weird that the MDA's character ROM includes both CGA fonts.

Too bad I don't got a PC... If I did, I could have dumped my norwegian version of the character ROM (from my MDA card) and then made a copy for my CGA card...

Maybe I'll also solder a 2-pin header to P3, but first of all, I need a 5153.

per
February 17th, 2009, 11:16 PM
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 (http://www.oldskool.org/pc/MONOTONE) to make the program more practical and support the Tandy/PCjr chip.

I'll test it on saturday.

BTW, when running on new computers, the machine detection code gives a runtime error.

vwestlife
February 18th, 2009, 04:43 AM
Oh, I'm sure M$ would have sold licenses for a machine-specific cassette BASIC to other vendors...in fact, they did...to everybody!
And I believe the generic MS-DOS GWBASIC (not requiring the IBM BASIC ROM) includes cassette commands... I know at least MOTOR works, since some programs used it to create sounds via the cassette motor relay on the PC's motherboard, such as a ticking clock, percussion in time to music, or if you toggle it fast enough (abuse!), a buzzing sound.

frozenfire75i
February 18th, 2009, 06:55 AM
You are 100% right, the 5150 is more like half System 23 Datamaster

Taken from my histroy page:

A 2nd very common myth is the IBM 5150 PC was designed from entirely “off the shelf” parts. That is also true to some degree. About half of the system was from the IBM system 23 Data master, such as the expansion bus, display, monitor, BIOS, floppy interface, keyboard and the other half of the system from “off the shelf” parts such as the floppy drives, all the software, BASIC in ROM, and Intel CPU. And some parts of the system were designed from “scratch” such as the motherboard.

To back up the display copy of system 23 Check out this:
http://www.ibm5150pc.com/docs/lew_c.zip

Page 12 cover the Loma MDA Display. Loma is the codename for the System 23 data master. Pages 10 and 11 cover the color display in it's very early design stage! Those pages also cover all kinds of cool stuff!





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.

Trixter
February 18th, 2009, 07:10 AM
I'll test it on saturday.

BTW, when running on new computers, the machine detection code gives a runtime error.

Yeah, I don't plan on fixing that. I tested it successfully up to a 1.3GHz machine, I figure that's good enough.

Said benchmark, when I write it, has a very specific focus; for that focus, it doesn't make sense to support anything faster than a Pentium III.

Great Hierophant
February 18th, 2009, 08:41 AM
Good news, the updated program detected my IBM CGA card, IBM PC and my Intel 8088 accurately. All I need do now is to try it on a real 5153.

Although it is more of a speed test than an adapter test, I would love to see one test that changes the background in mid-frame and another test that changes the palette in mid-frame.

Also, and it is not a favored test, I would really appreciate a small composite color test. Just a simple pattern for each color palette will do, such as the ones on the wikipedia page. Of course, it would not be complete without the option to cycle the background or foreground color, depending on the mode.

Fallo
February 18th, 2009, 03:12 PM
It still puzzles me that the interlace mode doesn't work on fixed-frequency RGB monitors, but it works perfectly fine on the equally fixed-frequency monochrome monitors.

Trixter
February 18th, 2009, 10:37 PM
Good news, the updated program detected my IBM CGA card, IBM PC and my Intel 8088 accurately.


Hooray for bugfixes! :-)



Although it is more of a speed test than an adapter test, I would love to see one test that changes the background in mid-frame and another test that changes the palette in mid-frame.


Your wish is already granted: The horizontal retrace detect test (the one with the demoscene-ish transparent copper bar effect) changes the background color every single scanline. And yes, that took assembler :-)

As for changing the palette mid-frame, a good test for that (if you have a real 4.77MHZ 8088 IBM) is California Games. Choose "more-color mode" from the video configuration menu and several parts (most notably the footbag event) change the palette mid-frame to stick 6 or 7 colors on the screen simultaneously. I have thought about using that trick to try to get 320x200 16-color pictures displayed, like C64 "FLI" pix... and also hack multiple pages to get C64 "IFLI"-like pix... maybe next year.



Also, and it is not a favored test, I would really appreciate a small composite color test. Just a simple pattern for each color palette will do, such as the ones on the wikipedia page. Of course, it would not be complete without the option to cycle the background or foreground color, depending on the mode.

I'll look into it, but the real "problem" (not really) is that composite mode can generate -- I'm not making this up -- over 100 unique colors depending on what the background color, foreground palettes, and some other regs are set to. So there really isn't one standard set of 16 colors.

Trixter
February 18th, 2009, 10:40 PM
It still puzzles me that the interlace mode doesn't work on fixed-frequency RGB monitors, but it works perfectly fine on the equally fixed-frequency monochrome monitors.

The book you told me about (which I then purchased and was surprised at the high volume of m6845 programming info, given that is a BASIC book) has a theory, that the very long phosphor times completely mask the interlacing flicker. I can buy that.

The same book also notes, however, that it is STILL useless on MDA because there's not enough RAM to display 80x50. So the book, as an example, programs a 40x25 mode in a column down the screen and then goes interlaced. So you get either 80x25 or 40x50... So it is still useless unless you have Hercules.

QuantumII
February 18th, 2009, 11:21 PM
Now that I have my IBM 5153 and an original IBM CGA card, do you want me to run the tests and report them here or is it not necessary because we kind of already know the results ?

I can also tell you this:

CGA performance is much better with the original CGA card. Colors look perfect now.
(When I used the VGA card it was always cyan magenta white).

Performance speed-wise is better. Alley Cat is now fully playable, even in the fish-tank. (Don't get me wrong about this game, I's not my favorite game or anything, but I used it as an example because this is where the difference is really visible)

Leisure Suit Larry 1 shows up in B/W.

Fallo
February 19th, 2009, 12:04 AM
CGA performance is much better with the original CGA card. Colors look perfect now.
(When I used the VGA card it was always cyan magenta white).

A number of games (most of the Atarisoft ones for example) set the palettes by writing directly to 3D9h. Dig Dug actually looks better on VGA (color-wise) than CGA.

One other little thing is that I never cared for the way 40-column text looks on VGA (too horizontally-stretched). The CGA 40-column text is perfect.


Performance speed-wise is better. Alley Cat is now fully playable, even in the fish-tank. (Don't get me wrong about this game, I's not my favorite game or anything, but I used it as an example because this is where the difference is really visible)

Leisure Suit Larry 1 shows up in B/W.

All Sierra AGI games start up in composite mode, which of course appears as the normal 640x200 mode on a RGB monitor. You can switch to RGB mode in AGI games by pressing CTRL-R, but it's not pretty (red-green-brown on dark blue). Definitely use a composite monitor for Sierra games (anything pre-SCI, at least).

QuantumII
February 19th, 2009, 12:55 AM
You can switch to RGB mode in AGI games by pressing CTRL-R, but it's not pretty (red-green-brown on dark blue). Definitely use a composite monitor for Sierra games (anything pre-SCI, at least).

Yeah, that's the shortcut. I did not remember that last night when trying it. I'll test it when I get home today :-)

vwestlife
February 19th, 2009, 04:46 AM
The book you told me about (which I then purchased and was surprised at the high volume of m6845 programming info, given that is a BASIC book) has a theory, that the very long phosphor times completely mask the interlacing flicker. I can buy that.
It's not just a theory. The Amiga features properly implemented 320x400 and 640x400 interlaced modes, and Commodore made several monitors with long-persistence phosphor specifically to make these modes tolerable to view.

Also, the MDA's 50 Hz refresh rate is already flickery enough on a monitor with short-persistence phosphor. Interlaced MDA at 25 Hz (!) would be downright seizure-inducing to view if the 5151 didn't have radar-scope-style looooong persistence phosphor.

Fallo
February 19th, 2009, 04:12 PM
The same book also notes, however, that it is STILL useless on MDA because there's not enough RAM to display 80x50. So the book, as an example, programs a 40x25 mode in a column down the screen and then goes interlaced. So you get either 80x25 or 40x50... So it is still useless unless you have Hercules.

Wrong. I tried it on a Hercules card, and it still wouldn't display 80x50 text. I thought that the Hercules could use it's extra memory in text mode, but it apparently can't.

Great Hierophant
February 20th, 2009, 12:21 PM
As for changing the palette mid-frame, a good test for that (if you have a real 4.77MHZ 8088 IBM) is California Games. Choose "more-color mode" from the video configuration menu and several parts (most notably the footbag event) change the palette mid-frame to stick 6 or 7 colors on the screen simultaneously.

[snip]

I'll look into it, but the real "problem" (not really) is that composite mode can generate -- I'm not making this up -- over 100 unique colors depending on what the background color, foreground palettes, and some other regs are set to. So there really isn't one standard set of 16 colors.

California Games changes the palette more than once per scanline in some screens. On the skating screen, you can see every single intense foreground color (light cyan, light magenta, light red, high intensity white, light green, yellow) the CGA card could produce!

What I suggest regarding the color composite tests is to make the program draw the patterns that are shown in the wikipedia entry, then cycle them through each intensity and foreground/background color. Start with the black & white versions for greater effect.

vwestlife
February 20th, 2009, 02:31 PM
What I suggest regarding the color composite tests is to make the program draw the patterns that are shown in the wikipedia entry, then cycle them through each intensity and foreground/background color. Start with the black & white versions for greater effect.
For compsite color mode, the most useful tool would be a pattern with predictable results to help adjust the color trimmer on the motherboard and the tint control on the monitor. (Some computers, such as the Tandy 1000 series, lack the internal color trimmer, so you just have to make do with the monitor's tint control.)

Also, even the standard non-artifacted 16 CGA colors show up differently on a color composite monitor versus a color RGBI monitor. For example, color 6 (brown) shows up as dark yellow (just like on "non-CGA-modified" older RGB monitors), and "cyan" shows up with more of a greenish hue, like aquamarine.

per
February 21st, 2009, 09:17 AM
I'll test it on saturday.

BTW, when running on new computers, the machine detection code gives a runtime error.

I've now gotten to test it.

Here is what it's reporting:
Model: IBM XT
Processor: Intel 8088
Processor Speed: 4.77MHz
Display Adapter: CGA
BIOS: 1501512 Corp. IBM 1981 (11/08/82, Rev. 244)

Everyhting as expected (maybe except the Revision number). However, when run on my 486SX, it reports it as a 486DX or 487SX.

Trixter
February 21st, 2009, 01:05 PM
Now that I have my IBM 5153 and an original IBM CGA card, do you want me to run the tests and report them here or is it not necessary because we kind of already know the results ?


If the host computer is still the same, I am curious to see what the memory speed benchmarks show now, because IIRC your VGA card had substantially faster read and write times, which surprised me given that it was an 8088.



Leisure Suit Larry 1 shows up in B/W.

It's in composite color mode. Hit CTRL-R or equivalent to switch to CGA paletted rendering.

Trixter
February 21st, 2009, 01:09 PM
I've now gotten to test it.

Here is what it's reporting:
Model: IBM XT
Processor: Intel 8088
Processor Speed: 4.77MHz
Display Adapter: CGA
BIOS: 1501512 Corp. IBM 1981 (11/08/82, Rev. 244)

Everything as expected (maybe except the Revision number). However, when run on my 486SX, it reports it as a 486DX or 487SX.

The BIOS: string is just the ASCII string copied from your ROM, so if it says "Rev. 244" then it's rev 244 :-)

As for the 486SX, do you have the 487 installed?

per
February 21st, 2009, 01:27 PM
The BIOS: string is just the ASCII string copied from your ROM, so if it says "Rev. 244" then it's rev 244 :-)
Strange. I've examined the BIOS dump, and I can't seem to find anything like that. I found the date and copyright, but not any revision number. I guess IBM didn't include revision numbers properly in the earlier BIOS'es before 1985.

As for the 486SX, do you have the 487 installed?
No. The 487SX socet is empty. The first versions of CGA_COMP wouldn't even run on it because it lacks a math coprocessor.

Terry Yager
February 21st, 2009, 05:08 PM
The BIOS: string is just the ASCII string copied from your ROM, so if it says "Rev. 244" then it's rev 244 :-)

As for the 486SX, do you have the 487 installed?

A '487? Are you kidding? Has anybody ever actually ever seen one of these in the wild?

--T

Trixter
February 21st, 2009, 06:12 PM
Strange. I've examined the BIOS dump, and I can't seem to find anything like that. I found the date and copyright, but not any revision number. I guess IBM didn't include revision numbers properly in the earlier BIOS'es before 1985.

No. The 487SX socet is empty. The first versions of CGA_COMP wouldn't even run on it because it lacks a math coprocessor.

Okay, my bad again (sorry, I wrote parts of the detection library 15 years ago): The BIOS date and revision are appended to the BIOS string. So, in this string:

1501512 Corp. IBM 1981 (11/08/82, Rev. 244)

The "1501512 Corp. IBM 1981" is ascii found in the ROM BIOS and the "(11/08/82, Rev. 244)" is found using the following code:




Function BiosDate;
Begin
BiosDate:=Chr (MEM[$FFFF:$0005])+Chr(MEM[$FFFF:$0006])+
Chr (MEM[$FFFF:$0007])+Chr(MEM[$FFFF:$0008])+
Chr (MEM[$FFFF:$0009])+Chr(MEM[$FFFF:$000A])+
Chr (MEM[$FFFF:$000B])+Chr(MEM[$FFFF:$000C]);
End;

Function BiosRevision;
Var
W:Word;
Begin
Regs.AH:=$C0;
Regs.ES:=0;
Regs.BX:=0;
Regs.Flags:=Regs.Flags and FCarry;
Intr($15,regs);
BiosRevision:=Mem[Regs.ES:Regs.BX+4];
End;



Since your BIOS doesn't support that call, it's invalid. The code to detect system type and BIOS revision are obvious not related, so I'll fix the code. (Someday, not now. Probably when I write my benchmark.)

As for the 486 misfire, I don't have a 486sx so I can't immediately fix that. But thanks for the bug report and I'll probably remove that part until I can test it.

Great Hierophant
July 26th, 2009, 05:11 PM
I had occasion to test this software in my Tandy 1000 TL, and the CGA emulation was surprisingly good. The tests it failed were the Interlace Mode (showing what a VGA card would show) and all the memory read/write tests. It complained about the timing, even though this machine is XT class and built before 1990. (It did have a 286-486 accelerator in it.)

It also did not show the tweaked text mode pictures exactly as they should have been, but the reason why is because the Tandy font has differences compared to the IBM PC font.

Edit: a Tandy 1000 SX is more compatible. The Interlace Mode showed up exactly as it would on a true IBM CGA except that you needed to set the screen to use 200 lines instead of 225. The memory read/write tests were faster than a real CGA, but I assume that is because the CPU is faster.

nestor
September 17th, 2010, 11:35 AM
Anyone has the last cgacomp release available? I can't access the oldskool.org webpage, it is down right now...

EDIT: Is up again.

Trixter
March 15th, 2016, 04:29 PM
I needed to add some monitor calibration tests to the CGA compatibility tester, so: Surprise! New version (v1.1) is available at http://www.oldskool.org/pc/cgacomp . Features added to the new release:



Composite modes and monitors now officially supported.
Added aspect ratio calibration pattern.
Added color uniformity/purity screens.
Added monitor linearity grids.
Replaced Robert Tyler picture with an amazing original piece from VileR.
Added Composite CGA identification screen originally seen in "8088 MPH".
Optimized code for size and overlay usage. Now runs on 128KB systems w/ DOS 3.x (I tested 3.1; bootable disk image available at same URL above). Tandy and PCjr still require 256KB, sorry.
Bugfixes (vertical refresh rate detection actually works now, whoops).


Much of this work was done because I'm going to start making videos of authentic CGA output, and needed a way to stress any capture/processing solutions I will be experimenting with.

Trixter
March 24th, 2016, 12:46 PM
New release of the CGA Compatibility Tester (http://www.oldskool.org/pc/cgacomp), in which Jim completely removes the aspect ratio test pattern and replaces it with something sensible. Here's what's new:


Added convergence pattern.
Changed Uniformity test to cycle through RGBI pins.
Pressing "P" will now pause/unpause any color cycling.
Re-tooled aspect ratio pattern for composite monitors only.
Clarified descriptions for tests meant for a particular monitor.


It's usable as a monitor calibration tool too, BTW.

Trixter
May 6th, 2016, 09:07 AM
Just added a new release (http://www.oldskool.org/pc/cgacomp) with some test plates and options that help if you are trying to capture real CGA video footage (both with a capture solution as well as a videocamera.) Here's what's new:



Added video capture color and luminance test plates.
Added vertical/horizontal motion video capture torture test.
Added capture dropped frame and audio/video sync test.
Added IRGB pin and color text labels to the uniformity test.
Completely rewrote vertical refresh rate detection because I'm an idiot.
Added command-line options for batch usage.

Scali
May 6th, 2016, 09:17 AM
Completely rewrote vertical refresh rate detection because I'm an idiot.

I thought this one was "Don't ask, don't tell" ;)

Trixter
May 6th, 2016, 11:00 AM
There is an obvious way to measure refresh rate (record time difference between two subsequent start-of-refresh events). I was not doing it that way, hence I was an idiot. I can't tell you how I was doing it before because I cleansed prior versions with fire.

Great Hierophant
May 7th, 2016, 02:00 PM
I know there is some color variation between Old and New CGA, but for color 6 on the composite low-res text should not be "forest green". Its closer to "moss green."

Trixter
May 7th, 2016, 06:43 PM
Just for you, I changed the text :-)

Trixter
June 23rd, 2017, 08:35 PM
For those who want to see how some of the sausage is made, I put the source code up on github (https://github.com/MobyGamer/CGACompatibilityTester). I also restored the original color bars test plate since people liked the solid colors, and also two new bars plates.

Simone2013
June 24th, 2017, 01:16 AM
Hi Trixter,
thank you for the code, very nice. I was asking myself why the detection code failed (hang) on my PC1 Olivetti with XT-IDE Universal BIOS.

Maybe I found an answer:
in WHICHCGA.ASM

4 demoAPI EQU 0F8h
6 ; Determine if loader is present, and abort if not
8 ; First, check to see if the API is even present.
9 ; If not, don't try to call anything since it will hang the system.
10 xor bx,bx
11 mov es,bx
12 mov di,(demoAPI * 4)+2 ;check to see if our INT is empty
13 cmp [word es:di],bx ;int. vector empty?
14 je exitShort ;abort if so
15 mov ax,0700h ;check int. vector to see if it's ours
16 int demoAPI

it check intvec F8 but:

"XTIDE BIOS variables can now be located to top of base RAM and it is the default setting. It will steal 1kB of base RAM but it ensures that nothing accidentally corrupts BIOS variables. Top of interrupt vectors (30:0h) can be used if necessary. All Tandy 1000 models with 640kB or less RAM require that top of interrupt vectors are used". Mine is configured to use top of vector. So it find a NON-zero vector @ int F8.

I checked and mine is nonzero...
Can be this that is locking machine during test?
Also earlier version of 8088MPH didn't hang, but last version did.

Thank you

Trixter
June 24th, 2017, 08:45 AM
INT F8h is custom to 8088 MPH's interrupt services code. When 8088 MPH runs, INT F8 is installed before the WHICHCGA code runs. If it hangs on your system, that isn't why; likely it is because of the custom video modes we're creating.

Including WHICHCGA in the repo was a mistake, whoops. I'll leave it in for the curious (we have better tricks now).

Simone2013
June 25th, 2017, 06:14 AM
INT F8h is custom to 8088 MPH's interrupt services code. When 8088 MPH runs, INT F8 is installed before the WHICHCGA code runs. If it hangs on your system, that isn't why; likely it is because of the custom video modes we're creating.

Including WHICHCGA in the repo was a mistake, whoops. I'll leave it in for the curious (we have better tricks now).

Ok, thank you trixter. Maybe installation of this INT overwrite some XT-IDE parameters and then reading from Hard Disk result in some mess?
Earlier version of 8088MPH did not hang so is not about the graphics, ... maybe there is some relation with high interrupt customization?
I had to investigate. To the debugger! ;)

Trixter
June 25th, 2017, 08:03 PM
Ok, thank you trixter. Maybe installation of this INT overwrite some XT-IDE parameters and then reading from Hard Disk result in some mess?
Earlier version of 8088MPH did not hang so is not about the graphics, ... maybe there is some relation with high interrupt customization?
I had to investigate. To the debugger! ;)

No, the INT F8h stuff is not related here, you're mistaken. It doesn't overwrite xt-ide parameters. It's an unused interrupt vector that we decided to use.

Scali
June 25th, 2017, 11:22 PM
Earlier version of 8088MPH did not hang so is not about the graphics

I don't recall that we changed anything in the loader between the party version and the final version, so it has always used a loader at int F8h.
Of course the WHICHCGA program itself is new in the final version. So it could be that this program is buggy on your system, while the rest of the demo is not.
I believe the WHICHCGA program is called 8088MPH.001 in the final version. You could replace that with a 'dummy' program to see if that fixes it.
Eg, if you would copy 8088MPH.002 to 8088MPH.001, you'd get the calibration screen twice, and the rest of the demo should work as-is.
Mind you, the calibration screen is new as well, so that may also fail... So you may want to try with 8088MPH.003 first, and perhaps also replace 8088MPH.002 :)