THIS IS AWESOME
Love the project too!
Show HN: My from-scratch OS kernel that runs DOOM
51–60 of 90 posts
Re: Show HN: My from-scratch OS kernel that runs DOOM
#52Great 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).…
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
Re: Show HN: My from-scratch OS kernel that runs DOOM
#53Earlier quoted context omitted.
> 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.
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
Re: Show HN: My from-scratch OS kernel that runs DOOM
#54Great 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).…
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.
Re: Show HN: My from-scratch OS kernel that runs DOOM
#55Hi, 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…
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
Re: Show HN: My from-scratch OS kernel that runs DOOM
#56Why is running doom one of your milestones, given that doom will run fine on bare metal?
Re: Show HN: My from-scratch OS kernel that runs DOOM
#57Very 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…
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.
Re: Show HN: My from-scratch OS kernel that runs DOOM
#58Why 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.
Re: Show HN: My from-scratch OS kernel that runs DOOM
#59Cool! Does OS kernel related to CPU model? Can I boot this kernel in KVM?
Yep! Works with KVM fine (at least for me).
Re: Show HN: My from-scratch OS kernel that runs DOOM
#60Earlier quoted context omitted.
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…
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!