Choose a Pocket development environment
Do not confuse Pocket development with the separate arcade or home Neo Geo architecture. A library for MVS or AES software is not an NGPC compiler or startup implementation. The author-maintained NGPC project template provides a Pocket build framework and describes its host dependencies. Read its instructions and license before reusing code.
Pin compiler package, template commit and asset tools together. Build an untouched example and retain size, checksum and log. Historical tools can have host-specific requirements; record these instead of claiming native support everywhere. A wrapper around an older compiler does not change the target architecture or justify undocumented switches.
Build a small observable program
Begin with a version string and an input response changing a visible element. Add one controlled sound test after drawing and input work. Keep initialization based on original examples. Change one feature per test so a blank screen can be narrowed to startup, asset conversion, palette selection or rendering rather than an entire engine.
Use emulation for rapid iteration, recording version and boot configuration. Emulator shortcuts are not hardware guarantees. Test monochrome support only if claimed, identifying which functions or assets differ. A successful Color build does not prove the program is readable or compatible on the monochrome machine.
Understand the physical loading format
Flash Masta USB documentation specifies programming and capacity constraints; the GameDrive manual supplies a different workflow. Match output to the selected device instead of relying on an extension. Retain the original build and loader-specific conversion separately so later debugging is not obscured by padding or layout changes.
- Test the handheld with a working original game.
- Load the unchanged example through a documented compatible device.
- Verify version marker and each direction.
- Check sound and timing-sensitive interaction.
- Test shutdown and restart, including native saving if implemented.
- Record console, firmware and output checksum.
Design saving independently
Use the storage implementation expected by the framework and cartridge. Begin with a disposable save. Test first creation, overwrite, normal restart and absent or incompatible persistence. Emulator states are not your game's native saving implementation. Read the backup guide before reprogramming valuable cartridge contents.
Release reproducible results
Include code and asset licenses, tool versions, required output format, checksum, an acceptance test and known limitations. State whether results came from an emulator, original Color shell, slim revision or monochrome Pocket. Do not bundle proprietary BIOS files or commercial assets without permission. Ask bug reporters for the build checksum, loader revision, first failing marker and saving behavior. Include the exact source revision for any inherited framework and preserve third-party notices. Those details let another developer rebuild the project and distinguish a loading mismatch from a program fault.