25+
AI and LLM platforms
Agent tooling, multi-provider gateways, grounded citations, streaming interfaces, and eval systems used by production teams across the firm.
$FF4052 · player one
Daniel Plas Rivera.
Lead software architect and hands-on engineer building trustworthy AI platforms, resilient data systems, and low-level software.
I lead GenAI and LLM platform work at a management consulting firm, where the systems I build support 25+ teams. Outside work, I reverse engineer arcade hardware and train fighting-game agents.
Featured work
Production platforms, applied ML, and machine-level research.
Featured · systems reverse engineering
Dark Sakura, running natively
No source, no documentation, encrypted program code: two fighters now run on their own relocated 1998 code inside a ROM that had no room for them.
2native character ports
Open project →
World first · reverse engineering
Bringing Cable to Marvel vs Capcom
The first character ever ported from the Dreamcast/NAOMI generation back into a CPS-2 game: 14,095 lossless tiles, a hijacked skeleton, and behaviour authored in 68000.
14,095tiles, zero lost
Open project →
Applied ML · live demo
One more round
A 2.2-million-parameter memorial policy trained from 7,554 recorded matches, with a hand-written browser inference path you can run here.
Open project →
What I build
Capabilities tied to shipped outcomes, not a keyword wall.
~99%
Data systems at scale
Re-architected a high-volume analytics platform from API polling to Kinesis event streaming, sharply reducing calls and infrastructure cost.
77%
Applied machine learning
Took deepest-level accuracy from roughly 4% to 77% in a four-level, 137-path classifier with weighted loss, focal loss, and branch oversampling.
64MB
Systems and reverse engineering
Built the custom emulator core that raised the graphics ceiling to 64MB, relocated 68000 code into free ROM space, and gated every claim on live execution.
Recent writing
Build notes, technical decisions, and reproducible evidence.
$1EBringing Cable from MvC2 to Marvel vs CapcomMy favorite Marvel vs. Capcom 2 character now walks, fights, shoots, launches, and fires a hyper inside the original Marvel vs. Capcom. This is the whole road: pulling him off the Dreamcast disc, rebuilding his art for 1998 arcade hardware, hunting down a palette bug that survived five builds, and then crossing the wall where converting ends and writing begins.Jul 28, 2026
· 56 min$1FOne Dreamcast Character Does Not Fit In An Entire SaturnI was told porting Marvel vs. Capcom from Dreamcast to Saturn would be an easy job, and that the DC build was really a Saturn project so the structures would match. Measured from the GD-ROM: a Dreamcast character averages 11.41 MB — 1.45x the Saturn's total memory including the 4MB expansion cart, and 17x one character's art slot. The data is already compressed (zlib gains 1.13x), so there is nothing to squeeze. It carries no Saturn structure at all — and the endianness fingerprint is decisive: the Saturn stores arcade tables byte-identical, the Dreamcast stores the same tables byte-swapped for a little-endian CPU. But it is not useless: it carries the two tables the Saturn threw away.Jul 28, 2026
· 12 min$1DMarvel vs. Capcom Fills All 4MB. The 68000 Has 16.Every CPS-2 expansion I had done was graphics or audio, because program ROM looked maxed out: MvC occupies all 4MB of it. Then I enumerated the actual memory map and found $410000-$5FFFFF completely unmapped - nearly 2MB of address space no CPS-2 game ever used. Flat-mapping 1MB there took four small changes to the emulator core and no banking at all, and it turned 41,608 fragmented bytes of free space into a single contiguous megabyte. That is the difference between a character port that borrows another fighter's data and one that actually imports its own.Jul 27, 2026
· 7 min$1BThe Debug Menu Was In The ROM The Whole TimeFor months I've been inferring Marvel vs. Capcom's animation structures from bytes. It turns out Capcom shipped a SECRET TEST MENU in the retail ROM that names them out loud -- the master debug flag is bit 15 of a single word at $C0, my static search for it failed for an instructive reason, and a MAME read tap found it in one 59-second headless run. Now extended with a full capability audit: all twelve sections probed with sixteen input combinations each, a control map that differs per editor, the discovery that ENEMY SENSEI exposes the CPU AI tables and that throws are a two-character CATCH/HOLD pair, and the bridge that the editor's character number doubled is the engine's internal char-id. Also here: two claims I had to walk back, including one the arithmetic simply refuses.Jul 26, 2026
· 19 min$1CReading The Debug Menu Like A DatabaseGetting into Marvel vs. Capcom's secret test menu was the easy part. Turning it into data meant writing an exact-glyph OCR, and every hard bug in it was self-inflicted: a threshold one unit too high clipped the bottom row of every glyph, which manufactured 100+ phantom characters and quietly corrupted two rounds of human labelling. What came out the other side is the moveattr record format, a way to drive the CPS-2 debug DIP switches that the published write-up says requires a custom MAME build, and -- once the screen-covering lattice was killed at the palette rather than fought in image space -- a control map for all twelve debug sections and a 76-of-76 JSON export of two characters' animation and throw data straight out of Capcom's own editors. Three of the bugs along the way looked like missing data and were all physical: redraw timing, then a sprite standing on the readouts, then the *other* character's sprite.Jul 26, 2026
· 22 min
· 56 min$1FOne Dreamcast Character Does Not Fit In An Entire SaturnI was told porting Marvel vs. Capcom from Dreamcast to Saturn would be an easy job, and that the DC build was really a Saturn project so the structures would match. Measured from the GD-ROM: a Dreamcast character averages 11.41 MB — 1.45x the Saturn's total memory including the 4MB expansion cart, and 17x one character's art slot. The data is already compressed (zlib gains 1.13x), so there is nothing to squeeze. It carries no Saturn structure at all — and the endianness fingerprint is decisive: the Saturn stores arcade tables byte-identical, the Dreamcast stores the same tables byte-swapped for a little-endian CPU. But it is not useless: it carries the two tables the Saturn threw away.Jul 28, 2026
· 12 min$1DMarvel vs. Capcom Fills All 4MB. The 68000 Has 16.Every CPS-2 expansion I had done was graphics or audio, because program ROM looked maxed out: MvC occupies all 4MB of it. Then I enumerated the actual memory map and found $410000-$5FFFFF completely unmapped - nearly 2MB of address space no CPS-2 game ever used. Flat-mapping 1MB there took four small changes to the emulator core and no banking at all, and it turned 41,608 fragmented bytes of free space into a single contiguous megabyte. That is the difference between a character port that borrows another fighter's data and one that actually imports its own.Jul 27, 2026
· 7 min$1BThe Debug Menu Was In The ROM The Whole TimeFor months I've been inferring Marvel vs. Capcom's animation structures from bytes. It turns out Capcom shipped a SECRET TEST MENU in the retail ROM that names them out loud -- the master debug flag is bit 15 of a single word at $C0, my static search for it failed for an instructive reason, and a MAME read tap found it in one 59-second headless run. Now extended with a full capability audit: all twelve sections probed with sixteen input combinations each, a control map that differs per editor, the discovery that ENEMY SENSEI exposes the CPU AI tables and that throws are a two-character CATCH/HOLD pair, and the bridge that the editor's character number doubled is the engine's internal char-id. Also here: two claims I had to walk back, including one the arithmetic simply refuses.Jul 26, 2026
· 19 min$1CReading The Debug Menu Like A DatabaseGetting into Marvel vs. Capcom's secret test menu was the easy part. Turning it into data meant writing an exact-glyph OCR, and every hard bug in it was self-inflicted: a threshold one unit too high clipped the bottom row of every glyph, which manufactured 100+ phantom characters and quietly corrupted two rounds of human labelling. What came out the other side is the moveattr record format, a way to drive the CPS-2 debug DIP switches that the published write-up says requires a custom MAME build, and -- once the screen-covering lattice was killed at the palette rather than fought in image space -- a control map for all twelve debug sections and a 76-of-76 JSON export of two characters' animation and throw data straight out of Capcom's own editors. Three of the bugs along the way looked like missing data and were all physical: redraw timing, then a sprite standing on the readouts, then the *other* character's sprite.Jul 26, 2026
· 22 min
Continue?
Stuck on something at this level?
I'm happy where I am, so this isn't a pitch. But I read every email, and these are the problems I like: agent tooling, evals, LLM infrastructure, or anything stubborn down at the machine level. Send yours over and I'll tell you what I actually think.