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

Specs of this card look like:

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

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.

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.

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:

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:

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?

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

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)

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

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

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.

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:

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

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.

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?

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

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

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

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.