The owner's observation that flying transports are missing is valid, but the earlier P18 preview confused one-based script words with zero-based sprite images. The source-backed first images are type $11 → script $0040 → bitmap $03F (purple creature) and type $26 (decimal 38) → script $005E → bitmap $05D (ostrich/bird). Type $21 instead starts script $0055 → bitmap $054 and later contains $005D → bitmap $05C, a different image. Type $2B starts $005F → bitmap $05E, not the ostrich. All these bitmaps originate in the user's opened Disk.1.

New source reconstruction: the previously unresolved actor type $26 animation pointer RAM $0B006 is now connected to Disk $8AF90. Native $95 decompression from that source yields 64/64 identical bytes in the user's Stage 1_1.uss RAM. This adds one code-verified first-segment source to the earlier 39/46 set (now 40/46). The bird bitmap $05D is therefore a game-referenced frame. Actor $26 has no direct level-start placements; this does not establish whether the original game creates it dynamically, or its parent.

Original generator request buttons also show a preceding $FE argument (for example, 25 in variant $06), where present. Its unit and whether that request executes are still unverified. The original type $11 has four direct placements and is also requested by 53 stock generators (native selector $01). This makes the rider a useful live review case. There is no established retail link proving $11 and $26 are simultaneously attached. A visually paired bird/rider, its +4px review offset, and its spawn position remain hypotheses. New v0.12 editor options render the real rider and bird as two separate layers and support a manually selected companion image for either a direct placement or an individual generator request. A manual pairing can be cleared and exported as review JSON only, never into Disk.1. Generator opening/closing, and optional child-request cycles, are preserved from v0.11.

Corrected preview, original source preserved: The true type $03 script at RAM $061A8 / Disk $86121 is $A6,$A6,$A5,$A4,$A3,$A2,$8048,$A1,$A1,$A2,$A3,$A4,$A5,$A6,$8048, and the one-based renderer maps these to bitmaps $A5,$A5,$A4,$A3,$A2,$A1 followed by $A0,$A0,$A1,$A2,$A3,$A4,$A5. The native $8048 handler does not request a pause: it clears two actor counters and advances the script cursor. The artificial v0.10 dwell on bitmap $A1 was editor behaviour, not native gameplay. The v0.11 preview progresses to bitmap $A0 and, for visual clarity, places its illustrative dwell there. Neither the dwell duration nor retail open/close trigger has been established.

Generated enemy overlay: When enabled, an independent layer at each generator source anchor previews children from the source descriptor's lexical actor-request list. A new selector provides Off, Cycle requests and Selected request modes; the right-side generator review lists the same native request tokens and lets the user pin one. Variant $06 is particularly useful: its original request types in source order are $04,$04,$05,$06. The child cycles through first-segment native candidate frames, drawn over the door at the parent source anchor without inventing a +18px spawn offset. It is not proof that the game emits those requests on a periodic timer, spawns the child at that pixel coordinate, or gives it that precise pose. No original bytes are changed. The original generator animation stays independently visible.

Retail-code verified: animation stream image numbers are one-based. The original graphics dispatch subtracts 1 at RAM $0BF80 (Disk $8BEE0) before looking up a 16-byte descriptor, so a script image $N displays decoded bitmap $N−1 for positive $N. Example initial Tiki $001 → bitmap $000; actor $04 $06F → $06E, $05 $079 → $078, $06 $082 → $081. The idle/walk meaning of Tiki $000 remains a separate state-selection investigation. A script value $0000 is NOT an instruction to wrap to image $FF. The animation-script interpreter, actor types and raw disk data remain unchanged.

Generator $03: its raw source stream Disk $86121, RAM $061A8, contains two $8048-separated graphic phases: $A6,$A6,$A5,$A4,$A3,$A2 and $A1,$A1,$A2,$A3,$A4,$A5,$A6. Original renderer conversion yields opening bitmap $A5,$A5,$A4,$A3,$A2,$A1, closing bitmap $A0,$A0,$A1,$A2,$A3,$A4,$A5. The first child-request token in the generator descriptor names a separately spawned actor and MUST NEVER be used as the generator's own visible frame. The editor animates the original door frames by default; optional generated-child animations are independent visual candidates, not native spawn simulation. As established in v0.11, the $8048 instruction resets actor counters; it does not specify a dwell on $A1. Opening/closing semantic labels reflect the image content, while timing and native branch activation still need behavioural verification.

Collectibles: The $1F 17-word native source lookup at RAM $07558 is also one-based. The image word $BD at slot 8 renders bitmap $BC, not bitmap $BD; native source word $BE at slot 16 renders bitmap $BD. Whether gameplay selects slot 16 is unproved; original direct placement parameter sets do not include literal $10. This resolves why calling $BD a slot-8 graphic was wrong. The $20 native $CA–$CF word sequence draws bitmaps $C9–$CE. Do not create collectible gameplay data from artwork indexes without proving the parameter-to-slot branch.

Unresolved systems (not discarded): initial enemy orientation and state; exact generator timing, delays, chains and respawn; projectile object construction versus placing the projectile at level start; the five $02 boss objective placements and possible dynamic actor $25 enclosure relation; rideable/flying transport compositions, and warp special routing beyond the ordinary 12 links. See Further Investigations.

Current source authority: user's original Disk.1 SHA256 fec7ce66934497b65745aa658599bdc697cf0ea0111d77d211fce3f48e27b416 and Stage 1_1.uss, cross-tested against native source windows. All app/ art and level contents are decoded from the opened disk; Wiki PNGs are documentation only.

Tiki correction: the user identifies frame $000 as standing Tiki. His earlier observation that $001 may begin walking was mistakenly interpreted as a requirement to replace the first Tiki graphic. The original type $00 animation script at Disk $8AEE6 begins $001,$001,$002,$002,$001,$001,$003,$003,$8000; this proves a source-script sequence, not the absence of $000 as an idle state or its separate selector. The editor restores $000 to the start of Tiki's gallery and default standing preview. Do not reinstate the incorrect P17 $001-as-standing interpretation.

The compressed 432-byte source at Disk $85C07..$85DB6 has 19 original variants (18 used). Each descriptor begins with a horizontal/vertical absolute-distance threshold. The game scanner RAM $05FD2 checks both before creating a child. The source scripts contain multiple actor-request records in many variants. The actor factory RAM $05872 consumes two bytes after a positive request type, so lexical inspection can recover request triplets without simulating the negative control opcodes. Examples:

$FC, $FD, $FE, $FF are real native control bytes; $FE has one delay byte. An encoded request list is not an executed spawn chronology: $FF reload, $FD state changes, scheduler conditions, occupancy and player movement must be traced before asserting which creatures appear, when, facing which direction or in what quantities. The editor displays requests in read-only inspection and the verified rectangular distance thresholds; the highlighted rectangle is not the same as a patrolling range or guaranteed visible zone.

The P09 ordinary table contains 12 configured source→destination links, derived from the native $95-RLE range Disk $84B14..$84B7F. The editor now lists outgoing and incoming links for each level. Clicking an IN opens the linked OUT source stage and highlights its source anchor; clicking an OUT opens the linked IN target stage and highlights its destination. Navigation also works across folded Worlds. The target's destination fields are raw pixel/position values and remain provisionally projected; no origin/arrival bytes are edited. Eight all-zero rows denote absence of ordinary-table transitions only; special 4-4b rescue and boss transitions are separate systems.

Source scripts for actor types $21,$22,$23,$25,$27 each include image $5D. The user's recognised artwork $3F/$40 is a purple rider; $5D depicts a flying ostrich-like transport. Image $40 is present in type $11's first native script. This supports keeping rider and transport available separately in the gallery; it does not prove a particular composite, vertical offset, initial combination or which actor owns a rider at any given time. There is one direct stock type $21 placement on 1-2 at (37,23); no direct type $25 placement. An optional read-only art toggle can show $5D at that type $21 anchor for review rather than overwriting the native script or claiming an exact startup frame.

Type $02 occurs once in each boss-ending _4 stage: five source placements. The original type $25 has zero direct placements in the 599 stock records, although it is present in the 46-entry native dispatch table and its animation stream refers to $5D. Thus the user's observation of “object $25” as a closure trigger is an important lead, not yet identified as a source type-$25 placement. Determine whether $25 denotes a different object, dynamic actor, image or control field. The closed-arena trigger and boss sprite assignments require additional original-code work.

Bullets/effects can be spawned by code: type $06 installs a secondary $8C–$8F animation (P15). There is no verified mechanism for declaring arbitrary bullet objects as four-byte start placements; adding them is not safe given contiguous entity lists and unknown factory requirements. The P18 editor allows visual-only placement of any frame on any current map for testing, without adding entity records or enabling writes.

Map headers at map offset − $80 declare width (+$02) and active height (+$04); all 21 raw storage grids hold 64×64 cells. For level 1-1, native header at Disk $18C00 states 64×14, not 64×17; the user's 17-row impression could involve camera rows or display composition, but the native header must not be changed until rendering logic is traced. Special 4-4 and 4-4b each declare 64×48, and have distinct classification tables.

The owner identified several presentation offsets, not defects in the 289-image source decoder. Original artwork and descriptor offsets still decode from the user-opened Disk.1 only. The reviewed display defaults are: Tiki $000 standing (P18 correction; $001 begins the first source script), caged kiwi $D9 before the first rescue/end animation $DA, and bonus browsing $C9..$CF (the native $20 script still explicitly starts $CA and has six original referenced images). The editor now uses $D9 as the provisional displayed bitmap for type $01/$02 objective placements rather than treating their first script frame $DA as a static captive kiwi. That is a visual distinction, not a proof of object lifecycle or an alteration to the source script.

The native $03 source script's first image words actually include $A6,$A5,$A4.... The owner reports $A6 is enemy art and requests the reviewed visual grouping to begin $A7. Therefore the browser presents a separate reviewed $A7..$AA group, while preserving a distinct RAW native script $03 listing with all its real words. Neither may be misrepresented as the other's source. Likewise type $05's artwork must not be truncated after movement frames or combined into one undifferentiated creature: $78..$7C movement, $7D..$7E death/debris and $7F..$80 firing/projectiles are now separate owner-reviewed visual groups as well as a combined $78..$80 family shown when inspecting type $05. Original native $05's initial script segment is still $79..$7D; later referenced graphics remain source data, not guaranteed animation states.

The 12 existing ordinary source warps can display the original two-frame $28/$29 animated warp artwork over their source points. The native directory's signed drawing offsets are applied; exact trigger-to-art positioning is still provisional. Incoming warp markers remain visible because their destination projection is not independently proved. The game does not store extra placement sprite IDs inside the ordinary warp rows.

Native-script source match: the 19 $03 generator variants can now be decoded from their original $95-RLE descriptor block on Disk $85C07..$85DB6, yielding 432 source-backed bytes (savestate RAM $05C90..$05E3F). In all 19 native scripts the first byte after the two activation-distance words is $FC, followed by the original first actor-request type. The common factory code invoked by the scheduler already establishes that this following value is an actor-type request, not an image number. The first actor IDs in variant order 0–18 are $0A,$11,$17,$0C,$16,$0D,$04,$06,$14,$0B,$08,$13,$12,$15,$0E,$0F,$10,$08,$17. 298/298 original generators resolve to one of these descriptors. The first requested actor can have a native animation script and a candidate bitmap from the same Disk.1. The image selection and sprite positioning remain preview hypotheses—the game creates a movable child, and the generator may trigger subsequent script requests rather than producing only one creature.

Editor behaviour: enable Original graphics on map and Preview generator children to render candidate child sprites over generator anchors, using the native sprite directory's signed drawing offsets. They are lower-opacity than directly placed actor graphics; disabling the child-preview toggle reveals source markers without changing the level. Selecting a native generator in Inspect entities exposes its variant, first requested actor type and proximity thresholds. Any per-placement image override is a browser-only review observation, never a writable source record. Existing owner-confirmed actor $04/$05/$06 leading frames and direct hero $00 animation references remain separate from the generic generator scripts.

Collectibles, not enemy actors: type $1F is the directly placed fruit/item family (29 records), while $20 is the six-parameter letter/bonus family (30 records). Their original $1F stream lists non-sequential item images, while the indexed visual item category now covers $B0..$C8; bonus browsing adds $C9 before the native $20 script family $CA..$CF; all original image pixels now decode from Disk.1 alone. Some $1F records may choose an alternate frame or animate dynamically; the precise per-instance type+parameter→image selection remains unproved. The editor must make the full image catalogue available, not artificially stop $1F at $BD. $BD is part of this set, whether or not the owner has previously encountered it in retail gameplay.

Corrected indexed collectible sequence: the first 17 consecutive big-endian words of type $1F's source at Disk $874CE are original image IDs in a non-numeric order:

slot  00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10
image B0 B1 B2 B3 B4 B5 B6 B7 BD B9 BA BF BC B8 BB C0 BE

In particular, image $BD is slot 8, whereas slot 13 (decimal) is $B8. The P13 assumption image = $B0 + slot is disproved for slots 8 and above. This proves image-table order, not the runtime relationship between the placement fourth byte and the selection slot; the P14 inspector labels any mapped image a candidate. The 29 stock $1F records still contain only parameter bytes $00,$02,$03,$06,$40,$41,$46 (high $40 semantics unresolved). The first six $20 words at Disk $87518 remain $CA..$CF and do not prove parameter→image either.

Test placement: viewer can place a temporary non-exportable visual projection of arbitrary selected image including $BD onto 1-1 by clicking its map. It DOES NOT insert a four-byte record or produce a playable collectible. To add a real $BD pickup will require proving its $1F parameter selection and either safe same-size record substitution with in-game tests or a controlled new-list relocation, given the packed 599-record block. No guess-based save path is enabled.

Scope: P14 independently matches 64 original decompressed bytes to live RAM for 39/46 actor-type sequences. Seven types $08,$1B,$1C,$1D,$1E,$24,$26 remain unproven source-offset cases, not "missing sprite images" — all 289 original image records are still available in the catalogue.

Creature identity and animation bounds (P15 correction): the owner identifies the leading original bitmap one image before the first ordinary image in the native actor stream: type $04 starts visually at $6E, $05 at $78, and $06 at $81. These leading frames are source-derived graphics, but their use as an idle/initial runtime state remains owner identification, not an independently traced instruction. The first straight-line source-script segments remain $6F..$73, $79..$7D and $82..$84, respectively. P15 has additionally decoded each complete, source-backed script-data envelope, including words after reset/branch commands. This proves source references, not that all referenced images depict the same creature or are seen in one animation. The source type $05 envelope references images through $81; the artwork at $81 is the owner-identified leading frame of type $06, so it must not be merged into the type $05 species group. The editor explicitly separates creature art from later effects and other images.

Owner-observed type $04 phases (not native trigger proof): $6E–$70 standing/walking; $71–$72 firing; $73–$74 death; $75–$77 weapon/projectile-related graphics (potentially a separate entity). Labels are provisional; $76/$77 are not demonstrated to occur in the type $04's bounded source stream. Other types' animation phases need gameplay validation.

Original image $8D is referenced in native game code, not an orphan collectible. Native type $06 handler code stores pointer $0000838E into +$14(A4) of a secondary object. The pointed-to word stream at RAM $0838E contains 008C 008D 008E 008F 8000. Image $8D is a source-decoded 23×10 curved red/orange graphic with hotspot (-12,-2); visually it belongs with a projectile/effect-like family, not with collectible $1F or $20. There are 15 direct source type-$06 placements, including four on level 1-1: (34,6), (49,10), (50,7), (51,4) (source offsets $8CFFE,$8D00E,$8D012,$8D016). The native code associates $8D with this secondary animation, but the event that causes it to appear and its live position have not been observed. Do not render $8D at the parent position as a definite gameplay object or assume it is a new collectible. There is no identified independent placed $8D collectible record. Details and exact source opcode addresses: Game Code and Runtime.

The original game animation interpreter (RAM $0B3F0) and image directory ($039AA6) now establish native moving graphics, rather than speculative bitmap probes. Original Disk.1 opcode bytes match the game-running RAM routine that resolves the descriptor and blits loaded data; P12 first decoded the bitmaps from Stage 1_1.uss, and P13 decoded all 289 independently from original Disk.1. See Game Code and Runtime for exact 16-byte descriptor, mask + four plane-major colour bands, palette and reproducer.

Distinguish two certainty levels. That these bitmap images are original, and that the animation families contain these IDs, is confirmed by native RAM and executable source matches. The precise image chosen at an arbitrary placement and the animation phase are not confirmed. The editor's optional artwork layer uses a clearly labelled source-table candidate or first linear-script pose; these are not asserted correct for every $1F/$20 record. The user can select a source placement in Inspect entities, choose any of the 289 native frames and apply a temporary per-placement review override, then export observations as JSON without editing Disk.1. Generator type $03 contains a script selecting a child actor; draw a generator marker until its full script→actor mapping is proved, never an arbitrary monster.

The owner has re-examined the v0.3 map and believes existing entity points look correct. Keep current original coordinates and default projection intact. Signed sprite descriptor hotspot fields enable eventual exact BOB origin comparison; any future alignment change must be based on source consumers and owner-tested gameplay, not an assumed whole-tile displacement.

