-
Notifications
You must be signed in to change notification settings - Fork 12
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
Gameshark type support #14
Comments
Are you sure it isn't possible to do a second transfer to send the ROM with the old build? The reason for doing a separate transfer is that the first one is written while the game is running, there may not be enough space to store the whole NES ROM in a way that it won't be overwritten before Neon64 takes over. (At least that was the theory. Also it lets you load another ROM without resetting the N64 and loading everything again.) If you could point me at the upload code you're using I can try to figure out what's going wrong, I looked in https://github.com/danhans42/xplorer64 but didn't find anything. In v2 there would be a lot of changes needed to support GS loading at all, since it uses overlays to load code based on what mapper is needed, and there's also the PAL mode thing. There's probably enough RAM to initially have all the modes and overlays in RAM and copy the appropriate one from there instead of PI DMA. You'd also need to change the ROM loading (which is now in parts to do the header and data separately) to work from a fixed location in RAM instead of doing a PI DMA. I'd like to do this eventually but no timeframe for when I'd be able to. |
Hey, Thanks for coming back to me. I think the Xplorer64 is different to the GS in this respect. The game doesnt actually have to run - it works pretty much in the same way as the Playstation Xplorer - the commands are only available on the main menu and not elsewhere. So basically I send over to the xplorer the command, the data length, load address, followed by the data and the checksum and then it uploads and runs - and thats where it ends. Ill get the code polished up and put on github - its nothing fancy it just an implementation of what can be found here https://psx-spx.consoledev.net/cheatdevices/#cheat-devices-xplorer-db25-parallel-port-function-summary (the SetMemAndExecute command) as its the only command that actually works other than status/burnfw. I think it was hoping it may be just a matter of appending a nes rom to the BIN output (no header etc) and changing the RAM address.. nothing is ever easy :) |
Hi,
Not an issue as such but wondered if it was relatively straightforward to build neon64 where it can be loaded by a cheat cart?
I have managed to get the xplorer64 to load code in a similar way to the GS with some assembly examples from peterlemon and was hoping to be able to do the same with neon.
I tried the old build but with the Xplorer you can't send the NES ROM seperately so it just sits on the title screen.
I know nothing about assembly unfortunately 😐
I have looked briefly at the code but with the other stuff I have tried it's just a matter of changing the address in the source and commenting out the header bits etc and the fill part so it doesn't get padded.
The text was updated successfully, but these errors were encountered: