Release notes – Stercore XD (C64)

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.

Stercore XD (C64)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.

Stercore XD (C64)

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.

Stercore XD (C64)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.

Posted in Programming | Tagged , , , , , , , , | Leave a comment

When C128 sprites collide

Your correspondent promised a reworked version of his C64 assembly language sprite collision detection code for the C128 when the author had finished a conversion of the BASIC program her was given but, since an entire month appears to have passed without any sign of said 11 line program being translated – that’s somewhat embarrassing for the author considering how certain he was about conversions to platforms without hardware sprites presenting “no problems” – your correspondent has decided to push ahead with publishing and documenting his previously revised, assembly language code. As with the C64 version, the source can be found at Github for readers to peruse.

There are in fact only two “significant” changes to your correspondent’s original code dear reader, with the first being memory layout; BASIC memory on the C128 starts at $1C01 as default compared to the C64’s $0801 so our code has to move accordingly, starting at $1C12 rather than $0812. The reason for this difference is that the C128 has memory below that higher start of BASIC assigned to other jobs – for example when the sprite handling commands are used, the graphical definitions are stored at $0E00 onwards – and, whilst there’s nothing to actually stop us assembling code into those assigned spaces should we feel the need, your correspondent wanted the BASIC start line which executes the program present so a move was required.

Collisions (C128)The second change to the program is right at the start of the actual code at lines 34 to 36 in the source where we find it reading the value from location $01, clearing the lowest two bits and writing that revised value back. This was done because one feature the C128 has which isn’t present on the C64 is double buffering of the colour RAM and as a default the processor is looking at a different chunk of memory to the video system on start up; in order to colour the two balls that our moving sprite is going to collide with, we need to first make sure both chips are looking in the same direction.

Speaking of which dear reader, apart from changing the colour of those balls to light green to match the C128’s default scheme that’s all of the modification required for this program because, for an assembly language coder, the C128 is very similar to the C64. Whilst it’s possible to use the ROM routines to manage the sprites it would be a relatively long-winded approach compared to simply working directly with the hardware registers as C64 coders do.

Posted in Meta Discussion, Programming | Tagged , , , , , , | Leave a comment

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 book is 292 pages long according to the link you sent. The list of memory locations starts at 0. The point I’m making is how many memory locations are people supposed to remember to write programs on the C64?

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.

It seemed to me while I owned that computer that the number of locations I might have to remember may be 65,536 (i.e. 64K) or perhaps 65,536-38,911 (i.e. the number of “BASIC BYTES FREE” on the C64 startup screen, which makes 26,625. I know it’s far more than the number of registers in the VIC-II and SID chips. There may be a clue of pages 83-84 of that book, where the memory locations listed suddenly jump from 8191/$1FFF to 32768/$8000.

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.

Of course, Commodore manuals never said what the limit was to the number of memory locations. What is the actual number of memory locations budding programmers would have do deal with?!

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.

Posted in Commentary, Debunking | Tagged , , ,