Mike wrote: ↑Tue Feb 21, 2023 10:35 am
Hi!
D-Type wrote:[...] JETPAC for VIC. I was always intrigued how the sprites worked, so 40 years later I thought I'd find out.
If you follow through that, let me tell you: you quite possibly find only one particular implementation of smooth moving objects on the VIC-20. One that has been tailored to the needs of the game. [...] Unlike to today's approaches, where such functions are encapsulated in a library with a well defined interface, it will be a challenge in itself to identify all related code up to the point that you could even 'lift' it from JETPAC for your own use (which I then would call one aspect of a successful Reverse Engineering attempt).
Thanks for your thoughts, Mike, some good topics to consider!
Yes, VIC-20 JETPAC is certainly a bit of a one-off, it has chunky single colour object sprites like the Spectrum version, more so because of the reduced VIC resoultion, but sadly that was the end of the line for ULTIMATE's VIC output.
The object sprites and the associated game engine I think are very well done, the object handler that manages the drawing seems well defined to me, I don't think it would be too difficult to repurpose the game engine. Knowing what I do now, other ULTIMATE games of the time would probably port across quite easily, PSSST for example looks pretty similar, they almost certainly used the same game engine.
What's impressive to me is the sprites can be any number of pixels in height and any number of characters width and colour tile mapping as also supported. Jetman is updated on interrupt, so he's always smooth.
Mike wrote: ↑Tue Feb 21, 2023 10:35 am
I'm using dasmfw for disassembly, MAME debugger for single-stepping, Kingswood as65...
If the main aspect of the thread is about how one might use these tools, that clearly positions this thread into the "Emulation & Cross-Development" section...
I wasn't sure where to put it, I guess I guessed wrongly. Happy for you to move it, I don't think I'm able to.
Mike wrote: ↑Tue Feb 21, 2023 10:35 am
D-Type wrote:This is the first reverse engineering work I've done (pretty much) and first work on 6502 since I played with it as a kid, so any comments on improvements are welcome.
One other aspect of successful reverse engineering is, that the code ideally should become relocatible...
That is not only important if you just wanted to move the program as whole, but also if you wanted to change parts of it by replacing code sections with other code sections of different size....
Another aspect is successful identification of data and storage usage outside the executable. This is especially important when there are any plans to port the program, game or tool to another platform - even if it uses the same CPU...
Apparently
"Premature optimization is the root of all evil". Spending all this time reverse engineering is crazy enough, I'll leave making the code relocatable as an excercise for the next person! Actually, there are only 5 or 10 places in the code where there are hardcoded values, otherwise everything is labelled or equ'd.
Regarding adding to the code, the games fits into an 8kB RAM expansion almost exactly, which is probably why they stripped out half of the rocket ships of the Spectrum version (two instead of four) and half the aliens (four instead of eight). I might consider add those missing parts back in for VIC-20 and, if I did, I'd add another 8kB of RAM, slot the new code in where it makes sense and then shift the remaining code up in memory by 8kB, taking care to leave things on the same $1000 boundaries where possible to reduce issues.
I reckon I know where all the data and code sections are, including those outside the game image. I ran the game in MAME and it can highlight all code that's executed, that finds maybe 98% of the executable code for you, the edge cases you come across during disassembly and can see in a MAME debugger memory view.
Any other tips regarding the ideas to structure disassembled code itself, name variables, tools that could assist etc., I'm happy to hear about.