Debugging.

I've been discussing the debugger and trying to gauge how people develop over on lemon64 (HERE!), so if your interested head on over there.

I still think this project has the chance of being invaluable to the retro comunity, particually if I can get emulator writers to pick it up and implement the STUB (which I think/hope should be minimal work for them). This then gives a stable, consistent debugger across the board and should allow developers a great code base for doing tools and other features, not to mention develop new hardware and games.

I'm actively looking for feedback and suggestions on how you develop and what you'd liketo see in a debugger, so feel free to join in the discussion on lemon64.

Plus4 world gone....

Well, it would seem that yet another problem has hit plus4world, emucamp has had many problems reciently and now it seems its domain name has expired! I'm not sure where all the plus4 folk have gone to talk/complain about it, but I think now is the time to bite the bullet and move the site - enough is enough. Emucamp was okay, but its so incredibly unreliable now it's not funny, and I'd hate to lose the site because of some badly maintained server.

I tried to mail Lando, but he appears to have changed email addresses since I last spoke to him - which is a bugger....

Alive and kickin'

Well, I appear to be back in the world of the living again. I finally had to take a couple of days off to try and kick this cold and it appears to have worked, so after a reasonably lazy couple of days I'm finally sitting in front of my machine again looking back at the debugger.

When I started this I thought it would be a reasonably small job, and one I could quickly do and get it out there so I could progress with more interesting things, but alas... this was not to be. It's turning into yet another mamoth task, and one thats eating up yet more of my limited free time. Sure, once its all working things will be great! But that still looks like being a long way off for now. I may have to scale my initial release back a little so I can at least release something and not have this as yet another project that never seems to appear.

What I'll probably do is finish the Plus4 debugging so that its pretty good to use, and then do the emulator (TCP/IP) stub for everyone else, then release that. I know I wanted to get the C64 version done first, but that will take ages, and since it requires a real machine hooked up, I can only do it in my work room at home. Once I get TCP/IP support for emulators, I can carry on doing debugging features using my laptop anywhere I like using Minus4 (or my C64/Spectrum emultor for that matter).

I gave Russell my spectrum emulator and he's be rewriting it in C# with the idea of playing with Silverlight, but this means he's doing a Z80 debugger and will use the plug in interface to support his emuator.

So....thats where we are just now, lets hope I can kick things up a gear and do some actual work! Of course...I go away on holiday to Florida in two weeks, so that's gonna get in the way, although I've bought an extra battery for my laptop, so hope to do some stuff on the plane there.

You wait. Time passes......

Yeah, I've not been doing much past few days. I've got a bit of a cold so I'm feeling a bit pooh, and we've had some birthdays etc. so I've not had much time. I might get a chance to get back into gear over the weekend, but it depends on this cold...*sigh*

Go faster stripes....

I've been struggling with replacing the rich text box for a while and almost everything I've tried was much slower, even though I know I could plot those bloody pixels myself quicker that windows ever could. I've tried several things but I've finally gotten a normal windows form to draw without flickering like a bugger and fast enough to be - well, actually usable.

I'm now rendering the dissassembly window using a large bitmap that I create each Paint (although I'll probably change that to be a little more optimal later). Still, at least I can do pretty much anything I want now without having to worry about it. The update is pretty good to - much quicker than the RichTextBox. So, I'll continue to progress with this and clean up the code as its been hacked around quite a bit in the last week.

After that I really need to address the registers as they have to be created, updated and process by the plugin.

So...progress at LAST! I'm now into the middle third of the project, and this is where things seem to move at a crawl and will never get finished. However, I'm now getting things moving again and I hope it picks up pace and I can actually release it to everyone to play with. I really do hope it'll help change development and make emulators a better platform to write on, not to mention making it easier to test on real hardware.

Wikipedia

I was reading through some wikipedia entry's on DMA and their games, and it staggers my just how bad community editing can be. I look at these every now and then to see if anyone's discovered anything cool, but what strikes me the most is how bad the editing is.

Uniracers for example. About a year or so ago it had a fairly large entry and was pretty factual, but now its a tiny stub as editors trim bits they don't like. If you look back through the history far enough, you'll find additions by me where I talked about the split screen system having to be verified by Nintendo R&D. This was because I got the guys to use an old C64 trick of ripping sprites to get perfect splits. However some over zealous editor started asking for citations and verifications and it eventually got cut. It pisses me off a bit since they really know nothing about it, and any citations would have come from me in the first place.

The problem with only putting down things they are 100% sure of because its been in print somewhere else, is that there's never anything new. Its just a duplication of what's out there already. This is stupid. It means no one could EVER use wikipedia to publish a new theory or idea, because some little Hitler will come along and nuke the whole thing just because they have never heard of it.

Community editing is good, over all the right thing gets out there. Bits you've never heard of you leave, bits your sure about you add or fix. But at some point you get some kind of community editor, and they have too much power to kill things they don't like or don't understand. They are usually appointed because they've spent lots of time adding content, but it doesn't means they know what the **** they're on about.

All in all, Wikipedia is going downhill fast. Rant over....Grrrr...

Status...

I've not done anything this past week as I've been fixing a friends machine (and been knackered to boot!), so I've made no progress from what I reported last time.

However I was thinking.... I got a question a while ago about my tools being runable on Mac/Linux and I said probably not, but that might not be true. You see the thing about C# and .NET is that you can just use it as a C/C++ compiler as C# will happily do whats called unsafe code; thats basically where you use pointers again. Now what this means is I can port SNASM and possibly Minus4 into a C#/.NET environment and get it compiling, and it would then magically work on other platforms!

