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....

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.