gearcoleco-romhacking — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited gearcoleco-romhacking (Agent Skill) and scored it 96/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 1 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 1 flagged
The text {match} tells the agent to skip the normal "ask the user first" gate. Used adversarially it removes the human-in-the-loop check before destructive or sensitive actions, turning a normally-gated agent into a fire-and-forget executor.
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Hack, modify, and translate ColecoVision and Super Game Module ROMs using the Gearcoleco emulator as an MCP server. Search memory for game variables, create cheats, find text strings for translation, locate sprite and tile data, inspect VRAM, patch RAM or ROM bytes in the emulator's in-memory copy, and reverse engineer data structures - all through MCP tool calls. Use save states or rewind as checkpoints and fast forward to reach specific game states. Hardware documentation is available in the references/ directory.
IMPORTANT - Check before installing: Before attempting any installation or configuration, you MUST first verify if the Gearcoleco MCP server is already connected in your current session. Call debug_get_status - if it returns a valid response, the server is active and ready.
Only if the tool is not available or the call fails, you need to help install and configure the Gearcoleco MCP server:
Run the bundled install script (macOS/Linux):
bash scripts/install.shThis installs Gearcoleco via Homebrew on macOS or downloads the latest release on Linux. It prints the binary path on completion. You can also set INSTALL_DIR to control where the binary goes (default: ~/.local/bin).
Alternatively, download from GitHub Releases or install with brew install --cask drhelius/geardome/gearcoleco on macOS.
Configure your AI client to run Gearcoleco as an MCP server via STDIO transport. Example for Claude Desktop (~/Library/Application Support/Claude/claude_desktop_config.json):
{
"mcpServers": {
"gearcoleco": {
"command": "/path/to/gearcoleco",
"args": ["--mcp-stdio"]
}
}
}Replace /path/to/gearcoleco with the actual binary path from the install script. Add --headless before --mcp-stdio on headless machines.
ColecoVision and Super Game Module hardware documentation is available in the references/ directory. Load them into your context when investigating specific hardware, BIOS, memory-map, graphics, sound, or SGM behavior.
| Reference | File | Quality | Load when... |
|---|---|---|---|
| ColecoVision Technical Notes | references/colecovision.md | PRIMARY - system quick reference | Cartridge headers, title-screen behavior, controller modes, keypad codes, memory map, I/O map, basic SN76489 and VDP context |
| TMS9918A VDP (Sean Young) | references/tms9918a.md | PRIMARY - detailed VDP reference | VDP registers, status flags, VRAM access, display modes, interrupts, sprites, fifth-sprite flag, collisions, undocumented modes |
| SN76489A PSG | references/sn76489.md | PRIMARY - ColecoVision PSG quick reference | SN76489 latch/data writes, tone periods, attenuation, noise control, frequency formula, PSG debugging |
| Super Game Module Notes | references/super_game_module.md | PRIMARY - SGM memory reference | SGM RAM mapping, port $53, port $7F, ADAM compatibility, SGM initialization, SGM AY summary |
Memory search is the primary tool for ROM hacking. It uses a capture -> change -> compare cycle to isolate memory addresses holding game values.
1. list_memory_areas -> identify WRAM, SGM RAM, or another area ID
2. memory_search_capture -> snapshot current memory state
3. (change the value in-game using controller_button, fast forward, etc.)
4. memory_search -> compare against snapshot to find changed addresses
5. Repeat 2-4 until only a few candidates remain
6. read_memory / write_memory -> verify and modify the found addressesmemory_search supports these operators: <, >, ==, !=, <=, >=
Compare types:
previous - compare current value to last captured snapshot (most common)value - compare current value to a specific numberaddress - compare current value to value at another addressData types: hex, signed, unsigned
1. list_memory_areas -> find WRAM area ID
2. memory_search_capture -> snapshot with 3 lives
3. Lose a life in-game (play or use controller_button)
4. memory_search (operator: <, compare: previous) -> values that decreased
5. memory_search_capture -> snapshot with 2 lives
6. Lose another life
7. memory_search (operator: <, compare: previous) -> narrow further
8. Or use: memory_search (operator: ==, compare: value, value: 1)
-> find addresses holding exactly 1
9. write_memory on the candidate offset to set lives to 99
10. get_screenshot to verify the change took effectScore values are often stored as multi-byte (16-bit little-endian on Z80):
1. memory_search_capture -> snapshot at score 0
2. Score some points in-game
3. memory_search (operator: >, compare: previous) -> values that increased
4. memory_search_capture
5. Score more points
6. memory_search (operator: >, compare: previous) -> narrow down
7. read_memory on candidates - look for values matching current score
8. write_memory to set a custom scoreFor 16-bit values: the low byte is at address N, high byte at N+1 (Z80 is little-endian). Many ColecoVision games use BCD (Binary Coded Decimal) for score display - each nibble holds a single digit (e.g., score 1234 stored as $12 $34).
Use fast forward to speed through gameplay when you need to trigger in-game changes:
set_fast_forward_speed (4 = unlimited)
toggle_fast_forward (enabled: true)
(play through the game section)
toggle_fast_forward (enabled: false)This is essential when you need to reach specific game states without waiting in real time.
Save states are critical for ROM hacking - they let you save your position and retry modifications:
select_save_state_slot (1-5) -> pick a slot
save_state -> save current state
(try modifications)
load_state -> revert if something breaksUse different slots for different game states (e.g., slot 1 = start, slot 2 = boss fight, slot 3 = specific level).
list_save_state_slots shows all slots with ROM name, timestamp, and screenshot availability.
The emulator also records continuous snapshots into a rewind ring buffer. Use get_rewind_status to check availability, then rewind_seek to jump to any recorded point without manual save/load. This is especially useful for quickly reverting after a failed memory write - pause, seek back a few snapshots, and retry.
To find text strings for translation or modification:
read_memory across ROM areas scanning for known byte patternsmemory_find_bytes to search for specific byte sequencesset_breakpoint (read: true) to confirm they are read by the text rendering routineget_screenshot to correlate displayed text with memory contentsread_memory (VRAM area from list_memory_areas) to examine the tile patterns used for font renderinglist_sprites - view all 32 sprites with positions, sizes, and pattern indicesget_sprite_image - capture individual sprite images as PNGread_memory (VRAM area from list_memory_areas) - examine pattern generator, color table, name table, and sprite attribute table dataget_vdp_registers - check table base addresses and sprite mode bitsvram) on sprite or tile data to find the rendering codeget_screenshot before/after modifications to see visual changesThe TMS9918A uses VRAM for all graphics:
Use read_memory (VRAM area from list_memory_areas) with base addresses from get_vdp_registers to access these. Use references/tms9918a.md for mode-specific table rules.
debug_pause -> get_disassembly around code that loads dataread_memory at the target offsets to dump table contentsadd_memory_bookmark to mark discovered data regionsadd_symbol to label data table entry points for future reference1. Find the address using the search loop (above)
2. Set a write breakpoint: set_breakpoint (write: true) on the logical address
3. debug_continue -> when it hits, get_disassembly to see the decrement code
4. Note the instruction (e.g., DEC (HL) or LD (addr),A)
5. Option A: Periodically write_memory to reset the value (simple poke cheat)
6. Option B: Identify the decrement routine for a NOP patchUse add_memory_watch on discovered offsets. Watches appear in the emulator's GUI memory editor, letting you monitor values as the game runs - useful for verifying cheats work across different game situations.
The most powerful cheat-finding technique:
set_breakpoint (write: true) on that logical addressdebug_continue - the emulator stops when the game writes to that addressget_z80_status + get_disassembly reveals the exact code modifying the valueget_call_stack shows what triggered the writeget_screenshot of a screen with textread_memory (VRAM area) - find tile patterns used for font charactersget_disassembly to find the character mapping table (byte value -> tile index)add_symbol to label the font table and rendering routineread_memory with large rangesmemory_find_bytes to search for known byte patternsadd_memory_bookmark to mark each string locationROM hacking translations must fit within existing space:
read_memory to determine how much space each string occupies$00, $FF, delimiter bytes, or length-prefixed strings)write_memory to patch translated strings into memoryget_screenshot to verify renderingsave_state before each change so you can load_state if it breaksUse list_memory_areas to get the full list. Key logical areas:
| Area | Description | Typical Use |
|---|---|---|
rom_ram | Full Z80 64K address space | General game code and variables |
vram | Video RAM (16 KB) | Pattern tables, nametable, color table, sprite tables |
vdp_reg | VDP registers | Display configuration |
| Address | Content |
|---|---|
$0000-$1FFF | BIOS ROM (or optional SGM lower RAM when mapped) |
$0066 | NMI handler vector (VDP VBlank path) |
$2000-$5FFF | Expansion area / SGM upper RAM when enabled |
$6000-$63FF | Internal 1 KB work RAM |
$6400-$7FFF | Internal RAM mirrors, or SGM upper RAM when enabled |
$8000-$FFFF | Cartridge ROM |
Internal RAM ($6000-$63FF, mirrored to $7FFF) is the most common location for game variables in non-SGM games. SGM games may use the 24 KB upper RAM window at $2000-$7FFF after enabling it through port $53. Load references/super_game_module.md before modifying SGM memory or port $7F BIOS/RAM mapping.
Keep your hacking session organized:
add_memory_bookmark - mark discovered data regions, variable locations, string tablesadd_memory_watch - track values that change during gameplayadd_symbol - label addresses in disassembly for readabilityadd_disassembler_bookmark - mark code routines you have identifiedUse list_memory_bookmarks, list_memory_watches, list_symbols, list_disassembler_bookmarks to review.
Changes made via write_memory to ROM areas are applied to the emulator's in-memory copy only - they are not persisted to the ROM file on disk. To create a permanent patch, use command-line tools (for example, a binary patch script) to apply the discovered modifications to the actual ROM file.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.