New video...

I've uploaded a small video showing the current state of the C64 version. I suddenly realised I'd been sitting on it for ages and no one had really seen it.

You'll notice its not quite right, as background stuff isn't animating, and bullets aren't quite right. Still, it looks pretty, and the multiplexor holds up pretty well too!

Proper Remote Debugging

I've decided to continue my remote debugger I started ages ago with the view to gettting it up and running on the Plus4 and C64. I had to look around to try and find the source to the bugger but I eventually found it and was shocked to discover that it was in C++ and not in C#; bugger. This means I'll now have to rewrite most of it so that I can get it into a much easier to maintain format. Bugger.

That aside, I have also been looking at the actual debug stub on the plus4 side and its a bit ugly to say the least. I've decided to get it into a much simpler form so that its easy to get into a game. This involves jumping through a coulple of hoops but I've now (mostly) got it running inside XeO3. All I now need to add is a call at the very start of an interrupt routine to the debug stub and it handles the rest. Theres currently a problem with tracing as it doesn't appear to keep registers in sync but I can stop/start the game and try and single step. The image here shows what happens when I click the STOP button. Now once I rewrite all this stuff into C# I'll add symbols etc. so that its easier to use, then I'll try and get it working on the C64.

This may seem like a bit of a departure but theres a couple of very good reasons. First when coding the MMC file loader it was a NIGHTMARE to debug as no emulator current emulates the MMC hardware (pitty), and means that writing code for real hardware becomes much simpler. Secondly it means I can extend it and actually debug SuperCPU code which nothing emulates currently. This is another major advantage and again helps speed up development hugely. I've lost count of the time I've lost because all I could do was change the border colour, or print a hex number when things go wrong,

Now this is likely to take some time to write (and port) but I expect it to be time well spent, and I'll then release the debugger and debug stub to everyone else. For the time being I'll carry on using the user port (since it allows you to program the SCPU or MMC etc.) but at somepoint I will try and allow the RR-NET as well in case you want to debug code for the user port! As a little side note.... If I can create a Plus4 ClockPort, it means I could use the RRNET on that as well, and that would let me do an MMC card on the USER PORT, which is so simple its not funny! Since the Plus4 has ROM space internally, you could supply a userport MMC card and a ROM for all basic functionality without any real problems!

So..first things first.... Get the debugger into a workable state.....

Slow progress....

Well, after listening to the Scotland v Italy match on the Radio I'm wondering if I'll ever speak to luca again!! Oh well, its our own fault - as usual. We should have beat Georgia. Everyone was complaining about the refereeing, but I think it swings both ways. Never mind....We've improved loads and had a great campain - Well done Scotland! Ya done us proud!

Oh well, after that how have I been doing...... slowly. Not had a lot of chance to do much, but I hope to do some more paths tonight. I really hate doing them, but Luca (SPIT!) is still learning the script so I'll be doing these one, but I hope he can start doing some for the actual game.

I was also thinking about the MMC card stuff. I really screwed up here. By not doing a schematic first, I have no idea where all the wires are going, so now I either need to start again, or revese engineer what I had started. Im also thinking I need to do a Plus4 user port version so that I can test out code and allow SID usage. A userport card would be much easier, and if I supplied a ROM (or ROM image) then it could still boot properly.
It does mean this version wouldn't have the clockport so couldnt' do the ethernet/serial addon's. Im still trying to get a milling machine what would let me make real boards, and if this was possible then I could make the card here....Oh well... Still lots to do first.


Oh, and theres a new POLL. The results of the old one were pretty predictable with no one really interested in an external RAM expansion.

XeO3: Demo level progression.

I'm slowly progressing with the alien waves for the demo level and I think it's going okay. If I play without wanting to power up, you can more or less run through without getting hit (so far). But if I get greedy and want all the coins, then it starts to get tricky; which is the idea.

I've mapped out about one third of the level, although I've extended the start a little to make the introduction a little simpler - mainly so theres no backgrounds while you get used to moving around.

I also fixed the 2nd bug in my list from yesterday, where the collision radius wasn't being used.

So.... the demo is progressing slowly. Slow but steady! which is of course better than it has been; stopped and dead.

XeO3: Demo level....

