Wiznet makers

Competitive fighting-game players have hit a silicon wall: every open fightstick board built on the RP2040 tops out at 1000 Hz because USB Full-Speed physically cannot poll faster — and worse, fast polling exposes a decades-old bug where two near-simultaneous button presses get split across a frame boundary and one input silently drops. NOBD Zero attacks both problems with a dual-MCU architecture (RP2040 for deterministic input scanning, STM32F723 for USB High-Speed) plus a W5500 hardware Ethernet path that bypasses USB polling entirely, targeting event-driven input delivery in the tens of microseconds.

COMPONENTS

Hardware components

• WIZnet W5500 hardwired TCP/IP Ethernet controller — dedicated network chip for LAN Mode
• RP2040 — PIO-driven deterministic input scanning, Dreamcast Maple Bus bit-banging, retro console protocols
• STM32F723 — USB High-Speed device controller (comms MCU), breaking the RP2040's 1000 Hz Full-Speed ceiling
• RJ45 retro jack wired to the standard Brook retro-cable pinout (pin 1 GND, pin 8 +5V, three signal lines — two carrying the Maple Bus pair)
• 20-pin header matching the Brook UFB pinout (existing stick harnesses plug in directly)

Software & Tools

• NOBD firmware — open-source fork of GP2040-CE (t3chnicallyinclined/GP2040-CE-NOBD); sync-window logic in src/gp2040.cpp
• NOBD companion app (PC) — enables the 16 kHz USB mode and receives LAN Mode input events, presenting them as a virtual controller
• NOBD Desktop — software-only version of the sync fix that hooks the Steam release of Marvel vs Capcom 2, usable with any stick
• Finger Gap Tester — open tool for measuring your own two-button press gap

