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.

Watch me now....

I've been fighting with .NET list views for the watch window and have finally managed to get a watch class being mapped and displayed via the .NET data mapper. The Data mapper is very cool, and lets you map a class directly into a control. It also lets you add new items and will allocate/edit/delete new entries without me lifting a finger! Very neat.

I'll start on the actual watch processing tomorrow, and with any luck that'll be all that I'll need to do to implement basic watches! After that I'll need to get breakpoints working and I suspect the first version will closely follow afterwards.

Coming together....

I've been making steady progress and have now got the dissassembly window scrolling around under user control (without tracing). So you can now use the cursor keys to scroll the window, and the page-up and page-down keys to move quicker. It's going pretty well but I'm not happy with the ricj text box control. It feels slow, and there are a few keys you can't seem to override. This means although it gets rewritten every tick, you can upset things by pressing enter at the wrong time. I think I'm going to have to draw it myself somehow - perhaps even on a bitmap or something....

However that aside, its making good progress, and once I have user breakpoints in I can start looking at memory and watch windows. But the drawing of the display remains a concern....

Single stepping.

After a long discussion with Russell on Friday about the best way to single step, I decided to try out the new method. It basically involves having the STUB execute a single command inside the STUB itself. Currently I simply place a breakpoint one instruction later, and then run the application; the program runs, hits a BRK then stops again. This new way is friendlier to machines like the ZX Spectrum that has issues (and bugs in the ROM), but its tricky.

Imagine you've stopped the execution of a program, saved all the registers, flags etc. and now want to single step. What you would have to do is copy the instruction you want to trace into a 3 byte slot (thats prefilled with NOP's), restore all registers and flags (also stack) and execute the command. You then resave everything and return back to the debug comms loop. It sounds fairly simple but its not as easy as it appears.

;******************************************************************************
;
; Name:  SingleStep
; Function: Given an address and a byte count, execute a sequence of bytes
;
;******************************************************************************
ExecuteCommand:
             jsr   GetByte             ; Get destination address
             sta   Dest
             jsr   GetByte
             sta   Dest+1
 
             jsr   GetByte             ; get opcode size
             tay
             dey
 
             ; Clear out exec buffer
             lda   #$ea                ; Clear the instruction space 
             sta   ExecBuffer+1        ; in case the instruction isn't 3 bytes long!
             sta   ExecBuffer+2
 
             ; copy 
!lp1         lda   (Dest),y            ; Copy the instruction to execute
             sta   ExecBuffer,y
             dey
             bpl   !lp1
 
             tsx                       ; Save current stack
             stx   StackStore
             ldx   RegSP               ; Restore application stack
             txs
 
             lda   RegF                ; Get the flags ready
             pha
             and   #$4                 ; We must keep interrupts OFF!
             sta   RegF
             pla
             ora   #4
             pha
 
             lda   RegA                ; restore registers
             ldx   RegX
             ldy   RegY
             plp                       ; restore flags
ExecBuffer:
             nop                       ; Command goes here.
             nop
             nop
 
             php                       ; Save flags
             sta   RegA                ; Save registers
             stx   RegX
             sty   RegY
             pla                       ; get the flags and store
             and   #%11111011
             ora   RegF
             sta   RegF
             tsx
             stx   RegSP               ; Store the application stack
 
             ldx   StackStore          ; get the debugger stack back
             txs                       ; and restore it.
             rts
StackStore   db    0

Now you'll also notice you have to do some jiggery-pokery with the flags so you dont reenable interrupts by accident (since we're actually still IN an interrupt), but aside from that theres a lot of stuff involved. The bit I really dont like is that emulators simply wouldn't do this. They would simply set a break point and run. I really don't want to have 2 ways to step through code, I'd like it if the CPU module simply didn't care if it was a real machine or an emulator. Now, the spectrum can still do it with breakpoints, but since the spectrum ROM has bugs in it, its limited in exactly what it CAN do.

We currently think you would need to do breakpoints with CALL's, as the RST instruction needs ROM support and its the part thats bugged. NOW calls take up a few bytes which means you have limits as to where you can place a breakpoint. For example, if you were to branch over an XOR A but wanted to put a breakpoint on the XOR, then the breakpoint would overrun onto the next instruction, and it might crash.

Now for single stepping, that shouldn't happen; particually if the coder is aware of the limits. On other Z80 machines, it should be possible to use the RST instruction to do the breakpoints so they would be fine. I've put breakpoint control on the STUB for a few reasons, but because of this it means each STUB can decide how it wants to do them.

So... after playing around a lot with it (and actually getting it to work), I've decided not to use it, but to go back to the breakpoint idea. I think it has the widest compatibility, and if your really stuck you could still implement you own single step if you modify a CPU module and package it together with a dedicated COMMS module.

I've also started to think about the TCP/IP module for using with emulators (and I'll do a UDP one for the RR-NET later), and I'm starting to get excited about the possibility of it being adopted by other emulator guys. If all goes well, then no one should ever have to write a built in debugger again!

Lookin' good!

I've finally done enough to make some visible progress. With the addition of the expression evaluation, symbol table lookup and command line processing means I can finally display symbols in the dissassembly view. It's now starting to look like a proper debugger. I need to get left side labels in next (where the addresses are displayed) so you can see where your branching to, then we'll be mostly done in that view.

I still have to add control of the view but thats next. The biggest unknown is the registers, I've no idea yet how to display a generic number of registers or how to lay them out. I'm tempted to let the CPU module display them as well as handle them, but I don't know yet.

Good progress!

I've gotten on pretty well tonight! I've managed to finish BOTH the lexical analysis class and the expression evaluation system. Not bad for a nights work. I can now evaluate things like...

((2<<(4*4)+8*4)&$ffff-MySymbol)*4

This means watches can enter calculations to be evaluated, which you can then apply the [...] modifier to so that its a memory lookup on the target. I still have a way to go as theres currently no way to get the evaluation system to look at the targets memory OR registers. However that shouldn't be hard and then things will start to get very cool. Of course the inital reason for this is so theres an interface for the CPU module to lookup symbols for the dissassembly, but through the same interface you'll be able to execute actual calculations.

I also have the ability to add commands to this, like Lo() and Hi(). This means you could do calculations like...

Lo( 2<<(4*4)+8*4 )<<2

This is pretty neat, but it also opens up for more complex functions like ...err... SQRT() or something, which is pretty cool too. The whole expression and lexical stuff is just 2 small C# files, so its pretty portable if I want to do anything else, so this could be handy!

Expressions and Lexical analysis

So I started to look around after yesterdays revamp of the plugins, and realised that to finish the intialisation system I need to pass in an expression evaluation interface. Oh well.... more code to port..... I started to port over SNasms expression stuff but it soon became apparent that I needed a lexical processor first. Now the one in SNasm it pretty fully featured, but a bit much for a command interface, then I suddenly realised that I dont need very much at all. I need to be able to pick out symbols (like *,."$&[]() etc.) and symbols. This means I only need a very simple one as at text I dont understand will be a label (or I can do a quick dictionary lookup to got basic commands).

So I've almost got this basic one going, and its really very simple but will do the job at hand. So I'll finish this tomorrow, and then port the expression stuff the night after and finally I'll be able to get the intialisation stuff done. It also means I can start to load symbol files and get a proper symbolic dissassembly!

Slow going, but we're headed in the right direction.