Login
This is a preview website! Changes made may get reset and will not carry over to the final version! Original website still up at https://old.smilebasicsource.com

Midori-OS

Root / Submissions / [.]

Autz64Created:
Download:53383XCF
Version:1.0Size:2.8 MB
I came late to the OS meme party, but anyways. Midori-OS is a scalable mock-OS made with the idea of making app development more easy and accesible, instead of using the typical approach of editing the sourcecode directly. On Midori-OS, users can make apps that Midori imports automatically to the code, you don't have to touch the sourcecode! You can export and import apps as you please with no hassle. Making an app for a mock-OS has never been easier! Midori-OS (1.0.1) comes with the following:
  • Terminal. App with diverse functionality, but most importantly, create shortcuts.
  • File Explorer. App to rename and delete files from SmileBASIC.
  • Wire3D. A small 3D demo, showing an hypercube.
  • Input test. Another small demo, showing different functionalities of Midori API.
  • SPaint. A useless paint app with tools and colors
  • Help. An useful embed app that tells most details of Midori usage and app development.
  • DEMO1 (as external .pkg). Small app that shows communication capabilities between apps
  • DEMO2 (as external .pkg). Small app that abuses direct memory access to corrupt programs.
  • Spaceship (as external .pkg). Small minigame where you shoot aliens.
  • Calculator (as external .pkg). Simple Calculator.
  • Chip8 emulator (as external .pkg). A chip8 emulator with Tetris in it (by 12Me21).

Instructions:

Load "EXECUTE" file, and let it do some magic. All programs are acessible via Start Menu -> Programs.

Controls:

  • L: Left-click.
  • R: Right-click.
  • A:Enter.
  • Y: Backspace.
  • Left-Stick /Touchscreen: Cursor movement.
  • R while hovering a box on taskbar: Close that window.
For app development, refer to the following pages: API reference: https://smilebasicsource.com/page?pid=1211 Making your first app: https://smilebasicsource.com/page?pid=1212

Notes:

Why is "Midori" written in Katakana?
"Special Thanks"
  • 12Me21: For creating VARS_ARRAY() and CHIP8 demo.
"Changelog"0.0: Public testing 1.0: Initial Release 1.0.1:
  • Fixed a bug with the desktop icon save/load
  • Added the following commands: SET_SIZE, SET_BANNERCOLOR, SET_BACKCOLOR, SIMPLE_INIT(), VARS_ARRAY(), VARS_ARRAY_ALLOC()
  • Fixed some oddities with the window drawing coordinates.
  • Fixed some stuff with PKG Loader, now it should load more fast.
(I'm using my old 3DS right now, so this might not actually be a problem...) I think it would be better to use the entire lower screen to control the mouse, maybe holding L or something would switch between keyboard and touchpad mode. Also there seems to be a problem with dragging windows around while using the touchscreen to control the cursor.

Replying to:12Me21
(I'm using my old 3DS right now, so this might not actually be a problem...) I think it would be better to use the entire lower screen to control the mouse, maybe holding L or something would switch between keyboard and touchpad mode. Also there seems to be a problem with dragging windows around while using the touchscreen to control the cursor.
I have an old 3DS (small) and is not a problem for me because I got used to it. I could add that feature. And yes, the cursor goes "off" when dragging near the window borders (specially up and down). I have an idea on how to fix it but, uhm... it gives these errors. Good thing the stick movement is not THAT noticeable.

Replying to:12Me21
(I'm using my old 3DS right now, so this might not actually be a problem...) I think it would be better to use the entire lower screen to control the mouse, maybe holding L or something would switch between keyboard and touchpad mode. Also there seems to be a problem with dragging windows around while using the touchscreen to control the cursor.
If you held L to enable the keyboard, you couldn't have a shift shortcut (unless you mapped it to another button.)

Replying to:12Me21
(I'm using my old 3DS right now, so this might not actually be a problem...) I think it would be better to use the entire lower screen to control the mouse, maybe holding L or something would switch between keyboard and touchpad mode. Also there seems to be a problem with dragging windows around while using the touchscreen to control the cursor.
You could just have briefly pressing L be a quick shift button.

I'm truly amazed at what people can do with SmileBasic. Great job in making this. I'd like to make a request to the website and to those who are very experienced in programming that if it would be possible to make an emulation which is focused around the Assembly Language. This means that you have the means to mess with memory that controls not only the hardware but also the buttons and touch screen, etc. I've been experimenting on the old commodore 64 and Ti-99/4a emulators to see how Assembly Language can be used to create programs that pus the limits of the machine. (Even though it's an emulator)

Replying to:LucasJG1994
I'm truly amazed at what people can do with SmileBasic. Great job in making this. I'd like to make a request to the website and to those who are very experienced in programming that if it would be possible to make an emulation which is focused around the Assembly Language. This means that you have the means to mess with memory that controls not only the hardware but also the buttons and touch screen, etc. I've been experimenting on the old commodore 64 and Ti-99/4a emulators to see how Assembly Language can be used to create programs that pus the limits of the machine. (Even though it's an emulator)
I'd be happy to help with an emulator! I've designed two virtual 16-bit computers which run in SmileBASIC that are programmed in a unique assembly language. I love the low-level stuff!

Replying to:LucasJG1994
I'm truly amazed at what people can do with SmileBasic. Great job in making this. I'd like to make a request to the website and to those who are very experienced in programming that if it would be possible to make an emulation which is focused around the Assembly Language. This means that you have the means to mess with memory that controls not only the hardware but also the buttons and touch screen, etc. I've been experimenting on the old commodore 64 and Ti-99/4a emulators to see how Assembly Language can be used to create programs that pus the limits of the machine. (Even though it's an emulator)
@bluekrill Thanks for the help. I also am fascinated by the old languages such as assembly. But i also find it important to learn this language as it opens you eyes to what you can really do with a machine without restrictions.

You should definitely use GCLIP if you aren't already.

Replying to:LucasJG1994
I'm truly amazed at what people can do with SmileBasic. Great job in making this. I'd like to make a request to the website and to those who are very experienced in programming that if it would be possible to make an emulation which is focused around the Assembly Language. This means that you have the means to mess with memory that controls not only the hardware but also the buttons and touch screen, etc. I've been experimenting on the old commodore 64 and Ti-99/4a emulators to see how Assembly Language can be used to create programs that pus the limits of the machine. (Even though it's an emulator)
I've written a few programs for my virtual computers. My favourites are probably my brainfuck interpreters because they are very easy to write in assembly! :)

