*sniff* There goes another year, man do I feel old now. Well, almost...couple of hours left I guess.
I've just updated my uploader ROM to fix some minor issues, and to add a loading bar. Its great to have programming space to burn! When I was coding it, I kept it as small as possible so that anyone typing it in by hand didn't have too much to do. But now its on ROM and doesn't even have to fit in the small space I'd use before, I can splurge on visuals a bit. Nothing too much, just the loading bar from the C64 one. I might add more features later on. I was also testing my new EPROM UV eraser which I guess works fine as the new code went on easily enough.
I hope to get a couple of 16K EPROM's soon and I'll put OS96 on it so I can do some stuff for Solder.
Lets hope we have as much fun next year as we did this, it looks like being a very busy one for me at work, so I hope I can find the time to finish XeO3 - I think 2007 could be the year!! Have a great new year peeps!
Sunday, December 31, 2006
Saturday, December 30, 2006
Stupid, Stupid, Stupid....
Yep...just realised I've been stupid. Theres no need to make a "userport" addon to expose more lines for ROM selection as I can just add a new hardware register(s) that do anything I want. idiot. This is in fact what Solder did on his 1Mb ROM expansion.
I wonder if you could add RAM instead of ROM and just write to it and page in in/out.... I know that writes fall through to the RAM under it, but if it could write to both, than while you'd lose 32k of RAM under the ROM (or rather pretend ROM as its now RAM), but gain megabytes of parged RAM for doing whatever you like....I wonder.. I suspect someone with a bit more skill would have to try that.
I think the 1st thing I'll do as an add-on, is a new register that sets some LED's, this is the basis of everything you add on a computer really, so it should be pretty good fun.
(Oh...and whoever designed the "8bit baby" has never plugged one of them into a Plus/4 in their life!)
I wonder if you could add RAM instead of ROM and just write to it and page in in/out.... I know that writes fall through to the RAM under it, but if it could write to both, than while you'd lose 32k of RAM under the ROM (or rather pretend ROM as its now RAM), but gain megabytes of parged RAM for doing whatever you like....I wonder.. I suspect someone with a bit more skill would have to try that.
I think the 1st thing I'll do as an add-on, is a new register that sets some LED's, this is the basis of everything you add on a computer really, so it should be pretty good fun.
(Oh...and whoever designed the "8bit baby" has never plugged one of them into a Plus/4 in their life!)
Friday, December 29, 2006
Plus/4 hardware fun.
I've having a bit of fun making my first ROM for the Plus/4, nothing too amazing but getting used to developing and burning ROM's for it. I've put my uploader onto ROM so that I don't have to load it from disk anymore and for a first attempt, its almost there. I altered minus4w so that I can autoload a ROM as well as a program so that I can test it better; although being an uploader, I can only test it so far inside an emulator!
I removed the 3-plus-1 ROM's from my development machine and put in an 8K EPROM (the slot's designed for 16K eproms, but 8K works just fine), and I now get the screen shown. I pinched the start-up code from the 3-plus-1 ROM's as its pretty handy, and I'll release it as source later on. Using this stuff, I could build a complete debug system on ROM meaning I leave virtually all the RAM for a game/application, which would be very cool.
I was also thinking about XeO3 and wondering if I could put it on a ROM, and I could...but it would be a little odd. I suspect that I'd need more than the available ROM slots left, so I'd need to have a cartridge and a connector from that into the userport so that I can expose a couple more control lines and page more ROM's in/out (probably allowing up to a 512k ROM), but that would mean that I could do a version of XeO3 completely ROM driven - no loading times! How cool would that be!
I also still want to try and make an MMC interface at somepoint and have a ROM bootup and load a basic filemanager fom the MMC card. This again means that there would be basic loading on ROM and you could put games etc. on an MMC rather than ROM/DISK. However, since this would take over the expansion port, you really need a SID card on there as well....bummer. The SID interface doesn't look too hard though, so you never know.
Anyways....I'll release all this stuff as soon as it's in a fit state - getting tools on ROM is pretty neat, particually since the Plus/4 has 2 available ROM slots internally - which I do really like.
Monday, December 25, 2006
Friday, December 22, 2006
Electronics fun.
I've been having fun with my electronics toys again - sorry. :) A whole load of stuff arrived so I've been playing away with PIC's and LED's. I'm planing to build a scrolling message using giant LED Matrix disaplays (5x8's) so I've been learning PIC assembler. You can code a PIC in basic and C, but while the assembler is a little odd, its still far more flexible than either language.While learning PIC assembly, I've managed to kill 3 pics in the process - doh. I'd originally read that there were 16 availble I/O pins on the PIC I'm using, however, thats not really true; theres 15 I/O lines and 1 input line. However after setting this input line to output, I've discovered that I can't reprogram them. Oh well, just as well they're cheap! a PIC16F628A is only around £1 a chip so its not the end of the world, but I'm glad I figured it out quickly!!
I've now progressed past the little pic+flashing LED onto something a bit more interesting, I've started to play with interrupts and generating them via an external PIN which I'll use to do some interrupt driven COM's. The PC will send data over a couple of wires, although I might look into the USART's every PIC seems to have. The picture opposite has a PIC16F628A driving some LEDs and a 555 Timer generating an external interrupt pulse. Great fun.It seems to take quite a while to do even the most basic stuff in electronics, something I'd never fully appricated before - particually since you end up checking and double checking EVERYTHING! However, its great fun, and I'm looking forward to building some real toys for my Plus/4 and C64. I just got a batch of C64 carts and EPROMs and I'm waiting for my new EPROM programmer which means I'll be able to put my C64 uploader on EPROM so I don't have to load it each time, that'll be very cool. I'm also waiting for some 8bit baby's so I can try and do some Plus/4 stuff, althought the Plus/4 has a couple of EPROM sockets inside the machine and that may let me do the same on that machine too - very cool.
Oh....and I also had never realised just how much NOISE will appear on a wire that is simply waving around in the air! Its amazing! It doesn't stay at 0 volts, or"X" volts...but jumps up and down like a yo-yo! Also, if I did get it sitting still at 0 Volts, as I moved my had towars it, it starts to get electrically charged - even though I never touch it! Thats just so cool....
Thursday, December 14, 2006
XeO3: Bug spray....
I've had an interesting evening here, what with fighting with 2 year olds and trying to get them to sleep, and tracking down some elusive bugs, its been quite eventful. However, I've managed to eliminate 2 nasty bugs, one in the cache system and one on the front end... letme take you through them, or rather how I go about bug hunting... I've discovered over the years that debugging is a real art form, and one not many new folk are very good at - so here we go...
Bug 1. Cache system - okay, I had a fair idea where this one was since I had just rewriten the whole cache but the problem is that the cache is pretty large so first things first, chop it down to 1 entry. This means it's gonna hurt as every sprite will get rotated every frame, but Im debugging so what the hell. After stepping through the code I discover I've taken some short cuts in the code which speeds things up, but also requires at least 2 cache entries - okay, 2's still not bad, so we set that. Next, we have to verify that the cache is actually intact, and looking correct. With 140 odd entries, this would be pretty horrible to do, but with 2 it's a doddle. Turns out not all is well in the state of cache land. So I set about rewriting the cache initialisation stuff. This is a bit of a mind bender - again because I've decided to improve things.
You see, being a coder I count from 0 up, which means my indexes also start at 0. But the probelm is, I also want to use 0 to specify a no links (like a NULL in C), so I increment every entry by 1 so that 0 is 1, 1 is 2 and so on....this is pretty easy, but then it means that all the table accesses have to have a -1 with them to offset this.
Anyway, after rebuilding the linked list (using indexes this time), I fix up the main code that refrences them to use -1's and fix a couple of $FF index issues and we're all set. Cache bug appears to be fixed.
Bug 2. I thought this was a really simple one, I'd moved all the graphics around and suddenly the front end font vanished; okay I thought, I'll just have to move something to point to the new graphics...but no. Bugger. Now, whenever you get a bug that you simply don't understand, the trick is to knock out as much code as you can while still having the bug occur. This narrows down the amount of code you have to debug, and also reduces any interactions between modules where any funny issues might be happening. So, I do this.... I remove the ECM mode stuff, force in specific character set addresses, and make damn sure the character set is where I expect - it is, and its all as expected; but still no font.
I play for a while trying to get something to appear, firstly by altering the PRINT routine so that it only writes WHITE to the colourmap, and then by filling the whole damn screen with WHITE. Ah! There we go! Something...but not a font. Now, I know its displaying the right character set as the stars are all working, and if I poke around in there with $00's and $FF's I can see it - but still no font.
Okay...what next. If in doubt - try it on a real machine. Mmm...looks the same, press and hold reset and hay look... the logo changes to the FONT characters as the IRQ's go down, so they are there.
Okay...Now I know the grahics are right, lets step through the print routine - which I was assuming worked fine. Now I have a table lookup to translate ascii into my font using self mod code, and it turns out that this table USED to be on a 256 byte bounday, so I would store the character in the low byte and have the high byte point to the table. However, with the big memory move, its all changed... and this table no longer sits on a nice 256 byte boundry! The result is that during the look up, all letters are changing to a space! DOH! So, now I align the table and PING! All working again, so quickly put in all the bits I'd taken out, and bang! Back to normal.
So... when debugging, lop out as much as you can; coment out huge sections, #ifdef 0, or whatever! The less code you have to step through, the quicker you'll find that bug - Here endith the lesson.
Bug 1. Cache system - okay, I had a fair idea where this one was since I had just rewriten the whole cache but the problem is that the cache is pretty large so first things first, chop it down to 1 entry. This means it's gonna hurt as every sprite will get rotated every frame, but Im debugging so what the hell. After stepping through the code I discover I've taken some short cuts in the code which speeds things up, but also requires at least 2 cache entries - okay, 2's still not bad, so we set that. Next, we have to verify that the cache is actually intact, and looking correct. With 140 odd entries, this would be pretty horrible to do, but with 2 it's a doddle. Turns out not all is well in the state of cache land. So I set about rewriting the cache initialisation stuff. This is a bit of a mind bender - again because I've decided to improve things.
You see, being a coder I count from 0 up, which means my indexes also start at 0. But the probelm is, I also want to use 0 to specify a no links (like a NULL in C), so I increment every entry by 1 so that 0 is 1, 1 is 2 and so on....this is pretty easy, but then it means that all the table accesses have to have a -1 with them to offset this.
Anyway, after rebuilding the linked list (using indexes this time), I fix up the main code that refrences them to use -1's and fix a couple of $FF index issues and we're all set. Cache bug appears to be fixed.
Bug 2. I thought this was a really simple one, I'd moved all the graphics around and suddenly the front end font vanished; okay I thought, I'll just have to move something to point to the new graphics...but no. Bugger. Now, whenever you get a bug that you simply don't understand, the trick is to knock out as much code as you can while still having the bug occur. This narrows down the amount of code you have to debug, and also reduces any interactions between modules where any funny issues might be happening. So, I do this.... I remove the ECM mode stuff, force in specific character set addresses, and make damn sure the character set is where I expect - it is, and its all as expected; but still no font.
I play for a while trying to get something to appear, firstly by altering the PRINT routine so that it only writes WHITE to the colourmap, and then by filling the whole damn screen with WHITE. Ah! There we go! Something...but not a font. Now, I know its displaying the right character set as the stars are all working, and if I poke around in there with $00's and $FF's I can see it - but still no font.
Okay...what next. If in doubt - try it on a real machine. Mmm...looks the same, press and hold reset and hay look... the logo changes to the FONT characters as the IRQ's go down, so they are there.
Okay...Now I know the grahics are right, lets step through the print routine - which I was assuming worked fine. Now I have a table lookup to translate ascii into my font using self mod code, and it turns out that this table USED to be on a 256 byte bounday, so I would store the character in the low byte and have the high byte point to the table. However, with the big memory move, its all changed... and this table no longer sits on a nice 256 byte boundry! The result is that during the look up, all letters are changing to a space! DOH! So, now I align the table and PING! All working again, so quickly put in all the bits I'd taken out, and bang! Back to normal.
So... when debugging, lop out as much as you can; coment out huge sections, #ifdef 0, or whatever! The less code you have to step through, the quicker you'll find that bug - Here endith the lesson.
Tuesday, December 12, 2006
XeO3: Bugging me....
Been a few weeks now since I last did anything really, so I started to try and hunt down the bug in the new cache system. I'm getting less and less time just now, so I only really got a chance to go over the code a little but I'm sure its in the cache. I reduced the number of cache entries down to 2, and the sprite corruption showed up everywhere, so I think its something to do with the last cache block, although I've no idea currently what that is. I hope to start proper debugging tonight, but that assumes I'll be able to stay awake long enough. I'm currently struggling with a cold which has me virtually asleep at my desk.
Anyway, while plodding away with XeO3 this year, I've been thinking that 8bit development has gotten far easier than it used to be, and I don't think theres any one reason why, I think tools are better, turn around is better, editors and web help and we just know more about it. Hell, I did the C64 multiplexor in a couple of days! It used to take weeks! But with this bug, I'm starting to think that its all just down to experiance. I've done lots of harder things now, and retro coding is pretty simple as far as game logic goes, so we just dont make as many mistakes as we used to when we were starting out. This new bug on the other hand is a little more complex as it's now using a more advanced/faster cache that will take a little time to unravel. Still, its good to know that I can still learn stuff, and Im not quite as thick as I once was.
Anyway, while plodding away with XeO3 this year, I've been thinking that 8bit development has gotten far easier than it used to be, and I don't think theres any one reason why, I think tools are better, turn around is better, editors and web help and we just know more about it. Hell, I did the C64 multiplexor in a couple of days! It used to take weeks! But with this bug, I'm starting to think that its all just down to experiance. I've done lots of harder things now, and retro coding is pretty simple as far as game logic goes, so we just dont make as many mistakes as we used to when we were starting out. This new bug on the other hand is a little more complex as it's now using a more advanced/faster cache that will take a little time to unravel. Still, its good to know that I can still learn stuff, and Im not quite as thick as I once was.
Subscribe to:
Posts (Atom)