Interleaved ROM layout in Shinobi
There was something in the Shinobi ROM Layout (from the MAME sources) that I found intriguing. I'll repeat here just the layout for the 68000 code:
ROM_REGION( 0x40000, "maincpu", 0 ) // 68000 code ROM_LOAD16_BYTE( "epr-12010.43", 0x000000, 0x10000, CRC(7df7f4a2) SHA1(86ac00a3a8ecc1a7fcb00533ea12a6cb6d59089b) ) ROM_LOAD16_BYTE( "epr-12008.26", 0x000001, 0x10000, CRC(f5ae64cd) SHA1(33c9f25fcaff80b03d074d9d44d94976162411bf) ) ROM_LOAD16_BYTE( "epr-12011.42", 0x020000, 0x10000, CRC(9d46e707) SHA1(37ab25b3b37365c9f45837bfb6ec80652691dd4c) ) // == epr-11283 ROM_LOAD16_BYTE( "epr-12009.25", 0x020001, 0x10000, CRC(7961d07e) SHA1(38cbdab35f901532c0ad99ad0083513abd2ff182) ) // == epr-11281
The first block of 64kb is put at offset 0, but the second 64kb block is set at offset 1. The same happens with the other two blocks, which are placed at offset 0x20000 and 0x20001. At first sight, I thought the blocks would overlap and it made no sense.
What actually happens is that the bytes from each pair of blocks are interleaved. It's likely the memory chips have only 8 pins for output, while the 68000 is a 16-bit CPU. So, to form each 16-bit word, the bytes were stored interleaved in two 64kb chips. This was probably faster than storing the bytes sequentially in the two chips, while keeping the cost low (memory chips with 16 output pins would cost more).
This means that in order to disassemble and analyze the code, we have to create a single binary interleaving the contents of the two blocks at 0, and then adding the interleaved contents of the two blocks at 0x20000. Easy enough to do, but trying to analyze the code without doing it would not be fun.
Comments
Post a Comment