IMPORTANT — supersedes P04–P08 claims that no actual warp source/destination records are known. We have identified and code-traced a separate native stage-transition system that is neither the $00 start entry, $01/$02 goal, $03 creature-generator, nor the header +$0E/+10 coordinate pair. It comprises 20 original eight-byte entries (one per normal selectable stage), with 12 populated and 8 zero. This is a verified engine-consumed transition table, not yet an in-game-validated complete list of every secret/warp mechanism. User confirms known departures in World 1 and the special rescued-kiwi outcome on 4-4. See Code and Runtime for original instructions and their matched disk addresses.

Native table: RAM $04B02..$04BA1, 20 × 8 bytes. Original disk stream $84B14..$84B7F (108 packed bytes); the precise stream reconstruction is in Disk and Binary Layout. There is no universal 1:1 file offset for a later row because the file stream uses run-length encoding for zero sections. The stage index stored at +$08(A6) is stage number × $10, which is ASR-shifted once to select an eight-byte table entry. 4-4b is selected through its separate special-area flag and is not an ordinary 21st row.

The active 10-byte RAM working record is at $04AF8, immediately preceding the 20-row table. It has X/Y at +0/+1; +2 is initially set to 5 by the stage-select routine (runtime status / gate, not part of the eight-byte source row), +3 is a working/reserved byte, destination stage at +4, and destination X/Y at +6..+9. The original stage setup explicitly sets active +2 to zero when special mode $26(A6) is on. Do not mark type $03 generator 'doors' as warp portals.

Eight all-zero ordinary stage rows: 3-1, 3-3, 3-4, 4-2, 4-3, 5-2, 5-3, 5-4. An all-zero row means this table has no configured transition on that stage. It does not prove absence of boss travel, rescued-kiwi transitions, warps via another subsystem, or later hidden routes. Each populated row is individually captured in research/P09_warp_table_all_20.csv with machine-readable JSON as a second format.

Direct matches to the owner's gameplay observations: 1-1, 1-2, 1-3 and 1-4 each have a non-zero departure record. In particular, 1-1 goes to 1-4 (destination stage $0030) and 2-1 goes to 3-4 (destination $00B0), providing a source-backed candidate for one of the 3-4 re-entry paths. 1-2, 2-2, 2-3 and 5-1 target themselves at different native positions; treat these as same-stage transitions, not errors.

Not present in the 20-row table: a destination of 1-3; a dedicated source entry for 4-4b; any nonzero entries on 3-4 or 5-3. If the owner's remembered additional arrivals in 1-3 or departures later in the game are confirmed, they will require searching other mechanisms. This table establishes one named transition record per normal stage, not a universal limit of one warp per map.

• visuals/03_native_warp_table_all_20.png — all 20 decoded slots and addresses, with the inactive rows clearly greyed.
• visuals/01_transition_source_<stage>.png — 12 authentic tile maps; the amber OUT marker corresponds to the table's two source bytes, not to generic spawns or header fields.
• visuals/02_transition_arrivals_<stage>.png — incoming native X/Y plotted as approximate pixel-like coordinates over target levels (requires retail visual confirmation of exact origin).
• visuals/05_transition_links_by_world.png — the actual 12 configured stock links without hypothetical arrows.
• visuals/06_header_vs_real_arrivals.png — contrasts code-backed destination coordinates with unrelated per-map header pairs, so no yellow-marker conflation.

User-observed gameplay authority: rescuing the trapped kiwi on 4-4 triggers 4-4b instead of the usual boss. P08 independently proved native 4-4b special-area flag +$26(A6), separate placement list and tile classification. New P09: the ordinary 4-4 transition row (29,6) -> 5-1 is a different mechanism from the rescue-to-4-4b outcome; P09 stage setup suppresses the ordinary warp's active gate when special mode is on. The two must be represented separately in the editor. The exact objective rescue -> special loader caller and arrival location remain to be proved in original code. Do not invent a 4-4b departure tile by copying either $01/$02 goal or the ordinary warp row.

Editing constraint: this page is data/research only. Do not yet enable changes to warp source/destination records, stage index or 4-4b source. The packed source stream and source decoder are not an approved encoder for editing; the destination writer and warp activation must be accepted in real WHDLoad first.

Verified native 68000 branch: normal setup clears word +$26(A6) at RAM $040B8 (42 6E 00 26). An alternative stage-loading path at RAM $04632 executes ST.B $0026(A6) (50 EE 00 26), then RAM $04636 executes BRA.W $040BE, deliberately bypassing the normal reset at $040B8. These instructions match Disk.1 near $8464C and $84650. The same nonzero flag is tested by two independent source-matched consumers:

• RAM $0421E: TST.W $26(A6); BEQ ...; LEA $0000DA3A,A2 at $04224. This overrides the ordinary stage object list with the 4-4b list.
• RAM $0AE70: the same TST.W/BEQ/LEA $0000DA3A,A2 choice before consuming the first list word; second native consumer of the same special list.
• RAM $0C7E2: TST.W $26(A6); BEQ ...; LEA $0000CFC2,A2 at $0C7E6; substitutes a different tile-classification table in special mode.

Thus 4-4b is not merely unused alternative scenery. It has independent native entity-list and collision/classification-table routes, selected by a single game-state flag. Original 4-4 lists: Disk $8D730 with 22 records, 12 generators; 4-4b: Disk $8D78C with 30 records, 14 generators. Their respective maps are stored at $5D880 and $5EE80. The special classification system itself is also distinct: ordinary 4-4 has 20 native classification words at RAM $CF98 whereas 4-4b has 56 at $CFC2; both are $AAAA-terminated. The exact event that activates the special load, whether it is a warp, and its physical entrance/arrival coordinates are not established. The code and labelled side-by-side map image visuals_P08/01_4_4_special_area_comparison.png should be used for owner validation; it does not invent a warp pin.

This result narrows the search for 4-4b travel to the callback installed at RAM $045EC (runtime function $045FE stored at $06459A) and its upstream activation. The alternate stage-loader sequence at RAM $04624 uses MOVEQ #$45,D0 ahead of a loader call at $04628, which is an exact code-level fact; the identity of resource $45 and source of the destination tile-map pointer are not yet proven.

