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/ --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 118.168.21.3 ※ 編輯: conpo 來自: 118.168.21.3 (09/14 11:45)