oldmanrukus.com /home SYSTEM ONLINE
[ OK ] toolchain: sh-elf-gcc · mips · m68k · 6502 · h8/3002
[ OK ] targets: win64 · linux · dreamcast · gba · n64
[ OK ] 7 titles recompiled to native code
[ .. ] portfolio // rev 2.0 — ready_

I take games off dead hardware and make them native code.

Static recompilation, console porting, and the infrastructure underneath it. I translate original machine code — MIPS, 68000, SH-2, 6502, H8 — ahead of time into C and C#, write the hardware layers those games expect from scratch, and ship them as executables that run without an emulator. Twenty years of systems and network engineering pays the rent; this is what I do with the rest of it.

7
Titles recompiled
6
CPU architectures
9
Platforms targeted
2
Tours in Iraq
6
Kids
01 // recompilation

Six titles, five instruction sets, no emulator in the loop.

Static recompilation is not emulation. There is no interpreter and no JIT at runtime — the original machine code is translated ahead of time into C or C#, compiled with the rest of the program, and executed directly by the host CPU. What that buys you is the real game, running as a native binary, open to modern framerates, widescreen, netplay and rewritten subsystems. What it costs you is that every piece of hardware the game expected has to be written by hand, and every wrong assumption shows up as a crash three million instructions later. Each entry below is honest about where it actually stands.

R-01

Tekken Tag Tournament

Namco System 12 arcadeWindows x64 native
PLAYABLE
Tekken Tag Tournament running as a native Windows executable — Eddy versus Paul, full HUD and stage geometry
Live match — Eddy vs Paul, running as native x64 code at a flat 60 fps
Tekken Tag Tournament title screen in the recompiled build
Attract sequence / title
Tekken Tag Tournament character select grid with correct portrait CLUT decoding
Character select — after the CLUT-Y fix
Tekken Tag Tournament versus screen
Versus screen

The largest of the six. System 12 has no BIOS, no CD, no SPU and no pads — so alongside the recompiled MIPS I had to build the board itself: the ROM bank window, Namco's ROM-DMA channel, the KEYCUS protection chip, and an H8/3002 sound sub-CPU driving a 32-voice C352 PCM chip. An instrumented MAME served as a bit-exact oracle so every subsystem could be proven against real behaviour rather than eyeballed.

Source
Sony CXD8661R (MIPS R3000A + GTE) · CXD8654Q GPU · Hitachi H8/3002 @16.9344 MHz · Namco C352 @25.4016 MHz
Approach
Static recompilation, MIPS → C# via RecompOne, with a hand-built System 12 hardware layer
Oracle
MAME 0.264 instrumented with Lua taps for bit-exact comparison
Ships as
Single-file TekkenTagTournament.exe + pak · keyboard, XInput and DirectInput
// engineering log
  • Five separate crash addresses were one bug. All of them resolved to a 46-entry fighter-state jump table at 0x800104FC indexed by [S1+0x156]. Rather than assume the base, I confirmed it against six already-resolved switch cases before declaring the 39 targets.
  • The performance metrics were lying. guestFps, pumpHz and presentFps all read counters the port itself drives, so they cheerfully reported 60 while the game actually ran at 12. gpuDmaHz was the one honest number, and it exposed an exact 5:1 vsync lock that was also starving the AI.
  • Protection chip solved arithmetically. The "exploded fighter" corruption came down to a single missing halfword from the KEYCUS chip; the constant 0x2651 was derived from two table entries rather than brute-forced.
  • GPU decode corrected against real hardware: texture-page Y is two bits on this GPU, and CLUT Y is ten bits with bit 15 as the high bit — which is what finally made the portrait grid render.
  • Audio built from nothing. The H8/3002 core ran 1.77 billion instructions with zero unimplemented opcodes. SHAR was doing a logical instead of an arithmetic shift, and the C352 loop/reverse flag mapping was proven correct by a 979-key-on census instead of being swapped on a hunch.
  • ROM-DMA made bit-identical to MAME across all 84 transfers.
78.8%
Statically recompilable with zero title-specific work
2,305
Functions recompiled
60.0 fps
Flat, worst frame gap 44 ms
1.77 B
H8 instructions, 0 unimplemented opcodes
917,000
Polygons in a single 170 s deterministic run
84 / 84
ROM-DMA transfers bit-identical to MAME
Where it actually stands Boots the full attract sequence, takes a coin, and plays a real match with HUD, timer and audio at a flat 60 fps. It still hard-crashes on undeclared function-pointer targets during extended play, an interrupt-delivered-mid-instruction bug fires roughly once every 2.5 s (absorbed, not fixed), and character-select music loops wrongly.
R-02

Wu-Tang: Shaolin Style

Sony PlayStationWindows x64 native
PLAYABLE
Wu-Tang Shaolin Style recompiled — RZA versus Inspectah Deck in a live match
Live match — RZA vs Inspectah Deck, widescreen
Wu-Tang Shaolin Style character select screen
Character select
Wu-Tang Shaolin Style title screen, press start
Title — press start
Wu-Tang Shaolin Style attract mode demo fight
Attract-mode demo fight

A two-stage boot — the front-end binary LoadExecs the real game — on top of an overlay-banked architecture where thirteen character overlays all live at the same address. An earlier C++ attempt had to be abandoned outright because it had no overlay-banking subsystem, which this game cannot run without.

Source
MIPS R3000A · 16 overlays, 13 character overlays sharing one bank
Approach
Static recompilation, MIPS → C# via RecompOne; HLE'd PsyQ/BIOS plus low-level GPU, SPU, MDEC and CD hardware
Ships as
Self-contained WuTangShaolinStyle.exe + pak · keyboard and gamepad · CD-DA music · widescreen
// engineering log
  • The fatality freeze was an interrupt that never arrived. Only VBlank was being dispatched — IRQ 2 (CDROM) never fired. Since the game ships its own interrupt-driven CD driver, an INT2 sat behind an unacknowledged INT3 forever while CdSync spun at roughly 40 million polls per second.
  • Every signed 8- and 16-bit value in the game was wrong. A global sign-extension bug in the toolchain emitted LH/LB zero-extended, so a -999 sentinel scan never terminated.
  • Two codegen fixes upstream in the recompiler: fall-through-after-jal (functions ending in a call were treated as tail calls, so registers were never restored) cleared 22 landmines; jump-table detection rebuilt on the sltiu bound promoted 343 out-of-boundary targets.
  • A shared-bank cross-binding trap: thirteen character overlays at one address were silently binding to each other's symbols — fixed with union entry points.
  • Save system reverse-engineered around a broken loader. The game's entire persistent record turned out to be one flat 1,172-byte block, found by tracing mirrored memcpys, and is now shipped directly rather than through the memory-card path.
2,074
Functions, up from 1,211 — 863 recovered by jump-table extraction
5,313 → 0
VSync timeouts
45,000 → 0
Sector-error retry spins after whole-sector CD reads
1,172 B
Save record located and reimplemented
Where it actually stands Practice and full Versus matches are playable end to end with gamepad, CD-DA music, sound effects and widescreen; fatalities and story mode work. The pause screen renders badly magnified, in-game FMVs never play, and memory-card loading is still unfinished (saving works).
R-03

Virtua Racing Deluxe

Sega 32XWindows + Sega Dreamcast
PLAYABLE
Virtua Racing Deluxe recompiled, 3D race in progress at Big Forest
Big Forest — native, no emulator
Virtua Racing Deluxe driving across the bridge at 223 km/h
Bay Bridge at 223 km/h
Virtua Racing Deluxe course select screen
Course select
Virtua Racing Deluxe running on the Dreamcast build
Dreamcast build (KallistiOS / SH-4)

The 32X is three CPUs at once — a Genesis 68000 plus master and slave SH-2s talking over a mailbox. This one is recompiled by two translators I wrote from scratch, roughly 1,600 lines of Python that decode each opcode straight out of the retail ROM and emit equivalent C. Game data is read from the original ROM at its original offsets and never re-authored.

Source
Motorola 68000 + master SH-2 + slave SH-2 · 4 MB retail cartridge
Approach
Static recompilation via home-grown m68k_recomp.py and sh2_recomp.py; portable-C runtime models both address spaces, the COMM mailbox, both VDPs and a three-CPU scheduler
Oracle
Instrumented PicoDrive for frame-for-frame COMM timeline comparison
Ships as
VirtuaRacingDeluxe.exe (ROM embedded) and a Dreamcast .cdi
// engineering log
  • The boot blocker was one register write. A single clobber of the $A15104 bank register corrupted the tile decompressor and swept 64 KB of work RAM. One line, and the first real frame appeared.
  • The oracle reframed a "hang" as impatience. Comparing against instrumented PicoDrive proved the recompilation's COMM timeline matched hardware exactly — we had simply been stopping at frame 320, and rendering starts at 428.
  • Rewrote the compositor as a scanline-accurate Genesis VDP — per-line and per-cell scroll, window plane, true priority order, sprite line limits, shadow/highlight — in pure integer C99, so it drops into the Dreamcast build unchanged. A 26-frame A/B was byte-identical on every attract and menu frame.
  • Recovered the SH-2 vector tables and implemented interrupt delivery for both cores.
  • Full audio chain brought up and then made cheap: Z80, YM2612, PSG and 32X PWM went from 1.26 ms to 0.10 ms per frame — a 12× win that put audio at 0.6% of the frame budget.
  • 60 fps speculative frames: measured, then rejected. Bisecting the interpolated scene words down to the strip-descriptor tail cut the bail rate from 21% to 0.4% — and I still shipped it off by default, because side by side it looked worse than the authentic 20.