P07 confirmed 32 entries of $10 bytes for native type $03 generators. New P08: the actor allocator called by the generator scheduler at RAM $06010 is RAM $06050 (source Disk $85FC9). It has a separate five-slot limit:

06050  47 F9 00 06 55 98   LEA    $00065598,A3    ; actor slots
06056  70 04               MOVEQ  #4,D0           ; 5 trials via DBF
06058  4A AB 00 18         TST.L  $18(A3)         ; active callback?
0605C  67 0C               BEQ    free
0605E  47 EB 00 3A         LEA    $3A(A3),A3      ; 58-byte record stride
06062  51 C8 FF F4         DBF    D0,$06058
06066  70 00               MOVEQ  #0,D0           ; no free slot
06068  4E 75               RTS
0606A  2F 0B               MOVE.L A3,-(A7)       ; free-slot path
0606C  30 3C 00 39         MOVE.W #$39,D0        ; clear 58 bytes
06070  42 1B               CLR.B  (A3)+
06072  51 C8 FF FC         DBF    D0,$06070
06076  26 5F               MOVEA.L (A7)+,A3
06078  70 FF               MOVEQ  #-1,D0          ; success

The generator caller uses BSR.W at RAM $06010 and branches if the allocator returned zero. Do not conflate five concurrent child actors with the number of generator definitions (32) or with the whole game's potential enemy count. This allocator could be specific to this family; other actor pools exist until disproved. It nevertheless limits what increasing generator density can accomplish without further code changes. All 44 bytes at allocator $06050 match original disk $85FC9.

New evidence-only overlays visuals_P08/03_direct_actors_*.png show each direct source type $04..$2D at its stored tile coordinate, with type number and no invented creature/warp meaning. Nine maps cover 2-4, 3-4, 4-3, 4-4, 4-4b, 5-1, 5-2, 5-3, 5-4; one nine-map mobile overview is 02_late_direct_actors_overview.png.

Important late-game negative evidence: stage 5-3 has no direct types $04..$2D at all (only first record $00, objective $01 and 20 $03 generators); 5-4 has only one direct $0E besides its first/goal and generators. If hidden warps exist in these stages, simply searching for an otherwise unused direct actor ID will not necessarily reveal them. This does not prove a warp is tile-encoded or scripted.

Important limitations: direct actor records can represent ordinary creatures, scenery hazards, pickups or triggers; this pass does not prove any of them are warp entrances. The distinct original $00 first placement, $01/$02 stage objective and header +$0E/+10 words are mapped separately in 04_separate_fields_*.png and 07_all_21_fields_not_warps.png. A complete hidden warp-arrival table remains missing. No new warp coordinates have been invented.

1. A type $03 uses the existing 19-descriptor selector: support only source-observed variant IDs until full script encoder and runtime test; max 32 allocated doors on any one stage.
2. A five-entry door-child pool means generator count is not the simultaneous-enemy maximum. Do not expose a user-facing enemy-count slider based only on $03 placements.
3. The 4-4b source list is selected by hardcoded $0DA3A references and special flag, not a 21st normal catalogue entry. Keep its records as a separate original area with its own native selector semantics.
4. All entity/warp controls remain read-only. Do not add/relocate source records until downstream source addresses, bitfields and load-time transformations have been traced and verified on Amiga.

Evidence and machine-readable tables: research/P08_verified_findings.json, P08_non_generator_direct_records.csv, and P08_header_and_entry_separation_all_21.csv.

13 October 2026. This section supersedes all P05/P06 statements saying the role of $03 is wholly unknown. The user proposed that $03 is a spawning generator. A direct native-code trace confirms that interpretation in operational terms: the game calls these fixed allocator entries "DOORS", checks proximity against descriptor thresholds, then creates normal runtime actors by executing a byte-control stream. "Door" in this subsystem is not evidence of a screen-exit or level-warp portal.

A map-list entry is still four original bytes 03 X Y VARIANT. There are 298 stock entries across 21 physical source lists. Original allocator at RAM $0B71C / source Disk $8B67C accepts X and Y (see below), scans at most 32 $10-byte entries in an array based at +$7C(A6), and finds a free entry by testing its +$08 pointer. The original diagnostic at RAM $0B742 says NOT ENOUGH DOORS!. All stock levels fit: the most heavily populated stage has 22 generator records (2-3 and 3-2 are among the busiest).

The allocator performs the native grid-to-position conversion door.pixelX = (tileX << 4) + 4 and door.pixelY = tileY << 4 before writing a packed longword to slot +$00. The per-door byte record positions and exact source offsets are in research/door_placements_P07.csv; top-down rendering follows the coordinate convention already verified for P05, but a per-frame game-state test would still be useful.

Processing: the $03 dispatch at RAM $05C32 reads the variant byte, doubles its index, consults the 19-word table at RAM $05C90 / Disk $85C07, copies the first two descriptor words to +$04/+$06 and stores its post-header script pointer at +$08. This is why $03's fourth byte is a variant number, not an ordinary flags field. The runtime scanner at RAM $05FD2 / Disk $85F49 compares absolute player-distance values against those words, allocates an actor when inside both bounds, stores the actor in slot +$0C, and seeds actor callback RAM $060B4 and script pointer at actor +$36. The $20/$A0 values for variant $00 are therefore 32 and 160 native coordinate units, rather than unclassified integers.

The ordinary non-$03 placement path branches to RAM $05872 / Disk $8583A with its type in D6. The door's script interpreter at RAM $060B4 / Disk $8602D also invokes the same RAM $05872 routine when a positive script token is encountered. Both BSR.W displacement targets have been independently calculated and asserted in research/P07_verify_generators.py. This confirms a common actor-creation mechanism rather than two unrelated "enemy type" systems. It does not yet prove that an actor-type byte equals a visual creature species, since that factory also reads further script bytes and uses dynamic game state.

