Quick followup to the following thread I had posted a few months ago:

https://www.reddit.com/r/EmulationOnAndroid/s/CwOYiQFBTt

Just wanted to say I am still working on this project, even if a bit slowly. It's proving to be much bigger than I thought. Here is my small website in case you'd like to check on the project progress every now and then (to be expanded).

Leave a nice comment or a donation on the website or anything if you like what you see :)

github.com/siggifly/ipod-emulator

Apple's retail iPod 5.5G firmware boots on an emulator I have been building for four days. It formats its own filesystem, reads the click wheel, draws its own menus, and runs Brick.

https://i.redd.it/jxyu7lp3odjh1.gif

The 5.5G shipped on 12 September 2006. I bought one that year, at twelve, and it was the first Apple product I ever owned.

I chose this model deliberately, because it is the one every clickwheel game runs on. That it is also the one I grew up with is a coincidence I have enjoyed more than I expected: my first Apple product, now running on a MacBook Air M4, twenty years later.

Working at Apple was always the dream. Having now spent four days taking their firmware apart, I have no idea whether that brought it closer or ruined it, and I find that funny either way.

What it actually is

Not a reimplementation of the interface. Apple's own code the whole way down.

The emulator enters at address 0, where the CPU fetches out of reset. Apple's bootloader brings up SDRAM, talks to the power chip over I2C, uploads firmware to the video co-processor, reads the partition table, DMAs 7.5 MB of RetailOS into memory, checksums it and jumps. RetailOS then remaps memory, starts its RTXC kernel and 61 tasks, mounts a FAT12 volume hidden inside the firmware partition, formats and populates its own FAT32 volume, spins the drive down, and draws.

Then you scroll to Extras, open Games, and play.

https://i.redd.it/4wma2f58odjh1.gif

There is a window too — a drawn iPod whose wheel, buttons and hold switch drive the machine, with a debug mode that shows instruction counts, both clocks, and a does the input reach RetailOS? panel carrying arrival counters at the real addresses. It proves its own claim rather than asserting it.

https://preview.redd.it/ks4euy0eodjh1.png?width=2940&format=png&auto=webp&s=8ceaada6695d0836a72585cda58fb2078b216410

Before anything else: I did not write this

I am not an engineer. I am a tinkerer, and I did not write a single line of code in this project.

It was written with Claude Opus 5 over four days. The model wrote all of it and did the reverse engineering: bisecting a boot to the exact instruction where a function stops returning, reading forty instructions of ARM to recover a structure layout, running the same experiment four ways to check a result held.

What I did was steer. Decide what was worth chasing and what was a rabbit hole. Push back when an answer sounded too convenient. Come up with ideas when it got stuck, which happened plenty. Go find the prior art that unstuck it. Say "that cannot be right, look again" — which was worth more than it sounds, because a confident wrong answer costs hours and sometimes only a human going hang on catches it.

That is not nothing. It is also not writing an emulator, and I would rather say so than let anyone assume otherwise.

Why

Apple sold 54 clickwheel games and delisted them in 2011. For years, if you had not bought them then, that was that.

Olsro's Clickwheel Games Preservation Project changed that, and it is why I got interested. It preserves the games and works out the authorisation. I used it on my own iPod last year and left it there.

The catch is that it needs the hardware, and a used 5.5G in good condition is not cheap now. So the games are being looked after while the machine they need gets scarcer. That seemed backwards.

I was also abroad on holiday with my iPod at home, which ruled out the obvious approach. And I had just seen someone running Tahoe 26.5's kernel natively on a Galaxy A55 a few days earlier, which is most of the reason I tried at all.

Four days, roughly

Day 1 — my iPod was at home, so the first problem was having anything for iTunes to talk to. That worked the same night: a virtual iPod that iTunes accepts as a real device, with the USB identity rebuilt out of real firmware artifacts. (The Palm Pre did something similar in 2009 and Apple kept breaking it until Palm gave up. It stuck with me as proof the idea was possible.) The ARM7TDMI core was written the same day — about 1,900 lines, zero dependencies.

Day 2 — the disk. RetailOS will not finish booting until it can write, which I had not allowed: it blocks on a one-sector write, times out after 3.9 simulated seconds, and retries forever. A read-only disk looks exactly like a deadlock and is not one.

Day 3, 02:06 — Apple's bootloader loaded RetailOS, verified it, and handed over. 02:16 — I set up a headless Ghidra server. That ten-minute gap is the whole story of the day: until then most questions could be answered by running the thing and watching, and once RetailOS was booting and then halting somewhere inside itself, they became "what calls this", which does not yield to watching.