99.74%
68000 translator coverage
99.33%
SH-2 translator coverage
~1.9 B
Instructions across three CPUs per 240 frames
12×
Audio cost reduction, 1.26 ms → 0.10 ms per frame
Where it actually stands The PC build boots, renders and plays through attract, mode/car/course select and racing at the authentic 20 fps with audio and gamepad support. Deeper modes such as grand prix progression are untested, and the Dreamcast build boots in Flycast with no audio and unmeasured performance on real hardware.
R-04

Tecmo Super Bowl 2026

NES / MMC3Windows + Dreamcast + Game Boy Advance
SHIPPING
Tecmo Super Bowl 2026 widescreen field reconstruction, play in progress
Widescreen Hor+ field reconstruction — more field than the NES could ever show
Tecmo Super Bowl play call screen with the first down line
Play call with broadcast first-down line
Tecmo Super Bowl 2026 title screen
Title
Helmet comparison between 1991 and 2026 rosters
1991 vs 2026 helmet sets
All 256 generated player faces
All 256 player faces

The most complete of the six, and the one that is quietly turning into something else. The 6502 is translated ahead of time into C, and the NES hardware it depends on — PPU, APU, MMC3, DMC samples, controllers, battery save — is hand-written from scratch with no third-party emulator code. On top of that, a migration layer is progressively replacing recompiled subsystems with idiomatic C, oracle-tested bit-identical against the original: a recompilation slowly becoming a decompilation.

Source
MOS 6502 · mapper 4 (MMC3) · 256 KB PRG + 256 KB CHR, battery save
Approach
Ahead-of-time 6502 → C translation, no interpreter and no JIT; clean-room NES hardware; progressive C migration under oracle test
Ships as
Windows .exe (primary), Dreamcast .cdi, Game Boy Advance .gba with SRAM save, plus a plain .nes
Beyond the original
Two-point conversions, widescreen Hor+ field, TV broadcast layer, SPC700 + S-DSP sound core, real weather, roster/team/face editors, netplay
// engineering log
  • Correctness proven, not assumed. 200 million instructions of lockstep against a clean-room 6502 interpreter with zero divergence and zero unknown-target traps, plus an 8,200-frame scripted regression — boot through touchdown — reproducing byte-identical frames. The console builds match the x86 reference exactly.
  • Four optimisation rounds took the GBA from 26.8 to 42.9 fps — hardware PSG standing in for the NES APU, hot code in IWRAM, register-resident 6502 state, and an ARM/Thumb interworking veneer that alone was costing 27 scanlines a frame.
  • Killed the NES 8-sprites-per-line flicker at the source. Per-down dropouts went from 1,875 to 0 across 400 frames; on-screen figure-count swing fell from 2.7 to 0.09.
  • Runs the SNES game's real sound program. An SPC700 + S-DSP core sits inside an NES title, playing the actual sequence data.
  • The broadcast layer was measured, not eyeballed: the first-down line lands within 2 px on 98.6% of readings, and 25,373 down-and-distance comparisons produced zero disagreements.
  • 1991 rosters verified against an original cartridge — 8,232 fields, no differences.
200 M
Lockstep instructions, zero divergence
8,200
Frame golden run, byte-identical
42.9 fps
Game Boy Advance, up from 26.8
59.8 fps
Dreamcast, with 34% idle headroom
1,875 → 0
Sprite dropouts per down
8,232
Roster fields verified against cartridge
Where it actually stands The Windows build is the actively shipped product and iterates near-daily — it boots, plays, saves, and carries netplay plus a large original feature layer. The GBA build runs at 42.9 fps rather than 60, the Dreamcast build has only ever been tested in Flycast rather than on real hardware, and the Windows executable itself has been verified under Wine.
R-05

NFL Blitz 2026

Nintendo 64Linux x86-64 native
HEADLESS — RUNNING, NOT YET DRAWING

Built on the NFL Blitz 2000 engine, and the hardest of the six to even begin: the cartridge ships no ELF and no symbol table. Function discovery and libultra identification had to be done from raw disassembly by a tool written for the purpose. It now boots, schedules, DMAs and emits display lists — but the renderer is still a null context that counts those display lists and throws them away, so nothing has been seen on screen yet.

