Posts Tagged ‘intro’

How Koalatro works

Tuesday, May 16th, 2017

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.

Refix 2017 (C64)

Sunday, January 1st, 2017

Well, we’ve finally got through 2016 and my first bit of code for the new year is Refix 2017 on the C64, a developed from scratch, expanded remake of an intro that Cosine used on games and tools during the 1990s. The original version looked like this…

…and here’s a video of the new version with a brilliant cover of the Amiga module Macrocosm handled by Andy Vaisey, the box around the screen being pushed into the upper and lower borders, a high resolution bitmapped logo and some quite frankly bonkers colour splitting on the text…

This was my third and, for this instalment, final release for the CSDb Intro Creation Competition and, although it was initially quite painful to actually get going – the colour effect was a tricky little bugger to get timed up – and needed quite a bit of late in the day optimisation to make the music fit, this really was a blast to code!

There’ll be another post about my second piece of code this year in the extremely near future, mainly because it’s another NYD contribution for the Atari 8-bit and should turn up online a little later today!

Koalatro (C64)

Wednesday, December 21st, 2016

I’ve been almost worryingly quiet for a few months – according to others rather than myself I hasten to add, I worry about me all the time – due to a mixture of illness and… well, more illness really. Normal services will hopefully be resumed once the “festive season” is out of the way and I cheer up a bit! In the meantime, I’ve been working on entries for the Intro Creation Competition at the C64 Scene Database where the primary rule is that the releases must use a single block of 16K at all times. I’ve already put out one called Clonetro on the C64CD label and today has seen the launch of the second, this time from Cosine and sporting some music from aNdy.

Koalatro is a somewhat masochistic exercise in cramming a multicolour bitmap, music, scroller (with unrolled colour splitting code that takes over five hundred bytes on it’s own) and some text into just 15K. Using a Koalapainter format picture in an intro that small whilst executing doesn’t sound too complicated, but the 10,001 bytes of data would normally eat through two thirds of the space before any code or music is included! So, whilst all the data that a Koala picture would normally require is still present, 1,000 nybbles of $D800 colour data have been rather unceremoniously packed into 500 bytes. The double speed music (the player is called twice per frame) was supplied by aNdy who originally created it for a CSDb competition a few years ago, fortunately it was pretty short because the intro needed it to be.

The scroller started out as a reasonably straight copy of one in Contribution by Super Swap Sweden – the sprite colours are split on each scanline rather than the background colour, so it only just has enough time to load two values, write to all eight and keep the side borders open if the entire loop is unrolled and all of the LDAs are absolute! As is now usually the case, I’ve pushed the source code to Github for people to prod around, but it’s not exactly the cleanest thing I’ve ever written!