2D layer bitmap corruption

[Bart]

Now, the VROM check is another matter. It always fails.

Ah, Ok! I was a bit vague with my question, infact the CROM never fails on unpatched games, VROM instead (and in some games the "boundary check", which I don't know what's about) fails. Thanks for the explanation.

Boundary scan is a very common way to debug integrated circuits. Special testing circuitry is added to device pins (or really, anywhere inside a chip, but usually on some sort of I/O pins or internal state registers), hence allowing the "boundary" of the chip to be tested by overriding the pins with certain values and then capturing the results elsewhere in the chip (or even on another chip, if one is connected to the other) using the same kind of logic on the other side. The values to drive the signals are shifted in one bit at a time using the JTAG serial protocol. The port that exposes this interface is called the Test Access Port (TAP). I refer to TAP and JTAG interchangeably. The results of the test are also read out serially using the same interface.

This is very specific to the chip being tested and would change from revision to revision. It's normally used for hardware engineers to debug and verify their design. But it can also be used to implement software patches if enough functionality is exposed and a bug in the logic is found after tape-out.

This will probably never be emulated, although if someone is a masochist, they can try to figure it out

Not me... This is the kind of things that usually MAME dev are onto for emulation accuracy, maybe one day it'll be possible to port the code, who knows?

What the VROM test logic is almost certainly doing is using the TAP port to drive pins on the Real3D chips that connect to the VROM. They probably program in specific VROM addresses and then capture what appears on the data bus and shift it back out through the TAP port. This is actually a perfect example of what boundary scan logic is for. The VROM address and data buses are not connected to the PowerPC but they are connected to one or more of the Real3D chips. These chips are JTAG-enabled and so the PowerPC can manipulate their pins directly, sample the values on each one, and then shift the results in and examine them one bit at a time.

The easy way to get the VROM checks to pass would be to detect the test and then shift back the exact values that the game expects. The correct way to do it would be to try to decipher the values and figure out which part of the VROM is being read. This would be very tricky but theoretically doable.

This is probably more than you wanted to know

Also, somewhat related, I've seen that in the last months, if I recall, they've added some network board emulation code for the various Model hardware.

Model 3's network board is very similar to Model 1/2. SailorSat is the expert on this stuff. I would like to discuss with her at some point. Nik actually had it all figured out but he's been too busy to get in touch and I'm not hopeful that I'll ever see the source code. But I will try to ask him for it at some point. Network emulation is tricky because these games used a fiber optic link with a custom protocol that expected to be synchronized frame by frame.

[Ian]

I found Nik on facebook. Sent him a message and a friend request just in case he didn't see that but he never replied. Can't believe he could get so far with network emulation then just never do anything with it

The jtag stuff is interesting, although I don't really know how it works. Is that why the last remaining games don't boot? I had a go at debugging the DX version of sega rally, and as best as I could make it the CPU is waiting on some jtag values, which never arrive.

[HarryTuttle]

This is probably more than you wanted to know

Indeed However it's still interesting.

The easy way to get the VROM checks to pass would be to detect the test and then shift back the exact values that the game expects.

I suppose something similar is done in games.xml, "patches" node, to run SWTrilogy and Sega Rally 2 ?

[Bart]

The ROM patches aren't simulating returned values. They simply patch out the test subroutines altogether by inserting a NOP instruction or changing a conditional branch instruction to a "branch always" instruction that pretends the check succeeded.

Ian: I haven't looked at Sega Rally 2 DX but failure to boot can be due to a large number of things. JTAG is definitely one of them. The solution to that would be to either apply a ROM patch to patch out the offending routine or try to figure out what value is expected. Usually this isn't too hard to do. You just have to figure out where it's reading in the values, then step through the debugger until it gets to a point where it tries to compare a value against some constant. Figuring out how to return this via the JTAG protocol is tricky but I did it way back in 2003 or 2004 for most games and the original code is still there in Real3D.cpp If we know what value the game expects, I could add debug logic to print out what instruction code is loaded via JTAG and how many bits are shifted out. I could then insert the correct output pattern in much the same way the other ones are coded up there.

Other games fail to boot for various other reasons. SWT is trying to communicate with the drive board that controls joystick force feedback, I believe.

[Ian]

Sega rally dx is stuck in a infinite loop at boot waiting in some values. In the debugger I manually override the values to feed it the values it was expecting, and it got further through the game code. Then my brain blew up But I am pretty sure it is jtag related

[Bart]

Stuck in a loop? That's odd because usually the game knows exactly how many bits to read from the JTAG device. Which hardware port is it reading from? If you remember where the loop is, I could have a look. The quick and dirty way is sometimes just to use the step-out command ('so') to move up the call stack and see if you can patch out an entire subroutine. It doesn't always work, though.

[Ian]

I don't know, just load it up and see
Press pause in the debugger and step through a few instructions and you'll see it's stuck in an infinite loop. It's waiting for a value that never arrives (as far as I could make out).

[Bart]

Ok. I patched it. Update your Games.xml from SVN. I don't know what it's doing and don't have time to look into it now but it didn't look TAP-related. It looks like it's writing to a tilegen register and then sits around waiting for something in memory to flip (which in turn must be driven by an IRQ handler or decrementer exception). Very bizarre. Video IRQ related, if I had to guess.

There are multiple places that can be patched to get it to boot. Unfortunately, it runs at half speed (haven't tried with Harry's frame timing fix yet) and there's no music because MPEG ROMs aren't included in the ROM set. I'll bet the game uses the same MPEG ROMs as Sega Rally 2 -- this is probably just a deluxe cabinet version -- but until I see confirmation in MAME or from someone who has dumped this game, I'll leave it as-is.

[Ian]

Well that's quite exciting it boots
Wonder if there are any differences

[Bart]

It's very surprising that something as fundamental as timing works differently. Although I see that patches are also applied to the normal ROM. I forget what those were for but they obviously didn't adversely impact the game play.