Sunday, August 03, 2008


I've finally figured out what I was doing wrong...what a twat! Okay, so in the old remote debugger I hadn't delt with the +2 of the BRK instruction and I have here, so that wasn't it this time around. I was begining to think the 7501 was slightly different from the 6502 and all the docs I had would be wrong for it, but no. The REAL reason was far simpler..... I had 2 interrupt routines.

Now I figered you only need to check for a debugger in one of them since its only checking comms and waiting a frame there doesn't matter, but the more I tested this BRK thing, the more confusing it became.

I was able to make a test where it was out right ignoring BRK instructions! I simply couldn't figure that out, that is until I realised you need to call the debug stub EVERY interrupt so it can ALSO check for BRK instructions. Otherwise it'll just exit the IRQ and carry on like nothing happened.

So, that really annoying bug fixed, and I can now single step/run/stop in a rock solid manner - at last! Now I need to emulate RTS and RTI instructions so that the debugger works properly, and I'll probably emulate branches as well since it means I only need one breakpoint. Although I'll allow RTI via the monitor, you wont't be able to debug interrupts, this is just for emulator support as it WILL be able to debug interrupts. Because a real machine uses BRK's for breakpoints, its stub is inside an interrupt, but emulators dont have to do that, they can single step anywhere and dont need to write BRK's, they can just have a breakpoint table and check to the current PC which makes them very powerful.

I have to say I'm relieved, it was starting to get to me. I usually don't spend long on bugs, but this one was pushing it.... Still, all fixed and now we can really push on with some monitor features! It'll be great to get real watches and multiple memory windows without having to do to much. The comm's speed will probably hurt the update of watch windows, but we can probably put in a bit of smarts and a FORCE UPDATE button or something to help. Watches are probably the most powerful thing I've missed as you can ask for a variable and tell it the type and number of entrys you want displayed. i.e.

DestAdd,w:        $2881
SrcTable,w,3: $8002, $8100, $8132
SpriteData,64: $00,$01,$02,$03,$04....(up to 64 bytes)
[Temp,w]+y,5: $10,$22,$44,$86,$00

The other great thing about watches is that you only get the memory you need, not a whole memory window just to watch a single byte! You'll also notice I hope to do expression evaluation like "[Temp,w]+Y". This would get the word contents of Temp and add on the Y - or something like this. this is of course way down the line, but features like this will come, and everyone that uses the STUB interface will benifit without having to do it themselves.


Anonymous said...

Glad you got it fixed. Thought it had something to do with interrupts - that stuff gets confusing after a while.

I'd be interested in seeing more about this stub, as the TG/PCE could stand to have this kind of debugging too - still several oddities about timing and some certain hardware that aren't emulated 100% because they aren't understood 100% yet.

Mike said...

Yep - I KNEW it had something to do with interrupts, I just couldn't pin it down! Still, all better now.

Getting this working on a real pc engine will be tough theres no doubt about it. You can't lay down normal breakpoints since its ROM there. You would need a RAM card and a way to talk to it and thats far from straight forward. It's on my list of things to tackle, but its so far down I'm almost stepping on it as I put my list away.

If you simply wanted to play with hardware on a real machine, then you can use the 8K RAM for running code, at which point a lot more things become possible. But you still have to get the comms working. I have a flash card with a parallel port on it, but I dont know if the PC Engine CPU can see it, I dont think so.