Day 4 — the display, which was the hard part and has its own section below.

Full timeline with commit counts: docs/HOW-IT-WAS-BUILT.md

The display, and the thing I would tell you if you only read one part

The iPod 5.5G has a Broadcom BCM2722 next to the PortalPlayer SoC. Rockbox treats it as a framebuffer — write pixels, kick an update. RetailOS does not. It reads a service directory out of the co-processor's memory, binds an RPC channel, creates a layer, and uploads dirty scanlines to a surface. None of that is documented anywhere I could find.

What cracked it: the resource volume on the iPod's own disk holds the co-processor's firmware and a library of .vll codec plugins, and those plugins are ordinary ELF shared objects — e_machine = 0x5f, EM_VIDEOCORE, an officially assigned ELF machine number. Standard tooling reads their symbol tables, and their undefined symbols are by definition what the co-processor's runtime exports. All 183 of them, including dispman_object_create, gencmd_register, and 25 Nucleus PLUS internals.

dispman_* is DispmanX — the same display manager Broadcom would later ship on the Raspberry Pi. The later chip is publicly documented and the concepts carry.

I never emulated the VideoCore. The transport layout came out of RetailOS's own parser, on the principle that code which reads a structure is a specification of that structure.

The whole thing is written up here: research/21-the-videocore-runtime.md

A small one, afterwards

Once RetailOS was drawing, the boot still opened on a black screen with what looked like diagonal noise. That frame had been dismissed twice as fragments. It was the Apple logo — sitting in the co-processor's buffer since the very first run at 62-halfword pitch, waiting for a rectangle placement the model never executed. A 62-pixel-wide logo in a buffer being read 320 pixels wide. The fix was to stop looking at the panel in screen order and look at it in address order.

the Apple boot logo · write-up

What does not work

• No audio. The Wolfson codec is unmodelled.
• 30% of real time headless, 19% with the window open. A JIT is the answer and is not written.
• Purchased titles do not launch. Apple's DRM refuses them. The identity it binds to is understood — the FireWire GUID, not the serial — the keystore is not.
• Four values in the co-processor transport are chosen rather than measured, and there is no timing model, so a bug that only appears when a reply is late is invisible to me.
• The boot takes ~300 seconds of simulated time where hardware takes five or ten. Something waits far longer than it should and I do not know what.

Everything faked has a row in a ledger with a written condition for retiring it. Nothing is faked without one: research/12-bypass-ledger.md

Where it goes

Running the games with no RetailOS at all is the real goal — host the framework yourself and you do not need Apple's OS in the loop. I did not know what that framework did, and there are around 98 entry points. Booting RetailOS is how you find out, because Apple's implementation of it is inside.

Then audio, a JIT, and eventually every non-iOS iPod. I picked the 5.5G because it is the superset: 14 of the 54 titles are iPod Video exclusives and do not run on a Classic at all.

Credit

Rockbox first and by a distance. pp5020.h and the iPod target code are where most of the register semantics came from, and it doubled as an oracle — a known-good OS to boot when something broke and I needed to know whether it was me. iPodLinux underneath it.

dreamlayers, who identified those .vll files as ELF DLLs on the Rockbox forums in 2009. I worked it out independently and then found the post, sixteen years late.

Also Olsro, daniel5151/clicky (which independently needed the same two undocumented register bits), freemyipod and q3k's wInd3x writeup, qemu-ios, giek2000, Xlinka, dstaley, raspberrypi/userland, and the Internet Archive. The full list, with what each one gave, is in the repo and it is longer than this.

If you feel like giving money, give it to Rockbox or to Olsro before me. Rockbox has been documenting this hardware for twenty years so that anyone could use it. Olsro spent a year working out the authorisation so the games could be played again at all, and without that I would never have started.

Download zuco8:
https://github.com/cherepets/zuco8/releases

Games:

- Ninja Cat by cubee
https://www.lexaloffle.com/bbs/?tid=38451

- Hungry Harry 3D by paloblancogames
https://www.lexaloffle.com/bbs/?tid=59509

- The Lion King Tribute by AuryArthan
https://www.lexaloffle.com/bbs/?tid=149613

- Pico Fox by electricgryphon
https://www.lexaloffle.com/bbs/?tid=28067

Music:

- Overgrown Labyrinth [Loop] by Visager [CC BY-SA 4.0]
https://visager.bandcamp.com/

The project is not affiliated with this Lexaloffle - developer of PICO-8.

Get official PICO-8 on https://www.lexaloffle.com/pico-8.php

I created 20 emulators for machines that are dear to me.

The main goal was to create emulators that work both on PC and mobile devices, with keyboard and CRT simulation.

The cores are my own development, so they do not use external assets or emulation libraries. This means that emulation is not perfect. Hopefully good enough to run most "normal" software and games.

Made a short article about some observations/things that I left out of my recent ARM64 optimizations on RPCS3 video. Let me know what you think!

I wrote an emulator for the USSR Iskra 226 and brought some software to life
Here is the story, code is on GitHub.

https://elaranovikova.com/projects/iskra-226/

I recently shipped the first emulator for the Iskra-226, the Soviet work-alike of the Wang 2200. Unusual constraints compared to a typical emu project, so I thought the approach might interest people here:
No firmware execution. I don’t have a clean dump and the processor isn’t emulated. Instead I built an interpreter for the machine’s tokenized BASIC dialect, a “reader for a language and something to carry it out.” That was enough to get 23/23 programs on my reference disk loading and running (counted off the catalog status byte, not eyeballed).
Token archaeology. The dialect is Wang-2200-adjacent but not identical. The breakthrough came from staring at the token stream until I stopped asking “which Wang token is this” and started asking what the bytes were doing on their own terms. Once the tokens came apart, the whole dispatcher fell into place in a few hours.

Disk forensics. The boot side isn’t in any catalog I could find, and carries the same firmware image written four times over. Cross-comparing the four copies is how I ended up with a file I trust.
Validation by pencil. My end-to-end test was a 1989 payroll program: I fed it invented numbers I could verify by hand, and the emulator’s printed wage sheet agrees with my paper arithmetic to the kopek.
Ternary bonus round. Next project is a Python port of the Setun (1958), the only ternary computer ever built serially, currently checked against the reference implementation for 550,821 steps without a divergence.

Browser emulator + 14 disk images:

https://elaranovikova.com/projects/iskra-226/index.html

Code:

https://github.com/elaranovikova

AMA about the format, the tokenizer, or reading 8-inch media in 2026.

A DSL is a Domain Specific Language which means a programming language made to solve specific type of problems, think SQL for databases and HTLM for websites.

I've recently dug into emulation development and there's a lot of overlap between how I approach different machines since the same type of components are often used.

Almost all emulators seem to be developed in isolation when in reality they sometimes share exact specifications like CPU's for instance. And even where they differ, their interface often overlap with e.g. load, alu and jump instructions.

I'm doing my Master's in Computer Science in a few years and I thought that creating a general Emulation DSL could be something to look into. By defining a standard framework for all emulators we could build emulators faster, easier and make them more accurate by abstracting/letting the language solve the small quirks like clock cycles etc.

My question is how much of this is already been looked into, if anyone has tried or maybe even just defined a general framework for emu development?

Thank you

This started as a debugger for my own PS1 games and grew from there, posting it because the debugging side is probably the interesting bit for the community.

Easiest way to try it is in the browser, press "Run" on the itch page and it comes pre-loaded with the PSoXide Demo Disc (you don't need a PS1 BIOS for it), which includes ten of my homebrew programs off one disc: https://bonnie-studios.itch.io/psoxide

Some of the goodies:

• Freecam on L3+R3. Detaches the camera and lets you fly around while the game keeps running underneath you.
• Wireframe toggle.
• RAM visualiser: In CB1 specifically you get a nice live view of the level streaming off the disc into RAM as you walk.
• VRAM visualiser: both framebuffers, and the textures popping in during load screens.
• Frame profiler, so you can see where the console actually spends its time.

Plus the usual: xBR filtering, PS1-native or screen-native resolution, save states, remapping. Crash Bandicoot is the guinea pig for all of it in the video.

Worth saying: I built this to develop and debug my own games, so it's aimed at hardware accuracy rather than running everything. I've done limited testing with commercial titles so expect that some won't boot, the ones that do get all the toys above though. Bring your own legally obtained BIOS and your own dumps and it'll load discs straight from a folder on your drive.

The emulator is one part of PSoXide, an open-source PS1 dev suite: emulator, SDK, engine, editor: https://github.com/EBonura/PSoXide. All developed with substantial AI assistance, with me directing the architecture, the debugging and the hardware verification.

It all exists because I'm making a souls-like for the PS1 and kept hitting tools that didn't exist yet, each one I build ends up improving the stack all my games share.

Hope you enjoy! Feel free to ask any question!