SmileNet 2.0 Is maybe happening soon (Don't burn me if it doesn't)

So here's a few details of what would be needed. at the end of the day a user will need these to use SmileNet 2.0 1) CFW installed on a new or old 3ds with Rosalina and Luma 3DS installed. 2) A windows or equivalent computer i'm not compiling for linux forget it 3) Input Redirection QT 4) A local wireless connection for both the 3ds and the computer 5) Basic understanding of what a local IP is so they can type it into Input Redirection QT 6) An internet connection 7) A third party program I write which connects to the internet 8) Knowing how to port-foreward cause it'll likely be needed 9) The know-how to send their ip to a friend to connect with them 10) Lastly an understanding that if they write to a specific array in SmileBasic that array becomes an IO port to the internet over SmileNet once it is set up, They'll have to put data in or out of the array specifically to talk to their program and their friends program. the programs made in SmileBasic that talk to eachother will have to be talking in the same user-created 'format' This is similar to the use a pc keyboard as input method but not the same project because it would be a different project of a similar nature. So yeah, here's what I require in order to make it work. 1) The ability to build Luma3DS from sources myself. I began working on that, So far I almost have it. But I'm missing a few things. 2) The ability to understand 3ds dev enough to poke into SmileBasic's memory / ram using Input Redirection built into Rosalina 3) A better grasp on sockets, websockets and bsd sockets in general. 4) Become more skilled at C

Thank you for not supporting Linux Je deteste Linux pour pas de raison.

I need to comprehend this line of code as well as most of the things happening around this line of code (30 lines up 30 lines down ish) https://github.com/AuroraWright/Luma3DS/blob/master/sysmodules/rosalina/source/input_redirection.c#L211

Aw man, please don't make me have to homebrew my 3ds for keyboard support. I don't want to brick it 😢. Can you upload a link to the legacy version of SmileNet (which used a mic)? EDIT: Nvm I found your post about it

Aw man, please don't make me have to homebrew my 3ds for keyboard support. I don't want to brick it 😢. Can you upload a link to the legacy version of SmileNet (which used a mic)? EDIT: Nvm I found your post about it

The risk of bricking if you have lower firmware than 11.04 ish.. is low. Don't be scared to do it just follow the instructions correctly. only ever use 3ds.guide, i'm not saying go put custom firmware on it it's your choice if you don't want that but it's the only way SmileNet will actually work because I have to design something which will hook into the ram of SmileBasic while SmileBasic is running. Using stock firmware it just isn't possible to do that nor is it possible to open a socket stream on the 3ds and send bytes across the network as I desire it using stock firmware. The idea is that if you do have cfw this will benefit you if you also use SmileBasic. Slightly cool thing I did, after finally getting Luma3DS to build I was able to add this new menu item to Rosalina's menu: So yeah, things are tough but they're coming along. I've had to ask alot of questions/ pester alot of users in the general 3ds dev chat but I think by the time I'm done THIS project I'll be well on my way. Speaking of there are going to be a few changes to the design of SmileNet 2.0 as it is now, it is going to use a user defined magic value set and I'm questioning the possibility of having it able to read that value set from a text file on the SD card (not sure how hard that would be) but it would seek those values in ram and if it found them, it would apply SmileNet's memory map to the ram bank of that. I'm thinking 255 individual bytes will be enough, and sent on a per frame basis. Apparently we can send more than just 2 bytes over a socket on 3ds making SmileNet a fast two-way online MultiPlayer solution for SmileBasic. So yeah I'm going to go experiment with some C websockets in a bit this week and also learn more about how the 3ds hardware talks and how Luma3DS interacts with the 3DS. This was a silly thing I didn't notice before but I can add any menu Item I want to Rosalina due to how it was coded, and then have it launch a thread, it's really quite sophisticated how they designed Rosalina. I'm going to be able to easily look at the rest of Rosalina's code now and with a few websockets and some memory mapping it should not be hard at all to get this thing up and running (I say that now). But so far despite some serious difficulties and confusion having to basically get people in the dev community to hold my hand and help me build Luma3DS for the first time on windows I have this all under control :P

Update Oh my gosh I fixed a bug that was really in the way of everything, and now I understand how Rosalina's draw buffers work. Also the project is now on github you are free to try to pull from it and build yourself but it isn't recommended yet. You'd have to build Luma3DS yourself. I'm not sure my version of the repo is set up to allow building using build.. Anyhow.. Eye Candy Below

