| |
logikstate
Account closed
Registered: Jan 2011
Posts: 21 |
USB Freezer/Downloader
Posting this to gauge interest.
Here is a hacked Action Replay ROM running inside an Easy Flash 3 cartridge. I've modified the cartridge CPLD core to allow freezing via USB. I can 'freeze' the machine via USB at any point, download new code, 'unfreeze' and then run.
I've modified Tom-Cat's ef3usb tools to achieve this, no point re-inventing the wheel :)
Next I hope to be able to modify the CPLD core further by adding true hardware breakpoints. The CPLD would 'freeze' when a read/write at a certain address is reached, allowing USB comms, further memory/register modification would then be possible over USB, as well as 'unfreeze' to resume.
Here's a video of me running a few random one-file demos...
http://www.youtube.com/watch?v=00kYghjobfU |
|
... 20 posts hidden. Click here to view all posts....
|
| |
Karoshier
Account closed
Registered: May 2010
Posts: 15 |
Thanks for the link to the document! It contains information I missed.
As far as I undestand, the document describes a neat way to get around the problem of not knowing from the cartridge side when the kernal is read, instead of the RAM, by the CPU, thereby being able to switch to ultimax mode at the right time to replace just the kernel (whose replacement is only possible in ultimax mode).
As you already said, $0000-$0FFF and $D000-$DFFF areas can still be breakpointed, but one instruction later. I agree that this is already better than nothing, but wouldn't all this address checking add to the footprint you need in the FPGA? Plus, wouldn't this discrepancy be confusing to the user?
|
| |
logikstate
Account closed
Registered: Jan 2011
Posts: 21 |
The footprint is already full to overflowing and I've had to remove some functionality... At the moment, just support for nordic power cartridge... and the button press logic.
Consider a "developer" edition of the CPLD and a "consumer" edition.
As it stands, I have this working, including the soft freeze but there isnt enough logic to make the buttons function... However, I believe its possible to simplify some other logic and also remove C128 support to simplify this down a little.
First things first though, I would like to get this NOP byte on the bus. At that point I think it could be considered proof of concept and we can look at how this might move forwards.
There are probably ways to simplify getting the NOP on the bus too once that is working. |
| |
Karoshier
Account closed
Registered: May 2010
Posts: 15 |
WOW! Cool. Keep us posted on the progress, please.
Unfortunately I don't have an EF3 (yet), but if there's any 6510 code or hardware thing I can help with...
|
| |
logikstate
Account closed
Registered: Jan 2011
Posts: 21 |
Hang on.
I think I've been trying to be far too clever with this. There is no need for me to put a NOP on the bus at all.
All I need to do is set the freezepoint register... physically alter the byte in RAM at that address to be NOP and then restore it again when the freeze is hit and rewind the PC counter by 1 byte.
This then allows for HW freezepoints at any address in RAM with a 1 byte instruction (NOP) and doesnt rely on any jump vectors or even the kernal to be present.
Problem solved! |
| Previous - 1 | 2 | 3 - Next |
