Reverse Engineering of JETPAC for VIC-20

[D-Type]

In case anyone's interested, I'm in the process of reverse engineering Ultimate's JETPAC for VIC. I was always intrigued how the sprites worked, so 40 years later I thought I'd find out.

I reckon I'm past the point of no return now, perhaps 50% of the way, so I have to finish it. I've spent about 9 months on it so far, an hour here and there.

I'm using dasmfw for disassembly, MAME debugger for single-stepping, Kingswood as65 for assembly, Textpad text editor, Excel for memory mapping & graphics and a tiny bit of Infiltrator for a one-off address label extract.

See it here: https://github.com/phillipeaton/JETPAC_ ... etpacX.a65

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.

[Mike]

Hi!

[...] 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. Chances are that other programs use different methods. 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).

I'm using dasmfw for disassembly, MAME debugger for single-stepping, Kingswood as65 for assembly, Textpad text editor, Excel for memory mapping & graphics and a tiny bit of Infiltrator for a one-off address label extract.

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, as it concerns the use of tools that don't run on the VIC-20 itself.

See it here: https://github.com/phillipeaton/JETPAC_ ... etpacX.a65

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. This not only involves extracting addresses in instruction operands and replacing those with labels. You'll also need to identify position dependent entries in tables and within immediate operands! For example with the four instructions right at the start that initialize the NMI vector to point to $201C, the LDAs would need to reference low- and high-byte from a label (you'd normally use the prefixes "<" and ">" for this).

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. If you do not find all those instances of address constants beforehand, buried within the executable, the program will break upon such changes.

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. In one particular case I did some years ago, I had to re-assign all relevant zero page and OS workspace addresses to new values, to interface correctly to KERNAL, and to not stomp recklessly over memory locations that had been free for that use on the source platform, but not so anymore on the target platform. Quite some extra work, which I saw necessary to do when I back-ported TEDMON from the 264 series to the VIC-20, and which - after a lot of other adjustments, bug fixes and careful enhancements - then became MINIMON.

Greetings,

Michael

[D-Type]

Hi!

[...] 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.

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.

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.

[thegg]

I would recommend 6502bench SourceGen as a disassembler. You can work with it interactively to help with the distinction between code and data. It provides automatic labelling of subroutine calls, jumps and branches. It also allows you to add comments and notes which I found particularly useful.

I successfully used the program to recover a program I wrote many years ago for which I no longer had the source code. I admit I could still recall some elements of how the program was structured, but I was still surprised how quickly I got something I could reassemble.

[D-Type]

I would recommend 6502bench SourceGen as a disassembler. You can work with it interactively to help with the distinction between code and data. It provides automatic labelling of subroutine calls, jumps and branches. It also allows you to add comments and notes which I found particularly useful.

Thanks for the tip. I did look at 6502bench originally, both programs basically do the same thing, I chose dasmfw for various reasons; it's a minimalist command line app, you use your own text editor (e.g. VSCode, although I'm using TextPad) for editing the disassembly control "info" file(s) and viewing the resultant diassembled source code (inc. syntax highlighting), and the options for output code element & output formatting are very customizable.

I tried a few different tools for working out code/data, none were very successful. Then, I used MAME's debugger option to highlight all executed code, you just play the game thoroughly, then one-off manually copy the highlighted executed code section addresses into a dasmfw info file for your binary and you're 98% done, took me maybe 90 minutes. Out of interest, here's the code/data info file for JETPAC, 55 sections of code, anything else is data:

Code: Select all

data     2000-3fff
; ----------------
code     201c-20ad
code     2079-20f2
code     20f7-216a
code     2173-2204
code     220f-22e8
code     22ed-22f7
code     22fc-2313
code     2318-233a
code     235b-2375
code     237a-2384
code     2389-2398
code     239d-23c6
code     23cf-244f
code     2471-2473
code     247e-2483
code     248e-2493
code     249e-24a3
code     24a4-24cc
code     24d4-24d9
code     24e1-24e6
code     24eb-251e
code     259d-2676
code     267c-268b
code     26ae-26c4
code     26cd-2742
code     274f-277a
code     2784-2789
code     278e-2839
code     283e-2869
code     286E-2887
code     2892-2966
code     2975-29f0
code     29f8-29fd
code     2a05-2a14
code     2a1c-2a1e
code     2a45-2a4a
code     2a4f-2a82
code     2a83-2b7e
code     2b8f-2bcc
code     2bd1-2be7
code     2bf8-2cda
code     2ce3-2d4b
code     2d58-2dba
code     2dbf-2E91
code     2e96-2ffb
code     3000-3069
code     306e-3093
code     3098-31b5
code     31bf-346b
code     3470-349c
code     34a1-3511
code     351d-3544
code     355c-355e
code     3569-356e
code     3579-385e

I successfully used the program to recover a program I wrote many years ago for which I no longer had the source code. I admit I could still recall some elements of how the program was structured, but I was still surprised how quickly I got something I could reassemble.

Anything dasmfw creates source code for will immediately reassemble back to an identical binary to the original, even with an empty info file. I expect 6502bench is the same.

[beamrider]

I find this very interesting. Thanks for sharing!

p.s. looking forward to you using it to implement Sabre-Wolf on the 35k Vic

[D-Type]

...p.s. looking forward to you using it to implement Sabre-Wolf on the 35k Vic

Sabre Wulf didn't really cross my mind, but I just looked on YouTube and the usage of sprites is very similar to JETPAC. A conversion would certainly be doable, though the 16x8 pixel colour tiles used in VIC JETPAC would make the backdrops a challenge. SW is one of the very few games I completed when I was a kid, on the C64, armed with a map from C&VG magazine, I think.

But attempting a conversion is a job for someone else, I have too many other projects lined up, sorry!

[D-Type]

I'm still plugging away on this whenever I get a spare minute in the evenings, the end is in sight!

Someone asked me for an intro of how I'm doing the reverse engineering, so I made a little video show 'n' tell.

Any hints and tips to improve my efficiency, much appreciated!

https://youtu.be/exYrwbS1JJg

[D-Type]

My reverse-engineering of JETPAC for the VIC-20 is now complete.

It's been a big learning experience, about the VIC computer itself, the tools and my own motivation and ability.

Check it out if you're interested, see what you think, comments appreciated.

https://github.com/phillipeaton/JETPAC_ ... /tree/main

[Vic20-Ian]

My reverse-engineering of JETPAC for the VIC-20 is now complete.

Well done, it certainly was an excellent game to look into.

JetPac and Star Defence (especially on fast mode) were very impressive and very playable even 40 years later.

JetPac on the Vic20 is much better than on the Spectrum

[Ola H]

I applaud this! I love Vic 20 Jetpac. Few Vic games at the time impressed me as much and it is great to learn just how the flying routine managed to produce such a great feeling and perfect responsiveness.

Thank you for a tremendous contribution to the knowledge of old games!

[Mike]

[T]hat clearly positions this thread into the "Emulation & Cross-Development" section, as it concerns the use of tools that don't run on the VIC-20 itself.

done

[D-Type]

... and it is great to learn just how the flying routine managed to produce such a great feeling and perfect responsiveness.

Thanks for your thoughts. Yes the flying routine is complex, more than I imagined at the start!