Monday, 26 September 2011
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)
Sunday, 25 September 2011
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:
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...
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...
Subscribe to:
Posts (Atom)