• Please review our updated Terms and Rules here

EGA video corruption?

Trixter said:
You'll notice that the stars stay in the same place while the entire ship is moving; this is due to the hardware address being changed while the stars are redrawn to make them look like they're stationary.

It's possible that a 286/10 + slow EGA card + bad programming is the cause. I don't think it means anything is broken, it's just the way it is.
Click to expand...

Foul ball for having a post with the words EGA, Video and Corruption in it and having Jim reply to it - got my hopes up.
 
Trixter said:
You'll notice that the stars stay in the same place while the entire ship is moving; this is due to the hardware address being changed while the stars are redrawn to make them look like they're stationary.

It's possible that a 286/10 + slow EGA card + bad programming is the cause. I don't think it means anything is broken, it's just the way it is.
Click to expand...

Thx! Some other games like Keen show the same issue, but i can live with that, mostly it is quite OK.
 
Last edited:
Some later games with that engine (eg. Keen) have an option for "svga-compatibility-mode"/"alternative-mode".
If that option is available und choosen, this fixes the stutterproblems for my EGA! card in that games.
I'll have a look what games that were and post them later on.
 
Is yours an original IBM EGA card, or a clone?
To me it looks like there is a synchronization problem. This may be because your EGA card latches and resets its internal registers at slightly different times than the EGA card the developers targeted.

It could also be as Trixter says, the timing issues are a result of your EGA card and/or your CPU not being fast enough to stay in sync.
 
It is a special EGA Onboard-Chip with 256KB (Gemini-VC001). That Card hat the same Chipset=> greyghost.mooo.com/eg3000
It has much more resolutions. 640x400 640x480 up to 800x600@16colors.
I can change some Bios-Settings for the used Monitor. Currently Multisync-Hires Display is chosen. That gives the best looking Picture.
I can change CPU/Cycles within the Bios of the Machine. Currently full speed is chosen (10/10), I can change that to 10/5 and 5/5,
but that will slowdown the PC significantly.

I have experimented with "ega.sys" dosdriver and "fastbios.sys" but the use of these drivers do not make any differences in performance or visability.

Doc
 
Last edited:
Commander Keen 4, 5 & 6 show the same kind of stuttering in their intros with an EGA card and if the game is run on a system outside a narrow speed range. I bet you won't see that stuttering if you run the game with a VGA card in the same system.
 
Great Hierophant said:
Commander Keen 4, 5 & 6 show the same kind of stuttering in their intros with an EGA card and if the game is run on a system outside a narrow speed range. I bet you won't see that stuttering if you run the game with a VGA card in the same system.
Click to expand...

That holy grail of smooth-scrolling in 1 frame... so easy on most 80s systems, yet so difficult on early PCs :)

I must say, I didn't know about that game Menace, looks quite nice (and ambitious) for early PC shoot-em-ups.
Xenon II should also work on EGA btw, although it only does vertical scrolling, which should be easier than horizontal.
 
what is "a system outside a narrow speed range?" can you fix it with some numbers?
EGA on an EGA-Card is 8Bit with what Busspeed? 5 Mhz?

Thx
Doc
 
I changed the Bios-Settings CPU/BUS from "10Mz/CPU-Takt", which means 10/10 to 10/5.
If I reboot the machine this particular Intro-Scene with the giant SpaceShip is absolute stutterfree !! :)
The reduction of the Bus-Speed causes 20% less GPU-Speed in the Landmark600 test (490->410),
but it causes some effects that the machine does not feel so fast as before with the 10/10 option.

But!, the 10/5 Option does not solve all down stuttering-problems.

First I must differentiate between "global stuttering" which most games have and "stuttering with flickering",
the stuttering with flickering (as you saw in the menace-intro) is in some games like "DDAVE", "CCAVES", "SAGENT".
Some of them have a "alternative scrolling" option which solves this problem, there is "only" global stuttering" left.

This scrolling issues are possible something for the next "nerdly-pleasures-article" :)

As "scali" already said, stutterfree scrolling was a domain of the old 8/16Bit Homecomputers, and the (early)
PC's have lot's of problems with that, that is a real mess.

Doc

****Edit****
Beside the first Shooter "MENACE" the follower "BLOOD-MONEY" does not get smooth scrolling.
The starfield in the Back of the planets look nice and is smooth, but the game stutters all the time.
it is a bit better by pressing "F4" during gameplay, but ist is far away from the amiga performance.
too bad that psygnosis did not include any other then pc-peepser. I alway thought about putting
audio in the old pc-ports of 16Bit Homecomputer-Stuff, but that is not realistic at any time in the future.
 
Last edited:
chjmartin2 said:
Foul ball for having a post with the words EGA, Video and Corruption in it and having Jim reply to it - got my hopes up.
Click to expand...

