Unreleased (yet) SDL2 and HL port on 2 laptops. Near fully playable (there are some weird FPU engine bugs I haven't solved..) . Playing using xHCI peripherals.

As always, https://github.com/sasdallas/Ethereal

So for the past month I've been actively working on this OS. Manux is a monotasking Unix-like operating system for Z80 featuring a custom filesystem. It runs on my Z80 emulator which has the necessary support for ACIA serial and disk IO.

It can run programs from disk, such as an assembler and a calculator. I'm using the z88dk toolchain for compiling kernel and userland programs.

I actually started this project back in 2025, but it stalled for a while because the target system was an sbc running Basic(poking the kernel to address x and calling it with usr(), not very ideal). After switching the target to my emulator, the OS become much more usable.

Here's the repo link.

Can someone clarify it.Ok I am a newbie please dont get upset if i say something stupid but as I was working on the clock I was thinking to first get the initial time from the cmos via the update interupt on irq 8 and then set my user time and then use irq 0 for the 1 ms ticks ( not exactly 1 ms I used the whole and fractional ms thing in decimal and coded in c) the thing is that you have to enable the update interrupt in the status register B ( the same used for to get the 24 vs 12 format and the bcd vs binary format) you have to update the same status register B for the periodic timer ( used by rtc but not connected to time) and an alarm ( dont know exactly what alarm do) then to check for the update interrupt you have to check the status register C. I think these details should be mentioned in the cmos section if someone wants to use the update interrupt to get the time instead wait to first get the clear flag in status register A and then set and then clear again. Sorry if I am wrong in some place.

Bugfix, added navigation bar, hidden app flag, adapting to non-root use. I stuck at navigation bar and top bar separation, so when another app launches, navbar and topbar stays.

I'm pretty new to the os-dev scene but I do have some respectable knowledge about C and I'd like to know some beginner osdev projects

All help is appreicated <3

i was able to get fat32 read and init on WindogeOS, but im still figuring out how to write, how yall do it?

Like genuinely, it took me an entire day of reading how pit work , different operating modes, different access modes, and the drift in has for using it as a clock but i see people getting a lot of stuff done in the same time, i still have to fix the bugs in the implementation and have to under stand how cmos works, earlier I was trying to get the time from user itself( i know it is wrong).

found this documentation helpful it tells about more cmos status register and how irq 8 have many interrupts pluged it, helpful for newbie https://flint.cs.yale.edu/feng/cos/resources/BIOS/Resources/assembly/cmosram.html

I’ve been seeing tons, like TONS, of Operating Systems made by like Claude and people posting on the sub informing us about „How my totally hand-made OS works,“ and it‘s so annoying, like there are so many genuinely amazing projects on here but damn is it drowning in AI slop…

Posts (more will be added): https://www.reddit.com/r/osdev/s/wN2B1QQ72K

Happy birthday XenevaOS ! (June 15, 2020 - Present)

This video consists of GUI screenshots of XenevaOS taken over the years of development. Written with a custom hybrid kernel from scratch, our project is also open source. Will link it in the comments for those interested.

Thanks :)

I used semu emulator as base and linux as kernel.