The first two big-endian words at each native descriptor are the X and Y activation thresholds. Every one of the 18 stock-used descriptors begins its script with control byte $FC, then a following positive byte. That following byte varies by subtype and is a candidate generated actor code. Do not treat every positive byte in a descriptor as a different creature: the common creation routine consumes additional arguments from the same stream. Variant $12 (decimal 18) remains a supported but unused selector and aliases variant $02's native descriptor.

The runtime byte interpreter at $060B4 reads from the current actor script pointer at actor +$36; after reading a byte it branches on its sign. Observed native command cases: $FF obtains a restart pointer and reloads descriptor threshold words; $FE,n installs the literal n as a countdown at actor +$30, decremented by callback $06194; $FD and $FC select distinct state/callback combinations; $FB clears the running callback. Positive tokens invoke the common actor path $05872. Parameter consumption by the invoked factory must be decoded before the script format is declared fully understood or edited.

Relocation caution: descriptor headers and selector table are source-identical between Disk and saved RAM, but the tail of many disk streams differs after game loading. For example, disk $85C2D variant 0 ends FF 95 00 02 5C B6, whereas the RAM counterpart at $05CB6 ends FF 00 00 00 5C B6. Do not copy a decompressed RAM script straight over the disk script as a binary edit; source relocation/fix-up mechanics require a separate investigation.

• visuals_P07/01_doors_<level>.png — 21 complete maps from owner-supplied disk graphics; amber marker and hex variant represent only confirmed type $03 door records. These are generators, not warp markers.
• visuals_P07/03_all_21_door_spawns.png — complete 21-map overview.
• visuals_P07/04_all_19_door_scripts.png — thresholds and first candidate actor byte, with usage counts.
• visuals_P07/05_native_door_code_flow.png — six-stage native code trace with RAM and disk source offsets.
• visuals_P07/02_anchors_<level>.png — separate overlays for only ordinary first-record $00, $01/$02 and the separate header coordinate, explicitly not warp inventories. $0000/$0000 header pairs are not plotted as markers.
• visuals_P07/06_entry_header_warp_separation.png — key stages tabulated without invented warp destinations.

The owner has explicitly stated that no hidden warp-arrival markers were depicted in the earlier yellow-marker output. This is consistent with the binary evidence: a level contains exactly one type $00 first record, and separately one header +$0E/+10 coordinate pair, neither constitutes an inventory of all warp arrivals. Some non-zero header positions might be re-entry anchors (owner examples: 1-3, 1-4, 3-4), but no native code trace proves the warp selection or its complete destination list. Earlier maps conflated provenance by colouring both header coordinates and normal starts as if interchangeable; this is corrected in the P07 PNGs. The $03 generator system is a different mechanism and must not be repurposed as a warp editor.

No producer/editor writes have been enabled for door records, scripts or warp coordinates. Native capacity is at most 32 door slots per stage; enlarging or moving contiguous lists also needs a runtime-safe relocation/lookup contract. This is a read-only research milestone, not a new build of the HTML5 editor.

New, code-verified conclusions (13 October 2026): The 599 entries and all source addresses documented in P05 have been reverified. The executable object-list parser is now located, so these are no longer merely plausible four-byte coordinates.

• Each stage's second longword at catalogue offset +$04 is selected by runtime code RAM $04216 / Disk $84230; the pointed-to list's 16-bit preface is consumed, then the first entry's type byte is skipped and the next two bytes are processed as coordinates. Across all 21 physical lists the first type is $00. This is now code-evidenced entry/initialisation layout, not a confirmed warp destination.
• A loop at RAM $05C1C / Disk $85B93 processes subsequent signed-byte type IDs. $FF ends a list. Dedicated branches exist for $01, $02 and $03.
• Type $03 has a variant-selector fourth byte, indexed into a native 19-slot descriptor table at RAM $05C90 / Disk $85C07. This is not an arbitrary unclassified flags field for that type. The stock source contains 298 such records, with all indices $00..$11 present and $12 absent. The $12 slot aliases the descriptor for $02; species, image identity, object lifetime and placement behaviour are not yet established.
• Other types are handled through a generic coordinate reader, with additional handling of the fourth byte. For $00/$01/$02, retain their raw byte values until their eventual live visual/object labels are confirmed; note the exceptional $00 fourth byte $00 in 4-4 (otherwise $FF).
• Map Y and object Y are different coordinate conventions in current evidence. Object coordinates are visualised top-down because this aligns 1-1/1-2 entry observations, but precise pixel-centre and camera projection require a game-state test. The separate header +$0E/+10 anchor is not part of the four-byte placement list and is not a complete warp inventory.

See Code and Runtime for complete original instruction addresses, subtype table, and source matching. The research/all_599_placement_records.csv is a flat human-auditable manifest with disk offsets; visuals/15_21_map_position_comparison_mobile.png compares the 21 entry/objective/boss/header coordinates. No entity editing/export is enabled: the lists are contiguous and only the stock selector/count contracts are known.

P05 — 12 October 2026. Original Disk.1 entity/placement data recovered and byte-verified. The earlier statement that the game had no known object/spawn records is superseded. We have now located 599 complete 4-byte native records distributed across all 21 maps. The correct sequence, file offsets, per-record values and reproducibility proof are in research/entity_manifest_disk.json and research/extract_verified_entities.py. User verification of the actual in-game start/warp/exit behaviour is still the authority for identifying an object type.

The 20 × 16-byte stage catalogue at Disk $85DB7 is an exact copy of RAM $05E40 in the supplied UAE save state. Its second pointer (entry-relative +$04) points to an entity-data list in RAM; on this contiguous source block the matching disk location is RAM_pointer + $7FD52. Example 1-1 table pointer at RAM $05E40, entity pointer at RAM $0D292, source entity list at Disk $8CFE4. The full 20-entry table and its code consumer are documented in Disk Layout and Game Code.

The lists are stored one after another at Disk $8CFE4..$8D992 inclusive. A further, distinct list for 4-4b is physically present at $8D78C..$8D807, even though the runtime's 20-entry selector table does not contain a separate 4-4b entry. This makes 4-4b a 21st data map, not a 21st ordinary selectable stage. Finding its loader/warp-selection path remains outstanding.