Spoiler

And so this means, by temporarily halting the still-running SmileBasic process we can attach a live memory viewer , pressing down scrolls through it, I can't create much of a UI because this menu system runs while the GSP/DSP on the 3DS is frozen. That said though the benefit is that it can be triggered from Rosalina's menu which is part of Luma3DS by pressing L+DOWN+SELECT Then going to MISC, then going to SmileHook. It should be noted that if you do build this and it runs there are undocumented potentials for minor crashes still. It should also be noted that you should not touch any of the kernel level sources of Luma3DS yourself unless you KNOW What you are doing. With that out of the way here's what I've learned. SmileBasic most likely runs in the memory location range of 0x00100000 and has a memory range limit of the same size as a non mem extended 3DS app. A person I know in Japan tested on a Japanese 3DS and the ram readings when this is launched are the exact same as mine. That tells us something else, at least the starting memory of SmileBasic's ram is always initialized to the same values regardless of region. That is a very interesting fact. The offsets on the left are the virtually un-mapped memory, and it does appear to be linear memory but I can't be certain though it is also possible (someone else had mentioned) that I am potentially looking at some of SmileBasic's executable memory (though I don't think so that's probably in the heap) I still don't quite fully know what I am doing with all this yet but I'm getting around and the people in the 3DSDev community are fairly helpful, some thanks extends out to a few members such as Stary, stuckpixel, Wolfvak, Kitlith, Sono-San. They have helped me the most so far. The next step now that we can read from ram, write to ram, and also initiate our own thread is to figure out possibly a websocket, and also add in a feature that lets us dump ram to a file (I know other ram dumpers exist but it would still be nice to have it for convenience. ) If anyone would like to contribute to the project in the near future please message me (I'm usually in chat). Or you can respond to one of my several active forum threads. XD. TL;DR: SmileNet 2.0 coming soon probably (in a year) I don't know when. Ram viewing and modification seems to work though. That's cool.

Update I can ramp dump SmileBasic live now on real hardware but it doesn't look like I've found user-variable space yet: Here's a piece of what I dumped contained in SmileBasic's ram.

