Or digging through unreleased code
So Acidchild of Padua reached out to see if I kept all my all old floppies... yes I kept those ! Probably not in good conditions as they were stored in my shed for at least 15 years but I still have about all my disks. He wanted to have a look so I started the tedious process of dumping the floppies to .D64 files. That was not that simple with my old 1541 which started to show its age. I tried to get my hands on another one but it looks like most of those are sharing an ability to fail quite quickly : I ended up getting a 1541 II in order to be able to make this whole dump process less cumbersome, maybe I'll talk more about that in a later more general note about disks and storage solutions on the C64.
As I was dumping my old dusty floppies I stumbled upon one of the disks we exchanged back in the days with Ludwig, containing some routines that he was working on for our demos alongside with code that was never used.
We discussed the matter with the other members and decided to look if we could make something with this code, maybe use it for a part in one of our next releases (stay tuned, it's almost there)
I started poking around the code and as I expected it, it was obviously an oldschool kind of animal, all written directly into memory using the monitor of some cartridge (I don't remember which one Ludwig was using back in the days, I for one was using an action replay from Datel), without any source code, any label, and barely any planning at all ;)
Nowadays one can expect to have at least code produced by an assembler like 64tass or kickass, usually using a cross development environment, and have a lot of planning done for memory organization (especially if it's a trackmo, not that I haven't done some really dirty things in Anthology... bear with me that was the first time we were using a loader and it was - hum - sort of inserted into the demo when a lot of the code and data was already in. In the countdown animation for example a chunk of the animation frames has been removed to make room for the loader init code and is loaded back just after the init is done. But I digress, back to topic)
Apart from the fact that back in the days we used to code almost everything directly in the monitor, there were some hints that confirm this was the case for this one, like :
-
Various NOPs instructions in some pieces of code, either here to keep some space for future changes but most likely to suppress instructions (like an SEI at the beggining of a routine)
-
The way the code was split into bits starting at strategically spaced addresses : like in a new block ($xx00), in the middle of a block ($xx80), or even using a multiple of 16 bytes ($xx50 for example), sometimes just a little bit ahead from the previous part of the code
-
The way the IRQs change was done by changing only the least significant byte, something that you usually don't optimise when using an assembler, where you'll probably be doing the following, maybe even through a macro :
lda #<my_new_irq
sta $fffe
lda #>my_new_irq
sta $ffff
here we have something like :
lda #$80
sta $fffe
-
The way some code from other demos was imported, and more precisely where it was imported as it was not beeing relocated ;) In this prototype you'll find some line drawing code around $C000 whereas all of the demo code is below $A000
-
The way the code was constantly jumping from places to places, as the init phase was built. For example all the starting process is done this way : starting code is in $9500, where it does some bits, then it goes to $9100 for other inits then to $9000 then to a completely different location around $1100
Those brought back a lot a memories from that time. That was not that fun, you'd have to save your work (slowly) to disk quite often or you'll loose something with a bad memory move. I still have a lot of files on my floppies for work in progress routines that are freezed dumps from my action replay. Sometimes I left some info on the screen (start addres...) before freezing the memory, some other times not, it's going to be fun trying to look back at those (of course all the filenames are meaningless)
I remember that at that time we knew from heart all the instruction set details, from the length of instructions to the precise number of cycles for the execution. When we had a first look at a brand new plotter from Joy with Ludwig, I remember that we teased him by reading out loud his code over his shoulder and providing lots of optimisations tips every other couple of instructions. "look there, you can save 2 cycles", "if you do that you'd save 5 more cycles", "don't do this like that"... that wasn't meant to be mean, we liked a lot to share coding tips and learn back from the others. I remember having endless discussions about data structures with Ozzy and Chocapoc at the Kurgan & Tagada bros headquarters when we were meeting up. We ended up rewriting all the plotter code with two C64s, one monitor and one TV setup, doing pair programming before it was a thing, one reading the code and the other rewriting it on the other setup at the same time.
Kids won't believe how things were done back in the days, with the available tools, lack of documentation not to mention the internet.
We'll be bringing this old piece of code from it's glorious part back in our next release, this kind of dedicated work deserves it, and it was fun trying to wire new code to this effect, even if I had again to do some yoga to fit all of what I wanted into memory.