-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Visual output #3
Comments
under what circumstances would reading back SRAM not be an option? |
Suppose you send a retroblaster cart with pif_rom_dumper to someone with rare N64 hardware, so they can dump the PIF ROM; they can run it and press reset, but they might not have equipment to dump the SRAM off the cart themselves. They could send the cart back, but that slows down the whole process, especially if it didn't work and a few cycles of debugging are needed. Having something visual that could be transmitted in a few photos would speed this up. It's a bit unrealistic, with a backup device that supports saving SRAM to an SD card it's easy to get at the save. Mostly I put it here because it seemed like it'd be fun to work on. #1 is more important, because in almost all cases it's just going to be a known ROM anyway. |
Ok. By "send the cart back" you mean return it to the seller? |
I mean send the cart back to the person who programmed it for them, so they can examine the SRAM. It's a contrived scenario. |
In cases where reading back SRAM is not an option, there should be a way to print the entire dump to the screen.
A higher density font that automatically (or via controller) cycles through all 2k would perhaps be feasible with OCR. QR codes would be denser still, but probably need to cycle through several (base64 would likely be necessary). gzip or other compression could get this down somewhat.
The text was updated successfully, but these errors were encountered: