shikaan

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!

The -le suffix is used in south of Germany for the small version of something. So OSle stands for small OS.

I'm not a native speaker, so maybe somebody else can paint a better picture. I used it just because part of my extended family comes from there (:

EDIT: s/prefix/suffix/

Hey all,

As a follow up to my relatively successful series in x86 Assembly of last year[1], I started making an OS that fits in a boot sector. I am purposefully not doing chain loading or multi-stage to see how much I can squeeze out of 510bytes.

It comes with a file system, a shell, and a simple process management. Enough to write non-trivial guest applications, like a text editor and even some games. It's a lot of fun!

It comes with an SDK and you can play around with it in the browser to see what it looks like.

The aim is, as always, to make Assembly less scary and this time around also OS development.

[1] https://news.ycombinator.com/item?id=41571971

As a follow up to my relatively successful series in x86 Assembly of last year[1], I started making an OS that fits in a bootloader.

I am purposefully not doing chain loading or multi-stage to see how much I can squeeze out of 510bytes.

It comes with a file system, a shell, and a simple process management. Enough to write non-trivial guest applications, like a text editor. It's a lot of fun!

Not quite done with it yet, but you can see the progress here https://github.com/shikaan/OSle and even test it out in the browser https://shikaan.github.io/OSle/

[1] https://shikaan.github.io/assembly/x86/guide/2024/09/08/x86-...

If anything, I know people contemplated the opposite (i.e., finding a less hype-driven job)

I think it's anyway not a strong reason to leave or stay, at this point. It's still "yet another technology", and I'd be surprised if it turned out to influence any decision in this regard.

Curious if anybody has non-anectodal data

I'd say Vivaldi[0] scratches that itch better for me, without having to sell my soul to the crypto gods. I only wish it did not crash randomly on MacOS a couple of times per week.

[0] https://vivaldi.com/

This is so cool!

I went through similar struggles when I implemented my js emulator last summer (though, admittedly, FPS was never so low there).

You just made me wanna pick it up again (:

In a long train ride over the weekend I made this little tool to chat with Ollama from VSCode.

I don't like AI assisted code completion as I find it distracting, but I like the convenience of not changing windows to look up the signature of `.reduce`.

It's very basic and honestly quite buggy (take a look at the issues) but I thought I'd share it here. If somebody else finds it interesting I can polish it up.

I built something similar a couple of years back. Glad to see I wasn't alone in my itches

https://github.com/shikaan/shmux

Thanks so much! I am doing something similar to OP in my game engine, but I hand-rolled a font, which is readable but ugly af.

This is going to be such a source of inspiration! Do people have favorites from the list?

I feel this podcast was the first time Rust was sold to me in a way I would buy it, and it was done by the C++ party of this conversation

Hey, thanks for the feedback (:

The second article is still shaping up, but I felt like publishing it to get some early feedback. What you mention are a couple of the reasons.

At this point, I find it too dense (and it was even more so in first drafts) hence missing information. Maybe I should cut some parts, like the rip intro, and accommodate for more details about flags and conditions.

This is good signal for me. Thanks again for taking the time

Thanks for the kind words! Yes, there's more coming. I planned a series of seven articles, the second of which is already out

Thanks for the comment and for taking the time to read :) I fixed it and it flows much better now

You got me thinking and I simplified the whole block. Removed the .bss part and just calling what goes in there "data".

Thanks once again for the feedback :)