#5/6 Raster A/B test

This test checked if the scrolling registers applies only at DMA time or it’s a post-processing effect, by changing these vregs in the middle of the frame. The oblique shape of the background indicates that it’s a post-processing effect. This also proves that Godzilla has jerky scrolling due of a completely different problem (timing, perhaps?)

#7 Trigonometry Test

This one was a test mostly made for tuning the sine / cosine maths and the scale factor used with it. The only major difference than before is that the scale is a two bits register. It’s hardly noticeable by the naked eye, but now bullet / character speeds are more accurate than before.

#8 Division Test

This one checked the 0x42c2 macro command functionality, but it failed miserably (returned always zero in tests). It indicates that the 0x42c2 command must be used together with the Pythagorean ones for correct functionality. It was re-tested in #12 (see below)

#9 Priority Test

This one checked the video priorities, via a simple “compare one layer with everything else” algorythm. It turned out to be:

(most priority)
– OBJ 0
– TXT
– OBJ 1
– BK3
– OBJ 2
– MBK
– OBJ 3
– LBK
(least priority)
I haven’t yet implemented the scheme into the driver, plus it’s unknown if there isn’t anything nasty like a per-pen priority but we’ll see.

#10 130e/138e test

This one checked the 0x130e/0x138e macro command (Pythagorean Theorem angle calculation). Other than some minor off by one errors (presumably due of rounding issues) and the fact that the execution of this command is mandatory for the correct functionality of 0x3b30/0x42c2 macro commands, there isn’t nothing really new to talk about for this one.

#11 3b30/3bb0 test

This one checked Pythagorean Theorem hypotenuse length command functionality. Again, nothing really new, it’s just the familiar square root(x²+y²) in binary format.

#12 42c2 test

This is where things gets a bit trickery. #8 proved that this macro command must be concatenated with 0x13*e/0x3b*0, so I was really curious to see what this one really does. Rather than being a simple division operation, it’s a multiply/divider of the RAW hypotenuse length result. In medical terms, while 0x3bb0 returns a 16-bit value, this one takes the original value, shifts it to the left (via the scale register) then divides again the result via a RAM parameter. It also changes 0x1b2 register, it returns the number of the scale multiplication factor.

This makes Legionnaire to have less cowardish enemies, even though some movements are still a bit off.

#13 Reg Mirror (Dummy)

This test tried if the COP registers 4-7 are a mirror of 0-3 via a simple read-back (hence the “dummy” name). The test failed (returns garbage in those ports), I’ll try again sooner or later.
It’s important to know this concept in order to understand an unclear fact regarding the COP machine code, i.e. what determines the usage of registers 4-7 in bit terms.

#14 0205 test

While doing this one I’ve studied the preliminary ASM code provided by OG and trap15 documented in the raiden2.c, and something catched my eye: there was a write (work RAM address +0x1c) that is definitely triggered by this, but it never gave noticeable result plus makes Zero Team to crash after some seconds of gameplay/attract mode. After the test run, it was clear that there is definitely an addition between +0x1c and +0x10 work RAMs. The discovery is that it seems to be a dword and not a word operation.

This fixes: Raiden 2 intro (ship objects now scrolls down correctly), Zero Team intro (the scrolling was a bit off before during the bike / van chase) and Seibu Cup Soccer now Kick Offs (although the players then decides that is the right time to make a strike action and leave the poor GK alone). Unfortunately, this also breaks Zero Team gameplay again, but 0.147 was just released so I have some time to understand why it crashes even if the fix is definitely right.

For the four people that lives in Mars, the Seibu COP is one of the most evil system protections ever studied by mankind, and that’s an understatement too. I’m doing some researches thru m68k coding and a working PCB kindly provided by Smitdogg. The researches involves ANYTHING unclear, and more I go ahead and more I do believe that the games doesn’t even reach the 10% of the possible potential of the system.
So, here’s the results and my speculations of the currently done tests:

Test #1/2 Manual Collision Check / Automatic Collision Check

An hit-box is a well known basic concept of gaming. For people that doesn’t know, every single object has an invisible shape (generally a rectangle for 2d) that defines its collision space.
Some macro commands in COP basically calculates the hit-box for two given objects. My previous attempts of HLE this concept failed miserably, and needed 7 videos from Smitty and various mods to understand that what I was taking as a collision detection parameter is actually a relative address to ANOTHER table, that’s positioned after the old table. Implementing this gave way better collision detections to every single game of the system. It’s still not 100% perfect, but my plan is to modify the manual test in order to return & modify this relative value on the fly.
These tests also provided the meaning of 0x582/0x584 (respectively y and x distance between origin points, i.e. an hexadecimal subtraction) and then the correct bit assignment for 0x580 (bit 0: collides in Y space, bit 1: collides in X space, active low). Unknown meaning for 0x586 (it seems always 1?) and 0x588 (that seems a mirror of 0x580 but then it also sets up bit 2 and 3 for whatever reason).

Test #3 Check 63X

The 0x***62e-0x***63f range is a bit weird, is modified from time to time by Godzilla so for a moment I’ve thought that was a clipping effect register for the tilemaps. The test instead proves that these are just alternative scrolling registers, setted up in a way that presumably puts the tilemap origin at whatever top-left corner the CRTC sets up. Now, the question is: why having TWO scrolling registers? Is it a weird design choice or there’s a definite difference between writing one or another register? The upcoming Raster A/B test should answer to this question.

Test #4 PDMA test

This test was specific to SD Gundam: according to a real PCB video that floats around the net, we are doing a full fade in/out when it should actually fade only some layers. The table used is a bit weird, and I’ve tried to upload the same thing to a different board (that is Legionnaire). The result? It does what is supposed to do even on real HW, so the prime suspect is that SD Gundam sets (either in SW or in HW) that specific area of the RAM in an encrypted fashion, also proved by the fact that it doesn’t test it at POST and having Denjin Makai that basically does the same.

Hooked up TC0091LVC to Fruit Dream driver, and after a bunch of silly bug-fixes, here’s the results:

Started working on Last Bank, that is a TC0091LVC-based bike gambler HW with many (not every) resemblances to Taito L HW. Basic graphics and inputs are hooked, but most charset (tiles and sprites) are missing for unknown reasons (bad dump?) …

EDIT (21-Jul-2012): Smitdogg provided an overlooked gfx ROM, and I’ve implemented almost every single feature missing from the new TC0091LVC device core (that will be ported to Taito L system at some point as well):

Thanks also goes to Haze that helped me with a gfx decoding issue that I was encountering on the device-ization process.

hap and me emulated Flipper Jack, a rather unknown pinball game by Jackson with unique HW.

Colors are quite off, needs some reference to get them right.