An optional bootloader. If you don't want to program EPROMs each time, you can build a nifty interface to send your code directly to the original hardware.

Here are some example programs that Alex has coded to demonstrate what you can easily achieve. The source code to these programs is included in the package.

There are plenty of cool uses for this SDK. On a basic level it could be used for the creation of test programs to debug and fix original boardsets. Alternatively, you could even use it to create an entirely new game! Whilst you'd lose some performance and memory by coding in C or C++ as opposed to pure 68k assembler, you'd gain the ability to swiftly create and debug code and port existing software.

I cannot express enough the shock i experienced when i found out your blog which describes what you did with one of my favorite games. I have studied computer science, and i can feel how intensely difficult this project was. Understanding thousands of assembly lines, and ALSO porting the logic to C/C++ - plus enhancements - is a major challenge even for the most advanced programmer. Well done!Regarding this, I have a question for you which i believe that you can help with your answer as i would like to experiment myself with a mame game in my free time. Could it be possible to use snowman for ida which produces directly C code instead of starting the work from assembly level? If this is achievable do you believe that starting with the generated C code would accelerate the porting ?

I've no personal experience with Snowman. Personally, I think it could make understanding the original code more complex, as it adds an additional layer of obfuscation. Working from the original assembler means that you're pretty much viewing the code as written by the developers. I would be concerned automated tooling may introduce further bugs.

Once you have the code documented, converting it to C is relatively easy and facilitates your understanding of the codebase.