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.

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.

XeO3: Pausing to gather our thoughts...

Yes I know... I've not done much XeO3 stuff for a while. I'm actually busy learning electronics, something I've always wanted to do but never found the time (or books) to learn. However, I've now gotten some of these so I'm trying to learn the fundamentals just now and that takes time... time that would normally be spent on XeO3. This has of course given rise to some new possibilities. The whole reason for learning this stuff is so that I can build add-on's for my retro machines, and we're currently wondering if you can build a retro game cartridge cheaply enough that people would buy XeO3 as a cartridge..... Anyway, this is all a sideline just now...The new cache system still has a nasty bug in it and is currently corrupting memory, so I'll have to track that down soon, and then try and tackle the weapons system....so once I get over the initial electronics hurdle, I'll be back on XeO3.....honest :)

OOOooooo.....Interesting.....very interesting.....

http://www.xbox-scene.com/xbox1data/sep/EEyuFuZkpFZpCHcoON.php

U.S. Copyright Office issues new abandonware rights>>

Here's something abandonware enthusiasts can be thankful for: the Library of Congress yesterday approved six exemptions to US copyright. The one most pertinent to gamers is that, for archival purposes, copy protection on software no longer being sold or supported by its copyright holder can be cracked.What does this mean? Well, those retro games -- classic or otherwise -- that you can't seem to find anywhere can now be preserved without fear of ramifications. Although it is still unlawful to distribute the old games, free or otherwise, rarely do any abandonware cases go to court. The ruling is more symbolic than anything, but a step in the right direction.

XeO3: Please Wait....Loading............

I was testing out TNT's new 1581 turbo loader last night, and WOW! what a speed. The whole thing loads in less the 10 seconds! Thats 179 blocks (45k) that load in a blip! While speaking to Luca I had mentioned that if I thought that most folk had a 1581, then I wouldn't worry about packing in the front end to the main EXE as it would all load in under a second! Pitty...Oh well, I guess the only way to really guarantee that kind of thing is to make a proper cartridge game; which is also somthing I considered BTW. Using a cart as a large instant Disk would be very neat, and I do think I'll do an MMC64 version that does just that! Once

the C64 version is done, I'll start splitting it off into parts and putting them on a memory card so that it can act like a cartridge. This not only gives instant loading, but also a huge capacity. I wonder how many MMC64's have been sold? The good thing is that unlike the SuperCPU, these are still being sold! So if someone wants to play XeO3 from cartridge, they can run out and buy one! I'll have to do a little investigation as to how it all works, but from what I've seen, it should be easy enough.

I wonder how much these cost to make.... If you could get it down a bit, you could bundle one with the game and sell it cased so it looked like a normal cart - even though there was an MMC inside! Althought thats probably taking it too far.....

XeO3: Spectrum Wars....

I've been trying to fix a +3 spectrum for Russell today. I have 3 of them, but only 1 working one - and even that one isn't perfect as the load/save cable has been butchered to make a SAVE-ONLY cable. This probably happened when the socket broke. However, I've ripped them appart, took the working drive and put it inside one of the other machines (that has a proper tape connector) and all is well. So at least I have 1 fully working +3.

As for the others, well I discovered that on both disk drives, the belt has degraded too much and is now more or less just a blob of rubber. Fortunately I have 2 spare belts (no idea where I got them...but you can get them from ebay these days), and I've repaired both. But only one of them is actually fully functional. The other kinda works, but doesn't read anything. I suspect it might be the heads needing cleaned, but theres always the chance its just plain dead.

It was touch and go for a little on the working drive as when I opened it up, a tiny pin dropped out and I had NO idea where it came from - and the drive didn't work without it. But, after searching for a while on the NET, turns out its the write pin or something and I was able to plop it back into place.

The last +3 is pretty dead though; well....kind of. It boots, and you get the Copyright message at the start, but the menu doesn't appear. It just stays on the copyright message. I swapped the ROMS with one of the working +3's, and it was the same, so the ROM's are fine. I suspect its waiting on something, but I've no idea what. I have a multiface +3 and it can break in and works fine, so the Z80 is working okay as well. Oh, and if I reset and hold down BREAK, I get the test picture and the machine beeps away. Very odd. Still, I might butcher it so I can get a working tape connector on the other machine which now is working thanks to the 3rd drive having its belt replaced.

