CE Runtime Foundation v5.1 pre-alpha

A universal Windows CE emulator: a virtual hardware platform that boots real CE and Windows Mobile ROMs on modern Windows.

Warning

Early stage. There are some bugs and boards are just MVP implementations. Some boards lack proper clocks, timings, caches, etc. - take into account. Today this is rather proof-of-concept. Contributions are welcome!

Downloads

Download WIP build (5.1) from artifacts to use all the latest features or go to latest release

Supported boards

SoC	Board / OS	Features
Intel XScale PXA255 ARMv5TE	Falcon 4220 Windows CE .NET
	NEC MobilePro 900 Handheld PC 2000 Windows CE .NET
Intel SA-1110 StrongARM	HP Jornada 720 Handheld PC 2000
	iPAQ H3100/H3600/H3700 Pocket PC 2000 Pocket PC 2002
	Siemens SIMpad SL4 Handheld PC 2000 Windows CE .NET
	SmartBook G138 Windows CE .NET
Intel SA-1100 StrongARM	HP Jornada 820 Handheld PC 3.0 Professional
ARM720T ARMv4T	Microsoft Windows CE Hardware Reference Platform Windows CE 2.11 Windows CE 3
NEC VR5500 MIPS IV	NEC Rockhopper SG2_VR5500 Windows CE 6
TI OMAP 3530 Cortex-A8	OMAP 3530 EVM Windows CE 7
Samsung S3C2410 ARM920T	Siemens P177 Windows CE 5
	Device Emulator Windows CE 6 Windows Mobile 5 Windows Mobile 6 WM 2003 SE Windows CE 5
Freescale i.MX31L ARM1136	Zune 30 Windows CE 5

Usage

Tip

Stock touch input is misbehaving in some devices/requires some additional effort. If your clicks do not register, try holding the left button and wiggling the cursor a bit.

The easiest way to run CERF is launcher.exe - a GUI app shipped next to cerf.exe that downloads publicly available ROM bundles and boots them. Pick a device from the list, tweak launch options (resolution, logging, network) if you want, click Launch CERF.

For direct invocation without the launcher:

Command	Action
cerf.exe	Boot default device (cerfos)
cerf.exe --device=devemu_ce6	Boot specific device
cerf.exe --log=ALL	Enable every log channel
cerf.exe --flush-outputs	Force-flush logs (avoid truncation on crash, extremely slow)

Logs are written to cerf.log next to the executable. On a fatal crash, every other thread's register state and a top-of-stack snapshot is dumped to cerf.crash.log next to it. Run cerf.exe --help for the full CLI.

Note

cerf.log is quiet by default - only critical CERF / CAUTION lines are written. Pass --log=ALL (or a channel list, e.g. --log=BOOT,JIT,MMU) to turn channels on.

Guest Additions

Running ROM images (NK.BIN, etc.)

Important

CERF is not a "drop any CE ROM and go" emulator. It emulates a whole device - the SoC, the board wiring, the memory map (OAT), and every peripheral the ROM's drivers touch. A ROM only boots if that exact board has been implemented in CERF. A matching SoC is not enough: the same chip on a different board has different RAM/flash addresses, a different display controller, different GPIO wiring, etc., and the ROM will fail immediately without them. Random ROMs pulled from the internet will not boot unless their board is on the supported list.

Running a ROM for a board CERF already supports

Use launcher.exe - it downloads the right ROM bundle and boots it. That's the whole flow for normal use.

If you have your own dump for a board that's already supported (e.g. a different region/revision of the same device), drop it in by hand:

1. Create a folder under devices/ (next to cerf.exe), e.g. devices/mydump/.
2. Put the ROM image in it - any *.nb0 or *.bin; the filename doesn't matter, CERF auto-detects it.
3. Run cerf.exe --device=mydump.

No cerf.json is required for this - it's optional and only carries display metadata plus a few board overrides. (Multi-partition ROMs, configurable-resolution boards, and network tweaks are the cases that need one; see device_config.h for the schema.)

Bringing up a board CERF does not support yet

This is real emulator development, not a config tweak and not something you can hand to an AI and expect magic. The board's exact memory map (OAT), every peripheral its drivers touch, the SoC quirks - all of it has to be implemented in C++, correctly, by someone who understands the hardware. It takes real skill. There are two honest paths:

• Contribute a proper implementation. Do it right - the code quality bar is whatever CERF already ships, no lower. That means a correct OAT (not a reused one from another board with if cases bolted on), real per-board peripherals (not board-specific behavior stuffed into shared SoC code), and accuracy grounded in datasheets/BSP/RE - not values that happen to "work." Contributions below that bar create more debugging cost than they save and won't be accepted.
• Just submit the ROM. If you can't implement it yourself, share the dump and the board details. Maybe someone picks it up someday - no promises, no timeline.

CERF does ship a Claude Code dev environment and a /start-board-implementation skill that can assist a capable contributor (see Claude Development Environment below), but it is a tool for someone who already knows what a correct bring-up looks like - not a substitute for that knowledge.

Building

Requires Visual Studio 2026 with the C++ desktop development workload.

Note

First build on a fresh machine takes 1+ hour. vcpkg compiles dependencies from source before CERF starts linking. This happens once per machine - subsequent builds reuse the cached vcpkg_installed/ tree and finish in a few minutes. Do not interrupt the first build.

Initialise source/dependency submodules:

git submodule update --init --recursive

Build via the helper script:

powershell -ExecutionPolicy Bypass -File build.ps1

Or invoke msbuild directly:

msbuild cerf.sln /p:Configuration=Release /p:Platform=Win32

Changelog

CERF Version	Changes
v5.1 (NOT RELEASED YET)	NEC Rockhopper SG2_VR5500 (MIPS) support Ford SYNC 2 support CERF/Launcher UI/UX improvements Added tools\fileserver.py in build directory (simple directory serving web server) Microsoft Reference Platform: added full PS/2 key mapping set
v5.0	iPaqs now use original .nbf format instead of normalized .nb0. Upgrade bundle in launcher! New boards booting: Jornada 820, Siemens SIMpad SL4, Siemens SIMATIC HMI TP 177B, NEC MobilePro 900 Series, SmartBook G138 Experimental hibernation/state saving system for all boards Added HP Palmtop VGA (F1252A) card Soft/hard reset fixes for some SoCs UI refresh/updates for CERF and launcher PC Cards: Serial modem emulator and serial forwader Added Keyboard mapping window for boards with keyboard Guest additions: DDraw export (now Zune and friends render, but might be broken in some cases) Guest additions: IMGFS injection fixes (e.g. WM >= 6) Guest additions: change resolution on Windows CE 3 at runtime with soft reset Guest additions: XIP injection improvements Guest additions: Keyboard support Guest additions: Windows CE 2.11 support Guest additions: DPI support SA-1110, PXA255 RTC implementation Falcon 4220 main battery wiring (fixes the idle suspend problem) Suspend feature support for different SoCs Ipaq 1st gen: microphone support ce_apps/xplorer.exe - dependency-free minimal shell, CE2+, useful for Zune 30 GA mode
v4.0	NE2000 is now hot pluggable in all boards that support PCMCIA Compact Flash too with configurator/generator iPaq 1st gen now has extensions sleeve emulated (for PCMCIA support) iPaq H3100: monochrome screen inversion fixed Soft/hard reset your device in Actions menu (might be broken for some SoCs) + corresponding SoC/peripheral updates Guest additions: task manager on host - see process list, switch to processes, kill and run right from HOST window NE2000 internet delivery hangs are fixed Jornada720/SA1110/JIT updates to make it boot Linux-based OS Launcher: optional packages feature Guest additions: Complete overhaul of XIP injection (Now you can boot Jornada 720 in 4K. Also suddenly Zune 30 is in the game too) Various UI/general fixes, improvements
Previous versions - see the full changelog.

Known Issues

See launcher's boards details database for per-board issues.

Claude Development Environment

Caution

DO NOT USE CERF CODEBASE AS REFERENCE FOR SoCs, BOARDS, PERIPHERALS - AI WRITTEN CODE CAN'T BE TRUSTED!

100% generated by Claude via Claude Code - no human-written code. Not production-grade.

---

CERF ships a Claude Code-based development environment for working on the emulator - including bringing up brand-new boards from their ROMs. Launch it from the repo root with:

run_claude.cmd

It runs Claude Code with a custom system prompt that injects the entire project documentation (CLAUDE.md plus every agent_docs/ reference page) into every agent, so each session starts fully briefed on the project's rules, architecture, and subsystems - no "please read the docs first" needed.

The environment provides the /start-board-implementation skill: drop your ROM into bundled/devices/ (or just point the agent at it) and run the skill. The agent identifies the board and SoC straight from the ROM, checks what CERF already supports, estimates the effort, and - on your go-ahead - starts the bring-up with a cross-session tracking document. So you can literally drop in your ROM and start the procedure of bringing it up.

Warning

The dev environment runs Claude in skip-permissions mode - it can execute anything on your machine without prompting. It also force-kills its own Claude instance, and any clangd.exe, that leaks memory past a threshold. The first launch shows a one-time explanation; press Enter to acknowledge it.

Third-party / Credits

• QEMU
• The Linux kernel
• nlohmann-json
• libslirp
• JIT studied/inspired by Microsoft's Device Emulator (Shared Source Academic License, 2006)