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.

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.