| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
FIFOgfx (with live C64 debugging)
A friend of mine built his own 6502 computer and he talked me into making a graphics card for it. I've connected my prototype via a cartridge to the C64, and a side effect of how I'm interfacing it means that the C64's memory is mirrored into a Raspberry Pi, making it possible to inspect its memory live. I realized that this might potentially be even more interesting than the main project, but I haven't had time to fully explore it as I'm focusing on finishing the gfxcore first. I've started releasing my project files on GitHub if anyone wants to play along:
https://github.com/MagerValp/fifogfx |
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
"mirrored" .... but read only, right? |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
interesting how it is possible to mirror 64k "live" ? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
i havent looked - but what i would do is just looking for write accesses and then reproduce them locally (in the "mirrored" RAM). ie, you dont have to actually "mirror 64k" |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
Yes, read only mirror. Groepaz is spot on, I capture all writes on the bus and copy them to a 64k mirror buffer. I haven't verified that it actually works, but I implemented simple $01 logic as well, to capture I/O writes to a separate buffer.
But this was really just a happy accident while making the graphics card :) |
| |
Skate
Registered: Jul 2003
Posts: 494 |
This could be very useful actually. There are similar realtime monitoring solutions for emulators but monitoring the real thing is completely a new level.
Thanks for sharing your project MagerValp. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:I haven't verified that it actually works, but I implemented simple $01 logic as well, to capture I/O writes to a separate buffer.
i'd be surprised if that does anything useful :) writes to the CPU port can not be "seen" on the BUS (only the address, not the data IIRC) - which is the main reason for why the chameleon became what it is, the only way to know about the state of the CPU port is to "look into the CPU". |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: Quote:I haven't verified that it actually works, but I implemented simple $01 logic as well, to capture I/O writes to a separate buffer.
i'd be surprised if that does anything useful :) writes to the CPU port can not be "seen" on the BUS (only the address, not the data IIRC) - which is the main reason for why the chameleon became what it is, the only way to know about the state of the CPU port is to "look into the CPU".
One could solder the unit directly on the inputs or the outputs of the PLA to know the state of $01 though, if you really wanna debug. Or on the various chip select signals for that matter. A bit intrusive, but possible. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
yes, thats the common solution (used by eg SCPU) |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: yes, thats the common solution (used by eg SCPU)
Aha, didn't know it jacked in that hard. :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
for SCPU128 its even funkier.... it needs to "bypass" the MMU, so it comes with an adapter for that and plenty wires routed inside the computer... |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: for SCPU128 its even funkier.... it needs to "bypass" the MMU, so it comes with an adapter for that and plenty wires routed inside the computer...
Aha wow, ok! :D |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
Quote: Quote:I haven't verified that it actually works, but I implemented simple $01 logic as well, to capture I/O writes to a separate buffer.
i'd be surprised if that does anything useful :) writes to the CPU port can not be "seen" on the BUS (only the address, not the data IIRC) - which is the main reason for why the chameleon became what it is, the only way to know about the state of the CPU port is to "look into the CPU".
Well that makes sense, yeah. It'd be easy enough to clip on to the cpu for those three signals, there are even three free bits left in the FIFOs, if one was so inclined. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
you need a couple of the select signals that come out of the PLA - then you can properly tell apart I/O and RAM/ROM accesses... quite easy actually if running wires into the c64 is an option. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: you need a couple of the select signals that come out of the PLA - then you can properly tell apart I/O and RAM/ROM accesses... quite easy actually if running wires into the c64 is an option.
Yeah. The PLA emits 6 signals (BASIC,KERNEL,CHAROM,IO,ROML,ROMH).
One of them is IO ($d000-$dfff) which is fed into two serial adress decoders to split out CS for $d000-$d3ff (VIC), $d400-$d7ff (SID), $d800-$dbff (COLOR) and $dc00-$dfff (CIAS).
The CIAS signal is then fed into itself (the second part of the chip) to select $dcxx (CIA1), $ddxx (CIA2), $dexx (IO1) and $dfxx (IO2) CS. The last two are just wired to the expansion port. So, yeah, it's quite easy indeed.
It's a very neat construction and extremely simple. |
| |
Slajerek
Registered: May 2015
Posts: 63 |
I need to have it :) |
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
Hackers! |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
Quote: I need to have it :)
If you have a soldering iron or a breadboard and an evening or two, go for it :) |
| |
doynax
Account closed
Registered: Oct 2004
Posts: 212 |
The alternative is to do parallel emulation to infer the $00/$01 state. In theory this might de-sync on the tape motor state and some unstable opcodes but in practice this pretty much requires intentional obfuscation.
I have actually been tinkering with a debugging cartridge doing precisely this for a fair while now. Unintrusively capturing bus traces which may then be stepped through offline, eventually along with the traditional debugging features.
Unfortunately the software side of things is still _far_ from finished and I now seem to have been scooped. Ah, well, serves me right for not putting enough time into it I suppose ;)
Good luck on your project! |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
doynax: yup, thats what chameleon does (except at some point we moved one step further and disabled the C64 CPU completely - we still have a test core that runs both in parallel however, that way we can verify/check the emulated CPU) |
| |
Martin Piper
Registered: Nov 2007
Posts: 722 |
Nice. :) I was using similar address bus snooping to get a TTL 6502 to drive LCD screens. These screens would of course have their own internal buffers for the draw commands.
http://www.wellytop.com/Fnagaton/TwoScreens.jpg |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
...of course maybe i miss something, but since there is a Z80 cpu cart for c64, isn't possible to build an hw with is own 6510 that is fully monitorable? |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: ...of course maybe i miss something, but since there is a Z80 cpu cart for c64, isn't possible to build an hw with is own 6510 that is fully monitorable?
It's called Chameleon |
| |
oziphantom
Registered: Oct 2014
Posts: 490 |
It would be interesting if one of these could be made to work in the 64. http://stardot.org.uk/forums/viewtopic.php?f=44&t=9655 They have them working in BBCs and Atoms which are VIC less, so not a good test. |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
Neat project! Stopping or single stepping is not an option with 6510 and VIC-II, but you could do tracing and memory inspection - sort of a mini logic analyzer. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
well, you could even do stop or stepping.... with the kludge that the VIC would still "run" anyway. i *think* the PDS could actually do this. |
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
Stopping the CPU via a very long dummy DMA I guess? |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: Stopping the CPU via a very long dummy DMA I guess?
Yes, "just" strobe the RDY-line |
| |
doynax
Account closed
Registered: Oct 2004
Posts: 212 |
Quoting JackAsserYes, "just" strobe the RDY-line Not a lot of use in a demo environment without restoring the VIC/CIA timer states afterwards though, otherwise the first breakpoint set in anything timing sensitive would be liable to desynchronize the system and you might as well capture and step through a passive trace instead.
Taking care to resume execution on a multiple of 63*312 cycles later would be a start at least. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
for demostuff all you need is inc $d020 anyway :) |
