The RGCD 16K cartridge competition is running during 2019, so your correspondent decided to have some fun and use it as an excuse to complete and release Stercore XD, a reworked version of the ported Spectrum shooter of a similar name which eschews software-based sprites in favour of larger, more colourful hardware ones and replaces the chunky scrolling backgrounds with something a lot more detailed. The competition rules state that entries must fit onto a 16K cartridge ROM and Stercore XD manages that even if it only just slides under the bar, with less than a hundred bytes of free space.
That doesn’t mean there aren’t some improvements to the original Stercore however, code for handling enemy movement patterns has been grafted in from Super Hyperzap to make the gameplay more interesting and the background scrolling speed slowed down to five pixels per frame rather than the original’s eight in an attempt to add further longevity to the game. The scrolling background’s map is 9,360 bytes wide by 20 high which means that there’s somewhere in the region of 182K of data passing by during the course of the game which, due to the slower movement speed on this version, will take just under five minutes to traverse.
As with the original Spectrum game there are two levels of background graphics, a darker layer which is always behind the hardware sprites and the mostly lighter one which passes over them. The technique is the same one used for games like Gryphon or Action Force and relies on one of the two character multicolours always staying behind the sprites regardless of what the hardware priority register is set to; this and the background colour are used for one layer whilst the other multicolour and various character colours provide the other. It does require a little more care than usual when designing the graphics but the effect works reasonably well.
Since the conversation here of late has been about hardware-based sprite to sprite collisions on the C64 it’s interesting to note in passing dear reader that this particular game exclusively uses software-based checks; that was a deliberate design choice for a number of reasons – this is something that your correspondent already has a longer discussion post in the works to cover more thoroughly – but it also harks back to the original Stercore and its subsequent C64 port, both of which rely on software sprites and, by association, collisions.
Along with the visual reworking, your correspondent also took some time to extend the original title music and tweak some of the sounds a little and most of the work files for the game are available over at Github including the Char Pad project containing the scrolling background for those wishing to understand more about how this works. It’s worth noting however that the source code is a little harder to read than usual, partly because chunks of the actual program are generated on starting up in order to meet the 16K limitation of the competition.
The source code even includes a macro since the author has previously talked about them. In this particular case the macro is called “print”, appears at the beginning of the source and is responsible for pushing text to the screen memory; the assembled code is slightly less efficient this way since your correspondent would normally optimise things by having one loop outputting multiple lines of text, but it does serve as a practical demonstration of how macros work since the author’s description was rather lacking.
Checking the registers
In response to his almost incomprehensible rambling during Oh that would be VERY difficult! – Part 5, the author was recently pointed towards Compute’s Mapping The Commodore 64, a book which exhaustively delves into the C64’s memory and how it’s used. He of course didn’t understand what the book was telling him presumably because he didn’t actually read it and just skimmed through before making some uneducated guesses that would fit with his current world view, so let’s take a quick look at his response to said comment.
This is an almost ridiculously vague question since it doesn’t specify which kind of programs; anybody writing a text adventure in BASIC has to know a grand total of zero memory locations, someone creating a single screen, sprite-based action game in assembly language needs access to some registers and those can be represented as offsets from a handful of base addresses meaning that knowledge of at most half a dozen numbers is required and not all of them are five digits either.
Even if someone were to insist on referring to the video registers directly there are only forty seven in total; the simple action game mentioned above hasn’t got to set sprite expansion or priority registers for example and certainly doesn’t need to be checking the current position of a light gun either so there’s no need to know what all of the registers do.
The author is confusing memory-mapped video, sound and I/O registers with memory as a whole dear reader; the spaces outside the 38,911 bytes allocated to BASIC programs don’t, as he falsely believed, all serve specific purposes that need to be learnt and the vast majority are merely memory that a programmer can assign at will. Yes there are rules and caveats to be learnt about specific ranges of memory – it’s not possible to store graphics data at $1000 to $1fff or $9000 to $9fff for example because the VIC-II sees a shadow of the ROM character set in those areas – but other 8-bits have similar rules and caveats so it’s not something unique to the C64.
The C64’s manual doesn’t exhaustively cover the memory map (the C64 Programmer’s Reference Guide does however, something that shouldn’t come as a surprise to anybody considering the title) but also doesn’t imply that a large swathe of memory locations need to be learnt either; that’s a mistake on the author’s part that a little further reading would have corrected.