Slight tangent but I've wondered about something similar to this, has there been much initiative to make games that directly boot on modern PC hardware? So not load a full OS but just go directly to the game. Similar to older generation gaming consoles. It should be possible, granted if you want to stay simple, things like wifi, bt, GPU would be hard to utilize without modern drivers, but a keyboard and mouse should be fairly doable as they seem to have some sort of default BIOS access? (probably wrong terms there but hopefully my point is understandable)
Hi, congratulations! You must be feeling proud. Nice choice of proof of concept (DOOM).
Sorry to disappoint you but all I have are some noob questions.
What would be the steps to run this on a laptop? I take it that after building it there would be a process similar to, say, setting up dual-boot in a Windows PC? (Whoa I'm asking a stranger on the Internet how to run dangerous software on my computer...)
If one wanted to undertake such a project, do you have any recommendations of textbooks or other reading material? I had some OS & related courses in university (I'm EE, so computer-adjacent), but they were all very abstract / high level / conceptually-focused. I'd love something more concrete. It doesn't have to be x64.
Not disappointed at all to answer! Running it on my laptop was literally just formatting a USB with the ISO and booting from the USB.
I would recommend checking out https://osdev.wiki to start out if you want to write a kernel, as well as reading relevant specifications (such as Intel Developer Manual and the specs for any drivers you write). I don't really know much about non-x86 kernel dev but most of the concepts are the same as far as I know, just different technical implementations. There's a link to a discord server on the project's readme, there are some very smart people in there who I'm sure would be more than happy to help you out.
I wrote a kernel as well (not complete yet), and I documented all the steps I'm taking. A lot of people found it useful: https://0xc0ffee.netlify.app/osdev
Hey unmapped (I am ThatOSDeveloper on GitHub and discord it's my display name) I never knew you got doom running on it, pretty cool, but I have a few questions, is it the original doom, is it on disk or an initramfs and do you use freedom or the shareware doom wad with the engine you use?
I kid I kid ;) That's a commendable effort and nice job! Question though: was it an effort to make TacOS using DOOM as a "standard" or was it an effort to make an OS dedicated to running DOOM run from scratch?
And I don't ask from any place but actual curiosity. I made an absolute bare-bones-cant-do-anything-but-boot type OS way back "in the day" (like almost 30 years ago, ack!!!) just for my own education/fun, but the idea of having a dedicated OS that can basically only run DOOM, yet be ported to anything would just make the "can it run DOOM" meme so much more ironic and fun!
Well, it can do a little more than run Doom, that's just the latest milestone as to what was ported last. It wasn't a huge effort, maybe took a week or so to get Doom itself running including adding libc requirements for Doom, but what came before that was a fair bit more groundwork. I used DoomGeneric, which is basically a fork of Doom which is made to be very portable. I hope I answered your question, I might have misunderstood.
Great work, I would love to have the skills to do something like this, but I can see you had to read lots of specifications to achieve this and thats my weakest point.
One silly question you may know: Imagine you wanted to use GPU acceleration, even in the smallest form. How hard would it be to build a driver for the GPU? Do you think there is good documentation about it?
Umm that's probably the extreme end of OSDev which I likely wouldn't be able to do, at least not for a driver you can buy. Qemu's emulated GPU is documented decently and could be possible, but things like nvidia GPUs are badly documented (and until recently, the docs were fully closed source) - even Linux has issues with this (and I actually see a few other hobby OS devs who just use Linux's GPU drivers in the end). There aren't a lot of things I've marked as near impossible but writing a genuinely decent GPU driver for a common GPU isn't really something I imagine I'll ever be able to do sadly.
The docs for intel’s integrated offerings seem pretty good, I’m planning to do a driver for those on my toy OS. Anything else is hit and miss in terms of availability of information unfortunately.
I use paging for virtual memory, which gives each process it's own address space. I have a round-robin scheduler connected to the PIT driver, so every 10ms the PIT fires an interrupt which triggers the scheduler, which selects the next task, saves the current state of the previous task, switches to the new address space, switches the stack, restores registers of the task, then uses the iretq instruction to switch to ring 3 user mode and jump to the instruction pointer.
Thanks for that explanation. I've been doing some low-level programming lately, and I'm getting interested on running stuff bare-metal. Every previous description of multitasking I've seen has been very hand-wavy.
Yeah no problem. Multitasking isn't really complex - it's generally split into two categories: collaborative and preemptive. Collaborative multitasking is simply having user programs call a yield syscall which tells the kernel that it's ready to give up control of the CPU and it switches to the next task, but this is not very secure and is uncommon on newer systems. Alternately, preemptive scheduling generally has a timer which goes off regularly which automatically switches to the next task. Choosing the next task is the next part which the simplest one is round robin, where you literally just have a list of tasks and it always selects the next task and gives each task an equal amount of time. You also have SMP versions (that work for multiple cores) and also priority-based schedulers (which give certain tasks, such as system daemons, more processing time). Hopefully that extra info helped a bit!
Not so much about security but stability. If a program enters an infinite loop then it never yields and the entire system is hung. Hopefully you have an interrupt you can fire off (like ctl-alt-del) that can wake up the kernel and allow you to take action.
In the fine tradition of Nachos and Pintos! (Still waiting on Burritos - which would obviously have to be based on functional programming principles - and Churros.)
I'd just like to interject for a moment. What you're refering to as Burritos, is in fact, GNU/Burritos, or as I've recently taken to calling it, GNU plus Burritos. Burritos is not an operating system unto itself, but rather another free component of a fully functioning GNU system made useful by the GNU corelibs, shell utilities and vital system components comprising a full OS as defined by POSIX.
Dude, I'm impressed cause I don't the energy to build my own OS kernel!
But here's a wacky idea. Just set it up so that the OS only runs DOOM as default. Boots directly into Qemu and runs DOOM, nothing to select or change. Maybe something you could fold other games into so that they can run off a USB boot loader. Might be appealing to people who don't want to install or compromise their base setup.
I could probably do that. The init program, which is a userspace program called by the kernel which spawns everything else, currently enters the shell but it'd be quite simple to make it just boot into Doom immediately. It's still not quite stable enough for actual usage, but it is able to boot off a USB at the moment, yes.
That __is__ true, Doom can run on bare metal, but that's a fairly hacky solution in many ways. Doing it properly in userspace with a LibC and conceptually POSIX syscalls require a bit more effort. It requires a list of LibC functions and POSIX utilities as well as a few OS specific implementations.
Doom is a fine milestone for an OS that intends to have graphical capabilities. Maybe Doom in text mode for other OSes :P
It's a known quantity, and doom has been ported to everything, so it shouldn't be too hard to make work either (he says, not having done it).
An OS that can run Doom is clearly capable of graphical interfaces with user interactivity, and maybe sound (although sound would be easy to leave out).
Yeah, that's perfectly fair. I raised my question because it occurred to me this kind of sells the operating system short. In other words: even DOS could run Doom (with some help with a memory extender I guess, which is a technology we can all very happily not worry about anymore).
Yeah definitely an achievement I'm happy with. I've got a bit of refactoring to do, ANSI parsing etc then I'd like to port more - perhaps even Vim (or another portable Vim-like editor called Dim)
Could you explain more about why you'd need to port things? If you have a libc, shouldn't it "just work"? Do you have to scatter #define or #ifdef all over? What about if you wanted to support Golang? Would you have to implement a bunch of syscall?
Well, the LibC is still quite small, and the syscalls aren't really compatible with Linux. A lot of things to port, for example Vim, require system libraries such as ncurses which need syscalls that aren't in the LibC. I don't really need many #ifdefs, at least not for most things, as it's a more or less posix-based libc.
I searched YouTube for actual evidence of Hurd booting to a desktop and only found two videos of Hurd freezing during boot, and a third video of RMS explaining to a very confused convention attendee that he's "never installed GNU slash lynn-ox" because he could just ask someone else to do it.
No videos of Hurd running Doom either, but anyone is welcome to create one and share.
The programming interface that Hurd provide is similar to that of any modern operating system. So, it can run pretty much any program that runs on Linux or BSD, but you have to port it. Doom is no exception. If you cannot find a video of Doom running on Hurd on YouTube, it doesn't mean that Hurd can't run Doom.
Hurd is sure not a successful project, but it is a capable operating system. Linux comes with a lot of device drivers for all sorts of hardware, so Linux nowadays can run almost everywhere. But that is not the case with Hurd because only a small number of people are contributing to this project and it is largely eclipsed by success of Linux. But it is an extensible system so if you want support for a hardware, you can develop a driver for it. But nobody is interested.
If you haven't seen Hurd running a desktop, I will introduce you to Debian Hurd (https://www.reddit.com/r/linuxmasterrace/comments/18i6e94/de...). It is a Debian distribution with Hurd as the kernel instead of Linux. It comes with Xorg and you can install XFCE, OpenBox. Basically, you can install any desktop that render on CPU. Desktops like GNOME and KDE need more infrastructure. They relay on modern GPUs and uses direct rendering. In Linux, we have DRI and Mesa for this. As of now, Hurd doesn't have any such infrastructure. As I have already said before, a lot of people are contributing to Linux and only a handful of people are contributing to Hurd.
The current Debian/Hurd port of nginx is outdated, but runs fine.
There's been a few problems with nodejs, as libfuse compatibility isn't the latest yet. Some libraries work fine. Some explode. So you'll have to compile it yourself.
Python and Go, however, should run out of the box just fine.
Its been a few years but I ran HURD in a VM and it ran a nice X Windowing system. Its been a few years though so I don't know what HURD is capable of today
Hurd is for sure a failed project and it can't realistically run a modern desktop as claimed, but it's more capable than you give it credit for. For example, see:
Haha not quite at the point Hurd has gotten. I'd be very happy if I could last that long on one project though, I have a tendency to get bored after a few months sadly.
Slight tangent but I've wondered about something similar to this, has there been much initiative to make games that directly boot on modern PC hardware? So not load a full OS but just go directly to the game. Similar to older generation gaming consoles. It should be possible, granted if you want to stay simple, things like wifi, bt, GPU would be hard to utilize without modern drivers, but a keyboard and mouse should be fairly doable as they seem to have some sort of default BIOS access? (probably wrong terms there but hopefully my point is understandable)
Hi, congratulations! You must be feeling proud. Nice choice of proof of concept (DOOM).
Sorry to disappoint you but all I have are some noob questions.
What would be the steps to run this on a laptop? I take it that after building it there would be a process similar to, say, setting up dual-boot in a Windows PC? (Whoa I'm asking a stranger on the Internet how to run dangerous software on my computer...)
If one wanted to undertake such a project, do you have any recommendations of textbooks or other reading material? I had some OS & related courses in university (I'm EE, so computer-adjacent), but they were all very abstract / high level / conceptually-focused. I'd love something more concrete. It doesn't have to be x64.
Not disappointed at all to answer! Running it on my laptop was literally just formatting a USB with the ISO and booting from the USB.
I would recommend checking out https://osdev.wiki to start out if you want to write a kernel, as well as reading relevant specifications (such as Intel Developer Manual and the specs for any drivers you write). I don't really know much about non-x86 kernel dev but most of the concepts are the same as far as I know, just different technical implementations. There's a link to a discord server on the project's readme, there are some very smart people in there who I'm sure would be more than happy to help you out.
I wrote a kernel as well (not complete yet), and I documented all the steps I'm taking. A lot of people found it useful: https://0xc0ffee.netlify.app/osdev
Hey unmapped (I am ThatOSDeveloper on GitHub and discord it's my display name) I never knew you got doom running on it, pretty cool, but I have a few questions, is it the original doom, is it on disk or an initramfs and do you use freedom or the shareware doom wad with the engine you use?
It's doomgeneric, as can be seen in the article, with a fairly small amount of modifications, as can be seen at the top of this page.
Ok, but can your tacos run DOOM??
I kid I kid ;) That's a commendable effort and nice job! Question though: was it an effort to make TacOS using DOOM as a "standard" or was it an effort to make an OS dedicated to running DOOM run from scratch?
And I don't ask from any place but actual curiosity. I made an absolute bare-bones-cant-do-anything-but-boot type OS way back "in the day" (like almost 30 years ago, ack!!!) just for my own education/fun, but the idea of having a dedicated OS that can basically only run DOOM, yet be ported to anything would just make the "can it run DOOM" meme so much more ironic and fun!
Nice stuff! Keep it up!!
Well, it can do a little more than run Doom, that's just the latest milestone as to what was ported last. It wasn't a huge effort, maybe took a week or so to get Doom itself running including adding libc requirements for Doom, but what came before that was a fair bit more groundwork. I used DoomGeneric, which is basically a fork of Doom which is made to be very portable. I hope I answered your question, I might have misunderstood.
Great work, I would love to have the skills to do something like this, but I can see you had to read lots of specifications to achieve this and thats my weakest point.
One silly question you may know: Imagine you wanted to use GPU acceleration, even in the smallest form. How hard would it be to build a driver for the GPU? Do you think there is good documentation about it?
Umm that's probably the extreme end of OSDev which I likely wouldn't be able to do, at least not for a driver you can buy. Qemu's emulated GPU is documented decently and could be possible, but things like nvidia GPUs are badly documented (and until recently, the docs were fully closed source) - even Linux has issues with this (and I actually see a few other hobby OS devs who just use Linux's GPU drivers in the end). There aren't a lot of things I've marked as near impossible but writing a genuinely decent GPU driver for a common GPU isn't really something I imagine I'll ever be able to do sadly.
The docs for intel’s integrated offerings seem pretty good, I’m planning to do a driver for those on my toy OS. Anything else is hit and miss in terms of availability of information unfortunately.
thanks for your response. Thats what I heard but I was wishing things to change...
I was also thinking about integrated GPUs like the one in a RPi or other SoCs
Really curious to learn more about TacOS. How does it manage running multiple programs safely at the same time?
Read up on OS design: https://pages.cs.wisc.edu/~remzi/OSTEP/
Read the intro : https://pages.cs.wisc.edu/~remzi/OSTEP/dialogue-virtualizati...
https://wiki.osdev.org/ has platform details and other resources.
Welcome to the club! Did almost the same and really enjoyed the serenity of doing something which never will end up in a product
https://jakobbr.eu/2024/08/19/writing-my-own-x86_64-operatin...
Very nice!i
> I have a Discord server for PotatOS where
what is potatOS in this context?
Very cool project! How are you handling process isolation and scheduling in TacOS?
I use paging for virtual memory, which gives each process it's own address space. I have a round-robin scheduler connected to the PIT driver, so every 10ms the PIT fires an interrupt which triggers the scheduler, which selects the next task, saves the current state of the previous task, switches to the new address space, switches the stack, restores registers of the task, then uses the iretq instruction to switch to ring 3 user mode and jump to the instruction pointer.
Thanks for that explanation. I've been doing some low-level programming lately, and I'm getting interested on running stuff bare-metal. Every previous description of multitasking I've seen has been very hand-wavy.
Yeah no problem. Multitasking isn't really complex - it's generally split into two categories: collaborative and preemptive. Collaborative multitasking is simply having user programs call a yield syscall which tells the kernel that it's ready to give up control of the CPU and it switches to the next task, but this is not very secure and is uncommon on newer systems. Alternately, preemptive scheduling generally has a timer which goes off regularly which automatically switches to the next task. Choosing the next task is the next part which the simplest one is round robin, where you literally just have a list of tasks and it always selects the next task and gives each task an equal amount of time. You also have SMP versions (that work for multiple cores) and also priority-based schedulers (which give certain tasks, such as system daemons, more processing time). Hopefully that extra info helped a bit!
> but this is not very secure
Not so much about security but stability. If a program enters an infinite loop then it never yields and the entire system is hung. Hopefully you have an interrupt you can fire off (like ctl-alt-del) that can wake up the kernel and allow you to take action.
What did you do make the project interactive enough so you don’t end up copying existing implementations?
Great project. Mmap implementation is a cheat :).
Cool! Does OS kernel related to CPU model? Can I boot this kernel in KVM?
Yep! Works with KVM fine (at least for me).
From-scratch kernel straight to DOOM is some top-tier hacker cred stuff. You must be very happy with it running on real hardware. Very cool.
Yes, quite happy with real hardware. The kernel isn't exactly straight to Doom, it boots into a shell which you can just run Doom from, but yeah lol.
THIS IS AWESOME Love the project too!
Wow congrats, this is very impressive.
Really really love the name.
In the fine tradition of Nachos and Pintos! (Still waiting on Burritos - which would obviously have to be based on functional programming principles - and Churros.)
Burritos are just monoids in the category of endotacos.
I'd just like to interject for a moment. What you're refering to as Burritos, is in fact, GNU/Burritos, or as I've recently taken to calling it, GNU plus Burritos. Burritos is not an operating system unto itself, but rather another free component of a fully functioning GNU system made useful by the GNU corelibs, shell utilities and vital system components comprising a full OS as defined by POSIX.
welp I think I found my favorite comment ever.
Dude, I'm impressed cause I don't the energy to build my own OS kernel!
But here's a wacky idea. Just set it up so that the OS only runs DOOM as default. Boots directly into Qemu and runs DOOM, nothing to select or change. Maybe something you could fold other games into so that they can run off a USB boot loader. Might be appealing to people who don't want to install or compromise their base setup.
I could probably do that. The init program, which is a userspace program called by the kernel which spawns everything else, currently enters the shell but it'd be quite simple to make it just boot into Doom immediately. It's still not quite stable enough for actual usage, but it is able to boot off a USB at the moment, yes.
Why is running doom one of your milestones, given that doom will run fine on bare metal?
That __is__ true, Doom can run on bare metal, but that's a fairly hacky solution in many ways. Doing it properly in userspace with a LibC and conceptually POSIX syscalls require a bit more effort. It requires a list of LibC functions and POSIX utilities as well as a few OS specific implementations.
Very impressive work regardless. Keep it up :)
Doom is a fine milestone for an OS that intends to have graphical capabilities. Maybe Doom in text mode for other OSes :P
It's a known quantity, and doom has been ported to everything, so it shouldn't be too hard to make work either (he says, not having done it).
An OS that can run Doom is clearly capable of graphical interfaces with user interactivity, and maybe sound (although sound would be easy to leave out).
Yeah, that's perfectly fair. I raised my question because it occurred to me this kind of sells the operating system short. In other words: even DOS could run Doom (with some help with a memory extender I guess, which is a technology we can all very happily not worry about anymore).
what a classic - great job!
Nice work!!!
Dude, getting Doom to run on your own kernel is epic - I gotta try building some wild stuff like this someday
Yeah definitely an achievement I'm happy with. I've got a bit of refactoring to do, ANSI parsing etc then I'd like to port more - perhaps even Vim (or another portable Vim-like editor called Dim)
Could you explain more about why you'd need to port things? If you have a libc, shouldn't it "just work"? Do you have to scatter #define or #ifdef all over? What about if you wanted to support Golang? Would you have to implement a bunch of syscall?
Well, the LibC is still quite small, and the syscalls aren't really compatible with Linux. A lot of things to port, for example Vim, require system libraries such as ncurses which need syscalls that aren't in the LibC. I don't really need many #ifdefs, at least not for most things, as it's a more or less posix-based libc.
A few months work by one guy and already more capable than the Hurd.
Imagine what you could accomplish given 35 years.
> A few months work by one guy and already more capable than the Hurd
It is no way capable than Hurd. It is a cool project though. Have you used Hurd recently? It can run a modern desktop.
I searched YouTube for actual evidence of Hurd booting to a desktop and only found two videos of Hurd freezing during boot, and a third video of RMS explaining to a very confused convention attendee that he's "never installed GNU slash lynn-ox" because he could just ask someone else to do it.
No videos of Hurd running Doom either, but anyone is welcome to create one and share.
The programming interface that Hurd provide is similar to that of any modern operating system. So, it can run pretty much any program that runs on Linux or BSD, but you have to port it. Doom is no exception. If you cannot find a video of Doom running on Hurd on YouTube, it doesn't mean that Hurd can't run Doom.
Hurd is sure not a successful project, but it is a capable operating system. Linux comes with a lot of device drivers for all sorts of hardware, so Linux nowadays can run almost everywhere. But that is not the case with Hurd because only a small number of people are contributing to this project and it is largely eclipsed by success of Linux. But it is an extensible system so if you want support for a hardware, you can develop a driver for it. But nobody is interested.
If you haven't seen Hurd running a desktop, I will introduce you to Debian Hurd (https://www.reddit.com/r/linuxmasterrace/comments/18i6e94/de...). It is a Debian distribution with Hurd as the kernel instead of Linux. It comes with Xorg and you can install XFCE, OpenBox. Basically, you can install any desktop that render on CPU. Desktops like GNOME and KDE need more infrastructure. They relay on modern GPUs and uses direct rendering. In Linux, we have DRI and Mesa for this. As of now, Hurd doesn't have any such infrastructure. As I have already said before, a lot of people are contributing to Linux and only a handful of people are contributing to Hurd.
If it can run nginx and node.js on a VPS it could be a nice alternative to Linux.
The current Debian/Hurd port of nginx is outdated, but runs fine.
There's been a few problems with nodejs, as libfuse compatibility isn't the latest yet. Some libraries work fine. Some explode. So you'll have to compile it yourself.
Python and Go, however, should run out of the box just fine.
Its been a few years but I ran HURD in a VM and it ran a nice X Windowing system. Its been a few years though so I don't know what HURD is capable of today
Youtube isn't an evidence of anything.
Set up yourself.
Hurd is for sure a failed project and it can't realistically run a modern desktop as claimed, but it's more capable than you give it credit for. For example, see:
https://www.debian.org/ports/hurd/
Hurd isn't exactly a useful project, but using Doom as the benchmark for the capability of an OS is a bit ridiculous.
Given that pregnancy tests can now run Doom, I have to agree with you. It was more of a symbolic thing than a technical difficulty at this point lol.
They can't, actually.
https://www.popularmechanics.com/science/a33957256/this-prog...
It runs on the screen of a pregnancy test, Doom is actually executed on an Arm Cortex M0+ based Adafruit Trinket.
You’re right. In fact it’s not even the screen - they replaced that too.
Why?
Haha not quite at the point Hurd has gotten. I'd be very happy if I could last that long on one project though, I have a tendency to get bored after a few months sadly.
> Haha not quite at the point Hurd has gotten
that's true, you've only shipped to one computer, while they've shipped to dozens!
This is so cool