Load failed.Uninitialized variable used.DLC not found...Protected resource..Can't usIllegal function call...Can't use in tool program...Can't use in program....Use PRGEDIT before any Pndo 3DS ver 3.3.2.(C)2011-2016 SmileBoom 
Co.Ltd...ÿÿPRG.GRP.DAT.TXT.GALAGA..DRUAGA..SKYKID..A_VALKYRO...U...a...d...e...f...g...ch..sh..j...k...cl..s
il.m...n...o...p...ts..s...t...pau.u...by..dy..gy..end.agree...change..close...ok_delete...write...
ok_save.ng..ok..go..no..yes.pass....exit....abort...Off1....progOff1....markOff1....
helpFuncOn1.typeOn1.progOn1.markOn1.clockMin1...clockHour1..helpFunc24..
34..44..54..func4...markOff4....markOn4.4...15..25..35..45..55..func5...markOff5....
markOn5.batttOff....insButOff...capsButOff..findNextOff.repNextOff..findPrevOff.del.swKanaOn....
swCmdOn.swFindOnlineShift...pasteShift..delShift....undoShift...bsShift.copyShift...10u.20u.30u.40u.50u.60u.0u..
11u.M.hid:USER.hid:SPVR.dmp_LightEnv.lutEnabledD0.dmp_
LightEnv.lutScaleD0.dmp_FragmentMaterial.samplerD0.specular0.dmp_
FragmentLightSource[7].specular0.dmp_FragmentMaterial.specular0.dmp_
FragmentLightSourEnv.lutEnabledD1.dmp_LightEnv.lutScaleD1.dmp_FragmentMaterial.samplerD1.dmp_
LightEnv.absLutInputD1.dource[7].specular1.dmp_FragmentMaterial.specular1.dmp_FragmentLightSource[0]
.geomFactor1.dmp_Fragmenmp_FragmentLightSource[1].samplerDA.dmp_FragmentLightSource[2].
samplerDA.dmp_FragmentLightSource[3].mplerTB.dmp_Texture[3].ptSamplerB.dmp_LightEnv.lutScaleRG.dmp_
FragmentMaterial.samplerRG.dmp_LightEngmentLightSource[5].samplerSP.dmp_FragmentLightSource[6].
samplerSP.dmp_FragmentLightSource[7].sampleptSamplerR.dmp_Texture[3].ptNoiseU.dmp_Texture[3].ptClampU.dmp_Texture[3]
.ptShiftU.dmp_Texture[3].ptv[2].srcAlpha.dmp_TexEnv[3].srcAlpha.dmp_TexEnv[4].srcAlpha.dmp_TexEnv[5].srcAlpha.dmp_TexEnv[0].opeexEnv[0].combineAlpha.dmp_TexEnv[1].combineAlpha.dmp_TexEnv[2].combineAlpha.dmp_TexEnv[3].
combineAlprandRgb.dmp_TexEnv[4].operandRgb.dmp_TexEnv[5].operandRgb.dmp_TexEnv[0].scaleRgb.dmp_
TexEnv[1].scales.shadingDensitySrc.dmp_FragmentLightSource[0].distanceAttenuationEnabled.dmp_
FragmentLightSource[1]p_FragmentLightSource[7].distanceAttenuationEnabled.dmp_FragmentLightSource[0].
spotEnabled.dmp_Fragmmp_FragmentLightSource[1].enabled.dmp_FragmentLightSource[2].enabled.dmp_
FragmentLightSource[3].enaburce[3].shadowed.dmp_FragmentLightSource[4].shadowed.dmp_FragmentLightSource[5]
.shadowed.dmp_Fragmence[1].distanceAttenuationScale.dmp_FragmentLightSource[2].distanceAttenuationScale.dmp
_FragmentLight_FragOperation.enableClippingPlane.dmp_FragOperation.clippingPlane.dmp_Texture[0].samplerType.dmp
_TehtSource[5].twoSideDiffuse.dmp_FragmentLightSource[6].twoSideDiffuse.dmp_FragmentLightSource[7].twoSentMaterial
.diffuse.dmp_Texture[3].ptAlphaSeparate.dmp_FragOperation.alphaRefValue.dmp_LightEnv.confragmentLightSource[4]
.spotDirection.dmp_FragmentLightSource[5].spotDirection.dmp_FragmentLightSource].position.dmp_FragmentLightSource[7]
.position.dmp_Texture[3].ptSamplerAlphaMap.dmp_Texture[3].ptAlp.dmp_FragOperation.penumbraBias.dmp_
FragmentLightSource[0].distanceAttenuationBias.dmp_FragmentLighttLightSource[7].distanceAttenuationBias.dmp_
Texture[3].ptTexBias.dmp_LightEnv.clampHighlights.dmp_Te.dmp_FragmentLighting.ambient.dmp_FragmentMaterial
.ambient.dmp_FragOperation.enableAlphaTest.dmp_Tex.stream end.incompatible version.data error.file error.stream
 error.buffer error.need dictionary.insed exception....%s: invalid pointer %p..%s: logic error.%s: unspecified error...%s: runtime error...S.H.....A.S.C...A.B.S...A.C.O.S.....T.A.N...C.H.K.V.A.R.....T.A.N.H.....C.H.K.C.A.L.L...C.H.K.L.A.B.E...L.I.M.E.....

Update Here's a link to the partial ramdump from SmileBasic on dropbox: https://www.dropbox.com/s/mtsg56i8lxkej2t/SmileBasic_memdump09_26_2017.bin?dl=0 Open in a hex editor or do whatever you want.

Update So I've been trying to create code which safely dumps SmileBasic's ram and I finally did it, a safe dumper... I was going to use DMA but the DMA seems to cause severe crashes and kernel crashes so I switched back to using a buffer, and my own code. (wait am I using dma? ) Lol I guess not.. well anyway, I'm using a 1 KB buffer, writing to file. Here is a link to the memdumps of SmileBasic i've done for reverse engineering and analysis purposes as a backup: https://www.dropbox.com/s/870co4mc5h2p6eb/SmileBasic%20MemDumps.zip?dl=0 The ram dumping is cool. I'm closer to making SmileNet 2.0 a reality it's just taking lots of time (Reverse engineering always does)

SmileNet is basically like a bridge between SmileBasic and your computer

So in other words its in no way an independent network, just a network extension?

