DEV Community: Paull Knya-z

My OS has a new name: meet Snorkel‑OS

Paull Knya-z — Sat, 23 May 2026 14:28:41 +0000

Snorkel‑OS – unusual, isn't it? Let me explain.

A snorkel is a tube that lets a diver breathe while staying just below the surface, observing the underwater world without interruption. For me, a computer is a similar “parallel world” full of mysteries. My operating system is a view from the outside, but as close as possible to the hardware and the code. I renamed the project to emphasise this metaphor.

Technically, the kernel is still called Paull‑kernel (a 32‑bit x86 monolithic kernel written in NASM and C). But the whole operating system is now named Snorkel‑OS.

The kernel is what's inside. The OS is how we see it from the outside.

My next technical article (about the FAT12 file system) is coming soon. For now, just remember the new name.

my OS link: https://github.com/Paullknya/Paull-kernel

forum(mailing list): https://paullknya.github.io/

Happy coding! 🐟

Booting from FAT12: How I added file reading to my x86 kernel

Paull Knya-z — Fri, 22 May 2026 14:23:41 +0000

My kernel Paull-kernel (32‑bit x86, protected mode) already had a command line and could run built‑in commands like hew → hello world. But everything was hardcoded. To load and run external programs, I needed a real file system.

I chose FAT12 – the classic floppy disk file system. Simple, well documented, and perfect for a hobby OS.

🧱 FAT12 structure (short version)

A FAT12 disk looks like this:

Boot Sector (512 bytes) – contains the BIOS Parameter Block (BPB) with geometry info.
First FAT (File Allocation Table) – a table that tells you which clusters belong to a file.
Second FAT (optional, backup).
Root Directory – a list of files (each entry is 32 bytes).
Data Area – the actual file content, split into clusters (usually 512 bytes per cluster).

Names in the root directory use the 8.3 format (e.g. HELLO BIN). Each cluster is a chain: a number in the FAT points to the next cluster; 0xFFF means end of file.

🔧 Reading a file step by step

1. Read the boot sector first

The boot sector (sector 0) contains the BPB. From there I read:

BytesPerSector (usually 512)
SectorsPerCluster (usually 1 for floppies)
ReservedSectors (often 1)
NumFATs (usually 2)
SectorsPerFAT
RootDirEntries (224 for a standard 1.44 MB floppy)

These values tell me where the FAT, root directory, and data area start.

2. Locate the file in the root directory

The root directory starts after the boot sector and both FATs:

root_dir_sector = reserved_sectors + (num_fats * sectors_per_fat);

I load the root directory into memory and scan each 32‑byte entry. I compare the name (padded with spaces) to the file I’m looking for, e.g. "HELLO BIN".

Follow the cluster chain

Once I have the first cluster number from the directory entry, I read that cluster from the data area:
c

first_data_sector = root_dir_sector + (root_dir_entries * 32 + bytes_per_sector - 1) / bytes_per_sector;
cluster_sector = first_data_sector + (cluster - 2) * sectors_per_cluster;

Then I use the FAT to find the next cluster:

Load the FAT sector that contains the entry for my cluster.
Read the 12‑bit value (FAT12 uses 12‑bit entries).
If the value is 0xFFF (or 0xFF8–0xFFF) – end of file. Otherwise, move to that cluster and repeat.

🐞 Problems I ran into

Wrong first sector of root directory – I forgot to add the reserved sectors. Always recalculate.

Cluster numbers start from 2 – I tried to use cluster 0 as the first data cluster. No.

Reading beyond the sector – I had to handle cases where a cluster spans two FAT sectors.

Disk geometry – The BIOS int 0x13 expects CHS (cylinder/head/sector). I had to convert LBA to CHS manually. It’s annoying but doable.

Debugging was a pain. I printed sector numbers to the screen (using video memory at 0xB8000) to see what was actually being read.
🎉 Result

Now my kernel can load a file from disk:
bash

load HELLO.BIN
Loading HELLO.BIN ... done.
Executing...
Hello from user program!

I can write small assembly programs, compile them into a raw binary, and copy them to a FAT12 floppy image. Then Paull‑kernel loads and runs them.

🔜 What’s next

A dir command to list all files in the root directory.
Better error handling (file not found, end of disk).
Maybe later: support for long file names (LFN) or FAT32.

🔗 Links

Source code of Paull‑kernel: github.com/Paullknya/Paull-kernel
Discuss this article: Community forum
My GitHub profile: github.com/Paullknya

Happy low‑level coding! 🦫

Why my keyboard handler caused #GP (and how I fixed it)

Paull Knya-z — Wed, 20 May 2026 08:09:03 +0000

— A true story of debugging a 32‑bit kernel

A few weeks ago I was happily writing my own 32‑bit x86 operating system, Paull-kernel. Everything worked: the bootloader, protected mode, a simple “Hello” message. Then I decided to add keyboard input.

