quasi-OS nonsense ramblings #453

 
viba src #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.

ubq323 (bureaucrat) src #4291

I really don't have the brains or energy to implement some compressed image format like PNG,

maybe you could look at QOI ("Quite OK Image format") (spec)? it's supposed to be quite simple to implement while still providing decent compression. i don't know much about it beyond this though

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, [...]

software that is made in a deliberately odd or confusing or weird way Just Because is always fun and cool, imo

citrons (bureaucrat) src #4292

I enjoy your bootable OS things conceptually, and I hope you make more of them.

viba src #4293

maybe you could look at QOI ("Quite OK Image format") (spec)? it's supposed to be quite simple to implement while still providing decent compression. i don't know much about it beyond this though

aha, I have heard vaguely of QOI from quintopia's site. perhaps I should have looked into it more. it seems like it could be quite good.

quintopia src #4299

I cannot tell what language you are implementing in from the site, but if you are using C or are able to interface with C, you can easily just drop in QOI, QOIG, or RPK codecs as they are Quite Small. If you are planning to use images with only a few colors or large swaths of the same color, I would strongly recommend using RPK over QOI, as it will give Better Compression and Decode Slightly Faster.

viba src #4300

it is indeed written in C.

good thing I happened to have already implemented a rudimentary memory allocator which I never ended up actually using.

quintopia src #4303

if you decide to go this route, i can modify the decoder so that it can accept a 2D color array as argument and write the correct colors to it instead of writing out a PNG file. it wouldn't take more than an hour to do that i reckon.

please log in to reply to this thread