VDP Tests

[r57shell]

Thanks for that video.
Sadly those who are not familar with VDP don't understand some things...
This tests made in that way that it requiring some interaction with user. It's not like some of other tests where it does self-diagnostic.

Tests with two rects filled with same colors confirm that VDP output consists of DAC from 4 bit Red, 4 bit Green, 4 Bit Blue, and highlight/shaddow stuff only does some simple arithmetics.

Tests with fast mode-switches should be recorded from screen, not from capture-card. Just because modern capture-cards does same unknown stuff like LCD does. I doubt if any of them does simulate full CRT behavior.

Tests with color ID and sprites stuff... You should know that there at least three "special" color id-s: 0 (transparent), E (shadow, IIRC), F (highlight, IIRC). That's reason why there is control of color id. Maybe I'm wrong and only 3E, 3F does that, but... anyway it does matter. But in your recording you stop at 3 color id, and it does not show cases.
Actually, I was assuming that one who will use this test, will first roll across all color ID's, then change first setting, and roll again, then change first setting into second position, and so on... until all combinations will be tested. And during that, one will do same in some emulator, and compare screens each time, to figure out difference in behavior. Or just somehow record all "testdata". Maybe I could put much more visual data on same screen, to make easier to save all testdata by separate screenshots, but I pick easier way.

[Mask of Destiny]

Tests with fast mode-switches should be recorded from screen, not from capture-card. Just because modern capture-cards does same unknown stuff like LCD does. I doubt if any of them does simulate full CRT behavior.

Even different CRT's will give different results here (as noted by MrTamk1s). I haven't looked in detail at what you're doing, but it's generally quite easy to screw up the duration of a line when you switch modes. As far as I can tell, mode changes don't alter the horizontal counter, just the values that are checked for triggering HSync and the horizontal counter jump. Depending on the counter value when you make the change, the line can either be very close to normal timing or very far off. Different TVs will cope with inconsistent line timing to varying degrees. Generally I would expect the average LCD to be less tolerant than the average CRT, but you're producing a signal that's out of spec so the results are not going to be well defined regardless of the display type.

You should know that there at least three "special" color id-s: 0 (transparent), E (shadow, IIRC), F (highlight, IIRC). That's reason why there is control of color id. Maybe I'm wrong and only 3E, 3F does that,

I don't think I've personally tested this, but Charles MacDonald's VDP documentation mentions that 0E, 1E and 2E don't act as operators but are always shown at normal intensity regardless of priority.

[Sik]

CRTs usually pass the signals straight to the screen though which is why they're more tolerant to weird stuff (while LCDs and recorders somehow have to translate the analog signals into something that can be dumped on a bitmap). How different CRTs cope with this depends on how they handle trying to stabilize after they got the line with the wrong duration (hence making the beam go off mark).

[r57shell]

Even different CRT's will give different results here (as noted by MrTamk1s).

Yea. Best for me would be tests on old crts, which not using digital stuff at all, like overlay display.

I haven't looked in detail at what you're doing, but it's generally quite easy to screw up the duration of a line when you switch modes. As far as I can tell, mode changes don't alter the horizontal counter, just the values that are checked for triggering HSync and the horizontal counter jump.

One of goals is to figure out this behavior. You can belive to what people say, but I would like to be able to test it on my own, so thats why I did this test.

Generally I would expect the average LCD to be less tolerant than the average CRT, but you're producing a signal that's out of spec so the results are not going to be well defined regardless of the display type.

Specs was made for CRTs, so there were idea how it would work even for this "exceptions". I understand how "plain" CRT works, and it's easy to predict how it will behave on certain signal. But what I don't know: what signal producing VDP during that stuff. Best would be just get osciloscope and record whole signal of some frames.

I don't think I've personally tested this, but Charles MacDonald's VDP documentation mentions that 0E, 1E and 2E don't act as operators but are always shown at normal intensity regardless of priority.

Again, ofc I can belive, but also I wanna confirm

CRTs usually pass the signals straight to the screen though which is why they're more tolerant to weird stuff (while LCDs and recorders somehow have to translate the analog signals into something that can be dumped on a bitmap). How different CRTs cope with this depends on how they handle trying to stabilize after they got the line with the wrong duration (hence making the beam go off mark).

Yea, exactly