3 ms·

I think you're totally right from a practical view. Trying to debug 16-bit x86 code is a nightmare, none of the debuggers properly support it. Leaving practica

by hmry 1y ago

I think you're totally right from a practical view. Trying to debug 16-bit x86 code is a nightmare, none of the debuggers properly support it. Leaving practicality aside and focusing on aesthetics... Normally, for hobby wheel reimplementation projects like this, I find doing it as close to the bare metal as possible, relying on the minimum amount of other people's code, a lot more fun. But AFAIK, these days legacy BIOS boot is just some emulated compatibility mode running under UEFI anyway. The bootloader already ran and configured the hardware for you, and then it un-configured a bunch of stuff so you can re-do it. It's role-playing as an 80s PC for you. I find that deeply unsatisfying. UEFI is the bare-metal API, for all intents and purposes. (Unless you want to go completely blobless, writing your own firmware.)

exDM69 1y ago
> hobby wheel reimplementation projects like this, I find doing it as close to the bare metal as possible, relying on the minimum amount of other people's code, a lot more fun. As a chronic wheel reinventor, I can understand this. But if I felt like scratching this itch now, I would pick some other hardware than x86. The RP2040 could be a nice target, or maybe some ARM or RISC-V SoC. That said, I totally understand that there's something different to having a bare metal / hobby OS project running on your daily driver computer than some embedded gadget. I'm speaking from experience here, I've written bare metal projects in the style of this project (first project I did with MS-DOS debug.com, wrote to a floppy disk and rebooted my machine from the floppy) and the "modern" way with compilers, emulators, debuggers etc. The difference in productivity and learning the interesting stuff is huge.