SmileBASIC Emulator?

Anyone know if there's a SmileBASIC emulator available? Or if anyone is working on one?

Not any that are very complete. Otya (Japanese User) has one at https://github.com/otya128/otyaSMILEBASIC

you can always rip your copy and run it through citra :p

you can always rip your copy and run it through citra :p

Details on how to do this pls

you can always rip your copy and run it through citra :p

That is if Citra is even good with SmileBASIC at all.

you can always rip your copy and run it through citra :p

Details on how to do this pls

You need a CFW and you need to rip your game into a cia file and run it through Citra, to get CFW follow https://github.com/Plailect/Guide/wiki

Anyone know if there's a SmileBASIC emulator available? Or if anyone is working on one?

I'm working on a project called TinySB which will basically be a different version of SmileBasic that should be capable of running any SmileBasic code! It's in BETA right now. Search the forums for TinySB you will find my post. I need to re work a lot of it right now but it's a work in progress and i'm not stopping for no one. Edit: Oh yeah, I forgot to mention for now it's Windows Only.

EDIT This directed mainly at CoinzReturns Did you see my Interpreter? I didn't stop because of anyone, I just got bored. Moreover, I didn't know anything about opengl, and I didn't feel like learning. http://smilebasicsource.com/forum?ftid=665 Hey though, here's my code. Take any part you want. I'm especially proud of the math string solving code, you gave it a string like ((not 1%5) or 4(ASC("r") + 8) / 5 and it would return the value exactly the way it would in SB. I don't think it's the most optimized but certain parts might make a good placeholder. You should be able to find at least a couple good placeholders. I was wondering if a better way to solve math strings would be to rewrite them to work from left to right at at startup, negating parenthesis, like 3*(4+5) = 3*4+3*5

I can explain how I got it to work, basically I had a function called Solve(string), and solve("1+1") would return the numeric value 2. If it went through an equation right to left respecting the order of operations as it went and came across a parenthesis, say in "1+(1+1)", it would call a function called get parenthesis, which would basically shave off the outer parts of a math string. So getParenthesis("1+(1+1)") Will return the string "1+1". If there were more parenthesis in there, like "1+(1+(3*2))" it would return "1+(3*2)". So the thing that tripped me up here was a new programming technique I learned, which was recursive programming. At least in the language I used, c++, and probably most other languages that use functions, you can actually call a function in the middle of a function, and it will run basically a completely seperate instance of that function in the function itself. So it actually called solve(getparenthesis(mathstring)) to get the next value when it ran into "(" in math strings. The way it was set up means an infinite amount of stacked parenthesis in a single string can be solved in the correct order. After I'd done all that I realized it ran very slowly however. I started looking into doing what you're doing right now, which is turning math strings into something that can be processed more easily. What programming language are you using?

why not call solve() when you reach parenthesis? so like solve("1+(1+1)") would first call solve("1+1") which returns 2, then call solve("1+2") (for example)

why not call solve() when you reach parenthesis? so like solve("1+(1+1)") would first call solve("1+1") which returns 2, then call solve("1+2") (for example)

That's the idea, then jumping to the end of the matching parenthesis, but reading tc's post a second time it looks like he knows recursive programming. I wouldn't mind helping you tc, if I could see your code I might be able to port some parts of my code over. I pretty much finished all non-graphic related commands and functionality.

I can explain how I got it to work, basically I had a function called Solve(string), and solve("1+1") would return the numeric value 2. If it went through an equation right to left respecting the order of operations as it went and came across a parenthesis, say in "1+(1+1)", it would call a function called get parenthesis, which would basically shave off the outer parts of a math string. So getParenthesis("1+(1+1)") Will return the string "1+1". If there were more parenthesis in there, like "1+(1+(3*2))" it would return "1+(3*2)". So the thing that tripped me up here was a new programming technique I learned, which was recursive programming. At least in the language I used, c++, and probably most other languages that use functions, you can actually call a function in the middle of a function, and it will run basically a completely seperate instance of that function in the function itself. So it actually called solve(getparenthesis(mathstring)) to get the next value when it ran into "(" in math strings. The way it was set up means an infinite amount of stacked parenthesis in a single string can be solved in the correct order. After I'd done all that I realized it ran very slowly however. I started looking into doing what you're doing right now, which is turning math strings into something that can be processed more easily. What programming language are you using?

Right now I am using Playbasic. The fastest way to solve these equasions is to create a math stack. And rather than step through it recursively , you run a multiple pass and solve everything in order at once That's how the simple math function works.. problem is.. it's limited and doesn't account for every symbol yet. I'll be porting all of TinySB to C++ later on though. For reals. Right now the process is just a matter of hammering out the right logical steps. Recursion can be fast maybe you used the wrong methodology. I don't plan to use recursion for the math parser at all , I suppose that's part of why I'm having a hard time. Of course that's a partial lie. So I have a basic solve equasion. I will have a function that steps through the original input and sorts it into tokens. This is the kind of data it would generate

