6.2 KiB
ALTTP Dungeon Object WRAM Usage (Initial Pass)
Heuristic scan: first 64 bytes of all dungeon object handlers (Type1/2/3) from zelda3.sfc, looking for absolute/long accesses to $7E:*. This is a starting point; many handlers use indirect addressing, so manual tracing is still required.
Observed WRAM Touches (by handler)
Handler $01:A7A3
| Offset | Op | WRAM |
|---|---|---|
| 0x30 | AF | $7EF0CA |
Handler $01:A7B6
| Offset | Op | WRAM |
|---|---|---|
| 0x1D | AF | $7EF0CA |
Handler $01:A7D3
| Offset | Op | WRAM |
|---|---|---|
| 0x00 | AF | $7EF0CA |
Next Steps
- Manually trace key handlers (e.g., Type1 $01:8B89, $01:8AA3; Type2 $01:97ED; Type3 $01:9C3E, $01:9895) to capture indirect $7E accesses and required initialization (tilemaps, offsets, flags).
- Expand scan window beyond 64 bytes and follow subroutine calls to capture deeper WRAM dependencies.
- Cross-reference accesses with known tilemap buffers ($7E2000/$7E4000), offsets ($7E049C/$7E049E), drawing flags ($7E0476), object ptrs ($7E00B7-B9), room state ($7E00AF/$7E00A0), and any temp work areas the handlers expect.
- For future state-injection (“load me into dungeon X with items Y”): map and annotate inventory/state WRAM (sword/shield/armor bits, small keys, big key, map/compass, heart count, rupees/bombs/arrows, crystal/pendant flags), Link position ($7E22–$7E2A ranges), camera offsets, submodule/state machine bytes. Use emulator save-state comparisons to seed defaults if not present in handlers.
Seeded Known Addresses (to verify/expand)
- Room/submodule:
$7E00A0(submodule/floor),$7E00AF(room ID) - Object data pointer:
$7E00B7-$7E00B9(24-bit pointer) - Drawing flags/context:
$7E0476 - Tilemap offsets:
$7E049C(X),$7E049E(Y) - Tilemap buffers:
$7E2000-$7E3FFF(BG1),$7E4000-$7E5FFF(BG2) - Temp/dungeon draw scratch (from handler traces, needs confirmation):
$7E7E21-$7E7E26– frequently touched across handlers (likely temp counters/coords)$7E7E71,$7E7EAA,$7E7EAD,$7E7ED1– sparse temps/state flags$7E7E22A8,$7E7E2BB2,$7E7E411E– long addresses referenced; verify if pointer tables/accumulators$7E7EC000-$7E7EC7FFregion – heavily used; appears to be work buffers (coords, queues, staging). Needs field-by-field labeling.$7E7EF0CA,$7E7EF3CA– high WRAM touched by A7xx/B3xx handlers; likely state or decompression buffers.
Data to Capture (for emulator state injection)
- Link position and camera: positions/velocities, camera scroll, room boundaries
- Inventory & flags: sword/shield/armor upgrades, small keys, big key, map/compass, rupees/bombs/arrows, bottle contents, pendant/crystal flags, boss defeat flags
- UI/graphics state: HUD counters, palette state, tilemap/CHR load state tied to dungeon/overworld room
- State machine: submodule/module bytes that gate movement/control and loading paths
Suggested Capture Workflow
- Select a target handler (e.g., Type1 $01:8B89) and run a trace for 256–512 bytes including subroutine calls; log all $7E accesses (direct and via indexed/indirect).
- In emulator, save two WRAM snapshots: before/after drawing a known object; diff to identify required fields. Repeat for a few object classes (floors, walls, special objects).
- Populate this doc with verified addresses: name, size, purpose, default/init value, “required for preview?” flag, and “required for state-injection?” flag.
- Once core init set is stable, script a minimal WRAM initializer for the emulator preview and for “load me into dungeon X with items Y” (inventory/state injection).
Static Scan (first 256 bytes per handler)
Heuristic, direct $7E absolute/long accesses found in the first 256 bytes of each handler:
- $01:9DD9 → $7E7E22
- $01:9DE5 → $7E7E22, $7E7E23
- $01:9E30 → $7E7E22, $7E7E23
- $01:9EA3 → $7E7E22, $7E7E23
- $01:A095 → $7E7E21
- $01:A71C → $7EF0CA
- $01:A74A → $7EF0CA
- $01:A7A3 → $7EF0CA
- $01:A7B6 → $7EF0CA
- $01:A7D3 → $7EF0CA
- $01:B306 → $7EF3CA
- $01:B30B → $7EF3CA
- $01:B310 → $7EF3CA
- $01:B376 → $7EF3CA
- $01:B381 → $7EF3CA
- $01:B395 → $7EF3CA
These are starting points only; many handlers use indexed/indirect addressing and deeper subroutines that won’t show up in this static slice. Follow-up tracing is required to confirm purpose and defaults.
Focus Handlers (1KB trace + subcalls, depth 3)
Direct $7E touches seen for each representative handler. Next step: label, size, and defaults via save-state diffs.
Type1 $01:8B89 (obj 0x000)
Touches include:
- Low scratch:
$7E7E21-$7E7E26,$7E7E71,$7E7EAA,$7E7EAD,$7E7ED1 - Work buffers:
$7E7EC000-$7E7EC7FF(numerous fields),$7E7EF051,$7E7EF0CA,$7E7EF282,$7E7EF2BB,$7E7EF2C3,$7E7EF2F0,$7E7EF2FB,$7E7EF340-$7E7EF37B,$7E7EF3C5-$7E7EF4FE
Type1 $01:8AA3 (common handler)
Touches mirror 8B89: $7E7E21-$7E7E26, $7E7E71, $7E7EAA, $7E7EAD, $7E7ED1, wide $7E7EC*** work buffers, $7E7EF0CA, $7E7EF34x block, $7E7EF3C5+, $7E7EF4FE.
Type2 $01:97ED
Touches: $7E7E21-$7E7E26, $7E7ED1, $7E7E3F1E, $7E7E9059, many $7E7EC000+ fields, $7E7EC3DC/DE/F6/F8, $7E7EC4FA, $7E7EC5DA+, $7E7EC7F2/7F4, $7E7EC832/834, $7E7EF0CA, $7E7EF282, $7E7EF2BB, $7E7EF2C3, $7E7EF2F0, $7E7EF2FB, $7E7EF340-$7E7EF37B, $7E7EF3C5-$7E7EF3D3, $7E7EF403, $7E7EF4FE.
Type3 $01:9C3E
Touches: $7E7E21-$7E7E26, $7E7ED1, $7E7E0709, $7E7E3F1E, $7E7EC000+ region, $7E7EC3DC/DE/F6/F8, $7E7EC4FA, $7E7EC5DA+, $7E7EC7F2/7F4, $7E7EC832/834, $7E7EF0CA, $7E7EF282, $7E7EF2BB, $7E7EF2C3, $7E7EF2F0, $7E7EF2FB, $7E7EF300, $7E7EF340-$7E7EF379, $7E7EF3C5-$7E7EF3D3, $7E7EF403, $7E7EF4FE.
Type3 $01:9895
Touches similar to 9C3E/97ED: $7E7E21-$7E7E26, $7E7ED1, $7E7E3F1E, $7E7E9059, $7E7EC000+, $7E7EC3DC/DE/F6/F8, $7E7EC4FA, $7E7EC5DA+, $7E7EC7F2/7F4, $7E7EC832/834, $7E7EF0CA, $7E7EF282, $7E7EF2BB, $7E7EF2C3, $7E7EF2F0, $7E7EF2FB, $7E7EF340-$7E7EF37B, $7E7EF3C5-$7E7EF3D3, $7E7EF403, $7E7EF4FE.
Labeling needed: Map each address to meaning (coord, size, flags, palette, queues, staging buffers). Use emulator WRAM diffs around object draws and known state toggles to confirm.