4 ms·

> Oh awesome! This one also has a tiny filesystem and prompt, but no UI for typing machine code in, is that right? Yes, but it offers more to the programs that

by bArray 7y ago

> Oh awesome! This one also has a tiny filesystem and prompt, but no UI for typing machine code in, is that right? Yes, but it offers more to the programs that it loads. There's a trade-off when you go this low on disk space! > But the filesystem supports more than one sector per file? SaxOS supports half the disk, but each file has to be 512 bytes [1]. There are potentially work arounds for this limitation of one sector per file, but it's just hacky. (For example, you could name your files txt0, txt1, ... - or you could leave some header information in your program's file for more data.) I will fix this in a future version though, the plan is to keep loading sectors by the same name in the file table. > Saxos is open-source, unlike BootOS, even if maybe that would be clearer if you used a widely-recognized license. When I wrote this I had no idea about licenses :) I will look to update this, but the project is mostly just archived for now. > I don't think BootOS tries to export its filesystem API to user programs. BootBASIC in particular doesn't seem to have a way to save and load programs. It takes very little to extend the functionality of your kernel to your implementing programs, hopefully BootOS will do this in the future. At some point I want to write a simple self-writing documentation (using the comments structure) so that I can always produce up-to-date documentation for the OS. > Brilliant work! Thanks! I was trying to build a very small low end compression algorithm for it to, but unfortunately I came hard up against entropy. The idea worked (as I envisioned it) but it had the effect of just transforming the dimension the data was stored in and adding unthinkable amounts of computational power and memory being required to get it back. > (Apparently I heard about this before and never looked at it? Because I have a clone of it on my laptop dating from September 14th.) Awesome! My plan for quite a while has been to write a small book and guide people through building their own very simple OS. I think people building their own 512 byte boot-able kernel is a nice intro into OSes whilst also having enough limitations that at some point you can say "this is complete". Anyway, it's what I wish had existed when I first set out may years ago! Speaking of which, I must give a shout out to MikeOS which is where I learned about assembly and OSes [2]. [1] https://bitbucket.org/danielbarry/saxoperatingsystem/src/96c90c3e867f62700580efb240a3af4054cbbdb8/FUNCTIONS.ASM#lines-39 https://bitbucket.org/danielbarry/saxoperatingsystem/src/96c... [2] http://mikeos.sourceforge.net/ http://mikeos.sourceforge.net/

kragen 7y ago
That would be amazing! There's a lot of exciting bootstrapping work going on right now, largely aimed at plugging the Karger–Thompson hole; unfortunately we don't have a viable kernel to compile things on, so while we are close to being safe from Karger–Thompson attacks on GCC, we're still somewhat vulnerable to Linux, and of course Intel. My own interest is largely from other objectives. I strongly encourage you to stick an explicit license on it if you want people to study it! Otherwise there's the risk of a Numerical Recipes or SCO lawsuit nightmare. (While we were writing this thread, Óscar Toledo G. added a BSD license to BootOS!) I wonder—and maybe it's presumptuous to offer suggestions like this without working code, so feel free to ignore it—if it might be more flexible to go the BootOS route of including at least some kind of hex or octal† input in the initial boot monitor, and relegate the filesystem to a loadable device driver in a second sector? It would be less convenient for running apps that want to use the firesystem, since you'd need to run two commands instead of one, but it also means those 512 bytes are sufficient by themselves to bootstrap anything else you wanted. With enough work. …holy shit, you have a scrolling full-screen editor in one sector? This is amazing. † I like octal because (sorry, rdl) the 8086 instruction set is way easier to read in octal. Also octal input takes less code than hexadecimal input, unless there's something I'm not seeing, or you're willing to count 0123456789jklmno.
- bArray 7y ago
  > I strongly encourage you to stick an explicit license on it if you want people to study it! I'm not concerned with lawsuits but allowing people to work with it is a good enough reason to add one. > (While we were writing this thread, Óscar Toledo G. added a BSD license to BootOS!) Very cool :) > t might be more flexible to go the BootOS route of including at least some kind of hex or octal I think that really depends on the goal of the OS, if it's to be self contained then fair enough, but it kind of limits out of the box usability for a normal user. I think most people would bork at having to type any program they want to use into the terminal each time they boot/test the system. > …holy shit, you have a scrolling full-screen editor in one sector? This is amazing. Thanks :) I will at some point improve upon it too, there's definitely some parts that could be better done. > Also octal input takes less code than hexadecimal input In terms of amount of code required, I'm not sure. Maybe there is some way to utilize AAA, AAS, DAA or DAS for converting hex to a value with minimal commands. The documentation appears to be quite crappy for these op-codes though, apparently Intel even managed to confuse themselves (which doesn't bode well for their reliable implementation) [1]. The other problem is that re-packing octal input back into raw bytes (for running) will be non-trival, the reason hex is generally used is because it represents a nibble (4 bits) and you can get away with pairs (i.e. OF 3A B7). Octal on the other hand is gonna be messy, you either have 3 octal characters per byte and lose packing density (even more) or you have cases where an octal character contains information for two neighboring bytes. [1] https://stackoverflow.com/questions/51710279/assembly-instructions-aaa/51713715#51713715 https://stackoverflow.com/questions/51710279/assembly-instru...

by bArray 7y ago

kragen 7y ago

That would be amazing! There's a lot of exciting bootstrapping work going on right now, largely aimed at plugging the Karger–Thompson hole; unfortunately we don't have a viable kernel to compile things on, so while we are close to being safe from Karger–Thompson attacks on GCC, we're still somewhat vulnerable to Linux, and of course Intel. My own interest is largely from other objectives. I strongly encourage you to stick an explicit license on it if you want people to study it! Otherwise there's the risk of a Numerical Recipes or SCO lawsuit nightmare. (While we were writing this thread, Óscar Toledo G. added a BSD license to BootOS!) I wonder—and maybe it's presumptuous to offer suggestions like this without working code, so feel free to ignore it—if it might be more flexible to go the BootOS route of including at least some kind of hex or octal† input in the initial boot monitor, and relegate the filesystem to a loadable device driver in a second sector? It would be less convenient for running apps that want to use the firesystem, since you'd need to run two commands instead of one, but it also means those 512 bytes are sufficient by themselves to bootstrap anything else you wanted. With enough work. …holy shit, you have a scrolling full-screen editor in one sector? This is amazing. † I like octal because (sorry, rdl) the 8086 instruction set is way easier to read in octal. Also octal input takes less code than hexadecimal input, unless there's something I'm not seeing, or you're willing to count 0123456789jklmno.

bArray 7y ago
> I strongly encourage you to stick an explicit license on it if you want people to study it! I'm not concerned with lawsuits but allowing people to work with it is a good enough reason to add one. > (While we were writing this thread, Óscar Toledo G. added a BSD license to BootOS!) Very cool :) > t might be more flexible to go the BootOS route of including at least some kind of hex or octal I think that really depends on the goal of the OS, if it's to be self contained then fair enough, but it kind of limits out of the box usability for a normal user. I think most people would bork at having to type any program they want to use into the terminal each time they boot/test the system. > …holy shit, you have a scrolling full-screen editor in one sector? This is amazing. Thanks :) I will at some point improve upon it too, there's definitely some parts that could be better done. > Also octal input takes less code than hexadecimal input In terms of amount of code required, I'm not sure. Maybe there is some way to utilize AAA, AAS, DAA or DAS for converting hex to a value with minimal commands. The documentation appears to be quite crappy for these op-codes though, apparently Intel even managed to confuse themselves (which doesn't bode well for their reliable implementation) [1]. The other problem is that re-packing octal input back into raw bytes (for running) will be non-trival, the reason hex is generally used is because it represents a nibble (4 bits) and you can get away with pairs (i.e. OF 3A B7). Octal on the other hand is gonna be messy, you either have 3 octal characters per byte and lose packing density (even more) or you have cases where an octal character contains information for two neighboring bytes. [1] https://stackoverflow.com/questions/51710279/assembly-instructions-aaa/51713715#51713715 https://stackoverflow.com/questions/51710279/assembly-instru...