Edit: Unfortunately, the original poster has removed all their posts from this thread, and it has been reduced to nonsense.
For information on the SmileBASIC interface, please refer to the manual.
http://smilebasic.com/en/e-manual/
I need help, bad.
Basically, it's like a text editor that can have 4 files open at once. Your main program is going to be in slot 0, which you can run using the RUN command (like PTC) or you can press START/SELECT anywhere to run it more quickly. For the other slots, you have to use RUN <slot number>.
To save/load code in a slot, go to that slot, press L or R, and use the LOAD/SAVE buttons, or you can LOAD/SAVE "PRG<number>:NAME" from the console.
What I hope to do in the end is make an internet-type thing where you plug a cable from your 3ds into a computer and the 3ds would receive data from the computer in the from of a data-modulated audio signal.Have you heard of PetitModem and P/SEND2? These already do exactly that, though they're made for file transfer rather than connecting to some network.
https://smilebasicsource.com/page?pid=257
This explains how WHILE/REPEAT loops work
Create an artificial packet system to go through the computer. Send the data to be in the packet to the computer, and have it compile it into a single packet until the 3DS says to send it. For HTTP requests, it may even be worth it to have the computer handle most of the interaction, just relaying the relative data to the 3DS at a pace it can handle, instead of trying to get the 3DS to do everything on its own, assuming that's what you're attempting to do. If it's a custom protocol, then you may want to just design it so that it can be easily received in small chunks at a time.
In theory, yes. In practice, audio is, like you said, analog, so it will degrade in the transfer process, so some level of contingency will be required so data isn't corrupted along the way. I'm willing to assist with this if you need help, though, as I happen to have the very specific set up required (though I am, admittedly, inexperienced in the way of audio programming, for both PC and 3DS)
Introducing additional hardware isn't a good idea, as few people will have access to such a thing. You could probably easily create something with 1000-1200 bps with ease using a simple audio FSK method, but I'd wager we can do better. The data doesn't have to travel far, so there's not much room for error to be introduced, so long as it's using an audio cable. I'd wager we could get ~3000+ bps if done right. Maybe leave in a safer-but-slower mode for those not in possession of an audio cable, though.
I have no formal schooling, no, just a hobbyist who loves seeing things pushed to their limits in the most unorthodox ways. Of them, an OS with internet capabilities on Smilebasic has to be one of the most interesting ones I've seen.
