XeO3: I'mmmmmmmmmmmmm.............BAAAaaack!

Well, after a long break, I'm back and trying to get things swinging again. But needless to say, I screwed up yet again and left the game in a terrible state. There's at least 2 very serious bugs causing crashes and corruption through out the game that I need to track down before I even get started with new stuff.

I've managed to sort the 1st one out which was the turret and mine animations were going nuts! It turns out that a huge chunk of code had been deleted (I assume by accident!), and the only way I managed to find it was by doing a DIFF using source safe (a source control program).

Source control is great - even for use at home when your the only programmer. They are normally used for large teams and manage source merging and storage, but for a single programmer they give valuable check points where you can roll back to if all else fails. This is how I caught this bug; I simply checked the current version on disk, to the current version that was checked into SourceSafe - and a huge block of code had vanished. A simple copy+paste from SSafe to CodeWright, and its fixed.

The next bugs probably going to be a lot harder as Im sure its to do with the new sprite cache....

Edit: Oh! and I've been told Im not allowed to do any demos until I've finished XeO3....bummer :)

limiTED: Hard core fun!

I've been having great fun making some real hardcore demos for a new demo comp - my 1st demo comp in fact! limiTED was started and managed by Luca and has 3 catagorys: 64bytes, 128bytes and 1k. 64 bytes is about as hardcore as you get and is pretty hard to even start a program properly never mind do anything constructive, while 128 bytes you can just about do something nice. 1k is quite a lot, so your back into real demos which have to look nice as well as do something. The demos have to be anonymous for now so I cant say much more except its getting me back into 6502 fun land! So much so I hope to start back on XeO3 real soon... as soon as I've run out of demos to try and enter. I've never been much for doing cool demos, I've always been able to optimise and do stuff, but never come up with wierd shit that works well in a demo. So if I manage to do something, I'll be interested to see if everyone else thinks they're pooh or not.

Plodding on....

I'm still slowly progressing with wiring up the prototype, and I thought I was getting on well until I decided to finish one of them off - just to see how much more I had to do, and it turns out; LOADS! Oh well.... Onwards and upwards and all that.

I've been coding up a demo for Luca's new competition, and Im struggling a bit to fit it in. The original size was supposed to be 64 bytes(!) so I started working on that only to find out they had increased it to 128! DOH! Oh well.... Its nothing special, but I do prefer these smaller demos to the larger ones as you dont have to do very much, and it doesnt have to look too pretty.

I've also been speaking to Luca about the level2 on XeO3, so I may pick that up again soon. But once again, I've left it in a horrible state! Its got a pretty serious bug in there somewhere (probably the new sprite cache) which causes the whole thing o slowly get corrupted and crash. Bugger.

The wiring begins!

Nothing much new, except I've started the long boring process of wiring up my prototype. I've been dreading this as its going to be really dull, and take AGES! I've decided that rather than wire up one at a time, I'll do them all at once, this means I'll get the correct connection from the schematic, and then wire that wire 5 times. It should save going back and forth all the time so it'll be quicker, but even more boring! Oh well....

The scrollys a foot....

After putting the display on a timer interrupt as well, I've managed ti get the whole thing going. So now the whole thing is interrupt driven. I optimised the IRQ routine so that the delay between each packet has been reduced and the overall update increased to around 20ms (rather than 100). So I've now started to wire up the prototype I started a while back but it'll take a while.

I put a new nib on my soldering Iron, but its already starting to lose its heat conductivity. Im not sure why but I think I may have it too hot and its losing its "tip", but I dont really know - this is the 1st time I've used an iron this long!

Alas poor scrolly, I knew him well..

I can't beleive how stupid I was last night. Banging my head off the wall trying to debug by just reading the source over and over without any feedback at all when suddenly today, I got one of those DOH! moments. I realised that I already HAVE a simple way of debugging (well...simpler). I can display an 8x5 pixel graphic! Or numbers and letters! What an idiot. So, I built the numbers 0 to 9 and then was able to find out the flow the program was taking (much like you'd do with PRINT's in your code). So, after an hour or so I've finally got it to run - more or less. It does work, but at the same time it doesn't. Theres still something wrong with the interrupts as if I get 2 packets very quickly, then the whole thing locks up. But if I delay 1ms between each packet, then all is well. This sounds like its getting a buffer overrun error (or I cant read it quick enough error). However, for testing, a 1ms delay is fine, particually as I have 100ms between displays to waste. This gives 64ms to send the whole row of pixels - fine.

But alas no.... Because of the system Im using I can actually test what it would be like to send 64 packets, and the load on the first units is far too heavy. It spends soo much time doing comm's, it has zero time left for anything else - like displaying the image. It flickers like mad! This isn't good. It simply can't handle passing on that many packets in an interrupt.

So, it looks like I'll have to try and reverse things. I'll put the comm's in the main loop, and the display in the interrupt. The display is VERY VERY simple, and will consist of a timer IRQ where by it sets 2 port variables - and thats it. This means when it does interrupt the comms, (which only happens every 3ms) it won't be in there for long.

*sigh*....its never easy.

EDIT: actually... it might not be all that bad.... The reason for the flicker could be that the delay in the main loop is being extended hugely due to the comms taking up more time. (the delay is a simple CPU loop). So before changing everything, I'll try using a timer for the counter instead which will of course be independent of CPU delays....

Almost there....

I've spent a frustrating couple of nights trying to get my units forwarding the packets, but I've almost got it. Theres hardly any documents or pages about doing interrupt driven coms with pick so it's taken a lot longer than I'd hoped. I'm also sure that theres a compiler bug as some of the code I was trying didn't work when it should have.

However once I got that going, I was able to forward the current packet to the next unit and display it there. But when I tried to address both at once, it just didn't work. I can address the 1st one (where by it doesn't forward anything), or the second, where the data is sent via the 1st but not displayed on the 1st; however I can't sent something to the the 1st and then the 2nd in turn for some reason. It gets the 1st packet and then locks up....*sigh*

PIC programming.

You know, the more I do of this, the more I think I need a proper PIC debugger. Its a pain to debug code on a PIC, especially interrupt routines. I started to write the interrupt driven transmition routine last night, but I've been struggling with even getting it to start up properly. This is mainly because I couldn't even find out where it died! After an hour or so I was eventually able to get a clue as to which part I need to debug, and was able to use the LED's on my PIC programmer to figure out how far I'd gotten, but its far from ideal!

There has to be a better way.....

Its working!!! Scrolly delight!!

Yep! At long last (although to be fair, I dont work on it ALL the time!) I've figured out what was wrong. My theory about it overheating appears to be correct since I've attached a heatsink (pinched from an old ZX Spectrum!) and its now been running for around 10 minutes without a problem. The heat sink is hot, but not too hot to touch (perhaps a new modern one will work better), and now I can finally work on the slave to slave forwarding of the message packets!

The idea behind this is that the master will send a packet with a unit number attached (say 5), and each unit it goes to will check it, and if its not 0, decrement it and send it on. This means theres no unit "allocation" or built in ID, and they are all then addressable. The only thing Im not sure about is just how fast this will be when there are 64 units all chained together... whats that going to look like? I intend on pinching a game developement trick for this and doublebuffer the display so that every unit will get its packet, and then a "flip" will be sent to them all via a single line which they are all attached to. This should solve any ripple which might occur. The other thing which may work is to send them, last unit first. Since each forwards the last packet on, it would mean they would all get the packets almost at the same time.... I'll try this before I solder a "FLIP" commandline.