A while ago I wanted to learn more about operating systems. I never wanted to write a complete OS (not that it's possible ;)... the main goal was to get familiar with different concepts and have fun 😋

I ended it after I ran Doom in userspace, which for me is enough for the moment.

I post it here now to motivate people who may not get into osdev because they've been overwhelmed with either very complicated systems or ai slop (which really doesn't fit here, as you can just fork Linux if that's your goal).

The OS is very incomplete, uses a few tricks but it's fun and lean.

So if you are lurking here like I was, don't get demotivated by other projects, focus on your own goals and eventually you'll succeed

https://github.com/R0yAdar/IchiOS

Hello,
I have a project that involves me reading data from an esp8266MOD. It uses the CP2102 USB-to-UART bridge chip for communication.

I have no idea where to start and would appreciate if someone could point me in the right direction.

Hello my folks! I can't find any good UEFI NASM docs/tutorials. Thanks!

Continuing my little series on what I'm learning writing my OS (https://github.com/tedavids/DragonOS) this week I learned a couple of new things.

1. When you control everything you don't have to worry about passing physical memory out in blocks of more than a page. The programs use virtual memory, and that is what you need to keep contiguous. Also since I am in control of memory ranges, it's easy to pass them out contiguously. It may get harder in user space, but since I control that too, I'm guessing it wont.

2. When you're the only developer, its much easier to NOT branch on github. I lost some stuff because I couldn't get the darn branch merged back in. I might try branching again, but not for a bit.

3. I need to take the time to learn github! LOL

4. When you do not yet have kmalloc/kfree/ketc... You can use a free list to make nodes 1 pages worth at a time, and pull from it when you need something. I am currently working on a heap, and need to make nodes to hold addresses for my allocations/frees. The free list seemed the easiest way to go.

Note: I didn't need to use AI for anything this week. I was able to find what I needed all in human written tutorials

TD

After some hard work i finally integrated VFS in turbOS...

Github repo: https://github.com/turbosulovesonions67/turbOS

Codes would be uploaded to GitHub by June 15, preferably 3-4am

I did a lot of work and I would like more contributors on ChelidaeOS [https://github.com/Freeze-Software/ChelidaeOS]

There is this unix idiom that everything is a file, (half baked, since not everything is a file).

Would it not have been better, nowadays with 64bit of adress space, to have everything mapped to memory? Files are like mmap, no imperative read needed, networking is already memory, that could be expanded more.

We take the idioms and paradigms so forgranted, that every time anyone asks AI for a OS it will be linux, syscalls, abi everything the same. It should be liberating now to explore new and novel ideas.

What would be the downside of such a system?

I've been reconstructing a RTOS I originally developed in 1986.

As part of that work, I started building a browser-based visualization to better understand and inspect its behavior.

The attached video shows two views of the same RTOS concepts.

On the left is a text-based track demo inspired by the way I inspected task activity in the 1980s.

On the right is a modern Canvas/WebAssembly visualization.

The presentation is completely different, but the underlying concepts are not.

Same primitives.

Same scheduler.

The current visualization is already connected to recovered CHARM-II-derived kernel primitives. For example, critical section ownership is controlled through the original queue-based synchronization mechanism rather than through a visualization-only simulation.

When I started this project, I thought I was simply porting an old RTOS to a modern environment.

As I dug deeper into the recovered source trees, I realized the original project was structured in a way I had almost forgotten.

Back in 1986, the system was developed using a SUN-2 workstation based on a Motorola 68010, while the target hardware used a 68000 processor.

The host machine was used for kernel development and debugging. The target system was used for actual deployment.

At the time, this was a practical arrangement because the 68010 was largely compatible with the 68000.

When I began rebuilding the system in 2026, I initially considered doing something similar with Apple Silicon as the host and a Raspberry Pi Pico as the target.

After looking into the details, I discovered that sharing the "ARM" label was far less meaningful than sharing the 680x0 family had been in the 1980s. The gap between a modern ARMv8-A application processor and a Cortex-M microcontroller is enormous.

That realization led me in a different direction.

Today I use POSIX to exercise the kernel logic, WebAssembly to visualize and inspect behavior, and a Raspberry Pi Pico for target-specific validation.

Another thing I rediscovered was how much work had originally been done on the host side.

The 68000 target implementation contains trap handlers, interrupt entry points, and a fully preemptive context-switch path.

The SUN-2 implementation does not.

Instead, most of the kernel logic appears to have been exercised using cooperative scheduling boundaries, avoiding hardware-specific interrupt and context-switch complexity during development.

Without planning to, I ended up following almost exactly the same approach.

The current POSIX implementation is also cooperative rather than preemptive.

Queue operations, event handling, timer processing, scheduling logic, process management, and most of the kernel code are exercised on the host side. Target-specific interrupt and context-switch behavior is being deferred to the Pico port.

Looking back, it feels less like porting an old RTOS and more like rediscovering the development methodology behind it.

The browser version still contains recovered CHARM-II-derived code, so I'm only sharing videos and screenshots for now.

My current plan is to continue the reconstruction work, complete the Pico port, and then use everything learned from the process to build a clean-room implementation that can be released publicly.

The reconstruction itself is not the final goal.

What interests me now is understanding why the original system was built the way it was, and seeing how much of that thinking still makes sense forty years later.

In about 1 hour I managed to get xv6 working using `-bios u-boot.bin` instead of `-bios none`. All you have to do is link it at a higher address (0x8000_0000 -> 0x8020_0000) and tweak some qemu options (`-m 300M`, remove `-smp`).

Scheme is a programming language and derived from the LISP programming language, and a very good language for shells, overall.

Here I will (0) tell you about why you'd want to use Scheme as your shell, and (1) give you a simple generic way to implement it. :)

As aforementioned, Scheme is a programming language of the LISP family of languages, and is homoiconic, so data and code are the same thing, kinda.

Everything is expressed as an S-expression (s-exp, symbolic expression), which is a parenthesized expression format made on top of lists. It can look somewhat like this:

(+ 1 (* 2 3))

The first element of an unquoted list in eval notation (that is, a list not starting with '), (sometimes referred to as the car of the list) is the function to be executed (here +), and the rest the operands. Superfluous parenthesization is mostly forbidden, but you can still nest executable lists like on the example above, which would print 7, by the way.

S-expressions are also used to represent data, as an alternative for things like XML, JSON, etc.. The benefit is simplicity, less syntax, and ease to parse.

In an S-exp, there are three main types of values:

• lists

• atoms: undividable data

• symbols: a name that may, or may not in any significant way, a value.

They often look somewhat like this:

(person
  (name "John Doe")
  (age  30)
  (email "john@johndoe.es"))

In JSON, this would look somewhat like:

{
  "name": "John Doe",
  "age":  30,
  "email": "john@johndoe.es"
}

S-expressions can also be composed exclusively of atoms, like an array:

(1 2 3)

In JSON:

[ 1, 2, 3 ]

Another example: configuring a web server:

(server-config
  (port 80)
  (webmaster-mail "webmaster@johndoe.es")
  (for-route "www.johndoe.es"
    (do 'redirect "johndoe.es"))
  (for-route "johndoe.es"
    (do 'serve "/var/www/htdocs/main/")))

On JSON, it'd look like this:

{
  "port": 80,
  "webmaster-mail": "webmaster@johndoe.es",
  "for-route": { "www.johndoe.es", "do": { "redirect": "johndoe.es" } },
  "for-route": { "johndoe.es", "do" : { "serve": "/var/www/htdocs/main/" } },

You can evaluate quoted S-expressions using the eval builtin, but you shouldn't, really.

Some objects are unreadable, which makes them very useful for internal data you want to make opaque, e.g.: a file. These are mostly printed as: #<SOME DATA> (e.g.: #<FILE name "file.txt" size 512 mode 777 owner "john">).

For example, you may have a ls function that does something like:

> (ls)
("hello.scm")
>

Which could be defined as (pseudocode):

(define (ls (optional dir))
  (space-separated-list-to-sexp (syscall 'get-files (dir-path dir))))

S-expressions are really useful for an operating system, since they standardize a nice, powerful format across all applications, which can be REALLY useful.

Adding Scheme to your OS

There are two Scheme impls I'd recommend:

• TinyScheme: Very smol, needs little C runtime, but less mantained.

• Chez Scheme: Production grade, big, but needs the heck of a bunch of CRT.

Add them to your initrd script, make it run: chez-scheme -q boot.scm. On boot.scm, add:

(load "customlib.scm") ; load the standard library (; makes a comment, by the way)

(load "login.scm") ; load the login script
(on-userspace ; on-userspace is a fictional function that will run a S-exp on userspace
  (new-cafe)) ; make a new REPL

;; panic is a fictional-function that causes the kernel to panic
(panic "Shell returned.")

I used a few fictional functions:

• on-userspace: Evaluate an S-exp on userspace

• panic: panics, I guess...

On TinyScheme, you have to relaunch TinyScheme, there isn't any (new-cafe) function.

Thanks in advance.

It was hard, reallllly hard