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.
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
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.
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)
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.
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.
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])
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 (:
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.
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!
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.
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.