I managed to get Luca to send the test level again, so I've now put that in and have started making new alien wave's. Heres the current plan for the demo.

1. Have the front end as is
2. Only have 1 weapon type but allow you to power it up.
3. Have the full weapon power up/down sequence


4. Only a couple of baddie types.
5. fix all current bugs before release.

Speaking of bugs, I've found another couple.

1. If you shoot a "group" of sprites too quickly, its possible to get multiple pickups. A group is only supposed to leave 1 item.
2. The baddie radius isn't used! This means all baddies have a fixed bullet collision area
3. If you collect a weapon pickup you appear to lose a bullet.
4. 2 character wide bullets don't always appear to hit baddies.

I've fixed the 1st and I'm about to fix the radius one, but I'll fix the rest later. I want to try and get some paths going.

XeO3: Demo level

I've been hunting around trying to find the demo level Luca built, and unable to find it, I went back to Luca's web page to see what it looked like. I was somewhat shocked to discover that he actually made it just over a YEAR ago!! So much for 2007 being the year of XeO3! I've done even less this year than last year! bugger.

XeO3: Here we go again.....

I've not done nearly as much as I'd hoped on XeO3 this year. I was convinced THIS was going to be it's year. A few things got in the way, my new found electronics hobby - which should still prove interesting to others once I start to finish things, and the fact I HATE makeing levels. Always have. Hate it! Hate it! Hate it!

But I think at the VERY least, I need to get the test level done so we can at least make some progress. For those that don't know, the plan is it make a 1 level demo with simple graphics but the game playing. This lets us (Luca and I) test the game mechanics out and at the same time, make sure we're not aiming to high (or low) on the difficulty side.

So...... to this end, I've decided to try and force myself to produce a new 1 level playable demo, and to release it AT THE VERY LATEST for Christmas. I really hope it'll be WAY sooner than that (a couple of weeks would be better), but Christmas at the latest.

Then once I get some feedback from everyone that's played it, we can both start to try and put the final game together.

..........well, thats the theory. So hands up if you believe one word of it?

Ready.....set.............GO!

Almost time to go, Im collecting all the bits I need for the trip, including minus4 source and of course XeO3. I dont think I'm going to get much done, but I hope to at least fix the bug thats holding me up. I'm also taking the RetroEdit source and might try and get basic editing done - I hope so at least.

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.

XeO3: Comments

Its funny reading some of the comments about the video, many of them seem to wonder why I'm doing it - so I thought I'd answer.

When I started coding all those years ago I did it for fun, nothing to do with money or a career (although it was a distant hope), but plain old fun. Years later when I started coding profesionally, I was pretty good at at because I'd spent years getting good at optimising things and making things fun.

Now...fast forward to today. I spend all my profesional time working on high end PC's/Consoles doing the games that these people say we should be playing and something is missing. It's been brought up a couple of times on the DIGG list. Machines are so big and powerful, we just dont need to take the same care and attention that we once did. Microsoft Windows being a case in point; it swallows virtuall all power from the latest processors and we hardly ever feel the upgrade the way we used to. We've lost something.

So, aside from the huge amounts of fun I get from writing of limited systems, and remember that this doesn't JUST mean retro machines that we won't let die but things like mobile phones and whatever the latest limited system is - theres always going to be a new one. I learn lots of new things by working with these systems. If you work on systems that are hardly ever taxed, that are heavying with memory, and have huge resources, then its hard to learn optimisational tricks any more. Working with these smaller machines keeps our minds ticking, thinking and working so that we can use these tricks when we need them on real projects. These days, it doesn't take a programming god to make a game that looks okay, but still you have to be pretty good to push the machine; its just harder to know that you've reached that limit and its not that you've just turned into a lazy coder.

Necessity really is the mother of invention. If you dont really need it, you'll never discover it.

XeO3: Editors.

I'm taking a small break to play a bit more with my C# stuff. I've gotten the Plus/4 sprites loading in, so now all I need to do is scale them. But to see the results, I thought I'd extend the program I was doing into something a little more useful. Something that can load in sprites, characters and XeO3 style maps. I may even add editing to it at a later date.

