(WIP) Kale's Mame WipC - The COP Diary #1 - 模擬器

2012.09.14

　　 有進展就算是好消息了。

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
http://0rz.tw/bhDou

n 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 0×582/0×584 (respectively y and x distance between
origin points, i.e. an hexadecimal subtraction) and then the correct
bit assignment for 0×580 (bit 0: collides in Y space, bit 1: collides
in X space, active low). Unknown meaning for 0×586 (it seems always
1?) and 0×588 (that seems a mirror of 0×580 but then it also sets
up bit 2 and 3 for whatever reason).

Test #3 Check 63X
http://0rz.tw/uk9FK

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
http://0rz.tw/gGFmm

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

來源：http://mamedev.emulab.it/kale/?p=1736

--

ポーラステーション
http://perryt0517.wordpress.com/

--