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.
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.