Testing out Amiga algorithms the cheating way

Despite working for a 3D graphics IP company I've never actually tried coding any 3D stuff from the ground-up on an 8/16-bit machine and I figure I might want to give that a try someday.

The problem is that there's all sorts of places an algorithm can go wrong. Is my maths shoddy to start with? Have a made a mistake converting it to fixed-point? Or have I just misunderstood some instruction?

Although I grew up prodding around with an action replay (and to be fair using windbg on kernal mode drivers for windows isn't that much better) it's a bugger of a way of working, especially when the error might involving trashing memory so you've not got any way to investigate.

To help me solve the problem of at least getting the algorithm right I've knocked up a framework. All it does is allow you to set up a palette (using Amiga colour values), give you 1-5 bitplanes (plane 0 providing the LSB) and allow you to read and write from them with bounds checking. Once your function (which should draw a single frame) returns it dumps the plane contents to binary files and spits out a .bmp with the output.

So what does this mean? It means you can breakpoint, single-step and printf the smeg out of your code when you are developing it and write it all as C with floating point maths, just like a PC routine but with a wierd graphics configuration. Once I'm happy with that I can convert the algorithm to use fixed-point 16-bit maths and keep an eye on it as I go. When that's working fine I can subdivide the steps taken until it becomes pseudo-68k and all with pretty much the same level of comfort as debugging a windows application.

By that point the remaining thing to do would be to convert it to 68k assembler (which should be a line-by-line translation if I've kept to the plan) and hope I don't introduce any bugs along the way.

Taking a break to play with some C64 music

Bliss by Muse in 3 channels (Not easy):

For those with dead A600 or A1200 internal floppy drives.

This bloke does a decent job at going through the process:




There is a bit of the video missing though, but for that part:

towards the front of the drive there are a couple of tabs which can gently be pushed outwards, allowing you to lift the second layer of the top of the casing. Once you've lifted the top part take care to lift the top read/write head clear before sliding the casing clear of the drive.

And don't worry about the spring that infuriated the bloke in the video - you don't actually need to remove that at all.

About 5 minutes with cotton wool buds and some cheap alcohol-based makeup remover and it was booting right up again.

Hola Amiga. Cuanto tiempo!

It seems I'm now in possession of a stock A1200 with a second diskdrive (and the obligatory knackered mouse).

Now to give it a compact flash card, some means of transferring stuff and ideally a little extra RAM...

Reaxion lives (on the ZX Spectrum)

It's been a long time coming...

But I've nearly done it...






Hopefully my next game won't get delayed by half a decade of life happening.

You have to love how accurate Spectrum emulators are

When you can just pipe the tape noise out of an emulator into a real machine and it loads perfectly every time (so long as you remember to emulate a machine with no YM soundchip, otherwise it gets confused)

Back on with the 68K/Amiga

Seeing as I've passed my driving test I should now be able to nip off and pick up my* trusty Amiga 1200 and see if my code is as hardware-friendly as I hope it is. It's a stock 1200, but I'm hoping whatever I turn out will run on a stock Amiga 500 with 1Mb of RAM (I'm assuming 512k chip, 512k unknown).

In the meantime I've gone back to my scrollcode and it worked okay, but it made no use of the Blitter. I've corrected that now, although it took a couple of attempts to decipher the documentation for the minterm stuff.

The minterm docs run to a couple of pages and goes through boolean algebra and venn-diagrams, but it's really not as complicated as that. I reckon it should be explained like this:

You have a truth table for the 3 possible inputs. Just write in the fourth column where you want a 1 or 0 to be generated, and put those into the bottom byte of bltcon0 with the first row as the lowest bit. So a direct copy from A to D would be:

A	B	C	D
0	0	0	0
0	0	1	0
0	1	0	0
0	1	1	0
1	0	0	1
1	0	1	1
1	1	0	1
1	1	1	1

so reading bottom-to-top the bottom byte of bltcon0 would be 11110000. Also, the 4 bits before that are the flags to use each channel, so those would be 1001 to use only channels A and D.

All the other registers do exactly what they say on the tin and don't seem to hold any nasty surprises.

problem is the scroller has a buffer that is just over 2 screens wide and draws each character twice, so once the buffer has hardware scrolled to the second half the first half should be visually identical, so I can snap back to the first half with no visible effects whatsoever. It uses a little extra memory and 2 blits, but it should perform better than shifting the entire buffer in one blit and then drawing a character in a second blit.

My next Problem is that the code busy-waits on the first blit, and then carries on to do other things on the second blit, so it's wasting time it could potentially be using for other tasks and not making good use of the machine. My next task is to get the code to build a blit list and then have an interrupt handler to dispatch the jobs to the blitter when it's no longer busy. Definitely overkill for this little framework, but when I generalise it for a game engine I can run game logic and blitting in parallel and scrape more power out of the thing.



*Actually it belongs to my brother, but he's not using it...

It's not all retro you know...

..although am coding this on an iPhone 3G, which some apple fanboys would consider oldschool.

I'm using a load of old graphics and code from some old university 2D openGL game assignment I did, fixing the fact that it's a bit of a mess (I learned the pitfalls of writing code that survives compiler changes, endian switches and being 64-bit friendly afterwards) and fixing it up for openGL ES.

Although I'm reusing some of the assets it is a different game (although inspired by a few 80s arcade machines) and hopefully should be a nice distraction worthy of the price of a pint of beer*

At the moment it's just a mishmash of code that gives the right results if you stare at it in the debugger, but looks nothing like a game yet, but I'm currently sat at home in a Lemsip-induced haze working on this so hopefully something should come together soon enough.

*half a pint if you live inside the M25.

Sometimes rebuilding can take a while...

so I started playing with the previous code and knocked out a chunky scroller whilst I'm at it.



The WIP version I have also has a chessboard zoomer in the background, but it's a bit dodgy (I think my interrupts are overrunning a bit), so I've disabled it for this video. If I can't fix up the interrupts I'll seperate them out into seperate parts, fix the scroll position or find some other workaround.

Oddly enough the chessboard is less dependent on lookup tables than the one I did on the ST (It's generated from scratch) and uses a hell of a lot less rastertime to run. I think for a lot of what I want to do the SMS is more powerful than the ST :)

or it could just be my shoddy 68K assembler abilities...

I've been playing with some Sega mastersystem coding. So far I've got a toolchain up and running that takes a level-sized bitmap, chunks it up, RLE compresses the columns of of tiledata and lets it run on the mastersystem.



The levelmap and graphics are from 'Edge Grinder' - an 8-bit collaborative project hosted at Format war led by Jason 'TMR' Kelk, and were designed for the C64, which is why all of the coloured pixels are double-width. They could be improved for the mastersystem and it's more liberal palette and 1x1 16 colour graphics mode, but at the moment I'm more concerned with getting the code up and running.

Looking at the Sega Megadrive/genesis it looks like it's pretty much the same technique to get things going there, albeit with nicer graphics and a faster 68000 CPU so when I have enough to be going on with I'm going to port it all across.

The sprites look like hassle though - I'm working with 8 sprites per line of 8 pixels width, as opposed to the 24 pixel wide ones on the C64 so it looks like things might get a little difficult.

Maybe a bit of flicker or creative use of background characters might be in order...

So... what happened?

I started with good intentions, but then the whole financial crisis kicked in and it ended up being impossible for me to find a job in Spain, so I ended up on a flight back to the UK for an interview.

I got the job, returned to Spain to collect my stuff and then started working on graphics drivers which has kept me pretty damn busy until now. So I've ended up doing low-level coding but nothing I can talk about in public.

I've just started finding time to do code in my free time again, so watch this space.