No brute force for Kong?

I've been pressing ahead with the disassembly during my lunchtimes and evenings, where possible. Right now I've completed the bulk of the non-game-play portions of the code, which includes the initialisation, title and coin-screens, and the high-level program flow. I'd estimate about 25% code coverage so far, which perhaps sounds less advanced than it is, considering a lot of the data areas have been identified. These data areas appear all throughout the non-commented portions of the ROM code, giving valuable time-saving clues to their function. There's also a fair amount of drawing and animating code that has yet to be commented, which should prove more tedious and time-consuming than technically challenging.

I have to say that the code is rather well structured, and obviously well thought-out. After initialisation, the main foreground loop is responsible for mundane tasks like checking bonuses and updating scores, whilst the rest of the main logic is scheduled from the 60Hz (VBLANK) NMI. Here the inputs are read, sprites and sounds updated, and the rest of the logic dispatched via a hierarchy of function vector tables, not unlike Pacman.

The hardware is also funky; two (2) banks of up to 128 sprites (a total of 16 per scan-line) whose registers are DMA'd from CPU memory space every NMI. Not unexpectedly, Donkey Kong only uses a handful of those sprites.

As I become more familiar with the code, I'm now considering re-thinking my approach to a 68K port. A brute-force, line-by-line translation would not only be mind-numbingly tedious and error-prone, but I'm starting to think also unnecessary! Previously I was worried about implementing portions of code that weren't understood, and whose side-effects were unknown, but now I'm thinking that those incidences will be kept to an absolute minimum.

It also tends to negate the need to maintain a side-by-side Z80-68K ASM listing. I would retain the overall architecture whilst organising the code and data in the same sequence as the original Z80 code, but in a separate file. Perhaps a little more cumbersome during development, but ultimately more flexible in the long-run. For instance, it would be easier to start implementation before 100% completion of the disassembly - for example right now I could code the attract screens without the game-play portion (and I may do just that) - and easier to patch functions and/or modify program flow for debugging/development.

The end result would be cleaner, more native 68K code, and easier to maintain. I would also strive to separate the Neo Geo hardware aspects of the code, facilitating easier porting to other 68K-based platforms, such as the Amiga.

All still pie-in-the-sky atm, but I firmly believe completely achievable!