A
ASGN
A
200
SUB
18
+
(
32
SUB
8
)

Each of those lines evaluates to a token. Tokens will be in a table as such:

A | Variable
= | Assignment
A | Variable
SUB | Operation
18 | Value
ADD | Operation
PARST | Parenthesis Start
32 | Value
SUB | Operation
18 | Value
PARND | Parenthesis End

now instead of working with strings directly I have a linear string array which can store individual strings or variable values and I've been using something called a parse-stack builder. A parse-stack builder doesn't care about the input or the nature of it. It's goal is to fully interpret an inputted expression onto a formatted execution stack as symbols instead of as strings because strings can be very arbitrary and I learned the hard way dealing with the literal position of a string (i'm not using CHR$ arrays ) is iffy when your iterator value and the length of the string can change at random and returning the new changed length is inaccurate. So we have two steps so far. My logical step which tries to break the string apart into an array, this is sort of similar to a

string.splitby(SymbolsList)

function. Actually it's what i'm trying to create. I'm trying to ultimately start off by creating a way to recognize any symbol of any length within a source string , and then rip it out as a sub string at a location in a source string, cut it out entirely of the source string, and then continue stepping through the new length-ed source string from the first character all over again until the source string's length is null. When the source string's length is null it means there are no more symbols to be extracted and the loop that collects symbols can end. It's quite elegant in it's own right and was also the only solution that worked for me for my simple math parser which always gets correct answers each and every time in respect to simple arithmetic (not including parenthesis) So the goal is to basically create these functions. Which should give us an array with the data I showed you above. once we have this data it's super easy to parse everything. The down side is things like dealing with decimals and such I haven't gotten there yet also I haven't gotten into dealing with special character cases. I will get there eventually.. But this is the start of a regular expression black-box.

Tokenslist$() = BuildTokenListFromSymbolsList(Symbols_List$(), SourceString$ )

The next function we need is something that knows how to parse all of this. It would be something super simple like

Variable_Result = ParseTokenizedExprFromArray( TokensList$() )

So when I'm parsing actual code if I find an assignment operator I get the rightmost side of the assignment operator, and then try to find where the expression actually stops. This is the next hardest part due to how arbitrary an expression can be. What symbol or statement usually ends an expression? Well.. a THEN or a THEN IF.. problem is I may have to parse more than one of those in a line.

IF A==B THEN IF A==C THEN IF D+1==5 THEN GOSUB @HALLO

You see how it wouldn't be so simple to find the == symbol and send the whole of the remaining of the string to the BuildTokenLIst function. The buildTokenlist function would have to know more rules about how to check for THEN / IF breaks. but to keep it simplified it doesn't. So well I need to build another function to extract something like this:

Conditions(1)$ = " A==B "
Conditions(2)$ =" A==C"
Conditions(3)$ =" D+1==5 "

We're not done yet. I have to have another function which linearly extracts the Variable value from the left side. Then uses the comparison operator.. and returns a boolean of true or false for the right side. It would look like this:

For I = 1 to Conditions_Found
LeftValue = val( Get_LeftValue$( Conditions(1)$ )
RightValue =val(Get_RightValue$(Conditions(1)$ )
if LeftValue == RightValue then Can_Continue_EXPR=True
if Can_Continue_EXPR = false then exitfor

As you can see at this point. I can actually build a list of all the tokens in my string Then during parsing if I happen to find any == signs or any = signs I can optionally parse for then statements or i can parse for the literal math statement and get the math value. I haven't covered all of the conditions yet but doing the parsing in this structure allows me to code for specific cases on an operator. This is important because you have to search for things like is there another if or then statement? I plan to build universal handling functions for such cases though so it will run code with very long math statements or it will run code that has a ton of if/then statements. The wonderful thing about parsing an if-then statement this way however is that it halts parsing the whole expression if a false statement is found. So let's assume C=1000 and D is 9

IF C==1000 THEN IF D=10  THEN PRINT "HELLO " +(myfunction(Convertedstring$[thisindex])

It wouldn't even reach the function name evaluation in my runtime. It would just move onto the next line of code if it knew that the rest of the expression can not be parsed. This little optimization can make a big difference with tons of if/then statements and I plan to implement other little things like this too. At any rate it won't make a huge difference playbasic can run thousands of loops at a time and not lag... I used to deal with 2000 individual particle objects and never have lag on an old pc that only had 500 mb of ram ^o^ I hope that gives you some insight into the mechanics of how i plan to have TinySB work. in C++ the code will look a lot cleaner as I find better ways to express what I want TinySB to actually do.