shikaan

Great read (: This is precisely how I learn, even though these days it all feels a little futile.

The other part for me is working within tight constraints. A couple of years back I made an Operating System that fits a bootloader (I was low-key hoping to find in the list :P) Not really golfing but surely a good exercise in playing within constraints.

If anybody wants to take a look https://github.com/shikaan/osle

A native application (Windows, Linux, MacOS) for music transcription.

It comes with time stretch and pitch shift as most of these softwares do, but it allows you to save loop regions and take notes. It's designed to be a practice session tool.

I'm doing it from first principles, and having fun writing GPU code, platform shims, and squeeze every ms I can to make it fast and smooth.

I will be looking for testers soon. If anybody is interested, hit me up.

Is this how we bring "works on my machine" in production? /s

Kinda OT: can anybody recognize the keyboard in the German keyboard shot? I have been looking for a similar ISO keyboard (with international layout) for a while

I have played with that idea for a while until I realized I was creating a poor man's web browser in the terminal.

At that point I started wondering if converting my man folder to HTML and using lynx[1] wasn't a better idea.

I ended up using vanilla man again.

Are there better/fancier manpage readers out there that can change my mind?

[1]: https://lynx.invisible-island.net/current/

Such a great read! Reminds me of the bootsector OS I made some time ago[^1]

Maybe it's time to equip it with a C compiler...

[1]: https://github.com/shikaan/osle

Shameless plug. I built a tool[1] to manage Keepass archives in the terminal which might scratch some of the itches I am reading here: it has a TUI, but can be piped into other commands too.

[1]: https://github.com/shikaan/keydex

Exactly this.

I have been planning on trying to glue up something with v86[1] as I did in OSle[2] but I did not get to it yet.

In that case, everything would run locally and sandboxes, so you would not have to care.

[1]: https://github.com/copy/v86

[2]: https://github.com/shikaan/osle

Something similar, but you can play with the examples in the browser without any local setup https://shikaan.github.io/assembly/x86/guide/2024/09/08/x86-...

For full disclosure, I am the author - apologies for the shameless plug

Honestly, I made it up :)

I thought about what would be the minimum I have to build in order to run some userland software that does "something". That to me looked like: spawn guest applications, make them persist something.

With slightly more leeway, I would probably do memory management as the next thing (besides what I mentioned in another thread here)

Oh boy, this is amazing! Thanks for the reference

Hey, thanks for your interest in this project!

3. The tty interrupt advances the cursor along with printing. So, once again, I do it to save on some instructions. In the first iterations I wanted to retain more control (by printing and moving as separate operations) so that I could reuse this across the board, but eventually I ran out of space.

4. I am relying heavily on BIOS interrupts, which are criminally underdocumented. The most reliable source is Ralph Brown's documentation[1] which is very far from what I was expecting to be authoritative documentation. Turns out this collection is really good and basically _the_ source of truth for BIOS interrupts.

To answer your question, yes, this is basically calling the BIOS API.

[1]: https://wiki.osdev.org/Ralf_Brown's_Interrupt_List

I would have assumed the same, but I haven't managed. On the other hand, I did not tinker too much with all these toggles; it's such a little amount of shared code (which is also partially different in some cases) that didn't particularly make sense to me.

If you know how to make it happen and/or want to contribute, hit me up (:

1. If you look through the commit history, you'll see that the first implementation was actually with Pascal strings.

Printing with Pascal strings is actually shorter (you skip the null test, basically), but constructing Pascal strings to pass as an argument when they are not constants yielded much more code to prepare for that call. Had I had more leeway, I would have used Pascal strings, it much less headache.

2. Files in `/bin` all include from the SDK. You can pretty much do the same for utility functions.

The includes, at least in nasm, are very much like copy-pasted code (or includes in C for that matter), and then you can just jump/call to the label.

I did not do it because I haven't been able to get nasm to optimize away the code that I don't use, and I didn't want to bloat the binaries or make a file for a 5LOC function.

All in all not good reasons in general, but it made sense to me in this context.

Indeed. Thanks for the correction; I edited the original message

Hey, thanks for taking a look!

On the former, I have no idea how to estimate BIOS functions size. Maybe I could just peek into an image and get a sense for it...

On the latter, with a 16x increase in available space, I guess I would do a much more thorough work in putting guardrails in place.

The API currently comes with a couple of traps (e.g., file names can be duplicated, processes are cooperative, all file operations perform disk I/O...) and it essentially requires guest applications to know about BIOS services in order to function.

Another sticky point I wish I had the space to address better are calling conventions, which I had to get rid of almost immediately to save on instructions.

> Thanks for pointing me towards the bosh emulator.

You're welcome! Bochs is such a nice tool which I discovered only for this project as well. It was a no-brainer, since I got no way to debug 16-bit assembly from QEMU (unless you go off and fork it[1])

[1]: https://gist.github.com/Theldus/4e1efc07ec13fb84fa10c2f3d054...

I went back and forth about the file system and disk stuff a fair bunch, to be honest. Most of it, as you say, was mostly due to wrestling the space constraints.

If one day I'll give in and take the shell out or go multi-stage, I will definitely look at that.

Maybe it's worth blogging about the journey; it's been a few weeks of merciless trade-offs to reach a usable API. It can make for a fun read (:

Thanks for taking a look!