I want to trigger the reset interrupt from software. What is the best way to do this? Set the CPU into emulation mode and then jump to the reset handler address? Will this look just like a hardware initiated reset?
I don't think there's a way to reset the SNES via software. If you're trying to simulate reset conditions, don't forget to restore the SPC-700 to its boot ROM loader, which will be difficult if unknown code is already running on it. I ran into this problem with my SPC player; I had to reset my SNES manually in order to get the SPC-700 into a known state.
Well, I am just playing around with neviksti's Game Doctor SF7 exploit, which lets you access the SF7's full memory map and BIOS. Hence you can write code for the parallel port and DRAM. I realized that when I reset the SNES, it returns to the SF7 menu. So basically I make code changes in a text editor then save them and run a script that builds the ROM and sends it over the parallel port to my SF7.
It would really speed up the process if I could reset my SNES remotely, i.e. via the parallel port or via a controller combination. This would make iterative development allot nicer. I think that I could stuff a parallel port or controller check at the very beginning of the NMI handler, so that even if my program gets stuck in an infinite loop, it can still be remotely reset.
Also, I don't think that the sound processor's state will matter. I don't think the SF7 uses it at all.
It would really speed up the process if I could reset my SNES remotely, i.e. via the parallel port or via a controller combination. This would make iterative development allot nicer. I think that I could stuff a parallel port or controller check at the very beginning of the NMI handler, so that even if my program gets stuck in an infinite loop, it can still be remotely reset.
Also, I don't think that the sound processor's state will matter. I don't think the SF7 uses it at all.
Jagasian wrote:
It would really speed up the process if I could reset my SNES remotely, i.e. via the parallel port or via a controller combination.
A bit of discrete circuitry inserted in the leads from the reset button might help.
Jagasian wrote:
It would really speed up the process if I could reset my SNES remotely, i.e. via the parallel port or via a controller combination. This would make iterative development allot nicer. I think that I could stuff a parallel port or controller check at the very beginning of the NMI handler, so that even if my program gets stuck in an infinite loop, it can still be remotely reset.
Yeah, jumping to the reset location should be ok. Or JMP ($FFFC) if you don't know the exact location. It won't be exactly the same as a hardware reset though, but should be close enough.
It doesn't work. It loads the reset handler for nevitski's exploit. I guess a hardware reset also changes the state fo the SF7 in some way, which causes its reset handler to be mapped into the interrupt handler table.
I probably don't know what I'm talking about ^^
But couldn't you just make a memory area that you jmp to a little loop that recives the code and wait for some specific memory adress to change. And in the mean time while in this loop upload new code, and when finished set this specific memory adress to some value so the little loop detects that it should jmp to the new code that is written to some specific adress
I hope you understand somewhat what I tried to write ;D
But couldn't you just make a memory area that you jmp to a little loop that recives the code and wait for some specific memory adress to change. And in the mean time while in this loop upload new code, and when finished set this specific memory adress to some value so the little loop detects that it should jmp to the new code that is written to some specific adress
I hope you understand somewhat what I tried to write ;D
dXtr wrote:
I probably don't know what I'm talking about ^^
But couldn't you just make a memory area that you jmp to a little loop that recives the code and wait for some specific memory adress to change. And in the mean time while in this loop upload new code, and when finished set this specific memory adress to some value so the little loop detects that it should jmp to the new code that is written to some specific adress
I hope you understand somewhat what I tried to write ;D
But couldn't you just make a memory area that you jmp to a little loop that recives the code and wait for some specific memory adress to change. And in the mean time while in this loop upload new code, and when finished set this specific memory adress to some value so the little loop detects that it should jmp to the new code that is written to some specific adress
I hope you understand somewhat what I tried to write ;D
Yeah, but that is allot harder. It'd be much easier to just make use of the SF7's ability to load a ROM over the parallel port. All I need to be able to do is jump the the SF7's reset handler. Does anybody know where it is located?
Jagasian wrote:
Yeah, but that is allot harder. It'd be much easier to just make use of the SF7's ability to load a ROM over the parallel port. All I need to be able to do is jump the the SF7's reset handler. Does anybody know where it is located?
yeah maybe it is =/
I did however do something similar for the APU on the snes (but that is ofcourse not the same thing
)
maybe a bit OT..
Is there some similar exploit for the Super Wildcard (DX2)?
dXtr wrote:
maybe a bit OT..
Is there some similar exploit for the Super Wildcard (DX2)?
Is there some similar exploit for the Super Wildcard (DX2)?
I'd like to know too. It would be nice to play around with the DX2's memory map too. The SF7 magic "C0" byte is the easiest way to play around with the SF7's memory map, even easier than the exploit. I wouldn't be surprised if the DX2 also has a similar feature. Also, has the DX2's BIOS been disassembled? Has its memory map been documented?
I have a few gadgets that I want to make work with the SF7. Basically parallel port IDE devices that use the kingbyte chipset. Having disassembled DX2 BIOS code would help, as it already supports the kingbyte chipset, as that is what is used in the Diskdual... and many other devices. An interesting thing to hack on the DX2 would be to make it support a harddrive on both master and slave IDE buses, as opposed to requiring the slave device to be a CDROM drive.
I think I have a rom on my other harddrive named something with super wildcard.. goint to check that later
havn't looked for the rom.. but I found this among my snes docs:
from SNES Documentation v2.30: Written by Yoshi[/code]
havn't looked for the rom.. but I found this among my snes docs:
Quote:
----------------------------------------------------------------------------
|I have never used an actual Super MagiComm before, and I would strongly re- |
|commend not using these unless you know what each one does for sure. If you |
|decide to write any sort-of operating system for the SNES, please do get in |
|touch with me. |
| |
|The below registers i've never tested, or had tested. If you end up killing |
|your console unit because of this, I TAKE NO RESPONSIBILITY. |
| |
|Location Value returned when read Value input when written |
|----------------------------------------------------------------------------|
|$C000: Input Register |
|$C002: Digital Output Register |
|$C004: Main Status Register |
|$C005: Data Register Data Register |
|$C007: Digital Input Register Disk Control Register |
|$C008: Parallel Data Parallel Data |
|$C009: Parallel Status |
----------------------------------------------------------------------------
|I have never used an actual Super MagiComm before, and I would strongly re- |
|commend not using these unless you know what each one does for sure. If you |
|decide to write any sort-of operating system for the SNES, please do get in |
|touch with me. |
| |
|The below registers i've never tested, or had tested. If you end up killing |
|your console unit because of this, I TAKE NO RESPONSIBILITY. |
| |
|Location Value returned when read Value input when written |
|----------------------------------------------------------------------------|
|$C000: Input Register |
|$C002: Digital Output Register |
|$C004: Main Status Register |
|$C005: Data Register Data Register |
|$C007: Digital Input Register Disk Control Register |
|$C008: Parallel Data Parallel Data |
|$C009: Parallel Status |
----------------------------------------------------------------------------
from SNES Documentation v2.30: Written by Yoshi[/code]
Is that the same as the DX2?
Jagasian wrote:
Is that the same as the DX2?
probably not.. but it's also made by FFE so there is a chans.. I might try it out tomorrow
Ok. found the rom.. it's named "Super Wild Card DX2 DOS V1.106 (BIOS)"
(don't know if it's ok to link.. please tell me to remove it, if it's not ok)
I put it together with some other backup units bios:es here:
http://sofe04.byh.bth.se/joaf03/temp/BIOS_Backups.rar
I will only have it there for 2-3days.. I'm short on space on the account
(don't know if it's ok to link.. please tell me to remove it, if it's not ok)
I put it together with some other backup units bios:es here:
http://sofe04.byh.bth.se/joaf03/temp/BIOS_Backups.rar
I will only have it there for 2-3days.. I'm short on space on the account
Jagasian wrote:
I want to trigger the reset interrupt from software. What is the best way to do this? Set the CPU into emulation mode and then jump to the reset handler address? Will this look just like a hardware initiated reset?
You don't need to enable emulation mode, but yes, it "look" just like a manually-initiated reset. Keyword: RESET.
It will *NOT* act identical to that of a manually-initiated power-on. :-)