Slow going....

You know C# is great and all, and you do code things faster, but the ground work reall does take some time to lay. I've found this at work as well where I use C# all the time, it just takes longer. When we started out current project it took us much longer than we thought it would to get the base application framework running. Of course once thats done you really do go quicker, and a few things are quicker right off the bat! I implemented a symbol table last night using my ISymbolTable interface, and using a few Dictionarys I was able to write it in about 15 minuets. In the past I've had to do a binary tree so I can do symbol lookups quickly, but Dictionarys in C# are very quick so I just dont have to worry about it.

I've also been slowly adding the basic 6502 dissassembler while at the same time trying to make it more C# than all the last versions. I've more or less just cut-and-pasted if from the old version (which is the same one I've been using since Minus4 DOS days!), so I want to make it a little prettier.

I decided a little while back that I just dont want to use C/C++ anymore unless i really have to, as C# and managed code is just so much nicer. I'm stuck with things like SNASM and Minus4 of course because they are pretty old and would be a major task to rewrite, and thats not something I want to do just now.

Anyways..... I'm slowly laying all the groundwork and I'm almost ready to start dissassembling stuff to the screen. Once I have that then steppng code will be the next big thing, but that appears to be a long way off for now. I'm actually looking forward to adding support for this to minus4 since while the debugger in Minus4 is actually one of the best in emulators, its still pretty poor. Also, once I have the module to do tracing in Minus4, I'll release that and see if i can't get someone to implement it in VICE and YAPE which would make my day.

(I also secretly hope that I can do a PC Engine module and get it added to Magic Engine, and possibly do a proper remote debugger for the real hardware too - one day!)

Debugger plugins

I've now got the debugger loading both CPU and COMMS plugins and have added a new ISymbolTable interface to deal with multiple symbol table formats. The idea obviously being that you can select different symbol table file formats that are independent of the CPU and COMMS control systems.

I've been thinking about the interface needed to both the comms and the cpu modules and I think a simplistic interface will work. I'll expand the CPU model to deal with breakpoints instead of the debugger just write break instructions, this does mean there will be an upper limit to breakpoints, something I didn't have to worry about before. Still, the monitor only has to have 2 for effective debugging, although MIPS debugging with a delay slot would be.... interesting. :)

I've also had to make an interface DLL rather than just have the .EXE hold everything, otherwise development would be difficult due to circular dependancies. However, its not amazingly important - just annoying.

Debugging....

Its just occured to me that if I modularise this debugger then it could be even more useful than just talking to a debug stub on a remote machine. If I have a UDP connection (keeping it as simple as possible), then theres nothing to really stop emulators adding this simple functionality either. Now I've been fed up with emulator debuggers for ages, all ofthem are rubbish and even Minus4's has quite a few issues due to the way I'd initially implemented it. So imagine doing a simple API where you can either write your own comms connection, OR implement a simple Serial/UDP stub on a remote machine or emulator and suddenly everyone could use this as a front end debugger to their own projects.

Now, I susupect it will take some time to get that API correct so it works across so many differnt machines/platforms but in the end it should be kind-of like DevStudio. It can plug into any system and do full debugging on it. As long as the debugger has a CPU plugin (starting with 6502), it can get a query for various high level things like get dissassembly (which could also return a source level view I guess), Step/Trace, Run, Stop, Get/Set Registers, Get/Set Memory, Get/Set breakpoints and all the rest - then it should be possible to make it completely modular.

I'll have to give this some thought as I carry on writing the new version.....

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

Come and get it!!

I've now added the C64 frame work (and sample app) to the downloads links on the right, scroll down a bit and you can't miss it!

So to recap what I've given you to play with in the framework....

Initialisation, mainloop and interrupts all setup and ready to go.

Production quality multiplexor

Three seprate switchable sorts.

Simple collision detection system

General sprite animation system.

Game based keyboard and joystick routines.

Simple player control framework.

Lightning fast 8x8bit multiply routine.

Simple random number routine.

Built in MMC64 FAT16 file loader.

Simple example platform engine showing the framework in action.

And there you go. As a little aside, the example also has a byterun decompression routine built in that you can use as well. Its all very simple really, but if you have any questions (or find any bugs) feel free to bug me about it.

Hope its of use to you and gets you going on your next great game!

MMC64 loader finished

I've now completed V1.0 of the loader complete with PRG file loading. Its shot up a little to about 900 bytes but it's now functionally complete. The only thing missing (which isn't vital just now) is error checking on initialisation. Its not important because if youve done a game thats supposed to load from an MMC card and its not there, then you have bigger problems! I've just ordered a retro replay so I can check all is well with that too (okay, okay...Coz it's cool...)

So tomorrow night I'll try and knock up a new downloads page somewhere and get all this up for you lot to play with. I'm not sure what I'll work on next but I like the idea of using the MMC card loader in the C64 version of XeO3.

I also want to do a proper Super CPU version of the loader so I can start playing more with that. I'd love to see how many software sprites I can pile on a bitmap screen, and I'd love to try that Lemmings idea too...

MMC64 cleanup

I'm putting the finishing touches to the MMC64 loader and making it work with more files. I've also shrunk it down a fairly sizable amount, with the code shrinking from 1,236 bytes down to 828 bytes (sofar) and the data block has shrunk from 624 to 568. While doing this I've optimised the load a bit so that the bulk of the file gets loaded directly into the destination rather than going via a sector buffer, which should make it twice as fast - in theory.

I'm pruning down all the "nice" bits and making it a bit more hard core C64 only - something I'll reverse when I do a SCPU version in the future. So for example while file sizes can be a full 32bits, we know a stock C64 will be less then 64k, so only work in that size.

That said I've tweaked quite a bit of it so it is a little bit more robust, but it will be likely to fall over if you use it wrongly, which isn't a problem as its not designed for a file browser, but a game that KNOWS what its loading. I've also decided to ignore long filenames, because again a game doesn't care! In fact, chances are you're filenames will be something like L1\1.PRG or LEVEL1\DATA.PRG. But this for a game is fine.

I haven't done a directory search yet and I might not for the 1st release as that'll put the size up again, still we're now sitting at 1,396 bytes total for code and data which is pretty good indeed. So for now you'll either put the game directory in the ROOT or specify something like GAMES\XEO3\LEVEL1\MAP.DAT. I have also yet to do PRG loading, so that it gets the 1st 2 bytes and loads it into the correct address - that will complicate things a little, but it should be okay.

I should also say I expect SAVING to come in later versions as well as its not hard to save to these things, so high score tables or editors can make use of the storage medium as well - which will also be pretty handy. Also...I do not disable interrupts, so technically speaking, you could be playing music, scrolling the screen or whatever while you load things. Also means the SCPU while taking time to load a meg of data can play music and display a loading bar or something!

So... only a little more to do for a 1st version, then I'll knock up antoher web page and post everything for whoever wants it.

Success!

I've now managed to load a file from the MMC64 given a full path+filename! Very cool indeed. It's a shame that you can't page in a ROM that has this functionality built into it. My plan of doing a Plus/4 MMC card was to have a built in ROM with lots of extra features built in like the Kernal, that way adding loading to a game would ultimately be very cheap and you wouldn't need to add all this code.

Still... thats a future thing, for now I need to test this code and load up lots of other files and make sure it all works. Im pretty sure it won't be terribly fast either as its pretty noddy code, however keep it simple and get it working - THEN speed it up and make it impossible to read.

The code is sitting at 1,860 bytes long (1,236 code and 624 data) so it would be nice to shrink this too. If the code can fit inside 1k that would be perfect I think. RAW loading is pretty simple, but including path searching and other features will push up the code space a little.

Anyway... all this aside, it's now working and is pretty cool. As a side note it should now be possible to load large files for my SCPU work; very neat.

MMC64 Progression...

I've progressed quicker than I figured I would and have almost got files loading from it. It also supports directorys and will load a file from a full path+filename (just about). It only uses 8.3 filenames so far, but I suspect it will get expanded to do more in the future.

It takes arond 2k to add this although 600 bytes of it is data and a sector buffer. I suspect this will shrink a little once its all working properly, but to have fast access to 4Gb's of data is probably worth the extra space.

I also plan to put in a recursive directory search, allowing you to search for a game directory and then load from there. That means people won't be forced to put everything in the root directory.

I will also write a full Super CPU version allowing you to load megs directly into memory, and MUCH quick than a floppy could.

Life after floppies....

I've spent a little time trying to chat up my MMC64, but it just won't respond to my tender words, at least I wasn't having much luck until about 5 minutes ago. I was following the documentation completely - cut and paste actually - but with very little to show for it. It then occured to me that since I'm loading from it, it must already be enabled and ready to go. So I've dispensed with the full initialisation and jumped straight in with sector reading, and what do you know! It works! I'm not quite sure what would happen if you have to re-initialise the thing as I can't seem to get that going at all, but as long as the cards in and you've just loaded the main program from that, its all funky.

For a first pass, not having any error state is probably fine, after all its not like you have to swap disks (err...MMC cards) during a game or anything, and if you remove the card then its probably your own fault. Still sometime down the line doing a better fault tolerant system is desirable - but lets get the bugger working first! I still expect this to be released in V1.1 of the framework, but its good to see it shouldn't be too difficult.

I've also added a simple animation system to the framework even though I said I wouldn't. I figured you can always rip it out, and in the end the ones I write are almost exactly the same over and over again so sod it. This means theres now the multiplexor, a few sorts, basic collision, animation, joystick and keyboard input and a very simple test app - which is a good start. Actually, theres 2 test apps. The Frame work has code to bounce sprites around in a simple manner, and then theres the playformer framework which gives a little more realistic usage. Still the more the merrier.

I'll now have to do another web page to download all this rubbish, and expand my wiki page to have some simple documentation...and I mean simple...

C64 framework V1.1?

I've thought of one more thing I'd like to add, but its not a quickie by anymeans so I'll leave it till version 1.1 so that I can get this version released. After speaking about using the MMC card as a loader, I suddenly realised that it would be awesome to have a proper file loader built into the framework. That way these no excuse as to not use it, and it'll make development MUCH simpler. Simply bung your files onto an MMC card in a folder or something, then load them - how simple would that be! It might also mean we would start getting some more games that load directly from the MMC rather than floppy/tape, which would be very cool.

I also suspect V1.2 will be when I start to add remote debugging features through RR-NET. As I've mentioned in the past I do have the beginings of a remote debugger on the Plus/4 and would like to get that onto the C64 but using the ethernet adapter rather than the user port. Although since the upload/download part is prett much GetByte()/SendByte() I can probably have both in case people don't have an RR-NET. It would be good to get a proper devkit again as I was reading about the old PDS system I used to use and starte getting a little homesick for it...

You can read about it HERE if you wish although its in spanish. HERE'S a translated version via Babelfish. It really was an amazing little system and I miss it hugely.


Oh and as a little side note, I've managed to get WWW.XEO3.COM again. I'd let this expire and some bugger pinched it which is why I went to the .ORG, but I've now got it back again so I'm happy.

C64 framework and sample

I've now finished the sample app that I was doing for the frame work; well, as much as I intend to. As you can see its a platformer in bitmap mode, and you run around collecting the bombs. Its basically a simple version of the first level in bomb jack (without the baddies). It uses the built in player-2-sprite collision routine as Ive been lazy and done the bombs as sprites, but it does help to show how to use the framework better. Also remember that I've only really spent a couple of days on the sample, so dont expect too much.

I've done it in bitmap mode because platformers should never really be restricted by character count or colours, so having a full bitmap is nice. It also let me have a pretty background, although it turned out to be harder than I thought at the time. I had to rip the bitmap off an old Ballistix floppy and then I discovered that I had stored it compressed! So I then had to rip the decompression code from Ballistix into the sample. Still it was only byte run so it was easy enough.

Anyway, with this done, I now only need to clean both up, write some very basic doc's and then upload it somewhere. Perhaps someone will even finish the platformer sample... who knows... It would be cool if you did a built in MMC loader and you could load each levels bitmap from an MMC card really quickly. I think any games you do these days should take advantage of new tech that everyone's buying, and that in turn would help sell more and move things along. If nothing uses a new bit of hardware, no one will buy it!

Last chance for anything to be added though. I can't think of anything, but feel free to suggest. I'm not sure when this will get released, but I dont expect it to be long now. Hope you all enjoy it, or at the very least have fun looking though the source...

Super CPU ideas....

Theres been several comments on the last post so let me go through them here...

First parallax scrollers. Games that have done these in the past have been limited to character blocks to do it's parallax effects and these have worked pretty well for the most part, but perhaps if you actually MASKED a full bitmap onto another you could produce something pretty special looking. Of course doing this would negate the use of the full attibutes as you would get colour clash... still dual playfields is always nice. You COULD stick to doing character based parallax and do a full bitmap scroller which would look pretty good, but not THAT much different from a stock C64 game using characters i suspect. This is what MetalDust does (I think) and its...okay... but we've come to expect games doing that kind of parallax.

Sprites. Now its true that anything I do I'll immediately load it up with as many software sprites as I can, and that I expect the screen to be crawling with baddies+effects. C64 games do this usually with lots of cheats, but if you can draw large sprites, you can push the boat out a little. However these will obviously suffer from colour clash again, which is never good. I suspect that if I arrange the bitmap better (straight rows rather than the funny character mode way) I can seriously increase the number of sprites I can actually draw. I'd then convert the screen on the fly as its copied down the VIC memory. Since the SuperCPU has a 1 byte write cache that gives me 20 cycles to get the next byte, and thats more than enough to convert the straight row format into the silly Commodore one. Of course on top of that, I now have 16bit registers allowing me to load and mask things on better, and upto 4Mb RAM (although mine has 16Mb, I think 4Mb is a good limit - anyone have less?) allowing me to pre-rotate everything at the start.

Now its also been suggested that you could do a full PROPER Lemmings game, and this is also true. You wouldn't be able to get the lemmings as the blue/white/green we all now and love, but a full white would be possible. In fact the best way (and to avoid colour clash) would be to use the full bitmap mode for the backgrounds and multiplex Hires-expanded sprites (on X at least) for the lemmings. That would have MCM resolution but it hires. Thats doable and gives a full dual playfield for drawing sprites + explsions easily. Not only that but because the SuperCPU can quickly multiplex sprites, you're only going to lose a few scanlines making this new playfield. On top of that... It only takes 7 sprites to do the playfield, leaving 1 hardware sprite for the cursor! Using the Commodore mouse you could finally replicate the proper lemmings game on the C64 - complete with the full 100 lemmings!

Lastly.... I suspect this will become a pet project and would be the ULTIMATE game for a SuperCPU, as theres no WAY a stock machine could even hope to do it.... GTA. Yup, I've been giving it some thought, and I think I could replicate the graphics engine I did on GTA1 on the SuperCPU. Im not sure I'd zoom in and out in the same way, but I think I can certainly do the perspective buildings... They may or may not be textured though... that Might be asking too much, but you would certainly get the effect GTA had of zooming around a 3D city... now that WOULD be cool....

Having a play.....

Okay, so I'm not doing my mini-game thing, I've been playing with my Super CPU instead. One question thats always got me thinking is what can you do with a superCPU that you can't do with a stock C64 (3D aside...).

Well, heres one: full screen overscan bitmap scrolling. Not using expanded sprites or anything, but using the full bitmap screen AND sprites in the side border. Now... I thought you might actually manage to do that with delayed DMA etc. but drawing into a full screen height would be virtually impossible surely, particually since you have to scroll through 4 sprites.

Well... okay... you COULD kinda do it... kindof... Imagine this...

FULL screen bitmap, delayed DMA scrolls that - great. Now how about the edges? Well, you need sprites there of course. BUT that means you've to smooth scroll through 4 sprites (2 on each side). Well no. Sprites can move in pixels after all, so just move in bytes and move the sprites in pixels to sumulate a normal scroll.

This still means you have to redraw the sprites though, and thats 4 sprites, (say) 189 pixels each. Quite a bit.... well...no...

IF you used another extra sprite on each side, then you can scroll the sprites and bring on new empty ones each frame too, then your only drawing 2 colums or sprites 189 pixels high over 8 frames (along with the bitmap) - which is perfectly doable.

Could make for a pretty cool C64 demo - standard MCM res, full screen/overscan scroller...neat. Course... since you can't change the colours very well in sprites, you'd have to pick 3 normal colours (sades of blue etc)... but still. You could also use character maps of course, which would make scrolling them much easier and would mean you didn't have to use delayed dma, as long as you double buffered the character map.

So the outcome.....A cool demo on a normal 64, and I still need to find an impossible task for the SuperCPU. It's pretty amazing what a stock machine can do if you poke it a little....


(and before you ask...no I have actually written it all, I've just been playing and know HOW to write it....)

Time for a quickie?

I've been playing with a bitmap to C64 convertor after several images I tried didn't convert very well. It seems for simple images the more complex convertors just dont gvet it right at all. Anyway, it was no more than a simple diversion but image processing is always good fun.

I've also started a little game and although I may not finish it, a sample app with realistic usage should provide some entertainment to folk. once I get a little further I'll post some piccys, but I wouldn't get too excited its just a sample app really.

Am I done yet?

I have now added some basic gameplay keyboard routines and a sample collision detection routine. I stress these are samples and need to be adapted for whatever game you might end up writing.

So what do GAMEPLAY keyboard routines look like? Well it doesn't scan the full keyboard for a start - that takes ages. You basically list the keys you want and it'll scan for them and set a BIT somewhere for you to check in the gamecode. This means you do minimal keyboard reading and spend all your valuable CPU time doing game stuff.

And how about the collision code? Well it's basically the same as I had in Blood Money, and have in XeO3. If you imagine 2 spheres colliding, to work out if they've hit, you subtract the centers and get the distance between them, then add the radii together and if the total of the radii is larger than the distance between the centers, they've hit. I do basiaclly the same thing but with squares. Each sprite has a center point and I subtract them (one at a time - no Square roots here!), then I add the two X widths (from the center) and compare with the distances between the X centers. If the 2 widths are greater than the to centers subtracted, then we've hot on X, if so we do the same with Y. For a little more speed, the X centers are divided by 2 so we can get rid of the significant bit of X - one less thing to worry about. SO! The current setup consists of:

16 sprite bouncing around with 3 compile time sorting options.

1 player sprite being controlled by the joystick (in either port)

A gameplay keyboard routine

Some basic collision detection.

And there you have it. If theres nothing else I'll start doing a little game of some sort or other and when thats done, I'll release it. Not that I really need to do a game though, but it'll give others time to ask for additions while I'm doing it...

C64 Framework...

So what I'm thinking, is that I should write a very small, very simple game using the framework so that people see how you could modify it. Even if its not a complete game to be honest, just something really simeple where you run around and shoot things, or pickup things or something simple.

So no idea what I'll write... but something....simple.... This also means I'll add simple collision detection that you can butcher to do something else later.

if you have any ideas of simple games that'll not take long (and I MEAN won't take long...) let me know...

C64FrameWork: Holy smoke Batman!

I've now added the sort Dan used in Armalyte as well, so theres now 3 different modes there all available as an option for when you start your game. To select them all you need to do is change a single equate value (setting it to 0,1 or 2) and the code will build the correct version (Try doing THAT with in a monitor!).

In the case of randomly bouncing sprites Dan's clearly win's out even over my shiny new one, to the sum of 42 freely bouncing sprites all on a STOCK C64. Thats damn impressive I have to say. However, I'll emphisis that it really, Really, REALLY depends on the game and how your sprites are setup, banded, spawned, moved and all the rest - BUT with 3 separate sorts now here, you should be in good standing to pick the right one without having to mess around. The image shown here is actually the worst case (the red bar taking up top and bottom borders), normally it only takes up the lower border which is superb.

I'll also make the point that this is a frame work. Its NOT a finish bit of code. You should take this as a basic core, and shape it to target your game/applicate better. For example, if you want to have a 2 player game, you should modify the code to multiplex only 6 sprites, or if you WANT to multiplex 8 to allow for a player with multiples above and below again you should extend the code to do so.

The code is pretty well commented but due to a couple of bugs in SNASM (namely nested IF/ENDIF's dont work) I cant get the code fully auto generating yet.

I've also now added a player sprite which is controlable via the joystick and flashes away over the top of all the rest. So, barring anything else being requested (and I'll give it a couple of days) I'll write up some doc's and release it next week sometime....

Oh, and as a little aside.... when running this on a SuperCPU without even coding it in 65816 assembly, it takes up around 16 scans in total - including ALL the IRQ's....

C64 Framework progress

I'm doing pretty well with this so far and have managed to get 30 sprites being multiplexed using 7 hardware sprites. I usually prefer to leave one sprite for the player so that theres never any danger of them glitching or tearing, and also that being sprite one they will always appear over the top of the rest of the sprites. However if you wanted to multiplex all the hardware sprites, it should be pretty easy to modify things to do so. I've ended up putting both sorts in just in case theres a case where the old one wins out which may be possible in some rare instances, but mostly I expect folk to use the new one. I might also put in Dan's one from Armalyte as it has a differnt range as well and may provide yet another option given a games unique circumstanstances.

If no one gives anything else they'd really like to see added, then I'll simply add a single sprite being controlled by a joystick and that'll be it really. What's here is a good head start for any new game, as a solid multiplexor is always first on the list of things to write. Thats not to say this is the best option for every game mind. In Ballistix (and also Morpheus if memory serves), I used fixed IRQ bands and a sprite was inserted into a band the "Y" coordinate fell into. This has the added advantage that the SORT is virtualy instant as its basically a bucket sort. Take the Y coordinate, shift it down a bit, and store it at the end of the bucket list. Easy. However this multiplexor is very flexible and will allow for large joined sprites to move in sync which a fixed banded one wouldn't.

I will at somepoint do this for the Plus4 as well, but I'll need to untangle the software sprite system from XeO3 first, and that'll take time. I also don't expect people to use 30 sprites either, but its what this can manage when pushed to the limit - unless your on a super CPU of course, in which case you can use it incredibly high. I will also at somepoint release a proper SuperCPU framework but I suspect theres less demand for that since theres only a couple of folk that even HAVE one!

C64 Framework

I'm currently cleaning up my new C64 framework and just now its pretty simple. A basic multiplexor with "N" sprites multiplexed (currently 16) and rasters going and I was wondering what else I should add?

Got any ideas as to what the basic frame work should contain? It should be fairly broad scope as theres no point in specialising stuff since it would get ripped out pretty quickly by anyone actually using it, but if you can think of some common stuff you always use, like keyboard routines, joystick functions and the like... then I'll probably add them in too.

So let me know what you think would be handy....

Back to work tomorrow....

I've had a reasonably fun week or so off, but it'll be back to the usual grind tomorrow which will mean fewer updates and less playing around. Oh well, its been fun :)

I'm currently playing with lots of different things just now, flicking back and forth as the mood takes me. Currently I've got my SuperCPU hooked up as I was playing with a true dual-playfield system. Its got 2 bitmaps and masks one onto the other if you can believe it! I've said it before but Metal Dust I don't think used the power very well and does look like just a nice C64 game. To my mind the new Enforcer 2 actually looks just as good but is on a stock machine. I think you need to do something really different - something that would be impossible on a stock machine, and I'm still playing around with what that could be.

The problem with TRUE dual playfields is that you can't make best use of colour, in fact your pretty much back to 3 colour displays or you end up with huge colour clash again, and thats not very SUPER. Also to make it simpler, you really need to manually smooth scroll the front layer and that means you can't make them up from a software character map meaning you can't have it all animating away which would also be a shame. Still, I'm working away on it...

On the C64 XeO3 front I've obviously been pluggin in my new multiplexor and speeding that up, although there is one more major speed up needed here and thats when I do the sprite copy to the IRQ buffers, I also copy in the first seven sprites, however these then immediately get copied into the hardware. This means an obvious speed up is to skip that and copy the first seven sprites into the hardware directly. This will slow down the copy a little, but not having to duplicate it will be a big speedup over all - I hope.

PC Engine.... I've almost got my assembler going although I need to add a few more addressing modes to deal with TEST #??,blah types. After that I can start to play properly, however my PC Engine has started to act up and it looks like its dying, so I'll need to find my TG16 in the loft at somepoint.

Lastly... XeO3 on the Plus4... After playing Blood Money a little again, I'm starting to sway towards the player dying but the action keeps on going. You then come back on flickering or something to give you a little bit of a shield and then carry on from there. This means you won't be thrown back to the start of the level, but you WILL lose some weapon power (not all). The reason for my sudden reversal is that after playing and watching Blood Money I realise that its gonna get hard later on anyway, so even if you don't get thrown back to the start, you're not gonna finish is easily anyhow - so what the hell. It will hopefully mean most folk won't get too frustrated early on, but it does mean it'll get pretty hard later on, which was to be expected anyway I guess. I'll try this out and get a few peoples feedback, or we might even release another test although I think that unlikely for now.

Oh... and a quickie. With the C64 codebase getting pretty stable, I think I'll be releasing a framework sooner rather than later. So it won't be the full XeO3 source yet, but it will be a nice framework for starting a game in, complete with a production quality multiplexor. People can then strip it to bits and bend it into thier own idea of a framework and make some toys with it..... we can hope.

And thats where things stand for now! Fun, fun, fun!! Any questions/suggestions/gripes/feedback, please just post a comment.

C64 raster splits

C64 sprites are great and all, but they really screw with your raster splits. Depending on how many sprites are over a raster, what character line we're on you may end up with virtually NO cpu cycles left at all! Looking up some timing info on the VIC (HERE) shows that BAD lines+ all sprites leaves you with less that 10 CPU cycles a scanline, and only 4 write cycles at the start.

Theres a few ways to get a cleaner split, but most use too much memory. However, I've got a reasonably stable raster for now and although it flickers a little now and then (when LOTS of sprites scross the panel raster) its mostly okay.

I guess the best way would be to count the number of sprites that cross then do some kind of variable delay depending on the count. Thats faffy stuff, and I could spent LOTS of time trying to get a clean raster split, so I'm happy enough just now with a basic flicker... I might fix it one day....

Actually.... If I lose the 1st pixel of the panel, the flicker won't be visible, thats probably the best solution.

EDIT: Well, removing the 1st pixel of the chars at the top of the panel actually works pretty well. I now have a solid raster split no matter what crosses the raster - cool.

XeO3: C64...

I've spent this evening plugging in the new sprite multiplexor sort to XeO3 which has given it a little speed boost as well. It's nice when all these things come together like this, bit of code here... function there. I've also sped up some of the other functions in the IRQ although these are all pretty minor. Still, faster IS faster...

I've had to start freeing up some zero-page though as I've started to run out. Right at the start I allocated 30 bytes for TEMP usage, and that was a bit silly, as it now means that temp+?? is used everywhere and its going to be very hard to reduce that count - even though I suspect that less than 15 bytes are actually used. Damn.

I've also shuffled some variable usage around so that most of the sort now accesses Zero-Page which helps with speed a little too. However, the multiplexor IRQ doesn't and that means its just a little slower than is possible, but ZeroPage is severly limited really so....

Sprite expansion....

You know I don't think I realised just how expensive X and Y sprite expansion was to the multiplexor. It's used twice (that I can remember), the reverse control radio transmitter, and the giant grab claws, and while its nice every sprite in the multiplexor has to store and process these bits! If I remove this feature the copy section of the sort is reduced by another 6 scanlines - SIX!!! Now that means each sprite pays around 1/3 a scanline for it in the copy which isn't much, but the more you have the more you pay.

On top of that we also have the display IRQ's which again has to pay the cost for only a couple of sprites in the whole game! Now I'm wondering if its worth the expense, or should I just drop those baddies altogether? Actually... only the CrabClaws need to be dropped (or reworked) since the tower would only require 1 extra sprite which is hardly expensive!

Anyway, I know when I was coding them I thought it was cool to allow expansion in a multiplexor as no one else did, and it allowed for HUGE baddies (oh..come to think of it, the level2 BOSS used it as well), but is it really worth the lost CPU time?

Quick tip....

So.... in the old days when I was trying to speed up a function, I'd change the border colour, mark in pencil where it was on the side of the monitor make changes and try and see if it was any faster - not very accurate I'm sure you'll agree. I had to make sure my head was in the same place (which usually meant marking the TOP and bottom of the bar), and with other functions marked in the same way, the monitor got a bit messy.

Now with emultors its even harder, they startup in a window and you cant draw on a TFT like you could a CRT, and I really dont want to draw on the side of it. I also used to use post-it's but again, its not very accurate. So what I do now is grab a screenshot of the first slow version and paste it into paintshop pro (or paint.net), then speed it up, then grab it again. Now I paste that as a new layer and apply a little transparancy to it so I can see the original through it - hay presto! I can see instantly how much faster (or slower) it actually is!

The image on the right shows timings for the new sort over the old one. The white+blue at the bottom is the new sort+copy, while the dark gray at the very bottom is the extra time the OLD sort+copy used to take. And if you copy the gray bit out, you'll notice its 9 raster lines (remember its double sized so 2 pixels = 1 raster) faster. Quite a saving, and VERY easy to see. I actually have an image with several old versions layered on so I can go back and forward through them easily which is pretty neat.

Minor increase.... But size isn't important...

Well, I've managed to shave 8 raster lines off the sort using the new system and it's all nice and stable now so I'm gonna stick with this new one. The good news is I'll be able to use this in the C64 version of XeO3 as well, so it's been a good couple days of playing. However, it's not the huge boost I was wanting, but its better than nothing! The new sort is shown below...

              ;---------------------------------
              ; NEW multiplexor sort
              ;---------------------------------
              ldx   #15
!FindFirst:   lda   yy,x
              bne   !FoundFirst
!BackHere:    dex
              bpl   !FindFirst
              lda   #0
              sta   yc
              rts                            ; NO sprites on!

   
!FoundFirst   lda   Anim_Current,x           ; if shape >= 200 then DONT multiplex
              cmp   #200
              bcs   !BackHere

              ;
              ; Found 1st sprite
              ;
              lda   #-1                      ; set first active as last in list
              sta   SPNext+1,x
              stx   SPNext                   ; and set first active as FIRST
              dex                            ; and move on one - we dont need to do the 1st one
              bmi   !AllDone
!SortAll
              ldy   yy,x
              beq   !DoNext
              lda   Anim_Current,x           ; if shape >= 200 then DONT multiplex
              cmp   #200
              bcs   !DoNext
              tya

              stx   xcount                   ; Sprite number we're inserting
              ldx   #-1                      ; pLast
              ldy   SPNext                   ; pCurrent
              ;
              ; X and Y take turns about at being pCurrent and pLast...
              ; The first itteration X=pLast, Y=pCurrent. The second is reversed.
              ;
!FindSpace:
              cmp   yy,y
              bcc   !InsertHere
              ldx   SPNext+1,y               ; get next
              bmi   !InsertHere2             ; Not end of list... so keep going!
              cmp   yy,x
              bcc   !InsertHere2
              ldy   SPNext+1,x               ; get next
              bpl   !FindSPace               ; Not end of list... so keep going!
!InsertHere
              inx                            ; allow for -1 when head of list
              lda   xcount                   ; Set last->pNext to be this one
              sta   SPNext,x
              tax                            ; Now move to the new entry
              sty   SPNext+1,x
              ldx   xcount                   ; Sprite number we're inserting
              dex
              bpl   !SortAll
              bmi   !AlLDone

!InsertHere2
              iny                            ; allow for -1 when head of list
              lda   xcount                   ; Set last->pNext to be this one
              sta   SPNext,y
              tay                            ; Now move to the new entry
              stx   SPNext+1,y
              ldx   xcount                   ; Sprite number we're inserting
!DoNext
              dex
              bpl   !SortAll
!AlLDone

So the idea here is that SPNext is a list of 17 bytes with 0 being the First in the 1D indexed-linked list. That way setting pFirst rather than an index is no different thanks to the inx/iny being used at the start of the insert code.
The only slight downer here is I need to loop forward to find the 1st allocated entry to start from rather than let the main loop do it itself. Still, its not really a slow down, just another bit of code to run.

The other trick is to run a paired inner loop. This lets me keep a LAST value without having to transfer it via A every frame, and that in turn lets me load A up with the Y value to compare at the start, and then I never have to reload it. It works pretty well although depending on the actual order of the sprites, timing may vary by a good few scanlines.

Multiplexor fun!

I've been playing with trying to speed up the multiplexor sorting, and I thought I had a much quicker way of doing it too. The old method was dumb, really dumb. I'd run through all 16 sprites, get the smallest Y value one store it, set it to $FF and then loop again until there were none left. VERY simple stuff. However that means for the worst case its doing a 16*16 loop, with a preloop of 16 to setup some values.

So, I though, "How about an insertion linked list?" Simply add a sprite index to a 1D indexed-linked-list at the correct point. Now, worst case shouldn't be as bad as 16*16 since you will only ever check with whats in the list already. Now for the 1st few, that means theres only a couple of entrys there, while the last few will obviously check to n-1(ish). Now this sounds all very good, and I'd hoped that it double the speed.... however, that was not to be. Would you believe for the worst case, its only about 1 scanline faster! Damn!

It's still not working 100% but its mostly there, and while the code is around 72 bytes smaller, its much harder to follow (since linked lists under 6502 are tricky anyway) so I'm wondering which version I should take....

After the sort I need to copy all the sprite data into the IRQ buffer for displaying, so thats another N loop as well. On the plus side, when theres not as much on screen its quite a bit quicker, and only gets bad once a load of things come on. I guess this means that when I'm displaying lots of character sprites and only a couple of H/W sprites I'd win out over all; still, worst case is usually the ones to watch for.... *sigh*

Optimising the IRQ's...

Last post of today - honest!

I was watching the timing bars on the IRQ's and had to again shake my head in appreciation of Dan's multiplexor, his trick of setting up a sprite if its already been displayed rather than kick off a new IRQ is top notch. I've added this to Blood money and you can see the result here. (Remmber I only multiplex 6 sprites, so theres more IRQ's needed than normal)

The bars on the LEFT are the old IRQ's, while the RED bars on the right are the new ones. You can see its almost halved the number and is happily packing them together thanks to about 6 lines of code. The multiplexor code is pretty slow really, and it was never unrolled, this means it has to keep track of VIC indexes etc. and thats not good. However, theres only 200 bytes free just now so I'd need to free up a lot more memory to be able to plug in the new one I've written for XeO3.

The saftly limit I've got in Blood Money is also 22 raster lines; thats the number of lines above where I kick off a new raster interrupt, while XeO3's magic number is 10! That means XeO3 can get sprites 12 scanlines closer than Blood Money which is a huge improvement.

Anyhow before I do anything major I need to free up memory... I think the front end takes up way too much, and all the fancy disolving characters (which was a fad at the time) also eats up space. Theres also lots of variables. I have space for 30 bullets here - and theres no difference between play and alien bullets! - so that should probably be cut down, and 12 character sprites which again I think could be reduced.

I also need to update the character sprite system as its not only slow, but embarrassing! The clipping is simply a loop to count how many chars are off screen, rather than just subtracting the thing! Stupid... Still I was young, I did that routine when I was 17 or 18!

Mmmm.... How thick was I!!

I do sometimes wonder what the hell I was thinking back when I was doing C64 stuff..... Now thats its all running I've been looking at the code a little, and some of its shocking! Now, I know commercial presures and all, but this was my dream game, and I remember thinking I was doing things so well.... But I really was young (only 19!) and I was doing whole games on my own - still, I was a twat sometimes.

The fastest code you can write, is code you can delete and never run, simple as that. Now the turrets in Blood Money are a case in point. It takes AGES to process and draw them, so with only a four on screen its taking up to 32 scan lines to process them! Thats ridiculous!! XeO3's turrets are a nightmare it has to be said. The scrolling is slower because of them, and when you hit them, its horrible! BUT! They're quick.... I never have to print them or really think very much about them until they shoot, or you shoot them. Here though, I draw them, do collision with them (bounding boxes) and then blow them up.... horrible.

Turrets should really be part of the landscape and drawn in there - like XeO3's, then you just dont have to worry about it. It would be trick in Blood Money because of the multi directional scrolling, and because the screen is drawn in 2 blits (theres actually 3 screens. 2 being drawn as they scroll between them, and a 3rd being built), but it is possible. Failing all that.... Im pretty sure you could at least speed them up!

More Blood Money from a stone....

I've managed to get everything back up and running properly now, well... except shops. For some reason they aren't being printed correctly at all. Turns out the multiply routine had a bug, probably a character removed by accident one of the times I was browsing away at the source. Anyway, that fixed the character sprites, and the circle script function (which was the other crash). So now the whole of level 1 is playing away fine and Im wondering what I can change first. I suspect I'll back up what I have working here as its taken quite a while to get it running again, but after that I'd like to try and put in a static starfield.

For now Im trying to replace the xply routine I had there as the new one I use in XeO3 is a third quicker taking only 119 cycle (worst) as opposed to 164. That will save around 32 scanlines in itself when all 16 sprites are in use doing the circle command (which is when the speed drops to a crawl). However its not working, and I'm not really sure why. Looks like the low byte of the result is wrong - very odd.

Blood Money Lives Again!!

I've been playing with trying to get my old Blood Money source to recompile off and on for a while now, and its finally rebuilding and running! Well, more or less. It still has some issues to be sure; character sprites appear to be killing it stone dead, and if I switch them off, I get a little further than then the game dies.

It's good to see it actually building and running though. One thing thats always bugged my was the crappy starfield I had on level 1 and I'd love to take some time and tune it up a bit. I'd also love to make a proper MMC64 version, one that loads directly from an MMC card - which would be cool.

Theres lots of things I did wrong back then. Shops weren't part of the background but drawn, as were turrets. Pretty stupid really as the only follow the screen - something the background map does pretty well without any extra CPU time. I'd also take away the 2 player mode and give that extra sprite over to the multiplexor. (Although.... a 2 player internet version would be interesting!) Theres a few areas where things glitch, and it would be nice to smooth that out. Talking of multiplexors, I would love to replace the one there and put my new one in as the IRQ is about twice the speed (I think).

I've also sped up the Character sprites a bit, and mu multiply routine (used for all the circle paths) is also about twice the speed. I suspect I could get it under 2 frames easily enough. Yes, believe it or not Blood money ran in 3 frames, with the main player ship running in the vertical blank.

So yes... theres lots of things I'd like to take a crack at fixing, although its gonna be tough as memory is down to a few bytes left! I've no idea how many sprites I used, but while I was aiming to get them all in, I think a redux-version could lose a bit to save memory. They were stored compressed then blitted down when needed. I might be able to speed that up or remove it completely.

Oh.... and get rid of that stupid front end screen....its pathetic... Not to mention the flickery raster on the game.

And don't worry.... I'm not setting aside XeO3 to do this, it's a project I'm doing in the background as I always wanted a console version of Blood Money, with nice dual playfields etc. and this is the first step.