Source
MIPS R4300i · libultra · F3DEX/F3DLX.Rej microcode · 16 MB big-endian cartridge
Approach
Static recompilation via N64Recomp + N64ModernRuntime, with a custom symbol-recovery tool built on raw disassembly
Oracle
Instrumented mupen64plus with PI DMA and VI logging
Ships as
Native Linux x86-64 executable, ~3.5 MB — headless, built and run on a remote build box
// engineering log
  • A whole-game deadlock traced to one unnamed function. Every guest thread was parked in osRecvMesg. The culprit was osPiStartDma under a native PI manager, blocking the segment-2 DMA that everything else was queued behind.
  • Found a self-referential thread queue in the runtime. osStartThread on an already-runnable thread made the node point at itself — 4,104,320 queue entries observed before a dedupe guard fixed it.
  • Corrected an address-space assumption in librecomp: it assumed ROM is contiguous in RAM, but Blitz lands its code roughly 2 MB away from where the functions were registered.
  • Identified and named 61 libultra functions purely by disassembly across VI, PI, SI, AI, SP and RDP, threads and message queues — including the o32 trap where a u64 parameter consumes an aligned register pair and shifts the whole argument list.
  • Two upstream-worthy N64Recomp patches and a cop0_status_write fix where an unhandled CU1 bit was calling exit(1).
  • Proved the 30 fps cap is by design, not performance — doubling the emulated VI rate still yielded exactly 30 swaps per 60 VI.
1,258
Functions recompiled across 28 translation units
474
Symbol names recovered with no symbol table
70 s
Continuous run, no crash
4.1 M
Bogus queue entries from the self-reference bug
Where it actually stands It boots, runs its scheduler, DMAs its segments, drives audio and emits display lists at the native 30 fps for 70 seconds without crashing. It is still headless — the frontend is a null renderer, so there is nothing to screenshot yet. 22 auto-stubs remain unverified.
R-06

Mega Man Legends

Sony PlayStation.NET 10 native
IN PROGRESS — BOOTS, STALLS BEFORE GAMEPLAY

The most recent, and the clearest illustration that "it runs" and "it plays" are different milestones. It boots the front-end stub, performs the LoadExec, banks the real game over the top, runs its startup and reaches the true main loop at a steady 60 Hz driving GPU, SPU and DMA without crashing — and then waits forever on a single queued work item that nothing ever dequeues.

Source
MIPS R3000A · two-stage boot with a banked main executable · 247 files across a 404 MB disc
Approach
Static recompilation, MIPS → C# via RecompOne, with a hand-built HLE'd BIOS, interrupt chains, threading and an overlay dispatcher
Oracle
Instrumented PCSX-ReARMed with custom page-execution and CD-DMA logging plus scripted pad injection
Ships as
Native .NET 10 binary, running headless on Linux
// engineering log
  • The port was deadlocking against itself. VBlank only ticked when the game called VSync — and this game waits for vblank without calling it. Fixed with a host-time 60 Hz pump polled from the memory-access path, so it runs on the guest thread rather than mutating CPU state from a timer thread.
  • ChangeTh was case 0x10: break; — a no-op. No thread the game opened had ever actually run, and this game runs its entire main loop inside one.
  • A one-sector decode misalignment meant the recompiler was treating the 2,048-byte executable header as code. Every instruction was plausible, and every one of them was wrong.
  • Implemented real interrupt status/mask handling and chain walking across four priority chains; before that, every handler the game registered was unreachable.
  • Built three debugging tools that all exploit the fact that memory access happens on the guest thread — a live recompiled-callstack sampler, a write watchpoint, and an indirect-call tracer. The tracer is what proved the queue module is never dispatched at all.
  • Solved overlay load addresses statically by clustering call targets and matching content byte-exactly — two independent methods that agreed.
11,746
Functions emitted across 45 source files
60 Hz
7,200 vblank ticks in 120 s — exactly on rate
9
Distinct bugs found and fixed
0
Indirect calls into the dispatch region in 90 s — the smoking gun
Where it actually stands Boots, banks, and reaches the real main game loop at a steady 60 Hz with no crash — but stalls at state 0. There is no gameplay and nothing rendered yet; the dispatch layer is provably dormant, which is at least a precisely located problem rather than a vague one.
02 // ports, emulators & homebrew

The rest of the workbench.

A seventh recompilation still in flight, an arcade emulator built for hardware that has no business running it, and one small fighting game rebuilt in C and pushed onto seven consoles.

R-07

Eternal Champions: Challenge from the Dark Side

Sega CD / Mega-CDWindows + Linux native
IN PROGRESS — BOOTS TO VS SCREEN
Eternal Champions title screen and main menu in the recompiled build
Title and main menu
Eternal Champions player select screen with character portraits
Player select — after the read-modify-write fix
Twelve-frame contact sheet of the Eternal Champions intro cinematic proving frame-to-frame motion
Intro cinematic — twelve-frame contact sheet showing real frame-to-frame motion

A Sega CD title is two 68000s at once — the Genesis main CPU and the Mega CD sub CPU — talking through a gate array and fighting over shared Word RAM. One code generator serves both; the emitted C is identical, with per-unit macros binding the registers and address space. Adding the second CPU cost almost nothing, which is the entire argument for doing it this way.

