I Coded a Solo 64-Bit Operating System on an Android TV (986 Commits as of 17 Jan, 2026)

Hi everyone,

I wanted to share a massive milestone for a project I have been building completely on my own. I don't own a standard desktop PC or laptop setup. Instead, my entire development environment consists of an Android TV, a physical keyboard hooked up via USB (sometimes a remote because my mom takes away my keyboard), a terminal emulator environment (Termux), cross-compilers, and emulation tools.

Working under these exact physical constraints, I have written a custom 64-bit "Notebook" style operating system called Aero1EOS 4.0 entirely from scratch. I just crossed 986 development commits, and the code is written strictly in raw C and x86_64 Assembly.

If you find this solo engineering project interesting, or if you respect the absolute grind of writing low-level kernel code on a television screen, please head over to GitHub and drop a star on the repository!

⭐ GitHub Repository: Here

🛠️ The Core Architecture & Boot Flow

Aero1EOS 4.0 bypasses modern high-level abstractions to deal directly with bare metal structures. The boot and memory layouts are manually calculated and mapped:

1. 64-Bit Long Mode Transition

The kernel entry begins in pure Assembly (boot.asm). The system boots using a 32-bit Multiboot 2 header. From there, the assembly initialization routines immediately handle the jump into 64-bit Long Mode:

• It disables the old 32-bit paging mechanisms.
• It constructs a manual 4-level paging hierarchy structure: PML4 -> PDPT -> PDT.
• To keep the initial system memory map clean and highly reliable, it identity-maps the first 64MB of physical RAM using 2MB "Huge Pages".

2. Post-Kernel Heap Allocator

Dynamic memory management is handled by a custom-written heap manager. To ensure that adding new operating system features never risks overwriting or overlapping compiled kernel instructions, the dynamic allocator's starting boundary is explicitly pinned to begin exactly at the memory address marked by kernel_end inside the custom linker script (linker.ld).

🚀 Key Technical Features

1. Persistent CMOS Security Hardening

One of the core features I wanted to implement was a hardware-level lock screen. I wrote a dedicated routine called lock_system_hardened.

• If an unauthorized user attempts to brute-force the operating system password, the failure state and lock tracking metrics are written directly to the motherboard's hardware CMOS registers via ports 0x70 and 0x71.
• Because this data is safely stored directly in the CMOS hardware, the security lock state completely persists across physical reboots or hard power cuts.
• (Note: If you run the ISO inside an emulator like QEMU, the default system unlock password is Ali123, I might make a command that changes the password).

2. 10 Independent Virtual Terminals (Multi-TTY)

The kernel natively manages a multi-terminal interface. The system supports 10 entirely independent virtual text terminals (designated TTY0 through TTY9). Users can hot-swap between these isolated active shell instances in real-time by using the standard hardware keyboard shortcut: Ctrl + Alt + F1 through Ctrl + Alt + F10.

3. Isolated 25th-Row UI & "Bad Apple!!" Engine

Aero1EOS 4.0 features a custom graphic/text demonstration built right into the core terminal logic to stress-test memory mapping efficiency.

• It includes a built-in "Bad Apple!!" ASCII animation demo that plays back smoothly at roughly 10–15 frames per second.
• The animation engine achieves high performance via direct, high-speed DMA-simulated loop writes straight to the VGA text-mode memory buffer at address 0xB8000.
• The Interface Isolation: While the animation completely dominates rows 1 through 24 of the screen buffer, the 25th row remains completely isolated and protected. The 25th row acts as a real-time status bar driven directly by CMOS hardware ticks, showing the Date, Time (12h format), and current TTY ID with zero screen flickering during heavy video playback.

📁 Repository Directory Structure

The project code is strictly compartmentalized to keep a clean separation of concerns:

.
├── src
│   ├── kernel.c           # Main Operating System Loop & Hardening Logic
│   ├── section1_cpu       # Boot Routines, PIT Timer, PC Speaker, & Heap Manager
│   ├── section2_video     # VGA Text Buffer Driver & Active TTY Management
│   ├── section3_io        # CMOS Communication Ports & Keyboard Layout Drivers
│   └── section4_shell     # Shell Interpretation Logic & Core Command Library
└── linker.ld              # Hardcoded Kernel Memory Layout Rules

💻 Built-in Shell & Utilities

The environment drops you into a custom, highly responsive command-line interface complete with command tab-completion capabilities. Some built-in utilities include:

• neofetch: Formats and displays CPU vendor strings, real-time RAM usage stats, and active OS bits.
• free: Directly queries the heap manager to map out Total, Used, and Free dynamic RAM metrics.
• uptime: Tracks high-precision system runtime statistics.
• timezone: Shifts the status bar CMOS clock offset configurations in real-time.
• lock: Manually forces the operating system into its hardened lock screen state.
• test: Runs a hardware verification routine by executing a high-precision 5-second countdown timer.
• beep: Triggers a classic system alert tone utilizing physical square waves sent directly to the PC Motherboard Speaker.
• twins: A custom command that prints out the names of my peak twins! 🥹

🐛 Current Quirks, Glitches, & Known Bugs

Because this is a solo hobbyist kernel built under highly unique television development constraints, there are a few interesting glitches I am working out:

• The PIT Frequency Anomaly: The Programmable Interval Timer is currently behaving weirdly. For some unexplained calculation reason, the timer works calibrating at 200Hz (using divisor 11931) instead of the industry-standard 100Hz mark for system uptime and task delays.
• The Emulated Speaker Stutter: The beep sound command experiences heavy audio stuttering when run inside virtual software emulators. However, when the OS is loaded onto real physical computer hardware, the audio stutters disappear entirely and the PC speaker tone plays back smoothly.
• Experimental Hardware Support: While the OS runs flawlessly inside QEMU, actual bare-metal hardware compatibility is heavily experimental and partially untested. My immediate roadmap includes constructing a native PCI Driver from scratch to lay down the initial infrastructure for Ethernet or Wi-Fi networking.

This project is 100% mine. However, I would absolutely love to hear your thoughts, structural critiques, or high-level engineering advice regarding my page tables, memory hierarchy layouts, or the CMOS hardware port security mechanics!

If you like what you see or want to follow along with the development progress, please click the link below and drop a quick star on the project. It means the world to a solo developer!

⭐ Support Aero1EOS on GitHub: Here