6 ms·

I have also developed a very small kernel in 512 bytes, it's a fun exercise [1] (this is a really old project that was uploaded to BitBucket long after it initi

by bArray 7y ago

I have also developed a very small kernel in 512 bytes, it's a fun exercise [1] (this is a really old project that was uploaded to BitBucket long after it initially started). I quite like this BootOS project, you can of course see the compromises that any OS this size has to make. I would make a recommendation to the BootOS project which is to squeeze a function table as I have done in order to allow programs to call functions in the kernel. If not, you either end up re-writing these functions for each of your programs, you have to recompile your programs any time you change your kernel or you end up trying to maintain jump positions. For those still reading, I'm working on a large overhaul of saxos which includes very simple multi-tasking (currently working). The intention will be to have the kernel load a 512 byte GUI on top and then for the programs to have access to a terminal within the GUI. Once that's working I then want to move towards also allowing programs to draw to the Window, but that also brings its own issues. [1] https://bitbucket.org/danielbarry/saxoperatingsystem/src/master/KERNEL/KERN.ASM https://bitbucket.org/danielbarry/saxoperatingsystem/src/mas...

nanochess 7y ago
Cool! I didn't knew of your work. I've been working in the service table, just that it isn't ready yet because I want DS to handle filenames and ES the buffer but currently the segment mangling still is destroying the directory. Almost ready ;)
- nanochess 7y ago
  bootOS now has a service table and an example program counter.asm to demonstrate it :)
  - bArray 7y ago
    Awesome! I thought about also using interrupts, how much did it affect timing and code size for you?
    - nanochess 7y ago
      Code size suffered because the need to sanitize the ES register to access the directories (PUSH CS + POP ES) but balanced because I made bootOS to call its own services (3-byte CALL is now 2-byte INT) and fortunately IRET is same size as RET. The most difficult thing was to return the carry flag, but the RCL instruction saved me, I'm glad the 8088 processor auto-uses SS when using BP addressing. At some point I was closer to write in paper the segment dependancies along code paths because it's pretty hard to track. Timing I think isn't so important at this moment.
      - bArray 7y ago
        Haha this is one of the reasons I stuck with the simple jump table :) I will have to check whether I have enough space left to implement interrupts though, hopefully because I already do so many internal calls I will save bytes by reducing from a 3 byte call to a 2 byte interrupt. Thanks for sharing by the way!
kragen 7y ago
Oh awesome! This one also has a tiny filesystem and prompt, but no UI for typing machine code in, is that right? But the filesystem supports more than one sector per file? Saxos is open-source, unlike BootOS, even if maybe that would be clearer if you used a widely-recognized license. 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. Brilliant work! (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.)
- 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/

by bArray 7y ago

nanochess 7y ago

Cool! I didn't knew of your work. I've been working in the service table, just that it isn't ready yet because I want DS to handle filenames and ES the buffer but currently the segment mangling still is destroying the directory. Almost ready ;)

nanochess 7y ago
bootOS now has a service table and an example program counter.asm to demonstrate it :)
- bArray 7y ago
  Awesome! I thought about also using interrupts, how much did it affect timing and code size for you?
  - nanochess 7y ago
    Code size suffered because the need to sanitize the ES register to access the directories (PUSH CS + POP ES) but balanced because I made bootOS to call its own services (3-byte CALL is now 2-byte INT) and fortunately IRET is same size as RET. The most difficult thing was to return the carry flag, but the RCL instruction saved me, I'm glad the 8088 processor auto-uses SS when using BP addressing. At some point I was closer to write in paper the segment dependancies along code paths because it's pretty hard to track. Timing I think isn't so important at this moment.
    - bArray 7y ago
      Haha this is one of the reasons I stuck with the simple jump table :) I will have to check whether I have enough space left to implement interrupts though, hopefully because I already do so many internal calls I will save bytes by reducing from a 3 byte call to a 2 byte interrupt. Thanks for sharing by the way!

kragen 7y ago

Oh awesome! This one also has a tiny filesystem and prompt, but no UI for typing machine code in, is that right? But the filesystem supports more than one sector per file? Saxos is open-source, unlike BootOS, even if maybe that would be clearer if you used a widely-recognized license. 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. Brilliant work! (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.)

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/