| |
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.) |
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
it will be not able to do its job as good as an emulator, freezing cia & drive fex is problematic on real hw. however some might find it very useful.
(edit it will also not be able to report cycle within line fex) |
| |
doynax
Account closed
Registered: Oct 2004
Posts: 212 |
Quoting Oswaldit will be not able to do its job as good as an emulator, freezing cia & drive fex is problematic on real hw. however some might find it very useful. That is indeed a real headache :(
The CIAs/VIC can be emulated in the absence of external stimuli (userport I/O, lightpens, etc) but the drive and (non-IRQ) loaders may easily de-synchronize and of course the drivecode _itself_ cannot be debugged.
Hopefully the passive trace capture and offline stepping alleviates the need to step to some degree but hardly completely.
Quoting Oswald(edit it will also not be able to report cycle within line fex) Whyever not? Admittedly I haven't gotten that far but a one-time synchronization per session should suffice. At least the horizontal cycle can be determined easily by peeking at the idle accesses. |
| |
soci
Registered: Sep 2003
Posts: 480 |
This is rather cool, respect! Unfortunately for me it feels like it's a bit late ;(
For example I've used similar dumps produced by VICE for debugging IDEDOS problems 10 years ago. Especially those bugs where the wrong configuration caused memory corruption. Eventually I had to resort to static analysis to make sure I fixed even those which I haven't encountered in practice.
These dumps might be useful for hardware development, but as for regular software I think emulators probably won. Unless something is not emulated (yet). |
| |
doynax
Account closed
Registered: Oct 2004
Posts: 212 |
Quoting sociThis is rather cool, respect! Unfortunately for me it feels like it's a bit late ;( Yes, I rather fear that you are correct.
I had hoped to make up for some of the limitations by providing a comfortable user interface (symbolic debugging, visualizations, rapid turnaround and so on) but of course that sort of effort would far more profitable to put into improving the VICE monitor.
Not to mention that I had partially suppressed just how much I dislike UI programming ;) |
| |
oziphantom
Registered: Oct 2014
Posts: 490 |
I've wanted to make such a device as well. Happy to help with the GUI programming.
For me the Killer feature would be DMA injection from a PC. Making a "C64 DevKit". I.e I can hit build on my PC, then it will do a DMA take over of the 64. Inject my code into RAM, switch to ultramax mode, fake a Boot loader in the reset vector that will jump into either my code, or run the boot sequence to initialise things, then call my code. Drop DMA line, trip reset.
Another cool feature we be live hot patches. So I can use my PC to DMA data into a running system. This I think would be best for art. Imagine being able to draw on the PC and see the sprite/bitmap/IFLI etc update on the C64 and its CRT for a "live" preview.
It would be handy for those times, when my CRT works fine on VICE, but plug it in and black screen....
What I would really like is a C128 devkit, as the emulator is bit lame and having 128K to load makes the loading slow. But it would need a couple of extra wires to be clipped on inside to trap/set A16 and you would do an external ROM boot-loader not ultramax mode. |
| |
doynax
Account closed
Registered: Oct 2004
Posts: 212 |
Quoting oziphantomFor me the Killer feature would be DMA injection from a PC. Making a "C64 DevKit". I.e I can hit build on my PC, then it will do a DMA take over of the 64. That sort of thing is definitely in the pipeline, quick compile-and-test turnaround is of great benefit in any kind of software development.
At the moment it only emulates a 16k cartridge however.
Quoting oziphantomAnother cool feature we be live hot patches. ... Imagine being able to draw on the PC and see the sprite/bitmap/IFLI etc update on the C64 and its CRT for a "live" preview. I can certainly see the benefit for art. I have toyed with the idea of a "DMA-designer" allowing arbitrary copper scripts to be tested out on hardware prior to a real 6510 implementation.
Admittedly this sort of thing falls rather low on my list of priorities but an API providing direct access to the bus for use as a cheap SID/VIC/Keyrah interface might be useful.
Quoting oziphantomWhat I would really like is a C128 devkit That would be a major project in and of itself. Keeping the state synchronized by the information visible on the expansion bus would require emulating the 8510/MMU, something which frankly still isn't working reliably even on the C64 side of things. |
| |
oziphantom
Registered: Oct 2014
Posts: 490 |
Quote: Quoting oziphantomFor me the Killer feature would be DMA injection from a PC. Making a "C64 DevKit". I.e I can hit build on my PC, then it will do a DMA take over of the 64. That sort of thing is definitely in the pipeline, quick compile-and-test turnaround is of great benefit in any kind of software development.
At the moment it only emulates a 16k cartridge however.
Quoting oziphantomAnother cool feature we be live hot patches. ... Imagine being able to draw on the PC and see the sprite/bitmap/IFLI etc update on the C64 and its CRT for a "live" preview. I can certainly see the benefit for art. I have toyed with the idea of a "DMA-designer" allowing arbitrary copper scripts to be tested out on hardware prior to a real 6510 implementation.
Admittedly this sort of thing falls rather low on my list of priorities but an API providing direct access to the bus for use as a cheap SID/VIC/Keyrah interface might be useful.
Quoting oziphantomWhat I would really like is a C128 devkit That would be a major project in and of itself. Keeping the state synchronized by the information visible on the expansion bus would require emulating the 8510/MMU, something which frankly still isn't working reliably even on the C64 side of things.
Quoting doynaxQuoting oziphantomFor me the Killer feature would be DMA injection from a PC. Making a "C64 DevKit". I.e I can hit build on my PC, then it will do a DMA take over of the 64. That sort of thing is definitely in the pipeline, quick compile-and-test turnaround is of great benefit in any kind of software development.
At the moment it only emulates a 16k cartridge however.
Well if you have a 16K cart with banking, you could still do a "loader" that copies 16K, requests next bank,copies some more.
Quoting doynaxQuoting oziphantomAnother cool feature we be live hot patches. ... Imagine being able to draw on the PC and see the sprite/bitmap/IFLI etc update on the C64 and its CRT for a "live" preview. I can certainly see the benefit for art. I have toyed with the idea of a "DMA-designer" allowing arbitrary copper scripts to be tested out on hardware prior to a real 6510 implementation.
Admittedly this sort of thing falls rather low on my list of priorities but an API providing direct access to the bus for use as a cheap SID/VIC/Keyrah interface might be useful.
What I would really like is a C128 devkit
That would be a major project in and of itself. Keeping the state synchronized by the information visible on the expansion bus would require emulating the 8510/MMU, something which frankly still isn't working reliably even on the C64 side of things.
If it takes a wire to A16 then it won't need any fancy emulation, just an extra bit in the recording.
edit sorry didn't know that quoting would do this... |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
This is the kind of project i always wanted to make myself. And the key kind of project i recommend everyone to at least try to build himself. And the kind of project i dont recommend anyone to use for actual debugging =) |
| |
soci
Registered: Sep 2003
Posts: 480 |
Quoting doynaxQuoting oziphantomFor me the Killer feature would be DMA injection from a PC. Making a "C64 DevKit". I.e I can hit build on my PC, then it will do a DMA take over of the 64. That sort of thing is definitely in the pipeline, quick compile-and-test turnaround is of great benefit in any kind of software development.
Wow, some things never change ;) Back in the last century I've wrote this:
Turbo Assembler Editor V0.3B
It's a PC PETSCII text editor written in pascal which mimics the C64 Turbo assembler. In both look and feel and operation including indenting, keyboard layout and shortcuts, C64 font etc. Of course it needed 6502tass for compiling and it could parse it's error output.
Back in the day PC64 and C64S ruled. It was really inaccurate and slow on my 486DX2 80MHz. And cross compiling was not all that useful when I had to use Star Commander all the time to copy to the result to disk and load it.
Therefore I've built a parallel↔userport cable, and wrote transfer code for it. It was quite fast and the complete memory could be downloaded in less than a second.
To make things even better 6502tass had a "non-linear" mode, so I could transfer scattered memory content even faster without touching the unused areas in between.
On the C64 I've loaded the transfer code once, then I just had to press ←3 and s in the editor and by the time I've turned around it was running on the C64.
Then I've exited the tested code (usually by pressing restore or space) and it jumped back to the transfer routine. Turned back to the PC, fix stuff, ←3s and all repeated.
That was a rather fast cross compile-test-fix turnaround and I was really proud of this cross development environment back then ;)
These days I use IDE64 with USB or Ethernet PCLink for getting stuff over to the C64. I think Codenet64 could be used to get similar results as well.
I'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.
Having a "memory injection" possibility as one of the feature list points is useful, without doubt. |
| |
oziphantom
Registered: Oct 2014
Posts: 490 |
DMA injection has a few benefits.
1.) you don't need to load anything on the 64 first.
2.) you don't need to keep any part of RAM or the code safe from your own code
3.) you don't have to make any changes to your code to support dropping back to the "transfer loop" or worry about it changing CIA settings.
4.) DMA mostly won't need to worry about needing a Safe point, but if it does it should be easy to add a Cycle counter to specify a safe line,cycle to take over
5.) DMA injection can allow for single byte updates like ICU=64 which gives you faster debugging, just give you self 5 more lives in a second.
6.) If I have some code that goes rouge and makes the wrong value during a function, I don't have to wait for the function to finish executing as I can use DMA to stall mid run and catch it.
But yes, not going to be an all new thing, not going to give us amazing "its the future" tech. Just help us get the past back with a little bit more ;) |
... 9 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 - Next |
