Archive for the ‘Seibu COP’ Category

The COP Diary #1

Thursday, September 13th, 2012

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.


By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close