SmileNet will allow SmileBasic users to start with a basic program that puts some magic numbers into the internal ram of SmileBasic in arrays, and hopefully if they appear linear in ram, then one array will be the out stack and the other array will be the in stack. Essentially, the user will have to then use the in and out stack to talk to the computer over wifi (yes WiFi), and a program on their computer which I create will then handle the incoming and outgoing packets. That same program will also allow p2p connections with other SmileBasic users, so essentially if you create a SmileNet 2.0 compatible program or game then it's like having two way multiplayer locally but it will be faster because I'm accessing memory directly, it doesn't use Nintendo's friend code thing at all so it isn't limited to their servers, and you can host anywhere/for anyone. So let's say I made two player pong. The pong game would say "waiting for player 2 to join" and it would be checking an array for data in the "in" stack constantly until the "player joined" message showed up in the stack Then the code would execute conditionally based on incoming network messages, and also send messages out to synchronize the other player's game. The synchronization code for the game is up to the developer to create within SmileBasic themselves. All I'm going to do is provide a network stack for I/O within SmileBasic and a client/p2p program for pc that SmileBasic connects to which also allows other clients (on PC ) to connect to so that it rigs together a virtual local network for SmileBasic users to play games together and a network messaging stack. (My end goal is to set up a program that allows the SmileBasic chat to stream into a running SmileBasic program in real time) Plus to have Monster Tamer finally have optional multiplayer features. TL;DR: SmileNet 2.0 will allow p2p multiplayer over the internet in any SmileBasic app, you (the user) have to decide what data to send and receive in your programs and manage it yourself but let's just say alot of the heavy lifting will be done for you

Update Alright, this week was crazy.. well what's new? I finally modified a smilebasic variable using an external process and was able to see the change. I still need to test if it's possible to do this while a SmileBasic program is still running but I think it is. I'll test now actually *dum dee doo doo testing testing* It works live.

• SmileBasic seems to persistently store arrays starting at the ram address: 0x0082301C
• When using OPTION DEFINT line, the value will appear as 4 bytes. Persistently.
• The values in ram from the start point of the first-declared array seem to be linear enough that we can easily create a stack with just one array
• This should be safe, as long as the initialization of the stack happens before anything else.
• We have a persistent ram stack for SmileBasic data for a process sitting outside SmileBasic
• It is possible now using cfw to manipulate variables in a running SmileBasic program from outside it using user-created code that runs much faster than SmileBasic does.

So yeah, soon hopefully if I can wrap my head around sockets SmileNet 2.0 will live. Note: To remind everyone if you don't have the newest version of Luma3DS installed on your 3ds then you will NOT be able to use SmileNet 2.0 Another Update I NOW HAVE SmileNet connecting to my pc. On it's own thread. Through a socket. I've been able to use QT Input redirection client for pc to send actual bytes to SmileNet. now how to make it continuously update... hmmm...

• It is possible now using cfw to manipulate variables in a running SmileBasic program from outside it using user-created code that runs much faster than SmileBasic does.

This is really interesting. Is it possible to know which variable you're editing, other than having the exact address it's stored at? Or is it required that said variable is, for example, the first one used with

SOMEVAR=WHATEVER

?

• It is possible now using cfw to manipulate variables in a running SmileBasic program from outside it using user-created code that runs much faster than SmileBasic does.

This is really interesting. Is it possible to know which variable you're editing, other than having the exact address it's stored at? Or is it required that said variable is, for example, the first one used with

SOMEVAR=WHATEVER

?

It looks more like this:

DIM MYVARS%[9000]
FILL MYVARS%, 555555
'NOW YOU ARE SAFE TO MANIPULATE THIS ARRAY WITHIN SMILEBASIC HOWEVER...
'THAT ISN'T ALL THERE IS TO SMILENET.
'I WILL BE DEFINING SPECIFIC OFFSETS WITHIN SAID ARRAY
'SO THAT YOU CANNOT MESS UP. IT WILL BE LIKE THIS PROBABLY
'IVE ALREADY TESTED IT AND THIS PATTERN WORKS
'NOW ALL YOU WOULD NEED TO DO IS KNOW WHICH SECTIONS OF THE ARRAY ARE FOR OUT DATA AND WHICH SECTIONS ARE FOR IN DATA
'THE FIRST 2 VALUES WOULD PROBABLY BE FOR SIGNALLING 'DATA OUT RECEIVED' OR 'NEW DATA IN'
'YOU WOULD THEN SET THOSE FLAGS TO REFLECT THE STATE OF THE STACK.
'I WANT TO MAKE IT MORE FLEXIBLE BUT THE FIRST HALF OF SMILENETS RAM WILL PROBABLY BE FOR OUT AND THE OTHER HALF FOR IN
'ALL BYTES ON THE OUT WILL PROBABLY BE SENT OUT AT ONCE AND ALL IN, RECEIVED AT ONCE. NO WORRIES THERE.        

