Taking a break from 68k

At least for a little while to write some tools. That's the beauty of crossdev - you can chew up relatively massive amounts of CPU time to distil your data into a form that is as close to being able to dump it straight into the hardware registers as possible. I prefer having my data this way because processing = time and time = limited. You could just go to google and look for native or crossdev tools that are out there already, but I couldn't find anything that did what I wanted (or in this case even work) so I ended up rolling my own. Maybe when it does everything I think it needs to do I might put it out there to save others the hassle.

First one up is the awe-inspiringly titled 'IFF Manager'.



Okay... maybe the least awe-inspiring screen shot ever, but it does actually work. I'm adding features as I need them but currently after unpacking an IFF picture file it can extract individual bitplanes in whole or rectangles for sprites (although at the moment the rectangles need to be byte-aligned) and output them as sequential bitplanes, interleaved to reduce Amiga blitter overhead or in ST screen format.

The code is factored nicely so I can wrap it up as a command line tool, build a GUI on top of it or maybe make the tool LUA scriptable to automate the cycle of modifying the graphics file and exporting the relevant data. Not sure what people would like for the best. I suppose I could combine the LUA and GUI options so if you start it from a prompt with a NOGUI parameter it'll just run as a (slightly bloated) commandline tool.

Playing nice with the OS

I just had a quick count of what is needed to manage a graphics application on the 16/32 bit machines I've been playing with. The startup library contains exactly what is needed to leave the OS, get a working fullscreen display, wait for the vertical sync, swop the screen buffers and return to the operating system without killing other applications or causing a crash.

These are the results at the moment.

Amiga - about 120 lines of 68000, although a copperlist is needed on top of that, but that's application specific.

Atari ST - about 90 lines of 68000

Acorn Archimedes - 25 lines of ARM.

RISC OS is nice like that, you just ignore the operating system apart from a couple of calls to swop buffers, pick a screenmode and check for input and it restores itself afterwards.
The Amiga has the most heavyweight startup library, but even in the small example code I've knocked together I've saved more than the 30 lines difference between the ST and the Amiga (along with the associated rastertime).

It's a damn shame the Arc was so underrated, it gives the ST a bit of a kicking, although it falls short of the Amiga. Quite a respectable second place I reckon.

...And on to the Amiga

Like many companies in the 1980s I decided to take my first steps onto the Amiga in the time-honoured traditional manner - by cutting and pasting my existing Atari ST code into Devpac Amiga and fiddling the screen output routines a bit. Okay it was slightly more effort than that, but not much. Most of the effort was put into removing code rather than adding it.

Although the screenshot doesn't seem to show much happening the screen is nicely divided up under the control of the copper coprocessor, with a 320x43x4 planes (16 colours) logo at the top, a 4-plane screenbuffer in the middle for rendering effects to (double buffered, naturally) and a 1-bitplane scrolling message along the bottom. There's also a protracker module playing in the background. Because the screen splits are all handled by the copper there's no interrupt uncertainty so the splits are 100% rock solid and no CPU time is lost.

The great thing here is the 'red bar of doom' code profiling method is in effect (turn the border red when your frameloop starts, turn it black when you're done and the thicker the red area the less CPU time you have) but there's nothing showing. If you remember I said the scroller alone on the ST used about 15% of the CPU time. In the Amiga code the bar doesn't even show.

This is what I love about the Amiga - the flexibility of the display hardware. It's a pain to set up (out of 3 days trying to get this going about half was spent just trying to get the screen setup without crashing the OS) but well worth it once you manage it. The ST version worked with an off-screen buffer 336 pixels wide (1 screen plus space for one character) and every frame each byte of graphics data had to be loaded, moved 2 bits to the left, the overflow put into the preceding byte and everything written back. It also had to be copied to the screen (not even using the fast block copies due to the annoying ST plane format) in the correct place.

The Amiga version is more cunning - the scroll buffer is now 84 bytes wide (twice as wide as it was) and each frame the hardware fine scroll is incremented by 2. when that overflows after moving 16 pixels the screen address is incremented 2 words until we've moved along to the right of the buffer. So where do we go then? well every 8 frames we draw the new character twice, so by the time we reach the right hand side of the buffer the left contains an identical copy of it so we can seamlessly snap back to the beginning. This means instead of moving 672 bytes left 2 pixels, then copying those 672 bytes to the screen as on the ST we're just writing 2 bytes every frame (for the fine scrolling), and 70 bytes every 8 frames (2 new characters to draw and to reset the graphics pointer).

Even with an increased resolution of 320x256 and an extra bitplane to bring us up to 32 colours it looks like there's going to be a lot more time on the Amiga for doing stuff.

..and I haven't even touched the blitter yet.

First steps in 68000

During the late 80s/early 90s all the cool kids had an Amiga. Some pressed on with an ST but still they had their games. Then there was me. I rolled the dice once again and tried the time-tested 'It'll help me with my homework, dad!' line to get myself an Amiga.

He looked around the school computing room and came home with an Archimedes. Not the worst machine, but not exactly overflowing with games released on a weekly basis. Nevertheless it was a good machine for a coder - the ARM 2 wasn't bad, the 12mhz ARM250 was quite nice, the 256 colour palette was naff but it was a friendly machine to code for. And these days ARM is a pretty good skill to have all things considered - they're everywhere, just not that visible.

But coming from a commodore 64 with hardware sprites, rastersplits and videochip trickery I always longed for something with interesting hardware and a few tricks. So to occupy myself a little recently I decided to right the wrongs of the 1990s and jump in to starting out with 68000 assembler... More specifically the ST.

I started with the Atari because of the simpler architecture - A screenbuffer and... yup. That's about it really. It has a few things in common with the Amiga (planar graphics), the palette is only 16 colours and you don't have such fine control (unless you target the STe), no blitter (STe again) but I figured the less custom hardware to setup the less I could get wrong whilst learning the instruction set.

And here we have the generic 1980s logo and scroller. Bit rough codewise because although it runs at 50hz there's 86 out of 200 lines taken up with static logos and the remaining chessboar area takes about 60% of the CPU time.

The 1-bitplane scroller has to be manually rotated and is then copied into the screen buffer, using another 15-ish percent of the frametime. Not a problem though because the screen is controlled by 2 interrupts - one just below the first logo to set the palette for the 'effect area', and a second below it which swops the video pointers (this doesn't take effect until the next frame), calls the music player (which basically streams out YM soundlog format data) and sets the logo palettes. Not exactly awe-inspiring but not bad for a first attempt and kinda smooth.

There's a youtube video of it in all it's 'glory' stashed away here.

Now let's try the Amiga...