Last week I was looking back at my intro collection Backlog and there was some method to my madness – most of the time there isn’t and it’s literally just madness – because at the time of writing I already had Femtotro pretty much completed. This new CSDb Intro Creation Competition entry is based on the small Babygang intro included within Backlog and, as with that 1991 release, my intention here was to keep things small. To that end the custom character set, some of the sprite definitions and chunks of data used by the code are being decompressed into the screen RAM and then hidden by changing the attributes for those areas so they match the background colour.
The result is, after some rather unceremonious hacking at 4-Mat’s music with the excellent Regenerator to relocate its work space down memory, an intro that can run in under 4K including the screen RAM as long as whoever is writing the scrolling message doesn’t feel particularly verbose. Even with the longer text included in this release it finishes near $1600 so is hovering around the 4.5K mark and, again, that’s with the screen RAM. There’s also no raster interrupt code included, another decision initially made to keep things close to the bone that also means there’s nothing to reset on that front once the space bar is pressed.
Then there is Zeptotro, a less than sensible attempt to take the idea of loading data into the screen memory that Femtotro is using just a teensy bit further. It only decrunches into the screen memory and never uses any space above $07ff when executing – the final memory footprint is $03c0 to $07ff – which sort of makes it invisible because, if there were a program linked to it, the intro could literally just exit by jumping straight to the start of its decruncher without having to relocate any memory first. Once again, the music is by 4-Mat and has been rather rudely pulled apart to relocate it in memory, in this case so that it could be included directly into the intro’s source code for brevity.
That does mean I owe Matt an apology for being so brutal to his music driver on both occasions, but it was in a really good cause I swear! As is always the case, there’s source code available for both Femtotro and Zeptotro over at GitHub if anyone fancies a little delve down through them.
As promised in the previous post, here comes C64CD release time! First out of the gate is Super Hyperzap, a slightly remixed and improved version of my little gallery shooter Hyperzap 2018 which was actually completed around a day or so after the original escaped into the wild but then put aside to “release next week” and accidentally forgotten about during the subsequent shift to “demo mode”.
The main difference between Super Hyperzap and its predecessor is that many of the modifications that people asked for in comments online which had previously been omitted for “artistic reasons” have now been implemented, so there are a lot more sprite animations including an explosion sequence and as the game progresses the enemies begin to move horizontally as well.
That latter change fixes a design flaw in the original that it’d actually inherited from the original Hyperzap which meant it was possible to just sit still and hold the fire button and, whilst the gameplay is still simple enough, that updates does make things significantly more manic, especially on the later attack waves when nasties really start to shift around. It still won’t win any awards of course, but this version is a lot more fun to play!
As is always the case, source code and the relevant binaries can be downloaded from GitHub for folks wanting a delve around under the hood and there’s already a trained crack by Excess which was, rather impressively, released before I’d even finished writing this blog post about my own release.
With musical accompaniment from the long-suffering Andy Vaisey, I pushed my first entry into the CSDb Intro Creation Competition for 2018 out of the door today. It’s a piece rather evocatively titled Oldest Style because there’s a logo with a $D016 wave effect and two areas with inverted graphics and raster-based colour changes beneath them, so it really isn’t doing anything special… but there’s still something unusual going on under the hood and that sort of counts, right?
First a little back story; when I were a lad, raster-coloured text was a new, exciting thing and the titles page of Andrew Braybrook’s game Alleykat was the first example I remember seeing on the C64. But as a novice programmer I simply didn’t understand the hardware well enough to code a working routine myself and my first instinct was to have a loop checking the current raster position by reading $D012 and, when it changed for the start of a new line, updating the relevant registers.
The problem with that technique are the badlines where new screen data is being fetched by the VIC-II; I didn’t know about them at the time so my routine worked for seven scanlines but would hiccup on the eighth, missing it completely. Waiting for every second scanline to get two pixel high splits worked without issue and a couple of the older parts in Sometimes including the tech tech actually do this, but I discovered how everyone else was doing raster bars around that time as well so switched to using a more sensible method for the rest of the demo.
So a few weeks ago I was, as is often the case, procrastinating and found myself reminiscing about that original routine and how clunky the idea was… before wondering if it’s actually possible to do what I hadn’t managed in the 1980s. The most “sensible” solution was to unroll the loop and the final result after quite a bit of testing has been pared down to just five commands that are repeated for every scanline where a register is being split – there’s source at GitHub for those wanting a delve around and the splitter code has been farmed off into a series of include files for easier reading – so one line of the logo has this code;
There’s some self modification updating the majority of those LDA commands to make the logo wobble and change the colours behind the static text, which was done because there aren’t enough cycles to read that data directly – I did try and it just wouldn’t behave, missing it’s timing by a frustratingly small amount – so one drawback of this method has been the size of the code and getting it and everything else into the first 16K of the C64’s memory. If we were to actually use this intro there are a couple of spaces left for a linker after the music but not much else and I’ve already got data decompressing directly to the screen in order to save space…