The only way I would target EGA for video playback would be to go back to text mode and use a custom font. EGA has latch tricks for updating graphics, but if the entire graphics screen is changing, it's too slow. EGA also has latch tricks for copying VRAM around, which I suppose could be leveraged for a vector-quantization scheme, but again if the entire screen needs to change, copying 64KB+ blocks would be too slow. Even deltas would be too slow, IMO.

So, here's a project for an enterprising individual: Write a video converter for EGA that uses text mode and leverages one or more of the following:


  • Multiple video pages
  • Custom font
  • Both font banks (can have 512 different characters onscreen simultaneously)
  • Different palettes (text mode can use any 16 of the available 64 EGA colors)

Quick datarate check: Assuming all of the above is possible to change in a single frame, (80*25)+(512*16)+16 = 10208 bytes per frame to change a "640x400x16" picture. At 24fps, that's ~240KB/s.
A more reasonable target would be a single font bank and 40x25 text mode, for (40*25)+(256*16)+16 = 5112 bytes per frame to change a "320x400x16" picture. That cuts the datarate in half.
 
dr.zeissler said:
I changed the Bios-Settings CPU/BUS from "10Mz/CPU-Takt", which means 10/10 to 10/5.
If I reboot the machine this particular Intro-Scene with the giant SpaceShip is absolute stutterfree !! :)
The reduction of the Bus-Speed causes 20% less GPU-Speed in the Landmark600 test (490->410),
but it causes some effects that the machine does not feel so fast as before with the 10/10 option.

But!, the 10/5 Option does not solve all down stuttering-problems.

First I must differentiate between "global stuttering" which most games have and "stuttering with flickering",
the stuttering with flickering (as you saw in the menace-intro) is in some games like "DDAVE", "CCAVES", "SAGENT".
Some of them have a "alternative scrolling" option which solves this problem, there is "only" global stuttering" left.

This scrolling issues are possible something for the next "nerdly-pleasures-article" :)

As "scali" already said, stutterfree scrolling was a domain of the old 8/16Bit Homecomputers, and the (early)
PC's have lot's of problems with that, that is a real mess.

Doc

****Edit****
Beside the first Shooter "MENACE" the follower "BLOOD-MONEY" does not get smooth scrolling.
The starfield in the Back of the planets look nice and is smooth, but the game stutters all the time.
it is a bit better by pressing "F4" during gameplay, but ist is far away from the amiga performance.
too bad that psygnosis did not include any other then pc-peepser. I alway thought about putting
audio in the old pc-ports of 16Bit Homecomputer-Stuff, but that is not realistic at any time in the future.
Click to expand...


I believe I have also seen what you describe as "Global Stuttering" with Keen 4-6. I refer to in game scrolling where the image appears to shift back and forth as you scroll and screen tearing can be seen. I can easily replicate this in DOSBox with an EGA machine type and a cycle count below 1000 or about 2400. I came to the conclusion long ago that these shareware games were designed by programmers with VGA cards, because with VGA these games' scrolling routines are not speed sensitive.
 
Great Hierophant said:
I came to the conclusion long ago that these shareware games were designed by programmers with VGA cards, because with VGA these games' scrolling routines are not speed sensitive.
Click to expand...

But that is totally stupid to "design" games for VGA and use EGA with fixed 16 colors instead of choosing up to 256 form 262.000 ?
 
The 10/5 Combination does not solve all Problems and causes some new ones. I changed it back to 10/10.
Here is how the Bios looks like.
P1080178.jpg

I managed to figure out, how to get "BloodMoney" smooth. It is quite simple. Choose "Fast-PC" in the menu
and press "F4" during gameplay. You will see the stuttering in the video and it is gone after pressing "F4"


Greetings
Doc
 
dr.zeissler said:
But that is totally stupid to "design" games for VGA and use EGA with fixed 16 colors instead of choosing up to 256 form 262.000 ?
Click to expand...

Not really.
In 16-colour mode you only need 4 bits for every pixel, instead of 8.
So you can fit twice as much data into video memory, and only need to move half as much data around for scrolling.
If they went for full 256-colour VGA, the system requirements would be much higher (just look at games like Jazz Jackrabbit).

I do agree that they could have chosen any 16 colours from the VGA palette. But since the game is even CGA-compatible, they probably wanted to be EGA-compatible as well, and didn't see any reason to make specific VGA-graphics.
 
Great Hierophant said:
I came to the conclusion long ago that these shareware games were designed by programmers with VGA cards, because with VGA these games' scrolling routines are not speed sensitive.
Click to expand...

I wonder what makes them speed-sensitive on EGA though. EGA should not behave differently from VGA when it comes to scrolling.
One theory I can think of is that they don't understand the latching of the screen offset and scroll registers.
On many systems you would wait for vertical blank to update the scroll position of the screen. On CGA/EGA/VGA however, you can write the value anytime you like, and it will not become active until the next frame starts (I (ab)use this in 8088 MPH: I set the new vertical scroll position just before I start drawing the sprite, which is after the last visible scanline of the previous position was passed by the beam).
If you actually DO try to wait for vertical blank, you may run the risk of being too late, and your value will get latched, and won't get active until a frame later. Which would explain the big jumps (they seem to jump 8 pixels at a time, which is exactly how much you can scroll the screen).

