True CGA vs VGA card in CGA mode

[Fallo]

...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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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...!