viewing post

viba 361d4h #4290

it appears there has been a recent surge in topics on the apious forum. I shall contribute to this with a topic I have been internally pondering in recent days.

I have been pondering the bootable Caillou OS i have made, and how it's disk access barely works. (well, the whole thing barely works in general, but this is one of the things.) any mouse movement during a disk operation is likely to screw up the mouse and make it not work good. I believe this is (at least partially) because every mouse update sends three packets, with an interrupt being sent for each individual packet. if interrupts are missed, which is likely to happen during disk operations, then there will be confusion as to which packet is supposed to be which. I'm sure there are ways to circumvent this, but I was, and still am, too tired to figure them out. and this issue is just the best case scenario; sometimes disk access just doesnt work at all for some other reason, depending on the system/emulator.

as it stands, all of the image assets are embedded directly into the binary, the entirety of which is loaded into memory at startup. once I had implemented disk access I attempted to put these assets into the filesystem instead. the images would then be loaded and unloaded as needed. however, because of the aforementioned disk access unreliability, this didn't end up working in practice. also since I didn't have the energy to implement directories in the filesystem, these assets would've just cluttered the filesystem anyways.

also, the whole OS had to fit into 492,544 bytes, as this is the amount of contiguous non-reserved memory starting from where the boot sector is loaded. (obviously this is not an absolute hard limit, it's just one caused by my own skill issues.) not like this was a huge challenge though, as the whole thing ended up being half that size anyways. but it does mean that, for instance, an 800x600 PPM image isn't even close to fitting. it's still more than enough to fit a bunch of smaller images such as icons, but you wouldn't be able to, say, have a full desktop background image. obviously PPM isn't going to be very efficient, but I really don't have the brains or energy to implement some compressed image format like PNG, and even if I did, an 800x600 PNG image might still not fit within the limits depending on its entropic entropicality-ness.

I am also hesitant to publish the source code of Caillou OS, as I have already done with Barney OS. this is because the Caillou OS source code is a complete and utter mess beyond any comprehension. I do not want any poor innocent people looking at it and getting the impression that it represents how any sane person should program things. The code is messy and hacky because I just wanted the thing to work, and nothing else. A lot of it is conglomerated into huge single files because I had too much brain fog to separate them into different files. Another reason is that I am interested to see how long it takes for someone to find a secret I have hidden in it. the answer will probably be infinity, since there are probably only going to be like 6 people who ever know about the existence of this weird OS thing.

I have thought about making some sort of means for other people to create things similar to this. maybe some weird contrived programming language, or perhaps a visual interface if I really felt like it. perhaps people would just be annoyed by the arbitrary limitations, namely the 492kb size limit, the lack of audio beyond PC speaker beep boops, the barely functioning disk access, or perhaps some arbitrary restrictions imposed by the language itself... perhaps I'm the only person in the world who cares this substantially about this weird quasi-OS nonsense, so such a utility would have little use. regardless, this just seems like another one of those ideas I have which I will likely never have the energy to do.

I have also thought about what the point to all of this even is. Perhaps it's a marginally fun novelty to see this whole "children show crappy OS" thing realized as an actual bootable OS. but also, perhaps it is simply a much more difficult means of writing a normal computer program. one that makes the program slightly more annoying and inconvenient to run, and have a great chance of having varying issues depending on hardware/emulators. perhaps there is little point to doing this when it is far easier and more worth it in the long run to make these weird fake OS things in LÖVE, as I have already been doing. That being said, it was still quite fun (well, mostly...) to make these bootable things and experiment with low-level programming and x86 stuff, but I'm not sure how much it would be worth it to continue these endeavors much further. but i don't know. maybe it is.

post source:

it appears there has been a recent surge in topics on the apious forum. I shall contribute to this with a topic I have been internally pondering in recent days.

I have been pondering the [bootable Caillou OS i have made](https://friends.citrons.xyz/~viba/os/caillouos/), and how it's disk access barely works. (well, the whole thing barely works in general, but this is one of the things.) any mouse movement during a disk operation is likely to screw up the mouse and make it not work good. I believe this is (at least partially) because every mouse update sends three packets, with an interrupt being sent for each individual packet. if interrupts are missed, which is likely to happen during disk operations, then there will be confusion as to which packet is supposed to be which. I'm sure there are ways to circumvent this, but I was, and still am, too tired to figure them out. and this issue is just the best case scenario; sometimes disk access just doesnt work at all for some other reason, depending on the system/emulator.

as it stands, all of the image assets are embedded directly into the binary, the entirety of which is loaded into memory at startup. once I had implemented disk access I attempted to put these assets into the filesystem instead. the images would then be loaded and unloaded as needed. however, because of the aforementioned disk access unreliability, this didn't end up working in practice. also since I didn't have the energy to implement directories in the filesystem, these assets would've just cluttered the filesystem anyways.

also, the whole OS had to fit into 492,544 bytes, as this is the amount of contiguous non-reserved memory starting from where the boot sector is loaded. (obviously this is not an absolute hard limit, it's just one caused by my own skill issues.) not like this was a huge challenge though, as the whole thing ended up being half that size anyways. but it does mean that, for instance, an 800x600 PPM image isn't even close to fitting. it's still more than enough to fit a bunch of smaller images such as icons, but you wouldn't be able to, say, have a full desktop background image. obviously PPM isn't going to be very efficient, but I really don't have the brains or energy to implement some compressed image format like PNG, and even if I did, an 800x600 PNG image might still not fit within the limits depending on its entropic entropicality-ness.

I am also hesitant to publish the source code of Caillou OS, as I have already done with Barney OS. this is because the Caillou OS source code is a complete and utter mess beyond any comprehension. I do not want any poor innocent people looking at it and getting the impression that it represents how any sane person should program things. The code is messy and hacky because I just wanted the thing to work, and nothing else. A lot of it is conglomerated into huge single files because I had too much brain fog to separate them into different files. Another reason is that I am interested to see how long it takes for someone to find a secret I have hidden in it. the answer will probably be infinity, since there are probably only going to be like 6 people who ever know about the existence of this weird OS thing.

I have thought about making some sort of means for other people to create things similar to this. maybe some weird contrived programming language, or perhaps a visual interface if I *really* felt like it. perhaps people would just be annoyed by the arbitrary limitations, namely the 492kb size limit, the lack of audio beyond PC speaker beep boops, the barely functioning disk access, or perhaps some arbitrary restrictions imposed by the language itself... perhaps I'm the only person in the world who cares this substantially about this weird quasi-OS nonsense, so such a utility would have little use. regardless, this just seems like another one of those ideas I have which I will likely never have the energy to do.

I have also thought about what the point to all of this even is. Perhaps it's a marginally fun novelty to see this whole "children show crappy OS" thing realized as an actual bootable OS. but also, perhaps it is simply a much more difficult means of writing a normal computer program. one that makes the program slightly more annoying and inconvenient to run, and have a great chance of having varying issues depending on hardware/emulators. perhaps there is little point to doing this when it is far easier and more worth it in the long run to make these weird fake OS things in LÖVE, as I have already been doing. That being said, it was still quite fun (well, mostly...) to make these bootable things and experiment with low-level programming and x86 stuff, but I'm not sure how much it would be worth it to continue these endeavors much further. but i don't know. maybe it is.

i am satisfied