PC-CHECK has a pretty comprehensive set of video card tests.

PC Tech Journal's VGA test suite: VGATEST2

Thanks so much, these look promising. Can't wait to try them out 😀

I like the VDIAG program that ships with Tseng cards 😀

I just tried to use the PGAME app from https://pcem-emulator.co.uk/phpBB3/viewtopic.php?t=3089 within UniPCemu.

Somehow, the display rocks back and forth each time it shifts a few(8 or less?) pixels while rendering it? That used to happen with vertical timing as well, until I changed the preset row scan to be properly loaded on vertical total being reached.

Anyone knows what might cause the horizontal jumping? When disabling the precalcs for the start address, the jumping seems to stop(and the vertical movement stops altogether)?

Although I know that split-screen is properly working(Jazz Jackrabbit uses it for the status part during gameplay), the thing I'm currently interested in is mostly the panning stuff(Horizontal/Vertical panning tests).

I ran the VGATEST2 checks. Most of them ran without errors.

Until I got to what seemed to be scrolling tests. There, the display scrolling was behaving strangely? Scrolling left kept bobbing up and down(just like CGA emulation does with the CGA Compability tester tool)?
That's the tool from http://www.oldskool.org/pc/cgacomp

Does that mean some weird bug in the Start Address Register emulation somehow?

Vertical scrolling seems to work without issue(at least with some tests, like the start of the test I mentioned earlier(the PGAME test's first test, until it starts scrolling horizontally)), but the horizontal scrolling somehow doesn't work properly?

I can remember seeing someone on Youtube using some kind of WhatVGA-like interface to modify the VGA registers manually(from text or graphics modes) to see what happened on a real VGA. Like putting strange values in registers and seeing them affect the display.

But I can't seem to find that video anymore... It might have been exactly what I'm searching for to find out what the VGA emulation is doing wrong?

Anyone? It was something about hack(ing) the VGA or messing around with it's registers... I just can't seem to find it anymore...

Btw, there's also WhatVGA, which allows a bit of playing with the display modes on (S)VGA cards.

After some messing around with the rendering handler's way of rendering, I notice something strange.

I set the software setting for the panning register to become 08h in it's settings.

When I look at the mode being set(by pressing Enter), I do indeed see it being loaded and used correctly(rendering n half-pixels without actually rendering them to display, ignoring bit 0). But somehow, when display is finished a few times, the register and precalcs on the Sequencer and it's value are zeroed again?

Is the app somehow clearing the register after it's set to it's configured value? In this case, I set it to 8h. UniPCemu shouldn't be clearing the register and precalcs by itself afaik?

Just taken a look at PGAME's source code.

There I see something weird:

1	pipa = x;
2	if (x > 7)pipa = pipa - (8*(pipa/8));
3	
4	x=x/4;
5	/*if (x > 79) x = x - (80*(x/80));*/
6	
7	y=y*80;

Y seems fine, as does x on the start address(is as documented in mode X).
But the pipa seems weird? x is never negative in this case. Then, the pixel panning is always from 0 through 7? Then that multiplied by 2(for 8-bit pixels), it's a range of 0-15, in steps of 2(steps of 2 sounds fine).
But why is the pixel panning in steps of 8 pixels instead of 4 pixels(which would work with the 4 pixel granularity of the start address register)? Isn't the pixel panning supposed to be handled in steps of 2, up till 4 pixels instead of it's setting of 8(which makes the start and horizontal pixel panning registers out of sync past an x of 3)?

Hmmm... What happens on a real ET4000 or VGA with the invalid high values in the pixel panning register? The demo seems to suggest it wraps around (&=7) for 8 dots/clock modes? Does the same happen for the 9 dots/clock modes, but -1? So 9=1, 10=2,11=3,12=4,13=5,14=6,15=7? Or are they incremented as well?

OK. Both Dosbox-X and Bochs seem to agree to wrap to 3-bits in non-9 bit mode.

But which one is correct? Is 9 bit mode for the horizontal pel panning determined by the 9/8dot clock setting(Bochs) or the 9-bit text setting of the attribute mode control register(Dosbox-X)?

Just managed to fix it. Now UniPCemu handles the reloading of the start address during the end of vertical total(as it did) on CGA/MDA and when starting vertical retrace on all other adapters(EGA and up).

Having fixed that, the PGAME application behaves properly now.