# Flatbox is a printable hitbox fightstick that has been revised ten times > Flatbox is a repository of 3D-printable models, PCB design files and firmware for a low profile, hitbox layout arcade controller, built around Kailh low profile switches, with ten hardware revisions and several firmware targets from ATmega32U4 to STM32G0B1. It ships no releases and states no licence. **jfedor2/flatbox** — Low profile hitbox-layout fightstick - Repository: https://github.com/jfedor2/flatbox - Stars: 820 · Forks: 143 - Language: C - License: not declared - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/jfedor2-flatbox ## Ten revisions of the same idea Flatbox is described as a low profile hitbox-layout fightstick, and the repository contains the 3D-printable models, the PCB design files and the code needed to make an arcade controller that looks like the product photo in the README. The striking thing about the project is the number of iterations. The README says there are ten major versions of the Flatbox, and the table lists them: rev1.1, rev2, rev3, rev4.1, rev5, rev6, rev7.2, rev8, rev9 and rev10. The repository tree matches that history, with a directory for each hardware revision, including rev1, rev4, rev4.1wasd, rev7 and rev7.1 which the summary table does not list in full. That directory listing is worth reading, because it shows what a decade of iteration produces. There are firmware directories for the ATmega32U4, for the CH552 and for CircuitPython, and for the RP2040. There is a 3d-printed-buttoncaps/ directory for the caps themselves. And there is the hardware directory for every revision, each presumably with its own README. The pattern is that of a hobby project refined over years rather than a product designed once. Each revision is a small set of changes to the same idea, and the README is explicit that you should look at the README for each version to see how to make them. The primary language of the repository is C, which is what the firmware directories contain, and the repository publishes no GitHub releases. The last push was on 2026-09-09. ## The switch choice is what makes it low profile Every one of the ten revisions uses Kailh low profile mechanical keyboard switches, referred to in the README as choc v1. That single constraint explains most of the design. Choc v1 switches are low profile keyboard switches, so a board built from them is a few millimetres taller than the PCB rather than the several centimetres a full height arcade switch adds. The result is a controller that sits flat on a desk, which is the point of the project. A conventional fightstick uses a full height lever and a chunky case; a Flatbox is a keyboard switch grid in a shallow printed shell. It also explains the hitbox layout. Hitbox is the fighting game control layout, a grid of buttons rather than a lever and four buttons, and it suits low profile switches because the buttons are what you are replacing, not the lever mechanism. The cost of the choice is the switch ecosystem. Choc v1 caps are not the caps you get with a standard keyboard, and the repository carries a 3d-printed-buttoncaps/ directory, which suggests the caps are printed rather than bought, or printed as an alternative. The 3D printing is also what makes the case possible. A shallow case is a good fit for a printed part: no injection moulding tool, and each revision can change the shape without a manufacturing contract. ## Reading the revision table: size, chip and how hard it is to build The README's comparison table is the reference document, and its columns are exactly the questions a builder has: the case dimensions, the console compatibility, the add-on board, the onboard chip, whether surface mount assembly is required, and the firmware. The case size barely moves. rev1.1 is 218x128x10 millimetres, rev2 and rev3 are 218x130x10, rev4.1 and later sit at 218x130x11, rev5 and rev6 come back down to 218x126x10, and rev7.2 through rev10 are 218x130x11. So the footprint is a stable 218 by roughly 130 millimetres across a decade, with the height in the 10 to 11 millimetre range, and the tenth iteration is a millimetre taller than the sixth. The chip column is where the change is. rev1.1 used an Arduino Pro Micro add-on board with no onboard chip, rev2 moved the ATmega32U4 onboard, rev3 kept the add-on approach but with a Brook board, rev4.1 introduced the RP2040, rev6 used the CH552T, rev7.2 and rev9 and rev10 went to the nRF52840, the SAMD21 and the STM32G0B1, and rev8 moved to the RP2350. The assembly column is the practical one. Surface mount assembly is not required for rev1.1, rev5 and rev7.2, and is required for the rest, which is a meaningful difference between a first build and a fifth build. ## Firmware is a choice, and the choice is a constraint The firmware column shows that Flatbox is not tied to one controller ecosystem, and the firmware directories in the tree confirm it: firmware-atmega32u4, firmware-ch552, firmware-circuitpython and firmware-rp2040. For the ATmega32U4 based revisions the README links the ATmega32U4 firmware, and for the CH552 based revision there is a matching firmware-ch552 directory in the repository. The RP2040 boards use GP2040-CE, with rev5 carrying an RP2040-Zero add-on board rather than an onboard chip, and the newest revisions use PGF, the portable gamepad firmware, which the README links to its own repository. GP2040-CE is the well known open source firmware for the RP2040 and RP2350, and it is what the rev4.1, rev5 and rev8 entries point at. PGF covers the Bluetooth capable boards, which is why rev7.2 with the Xiao nRF52840, rev9 with the SAMD21 and rev10 with the STM32G0B1 use it: the Switch compatibility depends on the wireless link, and that is a firmware concern as much as a hardware one. The CircuitPython firmware directory is the odd one out and suggests a path for anyone who wants to change the behaviour of a button without writing C, which is a reasonable way to learn the layout before committing to a full build. ## Console support is a matrix, and the asterisks matter The compatibility column is the one to read carefully, because it is not uniform across the revisions. rev1.1 and rev2 list PC and PS3. rev3 lists PC, PS3, and PS4, or PC, Switch, PS3, PS4 and PS5, with a Brook PS3/PS4 board or a P5 mini add-on board as the option. rev4.1 lists PC, PS3, PS4, PS5 and Switch with the RP2040 onboard. rev5 lists PC, PS3, PS4 and Switch with an RP2040-Zero add-on. rev6 and rev7.2 are PC and Switch. rev8 lists PC, PS3, PS4, PS5 and Switch with the RP2350, and rev9 and rev10 are back to PC and Switch. The footnote explains the asterisks: with caveats. PS4 and PS5 entries marked with an asterisk work, but with caveats, and no caveat is spelled out in the README. Given that the add-on boards for the PlayStation consoles are Brook products, the caveats are likely about how the console sees the device, but the documentation does not say, and that is exactly the kind of thing a builder should check in the per revision README before ordering a board. The pattern across the revisions is consistent: the more recent hardware drops the PlayStation support and keeps PC and Switch, and the Switch capable boards are the ones with wireless controllers, whether through the nRF52840, the SAMD21 or the STM32G0B1. The add-on board column is worth reading as a cost line. Several revisions need a separate controller board, either an Arduino Pro Micro, a Brook board or an RP2040-Zero, which is an extra purchase and an extra wiring job compared with a revision that has the chip on the board already. ## Where Flatbox is the wrong project Three situations rule it out. The first is a player who wants a finished, tested device. Everything here is a set of files that you turn into a product, and the assembly difficulty is not uniform. Six of the ten revisions require surface mount assembly, which means a hot air station or a very steady hand and a magnifier, and a first time builder is likely to spend a weekend on a board before they have a controller. The second is a Switch or PlayStation player who expects the console to treat the controller as something it recognises without caveats. The compatibility table marks several entries as working with caveats without saying what they are, and the PS4 and PS5 rows depend on third party Brook boards rather than on the design itself. The third is anyone who wants a warranty, a support line or a consistent product. There is no release, no versioning policy for the hardware files and no stated licence, so there is no clear answer to the question of who is responsible if a printed part fits badly or a firmware file does not behave as the table claims. The project is a body of work by a person, not a product line. What it is very good for is a player with a specific taste: they want a low profile, hitbox layout controller with Kailh choc switches, they are comfortable with hardware, and they want the design decisions already made rather than starting from a fightstick kit and a soldering iron. ## Conclusion Flatbox fits a player who wants a low profile hitbox controller that matches the layout and the feel of the arcade sticks they grew up with, and who is prepared to print the case, populate the switches and flash the firmware, since the repository gives you the files and the wiring for each revision rather than a finished product. It is the wrong choice if you need a guaranteed, tested and assembled device, or if you will not solder, because every revision needs assembly work and the newest boards need surface mount soldering. Before starting, read the README of the revision you pick, because the ten versions differ in case size, controller chip and assembly method, and check the compatibility row for your console, since the PS4 and PS5 entries are marked as working with caveats. ## FAQ ### What is the Flatbox? It is a low profile, hitbox layout arcade fightstick, and the repository contains the 3D-printable models, the PCB design files and the code needed to make one. There are ten major versions, and all of them use Kailh low profile, or choc v1, mechanical keyboard switches. ### Which controller boards does the Flatbox support? Across the ten revisions the onboard chip changes from an ATmega32U4, to the RP2040, the CH552T, the RP2350, the SAMD21 and the STM32G0B1, while some revisions use an add-on board such as an Arduino Pro Micro, a Brook PS3 or PS4 board, an RP2040-Zero or a Xiao nRF52840 Plus. The matching firmware is GP2040-CE, ATmega32U4, CH552 or PGF depending on the revision. ### Do I need to solder a Flatbox? You need to populate the switches at minimum, and the README's table marks surface mount assembly as required for most revisions, including rev2, rev3, rev4.1, rev6, rev8, rev9 and rev10, while rev1.1, rev5 and rev7.2 do not require it. ### Can I use the Flatbox with a PlayStation 5 or a Switch? Switch support appears in rev4.1, rev5, rev7.2, rev8, rev9 and rev10, while the PS4 and PS5 entries are marked in the README as working with caveats, and rev3 offers Brook PS3 or PS4 and P5 mini add-on boards for those consoles. ### How do I start building a Flatbox? Pick a revision and read the README for that version, which the main README says has the details on how to make it, then use the files in the matching hardware directory, such as hardware-rev2 or hardware-rev10, for the case and PCB, with the 3d-printed-buttoncaps/ directory for the caps and the matching firmware directory for the code. ## Sources - [Issues](https://github.com/jfedor2/flatbox/issues) - [jfedor2/flatbox on GitHub](https://github.com/jfedor2/flatbox) - [README](https://github.com/jfedor2/flatbox/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/jfedor2-flatbox