vcounter corruption

For anything related to VDP (plane, color, sprite, tiles)

Moderators: BigEvilCorporation, Mask of Destiny

Post Reply
notaz
Very interested
Posts: 193
Joined: Mon Feb 04, 2008 11:58 pm
Location: Lithuania

vcounter corruption

Post by notaz » Sun Oct 01, 2017 11:03 pm

I don't remember if this has been reported, but if you read the vcounter at the moment it's changing (presumably?), you'll get a corrupted value. Usually bit1 is set when it shouldn't be, at least on my VA6 MD1. It's very rare, but if you do reads in a tight loop, you'll get up to several bad reads per second. Bad reads are more frequent in H32 mode than in H40. I've seen similar behavior on PSX when reading video related counters too. So if you need an exact vcounter, it seems it's required to read it until you get the same value twice in a row.

Here is a test ROM:
http://notaz.gp2x.de/md/rel/testvc.bin

The test continuously reads vcounter and prints if there is an unexpected jump. Testing on more hardware would be welcome.

Sik
Very interested
Posts: 939
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: vcounter corruption

Post by Sik » Mon Oct 02, 2017 5:36 pm

Same applies to the hcounter, albeit with the big catch that for the horizontal value it's nearly guaranteed to be invalid, because it runs too fast for the 68000 (so absolutely never attempt to look for exact values, the bottom bits are prone to be garbage). We caught that one while working on Overdrive II. Not surprised that it also applies to the vcounter if you read it right during a transition.

Essentially, the HV counter keeps updating completely disregarding any bus accesses being made. The VDP just passes on its internal register directly to the data bus. Any bit that transitions in the middle of a bus access will be garbage.


PS: the reason why you're likely to get a 1 when a bit is invalid is because the bit in question ends up being too noisy and ends up prone to pulling high (similar to what happens when you leave a pin unconnected).
Sik is pronounced as "seek", not as "sick".

Nemesis
Very interested
Posts: 791
Joined: Wed Nov 07, 2007 1:09 am
Location: Sydney, Australia

Re: vcounter corruption

Post by Nemesis » Tue Aug 21, 2018 10:59 pm

I've observed this effect under a logic analyzer. As Sik said, the counter values are updated immediately, even if they're currently being read. You can see the VDP asserting its output lines for a read, then partway through the operation, the lines change state. When this happens, all bets are off. The M68000 will latch some value, but it may be either a 1 or a 0 for any affected lines, depending on how and when it latches the bits. I have a test ROM around somewhere that I wrote, which actually looks for and verifies that various "impossible" counter values actually occur, and in a sensible sequence. It'd be a "good" (IE, evil) thing to integrate into an Overdrive demo or the like.

Nemesis
Very interested
Posts: 791
Joined: Wed Nov 07, 2007 1:09 am
Location: Sydney, Australia

Re: vcounter corruption

Post by Nemesis » Tue Aug 21, 2018 11:02 pm

For the record, Exodus doesn't currently emulate this effect, nor does any other emulator I'd wager. I'd like to add support for this in the future though, because it's actually a very important aspect to be aware of, which can cause surprising failures if you rely on the HV counter value.

Post Reply