You see the thing about .NET is that its a virtual state machine, so you compile your code for a mythical CPU. This is then JIT (Just In Time) compiled when the program runs - much like Java is. This means my plain ol' C++ program would run quite happily under Mono on Mac or Linux. If I get a chance, I'll give this a go and see how I get on. Once its in a C# project I can then slowly port it properly to C# without all the pain.

(And yes...I know theres a managed C++ for .NET, but C/C++ sucks and I'd rather use C# these days...)

Toys - old and new

I've spent most of today playing with some old zx spectrum stuff. I looked out my old 48k spectrum (I actually have 4 or 5 now!) and some interfaces I have for them. I hooked up my Interface 1 and microdrive, tried my DivIDE (which I couldnt get to work on a 48k for some reason - need to find the manual...), and a Disciple interface. I had to find a floppy controller but had an old Amiga drive so used that. New PC drives dont work because they are hardwired to the wrong device. Still, the disciple interface works pretty well (its a clone though, not an original). It loads really (REALLY) quickly, and theres loads of storage. However theres no through connector (on this one) and I can use the interface one's RS232.

I also tried using the interface 1 with other things plugged in, and it didn't work either - although plugging an interface 2 did work. I have an interface 2 card that takes an eprom so thats a possibility as well. We could (for development) use an interface 1 and interface 2 to try out ROMs.

The other thing we could do is supply new ROM's for the spectrum itself, but thats not what we really want to do....

The first downloading code has to be written on the speccy, but after that It should be easy enough to develop for. However, most of this is Russells problem, and I've just been having fun for the day.

More progress...

As you can see from the screen shot I've now gotten the watch window up and running properly. I now need to implement breakpoints properly and come up with a better way to redraw the main dissassembly window, rather than use the rich text box.

Oh, I also need to implement the register window properly as its currently processed by the monitor app rather than the CPU module. Since each processor has different register requirements theres no way to have this done generically, so it must be handled by the CPU module. This is a pain, but necessary. Technically speaking, I could implement a simple generic one IF the CPU module doesn't, and this would mean you could get up and running quicker, but I'm not sure yet.....

Lastly, I suddenly realised that we could use RS232 on a 48K spectrum using an interface one as it has a serial port built in. This would be slow (2.4k a second) but would be quick enough for a remote debugger. I expect most work to be done in an emulator, but this would provide a cheap way to get access on a real machine. This will of course be up to Russell whenever he gets around to doing that.

Watch Window.

I've gotten most of the watch window running now, and although its not finished it IS doing the client memory lookup as part of the expression. This involves giving the expression system access to the ICOMMS interface. This is fine as the monitor window owns both the expression and the comms classes.

The theory is you can have multiple monitor windows each with their own ICPU,IComms and IEvaluation objects. This means watches are attached to the CPU window and so can fetch memory from the client using a different comms interface (or the same). This should provide the most flexibility for the future as you should be able to debug multiple CPU machines like the SNES or megadrive which has a main CPU and a seprate sound CPU.

So, for now the expression evaluation will do proper evaluations, and allow you to access memory on the client via the attached comms module like so: [TEMP+4,w] This looks up the label TEMP, adds 4 then looks up the client memory and downloads a word (the ,w bit). This could then be used as a further value into a more progressive expression like this....
[SpriteData+[CurrentSprite,b]*2,w]. Obviously the more remote memory accesses you have the slower it'll go; BUT it will do it.

So, its looking good. I've decided to drop the memory count at the end for now as this means you can ALTER watch values via this window as well - which I wasn't planning. So all in all, its going well.

I plan to release full sources the the following modules-

The ISymbolFile module to load the SNASM symbol tables

The ICPU 6502 CPU module

The ICOMMS parallel port COMMS module

The 6502 STUB for parallel port version of the comms (C64 and Plus4)

The TCP/IP ICOMMS module

The TCP/IP C++ STUB for emulators

I will not be releasing source to the main Monitor program. I do hope to be doing a UDP version for the RR-NET, but that might not be in the first release. There will probably also be a Z80 ICPU module for using with my spectrum emulator which Russell is currently rewriting in C#. He's also really keen to write a remote stub for a real machine somehow, although we'll need an interface for that first. I do have a download cable for an amstrad, so he should be able to write a stub for that in the future as well.

I'm not currently sure what the first version will look like, or what features will be in but I think it'll be the basic monitor with breakpoints etc. Watch and memory window. If theres anything you think it shouldn't be released without, let me know - but remember most key systems are pluggable, so if theres a CPU thats not supported, you can write it yourself! I might add some tool modules so that the ICOMMS can do things like fetch sprite data etc. This would mean you could add a tool that views maps, sprites and all the rest at a later date.

Future additions will include a 65816 module for the superCPU, and probably a 65c02 module as well as a Hu7 module sometime there after. I know these will take time to appear, but feel free to add it yourself! In the far distant future, 68000 will appear as I want to play with the Amiga+ST again and this would be an ideal way....

Be warned though, part of the license agreement to this will state that any new modules WILL be included in the main application package although I've yet to decide if it will require the source code to be relased as well. So even if you dont send me your modules to get included, if I find them, they WILL be. I suspect this won't be an issue for anyone, but be warned. This is only for new ICPU, ICOMMS (and any stub that goes with it) and ISYMBOLTABLE modules, not for any program that uses them. if you have a problem with this, let me know now why that is.