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.

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

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

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