Thanks, so glad people like the code! I keep looking for ways to make it simpler and more obvious.
> - noticed krn_main() ends with `while (1);` [1]. I would've expected a "schedule" call or something. I assume there's no real busy loop burning CPU, maybe it's never meant to reach this code?
Yeah, `gui_main()` takes over and is not supposed to return, so the code is unreachable. The loop is just an old idiom used in such places (e.g. [1]), though I've now replaced it with a comment and a call to `halt()` to better convey the intention.
> - I'm reminded of the "bare metal OS" when I see one of the apps call `krn_*` functions directly [2].
Yeah... but at least the kernel doesn't call the apps... which it could ;^)
All the photos are real, though it took me *lots* of time to get them somewhat right. The display on T1800 is indeed "challenging". What helped was:
- Letting it warm for a while
- Putting windows in the right places, because each one generates its own artifacts
- Setting background to dark with the white pattern
- Fiddling with the contrast knob and matching it with the right viewing angle
- Using 2x zoom
To be fair, the default photo app of iPhone 16 automatically reduced some of the artifacts. The only post-processing done myself in GIMP was very basic stuff like adjusting white balance, exposure and contrast.
Even on 2MB, you should be able to at least see GRUB, which would tell you that it can't load the kernel. Does it go blank before that? This could mean an issue with either GRUB or the floppy.
In case you have DOS installed on the hard drive, you can also use GRUB4DOS [1] - just put gentleos.elf on C:\, run grub.exe, then `kernel /gentleos.elf`. You may first need to comment out any upper memory managers from config.sys. A bit of an academic exercise since the kernel still won't fit into memory.
Btw. feel free to reach out to me on my profile email. I'll be busy with work for the rest of the week, but later I may look for some workarounds to get it running on 2 megs.
You’re welcome. You’d probably appreciate its focus on long-term stability; the authors wanted an environment for their software that would ensure code could stay frozen in a working state forever. The only thing that may need updates is the VM, as the host OS and userland will shift over time, but the VM is designed to be exceptionally easy to implement and maintain. That comes at the cost of some capabilities, but they were specifically aiming for simpler software, so it works out.
In this context, 32-bit means the minimal requirement. You can absolutely run even the 16-bit version on a 64-bit PC, provided it has BIOS/legacy-boot mode.
It only won't work on modern pure-UEFI systems because that would require writing full stack of USB drivers for keyboard and mouse, and that would be a huge task.
Good catch, the yellow and blue colors are totally inspired by BeOS :D I'm even adjusting the default VGA palette to get the right tints in 16-color mode.
For PS/1 you'll need the 16-bit version from https://github.com/luke8086/gentleos. A floppy image is provided in releases. Note you only need to copy the first 64KB, the rest is just padding for emulators.
The data bus was only 16 bits wide, but that doesn't really have much impact on OS compatibility; it just means that transferring a 32-bit value to or from memory takes two bus clock cycles instead of one. The address bus is only 24 bits wide, but that only affects physical memory address space; it still uses 32-bit pointers and a 32-bit virtual address space.
Bootloader developers used to be particularly fond of Forth.
For example, for many years the FreeBSD's 3rd-stage loader used FICL (Forth Inspired Command Language) for scripting [1]. It's still supported, although in the recent years it was deprecated in favor of Lua [2].
This was also my first thought, but looks like it's already designed to be toolkit-agnostic, like NetSurf. So it should be easy to port to fltk or anything else.
$ ls -1 fixgui_\*.c
fixgui_cocoa.c
fixgui_gtk.c
fixgui_haiku.c
fixgui_win32.c
> - noticed krn_main() ends with `while (1);` [1]. I would've expected a "schedule" call or something. I assume there's no real busy loop burning CPU, maybe it's never meant to reach this code?
Yeah, `gui_main()` takes over and is not supposed to return, so the code is unreachable. The loop is just an old idiom used in such places (e.g. [1]), though I've now replaced it with a comment and a call to `halt()` to better convey the intention.
> - I'm reminded of the "bare metal OS" when I see one of the apps call `krn_*` functions directly [2].
Yeah... but at least the kernel doesn't call the apps... which it could ;^)
[1] https://github.com/freebsd/freebsd-src/blob/main/sys/x86/x86...
reply