Posts

Showing posts from May, 2021

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. 

MAME debug

Image
 When it comes to understanding the code, we could just run the ROM files which contain code through a disassembler and try to read it, but it's easier if we can follow the code while it is executing instead of just reading it. That's one thing debuggers can do.  Luckily MAME already has a built-in debugger that can do that. You just need to invoke it with the -debug command line option, so  mame.exe shinobi -debug At the command line is enough. It will open the game and a debugger window, like this:  In the debug window you can see the register values on the left, a disassemble of the code at the center top panel, and the command window on the bottom right corner. The debugger includes the usual functions like execute the code instruction by instruction, set breakpoints, examine memory locations, and so on.  Though it's hard to analyze the code just by watching it execute on a debugger. Typically there are thousands of instructions executed for each frame , so it's har

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 ( 7 df7f4a2 ) SHA1 ( 86 ac00a3a8ecc1a7fcb00533ea12a6cb6d59089b ) ) ROM_LOAD16_BYTE ( "epr-12008.26" , 0x000001 , 0x10000 , CRC ( f5ae64cd ) SHA1 ( 33 c9f25fcaff80b03d074d9d44d94976162411bf ) ) ROM_LOAD16_BYTE ( "epr-12011.42" , 0x020000 , 0x10000 , CRC ( 9 d46e707 ) SHA1 ( 37 ab25b3b37365c9f45837bfb6ec80652691dd4c ) ) // == epr-11283 ROM_LOAD16_BYTE ( "epr-12009.25" , 0x020001 , 0x10000 , CRC ( 7961 d07e ) SHA1 ( 38 cbdab35f901532c0ad99ad0083513abd2ff182 ) ) // == epr-11281 ROM_REGION ( 0x30000 , "gfx1" , 0 ) // tiles ROM_LOAD ( "epr-11264.95" , 0x00

Intro

So this is about Understanding Shinobi, the Sega System 16 arcade game. It's mostly an exploration or exercise, nowadays you can play the game as it was in the arcades in multiple ways (emulation, versions for Nintendo Switch, Wii etc). But by understanding it we may port it to older platforms with some degree of fidelity.  The main things we are trying to understand are: How to extract the original artwork from the ROM dump Having the exact code for movement, enemy behavior etc., so it can be ported with high fidelity and without guesswork The first one does not seem too hard, the second requires analyzing the original M68k code to try to get to the specific subroutines. This can be a lot of work or it can be made easier if good tools are available. This is still to be determined.