software initiated reset

Discussion of hardware and software development for Super NES and Super Famicom.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
Post Reply
Jagasian
Posts: 421
Joined: Wed Feb 09, 2005 9:31 am

software initiated reset

Post by Jagasian » Tue Sep 27, 2005 11:03 am

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?

User avatar
blargg
Posts: 3715
Joined: Mon Sep 27, 2004 8:33 am
Location: Central Texas, USA
Contact:

Post by blargg » Tue Sep 27, 2005 3:57 pm

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.

Jagasian
Posts: 421
Joined: Wed Feb 09, 2005 9:31 am

Post by Jagasian » Tue Sep 27, 2005 4:56 pm

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.

tepples
Posts: 22084
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples » Tue Sep 27, 2005 5:29 pm

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.

User avatar
Memblers
Site Admin
Posts: 3889
Joined: Mon Sep 20, 2004 6:04 am
Location: Indianapolis
Contact:

Post by Memblers » Wed Sep 28, 2005 2:26 am

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.

Jagasian
Posts: 421
Joined: Wed Feb 09, 2005 9:31 am

Post by Jagasian » Wed Sep 28, 2005 6:57 am

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.

User avatar
dXtr
Posts: 375
Joined: Tue Sep 21, 2004 12:11 am
Location: Karlshamn (Sweden)

Post by dXtr » Wed Sep 28, 2005 9:23 am

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
Sorry for misspellings, I'm from Sweden ^^

Jagasian
Posts: 421
Joined: Wed Feb 09, 2005 9:31 am

Post by Jagasian » Wed Sep 28, 2005 10:09 am

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
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?

User avatar
dXtr
Posts: 375
Joined: Tue Sep 21, 2004 12:11 am
Location: Karlshamn (Sweden)

Post by dXtr » Wed Sep 28, 2005 12:02 pm

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)?
Sorry for misspellings, I'm from Sweden ^^

Jagasian
Posts: 421
Joined: Wed Feb 09, 2005 9:31 am

Post by Jagasian » Wed Sep 28, 2005 12:44 pm

dXtr wrote: maybe a bit OT..
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.

User avatar
dXtr
Posts: 375
Joined: Tue Sep 21, 2004 12:11 am
Location: Karlshamn (Sweden)

Post by dXtr » Wed Sep 28, 2005 2:08 pm

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:
----------------------------------------------------------------------------
|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]
Sorry for misspellings, I'm from Sweden ^^

Jagasian
Posts: 421
Joined: Wed Feb 09, 2005 9:31 am

Post by Jagasian » Wed Sep 28, 2005 5:05 pm

Is that the same as the DX2?

User avatar
dXtr
Posts: 375
Joined: Tue Sep 21, 2004 12:11 am
Location: Karlshamn (Sweden)

Post by dXtr » Wed Sep 28, 2005 5:57 pm

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
Sorry for misspellings, I'm from Sweden ^^

User avatar
dXtr
Posts: 375
Joined: Tue Sep 21, 2004 12:11 am
Location: Karlshamn (Sweden)

Post by dXtr » Fri Sep 30, 2005 8:29 am

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 ;)
Sorry for misspellings, I'm from Sweden ^^

User avatar
koitsu
Posts: 4218
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: software initiated reset

Post by koitsu » Fri Sep 30, 2005 9:03 am

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. :-)

Post Reply