Source
Dual Motorola 68000 (Genesis + Mega CD sub) · Genesis VDP · RF5C164 PCM
Approach
Ahead-of-time static recompilation — every reachable 68000 basic block becomes a native C function; no interpreter, no dispatch loop. Computed jumps recovered by trace-guided seeding.
Ships as
Static Windows x64 executable (~58 fps) and a native Linux build. A Dreamcast port is designed but not built.
// engineering log
  • Word RAM banking was the gate to the first frame. Implementing real 1M/2M banking took VRAM from 18,119 to 61,522 bytes written and CRAM from 0 to 58 — the difference between a black screen and a picture.
  • A systematic bug hiding in every read-modify-write instruction. Post-increment and pre-decrement addressing were being applied twice and stored to the wrong address. Fixed at eight sites; regenerating six modules changed five emitted lines and took the allocator's failure count from 17 to 0, which is what unblocked character select.
  • An overlay slot collision had the intro looping forever on a 512-frame cycle — two different overlay files load at the same address, so dispatch had to become bank-aware.
  • Mega CD hardware modelled from evidence, not guesswork: CD-BIOS high-level emulation, gate-array communication with correct per-CPU bit ownership, and the PCM window.
  • Full VDP Mode 5 renderer — planes A and B with priority, scroll, and the sprite link list — plus a regression harness that diffs a behaviour signature against a blessed baseline.
79,407
Disc sectors read on a normal boot
400 M
Blocks executed with zero traps on either CPU
61,533
Of 65,536 VRAM bytes exercised
~58 fps
Windows build
Where it actually stands Boots cold, plays the intro cinematics, and walks title → main menu → player select → versus with zero traps on either CPU. There is no audio at all, and it stops at an untranslated module before the match itself — four more overlays away from a fight.
E-01

ZNDC — arcade emulation on a stock Dreamcast

Sony ZN-1/ZN-2 · Namco System 11/12Sega Dreamcast (SH-4)
RESEARCH — HEADLESS HARNESS
VRAM dump from the ZNDC headless harness showing decoded stage textures and character sprites
VRAM dump — stage textures and sprites decoding correctly
Second ZNDC VRAM dump showing the frame in progress
VRAM dump — frame in progress

The opposite problem from a recompilation: here the guest code is not known ahead of time, so the PS1's MIPS CPU is dynamically recompiled into SH-4 code at runtime and the PlayStation primitive stream is handed to the Dreamcast's PowerVR2 instead of being software-rasterized. It is the piece of work I learned the most from and the one furthest from done.

Architecture
PS1 core in C with an R3000A interpreter as bit-exact oracle, plus a MIPS R3000A → SH-4 dynamic recompiler
Graphics
GP0 decoder emitting PowerVR2 display lists — verified rendering on Dreamcast
Sound
From-scratch Mitsubishi M37702 core for the Namco C76 sound MCU driving C352 PCM
Bring-up target
Namco System 11 Tekken; the Capcom ZN-1 BIOS also runs through full hardware init
// engineering log
  • Dynarec taken through seven phases — block cache, dispatcher, direct-branch chaining, self-modifying-code invalidation, global hot-register pinning, branch-epilogue shrink and GTE call-out — and proven bit-exact against the interpreter on real SH-4 hardware across all 32 general registers, HI/LO, PC and the RAM window.
  • Branch chaining cut dispatcher entries by 667×, and the hot loop went from 32 to 11 SH-4 instructions per iteration — 5.1× cumulative.
  • A real hardware bug found by rendering: PS1 GP0 vertices are 11-bit signed, not 16.
  • Reverse-engineered the M37702 from MAME and the manual, including the 0x89 multiply/divide prefix and a corrected 16-source interrupt vector table, and got the real C76 sound driver into its steady-state loop.
  • Implemented System 11's eight-window ROM banking, which eliminated a derail at roughly 300 million instructions — clean for 800 million afterwards.
667×
Fewer dispatcher entries after branch chaining
5.1×
Cumulative hot-loop speedup, 32 → 11 SH-4 instructions
10 / 10
Bit-exact dynarec cases on real SH-4
395,243
GTE transforms in a single Tekken run
Where it actually stands Everything runs in a headless native harness. Tekken boots its real code and runs its frame loop, and the graphics path is verified rendering on Dreamcast — but the emulator is not integrated into the Dreamcast runtime for live play, the interpreter is far too slow for real time, asset decompression is blocked on an unbuilt decode table, and audio is one event flag short of voices. Nothing is playable yet. The screenshots above are VRAM dumps, not a running game.
P-01

FOOTSIES — one fighting game, seven consoles

Unity / C# originalGBA · Dreamcast · Neo Geo · PS1 · N64 · NES · SNES
GBA COMPLETE · OTHERS VARY
Nine-panel verification sheet showing the FOOTSIES port with its hitbox, hurtbox and pushbox debug overlay active
Verification sheet — hitbox, hurtbox and pushbox debug overlay live, matching the original frame data
FOOTSIES GBA port showing title screen, credits, a fight in progress and the pause menu
Game Boy Advance — title, fight, pause menu
FOOTSIES NES port gameplay
NES build (work in progress)
FOOTSIES running on Neo Geo hardware in MAME
Neo Geo MVS/AES romset

FOOTSIES is hifight's open-source spacing trainer, written in Unity and C#. This is not a recompilation — it is a reimplementation of the engine in C, with every frame-data value extracted verbatim from the original Unity asset files: hitboxes, hurtboxes, pushboxes, per-frame movement, cancel windows, damage and stun, guard health, dash and charge timing. Then retargeted across seven consoles. Original game by hifight; ported by oldmanrukus.

Game Boy Advance
Most complete · runs on real hardware and flash carts · devkitARM + libtonc, Mode 4 software blitter
Dreamcast
Two builds — a netplay variant and a shop variant
Neo Geo
MVS/AES romset with MAME software-list hash · boots to title and fight
PlayStation
Bootable disc images, three revisions
Nintendo 64
Five cartridge builds including a 1:1 timing revision
NES
Work in progress · matches play through to KO
SNES
Diagnostic ROM only — least complete
// beyond the original
  • Pixel-exact debug overlay reproducing the original's hitbox, hurtbox and pushbox view — which is also how the frame data was verified rather than assumed.
  • Best-of-five ladder against the ported CPU AI, guard bar with guard break, one-hit-KO specials and a practice mode.
  • Original additions: a projectile, a raging demon with kanji, a glide and a parry — none of which are in hifight's version.
Honest scope The GBA build is the finished one and the only port with documentation. The Dreamcast, PS1 and N64 builds exist and boot, but their feature completeness is not independently verified; NES is self-declared work in progress and SNES is a diagnostic ROM.
03 // products

Things I've shipped that people actually use.

The same instinct as the recompilation work, pointed at problems that pay: build the thing end to end, own the infrastructure under it, and ship it to whatever the audience is holding.

RukFlix app icon

RukFlix

stream.yourfuturebox.com ↗ personal cloud media player · iOS & Android
RukFlix media center interface — Recommended row with poster art, a title detail pane and sidebar navigation
RukFlix media center — the ten-foot interface, running against a personal library

Your own library, your own server, streamed to everything you own. RukFlix is a self-hosted personal cloud media player — a server holds the catalog and streams it over HLS behind TLS, and you sign in from whatever screen is nearest. It ships as a native iOS and iPadOS app and on Android, and then keeps going onto hardware that has no business playing modern video.

iOS / iPadOS
Expo SDK 57 · React Native · TypeScript · token held in the iOS Keychain · shipped through TestFlight
Android
Same React Native core, adaptive icon and native player
Roku
Sideload channel, iterated across ten builds
Sega Dreamcast
KallistiOS homebrew — boots, DHCPs, signs in, browses and streams MPEG-1 through the PVR's hardware colour-space converter
Raspberry Pi Zero 2 W
Controller-first couch UI on RukusOS, playing the 480p rendition through mpv

Continue Watching and genre rows, live search, series and episode lists, playlists with auto-advance, and resume position synced back to the account so you can stop on the phone and finish on the TV. On iOS that comes with an audio-track picker, subtitles, scrubbing, picture-in-picture and AirPlay.

React NativeExpo TypeScriptHLS REST APIKallistiOS BrightScriptmpv
GB
Green Buddy homepage — Help around the home, without the runaround
greenbuddyai.com

A two-sided marketplace for on-demand home services, running as a Burks Foundation pilot across lawn care and handyman work. A customer posts a job, vetted providers quote it, accepting one atomically rejects the rest, and the booking runs through Stripe to an 85/15 split in the provider's favour.

Behind it: ASP.NET Core minimal APIs on EF Core, PostgreSQL on RDS, AWS Cognito for identity, Stripe Connect for payouts, SES and S3, and a Blazor Server admin. The whole estate is defined as infrastructure-as-code in C# and runs on ECS Fargate behind a pair of load balancers. Two native Android apps ship from a shared Kotlin core — Green Buddy for customers and Green Buddy Pro for providers.

ASP.NET CoreKotlin Jetpack ComposePostgreSQL AWS CognitoStripe Connect ECS FargateAWS CDK
THE
GUNNA
SHOW

The Gunna Show

gunnashow.com ↗
The Gunna Show live battle page — stream player with synchronised chat replay alongside past broadcasts
Live battle with synchronised chat replay — real audience, real broadcast archive

Philadelphia's premier song battle league, and the platform it runs on — web plus native iOS and Android. Not a brochure site but a working competition system: a live battle arena for streamed matchups, real-time audience voting on active bouts, weight-class divisions with champions, an artist roster and judging panel, and leaderboards ranking both the artists and the supporters backing them.

Around the competition sits the social and commercial layer — The Cookout feed with clips, walls and live rooms; a wallet with in-app coins and a GS+ membership tier; and promo packages sold directly through the site.

Live streamingReal-time voting iOS & AndroidMemberships In-app currencyLeaderboards
BS

Bash Sports Online Bowling

on Steam

A multiplayer bowling game shipping on Steam. The client is Unity — 3D physics, lane and pin behaviour, animation and cross-platform rendering. Behind it is the online infrastructure: matchmaking, player sessions, real-time game state between competitors, and persistence of profiles and progression. Running a live multiplayer title is where the systems background and the software work land in the same product.

UnitySteam MatchmakingGame servers
FL

faizonlove.com

demo.faizonlove.com ↗

Built alongside comedian Faizon Love — part streaming platform, part virtual comedy club. Content is ingested, transcoded to adaptive bitrates and delivered over a CDN, while the application layer recreates the room: shared spaces, the lineup, and an audience gathered around a performance rather than watching it alone.

Live streamingAdaptive bitrate CDN deliveryVirtual venue
U

Unico — Lead Software Engineer

MVSX · Arcade Stick Pro · MVS Mini

Lead Software Engineer on a line of dedicated arcade hardware. These aren't emulator front-ends bolted onto a PC — they're purpose-built consumer devices where the software has to boot fast, feel instant in the hand, and stay solid in living rooms that never get a patch window. The work spans the whole stack of a shipped device: on-device system software and UI, input handling where frame-accurate response is the entire product, media and save handling, and the build and release process that turns it into firmware you can put in a box.

Embedded systemsFirmware Low-latency inputRelease engineering
04 // systems & network engineering

Hypervisor to handoff — the day job that funds the workbench.

Cloud and on-prem compute, enterprise storage, and the switching, firewalls and WAN fabrics that tie them together — sized for anything from a two-rack office to a multi-site enterprise.

01 Compute platforms — cloud & on-prem

Both sides of the line. In the cloud that's AWS and Microsoft Azure — compute, storage, identity, networking and the managed services that replace racks of owned hardware. On premises it's Windows Server and Ubuntu Server estates: Active Directory, DNS and DHCP, file and print, certificate services, patching and hardening; and on the Linux side the web, database and application servers that quietly carry most of the load.

Underneath the guests sits the hypervisor, and I run both — VMware vSphere / ESXi and Hyper-V. Clustering, high availability, live migration, golden images, snapshot and backup strategy: the layer that decides whether a hardware failure is an outage or a non-event.

AWSMicrosoft AzureWindows ServerUbuntu ServerVMware vSphere / ESXiHyper-VActive Directory

02 Enterprise storage & SANs

Virtualization is only as good as the storage under it. I've deployed, migrated and maintained Dell EMC and Dell Unity arrays as well as Pure Storage flash — provisioning LUNs, volumes and datastores, zoning and presenting over Fibre Channel and iSCSI, and multipathing so a failed path or controller never reaches the application.

Day to day it's capacity and performance planning, tiering, array-level snapshots and replication that actually meet the business's recovery objectives, and the firmware and expansion work that keeps an array healthy for its whole service life. Storage migrations between arrays are some of the least forgiving work in the job — done properly, nobody notices they happened.

Dell EMCDell UnityPure StorageFibre ChanneliSCSISnapshots & replication

03 Switching, routing & firewalls

Years inside managed service providers means you see everything. For routing and switching that's largely Cisco and HP/Aruba — core and access switches, stacking, VLAN and trunk design, layer-3 routing and the access control that segments a business cleanly. At the edge I configure and support SonicWall, Cisco ASA and Fortinet — policy and NAT, content and application filtering, IPS, and the VPN termination that connects sites and remote workers.

For smaller businesses that want enterprise behaviour without enterprise overhead, I lean on Ubiquiti and Cisco Meraki: cloud-managed switching, routing and Wi-Fi with central visibility and no on-site controller to babysit. That breadth eventually pointed me deep into Cisco, which is where most of my current work lives.

CiscoHP / ArubaSonicWallCisco ASAFortinetUbiquitiCisco Meraki

04 VPNs, SD-WAN & cross-country connectivity

Networks are only useful when sites can talk to each other. I build the site-to-site and client VPN tunnels that link offices, data centers and remote workers, and increasingly I'm leaning into SD-WAN — currently in production for cross-country communications and for connectivity into TierPoint facilities.

