ROM layout

 A good source of information about the arcade game is MAME. From the sources we can get a big-picture view of the contents of the ROM (this is from mame/drivers/segas16a.cpp):

ROM_START( shinobi )
	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

	ROM_REGION( 0x30000, "gfx1", 0 ) // tiles
	ROM_LOAD( "epr-11264.95", 0x00000, 0x10000, CRC(46627e7d) SHA1(66bb5b22a2100e7b9df303007a837bc2d52cf7ba) )
	ROM_LOAD( "epr-11265.94", 0x10000, 0x10000, CRC(87d0f321) SHA1(885b38eaff2dcaeab4eeaa20cc8a2885d520abd6) )
	ROM_LOAD( "epr-11266.93", 0x20000, 0x10000, CRC(efb4af87) SHA1(0b8a905023e1bc808fd2b1c3cfa3778cde79e659) )

	ROM_REGION16_BE( 0x080000, "sprites", 0 ) // sprites
	ROM_LOAD16_BYTE( "epr-11290.10", 0x00001, 0x08000, CRC(611f413a) SHA1(180f83216e2dfbfd77b0fb3be83c3042954d12df) )
	ROM_CONTINUE(                    0x40001, 0x08000 )
	ROM_LOAD16_BYTE( "epr-11294.11", 0x00000, 0x08000, CRC(5eb00fc1) SHA1(97e02eee74f61fabcad2a9e24f1868cafaac1d51) )
	ROM_CONTINUE(                    0x40000, 0x08000 )
	ROM_LOAD16_BYTE( "epr-11291.17", 0x10001, 0x08000, CRC(3c0797c0) SHA1(df18c7987281bd9379026c6cf7f96f6ae49fd7f9) )
	ROM_CONTINUE(                    0x50001, 0x08000 )
	ROM_LOAD16_BYTE( "epr-11295.18", 0x10000, 0x08000, CRC(25307ef8) SHA1(91ffbe436f80d583524ee113a8b7c0cf5d8ab286) )
	ROM_CONTINUE(                    0x50000, 0x08000 )
	ROM_LOAD16_BYTE( "epr-11292.23", 0x20001, 0x08000, CRC(c29ac34e) SHA1(b5e9b8c3233a7d6797f91531a0d9123febcf1660) )
	ROM_CONTINUE(                    0x60001, 0x08000 )
	ROM_LOAD16_BYTE( "epr-11296.24", 0x20000, 0x08000, CRC(04a437f8) SHA1(ea5fed64443236e3404fab243761e60e2e48c84c) )
	ROM_CONTINUE(                    0x60000, 0x08000 )
	ROM_LOAD16_BYTE( "epr-11293.29", 0x30001, 0x08000, CRC(41f41063) SHA1(5cc461e9738dddf9eea06831fce3702d94674163) )
	ROM_CONTINUE(                    0x70001, 0x08000 )
	ROM_LOAD16_BYTE( "epr-11297.30", 0x30000, 0x08000, CRC(b6e1fd72) SHA1(eb86e4bf880bd1a1d9bcab3f2f2e917bcaa06172) )
	ROM_CONTINUE(                    0x70000, 0x08000 )

	ROM_REGION( 0x20000, "soundcpu", 0 ) // sound CPU
	ROM_LOAD( "epr-11267.12", 0x0000, 0x8000, CRC(dd50b745) SHA1(52e1977569d3713ad864d607170c9a61cd059a65) )

	ROM_REGION( 0x1000, "n7751", 0 )      // 4k for 7751 onboard ROM
	ROM_LOAD( "7751.bin",     0x0000, 0x0400, CRC(6a9534fc) SHA1(67ad94674db5c2aab75785668f610f6f4eccd158) ) // 7751 - U34

	ROM_REGION( 0x08000, "n7751data", 0 ) // 7751 sound data
	ROM_LOAD( "epr-11268.1",  0x0000, 0x8000, CRC(6d7966da) SHA1(90f55a99f784c21d7c135e630f4e8b1d4d043d66) )
ROM_END

From this we already know which files contain code (epr-12*), which ones contain tilesets (epr-11264, epr-11265 and epr-11266) and which ones contain sprite sets (epr-11290 to epr-11297). 

The graphics files probably contain just the raw pixel data in the format expected by the graphics chips on the board. A quick search about the Sega System 16 technical specs (e.g. here is the Sega Retro page about the board) reveals that the board uses 16 bits per pixel with 5 bits per component (R, G and B) and 1 bit for highlight/shadow. So the only information missing to extract the tilesets and sprite sets from the dump is how the pixels are organized (how many pixels per line, how many lines, etc.). This information can probably be obtained by further studying the MAME sources, especially the implementation of the graphics chips. Alternatively, the M68k sources also contain this kind of information, but it's harder to read. 

And maybe it's not that straightforward, because the hardware can only show a limited number of colors on the screen at the same time. So it's likely that the tiles and sprites reference a color map or palette. Even then, it shouldn't be too much trouble to sort it out. 

Comments

Post a Comment

Popular posts from this blog

How many instructions per frame?

 To get an idea of the complexity of code executing during one frame of the game, we can calculate an estimate of how many instructions are executed for each frame.  The main CPU is the Motorola 68000 running at a 10MHz clock. 10MHz means each clock cycle takes 100 ns or 0.1μs. The game runs at 60Hz or 60 frames per second so each frame takes 16.6667ms. So in each frame there are 166,667 cycles.  The M68k is a CISC processor and its simplest instructions take 4 cycles, but there are instructions that take more. An upper bound to the number of instructions executed per frame is thus 166,667 / 4 = 41,666.75 or just about 42 thousand instructions per frame. The real number varies per frame depending on the mix of instructions that are executed on it, and it probably never reaches this value of 42k instructions per frame because you don't expect to execute only instructions of 4 cycles, but something in the order of tens of thousands of instructions per frame seems right. 
Read more

Reference on D88 disk image format

 To investigate what code gets executed when a disk is loaded in one of the Japanese computers, we can investigate the contents of the disk image. Disk images for many Japanese computers are often distributed in the D88 format. Luckily it is a simple format and there's a reference about it in English here: https://www.z88dk.org/tools/x1/XBrowser_User_Guide.pdf Look in Appendix II. It is a reference to a tool intended for Sharp X1 users, but the format is the same used in PC88 and other Japanese computer emulators and tools.  The information is organized by tracks and then by sectors, as in a real disk. File header The file begins with a header with the following fields: struct header { char[17] name; // image name, usually empty u8[9] reserved; // reserved, usually zero u8 write_protect; // non-zero value means write-protected disk u8 media_type; // 0: 2D, 0x10: 2DD, 0x20: 2HD, 0x30: 1D, 0x40: 1DD u32 disk_size; //
Read more