Published October 27, 2026 · RetroForge Supply Team
Fixed-Program or microSD Game Boy Cartridge? What to Specify Before a Quote
Start a Game Boy cartridge enquiry with one question: does the buyer need one finished program, or must the person using the cartridge be able to load different programs? Those are different products, even when they fit in similar shells.
A low price for a factory-programmed cartridge is not a low price for a microSD flash cart. Before comparing suppliers, agree the loading method, usable save memory and the steps a player must follow to keep a save. That is especially important for music software, tools and other homebrew where the user’s saved work matters as much as booting the ROM.
On this page 6 sections
Fixed-program, externally rewritable or microSD: which do you need?
A fixed-program retail cartridge arrives with the agreed program loaded. Treat it as one finished release unless the supplier explicitly specifies a supported update method. The term describes the supplied product and workflow; it does not tell you whether its physical memory is mask ROM or a programmable device.
An externally rewritable cartridge uses a specified writer or interface to change the program. Ask who supplies the writer, which exact board it supports and how the process is documented. A board that a factory can program is not automatically a product that every customer can update.
A microSD flash cartridge is intended to load programs from a card through the product’s own loading system. Its supported mappers, save handling and hardware requirements are model-specific. A cartridge advertised as USB-updatable needs the same questions answered; the presence of a connector is not a specification.
For a physical homebrew game reward, a finished single-title cartridge may be the intended experience. For a musician who must add programs or move work between devices, that limitation may rule it out. Write down the required workflow before looking at quantity discounts.
Does a larger ROM mean more save space?
No. The program and saved data have separate requirements. Pan Docs’ cartridge-header reference describes cartridge type, ROM size and RAM size as separate fields. Use those requirements to start a board review, not to certify a supplied board from its header alone.
If your application needs 128 KiB of usable save space, state the unit and the requirement explicitly. “128K” can leave bits and bytes ambiguous. Ask the supplier to identify the memory, addressable banks and any firmware or mapper limits. A sufficiently large chip does not by itself prove that every required bank can be used and retained.
One useful sample check is to write a different known pattern to each required bank, read them back, follow the documented save and shutdown sequence, then repeat after power is removed. Check that banks do not mirror one another. Have the developer or test engineer define and record the procedure for the actual application. This is a proposed acceptance check, not a claim that our pictured sample has passed it.
Will the save survive switching off?
Get the answer as a sequence of actions. Does the application save directly to non-volatile memory? Is RAM battery-backed? Does the cartridge require a menu or reset step to transfer data elsewhere? Can the user back up and restore the application’s save in the expected format?
Do not reduce those questions to “batteryless is better” or “a battery means reliable.” The complete circuit and software determine behaviour. A clock, where required, is another separate specification. For a product to be resold, the instructions and the replacement terms need to describe the workflow customers will receive.
Test a save after a normal exit and after the product’s documented shutdown procedure. Test backup and restoration separately if they are part of the brief. Merely seeing the title screen establishes none of those results. Record the host model and software revision with each result so a later board substitution does not silently inherit the earlier approval.
What belongs in a comparable wholesale quote?
- Exact product and revision: fixed-program, externally rewritable or card-loading; board photos; supplier or manufacturer; and whether substitutions need approval.
- Software requirements: platform, program size, mapper, usable save capacity, clock or other special functions, and target hosts.
- What is included: shell, screw, supplied-program loading, verification, label application, card or writer if applicable, and packaging.
- Variants: counts per program and label design. Two labels on one hardware revision are not the same costing problem as two different boards.
- Sample and delivery terms: sample cost, checks to be performed, quantity breaks, freight, delivery term, tax assumptions, validity and defect handling.
Keep private quotations private and compare totals for the same scope. A unit price without freight or a clearly identified programming method can conceal a mismatch rather than a saving. Our physical reward budget guide covers the rest of the edition and parcel; it does not replace this hardware decision.
How should a crowdfunding reward describe the cartridge?
Write what a backer receives and what they can do with it. If it contains one original game, say that. If they can load other software, explain the supported method and any items they must supply. Do not let a picture of a cartridge stand in for that answer.
The BrickBoy campaign FAQ, for a different kind of retro hardware project, separates edition capabilities, optional accessories and the external reader needed for original cartridges. The useful lesson is the specificity of the scope, not that its hardware is equivalent to a Game Boy cartridge.
Approval also needs a final build identity. In GameTank’s October 2026 update, the creator describes supplying the ROM as manufacturing approaches. For your run, agree the version, checksum, board revision and last approved sample before replication. A late change should trigger an explicit review of the affected checks.
What should you send us first?
Tell us whether the end user must change programs. Then send the platform, quantity, intended hosts and ROM/save requirements for your own or authorised software. State the desired programming and backup workflow even if you have not chosen the board yet. We can review a custom cartridge build against that brief; a fixed-program proposal should never be accepted as a substitute for an SD-loading requirement.
For the enclosure checks, our GB/GBC shell sample guide includes two real videos and the limits of what they establish. Electrical approval remains a separate job, with a testable sample and a written result.