Yeah... this is not the place to rage quit...

Replying to:12Me21
You should definitely use GCLIP if you aren't already.
Yeah, if a graphic in an app would go beyond the window, it can so and dance around outside of the window
SpoilerThis happened to me by doing this: - Open the DEMO1 app and spawn a child. - Close the dad and open the Spaceship game. - Mash the L button on the "Send message to dad" text on the child and the game starts for 1 frame and then returns to the title screen though it didn't reset the variables. - After 1 hour of mashing L I managed to get -100 lifes which doesn't fit in the window so it goes beyond it.

Replying to:12Me21
You should definitely use GCLIP if you aren't already.
The way how DEMO1 works is with direct memory manipulation. That's expected, but I should do some checks to avoid it.

Version 1.0 is OUT! Includes:
  • Wallpaper Support
  • More API DEFS
  • Alternate mode for touchscreen
  • Better design
  • Glitch fixes
Check out the API DEF reference to see changes!

Replying to:Autz64
Version 1.0 is OUT! Includes:
  • Wallpaper Support
  • More API DEFS
  • Alternate mode for touchscreen
  • Better design
  • Glitch fixes
Check out the API DEF reference to see changes!
woah something that has caused me to retrieve my 3ds from the 4th dimentional void and download a project again!

woah something that has caused me to upload you know!

Here's a system for giving windows access to arrays (Based on OTYAX): Because SB doesn't let you create an array of arrays, the next best thing is to make a bunch of global arrays, and access them with VAR("name") When the window is created, you use VARS_ARRAY_ALLOC to request an array. The array ID number is stored in VARS_NUM, so you can access it later with VARS_ARRAY
'Put this code in __APMN, after DIM VARS_STR$ or something

DIM A_USED[256] 'this keeps track of which window is using each array (-1 = unused)
FILL A_USED,-1
DIM A_FREE[0] 'empty array
IF FALSE THEN DIM _A_0[0],_A_1[0],_A_2[0],_A_3[0],_A_4[0],_A_5[0],_A_6[0],_A_7[0],...,_A_FF[0]
'Code to generate that really long DIM list:
'FOR I=0 TO 255
' S$=S$+"_A_"+HEX$(I)+"[0],"
'NEXT
'CLIPBOARD S$

'Request an array to use.
'WID: window ID
'VNUM: VARS_NUM index to use
'ARRAY: array
'Returns 1 if it succeeded, or 0 if it failed (ran out of arrays)
DEF VARS_ARRAY_ALLOC(WID,VNUM,ARRAY)
 VAR I
 FOR I=0 TO LEN(_A_USED)-1
  IF _A_USED[I]==-1 THEN
   _A_USED[I]=WID
   VARS_NUM[WID,VNUM]=I
   VARS_ARRAY_SET WID,VNUM,ARRAY
   RETURN TRUE
  ENDIF
 NEXT
 VARS_NUM[WID,VNUM]=-1
 RETURN FALSE
END

DEF VARS_ARRAY_SET WID,VNUM,ARRAY
 VAR("_A_"+HEX$(VARS_NUM[WID,VNUM]))=ARRAY
END

DEF VARS_ARRAY(WID,VNUM)
 RETURN VAR("_A_"+HEX(VARS_NUM[WID,VNUM]))
