| |
doynax
Account closed
Registered: Oct 2004
Posts: 212 |
In-circuit debugger project
With MagerValp's recent revelation of his FIFOgfx project project and its promising application in tracing I have been prompted to show off my own work on a related project. At least that's the official rationale, frankly a desire to nail my colors to the mast and get some real work done during the upcoming holidays instead of falling prey to laziness is probably as big of a reason.
Anyway, for the last year or so I have been tinkering on-and-off with a cartridge intended to ease the pains of debugging software C64 projects on proper hardware. The end goal being to make debugging on hardware as convenient and fast as using an emulator.
So far the first step has been to implement a passive bus capture mode with offline stepping, effectively operating as a fancy logic analyzer and allowing unintrusive monitoring. Normal breakpoints and (back-)stepping is of course planned.
However while system may potentially be useful even in its present state the software still has an long way to go and has turned out to involve rather more work than I had initially anticipated. My hope is to stay the course this time instead of bailing out half-way once the interesting technical challenges have run out.
So.. Does this sound potentially useful or would today's accurate emulators render this sort of thing more of a curiosity than a practical development tool?
Early cartridge revision:
Early user interface:
(And, yes, I do realize that the Chameleon or 1541-U would have served as a far more capable platforms with large installed userbases. However anyone browsing this forum might be able empathize with a certain attraction towards making do with limited hardware resources.) |
|
... 10 posts hidden. Click here to view all posts....
|
| |
doynax
Account closed
Registered: Oct 2004
Posts: 212 |
Quoting sociI'm not sure how much DMA could improve on this. For me transferring stuff over for testing "fast enough" is solved for a while now. Frankly it wouldn't. An integrated code upload mechanism is simply a prerequisite for the debugger to be useful in the first place.
In the end it is all about comfort and reliability more than features. If reliable source-level debugging from a decent user interface can be had with the touch of a button within a second or so then the thing would be useful, whereas if you constantly need to think about desynchronization and run through hoops to get into it then the system is pretty much pointless for anything besides tracking down hardware-only bugs.
Of course reaching that point at best involves an awful lot of work, and at worst simply infeasible due to external I/O devices such as floppy drives. |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
Awesome looking project, and I firmly believe that this is something that would be useful. Emulators are great for development and frankly I couldn't imagine working without one these days, but at the end of every major project - especially if you're pushing your or the machine's boundaries - comes the stage when you need to test and debug on the real hardware. I certainly logged quite a few hours in front of my C64 with U4, battling with subtle differences between EasyFlash hardware and VICE, or tracking down stack corruption. Even if you could sit down and try to reproduce the bug in VICE, it's a huge boon to be able to debug it right there and then.
And this is the holy grail of development, isn't it? Emulators will always be the second best thing. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
the only problem still being: you cant stop the timers, the VIC, the drive - or basically anything that'd be interesting to debug :P
oh and you are basically reinventing the PDS :=) |
| |
doynax
Account closed
Registered: Oct 2004
Posts: 212 |
Quoting Groepazthe only problem still being: you cant stop the timers, the VIC, the drive - or basically anything that'd be interesting to debug :P Unfortunately I am going to have to parallel emulate and restore the CIA/VIC state after breakpoints, along with the 6510 for the $00/$01 state, and of course restoring the drive state isn't possible at all :(
Hence the crutch of a passive capture mode to cover drive and emulation inaccuracies. At least on bonus side you do get the ability to back-step out of it, which should come in handy on occasion.
Quote:oh and you are basically reinventing the PDS :=) To be honest I have only a vague idea of what the PDS actually did. Has the hardware ever been reverse engineered or emulated? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:Unfortunately I am going to have to parallel emulate and restore the CIA/VIC state after breakpoints
which is.... not only hard to do, but also the classic "perfect freezer is not possible" problem :) it cant really be done correctly.
Quote:To be honest I have only a vague idea of what the PDS actually did. Has the hardware ever been reverse engineered or emulated?
the original PDS came with a ISA card that basically resembles an 8bit capable printer port (EPS or whatever it was called) - on C64 end there was only a small stub program running (much like the debug stubs on current embedded systems). the software for this is available (and was circulating some years ago) but kindof useless unless you set up a DOS machine. i know at least one guy who has a working setup (or at least he had some years ago :=))
i have also heard stories about a second version which used a more sophisticated hardware that went into the c64, possibly as an adapter on the CPU socket - allowing for some better control. (rainbow arts people mentioned this a few times). this hardware has not surfaced yet afaik. |
| |
doynax
Account closed
Registered: Oct 2004
Posts: 212 |
Quoting Groepazwhich is.... not only hard to do, but also the classic "perfect freezer is not possible" problem :) it cant really be done correctly. I'm still not quite following you then I'm afraid. Does the problem lie in inferring the chip states, in restoring them afterwards or both?
My basic plan plan is to watch all pokes to the CIA/VIC while maintaining parallel emulated versions tracking their assumed states within the debugger. Then issue corresponding pokes to restore the states afterwards. (For the record at the moment I've only gotten as far as implementing the CPU simulator and latching the most recent I/O register pokes without further processing.)
Admittedly any external stimuli, such as userport devices, will make it all fall down, the real-time clocks can't be resynchronized perfectly, and there are probably a hundred annoying details besides. I was rather hoping to be able to get close enough so as not to desynchronize in practice on anything much beyond intentional obfuscation or external hardware though. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
if you watch all writes then you might be able to actually determine the state correctly (make sure to also watch $01 - oh, wait.... =P)
and restoring the state... yeah it can only be done on a "lets cross fingers and pray it works" basis, especially when timers or TOD are involved (the chameleon menu for example leaves the timers and tod running for this reason) |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
It doesn't have to be perfect to be useful. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
no, however i still doubt you can make it work properly for any use case where an emulator couldnt do the trick (and would even work much better). |
| Previous - 1 | 2 - Next |
