At first, everything was obscure and meaningless, I didn't even know what was code and what was data, but at the end of the process every single byte was assigned to a purpose. It was challenging, I had to "enter" the head of the original programmer and see thru his eyes. So I labeled and commented the whole code, giving it a second life! I wonder if the original source code is lost or is in the hands of the original developer or perhaps in the hands of what remains of Commodore ltd.

Well, I just had to share this with someone. Thank you for listening.

And, in case you are wondering, "Raid on fort knox" was the first game I ever played on the Vic20, at the time when I didn't have a tape recorder and a friend borrowed me his cartdrige. It is one my favourite games along with Trout, Paratroopers and 3d silicon fish.

Now I will try to convert it for the unexpanded Vic but I'm not sure because there is just not enough memory left (definable characters waste 2Kram).

Lately, I did the same with a BASIC extension, and a floppy-speeder. Nippur72, you pinned the nail on the head, when you said:

So I labeled and commented the whole code, giving it a second life!

With the re-built source code at hands, one can easily relocate the code, and/or combine it with other programs. IMHO, the most prominent problem is to find "hidden" pointers. For example, when a variable jump is pushed as return address onto the stack, and then executed as RTS.

I've written two C Programs, that - from a disassembly - extract jump-targets within the program's range, and then substitute them with labels. What tools do you use?

I've written two C Programs, that - from a disassembly - extract jump-targets within the program's range, and then substitute them with labels. What tools do you use?

I did that manually. The program had only one indirect jump via the stack, done in a "clean" way--that is reading addresses from a table and pushing in the stack. In that respect it was easy.

The main problem for me was distinguishing between code and data. I used the "da65" disassembler where you can mark each segment as data, code or else. So I start with everything marked as code, iterating the disassembling process until all data is found.

I also have converted the strict 6502 assembler into the "pseudo" assembler I use with my "asmproc" tools (asm with do...whiles and if..thens)

We would love an explication. I've always admired that games smooth motion.

explication about the smooth motion? Well, everything is precalculated and already put in the definable character area. There are two shapes: the "man" and the "guard", each one spanning on two characters when they move, and they can have 4 different movements (cardinal directions). And each of these has 8 different "shift" positions for smooth movement, so in total:

2 x 2 x 4 x 8 = 128 characters

With some other spare shape, definable characters are 2048 bytes and placed at 5120, making it very difficult to convert for the unexpanded vic.

On the 8K ROM there is some space left, and I wonder why they didn't add additional mazes (there are only two and they are very similar).

It would be very easy with your disassembly to create a new version! Maybe even a graphic change or new mazes. You wouldn't have to change any of the routine codes. I think it would be a very fun project!
remember "Coke Wins!" on the Atari 2600?

nippur72 wrote:2) having it run on normal memory expansion (relocated with video at 1024)

I'd just like to remind you, that the VIC-chip can only access internal RAM. So 1024 as address for the screen would be out of the question. Or did you mean 4096 as it's the case for 8K or more expansion?

Ideally you should make the game runnable with LOAD and RUN, i.e. preface it with a line like below: