Apple's iPod Video firmware boots here, from the reset vector, on an emulator written from scratch. It formats its own filesystem, reads the click wheel, draws its own menus, and plays a game. So does Rockbox.

Alpha. It boots, it draws, the wheel moves it, and it plays Brick. That last one was re-measured on 2026-09-07 on the build this program ships, at the iPod's own clock rather than the research accelerant, against a control arm that keeps every touch and removes only the turn of the wheel: same descent, same playfield, same served ball, and the paddle does not move (research/18). The Brick pictures on this page were made on 2026-08-14 and have not been re-rendered; what they show has been. Expect rough edges, and expect things that work here to fail on files nobody has tested. Open an issue if something breaks; every report so far has found a real bug.
You do not need an iPod, or any files off one.
ipod-emulator.app (macOS) or run ipod-emulator (Linux, Windows).That is the whole of it. The ROM is built from a table of 197 rows transcribed from libgpod, so the machine carries a real model number, serial and GUID, generated from a seed so the same iPod comes back next launch. The firmware comes from Apple's own servers — 66 of the 71 releases are still served, every one verified against a recorded size and SHA-256, and nothing is renamed into place until it verifies.
This is what a synthesised iPod shows while it starts:
It is not code-signed — deliberately, because buying a certificate to make a reverse-engineering tool look official is the wrong trade. macOS 15+ blocks the first launch: open it, then System Settings → Privacy & Security has a button to open it anyway. Windows: More info → Run anyway. Anything you build yourself skips this.
The two halves are independent. The boot ROM and the drive are separate questions, and you can supply either, both or neither — drop whatever you have anywhere on the window, in any order. Each file is identified by what it contains, not by which box you put it in.
It keeps them all. Everything you drop is filed in Resources — boot ROMs, .ipsw bundles,
drives — and a device is a name for one selection from it. So a second boot ROM does not replace
the first, one ROM can back several devices, and switching between two iPods is pressing start on
one of them rather than finding two files again.
| the boot ROM | the drive |
|---|---|
| synthesised — no file needed | built from a fetched .ipsw — no file needed |
| your own 1 MB NOR dump | your own .ipsw, built into a drive as it lands |
a drive image you already have — then no .ipsw is needed at all |
Any combination works. What a real dump additionally buys you is the things that are the ROM and cannot be synthesised: Apple's own bootloader running from the reset vector, and the service diagnostics below.
You can also give a synthesised iPod your own boot picture in place of the click-wheel outline — it is a path in the settings, re-read when you edit the file.
Reading a dump off your own iPod takes about five minutes with Rockbox and undoes cleanly: docs/GETTING-THE-FILES.md.
Apple's own code the whole way. The bootloader brings up SDRAM, talks to the PCF50605 power chip over I²C, uploads firmware to the video co-processor, DMAs 7.5 MB of RetailOS into memory, checksums it and jumps. RetailOS starts its RTXC kernel and 61 tasks, formats its own FAT32 volume, and draws.
![]() | ![]() |
![]() | ![]() |
Two bootloaders and two operating systems in the window — Apple's and Rockbox's; RetailOS and Rockbox 4.0, each unmodified, from upstream, fetched and verified by this program, installed onto a drive it wrote and started by Apple's own bootloader.
A third of each runs, and is not offered in the window yet. ipodloader2 and iPodLinux are
experimental: the install is complete and the kernel boot is clean, and then ZeroLauncher stalls
at its last step. ipod-boot install-linux builds that drive for anyone who wants to look at it —
the window does not offer a path that ends there after a 101 MB download. See
KNOWN-BUGS.md.
| Rockbox 4.0 — its main menu | ipodloader2 — reading the drive | iPodLinux — its userland starting |
|---|---|---|
![]() | ![]() | ![]() |
The right two are the experimental pair, reached with ipod-boot install-linux.
Rockbox is finished; iPodLinux is not, which is why the window does not offer it. Its kernel
boot is clean — both partitions found, FAT32 root mounted, /bin/init run, ZeroSlackr's ext3
userland loop-mounted, and no ATA error anywhere in the dmesg. Then ZeroLauncher draws the screen
above and stalls at its last step. The picture is there because it is what actually happens, not
because it is finished.
ipod-boot install-linux builds the drive: the loader into the firmware partition, ZeroSlackr's five
directories onto the volume, and a boot menu naming only what is actually on it. On a drive that
already has Rockbox, that is a three-entry menu — ZeroSlackr, Apple OS, Rockbox.
And Apple's service diagnostics — the program a real iPod shows on SELECT+REW at power-on.
It lives inside the boot ROM, so this one needs a real dump; a synthesised ROM has no image
directory to hold it:
A drawn iPod whose screen is the live framebuffer and whose wheel, buttons and hold switch drive the
machine. D overlays a readout; S writes a screenshot; Esc leaves a screen.
| user mode | with the readout |
|---|---|
![]() | ![]() |
Power off and restart are real — the machine is dropped and re-entered at the reset vector, not restored and pretended. By default the iPod writes to your drive image, exactly as a real one writes to its own disk, and closing the window parks it so the next launch resumes in three seconds instead of cold-booting for seventy-five. Work on a copy in settings never touches your image.
One document per question, and none of them answers another's.
| docs/DEVELOPING.md | building it, the command-line recipes, installing other operating systems |
| ROADMAP.md | what is intended, in what order — including the per-subsystem Where we are table |
| KNOWN-BUGS.md | what is wrong |
| research/04-bypass-ledger.md | what is faked, with a retirement condition for each |
| CHANGELOG.md | what changed, release by release |
| NEXT.md | what is being worked on now |
| research/17 | the boot matrix — which OS boots on which ROM, cell by cell |
| research/ | how any of it was found out — the larger half of this project |
research/ keeps what was believed and why it was wrong, in place, rather than tidying it away.
Several conclusions in it are retracted by later ones and the retraction sits next to the claim.
Development happens in a small group, and it starts on Discord rather than with a pull request:
That is deliberate and not gatekeeping for its own sake. Much of the work needs Apple's firmware, ROM dumps and multi-gigabyte disk images that cannot be published — so a contributor needs the files, the context for what has already been tried, and somewhere to ask before spending a weekend re-deriving something. A pull request arriving cold has none of that, and the reviewer cannot supply it in a comment thread.
So: say hello, say what interests you, and you will be pointed at the working repository and the guide that goes with it. Bug reports and questions are welcome as issues here without any of that.
If you own a click-wheel iPod, that is the most useful thing you can offer — more useful than code, and it usually takes an afternoon and no soldering. HARDWARE.md says which models help, what answering a question actually involves, and what will never be asked of you. Lending a device is not required; answering one question with it is the whole point.
The link above is the only copy of it in this project. If you find it written down anywhere else, that copy is the one that will go stale.
Other people's work made this possible, and some of it saved months. In rough order of debt:
pp5020.h and the iPod target code are
where most register semantics came from, and Rockbox was the oracle: a known-good OS to boot
when something broke and you needed to know whether it was you. If you want to understand this
hardware, read Rockbox first.sysinfo_t layout.dreamlayers, on the Rockbox forums in 2009, who identified vmcs.bin and the .vll
files as ELF DLLs loaded into the Broadcom chip. This project worked that out independently in
2026 and then found the post. Sixteen years early.If you want to give something back, give it to them. Rockbox has been maintained for twenty years by people who documented this hardware so anyone could use it, before there was an LLM to do the typing. If you still want to throw something at this one: ko-fi.com/siggifly — it goes on parts for oPod, the open player this is meant to run on when the hardware runs out.
I did not write a single line of code in this project. It was written with Claude Opus 5 under direction. What I did was steer: decide what was worth chasing, push back when an answer sounded too convenient, find the prior art that unstuck it, and say "that can't be right, look again". That is not nothing, and it is also not writing an emulator. I would rather say so than let anyone assume otherwise.
Part of the iPod Preservation Project — other arms are running games without RetailOS at all, presenting a virtual iPod to iTunes, and oPod.
GPL-3.0-or-later for the code, CC BY-SA 4.0 for research/. See docs/LICENSING.md.
Apple's firmware, NOR dumps, IPSW files and disk images are not covered, not distributed, and never
will be.
Hacker News (1)
Rust
91.4%
Slint
7.8%
Apple's iPod Video firmware boots here, from the reset vector, on an emulator written from scratch. It formats its own filesystem, reads the click wheel, draws its own menus, and plays a game. So does Rockbox.

Alpha. It boots, it draws, the wheel moves it, and it plays Brick. That last one was re-measured on 2026-09-07 on the build this program ships, at the iPod's own clock rather than the research accelerant, against a control arm that keeps every touch and removes only the turn of the wheel: same descent, same playfield, same served ball, and the paddle does not move (research/18). The Brick pictures on this page were made on 2026-08-14 and have not been re-rendered; what they show has been. Expect rough edges, and expect things that work here to fail on files nobody has tested. Open an issue if something breaks; every report so far has found a real bug.
You do not need an iPod, or any files off one.
ipod-emulator.app (macOS) or run ipod-emulator (Linux, Windows).That is the whole of it. The ROM is built from a table of 197 rows transcribed from libgpod, so the machine carries a real model number, serial and GUID, generated from a seed so the same iPod comes back next launch. The firmware comes from Apple's own servers — 66 of the 71 releases are still served, every one verified against a recorded size and SHA-256, and nothing is renamed into place until it verifies.
This is what a synthesised iPod shows while it starts:
It is not code-signed — deliberately, because buying a certificate to make a reverse-engineering tool look official is the wrong trade. macOS 15+ blocks the first launch: open it, then System Settings → Privacy & Security has a button to open it anyway. Windows: More info → Run anyway. Anything you build yourself skips this.
The two halves are independent. The boot ROM and the drive are separate questions, and you can supply either, both or neither — drop whatever you have anywhere on the window, in any order. Each file is identified by what it contains, not by which box you put it in.
It keeps them all. Everything you drop is filed in Resources — boot ROMs, .ipsw bundles,
drives — and a device is a name for one selection from it. So a second boot ROM does not replace
the first, one ROM can back several devices, and switching between two iPods is pressing start on
one of them rather than finding two files again.
| the boot ROM | the drive |
|---|---|
| synthesised — no file needed | built from a fetched .ipsw — no file needed |
| your own 1 MB NOR dump | your own .ipsw, built into a drive as it lands |
a drive image you already have — then no .ipsw is needed at all |
Any combination works. What a real dump additionally buys you is the things that are the ROM and cannot be synthesised: Apple's own bootloader running from the reset vector, and the service diagnostics below.
You can also give a synthesised iPod your own boot picture in place of the click-wheel outline — it is a path in the settings, re-read when you edit the file.
Reading a dump off your own iPod takes about five minutes with Rockbox and undoes cleanly: docs/GETTING-THE-FILES.md.
Apple's own code the whole way. The bootloader brings up SDRAM, talks to the PCF50605 power chip over I²C, uploads firmware to the video co-processor, DMAs 7.5 MB of RetailOS into memory, checksums it and jumps. RetailOS starts its RTXC kernel and 61 tasks, formats its own FAT32 volume, and draws.
![]() | ![]() |
![]() | ![]() |
Two bootloaders and two operating systems in the window — Apple's and Rockbox's; RetailOS and Rockbox 4.0, each unmodified, from upstream, fetched and verified by this program, installed onto a drive it wrote and started by Apple's own bootloader.
A third of each runs, and is not offered in the window yet. ipodloader2 and iPodLinux are
experimental: the install is complete and the kernel boot is clean, and then ZeroLauncher stalls
at its last step. ipod-boot install-linux builds that drive for anyone who wants to look at it —
the window does not offer a path that ends there after a 101 MB download. See
KNOWN-BUGS.md.
| Rockbox 4.0 — its main menu | ipodloader2 — reading the drive | iPodLinux — its userland starting |
|---|---|---|
![]() | ![]() | ![]() |
The right two are the experimental pair, reached with ipod-boot install-linux.
Rockbox is finished; iPodLinux is not, which is why the window does not offer it. Its kernel
boot is clean — both partitions found, FAT32 root mounted, /bin/init run, ZeroSlackr's ext3
userland loop-mounted, and no ATA error anywhere in the dmesg. Then ZeroLauncher draws the screen
above and stalls at its last step. The picture is there because it is what actually happens, not
because it is finished.
ipod-boot install-linux builds the drive: the loader into the firmware partition, ZeroSlackr's five
directories onto the volume, and a boot menu naming only what is actually on it. On a drive that
already has Rockbox, that is a three-entry menu — ZeroSlackr, Apple OS, Rockbox.
And Apple's service diagnostics — the program a real iPod shows on SELECT+REW at power-on.
It lives inside the boot ROM, so this one needs a real dump; a synthesised ROM has no image
directory to hold it:
A drawn iPod whose screen is the live framebuffer and whose wheel, buttons and hold switch drive the
machine. D overlays a readout; S writes a screenshot; Esc leaves a screen.
| user mode | with the readout |
|---|---|
![]() | ![]() |
Power off and restart are real — the machine is dropped and re-entered at the reset vector, not restored and pretended. By default the iPod writes to your drive image, exactly as a real one writes to its own disk, and closing the window parks it so the next launch resumes in three seconds instead of cold-booting for seventy-five. Work on a copy in settings never touches your image.
One document per question, and none of them answers another's.
| docs/DEVELOPING.md | building it, the command-line recipes, installing other operating systems |
| ROADMAP.md | what is intended, in what order — including the per-subsystem Where we are table |
| KNOWN-BUGS.md | what is wrong |
| research/04-bypass-ledger.md | what is faked, with a retirement condition for each |
| CHANGELOG.md | what changed, release by release |
| NEXT.md | what is being worked on now |
| research/17 | the boot matrix — which OS boots on which ROM, cell by cell |
| research/ | how any of it was found out — the larger half of this project |
research/ keeps what was believed and why it was wrong, in place, rather than tidying it away.
Several conclusions in it are retracted by later ones and the retraction sits next to the claim.
Development happens in a small group, and it starts on Discord rather than with a pull request:
That is deliberate and not gatekeeping for its own sake. Much of the work needs Apple's firmware, ROM dumps and multi-gigabyte disk images that cannot be published — so a contributor needs the files, the context for what has already been tried, and somewhere to ask before spending a weekend re-deriving something. A pull request arriving cold has none of that, and the reviewer cannot supply it in a comment thread.
So: say hello, say what interests you, and you will be pointed at the working repository and the guide that goes with it. Bug reports and questions are welcome as issues here without any of that.
If you own a click-wheel iPod, that is the most useful thing you can offer — more useful than code, and it usually takes an afternoon and no soldering. HARDWARE.md says which models help, what answering a question actually involves, and what will never be asked of you. Lending a device is not required; answering one question with it is the whole point.
The link above is the only copy of it in this project. If you find it written down anywhere else, that copy is the one that will go stale.
Other people's work made this possible, and some of it saved months. In rough order of debt:
pp5020.h and the iPod target code are
where most register semantics came from, and Rockbox was the oracle: a known-good OS to boot
when something broke and you needed to know whether it was you. If you want to understand this
hardware, read Rockbox first.sysinfo_t layout.dreamlayers, on the Rockbox forums in 2009, who identified vmcs.bin and the .vll
files as ELF DLLs loaded into the Broadcom chip. This project worked that out independently in
2026 and then found the post. Sixteen years early.If you want to give something back, give it to them. Rockbox has been maintained for twenty years by people who documented this hardware so anyone could use it, before there was an LLM to do the typing. If you still want to throw something at this one: ko-fi.com/siggifly — it goes on parts for oPod, the open player this is meant to run on when the hardware runs out.
I did not write a single line of code in this project. It was written with Claude Opus 5 under direction. What I did was steer: decide what was worth chasing, push back when an answer sounded too convenient, find the prior art that unstuck it, and say "that can't be right, look again". That is not nothing, and it is also not writing an emulator. I would rather say so than let anyone assume otherwise.
Part of the iPod Preservation Project — other arms are running games without RetailOS at all, presenting a virtual iPod to iTunes, and oPod.
GPL-3.0-or-later for the code, CC BY-SA 4.0 for research/. See docs/LICENSING.md.
Apple's firmware, NOR dumps, IPSW files and disk images are not covered, not distributed, and never
will be.
Hacker News (1)
Rust
91.4%
Slint
7.8%