I've also discovered a really cool TZX 2 WAV program which converts TZX files into WAV files, which can then be played out the PC's audio and loaded in on a REAL spectrum! Very cool indeed. I've been busy taking snapshots of them and saving them to disk - its great seeing all my old fav's on the real machine again. And it's also shown that Cobra DOES indeed run in a frame.... After seeing Russell's scrolling code - I wonder how he managed that!

So, the next thing to probably try is chopping the end of a +3 lightgun and using that AUX port to download programs directly. I'm not convinced this will be terribly quick, but I guess at least Russell will be able to view his work on a real machine.

Edit: Oh....I did try Xeo3 on the +3, but it didn't work since Russ uses that 48k ULA hack. This means I'll have to hook up a real 48k spectrum to see it....Perhaps later :)

Retro TV.

THIS is an old BBC documentary about Imagine and Ocean... Pretty funny to see now, but I would have loved to have seen it back in the day.... Have a watch... pretty good fun.

XeO3: Father Ted....

Okay.... I've gotten the TED sound playing the main theme, although its been a bit of a nightmare.... it turns out that normally these operate at location $D400 - the original location of the SID on the C64. But add-on for the plus/4 is mapped to $fd40 (or $fe80), but when the card isn't there then this is just normal IO space - and theres no RAM there. This means it just doesn't work! What I've ended up doing is making a relocate routine that runs through SID music player and then moves the writes to the SID card to an area of memory the Frequency convertor can get access to. I've also managed to shrink it down by 50 bytes, but I've had to add the relocate routine... so I've uised up just over 1k for this.

However....now for the REALLY bad news! This routine takes around 16 scan lines to run, and thats on top of the SID player! This is very painful! So, if we run low on memory again, this is the first to go as it will slow the game down in busy areas.

Still, I've given Luca the mconv source and he can release it on +4 world at somepoint so others can use it. As I said earlier, the source lets you play around with it easier..... as well as relocate it and change the storage locations.

XeO3: Mr. Ted Sound

The current poll on plus/4 world showing that only 28% of users have a SID card has forced me to include the TED frequancy convertor MConv. This unfortunatly steals yet another 1024 bytes leaving me with only 3k in the main code block. I spent last night disassembling it and typing it back in so that I have a source version and can relocate it all easily. Once it's fully working I'll let Luca upload it back onto Plus/4 world so everyone can get some use from it. It makes it very simple to relocate, change the SID base address and basiclly fiddle with the code. I'll also be able to shrink it very slightly since there were a few NOP's and the like due to it being written in the monitor. Having done a full game like that, I can appreciate the problems involved....

Once this is working, I'll get back to the sprite cache and finish that off, and then hit the weapon system I think.

XeO3: The big push.

After a small break due to family, work and a cold, I'm now back on track and pushing down the memory to try and free up as much as I can for the last chunk of code. I've rewriten the sprite cache, packed the sprite data and done a general re-jig of the data layout. I've managed to save 4K which means everything can move up by a whole bank ($1000) and this lets me easily pack this 4K in with the current code and data, which brings the grand total memory free to 6.5k - which isn't bad at all. Of course theres still lots to do, but this should give me plenty of space to do it! The remaining 1.5k is right at the top of memory, which makes it a bit of a faff to use for most things - unless I can generate tables there.

So, now that this little(!) task is taken care of, I can start to go through my to-do list. If I get the weapon system working, Luca and I can try and release a test level which won't be used in the final game, but will give us feedback on difficulty levels from - well all of you. If you look at Luca's page, you'll see he did another level based on the level 1 graphics. This is the one you'll get to play with first.

But before I do all that, I'll need to test the new cache system and make sure its holding up okay, and then try and insert the code I took out before that actually makes the cache work properly. If that still doesn't work as well as I hope, then I'll change it all again and make it a simple queue.

It should also be noted that the remaining 6.5k is IT. There is no more free memory after this runs out, which means if I need more space, then I need to start cutting things out....Lets hope it doesn't come to that.