Dev/Bugreports for SKKBAUI

サカキバラUI's development was terminated by CyberYoshi64 on 2021/1/24, 15:49 CET. Revival? Yes, but as a rewrite and under a new name: CYMOS The rewrite will ditch ミドリOS compatibility, make existing サカキバラUI assets obsolete (without major modifications) and be based on observations and my improvement ideas for existing mock OSs (Alpha OS X, R-OS V, ミドリOS) and my own previous attempts (Windows6Mix, SKKBAUI, SKKBAOS) Just like Alpha OS X, CYMOS will be compatible with New3DS and WiiU exclusively. CYMOS will not be made for Switch (for now)

Maybe you can implement my worm code somehow.

Maybe you can implement my worm code somehow.

For what purpose...

¯\_(ツ)_/¯ After I've released my space game I'll probably get to work on my "mock computer". Instead of just a mock os it'll be more like a programmable virtual machine which runs a mock os. Maybe I can make it complex enough so that the mock os the mock computer is running can run a mock os. The point of me saying this is I can help develop a file system for your mock os since I should make one for mine so that it can manage files properly on my mock computer's mock hard drive.

¯\_(ツ)_/¯ Oh, nice idea. (Especially a "virtual HDD".) X·J

Maybe you can implement my worm code somehow.

For what purpose...

¯\_(ツ)_/¯ After I've released my space game I'll probably get to work on my "mock computer". Instead of just a mock os it'll be more like a programmable virtual machine which runs a mock os. Maybe I can make it complex enough so that the mock os the mock computer is running can run a mock os. The point of me saying this is I can help develop a file system for your mock os since I should make one for mine so that it can manage files properly on my mock computer's mock hard drive.

That woudn't be a bad idea. The only thing I'd be concerned about would be speed.

That woudn't be a bad idea. The only thing I'd be concerned about would be speed.

Yeah speed could be a bit of an issue if someone tries to code something graphics expensive like a 3d cube or something. For now I plan on coding a basic "integrated gpu" which has very low level control over each pixel. I might even make this a game for beginners to help them understand coding a bit better. I'll elaborate on a seperate thread once I've got the project going. As for the file system thing I mentioned before my project will probably be too low-level to help with Cyber's mock os. I'll work on a file system mini model which can be integrated into the mock os when I get spare time which I seem to get often.

That woudn't be a bad idea. The only thing I'd be concerned about would be speed.

Yeah speed could be a bit of an issue if someone tries to code something graphics expensive like a 3d cube or something. For now I plan on coding a basic "integrated gpu" which has very low level control over each pixel. I might even make this a game for beginners to help them understand coding a bit better. I'll elaborate on a seperate thread once I've got the project going. As for the file system thing I mentioned before my project will probably be too low-level to help with Cyber's mock os. I'll work on a file system mini model which can be integrated into the mock os when I get spare time which I seem to get often.

Your best bet would to allow inline SB code that you can compile and run. This would for sure increase gfx speed.

That woudn't be a bad idea. The only thing I'd be concerned about would be speed.

Yeah speed could be a bit of an issue if someone tries to code something graphics expensive like a 3d cube or something. For now I plan on coding a basic "integrated gpu" which has very low level control over each pixel. I might even make this a game for beginners to help them understand coding a bit better. I'll elaborate on a seperate thread once I've got the project going. As for the file system thing I mentioned before my project will probably be too low-level to help with Cyber's mock os. I'll work on a file system mini model which can be integrated into the mock os when I get spare time which I seem to get often.

Your best bet would to allow inline SB code that you can compile and run. This would for sure increase gfx speed.

or compile a custom language into SB code ('cause real computers don't run SB)

Your best bet would to allow inline SB code that you can compile and run. This would for sure increase gfx speed.

or compile a custom language into SB code ('cause real computers don't run SB)

I was actually going for a basic kind of assembly/number thingy where the user would call machine functions like this:

0x01
0x05
0x02 0x0E
etc.

Once the user or whoever has coded an assembler then they could code in text. I think I'll go make that thread now.

Hey, I'm planning to do a sort of manual.

How?

Similar to the 3DS's "software manual"