SD-WAN lets me treat multiple underlying circuits — broadband, fiber, cellular — as one intelligent fabric: it steers traffic over the healthiest path in real time, fails over instantly when a link degrades, and applies consistent policy everywhere. A branch in one state and a data center on the other side of the country behave like they're on the same LAN.

IPsec VPNSite-to-siteSD-WANTierPointMulti-circuit failover
05 // background

Albany born, Philly raised, Army forged.

From upstate New York to the streets of Philadelphia, through two tours in Iraq, and into a career spent keeping systems and networks alive — newest first.

01 Becket & Lee LLP — Network Engineer · current

I'm the Network Engineer at a creditors' rights law firm. Legal work carries obligations most environments don't — client confidentiality, retention requirements, audit trails — so the network isn't just expected to be fast, it's expected to be defensible. I own the switching and routing, the firewalls and VPNs, and the site-to-site connectivity that keeps the firm's offices and data center facilities talking to each other.

It's the role where the breadth from everything before it pays off: when the network belongs to you, there's nobody to escalate to. You design it, you document it, and you're the one awake when a circuit drops.

02 The MSP years — Tech Impact · PCS · Angelisanti Elite IT

Most of what I know I learned inside managed service providers. At Tech Impact I was Senior Systems Engineer (Tier 3), running infrastructure modernisation and cybersecurity strategy for non-profits — a sector that needs enterprise-grade security on budgets that don't resemble enterprise budgets.

A large piece of that was unstructured data management with Komprise: profiling multi-petabyte file estates across NetApp, Dell EMC Isilon/PowerScale and Windows file servers to separate genuinely cold data from hot, then tiering the cold data out to S3/Glacier and Azure Blob while preserving native SMB and NFS access — users kept clicking the same paths and never knew the file had moved. The result was less primary NAS capacity, shorter backup windows and lower cloud spend.

The variety is the point. An MSP hands you dozens of environments you didn't build, each to a different standard, and expects you to be useful inside an hour — reading somebody else's cabling, somebody else's VLAN scheme, somebody else's firewall rules, and finding the actual fault rather than the one that's easiest to blame. It's also where I learned the part that isn't technical: telling an owner honestly what something will cost, what it will fix, and what it won't.

03 Enterprise & federal — General Dynamics · NCI/AdvanceMed · CoventBridge

At General Dynamics I was a Senior Systems Engineer on secure, mission-critical systems for DOD/NAVSEA — carrying defense projects from concept to deployment, designing secure communication networks with military-grade encryption, and building high-availability systems expected to keep running in remote and hostile conditions. I deployed a communications infrastructure that cut data transmission times roughly in half and lifted system reliability by around 30% through redundancy and failover.

At NCI / AdvanceMed I was a Systems Architect for healthcare clients, where HIPAA is the floor rather than the goal — scalable architecture for high-traffic clinical applications, cloud design across AWS and Azure, and hardening with MFA, encrypted storage and end-to-end protection, while cutting client operating costs about 10%. At CoventBridge Group, also as Systems Architect, I supported global insurance-investigation operations; migrating on-premises systems to hybrid cloud took roughly 15% out of operational costs and re-architecting the data pipelines improved performance by about 20%.

04 U.S. Army — 25B Information Technology Specialist · 2005–2013

My career started in uniform. I served as a 25B from 2005 to 2013, including two tours in Iraq. A 25B installs, operates and maintains the networks, servers and communications gear a unit runs on — laying and terminating cable, standing up and troubleshooting network infrastructure, and keeping all of it working in conditions nothing like a climate-controlled server room.

Eight years and two deployments is where the standard got set. In a garrison network an outage is an inconvenience; downrange, communications are how people stay safe. That's where I learned to fix what's in front of me with what I have, to document so the next shift isn't guessing, and to stay level when everything is failing at once.

U.S. Army Veteran25B · 2005–20132× IraqAWS CertifiedSystems ArchitectNetwork Engineer

05 Home

I'm married to Jessica McLaughlin, and together we have a combined six children — a full, loud, wonderful house that keeps me grounded and is the reason most of this work happens after everyone's asleep.

✉ // work with me

Available for freelance work.

Two kinds of engagement

I take work directly, as a senior pair of hands without a headcount. Small business or enterprise, one-off project or ongoing support, remote or on-site.

▸ Systems & network engineering
Server and hypervisor builds, cloud and on-prem migrations, SAN and storage work, network design and rebuilds, firewall and VPN configuration, site-to-site and SD-WAN connectivity — or an extra senior pair of hands when something is broken and needs to be right the first time.
▸ Porting, recompilation & embedded
Static recompilation and decompilation, getting a legacy title onto modern hardware, console and embedded ports, toolchain and build-system work, low-level graphics and audio bring-up, and performance work on constrained targets.

Tell me what you're running and what's hurting, and I'll come back with a straight answer and a price — including when I'm not the right person for it. Include what you need and your timeline; that's usually enough.