Multitasking

You know SmileBASIC doesn't support multitasking. I am thinking of writing a program that can handle running multiple programs, interleaving their commands and executing them. Not quite as simple as that with the structured programming (i.e.: FOR, IF and DEF), and conflicting variables, of course, but I think I know how to fix that. 1: Give all variables and DEF functions a prefix in code before executing. Maybe 2 letters. Like the first program will have the prefix AA on every variable, and the next one will have AB. This will keep the programs' variables from conflicting when they both use variables of the same name. 2: Remove comments and blank lines from the code and move DEF blocks from the code to PRG SLOT 2 with prefixes so DEFS for other programs don't conflict, changed to COMMON DEF and made usable with USE 2. 3: Handle @labels, VSYNC, WAIT, DATA, READ, RESTORE, IF, FOR, WHILE, and REPEAT commands manually, not executing them. 4: If the program is not focused, do not execute sound or visual commands, but handle their effects in memory and reload the data on screen when focused. 5: After those things, execute the remaining commands interleaved. Executing them by using PRGSET to load a command or commands into PRG SLOT 3 and using EXEC 3 to make SmileBASIC itself execute the commands. So that's what I think I have to do, but what have I missed or gotten wrong? By the way, I think it would be possible to save and load execution states with this kind of program. Maybe I could put that in too. Postscript 22:55 3/2/16 - Also, what do you think would be a good button combination for switching programs?

sounds very easy, if its just changing how you approach writing programs. Maybe harder if you are writing a tool that converts existing programs to be ran simultaneously. But if the idea in mind is a tool that scans a program and looks for problem scenarios that tell the coder "this needs to be cleaned up for multi-task environment" they can then do the necessary changes, then it might be easier. Or is it more like a runtime/OS? Would it be like a parent program running two child programs? Assuming a non multi-tasked program uses a lot of sprites, the parent program would probably handle storing sprite states, keep a count of how many maincnt frames the program has ran for. Would have to detect the child's main loop and make it a function, make sure the function is using globals instead of function locals. saving graphics state in an array might take a lot of memory because you can't save it I think without a save dialog box. its alot easier if the program knew and implemented functions or was written knowing that its sprites were "volatile" I think is the word. Implemented a "multitask" interface. I'm sure it would mirror modern os apis, minimize/maximize or lost focus, focused etc knowing that it not longer should affect the screen and should quickly perform its tasks. don't perform vsyncs, waits, don't block waiting for a keypress or cause dialog boxes. Asks the parent if there is enough memory to save its own graphics page, if the page will be destroyed etc. the parent program could also scan the programs public functions for commands that would violate the behavior of idle'd/slept program and throw an error before loading the program saying it doesn't obey the multi-task rules etc. Were you looking for a more interleaved execution where every program is guaranteed access every frame? I don't know how to do that with things that wait until a button press etc.. vsyncs might be the thing to replace with the mechanism that tells the parent "I'm done, goto the next child's needs" the bgmchk would have to be struck out when not focused. But what if people made games that didn't use music, and somebody made an SB music player that played music while you play a game in a different slot. the music player need access to the bgmchk function in that case. Alot of possibilites for a multi-task environment. using an editor, with your "pet-simulator" running in the background and makes an alert sound, and you get a scrolling marque across the bottom saying its hungry, and sb music playing in the background..granted I don't think there is a lot of demand for stuff like that..but why not.

I've already played around with this a little bit. Possible? Definitely. Easy? Not really. Benefits? Not many. I wish you luck, and I can't wait to see what this develops into.

Or is it more like a runtime/OS? Would it be like a parent program running two child programs?

That's what I was thinking of! I actually kinda wanted to be able to put the programs into windows, and you can have multiple programs on screen at once. That would be a big mess, though. They're designed for the whole screens. It would be hard to code, ugly, and not fun to use. So I think it should be more like a mobile OS! Shocking, I know. (sarcastic tone)

But what if people made games that didn't use music, and somebody made an SB music player that played music while you play a game in a different slot. the music player need access to the bgmchk function in that case. Alot of possibilites for a multi-task environment. using an editor, with your "pet-simulator" running in the background and makes an alert sound, and you get a scrolling marque across the bottom saying its hungry, and sb music playing in the background..granted I don't think there is a lot of demand for stuff like that..but why not.

Oh yeah, that's something I wanted! Maybe the commands for background notifications, sounds, and music should be written as comments or reserved variables so the program doesn't crash when running standalone. OHH maybe there could be a chat program in the background so you can be in an application and ba-ding! You got a message! *realizes how the multiplayer commands work* Yep, we're gonna have to restrict multiplayer commands to one program at a time. yeaahhh on the subject of dialog boxes, with SAVE, should we keep that from interrupting your focused program? Instead of popping up the SmileBASIC SAVE dialog which halts the execution of the multitask handler itself, just manually halt the execution of the program wishing to save, and put a notification like "BUBBLESORT.PRG" would like to save a file., to which the user can tap it and save the file or hold the contents in memory to save later. So I'm thinking the notifications should be on the bottom of the touch screen so you can tap them? And again I'd like to ask what's a good button combination for unfocusing a program?

I've already played around with this a little bit. Possible? Definitely. Easy? Not really. Benefits? Not many. I wish you luck, and I can't wait to see what this develops into.

Yeah this may be useful in some cases, maybe if you have a program that takes a long time to process something, but you want to play a game while it's processing? *shivers* I keep thinking about how it'll take up memory and run slower, but that's just what multitasking does.

I'm thinking now it might be best to make the notifications sideways on the right side of the touch screen. Maybe it could have different colors on it, so when you tap green, it could take you to the program, and when you tap red, it'll close the notification. Or maybe something that looks better like grey and blue.

Ohh but I forgot about the SmileBASIC keyboard. So a ticker on the top screen, on the right edge. Activate the notification with a button combination. I should make that combination editable But the default I think should be L+R+something. Maybe this A: Accept notification B: Ignore notification X: Close Y: Unfocus

I had pondered this idea way back on PTC when i was creating an 'OS'. This would be an amazing program to use, especially if it could recompile or reconfigure a program you've written to operate in the multitasking program. I really like the idea of having windows the programs run in. I suggest you create a simple, small, alpha-numerical keyboard on the touch screen as a kind of 'window' so that you can still perform operations and things on the touch screen without sacrificing the whole thing to the panel keyboard SB uses.

WOW the last post here was nine months ago? time goes by too fast. I'm thinking again about something like this, that still requires automatically added interrupts into code, but now for a debugger-type program. possibly even with a function that allows you to view the execution real-time and add break points and edit, view, and save variables and execution state on another 3ds

Question: Can you hand off execution between program slots that edit each other without continuously building up a stack in memory?