You need Trinket/rebug I think as you are using the new methods if I remeber correctly.
1.3.2 installed and working well, thank you for all the continued updates and support 
Is bootlogo drawing messed up for you on 1.3.2? I get no boot logo after the Sept screen minus this little bar on the left edge of the screen.1.3.2 installed and working well, thank you for all the continued updates and support
As standard there isn't one, I think you must add one in
It's running extremely well for me, this chip software keeps getting better and better.... everyday is June 15th with Mattytrog at the wheel
Right. I did. Just used the standard Atmosphere boot logo. Worked fine on Switchboot 1.2.2 and Hekate 4.10 and 4.10.1 with the same image and INI file.
No, it doesn't. Try an older Switchboot, or Hekate to see the difference. After the Sept screen, the boot logo should display again and not be immediately erased.
From power off, it should go: Boot logo, Sept screen, Boot logo, Nintendo Logo, Switch Logo.
Switchboot 1.3.2 is going: Boot logo, Sept screen, Boot logo immediately erased to the last 10 pixels or something, Nintendo logo, Switch logo.
Last edited by romracer,
Ummm...OK
I can add a delay if you like to stop the fb clearing so quickly...
The boottime has got faster. Thats why is disappears quickly but I can slow it down if you wish.
There is also a boot delay option.
Boot delay is set to 2 or 3 for me. But boot delay is before the Sept screen. Spend 5 minutes trying Hekate or an older Switchboot to see the difference. The framebuffer clearing is not because the boot sped-up, unless by that you mean your modification to the code jumps to clearing the framebuffer while still doing other stuff in the background.
The FB is cleared as soon as boot begins (hence the "free (bootlogo);")
If everything is ok, boot now commences immediately. A check is done at boot time. If "dump keys" was the reason for sept boot, this will continue. Otherwise boot will continue normally immediately. Like I say, I can put a short delay in (using boot time delay read from ini) before the buffer is freed.
Not a big deal. Will put it in next version.
OK... Coming in next day or two... I say that because I`m decorating...
V1.3.3 Changelog
But its nearly done... Just tidying code up and trying to escape the missus.
V1.3.3 Changelog
- Dump your nca files from emmc to your SD, decrypted from Contents/registered
- Dump your emmc /save files to SD, decrypted from /save
- Dump other emmc stuff decrypted
- Graphic glitch showing max fw when fuse under 9 (you won`t see eg v.5.1.0, v6.1.0 on a different line)
- After Sept has ran, bootlogo shows for time specified in autoboot delay setting (before it just flashed on and off)
- Got rid of an artefact (on left side of screen when screen buffer emptied and boot begins - That annoying line!)
But its nearly done... Just tidying code up and trying to escape the missus.
Last edited by mattytrog,
I am using Mode 1 in a few switches and your Fusee-UF2 chain loader seems to be an ideal solution for a more permanent flash. I was trying to find a way to get Fusee-UF2 to chain launch SwitchBoot so it would be easier to update in the future. Having to reflash the trinket every time a new Atmosphère build or new Switch update is released is a bit problematic when helping friends update their hardware.
The idea would be to have Fusee-UF2 launch a start.bin on SD root, actually SwitchBoot.bin, and then have SwitchBoot autolaunch payload.bin as usual. This would allow to update SwitchBoot by simply replacing start.bin with the latest version when it's updated. The problem is that both Fusee-UF2 and SwitchBoot are hardcoded to look for and launch payload.bin which results in an infinite loop if Fusee-UF2 launches Switchboot directly (as payload.bin).
I've looked for the source Fusee payload you have created to simply change the payload filename but I cannot find it on your github. Do you have the source available somewhere or would you be willing to build a "special" UF2 version that looks for a different filename on SD root so we can chain Fusee-UF2 and SwitchBoot?
Appreciate all the work you have been doing - have been a day 1 user of your trinket m0 solution. Cheers!
The idea would be to have Fusee-UF2 launch a start.bin on SD root, actually SwitchBoot.bin, and then have SwitchBoot autolaunch payload.bin as usual. This would allow to update SwitchBoot by simply replacing start.bin with the latest version when it's updated. The problem is that both Fusee-UF2 and SwitchBoot are hardcoded to look for and launch payload.bin which results in an infinite loop if Fusee-UF2 launches Switchboot directly (as payload.bin).
I've looked for the source Fusee payload you have created to simply change the payload filename but I cannot find it on your github. Do you have the source available somewhere or would you be willing to build a "special" UF2 version that looks for a different filename on SD root so we can chain Fusee-UF2 and SwitchBoot?
Appreciate all the work you have been doing - have been a day 1 user of your trinket m0 solution. Cheers!
I think I hardcoded switchboot in there... I know I have now. Not uploaded it yet.And I forgot the source before...
In summary...
I have made a new Fusee-UF2 that works exactly the same as before... Apart from "switchboot.bin" is hardcoded... So if switchboot.bin is found, that will run instead of payload.bin... Of course if you have a payload.bin, that will be launched by "switchboot" as it has hijacked Fusee-UF2. If there is no Switchboot, payload.bin will launch as usual.
Also... Fusee-UF2 will make a new text file on SD root (only 70 ish bytes) that contains strap info. If straps are connected and working, this file will tell you. This can then be viewed or imported into switchboot/hekate or whatever to be displayed.
If you don't need the information, feel free to ignore it.
So, the chain of command will go...
Fusee-UF2 runs... Is switchboot present?
Yes - run switchboot. No - run payload.bin... if neither are present, max77620 reboot state is reset and unit powered off.
If yes, switchboot will launch your payload.bin as it has taken over from Fusee-UF2.
Last edited by mattytrog,
i got it sorted, im slow to reply sorry.
mine is old school method 3 ive worked out, the mod before you did straps and so on on the 4 wire install.
need to resolder to bring it up to your current wiring but for now its working.
Madturbo123, did you finally find a solution for the RCMX86 usb problem?
I have the same problems and I suspect that the IC USB logic chip is who is causing the issues.
Did you try unsoldering straps?
Similar threads
- No one is chatting at the moment.
-
-
-
@
Psionic Roshambo:
One thing that just occurred to me.... The sound on the 2600 sucked less back then the harsh sound we hear now is from infinitely better speakers we have now, back when the 2600 was new speakers produced a almost muffled sound, like CRTs made old graphics look slightly better. -
@
Psionic Roshambo:
I wonder if I could recommend that to some emulation devs that perhaps the sound could use some smoothing out to simulate those old TVs
-
@
Psionic Roshambo:
I think a few of the early systems could benefit from that, at least up to the 8 bit generation, by the 16 bit generation I think TVs had gotten a lot better in almost every way
-
-
-
-
-
-
-
-
-
-
@
Xdqwerty:
it says it only works for the original R4, R4i Gold (r4ids.cn), R4iDSN (r4idsn.com) and Acekard R.P.G. -
-
-
-
-
-
@
Psionic Roshambo:
Just give it a try, but honestly if you have a 3DS you can play DS games without a card just off the internal SD card
-
-
-
-
