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

XeO3: ZZZZZZZZZZzzzzzzzzzzzzzzzz..............

Yep....did nothing but sleep again last night..Oh well... Just as well this isn't my day job.....

I have been thinking about the absolute limits of memory I can free up though, and I reckon I can claw back around 4k from various sources - tops. After that, I need to start cutting features.

   1k  -   Sprite Cache by seperating all the sprite data from from the sprite structure.
   1k  -   Sprite definitions. Just now there is a 16bit pointer to a cached rotation, 
           if I change this to a cache number, I can save 8 bytes per sprite *167 sprites, 
           but I'll then need a 300 byte look-up table, so gain around 1k overall.
   1k  -   Paths. I really dont think Im going to need a full 4k for the scripting. The levels 
           aren't that long really (compared to Blood Money which used 4k for paths as well),
           so I can probably cut at least 1K, possibly 1.5k
   1.5k-   Theres currently a free block right at the top of memory of 1.5k which Im desperately 
           trying to hold on to, but if push comes to shove.... it'll have to go too.

Now this is a fair bit to free up, and the sprite stuff will take a little bit of work but once done, that should set us on course to finish up the main code. wow....code complete...who would have though it... Still, not there yet!

The to-do list is currently...

  Finish Weapon system
  Finish loader with the new Turbo Loader
  Add loading screen
  Add High scrore table to the front end (top 10)
  Save High scores to disk
  Add TED music player - if possible
  Add multi-load for more levels (make sure its a variable number for skining later)
  Do a TEST level that we can release to help get the difficulty right.
  Make all levels
  End sequance - even if its a simple one

I think that about covers it..... Still lots to do, but we're over the hill and rolling down the other side.

XeO3: Another day, another feature....

I've been playing with the sprite routine again last night, and came up with a nice little feature that I'll use when baddies are shot. As you can see the sprites now turn completely single colour and flash when they get struck. On the C64 something this is pretty easy to do since each sprite has its own colour, so you can just flash that - but when drawing software sprites, its not as simple - this is in fact a whole new sprite! Or is it.... All I do for this is to use an inverse of the AUTOMASK and ORA the data into the display. The automask if you'll recall is a way of automatically masking MCM pixel data, and given any sprite the automask works out the data needed to MASK it on - so invert that, and you have your FLAT sprite.

Like everything, its not without its expense. It costs around 200 bytes for the code, and is slightly slower (when a sprite is over space) than normal. But it only happens every now and then, and being able to tell you've hit something is great, particually on baddies that take plently of wallop - or ones with limited collision areas - like a BOSS or something.

I also had to get Luca to swap all the colours to make use of it as it must use colour bits %11 or I have to AND as well.... Still, its a neat little touch so we'll probably try and keep it in.

Its also that time again, and I have to go hunting for memory once more. I've decided to rewrite yet more areas of the sprite routine - mainly the data structures as this should save around 2k overall - quite a saving. But theres a lot of work involved; I'm going to replace the cache pointers with a cache index (and a small table). Also, due to the way I move sprites up and down, I have 8 bytes at the start of every cache block to allow for a sprite to move down (I move the draw pointer up 1, the sprite gets drawn down 1 pixel mode), and because these are located directly beside the cache info, I have to repeat these 8 bytes all the time. However, if I split up the INFO structs, and the DATA itself, I can store 8 bytes at the start, and then remove all the others - again, a small table will probably suffice.

XeO3: Faster and faster....

The thing I love most about fully open development is that no matter how clever you think you've been, and how well you think you've written something, someone almost always comes along and improves it! It's not that I'm bad at what I do, or that the other person is way smarter; no, it's simply that a fresh pair of eyes and a different brain can pickup on small things you've missed. This is especially true if you've been staring at the same few lines for months trying to improve it. You're brain gets into a rut, and you just can't get past what you see. Open internet development gets rid of this by allowing anyone on the web to help. Sometimes the codes so obscure that no one can understand it - but thats fine, your no worse off... But other times, its a nice small snippet that someone points out something and you slap your forehead and say "why didn't I think of that!!"

Heres a case in point.... Some time back I was struggling to find a faster way to fire bullets, and it took me several days to come up with what I thought was the perfect solution - and to be fair to me, it was pretty spiffy. So I happily posted it for everyone to see and use. Heres the original...

FreeList db 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,$ff
;
; Usage:-  AllocBullet  [x|y]  Specify the X or Y register that hold the bullet to free
;
AllocBullet macro
    ld\0  FreeIndex           ; 3     ldx FreeIndex
    lda   FreeList,\0         ; 4     lda FreeList
    bmi   !NoneFree           ; 2     bmi !NoneFree
    in\0                      ; 2     inx
    st\0  FreeIndex           ; 3     stx FreeIndex
    ta\0                      ; 2     tax
    dec   BullInUse,\0        ; -     dont count this... its not in the new one.
!NoneFree:
    ta\0                      ; 2 = 18  tax X=next free bullet (or $ff for none left).
                              ; (best case=12) Negative flag SET on none left
    endm

Now, this was a pretty fantastic improvement over the original which was just a loop through "N" bullets. It was fast, it didn't matter how many bullets you had to allocate from, the time was linear. Great! Then along came TNT (who incedently is doing a cool remake of paradriod), who quickly pointed out that if I reversed the stack it would be even quicker - like this:-

AllocBullet macro 
        ld\0  FreeIndex          ; 3
        bmi   !NoneFree          ; 2 (best case=6)
        lda   FreeList,\0        ; 4
        de\0                     ; 2
        st\0  FreeIndex          ; 4
        ta\0                     ; 2 = 17
!NoneFree:
        endm

Now I had fiddled with the routine for some time, but had missed this simple switch, and this is the great thing about open internet development. My game goes faster, and I hardly had to lift a finger! While it appears to be a small change, allocations happen all the time, so if you can knock of a cycle, or make it early out quicker, then its all good.

Anyway.... the reason for all this is that I've been retro fitting all my allocators with TNT's new version, and it reminded me why I'm doing all this in the first place: Open Internet Development is good, for a retro scene - its vital!