Adjusting my point of reference, and all becomes clear.

I have been scratching my head over the logic implemented in the routines that calculate object intersection for some time now, and it is the reason they remained unnamed until now, despite the fact that I knew their purpose. I had assumed all along, for no good reason and without giving it further thought, that an object's (x,y) position in 3D space was defined by the location of the corner closest to the origin, and the width and depth were the dimensions along the X and Y axis respectively. It occurred to me today however (whilst not even at the computer), that the position could instead be the center of the object, with the width and depth being the X and Y radii respectively. Looking at the aforementioned routines in a new light, the logic became obvious. Doh!

All variables and bit fields (flags) have been decoded and documented. All routines (with the exception of Z-ordering) have been documented. I now have stubs for all of the audio routines in the C port, but have not implemented any audio logic as of yet. IOW the entire program, again with the exception of Z-ordering, has now been reverse-engineered!

I do know of one bug in my C port that causes special objects to re-appear after you've picked them up whenever you re-enter the room. I'm hoping that's the same bug that I saw last week when picking up a special object that caused Sabreman to fall through the floor indefinitely!?!

Next task though is to reverse-engineer the Z-order algorithm and port it to C. I suspect the maths will be quite simple, it'll be the recursion that will be trickier to unravel and port to C.

Speaking of which, the code lends itself to a C implementation remarkably well. In fact there are only two (2) cases when stacks are adjusted and JP is used to jump to code elsewhere - exiting a screen and ending the game. As it stands I've used setjmp/longjmp in an attempt to preserve the implementation, but I have 2 issues with this. Whilst the exit screen case works fine, for some reason I can't fathom the end game case crashes. But more significantly, some development platforms (eg. Neo Geo) don't actually have implementations of setjmp/longjmp. So I'll need to find a work-around soon.

MUST. IGNORE. TRS-80. GRAFYX. SOLUTION. PORT...