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.

XeO3: Sprites....damn them....

Well, Russell and I have discussed this cache problem at length, and came to the simple, resounding conclusion - I'm a moron. When I started doing the sprite routine some 6 years or more ago, I hadn't done any real 6502 in anger (as it were), for over 10 years before that! And when I designed it, I used normal structures of things. This is bad. In 6502 you really want to use the index registers and multiple arrays for structs. Like this.....

  struct
    dw  Next
    dw  Last
    db  index
    db  flags
    ds  8
    ds  72
  end

But instead, you should really do this....

NextIndex   ds  140
LastIndex   ds  140
index       ds  140
flags       ds  140
GfxLo       ds  140
GfxHi       ds  140

Now, you really have to wonder why I haven't clicked with this before since my scripting system does just that! Well, now that I know, I'll make it part of the rewrite of the sprite system, but this is a pretty large undertaking and will take time...... bugger.

Anyway, even after I do all this Im still not sure I'll be able to use the cache to its full. Even at 40-50 cycles, thats almost a full scanline, and with 10 sprites, thats a lot to waste every game cycle. With a simple circular list, you only lost around 20-30 every minute or so....

Doing this change will also allow me to remove the redundent 8 bytes in each sprite-cache block, which will help save space overall.

XeO3: The Sprite Cache.

I finally got around to visualising the sprite cache, and in doing so I was in for a shock. It wasn't working! Well, not the way I'd planned. When I originally designed it, I had intended for sprites that were used a lot to stay in the cache, so I'd used a doubly linked list so that I could unlink and entry and place it at the bottom. This would then keep it as far from the TOP (which is the next free slot) as possible. Its a simple idea that works extremely well when used with textures on the PC. However, mine wasn't working - in fact, all that was happening was I was operating a simple queue system. It came off the front, and went on the rear. This means that when enough baddies have passed, I have to recache the graphics that are still in use - like the player ship. This wasn't the idea at all!

So, I added the missing code to push it down to the bottom of the stack where it would stay until it hadn't been used in ages and then it would get freed and used again. However...being a ful 16bit doubly linked list - it isn't quick, and sprite engine takes a hammering because of it; way too much in fact. So now I'm left wondering if I should in fact scrap this idea, and just use a simple queue. This would help speed up allocations, but I'd still have the same issues I have now - which you don't really notice anyway!

I'm just not sure.... the whole concept of the sprite system came about because I wanted to use the texture cache idea to help keep things fast, and now thats the code thats slowing it all down!

Bugger.....