# dspico-hardware: an open-source flashcart shell, PCB and box art > The DSpico hardware repository holds every fabrication file for an open-source Nintendo DS flashcart, from the KiCad schematic and Gerber outputs through the Autodesk Inventor shell models to the stickers and box art, all under CC-BY-SA-4.0. There is no code to read here, which makes the repository interesting mostly for what it shows about publishing hardware design as a set of manufacturable artefacts. **LNH-team/dspico-hardware** — DSpico Hardware (PCB, shell, sticker, boxart) - Repository: https://github.com/LNH-team/dspico-hardware - Stars: 597 · Forks: 36 - Language: Unknown - License: CC-BY-SA-4.0 - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/lnh-team-dspico-hardware ## What a flashcart is, and what this repository actually contains DSpico is described as the world's first open-source DS(i) flashcart, created by the LNH team, and the pitch is that everything from the PCB, shell, stickers and box art is open-source. The README is explicit about the two ways to get one: you can build it yourself as a DIY project or have it made by a manufacturer. The repository is then scoped precisely. It contains the necessary files for the hardware of the DSpico, including a PCB, CAD design of the shell, stickers for cartridge and box art. That is the whole scope, and it is worth being clear that this is a hardware repository rather than a firmware one. The firmware lives in a separate DSpico Firmware repository, and the README links it for the performance figures, along with Pico Loader and Pico Launcher for the software side. The primary language is unknown, which is the correct answer for a repository of CAD and artwork files. The default branch is develop, the licence is CC-BY-SA-4.0, and the last push was on 2026-04-10 with the project not archived. The single release is v1.3.0 from 2025-11-25. The hardware specification is short enough to read in full. An RP2040 microcontroller, 16 Mbit of flash memory, a micro USB port, a micro SD slot, a development port, two LEDs in red and blue, and dual power support, so the cartridge can be powered by USB and the DS simultaneously through an ORing circuit. The firmware figures given are a sequential SD read speed of up to 6MB/s, power consumption of around 57 mW, and compatibility with DSi mode. So the design decisions visible in the repository are a common microcontroller, standard flash, and a real attempt to handle the power negotiation of a cartridge that draws from two sources. That last one is the kind of detail that separates a hobby design from a product. ## The three folders, and why each one has a different format The top level of the repository contains three directories, and the reason they are separate is that they are consumed by different tools and by different people. The dspico-pcb folder holds the PCB design, split into three subfolders. The design-files folder contains the PCB schematic and layout in KiCad format, which is the editable source. The fabrication-files folder contains the Gerber files, the Pick and Place files and the BOM for PCB fabrication, which is what you hand to a fabricator. The docs folder holds documentation for manufacturing and assembling the DSpico, which is what a contract manufacturer reads. That three-way split is the standard open hardware practice and it is worth noticing because it is what makes the repository actually usable rather than merely published. The KiCad files let a person change the design. The Gerbers and BOM let a person order boards without a KiCad licence or a KiCad installation. The docs let a person who has never seen the project know what to order and how to put it together. The dspico-shell folder is the same idea in three dimensions. The design-files folder contains the source design files for the shell, and the 3d-models folder contains 3D models in STL and STEP format for fabrication. The README notes the shell can be viewed and modified using Autodesk Inventor, which is a commercial tool and therefore a constraint on anyone who wants to modify the enclosure rather than just print it. The dspico-artwork-design folder holds the print-and-stick files. It contains stickers for the cartridge, box art to print and put on a DS box, the logo in different formats, and an others folder for other graphics. The formats are SVG, PSD and PNG, which again tells you who consumes each file: SVG for cutting and printing, PSD for editing, PNG for preview. One thing the repository does not do is include a firmware project or a build system, and that is the point. This is a set of files that other people make things from. ## The pinout table, which is the real specification The most technically dense part of the README is the pinout table, and it is worth reading closely because it is the document a hardware reviewer would actually check. The table maps three things per row: the peripheral signal on the DS slot side, the RP2040 pin name, and the physical pin number on the microcontroller. The DS slot takes D0 through D7 on GPIO12 through GPIO19, with CLK_DS on GPIO11, ROM_CS on GPIO10, SPI_CS on GPIO21, IRQ on GPIO20 and RST_DS on GPIO09. The SD slot is a separate peripheral and it is wired to different pins: CLK_SD on GPIO03, the four data lines DAT0 through DAT3 on GPIO05 through GPIO08, and CMD on GPIO04. The development port carries SWD and SWCLK on the dedicated pins 25 and 24, plus TX on GPIO0 and RX on GPIO1. The two LEDs are on GPIO28 for blue and GPIO27 for red. Two observations follow from the table without needing to guess. First, the SD card bus is on its own set of pins, separate from the DS slot lines, which is what allows the cartridge to serve both the console and the micro SD storage over SPI without the two buses fighting for the same controller pins. Second, the development port exposes both the debug signals and a serial console, so the board can be debugged and talked to without taking it out of the shell. The pin numbering is given, which matters more than it sounds. When the RP2040 is in its package, GPIO numbers are what a firmware developer uses, but the physical pin numbers are what the PCB layout uses, and a table that carries both removes a class of error at the boundary between the two. It is also a complete account of the board's interfaces. Anything not in this table is not on the board, which makes the table a way to answer questions about what the hardware can do without opening the KiCad files. ## The build instructions are a manufacturing guide, not a script The Instructions section is where the repository stops being a design archive and starts being a how-to, and the shape of it is instructive. Step one is Build, and it starts by asking you to manufacture the PCB and the shell. You go to the respective sections and read the README file in each to understand how to create those parts, which means the actual manufacturing knowledge is in per-folder READMEs rather than in the root document. The second sub-step is optional: if desired you can print a sticker from the stickers section and add box art for storing the DSpico, for example by reusing an existing box. Step two is Assembly, and it is three sentences. Insert the PCB into the bottom part of the shell, attach the top part by aligning the pegs with the holes in the bottom part, and stick your favourite DSpico sticker on the top part. The README then says to make sure everything fits and the DSpico will be ready for the next steps. Step three is Setup the software, which points at a guide in the dspico repository on the develop branch. That is the boundary between the hardware and the firmware, and the hardware repository stops exactly at it. So there are no commands to run and no package to install, and that is not a gap in the documentation. A hardware project has a different entry procedure: you order parts, you solder or you have them soldered, you assemble, and then you flash firmware. Any article about this repository that tried to present it as a build-it-with-a-package-manager project would be describing something it is not. For an adopter, the practical checklist is therefore about the parts and the process. Do the fabrication files exist for the version you want, does the assembly documentation match the shell revision in the repository, and is the firmware guide compatible with this hardware revision. The v1.3.0 tag and the v1.3 artwork in the photos suggest the version is tracked somewhere, and matching a shell to a PCB is the kind of thing that goes wrong silently if you mix revisions. ## Why CC-BY-SA-4.0 for hardware, and what it obliges The licence is CC-BY-SA-4.0, the Creative Commons Attribution-ShareAlike licence, which is the standard choice for open hardware artwork and documentation and is a contrast with the MIT licence that most of the software in this site carries. The difference is not cosmetic. The code in a MIT project can be taken, modified and closed, and the only obligation is to keep the copyright notice. Under CC-BY-SA-4.0, a derivative of the design has to carry the same licence, so a modified PCB, a reprinted shell or a redesigned sticker set remain share-alike. That is the mechanism by which open hardware stays open: a manufacturer who produces the board from these files and modifies the layout owes the community a share-alike release of the modification. The attribution requirement matters in the same way. Someone who produces a DSpico and sells it, or who publishes a variant enclosure, has to credit the LNH team, which is how the attribution trail survives the fact that the physical product has no README in it. For a team that intends to build the cartridge for themselves, the obligations are close to nothing. For a team that intends to manufacture and sell it, the share-alike term is the thing to read carefully, because it governs the derivative designs rather than the individual files, and it is the term that keeps the project open rather than letting a commercial version fork away from it. The repository also carries a section on the LNH Team Statement in its table of contents, which is the usual place for a hardware project to put the non-commercial and no-competition clauses that the team wants attached to the design. That section is not reproduced in the excerpt available here, so for anyone planning to manufacture, reading it in full matters as much as reading the licence. ## What this kind of repository is for It is worth naming what publishing hardware like this actually accomplishes, because the value is not in the files themselves. A flashcart is a crowded space, and the DSpico's claim is that it is the first one where the PCB, the enclosure, the artwork and the firmware are all open. That combination changes what is possible for the people who use it. A manufacturer can produce boards without a reverse engineering effort to derive a design, because the design is published in a form a fabricator accepts. A hobbyist can print an enclosure, or modify the shell to fit a different cartridge label, because the CAD source is there. A security researcher can look at the firmware and the hardware together, which is not possible when the two are separately closed. The community around it is visible in the repository layout as well, with a Discord section, a contribution section, and artwork that includes a logo folder in different formats and an others folder for additional graphics, which is what a project with a volunteer design team produces over time. There are also honest limits. The shell is in Autodesk Inventor, a commercial tool, so modification requires a licence that a hobbyist may not have, though the STL and STEP exports mean printing does not need it. The build process assumes access to PCB fabrication, which is a real cost and a real barrier, and the README offers the manufacturer route as the alternative to doing it yourself. And the documentation is spread across per-folder READMEs rather than gathered in one place, which is fine for the people contributing to each part and less convenient for a newcomer trying to get a single overview. The result is a repository that is small in bytes and large in intent. If you are evaluating open hardware projects, this is a good one to study for how the design files, the fabrication outputs, the assembly guide and the artwork are separated so that each can be consumed by whoever needs it. ## Conclusion Adopt the DSpico hardware files if you want to build an open-source DS flashcart, if you want to manufacture the board from published Gerbers rather than reverse engineer one, or if you want to modify the enclosure and the artwork for a project of your own. Do not adopt them expecting a software package, because the repository holds fabrication files, CAD models and artwork, and the firmware, the Pico Loader and the Pico Launcher all live in separate repositories. Before you commit, read the LNH Team Statement alongside the CC-BY-SA-4.0 licence, because the share-alike term governs any derivative design you publish, check that the PCB and shell revisions you are ordering match the firmware guide you intend to follow, and note that modifying the shell source requires Autodesk Inventor while printing it does not. ## FAQ ### What is the dspico-hardware repository? It holds the hardware files for the DSpico, the open-source DS(i) flashcart by the LNH team: the KiCad PCB schematic and layout, Gerber, Pick and Place and BOM fabrication outputs, the Autodesk Inventor shell design with STL and STEP models, and the stickers, logo and box art in SVG, PSD and PNG. ### What hardware does the DSpico flashcart use? An RP2040 microcontroller with 16 Mbit of flash memory, a micro USB port, a micro SD slot, a development port, two LEDs in red and blue, and dual power support so the cartridge can be powered by USB and the DS simultaneously through an ORing circuit. With the DSpico firmware, sequential SD read speed is up to 6MB/s and power consumption is around 57 mW. ### Which files do I need to actually manufacture the DSpico? The fabrication-files folder in dspico-pcb holds the Gerber files, the Pick and Place files and the BOM, while the design-files folder holds the editable KiCad schematic and layout. For the enclosure, the 3d-models folder holds the STL and STEP models, and the design-files folder holds the Autodesk Inventor source. ### How do I assemble a DSpico? Insert the PCB into the bottom part of the shell, attach the top part by aligning the pegs with the holes in the bottom part, and then stick a DSpico sticker on the top part. The README asks you to make sure everything fits, and the software setup step then follows the guide in the dspico repository on the develop branch. ### Under what licence is the DSpico hardware published? CC-BY-SA-4.0, the Creative Commons Attribution-ShareAlike licence, rather than a software licence like MIT. The share-alike term means a modified design must be released under the same licence, which is what keeps derivative hardware open, and the repository also has an LNH Team Statement section in its table of contents. ## Sources - [Issues](https://github.com/LNH-team/dspico-hardware/issues) - [License: CC-BY-SA-4.0](https://github.com/LNH-team/dspico-hardware/blob/develop/LICENSE) - [LNH-team/dspico-hardware on GitHub](https://github.com/LNH-team/dspico-hardware) - [README](https://github.com/LNH-team/dspico-hardware/blob/develop/README.md) - [Releases](https://github.com/LNH-team/dspico-hardware/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/lnh-team-dspico-hardware