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

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.

Got some interest in the Nintendo Virtual Boy system, that was a failed portable (?) console experiment. Currently working in improving booting in current driver, so fixing logical stuff like irqs and non-graphic related stuff. After some hours of development here are the results:

I’m currently improving NEC PC-8801 line of computers. There’s a lot of room for improvements (many programs has all kinds of floppy copy protection tricks) but here’s a video for Misty Blue opening, a relatively famous JP-only game by Enix that was recently improved by fixing the graphics in it and properly adding YM2608 sound chip support to the base.