New we're getting some where!

So with most of the ground work done I've now managed to get registers from the client and can dissassemble the current view (as shown). I'm using a rich text box (after some head scratching) and it appears to work fine. I have a stack of new interfaces and classes that people will use to write their own debugging aids, and Russell says he wants to do a Z80 one and plug it into my noddy spectrum emulator. (which I had forgotten all about). This means when I get the basic one going, he's going to write a TCP/IP (or UDP) version and that can be given away free for folk to include in their own code. These stubs will be in C++ so most emulators should be able to use them.

I did start to port my spectrum emulator over to C# but never got around to finishing it - perhaps something to do on my next holiday.....

So the current state of play is I can stop the target, run it again, and get its registers and a dissassembly view of it. Next I need to be able to STEP an instruction, and then things will get really interesting! While you're using a PC to debug the Plus/4, its easy to forget that it's a slow beasty and the more watches, memory windows and the like you have, the slower its going to go! downloading all that memory will take time! So if its too slow, closing a memory window will probably speed things up quite a bit!

The debugger is also designed so that one day I can add source level debugging as well. This means you can step through your actual source code and not just some abstract view. It also means you'll get all your comments while stepping and viewing code. This will be pretty cool indeed. Minus4Dos actually did this. It was the last feature I added before stopping its development, and it was pretty cool so I'm looking forward to getting that feature back. I'll need to expand SNasm's output support so that it does index files which will eventually enable me to do this, but that should be pretty easy....

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.