Small Update So I've got sockets mostly worked out and now I'm working on buffers and data stuff... and how best to represent it. This was bad, it caused Luma3DS and Rosalina Menu to be stuck in the menus.. but it sure as heck was cool. The next step is to see if I can replicate it , but instead have the bytes transferred into SmileBasic from the internet (YES LITERALLY FROM THE INTERNET :D )

Spoiler

Top: 3DS receiving message through wifi (SmileBasic ram is mapped I'm just not injecting yet) Bottom: IRC chat. A bot of mine transfers it to Rosalina.

Update Today, I've used the same mechanics as with Rosalina but I've discovered I can transfer utf8 format chars directly into SmileBasic ram... Well that result turned into me being able to control MML through a chatbot I created. I put the A, B, C, D, E, F, or G letter in, a long string such as: "BERBEFBSDGBDFDBADFBECB" and it sends it all at once to SmileBasic at really fast (nearly instant) speed. SmileNet is definitely proving to be a fast solution at least on a local client side. Next up, Work on the actual buffer and stop toying around (lol), and make it able to also send data out. It's going to need a signalling system to know when to send data out and when to receive it back. (or I could leave that to the user). I guess maybe it should always send all data back and always listen for all data coming in. That would make it the most open.. So A PC program on the user side will also have to be running such that it will actually work like a bridge between the 3DS, and the rest of the internet. Here is a C# code example that sends data to SmileNet using UDP packets: https://pastebin.com/TkqwKNhG And yeah so, sending full utf8 strings to SmileBasic directly is pretty neat. I can even draw them on the screen in real time. So basically any standard string I can receive in C# I can send to SmileBasic in real time. now. That's cool I guess.

Update Alright, I know I kind of vanished off the forums for a little while after the halloween contest and I haven't posted ANY news about SmileNet 2.0. I spent a lot of time dealing with uncertainties and confusion as well as basic life stuff, but I'm happy to announce some new progress today. A user by the name of Stary has been a huge help to me despite also sometimes being seemingly vauge they did infact give me just enough information at various intervals to move foreward. So what's the deal here? SMILENET with TCP is a go. So far all I know is that I can send text characters in utf8 format between the pc and 3ds using SmileNet, on a stable TCP connection that has been bound. It means I won't have to resort to using an unstable connectionless SOCK_DGRAM connection (aka UDP) to send data. It also means that the connection should linger, for as long as the two devices can continue to be connected. It should be just as stable a connection as your local wireless. It also means, that so far.. well more or less it may be possible to have another 3ds connect to a different 3ds directly and rule out the PC as a middle man but I still want to make the first version use a PC as a middleman simply to ensure that I actually get this right. So yeah, from what I can tell my head has been filled to the brim and almost broken with Nintendo 3Ds dev Knowledge and I still barely understand how I even pulled this off, A LOT of help and perseverence. And Tears and sweat and sleep loss. THIS IS A DAY TO CELEBRATE for our community. Future Possibilities.

• Static file sending from PC over a network into SmileBasic is now a possibility.
• Potential for sound streaming live from a PC client into SmileNet (and directly into a smilebasic array in real time)
• Multiplayer games for SmileBasic in real time or atleast MultiPlayer trades and turn-based but more or less likely to support MultiPlayer in general
• It should be possible to have one 3ds act as the host and another as the client, through a pc program I'll create.
• The pc program will most probably be data agnostic and not care what's coming through, it would be up to the SmileBasic creator to determine how networking is handled on the SmileBasic game/program. I can most likely make a send / recieve buffer function
• With extra work it might be possible to target multiple clients or only clients selectively from a list. All clients will still get the data but if the SmileBasic program is made to filter out intended client name or user then it should still work so in theory all clients will always recieve all data but the 'messaging' system built ontop of the base SmileNet protocall would allow filtering and selective send/recieve!
• It's now time to start unit testing and performing a variety of tests to see what is and not possible but I already know moving sprites in real time on a 3ds using a pc will be possible. As well as chats.

Sounds amazing! People better get on developing for this once it's done.

Sounds amazing! People better get on developing for this once it's done.

I'm nearing the end of the early stages and getting to the more technical aspect. Right now I am worrying about New Nintendo 3ds compatibility and trying to work towards making it work on all 3ds models.