END

'put this at the end of DEF APP_WINDOW_DESTROY
FOR J=0 TO LEN(_A_USED)-1
 IF _A_USED[J]==I THEN
  VAR("_A_"+HEX$(J))=_A_FREE
  _A_USED[J]=-1
 ENDIF
NEXT
'examples:

'allocating an array (usually inside `IF ON_OPEN(WND) THEN...`)
'uses VARS_NUM[WID,45]
DIM NEW$[10,23]
IF !VARS_ARRAY_ALLOC(WID,45,NEW$) THEN APP_WINDOW_DESTROY WND:RETURN
'(close the window if there weren't any arrays available)

'accessing the array
IF FALSE THEN DIM ARRAY$[0]
ARRAY$=VARS_ARRAY(WID,45)
ARRAY$[0,7]="HELLO"
PRINT ARRAY$[4,5]
Note: IF FALSE THEN DIM... is used to create array variables without actaully creating the arrays (this is faster and uses less memory)

Replying to:12Me21
Here's a system for giving windows access to arrays (Based on OTYAX): Because SB doesn't let you create an array of arrays, the next best thing is to make a bunch of global arrays, and access them with VAR("name") When the window is created, you use VARS_ARRAY_ALLOC to request an array. The array ID number is stored in VARS_NUM, so you can access it later with VARS_ARRAY
'Put this code in __APMN, after DIM VARS_STR$ or something

DIM A_USED[256] 'this keeps track of which window is using each array (-1 = unused)
FILL A_USED,-1
DIM A_FREE[0] 'empty array
IF FALSE THEN DIM _A_0[0],_A_1[0],_A_2[0],_A_3[0],_A_4[0],_A_5[0],_A_6[0],_A_7[0],...,_A_FF[0]
'Code to generate that really long DIM list:
'FOR I=0 TO 255
' S$=S$+"_A_"+HEX$(I)+"[0],"
'NEXT
'CLIPBOARD S$

'Request an array to use.
'WID: window ID
'VNUM: VARS_NUM index to use
'ARRAY: array
'Returns 1 if it succeeded, or 0 if it failed (ran out of arrays)
DEF VARS_ARRAY_ALLOC(WID,VNUM,ARRAY)
 VAR I
 FOR I=0 TO LEN(_A_USED)-1
  IF _A_USED[I]==-1 THEN
   _A_USED[I]=WID
   VARS_NUM[WID,VNUM]=I
   VARS_ARRAY_SET WID,VNUM,ARRAY
   RETURN TRUE
  ENDIF
 NEXT
 VARS_NUM[WID,VNUM]=-1
 RETURN FALSE
END

DEF VARS_ARRAY_SET WID,VNUM,ARRAY
 VAR("_A_"+HEX$(VARS_NUM[WID,VNUM]))=ARRAY
END

DEF VARS_ARRAY(WID,VNUM)
 RETURN VAR("_A_"+HEX(VARS_NUM[WID,VNUM]))
END

'put this at the end of DEF APP_WINDOW_DESTROY
FOR J=0 TO LEN(_A_USED)-1
 IF _A_USED[J]==I THEN
  VAR("_A_"+HEX$(J))=_A_FREE
  _A_USED[J]=-1
 ENDIF
NEXT
'examples:

'allocating an array (usually inside `IF ON_OPEN(WND) THEN...`)
'uses VARS_NUM[WID,45]
DIM NEW$[10,23]
IF !VARS_ARRAY_ALLOC(WID,45,NEW$) THEN APP_WINDOW_DESTROY WND:RETURN
'(close the window if there weren't any arrays available)

'accessing the array
IF FALSE THEN DIM ARRAY$[0]
ARRAY$=VARS_ARRAY(WID,45)
ARRAY$[0,7]="HELLO"
PRINT ARRAY$[4,5]
Note: IF FALSE THEN DIM... is used to create array variables without actaully creating the arrays (this is faster and uses less memory)
Thanks 12. I didn't knew about that VAR() trick to refer to variables. I implemented your code with some changes to avoid messing up with VARS_NUM and I was trying to simplify it, but is fine as it is. And off-topic, I toyed with that clipboard code to make 4095 variables, obviously it won't work, but the editor just slowed down when I pasted all of it. First time I see a slowdown on the editor jeje.

You should consider adding OTYAX API support. I think it would be cool to try out OTYAX programs in this environment.

"If you need an Operating System with the developers in mind, then the ミドリOS is the best option, with a more easier way of developing for its Operating System compared to its competitors; it is the true winner of Operating Systems on Smilebasic.

Replying to:GamerCymreig
"If you need an Operating System with the developers in mind, then the ミドリOS is the best option, with a more easier way of developing for its Operating System compared to its competitors; it is the true winner of Operating Systems on Smilebasic.
I will never forgive you for what you said.