Sound is key to a great user experience. And so i give you: the Welcome orchestra. Actually quite giddy about how pleasing this sounds :)

It's really somewhere in-between a Preemptive scheduler and Cooperative scheduler, as it doesn't truly interrupt thread (commands), but rather boils them down to single lines of code to facilitate the scheduler; But this also means that it isn't at the mercy of a process like Cooperative (unless WAIT is used), nor do processes need to be explicitly programmed to hand control over to the scheduler.

Due to SmileBASIC limitations, it's not perfect however; It cannot natively support IF statements and other multi-command blocks of code, so "wrappers" using COMMON DEF must be implemented. And as there is no true method of interruption, programs must be thoughtfully coded around the scheduler; a poorly placed wait can cause the whole system to freeze, making the scheduler merely preemptive-esque.

Essentially, to adopt terms that closely meet the implementation, it's single-threaded (one command at a time), and similar to a 'time slice', the scheduler regularly runs, in-between threads, splitting processing time between process threads equally.

Not at the moment. I want to wait till I have the core OS working before I publish anything. But I will explain the basics: It works by using an empty slot as the "thread space"; The software will load up the code for both "processes" into the "schedule", and the "scheduler" will replace the current "thread" with the next thread in the schedule and execute it.

It may look terribly BASIC, but it's what's inside that counts! And in this case, that means... PREEMPTION! What's that mean, you ask? That means this simple little program is using a form of MULTITASKING! Using a scheduler, it schedules equally the repeated printing of the alphabet to the console AND control of the pointer via input, allowing both to run effectively the same time!

Been quite a few months since I worked on this. Reworked the input library, which itself is a W.I.P like the rest, and designed a new background. Pictured is a test of the window and input libraries.

@komodo † I don't really see how. You're not accessing any parts of the system directly, but rather the system is passing information to SmileBASIC, which in turn gives access to select parts via code (just like the rest of the hardware) I could even rattle of an example of how the code might work: XON AMIIBO AMIIBO OUT ID$, NICKNM$ IF RESULT==1 && ID$=="KIRBY" THEN PRINT "Hiiii!"

@Zee Not necessarily. You wouldn't be able to use copyrighted content for published software, but you could still associate different amiibos with different sets of code; I.E isabelle could unlock a hat in a game or mario could add an extra life. It'd be better than how that crossword title uses them :|

Anyone else think they should add Amiibo support in a future update? Users could add unlockable functionality to their games, and even scan their own Amiibos to limit certain functions to specific characters! This would also have the side effect of supporting yet to be released Amiibos. Thoughts?

I dont have anything uploaded yet. This is part of a bigger project, which if successful, will be uploaded (much?) later on. However, when that happens, a different version of this tool, and the code to use the libraries in other programs, will be packaged and released. Sorry about that.

In order to increase efficiency (and build a better custom assigned smile tool) I have converted my development command-line and packaging tool into graphical equivalents. This allows for quicker launching (simple button presses vs. typing out commands) AND eases in library packaging (lists folders vs. typing folder name & coding filename error handling.)

a string which can be saved and loaded at will, and appended to the specified slot! Along with COMMON DEF and USE this allows for me to create "code libraries" that contain custom methods, callable from other software! I've dubbed them "Modular Code Libraries" (or MCL files) due to their modular nature. Neat, no?

In order to reduce the file size of the actual system, and to facilitate third party software, I had to create a method of making a modular program which would reside in a single slot yet be able to have whole blocks of code addable through code. I found out that PRGGET$() includes the linebreak, which is preserved when saved, so I created a way of converting a program into...

Not currently. Each window is 9 sprites (8 sprites linked to a 9th "master sprite"); This test was to test a subroutine that could create multiple windows efficiently. I do plan on using an numeric array however to store a list of the master sprites (which affect entire window position and appearance) in the actual system.

After hours chasing down bugs i finally built code to generate windows! I also added a rough 3D prioritization method for the last window drawn (The "Active" window) to this demo. One step closer to my goal!

Niiice

O-o-oh. That makes total sense! I could stretch the sides and top to cut down on graphics AND have a more refined range of window sizes! (Since it'll no longer rely on the width or height if the side sprites {16x16px}) Thanks for the tip!

Are you making a C#-like language? o0o

@Kl'Dck Hul: No I have not actually. Care to explain? If it supports full control over the design, adjustment of the Z-index per window (as opposed to the entire drawing space), resizing of the "window" without compromising elements, and attachment of sprites (Window Controls) then I'm all ears! (These req. are a must!)