Choose an actual Lynx target
The cc65 Lynx target documentation describes cartridge output and a separate BLL-compatible download configuration. These formats are not interchangeable just because both are binary files. Start with the target's documented examples and linker configuration; a generic 6502 program does not automatically include the startup and hardware setup a Lynx needs.
Pin the compiler version, library revision, configuration and example commit. Build an unchanged example first and retain its command line, log, output size and checksum. If that sample does not run, resolve the tool or loading arrangement before adding a graphics engine. Begin development with one visible title string, simple sprite or controlled input response that makes success unambiguous.
Select the loading route deliberately
A cartridge image can be tested through a documented compatible flash cartridge. A serial upload workflow needs its corresponding resident loader and cable arrangement. The developer-written cc65 uploader chapter explains BLL and ComLynx uploading. Do not connect an improvised cable from a pinout remembered for another console; use the exact documented interface and verified hardware.
For ElCheapoSD, use the cartridge maker's firmware and boot-menu downloads and instructions matching your revision. Keep cartridge firmware distinct from a menu program. A later menu is not automatically a firmware update, and firmware for another BennVenn product must not be flashed to this one. Record which boot files and card layout produced a successful test.
Commission a flash cartridge in small steps
- Verify that the console already boots an original cartridge reliably.
- Identify the flash cartridge, firmware and supported card format or transfer method.
- Back up its existing card and configuration before changing either.
- Load one creator-authorized homebrew sample in the supported format.
- Test a cold boot, input, a later transition and normal shutdown.
- Add further programs only after the first sample works repeatedly.
A filename extension is not proof of the expected header or cartridge layout. Keep the author's original archive and release notes, and perform conversions on a copy. Compare a failing program's declared memory requirements and output format with the loader's actual support. Do not describe an emulator-only executable as compatible with physical hardware without a hardware test.
Test more than the title screen
Use a fixed sequence covering drawing, sound, input and any file or save operation. Record emulator version separately from physical results. An emulator helps single-step a failure, but cannot establish that a homemade connector or serial cable is correct. For a release, include tool versions, code and asset licenses, checksum, required loading route and tested model. Retain failures with their last visible marker so another developer can reproduce them.
Publish only code, assets and firmware you may redistribute. Keep commercial backups and console ROMs separate from original homebrew packages. Continue with testing and preservation to maintain a reproducible archive.