Once I have the drawing working, I'll write a quite scale function that'll allow me to save out full size C64 sprites - although they'll be a bit rough around the edges. The biggest issue I have with XeO3 on the Plus/4, is that I can't view or edit sprites easily, Luca has to make little Plus/4 programs that show his work animating in a self contained PRG, which is far from ideal - so I hope this will help a bit more.

Level editing is also a concern as the current one was created by "FatMan", and he has long since vanished. So now we really need to be able to create one outselves, particually if we want others to make new levels or even games out of it.

I'll have to watchout when doing this program, as the temptation is to make an all singing all dancing app, which will take longer to write than the game itself. If I was doing an editor to "sell", I guess I would make everything variable and portable. But the idea is to keep the goal in mind, and not get too carried away with what should remain, a simple XeO3 editor.

XeO3: C#

So, I thought it was about time I got the full benifit of the Multiplexor, so I'm about to do a small c# program (my latest language of choice) to convert into the proper format, and scale it up to the required size. Now the aspect will obviously change, and it will look a bit naff.... but it'll help "fill" the screen with sprites AND give me a basis for converting over Luca's art in the future.

On another note, I was speaking to TNT over at Lemon64 and we got into chatting about old programming diarys from ZZap days, anyway he reminded me about the Citadel one as well as the Morpheus one I've just read. I seem to remember this one being pretty cool to. He's currently doing a supped up version of Paradroid and I'm trying to persuade him to do a diary as well. I love reading techy stuff like this, and I'm sure others do to. These days games are such a closely guarded secret that you never get to hear the gritty details which is a shape. Also things are now so complicated that it can take weeks to do the smallest thing which doesn't make for good reading.

If you have an opinion on this, or if you like reading this kind of stuff, then let me know and perhaps I'll start to try and push more people to keep retro coding blogs.

XeO3: A job well done....

Okay, I spent a little bit of time optimising the IRQ side of the multiplexor, and I can now get a sprite within 10-11 lines of the other set. Thats not bad, not bad at all (I seem to remember Blood Money being almost 20). This should be more than enough for a game. I more or less copied Dan's IRQ model for this (although I did a macro with some paramaters rather than having to maintain a whole chunk of code) and I've gotten it down to the barest minimum I can get away with. Heres the macro I used, which if you compare with Dan's, you'll find it quite close with only minor changes. If I had a couple of these, I could save an extra 4 per sprite - but thats excessive :)

;
; \0 = sprite number ( 1,2,3,4,5,6,7 )
; \1 = x+y offset ( 2,4,6,8,10,12,14 )
; \2 = NEXT sprite ( 2,3,4,5,6,7,1 )
; \3 = "b" for bcc or "j" for jcc
;
sub_amount    equ     10     ; number of lines before a sprite needs to be setup

SetUpSprite macro
DoSprite\0:
   cpy  #\0                  ; is this the Hardware sprite we're after?
   bne  NextHWSprite\0       ; not THIS sprite ->jump to next

SkipCPY\0:
   lda  XTable,x             ; Store the sprites "X" coordinate in the
   sta  $d000+\1             ; VIC hardware sprite register

   lda  $d010                ; get all sprite significant bits
   and  #~(1<<\0)            ; mask OFF this one
   ora  XSig,x               ; already set for the correct bit!
   sta  $d010                ; so we OR in this sprite and store it!

   lda  YTable,x             ; Get sprite Y coordinate
   sta  $d001+\1             ; store in VIC hardware register

   lda  XShape,x             ; get the sprite graphic
   sta  HWShape1+\0          ; Since we have a double buffered screen, 
   sta  HWShape2+\0          ; we store it in BOTH locations.

   lda  SprCol,x             ; Get sprite colour
   sta  $d027+\0             ; store in VIC hardware

   inx                       ; next sprite in list
   ldy  #\2                  ; next hardware sprite

   lda  YTable,x             ; Get sprite Y
   jeq  EndOfSpriteList2     ; 0? If so all finished
   sbc  $d012
   cmp  #4                   ; do we HAVE enough time for another IRQ? (magic number)
   \3cc SkipCPY\2            ; if not do it now!

   ;
   ; If we've lots of raster time until the next sprite
   ; but the sprite we will be copying over was already drawn
   ; by the VIC, then just copy it over NOW!
   ;
   ;sec                      ; Carry is ALREADY set
   lda  $d012                ; Get the current raster
   sbc  #22                  ; -22 gets us the last "safe" sprite
   sbc  $d001+(\2*2)         ; location. Now subtract the next sprite Y
   \3cs SkipCPY\2            ; is > last sprite, then setup NOW!


   ;
   ; If its further down the screen, and the current sprite
   ; is still being drawn, then setup a new IRQ just above the 
   ; sprite to handle it
   ;
   ;sec                      ; dont set carry, we'll offset this in the SBC
   lda  YTable,x             ; if we can't copy now, then we set up
   sbc  #sub_amount-1        ; a new RASTER IRQ based on the next sprite (-1 for SEC)
   sta  $D012                ; and its Y coord.
   jmp  EndMultiIRQ          ; and then this starts all over again!

