Aaron Giles 069747cca3 From: David Haywood ... Subject: Shogun Warriors / BRAP Boys Aaron / Kale, I got a private request to take a look at these, and made a few discoveries about the external protection data rom. Basically it's a 'linked list' of encrypted tables and command types / modes. The encryption is pretty straightforward, although working out the tables could be tricky. It also has an 'inline table' mode, but it's only used for a few tables. There is a large 0x1000 block at the end of all the data which could be related to the normal tables. I've added some rather verbose code to process the rom, and dump out some data, so that if somebody wants to look at it further they can. Understanding how it works properly before decapping it would help to verify and implement the proper emulation of the device later. (the actual protection device is a completely unemulated cpu type, so could prove tricky even with results) I don't fully understand all the parameters at the moment, although I suspect that with this newfound knowledge getting the game(s) up and running would only take a few trojans to figure out the behaviors that aren't understood, and get the decryption tables (which could be time consuming otherwise) The previous implementation of the protection simulation was also wrong, it copies the first 'block' of data (worked out at the time with a trojan) upon the first mcu command (0xff) but infact, it shouldn't be transfered at that point, as the command containing the number of the table to transfer (0x19 in the list) comes later. The game seems to provide lists of transfer operations to perform, I suspect some are direct, and some are indirect. I've also added code to calculate the CRC of the protection rom, rather than hard coding it. I haven't yet moved the decrypted startup code out of the driver, which should be possible as we can correctly copy that from the external rom using the command system at this point. I know Andreas was looking at this in the past, so this new information might be of interest to him, as it provides clearer blocks of encrypted data, and the 0x1000 block at the end might be of interest to him if it relates in some way to the smaller 0x40 byte tables used for decrypting the data.		2009-06-18 03:53:38 +00:00
docs	Crosshair update	2009-03-28 22:55:34 +00:00
src	From: David Haywood	2009-06-18 03:53:38 +00:00
.gitattributes	From: Atari Ace [mailto:atari_ace@verizon.net]	2009-06-08 06:24:21 +00:00
makefile	CPU cores are now enabled on a per cpu core family basis instead of per cpu core variant. As a result CPUDEFS is no longer needed in the makefile.	2009-03-25 19:39:41 +00:00