VOGONS


First post, by VileR

User metadata
Rank l33t
Rank
l33t

Other than the usual things you can expect in such a situation (such as some monitors losing sync) - could this also result in garbage/unexpected *content* from VRAM being displayed?

Not that this is a very useful thing to do... but I've seen this happen on the internal plasma display of a PS/2 Model P70 (while the machine's owner and I were trying to figure out some *other* puzzling behavior with the P70's video subsystem). One of our tests involved setting plain old 80x25 text mode - clearing video RAM in the process - then increasing Vertical Display End. When this exceeded Vertical Retrace Start, the screen suddenly filled up with garbage content.

I'm curious to know whether this is common VGA behavior, or just another quirk of the P70. I realize that the start of vertical retrace is 'special' in some respects, e.g. it's when the (latched) start address takes effect for the next frame; also, there are certain situations in which the VGA has no business reading video RAM, and the vertical retrace period might be one of those.

But that wouldn't fully explain actual content being displayed when VRAM has just been cleared by a mode set. I suppose it may somehow be the font data from plane 2 (misinterpreted as character/attribute pairs), but how and why is still a puzzle.

If anyone feels like trying a quick test with TWEAK program (http://ftp.lip6.fr/pub/pc/garbo/pc/screen/tweak16b.zip), you can:
- hit TAB for the text mode test, then Enter to see what it looks like with the default values
- change "Vert. disp. enable end" to 9c or greater, then run the test again
- does the screen now show the same test pattern, or some other garbage? Is the display stable, or does it keep changing?

[ WEB ] - [ BLOG ] - [ TUBE ] - [ CODE ]

Reply 1 of 13, by clb

User metadata
Rank Member
Rank
Member

I did a quick test with the VGA adapter I currently have connected on my test lab PC, which is an Ahead V5000B card:

AheadV5000B.jpg
Filename
AheadV5000B.jpg
File size
1.45 MiB
Views
754 views
File license
Public domain

Specs of this card look like:

SNOOP-AheadV5000B.png
Filename
SNOOP-AheadV5000B.png
File size
409.4 KiB
Views
754 views
File license
Public domain

Initially I get this in the Tweak 1.6b text test mode:

AHEAD-V5000B-Tweak-default.png
Filename
AHEAD-V5000B-Tweak-default.png
File size
1.43 MiB
Views
754 views
File license
Public domain

and when I set Vert. disp. enable end to 9c, it starts to output this kind of a flickering thing instead: https://oummg.com/dump/AheadV5000B-Tweak16B-D … pEnable=9Ch.mkv

Not sure if that is the behavior you are seeing, or something different.

Reply 2 of 13, by VileR

User metadata
Rank l33t
Rank
l33t

Thanks for checking! The status display is helpful too, since it shows that the H/V In timings are stable (i.e. those blank frames aren't due to a loss of sync). Along with the changing patterns, it looks like the start address keeps changing between frames... so extending Vertical Display into the retrace period does seem to interfere with retrieving the latched start address value, somehow.

That seems to fit what I saw on that P70, although there's no spurious content being displayed that wasn't explicitly put there by TWEAK.

[ WEB ] - [ BLOG ] - [ TUBE ] - [ CODE ]

Reply 3 of 13, by clb

User metadata
Rank Member
Rank
Member

Yeah, video sync is definitely stable.

I tried it out on a couple of other cards, and interestingly that flashing behavior was unique to Ahead V5000B.

The other cards all showed a static unchanging picture (no flashing to black in between), e.g. here on a ATI 28800-6:

TWEAK16B_VertDispEnableEnd=9Ch.png
Filename
TWEAK16B_VertDispEnableEnd=9Ch.png
File size
841.42 KiB
Views
692 views
File license
Public domain
ATI28800-6.jpg
Filename
ATI28800-6.jpg
File size
1.76 MiB
Views
692 views
File license
Public domain

Reply 4 of 13, by kdr

User metadata
Rank Member
Rank
Member

Just before the holiday season, I was playing around with improper VGA modes in an attempt to reload the CRTC start address multiple times per frame. I was doing my experiments on an old 286 with an integrated Paradise PVGA1A chipset. I was planning to do further work before writing it up, but Real Life got in the way and I'm not able to get back to the old retro computers for a while.... so here's a quick summary:

Using standard IBM VGA registers, it's possible to move the CRTC's VSYNC period into the active display area without the CRTC producing a corresponding pulse on the VSYNC pin connected to the monitor but still trigger the reloading of the CRTC's internal address counter from the Start Address register! We can also (ab)use the Vertical Display End register to generate an alternate sync pulse that is output to the monitor on the VSYNC pin but without triggering the CRTC's vertical sync logic!

This lets us place Vertical Retrace Start/End on any desired scanline (without needing to count scanlines or poll the status register) and thus reload the CRTC's address counter with an arbitrary value at an arbitrary scanline of our choice! We still have Line Compare, and this lets us do a really cool trick: hardware split screen with the fixed portion of the display ABOVE the scrolling portion of the display!

How to do it?
- set port 3CA bit 3 (VSYNC Select bit of the Feature Control Register)
- set Vertical Display End to be ~8 scanlines less than Vertical Total
- set Vertical Blanking Start to be ~12 scanlines less than Vertical Total and Vertical Blanking End to a value of 16 or so
- move Vertical Retrace Start/End into the active display area
- (optionally) set Line Compare to trigger on scanline 16

The Video 7 VGA technical reference manual has the best description I've seen of what the "VSYNC Select" bit actually does:

vsync_select.png
Filename
vsync_select.png
File size
118.16 KiB
Views
643 views
File license
Public domain

Basically what happens is that during the active display, the internal vertical display enable signal is high, forcing the VSYNC output to remain high regardless of what the internal vertical sync signal is doing. The brief period between Vertical Display End and Vertical Total is our new vsync signal - during this time the internal vertical display enable signal is low, and the internal vertical retrace signal is also low, so the VSYNC output goes low.

I'm pretty sure (but haven't yet tested) that Vertical Retrace can be reloaded multiple times per frame and that bit 3 (vertical retrace) of the input status register will follow the internal vertical sync signal as opposed to the external VSYNC pin. It shouldn't be too difficult to use a timer interrupt to poll the status register and use the vertical retrace bit to trigger the reloading of the next Vertical Display Start/End and Start Address from a "display list" of (scanline, address) pairs and get as many split screens as you want...

The big question: does this work on other VGA chips?

Reply 5 of 13, by VileR

User metadata
Rank l33t
Rank
l33t
clb wrote on 2024-01-25, 23:56:

Yeah, video sync is definitely stable.

I tried it out on a couple of other cards, and interestingly that flashing behavior was unique to Ahead V5000B.

The other cards all showed a static unchanging picture (no flashing to black in between), e.g. here on a ATI 28800-6:

With the Ahead card, I see that SNOOP.EXE warned about non-standard register latching behavior. I wonder if there's any correlation between that and the flashing/start address instability - do the cards with the stable image report anything off there, or are they more compatible?

(I'm not really expecting that to be the issue, since the VGA in the Model P70 should be as IBM-standard as they come... but there have been instances of IBM not being 100% compatible with themselves.)

[ WEB ] - [ BLOG ] - [ TUBE ] - [ CODE ]

Reply 6 of 13, by clb

User metadata
Rank Member
Rank
Member
VileR wrote on 2024-01-29, 18:53:

With the Ahead card, I see that SNOOP.EXE warned about non-standard register latching behavior. I wonder if there's any correlation between that and the flashing/start address instability - do the cards with the stable image report anything off there, or are they more compatible?

Ohhh, that is actually a bug if it says that for you.

Some of the tests there require CRT Terminator to be present (and the tests are skipped if not). The register latching behavior is one of those tests. (that test requires getting feedback from the generated video pixels back to CPU side, which CRT Terminator enables)

But looks like I have not properly gated out the latching printing in that test when CRT Terminator is not present - so in your case, the code that SNOOP reports is bogus (just based on default-initialized ints in that main function)

Reply 7 of 13, by VileR

User metadata
Rank l33t
Rank
l33t
kdr wrote on 2024-01-27, 03:38:

Just before the holiday season, I was playing around with improper VGA modes in an attempt to reload the CRTC start address multiple times per frame. I was doing my experiments on an old 286 with an integrated Paradise PVGA1A chipset. I was planning to do further work before writing it up, but Real Life got in the way and I'm not able to get back to the old retro computers for a while.... so here's a quick summary:

[...]

The big question: does this work on other VGA chips?

Ha - interesting find! If you posted a thread with a test program I'm sure some answers will materialize. I think I'm getting the idea, although Video 7's depiction of what is 'expected'(?) doesn't make much sense to me.

Of course, IBM being IBM, *their* documentation of Feature Control just says "All bits in this register are reserved, bit 3 must equal O". I was able to find other manufacturers documenting the same behavior though, so it just might work quite reliably. 😀

[ WEB ] - [ BLOG ] - [ TUBE ] - [ CODE ]

Reply 8 of 13, by VileR

User metadata
Rank l33t
Rank
l33t
clb wrote on 2024-01-29, 18:59:

Ohhh, that is actually a bug if it says that for you.

I don't have that particular card - I was referring to the screenshot you posted (second one in post #2).

[ WEB ] - [ BLOG ] - [ TUBE ] - [ CODE ]

Reply 9 of 13, by clb

User metadata
Rank Member
Rank
Member

Gotcha, now I follow.

I would assume that the latching of the DS and HS registers would not affect this behavior - except possibly indirectly, if engineers happened to choose to latch other registers with the same scheme. Maybe there might be some correlation if it was common/easy for engineers to follow the same latching logic on multiple internal registers, but not sure if that might be a thing.

Reply 10 of 13, by VileR

User metadata
Rank l33t
Rank
l33t

Maybe this is a better test to run. This is the exact test which was run on that Model P70 - I just took out the irrelevant stuff:

Filename
VDETEST.zip
File size
390 Bytes
Downloads
15 downloads
File license
Public domain

It simply loops through the Vertical Display End values 100h-1FFh. Here's a video of what happened on the P70:
https://int10h.org/dump/P70_VDEtest.mp4 (warning for the photosensitive - lots of flashing!)

P70_VDEtest.jpg
Filename
P70_VDEtest.jpg
File size
45.59 KiB
Views
468 views
File license
Public domain

When the value exceeds Vertical Retrace Start, it starts flashing this garbage onto the screen. I don't have the slightest clue where this content comes from, since video RAM was just wiped clean by a mode set, then written with 16K of plain blue background.
I thought perhaps the wrong plane was being displayed somehow, and this was the font bitmap data being misread as characters and attributes... but upon further investigation, this isn't what that would look like.

I wonder if the Ahead V5000B card will show the same results here... but if anyone can test this and find another VGA card where this occurs, I'd be thankful.

[ WEB ] - [ BLOG ] - [ TUBE ] - [ CODE ]

Reply 11 of 13, by clb

User metadata
Rank Member
Rank
Member

Here's what happens with the Ahead V5000B card: https://oummg.com/dump/AheadV5000B_VDETEST.mkv

I wonder if the behavior you are seeing is related to DRAM refreshing? Maybe the refreshing logic is somehow dependent on vblank triggers, and when those get messed up, the video memory corrupts itself?

What would happen if after doing that test, before changing video modes you might read the whole 256KB video memory to disk, and examine the contents? Could the bytes all of a sudden be no longer cleared?

Reply 12 of 13, by clb

User metadata
Rank Member
Rank
Member

I recently acquired the original IBM VGA card in ISA form, 75X9017XM:

IBM_VGA_75X9017XM.jpg
Filename
IBM_VGA_75X9017XM.jpg
File size
1.21 MiB
Views
446 views
File license
Public domain

Running VDETEST on this adapter produces the same kind of result as the Ahead card:

https://oummg.com/dump/IBM_VGA_75X9017XM_VDETEST.mkv

Reply 13 of 13, by VileR

User metadata
Rank l33t
Rank
l33t

Cool, appreciate the results. I don't think it's an issue of DRAM under-refresh corruption; when it exits to DOS you can see the clean blue background again, although it doesn't reset the mode or rewrite video RAM, so the contents are intact.

Maybe if the display is still active during vertical retrace, it puts the VGA into some state where the start address is improperly decoded, and the sequencer ends up trying to read non-existent memory, thus receiving undefined data... or maybe the garbage comes from video RAM outside of the four 32K banks used in text mode - if those unused 128K aren't initialized when you set mode 3, I suppose they could contain anything.

[ WEB ] - [ BLOG ] - [ TUBE ] - [ CODE ]