SB ver 3.6 is unstable if this bug has been executed.

If you're like me, you know I try to find some interesting bugs. This one is very interesting. All of this has to do with the new START button function.

How can you do it?

You choose any PRG slot to get to the editor. Then you select SAVE while holding L/R. Hold the START button till you see the main keyboard again. Return to the Top Menu while this glitched save option is still up by pressing the TOP MENU key on the keyboard. Go back to BASIC and return to the TOP MENU again. You'll notice the translucent OK button becomes opaque. Press OK without tapping anything else other than the keys for the save option otherwise SB will crash. After doing so, you get a glitched dialog. Go back to BASIC. Your keyboard will glitch out. Choose Yes or No. (Choosing Yes will indeed save the file with this glitched name.) Have fun with your broken SB until it crashes by performing it again + incorrectly or trying to type CONTROLLER(0). (Yes, it still exists & crashes.) Or you exit it and (or not) restart it.

While SB is glitched like this the keys (with L/R) will malfunction sometimes. Otherwise it's fine. Can run everything like before.

nice

... no-name program/project ...

The font for the lists doesn't support these 2 characters, that are put when executing the bug. Best example is when you type DIALOG PROJECT() or ?PROJECT() The 3DS and the standard SB font support it somewhat (replace it with the substitute char). After restarting, SB substitutes these invalid chars with another ones but valid for the 3DS font. (ASCII 65483 I guess which is a half-width japanese character.)

Perhaps when you press TOP MENU on the keyboard to opaque the OK button, it sends a kind of entry code to the SAVE FILE routine, because the routine is looking for an entry of some kind. The special keyboard for the SAVE FILE routine doesn't seem to have any characters the routine wouldn't accept, and so maybe it doesn't perform any checks on it and thus doesn't perform any checks on the TOP MENU entry code when it receives it. Instead, it understands it as a non-nil entry and allows you to save the file under the title of that entry code. The character would have no font representation, so we don't see it, and I suppose when the system attempts to display it, it does some freaky conversion stuff. Also, when you try to upload a glitched file to the server, it returns an Internal Server Error. Edit: Never mind. This no longer appears to be the case.

Every time you go to the top menu, it adds CHR$(65415) to the file name input box (you can check this using FILES) This symbol doesn't exist in the font used for the file browsing menu, so it looks like an empty filename.

I discovered something: While SB was glitched I saved 2 files and both are corrupted, for a reason. When I upload these 2 from a "no-name" project, it shows the message "Failed to write file.", I pressed OK and then a second message appeared that the upload cancelled but the buttons are back and clickable. I try some other things now. EDIT: - This error even works after starting SB rightaway but sometimes SB softlocks. - I tried again and tried to close it after the softlock but the firmware crashed in itself!¿ - While this message is up, the top left option crashes and the keyboard looks odd. - The LOAD/SAVE functions lack the background as well but the keyboard won't glitch and no random characters can be input.

Load in a PRG and then make a modification to it. Go to the console and execute NEW. While in the "unsaved changes" dialog, hold the start button a moment and hit no. Now, flip back over to the PRG slot you used, hold L/R and click LOAD. It should execute the PRG in the slot. Edit: After the incidental execution, if you attempt to save the edited PRG by holding L/R and SAVEing, it LOADs instead, completely ignoring the fact that changes have been made. Edit 2: I think it executes when you try to LOAD because the START code is put into some kind of operation stack which becomes dissonant after starting the glitch. By hitting START in the NEW dialog box, a PRG "start" code is pushed onto a stack, but not executed (likely because the NEW dialog is preventing it). By then hitting LOAD, it pushes a PRG "load" code onto the stack and executes, but executes a "start" instead, because it was next on the stack. When you then attempt to SAVE, it pushes a PRG "save" onto the stack and executes the previous "load" code, again for the same reason.

I had a well corrupted file in PRG0.

What?

I removed the SD Card during 50% of saving a copy of Win3DS. After 2 attempts I corrupted the file in such a way that the header is seen valid although it wasn't and the main content is a bunch of garbage.

After executing the glitch, SB crashed. Another try and my 2DS locked up. Not even ejecting the SD Card helped. Needed to hold the power button for 10 secounds. Well... No, my own 2DS isn't the problem here. On my sister's 3DS, the same thing happend.

I got something weird where I was playing a sample game, but the screen was frozen on direct mode even though the game is still running (found on EU SB 3.6.0). Here's what I did: 1. Open the program below in slot 0 2. Open slot 1 and open the save dialog (by holding L/R), hold start, press (B), open the save dialog again, press start, open slot 1, then the save dialog, hold start 3. go back to the top menu, press (A), select "SYS" with (A) 4. open a sample game with (A) (I chose GAME4SHOOTER), press (A) again 5. At any time, press (B) and he screen should change to direct mode, but the touch screen buttons won't work.

CLS
DIM ARRAY[0]

FILE$ = DIALOG("","Filename?")
IF CHKFILE("DAT:"+FILE$)!=TRUE THEN GOTO @FAIL
LOAD "DAT:"+FILE$,ARRAY,0

@FAIL
END

Not sure if it works with any program, but this is the one I used to reproduce it. This is also the only way I could find to open the file viewer safely.