Fixed scenery walking enemies in Legionnaire and Heated Barrel, they both uses a variation of the 138e macro where last opcode is an addition instead of a subtraction.
This translates in angles being Y inverted, and the macro is effectively used by enemies to check out playfield boundaries.

Both games can be assumed working at this point.

Fixed sprite to tile priorities in Legionnaire, Heated Barrel, Godzilla and Denjin Makai.
Following is a specific comparison example between old and new implementation in Denjin Makai.

Other most notably fixes are the so far hidden Game Over screen in Legionnaire …

… and the clipping used by the opening in Godzilla.

Over the past week, me and Olivier Galibert ironed out several issues in the Seibu COP simulation. This includes Zero Team not crashing anymore and this one happening …

… and yes, this one means that both Raiden 2 and Raiden DX are now (almost?) working. I have doubts especially towards DX just because I haven’t yet checked out if beating properly Alpha Stage doesn’t have issues (and yes, it’s amusing having this kind of doubt now, compared to just one week ago).

#15 Advanced Hit Test

With this we tried to understand better the collision detection, by repeately poll the collision ports but it didn’t gave reasonable results. Amusingly, if you don’t clear the unused data of the collision table it will give complete garbage.

#16 Purple Laser Test

a.k.a. test for 0x6200 COP macro, used by various games to calculate angle direction according to a fixed function.  This is used by Raiden 2 purple laser, chopper (first enemies ) facing direction, SD Gundam homing weapon and 3rd level mid-boss direction (and probably others too). We now do know that the algo does some corrections to the result in particular circumstances, discovering what these are is the next goal.
#17 Ext Pin Test

In Legionnaire program code there’s a weird r/w access to an i/o port in range 0x700-0x7ff while polling bit 13 of the external port (0x470), then it puts the results of this weird read to some work RAM addresses that are never readed-back by the program itself. We tried to read the contents of this while doing the exact same thing as Legionnaire, but it just returned 0xffff. So it’s very likely to be a development left-over (either debugging device or a feature of the game that was discarded at some point).

#18 OBJ Y Test

This tested video register 0x644. The test confirmed that is a simple Y base register for sprites.

#19 0905/0904/0903/0902/0985/0984 Test

This checked the simplest macro (the 0x905, aka read to work RAM address X, add with RAM address Y, write the result to RAM address Z) and tried various combinations of it. 0x905 behaves normally, 0x904 (used in Zero Team and X Se Dae) definitely does a subtraction instead of an addition, 0x903/0x902 doesn’t do anything and 0x985/0x984 behaves like 0x905/0x904, respectively.
There’s a new theory, where the COP trigger is masked with a ~0x281 value when it executes commands at 0x50x, to define what COP macro should be executed (and also explains why Seibu Cup Soccer tries to execute 0xe18e, that isn’t in the uploaded table at all).

#20 DDE5 Test

This is used by the radar in Seibu Cup Soccer, but what we do know about it is completely wrong, so it doesn’t return any result in there. It doesn’t help that we still don’t have a proper way to access COP registers that are above 3 (see also test #13).

#21 DMA 14/15 Test

This checked if the DMA is really a burst one (-> halts main CPU and takes complete control over the system). The algo is:

enable both DMAs (14/15)
\-resync to v-blank
\-set the vblank flag to 1
\-increment a variable by one, and check if vblank goes to 0, if not rinse and repeat.
\-Put the variable buffer to screen
Disable DMA 14, enable 15
\-(do the above again)
Enable DMA 14, disable 15
\-(do the above again)
Disable both DMAs (14/15)
\-(do the above again)

Disregard the snapshot, timings with this algo are: 0xaa1/0xaa2 for first test, 0xafb for second, 0xac6 for third and 0b1f for fourth. So the test confirmed that the DMA is really a burst one, and also that the original PCB is slighlty slower than emulation in “idle” mode (either refresh rate or waitstates). Next step is to extract the exact timings out of the DMA.

#22 680 Test

This test tried to check out what’s the meaning of writing to port 0x680 (that is done at irq routine by all games). I’ve expected a full stop of the operations (so that is an irq ack) or a jumpy sprite movement (so that is a sprite buffer copy). It’s neither of those, fun.

#23 COP R/W Test/COP Read Test/Bogus R/W Test/Bogus RAM Test

This one tries to r/w the COP ports (0x100400-0x1005ff). System locks up if there’s an attempt to write at 0x100430 for whatever reason. Every other register prior to that seems to be read-backable.
With Bogus RAM test, it tries to check out RAM addresses 0x100000-0x1003ff. It’s a normal RAM.
With the Read tests instead, we tried to only do a read to these addresses, and we did two discoveries. A) default RAM pattern seems to be:

if((ram_addr & 0x20) == 0x20)
return 0x4141
else
return 0x0f0f

B) none of the 0x5** COP registers have default RAM values (returns either 0xffff or default state values), while all of the 0x4** all returns 0x4141 / 0x0f0f except to where I’ve did mods for the correct functioning of the system (so it returns back last value I’ve written in there).

#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.