Progress? Who knows....

Here's another little test app and this one's pretty simple, but it does show up the flaw.

58C9  CE 15 FF      dec $FF15
58CC  EA            nop   
58CD  EA            nop   
58D0  00            brk   
58D1  EA            nop   
58D4  EA            nop   
58D5  4C C9 58      jmp $58C9

Now on entry to the debugger I adjust the stack to point to the BRK instruction so that we know exactly where its stopped. This works fine. But on exit I expect it to re-execute the BRK and not do anything, however this one does not. When I run it again the screen colour changes, and its not supposed to. I suspect this is the problem, BRK's are not being restarted properly, but at least now I have a test case, I should manage to fix it easily enough - I think.

Trouble ahead.

I really am struggling with getting this thing to single step properly, its a nightmare! The actual monitor code is pretty easy but I think I have something wrong on the stub end that means its just now working right. I have a single breakpoint that I place after the current instruction (lets ignore branchs and calls just now), and I then resume execution. The idea being that it runs a single instruction and hits the new breakpoint (however its been implemented) and jumps back into the debugger again.

The problem is, its just not working like that. Now RUN and STOP work great, so I know jumping in and out the debugger is fine, and I have tested BRK instructions as well and they are okay too. Whenever I hit a break I subtract 2 off the PC (as its moved on entry to the interrupt routine), and I can then resume again.

So far so good.... but if I drop in some more BRK's, they don't seem to be getting hit properly at all. I can't of course debug the stub either so I'm left with just looking at code. I suspect I'll need to start a new, simple project to try and figure out why its not working, as staring at code doesn't seem to help.

So heres the loop Im trying to debug, and its interesting coz aside from not doing much, it shows up several issues.

58D1 CE 15 FF    dec $FF15
58D4 A9 01            lda #$01 
58D6 A2 02            ldx #$02 
58D8 A0 03            ldy #$03 
58DA EA               nop   
58DB CA               dex   
58DC D0 FC            bne $58DA
58DE B9 00 10         lda $1000,y 
58E1 88               dey   
58E2 4C D1 58         jmp $58D1 

First, if I try and single step $58DA, the whole thing dies a horrible death. IF I try and step $58D6, then $FF15 is increased and Y is decreased to 1 (which is impossible).

Its all very odd, but there must be a logical solution - somewhere!

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

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