X-Git-Url: https://git.jtryba.com/browse/friidump.git/blobdiff_plain/d44030dfa440b1967ec7dcd3ccfe46fb69934486..6e43cd3fd4f7324a177331a01d653b4c19c4bca7:/docs/XBOX.md?ds=sidebyside

diff --git a/docs/XBOX.md b/docs/XBOX.md
index 0b203ed..29c1f6e 100644
--- a/docs/XBOX.md
+++ b/docs/XBOX.md
@@ -176,7 +176,20 @@ Implementation map:
 
 On Windows, GDR-8050L `-i` and `-X` are dispatched to a copied-in reference implementation from jtryba's original Xbox dumper (`main.c`, `utils.c`, `unlock.c`, and helpers). This preserves the original state-machine order instead of approximating it in FriiDump's generic read loop. It also preserves the reference timing sleeps: tray-cycle 3000 ms, readiness settle 1500 ms after success or 10000 ms fallback, RefreshVolume's 1000 ms wait, and the explicit post-refresh 2000 ms settle.
 
-For GDR-8050L, bare `-i` derives `Title[MediaID].iso` from the XBE title and DMI media ID, and bare `-X` derives `Title[MediaID].xiso`. Supplying `-i <file>` or `-X <file>` is an explicit filename override. The first unlock/metadata pass exists for that size/title/media-ID discovery before the actual dump mode runs.
+For GDR-8050L, bare `-i` derives `Title[MediaID].iso` from the XBE title and DMI media ID, and bare `-X` derives `Title[MediaID].xiso`. Supplying `-i <file>` or `-X <file>` is an explicit filename override. FriiDump prepares the game view for that title/media-ID discovery with state-aware READ CAPACITY classification: it reuses an already-unlocked view, otherwise it attempts one direct full handshake without a media transition. A tray-cycle-and-retry path exists only as recovery when direct verification fails.
+
+FriiDump 0.5.3.8 returns the reference dumper's actual finalized ISO filename,
+byte count, CRC32, MD5, SHA-1, and SHA-256 to the common Redump verifier after a
+successful option-1/full-disc dump. This supports both explicit `-i <file>` and
+bare `-i` with XBE/DMI-derived names without hashing the 7.29 GiB file twice.
+Use `--redump-report <file>` to publish the same atomic schema-2 evidence record
+used by GameCube/Wii paths.
+
+The current XGD1 image map contains documented synthetic zero-filled ranges.
+Accordingly, `NO EXACT MATCH` is a valid evidence result even when all readable
+sectors were acquired successfully. The verifier reports acquisition evidence
+and archive identity as separate claims. `-X` remains outside DAT verification
+because XISO is not a full Redump disc image.
 
 GDR-3120L remains on the separate `FF 08 01` vendor lock/unlock path. Forced Xbox mode on non-supported Xbox unlock profiles is rejected rather than routed through FriiDump GC/Wii fallback methods.
 
@@ -224,3 +237,39 @@ The first candidate that can read/validate sector 0 is selected for the rest of
 the run and logged.  If all candidates fail, seed retrieval stops and the log
 records each failed probe.  Unsupported/non-HLDS drives now keep zeroed HLDS
 profile fields so stale cache-base/window values are not printed.
+## FriiDump 0.5.3.9 live-summary closure
+
+The embedded GDR-8050L reference path returns finalized hashes, output size and
+sector count, title, media ID, and elapsed evidence to FriiDump.  The final HLDS
+summary therefore describes the reconstructed output rather than the locked
+6,992-sector view.  GC/Wii seed terminology is marked not applicable for this
+Xbox authentication path.  DumpXboxGameDisc no longer spins the drive down
+internally; FriiDump performs one final STOP UNIT after Redump verification.
+
+## FriiDump 0.5.3.10 state-aware metadata-entry handshake
+
+The copied GDR-8050L bridge no longer performs the unconditional sequence
+`unlock -> tray cycle -> unlock` before title/XDVDFS probing.
+
+Normal entry paths are now:
+
+- already-unlocked entry: verify readiness, reuse the game view, and read title,
+  XDVDFS, media ID, and physical metadata;
+- locked/video entry: issue one full handshake directly, refresh/read capacity,
+  and continue only after the game view is observed;
+- recovery only: when direct verification fails, cycle the tray once, retry the
+  full handshake once, and fail cleanly if the game view is still absent.
+
+The dump itself still performs one intentional media transition to restore the
+locked/video view before VIDEO-L0 and VIDEO-L1 capture, followed by one full
+handshake for game/XDVDFS sectors. Therefore the expected normal cold-state
+sequence is `unlock -> metadata -> tray cycle -> video -> unlock -> game`, and
+an already-unlocked entry omits the first unlock.
+
+XDVD sidecar authentication evidence now distinguishes two separate facts:
+
+- `unlock_requires_media_transition: false`
+- `locked_video_view_restore_requires_media_transition: true`
+
+The compatibility field `requires_media_transition` is also `false`; it refers
+to authentication/unlock acceptance, not to restoring the locked video view.