It might sound like a stretch, but it has actually been done in the past (Wang 2200). How would it work?: We would microcode a CPU so that it would take the BASIC instructions, and execute them. We could also run it at a higher level (such as assembly), but that would result in slower execution times. Is it feasible?: Maybe. The computer would definitely run at a lower clock speed than the 3ds, but it would also use the clock cycles FAR more efficiently. Its hard to tell.hasn't this already happened? oh wait that was just a raspberry pi with SB, a screen, an emulator for some obscure console and a keyboard, so it wasn't technically built for SB, but it's included with it.
Dedicated Machine to run SmileBASIC?
ShellyCreated:
The Pasocom Mini exists.
The Pasocom Mini exists.There's even an extra thread on the Pasocom Mini.
You didn't say "Pasocom Mini" :p
You could have talked about something else.You didn't say "Pasocom Mini" :pi was talking about it
With TCP SmileNet, you could easily set up a SmileBasic program that sends opcodes over the network to another machine, to have it co-process that, and then have a wait-on loop in the main loop of the SmileBasic program for the recieved transmission of opcode completed running but, this isn't practical for JUST in time complications or compilations because of the fact that it would always take more time for packets to transfer to another machine, be processed, and then be returned. That's just due to SmileBasic and SmileNet requiring MORE loop cycles to complete packet transmissions than is needed for SmileBasic to run the calculation on it's own (unless the calculation is so specialized the gains from network transmission co-processing would be greater than the time-wait loss.) That's just my two cents. Alternatively, you coudl set up a dummy server within SmileNet that runs a SmileBasic program who's only job is to parse and run transmitted code results from another machine. A good example of this, is an nes Emulator running on the PC side, transmitting pixel frame data to the 3ds, and recieving 3ds-side input data and sending it to the Nes-Emulator on PC. This is something that would benefit from co-processing, even if the lag would be pretty reasonable, it wouldn't be impossibly unreasonable you'd probably get up to 30 plus frames considering that SmileNet can transmit alot of packets in a little time.It might sound like a stretch, but it has actually been done in the past (Wang 2200). How would it work?: We would microcode a CPU so that it would take the BASIC instructions, and execute them. We could also run it at a higher level (such as assembly), but that would result in slower execution times. Is it feasible?: Maybe. The computer would definitely run at a lower clock speed than the 3ds, but it would also use the clock cycles FAR more efficiently. Its hard to tell.Another possibility is something like a FPGA being ran as a coprocessor (the most likely way this could be done is with something like an esp8266, a FPGA, and branching off of Coinz's work).