The author has previously seemed rather childishly perturbed that, when examining the demo Planet Invasion a few posts ago, your correspondent didn’t “give a flowchart or list even one Machine Code/Assembly Language, or Commodore BASIC V2 instruction showing how this demo was programmed”. Your correspondent doesn’t feel any need whatsoever to pander to the author of course – it really wouldn’t be worth the effort on anybody’s part – but did find himself wondering about how interesting it would be to take things just a little further… and, since C64CD has a shiny new Github account, there’s no need to stop at mere snippets of code!
So instead we have Clone Invasion, a new demo for the C64, which started as a reasonably accurate copy of the Harlow Cracking Service’s program and… [ahem] grew a little! It was put together from scratch in a leisurely twelve-ish hours by your correspondent over the course of a day off work. The source and binary files required to assemble the working program (apart from the ACME cross assembler and Exomiser file compression tool which are called from the build.bat script) are all available from the relevant Github repository along with some of the workfiles; the character set and sprite files were put together with Char Pad 1.0 and Sprite Pad 1.8.1 respectively.
This little demo takes just over 16K of memory uncompressed and runs entirely from raster interrupts which are triggered at five positions during each frame – there are constants at the top of the code called raster_1_pos and so on which govern these positions – so, since those are where the meat of the code lies, here’s a quick summary of what each interrupt routine does:
This is the first interrupt at raster position $00; it sets up the border and screen colours, points the VIC-II towards the character set at $2000 and then positions the hardware sprites for the upper border’s scrolling message – some of the registers like sprite X position, colour, expansion and so forth aren’t set here because the values are the same as set by IRQ_ROUT6 so, since the border won’t be open until the second frame anyway, it’s more efficient not to bother.
The code then settles into a forty scanline high loop, writing one byte of character data per scanline to the “ghostbyte” (the last byte of the current video bank) for the first layer of parallax scrolling; this finishes on scanline $31 where the screen colour is changed and the first row of hardware sprites for the main screen are positioned.
One feature to watch out for in this and the other three routines dealing with the sprites within the main screen area is that there’s some indirection happening; the sprite data pointers and colours are stored in an eight byte table and any instance of an object is reading the same byte for data pointer and colour as the others. This is a bit trickier than merely having thirty two bytes of data pointers and colours but makes updating the objects faster.
This interrupt occurs at raster position $58 and, along with moving the hardware sprites down for the second row (as well as changing their data pointers and colours), it also calls the music routine – the positions for this and the next split have been widened to leave some extra space for the music driver.
The next stop is scanline $9c where the positioning for the third row of hardware sprites happens, followed by the code to update the scrolling message and, where needed, fetch a new character from the text.
This is the final hardware sprite positioning split for the main screen and is triggered at raster line $c8 – once this is done the sprite animations and positions of the four roaming sprites are all updated.
Finally we get to the final interrupt at raster line $ee which shifts the sprites for the lower border scroller and then waits until the end of the screen to “trick” the C64 into not closing its lower and then upper borders. After that there’s a second loop hammering at the “ghostbyte” (which also rather sneakily updates the data it uses so the area is ready for the next frame) and, since the screen has finished when that loop is done, the definitions of the three characters being used for the on screen parallax effect can be updated as well.
The program itself isn’t particularly complex, doesn’t rely on any “naughty” self-modifying code (which is usually something of a “trademark” in your correspondent’s work) and features significantly more documentation in the comments than your correspondent would usually provide, but it still requires at least a basic working knowledge of the C64’s video registers or at least the C64 Programmer’s Reference Guide open at appendix G to be understood. Generally speaking, this shouldn’t be considered as something for a beginner to learn from and there are some parts which are probably somewhat “quirky” despite attempts to sanitise everything for public consumption, but your correspondent is happy to answer questions that may arise!
 And the odds of a flowchart appearing for anything other than “comedic effect” on this blog are so infinitesimally small that most computers simply don’t deal with that many decimal places.