Each per-map block begins with a big-endian 16-bit preface word of unknown function, then N consecutive four-byte records, ending with a $FF first byte (normally $FF 00 padding; the final 5-4 list ends in only $FF before another disk data stream). Example 1-1 at $8CFE4:

8CFE4: 00 50        ; 16-bit preface, role UNKNOWN
8CFE6: 00 03 0D FF  ; type $00; X 3; Y 13; flags $FF
8CFEA: 01 3B 06 FF  ; type $01; X 59; Y 6; flags $FF
8CFEE: 04 0F 0D FF  ; type $04; X 15; Y 13; flags $FF
...                 ; thirteen 4-byte records total
8D01A: FF 00        ; end marker + padding, next block starts $8D01C

Record layout (field meanings graded rather than assumed):

Crucial orientation distinction: Stored map pixels/tiles run bottom-up (storedY=0 is bottom), but the entity-list Y coordinates appear to be top-down within the declared active stage height. In the 1-1 64×14 map, $00 entity (3,13) appears at bottom-left using top-down Y, matching the user's known ordinary start. The 1-2 $00 at (2,31) independently matches a bottom-left ordinary start. For an active map rendered at 16px/cell, use screenX=16×X, screenY=16×Y relative to the top of the active cropped map. The P05 PNGs visualise this interpretation; runtime code must still prove the coordinate convention.

• Type $00 occurs exactly 21 times: once per stored map. For 1-1 at (3,13) and 1-2 at (2,31), top-down placement puts it in the bottom-left known ordinary player-start area. It is a strong normal stage entry/player start candidate.
• Type $01 occurs 16 times: exactly one in every ordinary stage including 4-4b, and none in the five ordinary _4 boss stages. It is a strong normal exit/goal candidate.
• Type $02 occurs five times: exactly one in each of 1_4, 2_4, 3_4, 4_4, 5_4. This perfectly matches the five boss-stage divisions and makes it a strong boss objective/trigger candidate, but the object/monster ID is still unverified.
• Type $03 occurs 298 times across the maps; its high frequency and widely varying parameter bytes suggest a repeatable object/event/placement role. Whether these are creature spawn records, environmental triggers, collectables or something else is not established; do not name $03 as an enemy without a code trace.
• All 599 records are within their respective 64×height rectangles, including the extra 4-4b list. Their co-occurrence, stage boundaries, repeated identifiers and matching source/snapshot copies make the record format substantially stronger than coordinate-only guessing.

The level-header pair (map header +$0E/+10) is a separate position-like system from these actor records. For 1-3 the header pair is (33,10) while the type $00 list start is (2,31). For 3-4 the header pair is (42,24) while type $00 is (5,60) and type $02 is (54,13). These differences strongly support the user's observation that header points sometimes denote warp re-entry or screen-placement anchors rather than normal player starts. What controls warp destinations and how many re-entry points exist is still unknown. Do not use the header pair as the complete warp list.

All coordinate pairs in the following table are grid (X,Y) from the four-byte placement records, with Y provisionally top-down. Values are independently read from original Disk.1, not generated from earlier PNG landmarks.

P05's visuals/07_all_21_native_entity_records.png covers all 599 entries as an overview. Eight large map PNGs 08_records_1_1, 1_2, 1_3, 1_4, 3_4, 4_4, 4_4b, 5_3 show individual coordinates over authentic disk-extracted tiles, with stage record addresses. Green = $00, cyan = $01, red = $02, lilac = $03, pale = other types, yellow cross = independent level-header pair. All colours are research annotations and are not the runtime object graphics.

visuals/11_21_entity_stage_table.png provides a compact 21-stage index of the key possible start/exit/boss coordinates. The project Wiki remains concise and descriptive; use these PNGs only for visual validation, not as proof that an object is an enemy or a specific warp.

A future object mode must parse the original Disk.1 bytes directly using the table and lists, not hand-authored coordinate JSON. Display the known type byte and flag byte; leave semantic names provisional until the actual 68000 handlers are traced and compared against retail gameplay. Distinguish normal start, normal exit/boss candidates, and header/warp anchor in separate toggleable overlays. A record must not be edited until we know which flags have semantics, what happens when record counts change, and whether the game safely handles an updated list length. The 20-entry stage catalogue/extra 4-4b relationship must be preserved exactly. No source binary modifications occurred in P05.

Use research/extract_verified_entities.py on the same 901,120-byte Disk.1 with SHA-256 fec7ce66934497b65745aa658599bdc697cf0ea0111d77d211fce3f48e27b416. It verifies each list's $FF termination, every coordinate bound, contiguous level-block boundaries (except the correctly resolved 4-4b alternate), and compares source records against the user's save-state when available. The machine-readable entity_manifest_disk.json stores original byte offsets for all 599 entries, facilitating further 68000 routine tracing and later safe editor integration. A representative change to map/placement bytes has not been runtime-tested, so source-verified read-only viewing is appropriate.

The 599 code-backed source placement records contain 259 direct records other than the $00/$01/$02 special entries and type $03 generators. Previous passes plotted some direct IDs, but did not expose a clear inventory of potential pre-populated pickups. P10 now provides the full original direct-actor manifest in research/P10_direct_prepopulated_actors.csv, with exact source Disk positions, stage, native (x,y) and fourth byte. The 21-level $1F/$20 counts and mobile PNG overlays form a usable visual review set.