I wrote an IRQ1 handler, compiled, ran… and QEMU crashed hard with a General Protection Fault (#GP) on every key press. Triple fault. Reboot loop. Frustration.

After two hours of staring at the code, I finally understood the problem – and it wasn’t inside the handler logic. It was two stupid mov instructions.

🧠 What I wanted to do

Catch keyboard interrupts (IRQ1) and read scancodes from port 0x60.
Convert scancodes to ASCII characters and print them to the screen.
Simple, classic OS‑dev step.

My handler looked (mostly) correct: read scancode, skip key‑release, translate via a table, write to video memory.

💥 What went wrong

Every key press caused #GP. The processor reset. No error message, no debugging output – just a black screen.

Here’s the piece of code that broke everything:

keyboard_handler:
    pushad
    mov ax, 0x1000
    mov ds, ax
    mov ax, 0xB800
    mov es, ax
    in al, 0x60
    ...

Can you spot the error?
🔍 The investigation

In real mode (16‑bit), mov ds, ax with ax = 0x1000 would set the data segment to physical address 0x10000.
In protected mode (32‑bit), segment registers hold selectors – indexes into the GDT (Global Descriptor Table).

0x1000 is a garbage selector – it points to no valid descriptor.

0xB800 is also a garbage selector.

Loading them doesn’t trigger an immediate fault, but as soon as the CPU tries to access memory through ds or es (e.g., stosw with es), it throws #GP.

The handler looked like it should work, but the environment was completely different from real mode.
✅ How I fixed it

My GDT uses the flat memory model:

Code selector: 0x08

Data selector: 0x10 (base = 0, limit = 4 GiB)

So I changed two lines:


keyboard_handler:
    pushad
    mov ax, 0x10        ; correct data selector
    mov ds, ax
    mov es, ax
    in al, 0x60
    ...

And for video memory, I stopped using segment overrides. Instead, I write directly to the linear address 0xB8000:


mov edi, [cursor_pos]
shl edi, 1
add edi, 0xB8000
mov ah, 0x07
stosw

No more es magic. Now the handler works perfectly.
📦 Key takeaways

In protected mode, segment registers store GDT selectors, not physical addresses.

Values like 0x1000 or 0xB800 are almost always invalid and will cause #GP when accessed.

Always check your GDT and use the correct selectors (e.g. 0x08 for code, 0x10 for data).

When writing to video memory, use the linear address 0xB8000 and a flat‑mapped ds/es.

One small mistake can cost you hours of debugging. But once you understand the model, it becomes obvious.
🔗 Links & resources

Source code of AxonOS (full kernel + bootloader):
👉 github.com/Paullknya/AXonOS-kernel

My GitHub profile:
👉 github.com/Paullknya

Discuss this article on the community forum:
👉 paullknya.github.io

🚀 What’s next?

Next article I’ll show how I added ring 0/3 switching and why sudo reboot asks for a password.
If you’re interested, follow me or star the repo – it helps a lot.

Happy coding, and may your selectors always be valid.

Writing a Bootloader for My OS: Common Pitfalls and How I Fixed Them

Paull Knya-z — Wed, 20 May 2026 07:41:54 +0000

Writing a Bootloader for My 32-bit x86 OS: Common Pitfalls and How I Fixed Them

I decided to write my own 32-bit x86 operating system from scratch. The first step was a bootloader – the small piece of code that loads the kernel. It’s supposed to be simple, but I ran into several frustrating issues. This post documents the real problems I faced and how I solved them, so you can avoid the same traps.

1. The BIOS signature

The boot sector must end with the magic bytes 0x55AA. The BIOS checks these two bytes before loading the sector. I forgot them, and nothing happened.

Fix: Add dw 0xAA55 at the end of your bootloader code, after filling the rest of the 512-byte sector with zeros.

times 510-($-$$) db 0
dw 0xAA55

Losing the boot drive number

The BIOS passes the disk number in the dl register. I accidentally overwrote it before using it in the int 0x13 call. The disk read failed silently.

Fix: Save dl right at the start:


mov [boot_drive], dl

Then restore or use the saved value when reading sectors.

A20 line – the hidden gatekeeper

To access memory above 1 MB and enter 32‑bit protected mode, the A20 line must be enabled. I wasted hours trying to figure out why my far jump crashed. The quickest way (though not the most universal) is to use port 0x92.


in al, 0x92
or al, 2
out 0x92, al

Many emulators enable A20 by default, but real hardware doesn’t – always include this step.

Global Descriptor Table (GDT) mistakes

A flat memory model requires at least two descriptors: code and data. I messed up the segment limits and flags, causing general protection faults.

Correct minimal GDT for flat model (32‑bit):


gdt_start:
    dq 0                       ; null descriptor
    dw 0xFFFF, 0x0000, 0x9A00, 0x00CF   ; code segment 0x08
    dw 0xFFFF, 0x0000, 0x9200, 0x00CF   ; data segment 0x10
gdt_end:

Load it with lgdt [gdt_desc] before switching to protected mode.

The protected mode jump

After setting the PE bit in cr0, you must perform a far jump to reload CS with the new code segment selector. I initially forgot the jmp and the CPU continued with the old real‑mode CS, causing a triple fault.


mov eax, cr0
or eax, 1
mov cr0, eax
jmp 0x08:protected_mode   ; 0x08 is our code segment selector

Segment registers in protected mode

Inside the kernel (or later, in interrupt handlers), I naively loaded ds = 0x1000 and es = 0xB800, assuming they would work like in real mode. That’s wrong – in protected mode they must hold selectors (indices into GDT). This caused instant #GP.

Fix: Use the data segment selector (0x10) and access video memory directly by its linear address:


mov ax, 0x10    ; data selector
mov ds, ax
mov es, ax

; Write character via linear address 0xB8000
mov edi, [cursor_pos]
shl edi, 1
add edi, 0xB8000
mov ah, 0x07
mov [edi], ax

Result: a working bootloader + kernel

After fixing these issues, the bootloader loads the kernel, enters protected mode, and runs a simple command line. Everything is open source.

GitHub repository: github.com/Paullknya/AXonOS-kernel
Project discussions and updates: paullknya.github.io

If you’re also writing a hobby OS, I hope this saves you a few hours of debugging. Feel free to ask questions in the discussions – I’ll be happy to help.

Happy coding!

my OS link: https://github.com/Paullknya/AXonOS-kernel