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

Popular posts from this blog

How many instructions per frame?

Reference on D88 disk image format