The COP Diary #2
#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.
September 25th, 2012 at 12:37 am
Nicely done!