How would you like that? EDIT: I already implemented a mouse (it's there but you couldn't click anything except the start button) and a better UI. (Start Menu is broken though. (Originally it wasn't! XD))

... Some sort of Assembly like:

0x01
0x05
0x02 0x0E
etc.

What a good idea but early Assembly is completely binary information:

20 E3 8F 7F AA...

But newer ones (since MS-DOS):

JSR 8FE3
ASL A
LDX
JMP 0000
...

The problem: There are already PUSH and POP but they are functions rather than instructions... Also I already have a huge DEF library with a lot of DEFined instructions and functions... What would happen with that?

Maybe use POOSH and PAWP instead? Or just PSH and I'm not sure what for POP besides coming up with another name. Maybe, if you make a thingy to execute your code you won't need to execute the instructions as sb code. Instead you could decode the instructions to numbers or something which a function selects a DEF function or sb function and runs that. You could also go as far as to make a compiler which converts your code to sb code (which is possible, it's been done) and save your compiled programs as DEFs in a text file(s) which can be loaded in a slot and called when the icon for the program is clicked in your mock os. Btw I keep forgetting to work on the file system, probably because I keep running into some issues where I want to implement file explorer capabilities but I should keep it simple and only add the base file manipulation functions. I should have the thing done within a few weeks.

It's so difficult that you forget it, right? lol

Yep, forgetting stuff makes things hard! Do you want a simple example file explorer with the file system or just the file system? It'll come with documentation anyways.

The current explorer is a bit off. It would be nice if you send the file system with the new explorer. EDIT: If it doesn't look nice i'll make it look better + It helps me figuring out how hard it is.

...

The current explorer doesn't really count as one...

So example file explorer it is. An easy way to impliment that (and every program so those things don't become full time parts of the os) is to load the program being run into a slot and calling its execution function (ie the commonly defined function containing the program's code). The program can be loaded based on a registry value which is part of the os stored in a text file which has its contents loaded on startup. Therefore when a shortcut is used it loads its assigned program into a slot and executes the DEF function (call it main or something so the os doesn't need modification). The program should be made work with the os's main loop so multi tasking is possible. The program can also make calls to the os's built-in library (built-in cause a lack of available slots) for window interface widgets and whatnot. You can paste the code of my mock file system library into your os's main file if you want to save space once I've gotten it ready. Yet another program concept but using the mock file system: the def files loaded can be used as a form of media (disks. Cool, right?) which give the option to run the program or install it onto the available drive (dat file). Since slots are limited only one of each instance from each slot can happen but with the drive you can have more than three instances running at a time. Also I suggest dummy files on the drive for the os for immersion. You'll see how to do this. To make this more like windows (but not too much, the button-based ui is great and should stay, do both?) try making a cursor and use sprites as shortcuts with a registered link to the installed programs. If you need help with that think of the "SPSET" commands. It shouldn't be too difficult. Oh I forgot you'll need a form of assembler to run the installed program code from the drive and a memory management system. I'll work on some concepts for those too.

To make this more like windows (but not too much, the button-based ui is great and should stay, do both?) try making a cursor and use sprites as shortcuts with a registered link to the installed programs. If you need help with that think of the "SPSET" commands. It shouldn't be too difficult.

Well, this version has a mouse fully implemented. I'm working on the Start menu UI where you need to click/hover your way through just like Windows. I'll make desktop shortcuts, too. )

Just a question to you spaceturtles. Is the file system model somehow similar to the file system found in "otya window system". (Tons of files with hexadecimal file names.)

I guess it's similar in some ways. I haven't really gotten a chance to mess around with otya's code. When I'm done you'll be able to store organized program data in a dat file (the drive) and you'll also be able to execute the code with an interpreter of sorts. I'm also considering making a disk system which can "install" other programs onto the drive from a loaded "disk" dat file. Also if you want to you can make all the programs optional features by converting their code to low-level binary code and store them with the file system and add dummy files and folders for the "OS". And "model"? I'm not sure about calling it that anymore since it's more fictional and not an exact replica of an existing file system. Not really important.

Just a question to you spaceturtles. Is the file system model somehow similar to the file system found in "otya window system". (Tons of files with hexadecimal file names.)

I believe otya has implemented an entire virtual drive that uses files for sectors.

I believe otya has implemented an entire virtual drive that uses files for sectors.

Oh that explains why it stores stuff with multiple files (Do you mean partitions btw? Normal drives have a lot of sectors) so the major difference between my mfs and the otya one is that mine stores everything in a single dat file. My original plan was to do something similar by having all the files for the system and any user content stored in the project folder and not as data and with a directory registry file which stores the paths of every file and additional folders but I chose to use a dat file for some reason. I'm a little too far into the current design to care much about using the dreg design but there are other times.

Here's something:

OTYAXWE

You created a file "dummy.txt" and saving it causes "TXT:@00000002" to be saved. Open dummy in TXTED or PRGED and it displayes it's content flawlessly. Open @00000002 in the SB editor will display it's content flawlessly as well. So no encryption of some sort happens.

Word documents...

Word documents are saved with .docx. Rename the extension to .zip and opening it will result the mystery to show. Unlike OTYA docs, MS Word uses XML to define the attributes for every char. OTYA docs use ASCII characters below 20H to define attributes for each char.

"Word" documents are encrypted but if you look closely you can find every character of the document by removing the replacement characters. "README.DOC" has it's own file with the same name though. Folders are saved in a way to store the names for each virtual file and assign them to their respective file in the project.