Source notice — This article reconstructs the NOBD Zero project as presented by its creator on r/fightsticks ("NOBD Zero, dual-MCU flagship fightstick PCB, 8 kHz…") and, primarily, on the official project site zero.nobd.net and the public GitHub repositories. Reddit blocks automated retrieval, so the post itself was not re-fetched; the official site is the richer and more current source (the Reddit title's "8 kHz" has since evolved into "up to 16 kHz with companion" on the site). Important: the board is at prototype stage and every performance figure below is a stated design target, not a measurement — the project itself says real numbers go to inputlag.science before being claimed. This reconstruction preserves that framing throughout.

New Content Summary

Similar Existing Content

1. SKVMOIP

• Why similar: The same core idea — human input events (keyboard/mouse HID) transported over a W5500 Ethernet link instead of local USB — with RP2040-class hardware and latency as the headline metric.
• How it differs: SKVMOIP is a KVM-over-IP remote-administration tool; NOBD Zero aims the identical transport concept at competitive gaming, where determinism (not just average speed) is the selling point.
• Connection point: Both demonstrate the W5500 as an "input event bus"; SKVMOIP's implementation details can inform LAN Mode firmware decisions.

2. IP Keyboard on W5500-EVB-Pico

• Why similar: RP2040 + W5500 (on WIZnet's own EVB-Pico) turning keystrokes into network packets — three overlapping axes: chip, MCU, and the input-over-Ethernet application.
• How it differs: A single-MCU proof of concept without the dual-processor split or hard latency targets.
• Connection point: The natural starting point for readers who want to prototype NOBD-style LAN input on off-the-shelf WIZnet hardware today.

3. Windows CE Dreamcast Community Edition with Experimental Ethernet Link Shim

• Why similar: The same unusual pairing of Dreamcast-era retro gaming with W5500 Ethernet connectivity.
• How it differs: It networks the console side; NOBD Zero networks the controller side and speaks native Maple Bus to the console.
• Connection point: Together they sketch a fully Ethernet-augmented retro setup — networked console, networked controller.

Differences and Extension Value

Gaming-adjacent W5500 content on the Maker site has treated Ethernet as a way to remote an input device (KVM, IP keyboard). NOBD Zero inverts the value proposition: Ethernet as a lower-latency, more deterministic alternative to USB itself, for a device sitting right next to the PC. Its argument is architectural — USB is polled (the host asks, on a clock), while a W5500 LAN link can be event-driven (the device speaks the instant state changes, and only then). Even at 8 kHz, USB imposes a 0–125 µs polling quantization; the LAN path targets removing that quantization entirely. That reframing — determinism over raw speed — is a genuinely new angle for W5500 content.

Extension value: the pattern generalizes to any HID-class device where jitter matters (sim-racing wheels, rhythm-game controllers, accessibility devices), and the receiving side is just a PC app feeding a virtual controller — no driver installation. For WIZnet specifically, this is a consumer-facing, esports-adjacent showcase of the W5500 in a product category (fightstick PCBs) where it has never appeared, alongside Brook-ecosystem compatibility that eases adoption.

PROJECT DESCRIPTION

Why does a fightstick — a box of buttons a foot from the PC — need two processors and an Ethernet chip? And why do classic fighting games drop one of your two buttons no matter how good your hardware is?

 the polling clock is the enemy, so remove it twice. First, split the work: an RP2040 does nothing but scan inputs deterministically via PIO while an STM32F723 does nothing but talk USB High-Speed, so neither ever blocks the other. Second, offer an escape from polling altogether: a W5500 sends input events over Ethernet to a companion app the moment they happen. And for the classics that read input only once per frame, a tunable sync window regroups your humanly-imperfect (2–8 ms apart) button presses so they land in the same frame — every time.

0. Core Technology: Three Chips, Three Escape Routes from the 1000 Hz Wall

Every open fightstick board today shares one ceiling: the RP2040's USB is Full-Speed only, and Full-Speed HID cannot exceed 1000 Hz polling. The fastest commercial board ever independently measured (Brook UFB, per inputlag.science) sits exactly on that 1 ms wall. NOBD Zero's answer is division of labor. The RP2040 stays — its PIO blocks are unmatched for deterministic, jitter-free input scanning and for bit-banging the Dreamcast's Maple Bus — but host communication moves to an STM32F723, whose USB High-Speed peripheral supports 8 kHz reports natively (0.125 ms) and a 16 kHz mode (0.0625 ms) with the companion app. The third chip, the W5500, exists for a different reason entirely: not to poll faster, but to stop polling — covered in §5.

1. Development Platform: GP2040-CE Lineage, Brook Compatibility

The firmware is a public fork of GP2040-CE, the open-source firmware that dominates the DIY fightstick scene. That lineage matters twice over: the sync-window fix already runs on stock GP2040-CE boards today (anyone can flash it, free), and the NOBD Zero hardware inherits a mature configuration ecosystem rather than starting from zero. Physically the board slots into existing sticks through the standard Brook 20-pin header, and its retro RJ45 jack implements the Brook retro-cable pinout — pin 1 GND, pin 8 +5V, three signal lines of which two carry the Maple Bus pair — so cables players already own plug straight in. Firmware is open; board hardware files are not yet published 

2. Operating Principle: the Dropped-Input Bug, Measured

The bug the project is built around is real, specific, and quantified. Classic fighters (arcade boards, Dreamcast-era consoles) read the controller once per 16.67 ms frame, in hardware lockstep — so two presses landing 2–8 ms apart (the project's measured human "finger gap") were swept into the same read and registered together. On modern PCs and emulators, a 1000 Hz stick reports state every millisecond; a 3 ms gap becomes three reports with only the first button held, and if the game's single per-frame read falls inside that window, the second button never existed. The fix is a sync window (default 5 ms, tunable): the first press opens a grouping window, held inputs commit together, releases pass instantly. A Raw mode disables grouping for minimum latency. The project is careful to scope the claim: this targets frozen classics on modern hardware (Fightcade, emulation, ports) — modern fighters already add input leniency in software.

3. Device A: the Scan Engine (RP2040)

The RP2040's job is deterministic truth about button state, plus everything retro. PIO state machines scan inputs on fixed timing that no USB interrupt can perturb — the entire reason for the dual-MCU split is that scan timing "never gets blocked by USB work, so timing stays consistent under load." The same PIO capability bit-bangs the Dreamcast Maple Bus natively, making NOBD Zero (per the project) the first board of its class with adapterless Dreamcast support

4. Device B: the Comms Engine (STM32F723)

The STM32F723 exists to say one thing to the host, extremely often: the current input state. Its High-Speed USB device peripheral delivers 8 kHz HID reporting out of the box with standard OS drivers, and 16 kHz with the NOBD companion handling the host side — no driver install claimed. Isolating USB on its own silicon means descriptor handling, enumeration quirks, and host-side stalls can never steal cycles from input scanning. It is a brute-force solution — a second full MCU as a USB offload engine — which is precisely the "over-engineered" positioning the project embraces.

5. Core Communication Logic: W5500 LAN Mode — Deterministic, Not Just Fast

LAN Mode is the W5500's showcase, and its design argument is worth quoting precisely: "Not faster on average. Deterministic." The W5500 sends an input event over Ethernet only when state changes; a companion PC app receives it and feeds a virtual controller. This bypasses USB polling completely — no host clock to wait on, so the input arrives "the same way every time" instead of anywhere within a polling interval. The project's stated targets: ~25–35 µs press-to-game, versus roughly 125–187 µs for 8 kHz USB — marketed as the equivalent of ~40,000 Hz. Direct PC-to-board connection is supported without special cables. All of this is explicitly pre-prototype target, to be independently measured (inputlag.science) before being claimed as fact.

The W5500 is the right part for this job for the same reason it suits the rest of this board's philosophy: its hardwired TCP/IP stack keeps the network workload off both MCUs, so adding a third transport doesn't compromise the timing guarantees the first two chips were separated to protect. An event-driven single-packet-per-change pattern also means near-zero steady-state traffic.

6. Verification / Exception Handling: Receipts, Not Trust

The project's evidence posture is unusually disciplined for a crowdfunded gaming product, and it deserves credit. Verifiable today: the sync logic as readable source (src/gp2040.cpp in the public fork), side-by-side demo video of the same two-button input dropping with sync off and landing with sync on (captured in Marvel vs Capcom 2), a free Finger Gap Tester to measure your own press gap, and NOBD Desktop to feel the fix in software with any stick. Independent supporting evidence: a third-party relay-rig test (Vodka's) found slower boards register simultaneous presses more consistently than fast ones — the same direction as NOBD's thesis. Not yet verifiable: every latency number for the board itself, which the project consistently labels as targets pending independent measurement. This article adopts the same discipline.

7. Results & Status

Where things stand: prototypes in production, firmware public, hardware closed (for now), reservations open. The comparative chart the project publishes places its targets against real inputlag.science measurements — Brook UFB at the 1.0 ms wall, GP2040-CE boards at the same 1000 Hz cap, stock pads far behind — with NOBD's 8×/16×/40× bars clearly asterisked as unmeasured targets. Founding-batch pricing is $150 (retail $199), non-binding, no payment collected. For the WIZnet ecosystem, the noteworthy result is already in hand regardless of how the latency numbers land: a W5500 designed into a competitive-gaming flagship as the headline differentiator, not a utility port.

Takeaways

• Polling is quantization; events are exact. The W5500 LAN Mode's core insight — send on change, skip the host clock — trades USB's 0-to-125 µs polling uncertainty for a fixed, repeatable path. Determinism is the product, not the average.
• Dedicated silicon per timing domain. Scan (RP2040 PIO), host comms (STM32F723 USB HS), network (W5500 hardware stack): three jobs, three chips, zero shared stalls. The W5500's offloaded stack is what lets a third transport join without new jitter.
• The bug was in the clocks, not the hands. Classics read once per frame; modern sub-ms polling reports intent before it finishes forming. A 5 ms grouping window on the controller is the only place left to restore the old sync.
• Targets labeled as targets build more trust than specs. The project's refusal to claim unmeasured numbers — and its commitment to independent testing — is a model for hardware marketing, and for editorial coverage of it.
• Open firmware first, hardware later, fix free forever. Shipping the sync fix as a free GP2040-CE flash decouples the community benefit from the commercial board.

Room for Improvement

• All performance claims await measurement — 8/16 kHz effective latency, LAN Mode's 25–35 µs, and the inter-MCU link's overhead are targets on pre-prototype hardware; treat this article's figures accordingly until inputlag.science results exist.
• LAN Mode requires a companion app feeding a virtual controller — acceptance at offline tournaments (where unknown host software is often banned) is an open question the project will need to address.

Notes for New Designs

• For any latency-critical input device, consider the NOBD split as a template: keep scanning on PIO-class deterministic hardware, and let a W5500 provide an event-driven network path whose stack costs your MCUs nothing. A W55RP20 could merge the RP2040+W5500 pair into one package for a leaner variant of this architecture.
• Event-driven beats periodic for control streams: transmit on state change with a heartbeat, not on a timer — you get lower average latency and near-zero idle traffic.
• If you prototype LAN-Mode-style input today, the W5500-EVB-Pico plus the IP Keyboard project above is a working starting point; the receiving side can be a simple UDP listener feeding a virtual HID device.
• When publishing performance-oriented projects, copy the receipts pattern: label targets as targets, publish the measuring tools, and invite third-party verification — it reads as confidence, not weakness.

Documents

• Official site: https://zero.nobd.net/ (specs, demo videos, latency chart, reservation)
• Original Reddit thread: https://www.reddit.com/r/fightsticks/comments/1ujt7k5/nobd_zero_dualmcu_flagship_fightstick_pcb_8_khz/
• Firmware (open source): https://github.com/t3chnicallyinclined/GP2040-CE-NOBD — sync logic: src/gp2040.cpp
• NOBD Desktop (software fix): https://github.com/t3chnicallyinclined/nobd-desktop
• Finger Gap Tester: https://github.com/t3chnicallyinclined/finger-gap-tester
• Upstream firmware: https://github.com/OpenStickCommunity/GP2040-CE
• W5500 datasheet: https://docs.wiznet.io/Product/iEthernet/W5500/overview