NextHWSprite\0:
   endm

I may not have mentioned this to the C64 guys, but once the game is finished, I plan on giving the source out, along with some documentaion that should allow others to either skin it quickly into another shooter, or to hack it into something completely different. I've always thought that the main problem with the scene was that good games take time, so no one can usually be bothered to make one - and when they do, they feel completely attached to the source and want to keep their master-peice. So I decieded from Day 1 of the Plus4 version that it was all going to get released. There no money in it, so why hold on to it when it could do so much good the scene.

That supercpu shoot-em-up is a good example - I wonder how much they actually made from it.... whats the point? I'm even trying to keep the comments up to date!! So don't say I'm not good to you all!!

Also, if theres anything I've touched on that anyone would liked explained, then just drop a comment letting me know, and I'll try to post something more about it.

XeO3: Multiplexor V1.0

Well, the first version is done and although it still needs seriously optimised, it's in and working. I ended up using a slight hybrid between the one from Blood Money, and Dan's one from Armalyte. I loved the way he gathers sprites into blocks IF the hardware sprite your going to overwrite next has finished rendering, then it doesn't bother with a new IRQ, it just does it anyway! Very cool. I'll probably unroll the multiplexor IRQ and that'll help me get sprites closer to other ones. It looks like I'll have to redo a few paths from the Plus4 as they are a little close for the multiplexor (since they're 16x16 and not 24x21); theres an advantage to having software sprites... Still, it'll probably make the games a little different so you can have fun playing them both!

I'll probably try and get a C64 teaser done soon now, but I still have a couple of bugs to fix on it - and the sprites are still all actually only 16x16, even though its displaying 24x21! I might just "scale" them for now, just so they fill more of the screen.

Luca has also said he's not really interested in doing any changes for the C64 version - he's a Plus/4 man through and through, so nearer the time I'll be on the look out for a dedicated C64 artist to add some spit and polish.

Xeo3: Vice...

Well, thanks to the comment made the other day, I've managed to add symbols to VICE. Since I use my own assembler, it was a quick 10 min job to get the symbol table exported in the VICE format. This does help when trying to track down odd bugs so its very much appricated - whoever it was (names on the comments would help!). Although not being able to have a memory window is prehistoric!!

I've got the basic flow of the Multiplexor in, so now I need to test the start of it, and then start generating interrupts. I can test the beginings since I copy in the first 7 sprites in the list to save having to do early interrupts. Its also a good way to start, it lets you see if things are progressing the way you expect.

Xeo3: Multiplexor...

I've been sitting here playing with a C64 multiplexor - boy has it been a long time since I did this! Actually, reading about Dan's one from Armalyte is what got me doing the port in the fist place. Armalyte was probably the best looking game to come out on the C64, so I had a read through his source and got back in the mood. Pretty interesting it was too, I'd never really used the stack much since I tended to stick to zero page lda/sta as it was one cycle quicker, but his multiplexor sort approach was novel. So, I did some tests on it and compared it to the one I had in Blood Money... His varaied quite a lot and either gained a few scanlines or lost a few depending on sprite order etc. Mine is pretty much static (unless theres < MAXSPRITES on screen, in which case it gains) so I've decided to stick with mine for now, particually since it does a proper sort, while Dan's is an approximation (which is usually good enough for a multiplexor).

So now that its all sorted, I'm just about to start on the actual fun stuff! Building new raster interrupts based on where a sprite needs to go. When I first used this in Blood Money (after hacking Armalyte to find out how he did it), I thought it was very cool indeed. In fact, it took me a while to actually believe thats what he was doing - very cool stuff. In Ballistix, I'd gone with a static array as documented by Braybrook in Morpheus, and since I HAD to control 32 sprites for that, it was probably a fairly wise course of action. But for Blood Money, I could use something more flexible, and after seeing Armalyte, I just had to know how he did it.

Anyway, I'm about to do it again. I'm not quite sure if I'll follow his IRQ routine either, as I hate maintaining large unrolled loops. Im sure at some point in the future I can unroll it if I need to.

OH! And I've just discovered a 4th C64 that I have, and its the older ones with the original SID chip in it, so I can at last listen to all the old classics on the machine itself! Ahh...bliss.

Xeo3: Sprite time...

Luca's given me a new batch of sprites to bundle together so while I've been doing that, I've also been updating Luca's scripting build so that he gets all the latest features. While doing so I've fixed the parent+child system. This allows small sprites to be joined and act as a single BIG sprite. Luca's been playing with a large mid level baddie, but it wasn't working right. Turns out when I had rewriten the killsprite routine I had inadvertantly broken the link system. I'm not terribly happy with the fix however, as it means I have to loop though all the sprites every time one is killed. Its not the end of the world, but I dont really have any spare FLAG bits to enable me to fix it.
I've only 2 left, and I think I need these for other features. Luca wants to be able to orbit baddies around parents, and I'll need a flag for that, I also need a flag for something else...but that escapes me just now. I may well have to admit defeat and add another FLAG byte, but I really dont want to do that.

I got my Retro Replay today!! Very cool! I think I'll probably get the RRNet and SilverSurfer add on as well as it'll let me squirt stuff down rather than having to copy it to the MMC card all the time. Using a RetroReplay and the MMC64 I can now mount a D64 image and read it like a normal disk, which is very funky - its now a pitty that so many have "custom" loaders that dont work with it! At least Blood Money and Ballistix seem to, well... they manage to load, but blood money then crashes when you start playing, no idea why - seems to have all the graphics and code it needs.

Xeo3: Playing shuffleboard with the C64....

I've been shuffling around the C64 code and data for a couple of reasons really. 1st It means I can use the music as is without having it relocate it, and second buy changing the VIC bank to $4000-$7fff it gives me a few extra sprites. It got me going for a while though until I discovered a bug in my IRQ code which was always setting a bit in the screen address, this meant I could only have screens at $0400 and $0c00 and it took me a while to track down exactly why this was. Vice came to the rescue with a reasonable debugger, although I really wish they would add some basic symbol table support. Being able to put a breakpoint on a label address is a godsend! Anyway, bug fixed, code and data all moved around... and I now have 160 sprite slots, and a few more above the panel.

I also workout out that if I changed the format of the +4 sprite a little, I could squeze in 199 sprites, quite a bit up on the 167 we already have! It depends if I get around it it... its not a huge change as it just involves making a 300 byte xply table and changing the cache pointers from pointers to indexes (theres only 147). But that would save 8 bytes per sprite * 167 sprites... a lot! I hope I get a chance to make the change, although Luca might not thank me, he already has a lot of space to fill!

XeO3: C64 sprites....

I'm having a little coding break at the moment. I thought I'd have a quick play and see how much bigger the sprites feel when theres a proper C64 sized one in the level. It's not a lot bigger really, but I suspect a few of these larger ones and it'll start feeling a little cramped. I was pleased as punch when I discovered an old copy of Tony Crowthers 3in1 graphics editor that I used to use, it does sprites, characters, backgrounds and has a scratch page for playing with ideas.... great little C64 editor. I've not really seen it on the NET anywhere so I really should upload it somewhere for folk to use, coz it really is fab.

XeO3: C64....

Not a bad evenings work! I've managed to get the sprites converted over as well! Although at somepoint I guess I'd have to get them redrawn since they are only 16x16 but still, it looks great with the added colour! I'll probably release a C64 teaser in the near future as well, lets see if any C64 guys get interested :)