Spaghetti?

No more porting but I have spent some time on the reverse-engineering.

I've located the player movement (and dig) routines, which I eventually tracked down via the keyboard read call. I'm working through those now and have unearthed a few more crucial variables related to the player tracking throughout the play-field.

It's relatively early days yet, and I reserve the right to retract my statements, but I find some comfort in what I've found so far. Way back some 20+ years ago when I was attempting to write my TRS-80 version, I naively coded the player movement routines by handling each case explicitly in what equated to a rather lengthy case statement. It was classic spaghetti Z80 assembler, and whilst I knew it wasn't elegant, I was too eager to see results to attempt to formulate a more efficient algorithm.

On the surface, that appears to be pretty much how the original code was written. There's a ton of duplicated, cut 'n' paste code related to movement from what I've seen so far; perhaps not as bad as the code I first churned out but certainly nowhere near as elegant as the code that I finally crafted - albeit in its 3rd incarnation - on the PC. At least, it seems to be the case as far as I've gotten at this point.

It's also somewhat reassuring to note that the variables I've managed to identify thus far are heavily used throughout most of the codebase, in fact a surprisingly large percentage of the code seems to be concerned with manipulating these very variables, mostly related to movement (presumably of enemies and the player). If I'm right in assuming the same logic is used for both, then I guess there's little more to the actual game mechanics, other than digging (which should be relatively simple) and enemy AI.

What this suggest is, in stark contrast to a few other projects I've undertaken, that the actual reverse-engineering effort may be relatively straightforward, and somewhat devoid of instances of large sections of code whose functions defy explanation without some serious time & effort and even some guesswork and trial-and-error. That would be nice for a change!

I'll continue with the reverse-engineering for the time being as there are a few aspects of the movement that I'm yet to decipher that would prevent a functional port at this point. But I'm still on a roll and would expect that it won't be too much longer before I can draw a line in the sand and start the implementation of the movement routines.

I'm also sorely tempted to break with tradition and start with the 6809 this time 'round. We'll see...