VOGONS


First post, by gsos

User metadata
Rank Newbie
Rank
Newbie

Years ago I started a personal project to learn how kernels work at their core. My initial goals and principles were
1) Try to use absolute minimum of ASM
2) Try to make the logic as clear as possible (educational)
3) Work from the philosophy that "programming languages are to CPU/MEM, what Kernel is to the machine/peripherals".

The last point is that a kernel should abstract the details of a machine into an API that allows usage of the machine as it interacts with humans in a portable form, just like programming languages do this for the machine as it computes. 
See my readme https://github.com/gerben-stavenga/RetroOS/bl … 8e505/README.md from 2023.

It became a working prototype kernel over my summer time off, but development stalled like it happens a lot with hobby os's. I had plans to have the kernel run 16,32 and 64 bit code and support old dos games.
Over the last months, I immersed myself in doing agentic coding projects to learn what is possible and I decided to pick up my kernel work. I had AI port it to rust which is what I have been coding in the last couple of years and which is well suited for OS dev. Using LLM allowed me to aggressively refactor and try out some new designs.
I pushed further on the design principles I started from and could really isolate the core of the kernel into a form where it became a rust trait/lib, that could either be implemented by the actual core-arch or by an interpreter. Using this I could build a kernel on top of it utilizing AI to implement syscall API's. I chose to do legacy DOS and Linux. Very quickly I could get some games working which made the project very fun. 

https://www.youtube.com/watch?v=Clh45xUpZNY

I ended up with a project that might be of some interest for the vogons community. It's basically a near fully compatible DOS OS. The kernel can be compiled against arch-metal and be installed on your computer to play natively (or run using qemu/bochs/86box), or it can be compiled against arch-interp (based on unicorn / qemu tcg) and it works like a dosbox app.

It tries to be as retro as possible, so on legacy bios machines with legacy soundblaster you can play the games natively utilizing vga/sound blaster directly. If you have a machine without a sound blaster it can emulate it over ac97 or hda. If you have a modern uefi without legacy bios it can emulate vga as well. Vga emulation and hda emulation is still work in progress and there are rough edges and some bugs, but it's in a state where one can start playing for real.

Previously I posted on vogons and it got removed because it violated rules around AI. I got a message on my youtube from a vogons visitor who expressed interest.,this incentivized me to try to post once more. Obviously I used AI to get my OS to a state where it presents some interesting capabilities. Filling in DOS int 21 syscalls or DPMI API in 30 min is just such a relief, allowing me to focus on design / architecture while seeing results. I know AI is a touchy subject, but I believe this project still to be of interest to this community.

Reply 1 of 3, by gsos

User metadata
Rank Newbie
Rank
Newbie

This hobby project has added quite a bit of features and I think the architecture will be interesting to the OS aficionados on this forum. See

https://www.youtube.com/watch?v=_DG_4CkjV9I

The most interesting thing perhaps is that I was able to isolate the x86 core stuff into arch-metal lib that implements arch-abi trait. The way it's setup is such, that I also implemented the trait by wrapping QEMU TCG engine (unicorn) and also a full kvm variant. The actual kernel (vfs, dos personality, linux personality, threading, ...) is written in almost entirely safe rust calling into a handful of arch functions through the arch-abi trait. This means that the same kernel can be build in three modes,

1) metal. It's a full OS with both legacy bios and modern uefi compatibility. So it can run on old machines with vga compatible graphics and sound blaster and it will expose this. But it can also run on uefi with hda, in which case vga and sound blaster is emulated, so you can still play your retro-games directly on the machine.

2) interpreted. This is basically dosbox mode, the QEMU TCG emulates the userspace programs, while the kernel is compiled as a regular app running native on the host machine. This can be played on any architecture.

3) kvm. This is basically dosemu2 mode. The userspace apps run natively on the cpu under kvm hypervisor, the kernel still runs as a regular app on the host machine. Most of the hosted specific code is shared with interpreted mode. The only differnce is that TCG is replaced with native execution using kvm

All the three modes above run the exact same kernel, with only a different implementation of the arch-abi injected. This actually is quite convenient as one can just run and debug the kernel like any normal app. No need to hook gdb through qemu or that kind of tricks.

So far it allows me to play my favorite games from my youth again on my razer laptop which is very satisfying. You can use it by just copying the kernel into your ext4 /boot directory, setup grub entry and /home/retroos becomes c: . You have access to your linux tools by starting shell.elf in c:\boot , but this is still work in progress (ls/cat/echo work but I'm not close to full linux environment). Of course I recommend qemu and installing it on your computer as in the video above is at your own risk. Anyway the project is complete enough that it might appeal to some retro hobbyist.

Of course I used AI as a "compiler" to compile DOS syscall spec to rust, compile the DPMI spec to rust, linux syscall API to rust. But the design and architecture is mine and you can see that that is still very similar to my code written back in 2023 in this repo. The design of the OS seems to occupy a somewhat new/original spot in the OS design space, sharing features and ideas with many other concepts in kernel design but in a unique way.

It is a monolithic kernel, one elf linked together, but it shares many ideas with microkernels. Arch is a microkernel , but uses just function calls instead of messages. The arch design is more like a hypervisor then the standard osdev tutorial/linux flow, which allows to abstract the core as a library. I haven't seen the trait factorization, ie. providing different ways of running the same kernel, done this way, but it of course strongly reminds one of UM-linux.

What I certainly havent seen before is using recursive paging in a way that unifies 32bit PAE paging and x64 paging, allowing the kernel to seamlessly toggle between 32bit and 64bit mode, which allows vm86 and 64-bit code to execute under one kernel (without the virtualization instruction set).

Specs:
It should run on 386/bios all the way up to x64/uefi without CSM. If you have an old computer with an actual sound blaster, games can use it natively. Otherwise sound blaster/adlib (experimental gus) is supported over hda/ac97 systems. Also when vga is not available, vga is emulated over the regular framebuffer. The video is RetroOS running on a razer (2025) with realtek hda. Old 486/sb I only tested through qemu/bochs/86box emulators.

Reply 2 of 3, by aVd

User metadata
Rank Member
Rank
Member

Hi, @gsos,
This is one very interesting project. Maybe I'm wrong, but at first glance it looks to me like a DOS (compatible) kernel without COMMAND.COM support.

SvarDOS fan :: artificial "intelligence" bots - not a fan at all :: say NO to systemd :: is freeware a lie, when human freedom is a fundamental lie? :: f00ck €u!

Reply 3 of 3, by gsos

User metadata
Rank Newbie
Rank
Newbie
aVd wrote on Today, 07:45:

Hi, @gsos,
This is one very interesting project. Maybe I'm wrong, but at first glance it looks to me like a DOS (compatible) kernel without COMMAND.COM support.

Yes it’s a dos compatible kernel (but also Linux compatible) it has a very basic command.com the forks address space to start programs. I use dos navigator as the tui to the os for the retro feel. It DN invokes “command.com /c program.exe” to start programs which forks internally. Look for command.c in the repo it is compiled by Borland c using retro os itself as part of the build to build command. Com . But command. Com is not a shell currently no