Workprint – June 2017

There hasn’t been a lot of coding time for one reason or another recently, but one thing I’ve been tinkering with a little is the SuperCPU or more accurately an emulated version courtesy of VICE; I’ve reworked my unrolled plotter – the one used in MD201704 – to handle about four hundred points. There’s also a “user interface” so that the cosine curves can be fiddled with as well because that seemed like a fun thing to do.

Halfway through playing with it I realised that, since it’s 6502 code rather than 65816, there’s no reason it won’t work on my Turbo Chameleon-equipped machine as well… where the 6MHz mode takes longer to get all of those points cleared, updated and drawn whilst the “unlimited” mode actually gets job done faster than the SuperCPU! Since I can at least release it as tested on one real accelerator and possibly get someone to run it on a SuperCPU as well, this may well become MD201706 and there should be enough raster time to finally use Sean’s double speed cover of Brian The Lion without breaking a virtual sweat.

There’s also a C64CD demo being prodded at right now, quite literally in fact since it’s testing on my C64C as I write. Unlike previous releases on said label it isn’t inspired by classic 1980s or 1990s releases and instead has a loose theme based on current events and a discussion at the Atari Age forums which got onto the subject of encryption. It needs a little more work, but should be ready to go either tomorrow or possibly Thursday.

MD201705 (C64)

There’s no theme to MD201705 so I can’t mumble about that for this post, but it does rework an effect I did previously in the demo Mish Mash, covering a larger area of the screen and updating the colour RAM this time as well as adding some more cosine curves for good measure.

It’s available to download from the usual suspects and the source code is available from Github too. There’s no YouTube video at the time of writing but I’m in the process of rethinking how to do those for better results.

How Koalatro works

There were some interesting responses to Koalatro over at the CSDb when it was released, with a few people expressing surprise that the code only takes 16K which has left me giggling like a schoolgirl because, apart from some zero page use which doesn’t count towards the total according to the competition rules, the entire thing runs from 15K, loading and executing between $0400 and $3fff. A Koala-format bitmap is 10,001 bytes (8,000 of bitmap, 2,000 of colour and a byte for the background colour register), aNdy’s music takes around 3K and another half a K is taken up by unrolled code to open the borders and split sprite colours. So that’s about 13.5K use and the rest of the code, some tables, sprite definitions and a little scroll text therefore have to fit in the remaining 1.5K… right?

Well not exactly and it’s probably best to look at the memory map in order to explain further; before the code starts, the layout looks like this:

$0400 - $07e7	First block of colour RAM for the bitmap
$07e8 - $09db	Second block of colour RAM for the bitmap (packed)
$09dc		Background colour register
$0a00 - $13ff	Code, data and scroll text
$1400 - $1fff	Music
$2000 - $3f3f	Bitmap data
$3f40 - $3fff	Colour tables and sprite positioning/set-up data

The first two “tricks” are how colour for the bitmap has been stored; the first block at $0400 is already where it needs to be (which is why only the crunched file from the Github repository can be dragged and dropped into an emulator) so there’s no memory lost elsewhere or code required to move it into place. The second block of colour is a bit more involved since it’s been packed down into 50% of the RAM; this relies on the fact that only the lower nybble is used (a value from $0 to $f) so two of those can be stored in one byte. The background colour byte from the Koalapainter format file is included for completeness and the code will actually deal with other background colours cleanly despite that not being required in the final release.

One thing that’s missing from the memory map above is where the sprite definitions for the scroller are being stored but there’s a small hole between the end of the packed colour data and where the code starts for a reason; one of the first things the code does is unpack the colour data to $d800 and, once that’s done, the space from $0800 to $09ff is then cleared and used for the sprites so there’s only eight definitions available but, since both scrollers use the same eight sprites, that’s not an issue.

And speaking of the scrollers, there’s that block of unrolled block of code I mentioned previously to split the sprite colours and yes, it’s literally doing that; rather than changing the background colour and having black sprites over the top it’s actually writing one of two values to every sprite colour register on each scanline whilst juggling $d016 to open the side borders. The same block of unrolled code is recycled for the two scrollers, starting one scanline further up the sprites for the upper area so the reversed version of the scrolling message gets the static colours. Finally there’s the eight hundred bytes of scroll text from $10de to $13fe which leaves one byte free before the music starts.

I think that’s everything of note covered, the source code is, I hope, reasonably well documented.