• Code-backed: Type $20 occurs 30 times in stock lists, with a native fourth-byte value strictly 0–5 (six possible variants). Its behaviour routine uses the player/actor proximity helper, branches on its outcome, then loads #$03E8 (1,000) and calls a common numeric update routine. The native routine is consistent with a collectible or pickup that awards points, but the ultimate game-visible effect and image have not been confirmed by an Amiga play test.
• Code-backed but not identified: Type $1F occurs 29 times. Its handler and animation sequence differ from $20; do not assume it is the same sort of pickup. Fourth-byte stock values are $00,$02,$03,$06,$40,$41,$46, and positions frequently form deliberately arranged groups. It is a separate visually reviewable class of pre-placed actor.
• Unclassified: Types $04/$05/$06 occur 29/30/15 times, with distinct animation sequences and behaviour handlers. They are explicitly positioned in 1-1, which has no $1F or $20 records; therefore existing pickups in that level, if any, might be represented by another system/type or created dynamically. Never claim the $1F/$20 inventory is complete for the game.
• Separate source of actors: Type $03 is the confirmed generator; its #$FC script command can request a native actor type even when that type is absent from the stage's direct placement list. An actor type or bitmap may therefore occur without a corresponding direct placement.

Coordinates are the saved direct-placement tile coordinates, Y increasing down from the top of the active map. They are not pixel positions. Parameters are unmodified source bytes; $FF in other types does not have a globally interchangeable meaning.

These coordinates can be reviewed on visuals/01_placed_actors_<stage>.png (individual map overlays), visuals/02_prepopulated_types_all_21.png (all-stage table). Amber $20, purple $1F, cyan $04–$06, green other native direct types. Type $03 is intentionally hidden on these maps to reduce visual clutter.

The factory's RAM actor table selects two code/data pointers and two words. The second pointer leads into native word streams with repeated frame-number-like words and high-bit command words. P10 matches the streams with unchanged bytes in the original disk. The link from those token numbers to bitmap addresses, dimensions, palettes and masks is still unknown. Calling a raw $CA word a confirmed image of a particular pickup would be false precision.

For instance, $20 points to sequence $075A6 (Disk $87518), beginning 00CA 00CB 00CC 00CD 00CE 00CF. $1F points to $07558 (Disk $874CE), beginning 00B0 00B1 00B2 00B3 .... There are also $8000+ control words and numeric operands; do not treat the entire word stream as pure frame IDs. These two sequences are demonstrably different from type $04 at $080D8, $05 at $08DD8, and $06 at $0832A.

Visual evidence availability: 04_native_animation_streams_1.png and _2.png show their native RAM pointers and raw tokens. 05_graphics_RAM_probe_*.png are clearly labelled unvalidated candidate graphics from snapshot memory, not a character atlas. Without the original graphics-index consumer, their tiles cannot be reliably assigned to actor IDs, and the sprite palette is not established. No literal pickup icon has been added to the editor.

• 1-2 type $20 at (21,31,00), (62,21,03) and (62,23,01); the PNG plots all three independently of surrounding actors.
• 2-2 type $1F shows an eight-actor arranged cluster near the top of the map (values $02/$03), very different from scattered $20 placements.
• 3-3 includes both unusual direct types and $20 placements; use its overlay to identify whether any of the $20 candidates correspond to familiar bonus items.
• 4-4b is its own native entity list. Its direct actors, where present, are not automatically carried over from 4-4.

Do not add a $20 item editor yet. The source lists are tightly packed, actors may need normalised parameters, the $20 six-value family may set global bit flags, and the on-screen image table/source still needs decoding. Existing read-only overlays are safe.

The P03 production map editor remains unchanged and preserves map-only export. A separate, read-only app/nzs-entities.js browser reads all 599 packed original actor placements by their existing offsets and type fields, and independently decompresses the 108-byte $95-escaped transition stream at Disk $84B14..$84B7F to 160 bytes (20 × 8). It draws distinct overlays for $00 entry candidates, $01/$02 objective candidates, $03 generators, direct actors, $1F, $20, outgoing ordinary transitions and incoming ordinary transitions. 4-4b remains separate; logical ordinary stage rows 16–19 map to browser stage indices 17–20 because the browser has the extra 4-4b name at index 16. Warp arrival X/Y are still approximate screen projections.

P11 correction: original code at Disk $8AB04/$8AB32 demonstrates a movement/control stream using a countdown and two native-position increments (see Wiki 04). Previous language that named all positive $B0../$CA.. values "picture frames" was premature. Do not label or render those numbers as artwork without the actual image-index resolver.

The reader is deliberately non-mutating: its stock full-disk test passes 599 records (298 $03, 29 $1F, 30 $20) and 12 populated ordinary warp rows; an independent synthetic test exercises empty RLE data and confirms byte immutability. No actor, transition, sprite or palette writer is enabled. A raw source coordinate and a display-only -16 px projection can be compared without changing Disk.1. Neither is yet a proved sprite hotspot.

Native Disk.1 scenery backgrounds are used in the P11 mobile figures below, not mockup fills. The original $20 record in 1-2 at (21,31), Disk $8D02E, illustrates why showing only the stored tile centre can look a full tile too low. The corrected presentation depends on tracing native sprite size/hotspot and runtime Y consumer. The white source marker is retained for verification until that proof exists.

New verified coordinate detail: the original direct actor factory and native type $03 generator routine both decode the two stored bytes to Xtile*16 + 4 and Ytile*16. Exact matching opcode bytes exist at Disk $8583A/$8B67C and game RAM $05872/$0B71C in the owner's hash-verified Stage 1_1.uss. On a full 64×64 editor canvas, Y also includes (64−declaredHeight)*16 for the stage's visible bottom-aligned tile area. The old marker Xtile*16+8, Ytile*16+8 is not the code-derived origin.

Do not silently move records. The owner also suspects up to a whole tile of X misalignment (in addition to Y). The P11.1 viewer provides separate X and Y −16 / 0 / +16 pixel comparisons and leaves all 599 source records unchanged; full sprite graphics and their hotspot offsets still need tracing. Default markers now indicate the code-derived position, with a white source cross. Type $20 is still a bonus/pickup candidate, not an identified sprite. P09 incoming/ordinary warp coordinates are not reinterpreted using the actor factory's offset.

These figures have been curated under wiki/images/ from previously verified source/data diagrams. They are not authentic moving-art frames.