Perhaps most VGA cards are somewhat more 'forgiving', or they just process the data faster, leading to less sensitivity when scrolling.
 
Great Hierophant said:
I believe I have also seen what you describe as "Global Stuttering" with Keen 4-6.
Click to expand...

You are right with that. Keen 4-6 stutter all the time. The svga-compatiblity mode does not help either. What did they do wrong? Keen 1-3 is not stutterfree either, but MUCH better then the later ones.
 
Trixter said:
The only way I would target EGA for video playback would be to go back to text mode and use a custom font. EGA has latch tricks for updating graphics, but if the entire graphics screen is changing, it's too slow. EGA also has latch tricks for copying VRAM around, which I suppose could be leveraged for a vector-quantization scheme, but again if the entire screen needs to change, copying 64KB+ blocks would be too slow. Even deltas would be too slow, IMO.

So, here's a project for an enterprising individual: Write a video converter for EGA that uses text mode and leverages one or more of the following:


  • Multiple video pages
  • Custom font
  • Both font banks (can have 512 different characters onscreen simultaneously)
  • Different palettes (text mode can use any 16 of the available 64 EGA colors)

Quick datarate check: Assuming all of the above is possible to change in a single frame, (80*25)+(512*16)+16 = 10208 bytes per frame to change a "640x400x16" picture. At 24fps, that's ~240KB/s.
A more reasonable target would be a single font bank and 40x25 text mode, for (40*25)+(256*16)+16 = 5112 bytes per frame to change a "320x400x16" picture. That cuts the datarate in half.
Click to expand...

Why 640x400 and 320x400 versus 640x200 and 320x200? Don't want to hijack thread....
 
Scali said:
I wonder what makes them speed-sensitive on EGA though. EGA should not behave differently from VGA when it comes to scrolling.
One theory I can think of is that they don't understand the latching of the screen offset and scroll registers.
On many systems you would wait for vertical blank to update the scroll position of the screen. On CGA/EGA/VGA however, you can write the value anytime you like, and it will not become active until the next frame starts (I (ab)use this in 8088 MPH: I set the new vertical scroll position just before I start drawing the sprite, which is after the last visible scanline of the previous position was passed by the beam).
If you actually DO try to wait for vertical blank, you may run the risk of being too late, and your value will get latched, and won't get active until a frame later. Which would explain the big jumps (they seem to jump 8 pixels at a time, which is exactly how much you can scroll the screen).

Perhaps most VGA cards are somewhat more 'forgiving', or they just process the data faster, leading to less sensitivity when scrolling.
Click to expand...

Thing is, CGA/EGA/VGA are *not* compatible in terms of register latching. It took a while, and lots of comparison to real HW, to get it right in DOSBox back then (vga_draw.cpp).

Code: 
switch(machine) {
...
	case MCH_CGA:
	case MCH_HERC:
		// MC6845-powered graphics: Loading the display start latch happens somewhere
		// after vsync off and before first visible scanline, so probably here
		VGA_DisplayStartLatch(0);
		break;
	case MCH_VGA:
		PIC_AddEvent(VGA_DisplayStartLatch, (float)vga.draw.delay.vrstart);
		PIC_AddEvent(VGA_PanningLatch, (float)vga.draw.delay.vrend);
...
		break;
	case MCH_EGA:
		PIC_AddEvent(VGA_DisplayStartLatch, (float)vga.draw.delay.vrend);
...

On the 6845 the display start latching is not related to the vertical retrace pulse in the status register. Probably it's taken at the point where it's used for the first time, before the first line of the frame.

On compatible VGA, the display start address is latched at the rising edge of the retrace pulse. The PEL panning value is latched at the falling edge. Yes, it's idiotic but that's what the vast majority of VGA models do.

On EGA and the Paradise PVGA1A, and maybe others, display start is latched at the falling edge, and PEL panning is NOT LATCHED AT ALL. PEL panning can be updated while visible scanlines are put out and the change is seen immediately (or at scanline start). The game Beverly Hills Cop (by Tynesoft) uses this to show a screen with text with sine wave effect. This works on EGA but not on VGA (except on the Paradise card).

As this exact latching behaviour is totally undocumented, programmers who were not aware of it and trusted backwards compatibility produced bad games for the EGA. Also hardware manufacturers who didn't bother to test their compatibility 100% exactly produced incompatible cards, such as Paradise and Matrox and I think I've also seen problems on some AGPish ATI models.

From the behaviour above it can also be derived that it's a bad idea on EGA/VGA to write the registers any time you like if using panning. There is a time window where values from the previous frame can be mixed with the next frame: the vsync pulse. When your update hits this window you will get an inconsistent frame.
 
You must log in or register to reply here.
Back
Top