Homebrew Somone please explain the mechanism for software reset

[ethanpet113]

Ok, so first off, I am a programmer, I can program in several languages, although libnds and palib are C.

My question is how does software reset work, it seems to recieve an interrupt, and then jump to an address, which I assume is a hook designed for something different. But how does the function for software reset get put at that location, does the flashcard put it there on load, do flashcards use known loaders that patch this, why is it exactly that said loading mechanism is incapable of patching homebrew on many cards?

I have an origional model NDS, and an R4, as well as an R4 SDHC v1.43.

It seems to me that most cards have something named aling the lines of swreset.sys which contains the mechanism for jumping back to the menu, and it gets loaded into the address space for this IRQ.

It really isn't very well doccumented though, if you have any insight on the matter please post.

 

[Janthran]

If you have an original NDS then why are you posting in the 3DS section?

 

[Foxi4]

If you have an original NDS then why are you posting in the 3DS section?

If you don't have anything to say, don't say anything. Just report the post if you believe it's in the wrong section.

The mechanism is pretty simple - a part of the menu remains in RAM and with a combination of keys, it can return you to the bootloader.

http://devkitpro.org...o_Menu_Protocol

 

[Cyan]

Maybe just a mistake.
You could report the error instead of asking like that without helping him. he might take your comment as an attack.
Topic moved to NDS section.

Welcome on GBAtemp.
I'm sure you'll find an answer from another developer.

Edit:
he posted before me

 

[ichichfly]

The mechanism is pretty simple - a part of the menu remains in RAM and with a combination of keys, it can return you to the bootloader.
http://devkitpro.org...o_Menu_Protocol

actually the irq handler or swi(?) code gets patched and jumps to the region mentioned in the quote. The patch depend on the loader.

 

[Foxi4]

The mechanism is pretty simple - a part of the menu remains in RAM and with a combination of keys, it can return you to the bootloader.
http://devkitpro.org...o_Menu_Protocol

actually the irq handler or swi(?) code gets patched and jumps to the region mentioned in the quote. The patch depend on the loader.

SWI - Software Interrupt (ARM instruction), IRQ - Interrupt Request.

Either causes a jump to an earlier part of the memory, It's pretty well-explained on the Homebrew Launcher site, y'know. Of course it depends on the loader, but the base mechanism remains the same.

 

[ichichfly]

The mechanism is pretty simple - a part of the menu remains in RAM and with a combination of keys, it can return you to the bootloader.
http://devkitpro.org...o_Menu_Protocol

actually the irq handler or swi(?) code gets patched and jumps to the region mentioned in the quote. The patch depend on the loader.

SWI - Software Interrupt (ARM instruction), IRQ - Interrupt Request.

Either causes a jump to an earlier part of the memory, It's pretty well-explained on the Homebrew Launcher site, y'know. Of course it depends on the loader, but the base mechanism remains the same.

That was not why I wrote the ? it is more like I don't know a way to hook the swi without having to patch more things.

 

[Foxi4]

That was not why I wrote the ? it is more like I don't know a way to hook the swi without having to patch more things.

Ah, alrighty then.

Well, I suppose it would be best if we actually ask Normatt or Smith about it, seeing that AKAIO supports both IRQ Hooks and SWI... I never really got into the issue.