[HN Gopher] Show HN: My from-scratch OS kernel that runs DOOM
___________________________________________________________________
Show HN: My from-scratch OS kernel that runs DOOM
Hi there! I've been on-and-off working on TacOS for a few months,
which follows some UNIX-derived concepts (exec/fork, unix-style
VFS, etc) and is now able to run a port of Doom, with a fairly
small amount of modifications, using my from-scratch libc. The
performance is actually decent compared to what I expected. Very
interested to hear your thoughts. Thank you!
Author : UnmappedStack
Score : 297 points
Date : 2025-04-24 00:15 UTC (22 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| pkoird wrote:
| Really really love the name.
| aoki wrote:
| 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.)
| khazhoux wrote:
| Burritos are just monoids in the category of endotacos.
| Octoth0rpe wrote:
| welp I think I found my favorite comment ever.
| rzzzt wrote:
| 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.
| KerbalNo15 wrote:
| This is so cool
| planck_tonne wrote:
| 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.
| UnmappedStack wrote:
| 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.
| khaledh wrote:
| 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
| gitroom wrote:
| Dude, getting Doom to run on your own kernel is epic - I gotta
| try building some wild stuff like this someday
| UnmappedStack wrote:
| 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)
| edoceo wrote:
| 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?
| UnmappedStack wrote:
| 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.
| thewileyone wrote:
| 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.
| UnmappedStack wrote:
| 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.
| donnachangstein wrote:
| A few months work by one guy and already more capable than the
| Hurd.
|
| Imagine what you could accomplish given 35 years.
| UnmappedStack wrote:
| 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.
| parl_match wrote:
| > 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!
| dxroshan wrote:
| > 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.
| donnachangstein wrote:
| 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.
| gertop wrote:
| 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/
| dxroshan wrote:
| 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/linu
| xmasterrace/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.
| k__ wrote:
| If it can run nginx and node.js on a VPS it could be a
| nice alternative to Linux.
| shakna wrote:
| 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.
| blendergeek wrote:
| 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
| anthk wrote:
| Youtube isn't an evidence of anything.
|
| Set up yourself.
| fr4nkr wrote:
| Hurd isn't exactly a useful project, but using Doom as the
| benchmark for the capability of an OS is a bit ridiculous.
| UnmappedStack wrote:
| 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.
| saagarjha wrote:
| They can't, actually.
| UnmappedStack wrote:
| https://www.popularmechanics.com/science/a33957256/this-
| prog...
| voxadam wrote:
| It runs on the _screen_ of a pregnancy test, Doom is
| actually executed on an Arm Cortex M0+ based Adafruit
| Trinket.
| mikehall314 wrote:
| You're right. In fact it's not even the screen - they
| replaced that too.
| notorandit wrote:
| Why?
| andrewmcwatters wrote:
| 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.
| UnmappedStack wrote:
| 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.
| waschl wrote:
| 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...
| UnmappedStack wrote:
| Very nice!i
| badmonster wrote:
| Very cool project! How are you handling process isolation and
| scheduling in TacOS?
| UnmappedStack wrote:
| 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.
| balou23 wrote:
| 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.
| UnmappedStack wrote:
| 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!
| MisterTea wrote:
| > 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.
| the_hoffa wrote:
| 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!!
| UnmappedStack wrote:
| 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.
| halfer53 wrote:
| Nice work!!!
| tamat wrote:
| 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?
| UnmappedStack wrote:
| 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.
| tamat wrote:
| 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
| noone_youknow wrote:
| 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.
| finalhacker wrote:
| Cool! Does OS kernel related to CPU model? Can I boot this kernel
| in KVM?
| UnmappedStack wrote:
| Yep! Works with KVM fine (at least for me).
| torcete wrote:
| Wow congrats, this is very impressive.
| kuberwastaken wrote:
| THIS IS AWESOME Love the project too!
| justin66 wrote:
| Why is running doom one of your milestones, given that doom will
| run fine on bare metal?
| UnmappedStack wrote:
| 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.
| justin66 wrote:
| Very impressive work regardless. Keep it up :)
| toast0 wrote:
| 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).
| justin66 wrote:
| 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).
| UnmappedStack wrote:
| I think the thing is, Doom was originally written __for__
| DOS. Part of the cool part is porting 3rd party software to
| my OS that wasn't originally written for it. That was part
| of my reasoning at least.
| snappyleads wrote:
| what a classic - great job!
| NoOn3 wrote:
| Great project. Mmap implementation is a cheat :).
| NoScopeNinja wrote:
| Really curious to learn more about TacOS. How does it manage
| running multiple programs safely at the same time?
| MisterTea wrote:
| 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.
| throwawaymaths wrote:
| > I have a Discord server for PotatOS where
|
| what is potatOS in this context?
| UnmappedStack wrote:
| Ah sorry, PotatOS is my old project. I'll fix that, I just
| copied that paragraph from the old README.
| sarkron wrote:
| What did you do make the project interactive enough so you don't
| end up copying existing implementations?
| OSDeveloper wrote:
| 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?
| kleiba wrote:
| 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.
| xhrpost wrote:
| 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)
| dmwilcox wrote:
| I don't know if it's been much used but it is known and works.
| I was doing this early on in my x86-16 assembler experiments
| but ended up using DOS as a program launcher for an easier
| emulator to use than qemu (dosbox-staging).
|
| The big limits if you don't want to get into disk IO, is 512
| bytes or less since you're basically running your program as a
| master boot record. To get more you'll need to load some LBAs
| from disk which yes there is an interrupt for and osdev has
| even better stuff.
|
| Other than that, the difference between a .com file (usual
| limit 64kb single segment) and an MBR style bootable program is
| pretty minimal
___________________________________________________________________
(page generated 2025-04-24 23:01 UTC)