FriiDump Technical info =============================================================================== This document is a reworking and unification of information found all over the net, regarding the structure of Nintendo Gamecube/Wii Optical Discs and how to read them on an ordinary DVD-ROM drive. All the due credits can be found in the AUTHORS file. =============================================================================== Nintendo Gamecube/Wii Optical Disc (GOD/WOD) structure =============================================================================== In order to understand how a Gamecube or WII Optical Disk is made, let us first take a look at a standard DVD-ROM. The complete standard is explained in the ECMA-267 Standard. The user data stored on the DVD is divided in blocks, each 2048 bytes long. Each 2048-byte block is then encapsulated in a 2064-byte structure, adding some other data needed for error-correction and head positioning. A 2064-byte block is called a "Data frame", and its logical layout is as follows: 4bytes 2bytes 6bytes 2048bytes 4bytes - - - - - - - - - - - - - - - - - - - - - - - - - - | ID | IED | CPR_MAI | User Data Frame | EDC | - - - - - - - - - - - - - - - - - - - - - - - - - - - Identification Data (ID): Contains the PSN (Physical Sector Number), info about the sector itself, like the layer, reflectivity, zone, etc. - ID Error Detection Code (IED) - Copyright Management Information (CPR_MAI): Its use is application-specific, for instance it can be used to store a sector key in videos that use CSS, or a scrambling key in the XBox and XBox360 Security Sectors. - User Data: This is the data available for the end user. - Error Detection Code (EDC): It is the checksum data for all the fields above, its polinomial is x^32 + x^31 + x^4 + 1. For various reasons (not related to copy protection), the User Data Frame is XOR'ed with a stream cipher generated by an 15bits LFSR (Linear Feedback Shift Register), with bits 10 and 14 used as taps. The seeds are obtained from a table of the ECMA-267 standard, the index of the seed is the 4 MSB of the last byte of the "ID" field of the Data Frame. The same stream cipher is then used by 16 consecutive Data Frames: for this and other reasons (again related to error correction), data from the DVD are always read in 16-data frame blocks. 4bytes 2bytes 6bytes 2048bytes 4bytes - - - - - - - - - - - - - - - - - - - - - - - - - - | ID | IED | CPR_MAI | User Data Frame | EDC | - - - - - - - - - - - - - - - - - - - - - - - - - - ^ | 2048bytes cipher stream | ^ - - - - - - - - - - Scrambling seed index Now, the first problem when dealing with Gamecube/Wii Optical Discs is that they use a different (and yet unknown) set of seeds. This means that when an ordinary DVD-ROM drive tries to read a GOD/WOD disc, it will unscramble the User Data Frame with the wrong seed, causing the EDC check to fail and a read error to be reported to the operating system, which means the inability to read the disc. Furthermore, Gamecube/Wii Optical Disks use a slightly different structure for the Data Frame, as shown in the following figure: 4bytes 2bytes 2048bytes 6bytes 4bytes - - - - - - - - - - - - - - - - - - - - - - - - - - | ID | IED | User Data Frame | CPR_MAI | EDC | - - - - - - - - - - - - - - - - - - - - - - - - - - | 2048bytes cipher stream | - - - - - - - - - - Basically, the User Data Frame and the CPR_MAI fields are swapped, while the scrambled bytes remain the same. =============================================================================== Tricks used to read a GOD/WOD on a standard DVD-ROM drive. =============================================================================== To cope with the above-mentioned problems, some methods have been suggested by many people on the net. They vary in performance, but the basic idea is always the same: 1. Issue a read command for the sector of interest (this is actually a 16-sector block, not a single sector, as stated above). 2. Let the read return failure. 3. At this moment, the DVD-ROM drive must have cached the data read from the disc somewhere in its internal memory, to be able to unscramble them and to check the EDC. So, we can dump the data from the drive's internal RAM. Unfortunately, this is not as easy as it seems, due to the fact that there is no standard "Dump drive memory" command. This is probably implemented in many drives for firmware debugging purposes, but, as such, it is a vendor-specific command, which are usually undocumented and vary from vendor to vendor (or even from drive model to drive model). This is where the work that many hackers around the world have done, in order to crack the Microsoft XBox360 console, becomes useful. They needed some way to read and write data to the XBox360 drive's internal memory, so they disassembled the drive's firmware and patiently tried to understand what each of the vendor-specific commands did. This way, they discovered that a certain command could be used to read an arbitrary portion of the drive's internal RAM. They also managed to map the RAM addresses, so that it is known where data read from the disc are temporarily stored. Fortunately, the XBox360 drive is not too different from some retail DVD-ROM drives, namely some models from LG, which means that the discovered command works on them as well. Hence, we now have some sort of access to the disc data. Although, this comes at the price of speed: dumping the drive's internal memory is a slow process, as it uses Programmed I/O (PIO) instead of Direct Memory Access (DMA) to transfer data from the drive to the computer's memory. For this reason, some have proposed the use of the "streaming read" command: it is a standard command thought for those applications where the constant flow of data is more important than its absolute correctness, such as audio or video applications. Thus, this command does not perform the EDC on the data read from the disc, but returns it immediately. Anyway, the command will only return the User Data Frame, which means that only a portion of the data will be read this way, while the rest (i.e.: the first 12 and the last 4 bytes) will have to be read using the memory dump method. Nevertheless, this combined method will be faster overall, as only some dozens of bytes have to be transfered through PIO, instead of the whole sectors. We still have to cope with the unknown seeds. This problem can be easily solved through the use of brute force: as there are only 15 bits to try (and commonly only 17 seeds per GOD/WOD), this approach only takes about 30 seconds. The bruteforce process is very simple: the LFSR is seeded from 0 to 7FFFh and for each seed the corresponding stream cipher is generated and XOR'ed with the proper section of the Data Frame and the EDC is computed. If the EDC is the same as the one in the EDC field then we have the correct seed. =============================================================================== The FriiDump approach =============================================================================== FriiDump can use four different disc dump methods. They have been developed gradually, empirically and heuristically, by experimenting with the PLScsi tool and comparing the retrieved data with a known-good dump. In this section the inner working of every dump method will be described. The code implementing the different methods can be found in the "disc_read_sector_X" functions of disc.c. Please note that the desibed behaviour is that of my LG GDR8164B drive, which I assume to be shared by similar drives. Other, more different drives, might behave differently and require totally different methods. Also note that all of the methods read 16-sector blocks. Method 1 This method is very slow. So slow that I have never dumped a whole disc with it. Although, it served me to prove that I was going in the right direction and that my efforts could eventually come to a working end. It also showed me that the first versions of RawDump create bad dumps, sometimes. Basically this method is the same used by those early versions of RawDump, which took 50+ hours to dump a whole disc. It works like this: 1. Issue a read command for the required sector. This will cause the 16-sector block to which the sector belongs to be placed at the beginning of the drive's cache memory. Do not even bother to see what the read command returns, as it will surely be a data read error. 2. Dump the 16-sector block. Method 2 Method 2 is similar to method 1, but uses the above-mentioned "streaming read" method, which somehow allows us to dump 5 blocks at a time. 1. Issue a "streaming read" command for the required sector. This will cause the 16-sector block to which the sector belongs to be placed at the beginning of the drive's cache memory, together with the 4 following 16-sector blocks. Do not bother to see what the read command returns. 2. Dump the 5 16-sector blocks. Method 3 This is similar to the previous method, but instead of dumping the whole sectors from memory, it uses the (not EDC checked) data returned by the "streaming read" command. and completes it dumping only the missing bits from memory. 1. Issue a "streaming read" command for the required sector. This will cause the 16-sector block to which the sector belongs to be placed at the beginning of the drive's cache memory, together with the 4 following 16-sector blocks. 2. For each sector of each block, reconstruct the whole Data Frame, as follows: - Dump 12 bytes from memory. - Use 2048 bytes returned by the read command. - Dump 4 more bytes from memory. Note that this method has a small issue, as sometimes the beginning of the cache will be dirty and contain invalid data, needing the sector to be read again. As this seems to happen quite often, we always read a dummy sector before the requested sector. Method 4 Method 4 is just method 3 with a trick to use a single dump command for every sector that has to be reconstructed, instead of two. It is the faster dump method currently supported and, as such, the default one. 1. Issue a "streaming read" command for the required sector. This will cause the 16-sector block to which the sector belongs to be placed at the beginning of the drive's cache memory, together with the 4 following 16-sector blocks. 2. For each sector of each block, reconstruct the whole Data Frame, as follows: - If this is the first sector of a block, dump 12 bytes from memory. Otherwise, use the last 12 bytes of the preceding dump. - Use 2048 bytes returned by the read command. - Dump 16 bytes from memory, and use the first 4. This leaves 12 bytes to be used for the reconstruction of the next sector. Note that the issue of method 3 applies to this method, too. =============================================================================== Xbox/XGD direct-read and redump-style support =============================================================================== Xbox/XGD support is separate from the Nintendo GOD/WOD cache-dump methods above. FriiDump only switches into the Xbox-specific planner when the disc type is forced with `-T 4` or when the drive identifies as one of the two native Xbox profiles currently wired for autodetection: - HL-DT-ST DVD-ROM GDR8050L - HL-DT-ST DVD-ROM GDR3120L / GDR-3120L All other drives continue to use FriiDump's original command/method selection, autodetection, seed cracking, cache reads, and raw/ISO dumping behavior unless the user explicitly forces Xbox mode. This keeps normal GameCube, Wii, Wii DL, and plain DVD workflows on the original FriiDump path. Plain DVD-ROM dumping is also exposed with the convenience flag `-D` / `--dvd`, which is equivalent to forcing disc type `-T 3`. It is available to all drives and deliberately uses the original FriiDump DVD/raw/ISO path; it does not invoke Xbox unlocks, XISO planning, or Xbox metadata output. For Xbox media, FriiDump reads 2048-byte sectors with MMC READ(10). Method 10 is reserved internally for this direct Xbox READ(10) path. The older Nintendo raw 2064-byte format is not meaningful for Xbox redump output. GDR-8050L challenge-table handshake ------------------------------------------------------------------------------- The GDR-8050L normally exposes a small visible DVD-video view before Xbox authentication. For redump-style output, FriiDump follows the original dumper's state machine rather than a single continuous read: primary handshake, media-cycle, re-handshake, metadata/auth probe, media-cycle back to the visible DVD-video view, video L0/L1 capture, final handshake, game data write, metadata write, and STOP UNIT cleanup. The handshake sequence is based on scsi1.pas / "XBOX 1 DVD-Drive unlocker tool v0.1" by The Specialist and the xboxhacker.net contributors credited there. The sequence is: 1. READ CAPACITY(10) to observe the current visible view. 2. MODE SENSE(10), page 0x3E. 3. READ DVD STRUCTURE, format 0xC0, using this twelve-byte CDB: AD 00 FF 02 FD FF FE 00 06 64 00 C0 The requested transfer length is 0x0664 bytes. If this format 0xC0 request does not return a usable table, FriiDump falls back to the Hitachi-family vendor challenge-table command 0xFD. 4. Decode the challenge table: copy 0x2C bytes from offset 0x4A3, hash them with SHA-1, use the first seven SHA-1 bytes as the RC4 key, and RC4-decrypt the response table beginning at offset 774. 5. Select usable challenge entries whose decoded table entry begins with 0x01. 6. MODE SELECT(10), page 0x3E, first challenge. 7. MODE SENSE(10), page 0x3E, verify. 8. MODE SELECT(10), page 0x3E, second challenge. 9. MODE SENSE(10), page 0x3E, verify. 10. MODE SELECT(10), page 0x3E, partition-1 unlock. 11. MODE SELECT(6), page 0x31, to enable sticky descrambling. 12. READ CAPACITY(10) again as an observation. Like the original dumper, this verification is diagnostic; the later XDVDFS probe determines whether the game view is actually available. GDR-3120L / Kreon-style FF 08 01 vendor lock-state path ------------------------------------------------------------------------------- The GDR-3120L path is not the GDR-8050L challenge-table handshake and is not a plain direct READ(10) path. DiscImageCreator documents and uses a vendor command family beginning with `FF 08 01`; FriiDump now mirrors the relevant parts: - `FF 08 01 10` - get feature list. A valid reply begins with words `A55A 5AA5` and then feature words such as Xbox unlock-state support. - `FF 08 01 11 00` - set lock state 0, returning the drive to the normal vendor lock state 0 / normal DVD-video state when supported. FriiDump uses this before the redump-style `-i` planner captures the visible/video view. - `FF 08 01 11 02` - set lock state 2 / wxripper state. FriiDump uses this before reading the game/XDVDFS view. - `FF 08 01 15 00` - disable vendor error-skip before dumping so real read failures remain visible to FriiDump. Samsung/Kreon-style drives such as TS-H352C, TS-H353A, SH-D162C, SH-D162D, SH-D163A, and SH-D163B are not autodetected as Xbox mode by default; ordinary FriiDump GC/Wii/DVD behavior remains unchanged. To test those drives with Xbox media, force Xbox mode explicitly with `-T 4`. Xbox dump outputs ------------------------------------------------------------------------------- `-i / --iso` writes a redump-style Original Xbox/XGD1 2048-byte-sector image. This is more complex than copying the game partition. For retail dual-layer media FriiDump writes this layout: - output LBA 0..6831: visible DVD-video L0, read from source LBA 0..6831; - output LBA 6832..198143: pregame padding, currently zero-filled; - output LBA 198144..198175: 32-sector game lead-in, read from unlocked source LBA 0..31; the native libfriidump path zero-fills only a genuinely unreadable sector and records the fallback count; - output LBA 198176..3629407: unlocked game/XDVDFS data, normally read from source LBA 32 on GDR-8050L, or from the detected XDVDFS source LBA on other supported profiles; - output LBA 3629408..3820719: postgame padding, currently zero-filled; - output LBA 3820720..3820879: visible DVD-video L1 tail, captured from locked source LBA 6832..6991 before the unlock. The full redump-style output is 3,820,880 sectors. FriiDump also tries to save PFI and DMI READ DVD STRUCTURE captures next to the ISO as `.pfi.bin` and `.dmi.bin`, and writes a `.redump.json` file describing the reconstructed layout, hashes, drive profile, PFI/DMI filenames, lead-in read/zero-fill counts, and DiscImageCreator-compatible layout constants. The code checks the layout against DiscImageCreator's Original Xbox/XGD1 model: `XBOX_SIZE = 3820880`, `XBOX_LAYER_BREAK = 1913776`, DVD start PSN `0x30000`, Xbox start PSN `0x60600`, and therefore game-output start LBA `0x30600` / `198144`. This is dump metadata output, not required input for the ISO or XISO. `-X / --xiso` writes only the game partition as an XISO-style image. FriiDump unlocks first when needed, probes for the XDVDFS descriptor at LBA 306112 first, then falls back to LBA 32. For retail dual-layer media it copies from the detected XDVDFS start LBA through LBA 1913920 and prepends a 32-sector game lead-in. For single-layer/homebrew-style media it treats the XDVDFS VolumeSize field as a byte count and converts it to 2048-byte sectors. Both Xbox output styles preserve the 32-sector game lead-in from unlocked source LBA 0..31. The GDR-8050L reference path fails the dump if this proven range cannot be captured; the native libfriidump path retains a counted per-sector zero-fill fallback for other profiles or transient read failures. Supported-drive notes ------------------------------------------------------------------------------- GC/Wii Hitachi-LG list now documented in this branch: - GDR-8082N, GDR-8083N, GDR-8084N - GDR-8161B, GDR-8162B, GDR-8163B, GDR-8164B - GCC-4160N, GCC-4240N, GCC-4243N, GCC-4244N, GCC-4247N - GCC-4243N/GCC4243* and GCC-4244N/GCC4244* default to Method 8. - GDR-8085N, GDR-8087N, and GCC-4246N are probable but not confirmed here. - GCC-4241N and GCC-4242N are capable but known to have many errors. Additional reference candidates from DiscImageCreator: - XBOX/XBOX 360 Kreon firmware candidates: TS-H353A, TS-H352C, SH-D162C, SH-D162D, SH-D163A, SH-D163B. - XBOX/XBOX 360 swap candidate: GSA-4163B. - HD-DVD and BD are DiscImageCreator-supported disc classes, but this FriiDump branch does not claim DiscImageCreator-equivalent HD-DVD/BD coverage. Implementation map: - MMC/SCSI helpers, GDR-8050L challenge-table unlock, and FF 08 01 vendor lock-state helpers: `libfriidump/dvd_drive.c` - Xbox disc detection/unlock timing: `libfriidump/disc.c` - Redump-style ISO and XISO dumping: `libfriidump/dumper.c` =============================================================================== How to add support for a new drive =============================================================================== If you read all the above stuff, it should be clear that, in order to add support for a new DVD-ROM drive, all that is needed is a way to dump the drive's internal memory, in particular the portion where the data read from the disc is cached. As explained above, this function might not be present in all drives, and might not be easy to find or to use. In case you manage to discover it, just copy the file "hitachi.c" to a new one, and modify it opportunely. Some modifications will also be needed in "dvd_drive.c", in order to add autodetection for the new drive, in the "dvd_assign_functions" function. Apart from this, the cache behaviour of the new drive might not be the same as that of the currently supported models, so the program architecture might need radical changes. In this case, please report. Current fleet test notes ------------------------ The current uploaded inventory.cvs lists: GDR-8163B x15, GDR-8081N x3, GCC-4241N x5, GCC-4243N x5, GCC-4244N x9, GCC-4160N x3, GWA-4164B x1, GSA-H73N x1, and GH22NS30 x1. The planned validation order remains incremental: first confirm GCC-4243N against the known-good Sonic Mega Collection hash from the GCC-4244N run, then repeat the same disc on GCC-4244N if reinstalled, then move through GCC-4241N/GCC-4160N/GDR-8081N/GDR-8163B and finally the SATA DVD writer family. Do not test the entire fleet at once; keep one drive/disc/hash record per run. GCC-4243N/GCC-4244N Method 8 split-recovery note -------------------------------------------------- For HLDS GCC-4243N and GCC-4244N GameCube/Wii dumping, the default Hitachi command-2 / Method-8 path now has three visible recovery layers: the existing Method-8 5-block/window read reconstruction retry loop, the dump-level retry envelope, and a Method-8 split-recovery path for a failed 16-sector block. The split-recovery path reconstructs the failed block by trying 8-sector, 4-sector, 2-sector, then 1-sector streaming chunks, validates the rebuilt 16-sector raw block with the normal unscrambler/EDC check, and only caches/writes it if validation succeeds. All retry and split-recovery messages are mirrored through the shared FriiDump log file, so a failure such as `Dump failed at sectors: N..N+15` should now include whether 8/4/2/1 chunk recovery was attempted and where it failed. Existing Xbox logging remains on the same shared log path; GDR-3120L Xbox support remains on the explicit vendor lock/unlock path. HLDS 0xE7 DIC profile-layer update ------------------------------------ This branch now classifies HLDS/MN103 0xE7 GC/Wii dumping drives into DIC-style profiles before assigning the FriiDump Hitachi cache reader. The selected profile is printed in the run log after Command/Method: - Type1: GCC-4160N/GCC-4240N, cache base 0x00a13000, one 16-sector memory window. - Type3: GCC-4243N/GCC-4244N/GCC-4246N/GCC-4247N and GDR8083N/GDR8084N, cache base 0x80000000, five 16-sector memory windows. - Type4: GDR8082N/GDR8161B/GDR8162B/GDR8163B/GDR8164B and related DVD-ROM profiles, cache base 0x80000000, five 16-sector memory windows. - GDR-8050L modified 0xE7 speed-probe/fallback: GDR8050L/GDR-8050L with cross-flashed or modified firmware that adds 0xE7 memdump, cache base 0x80000000. Single-window is proven; this build probes guarded 3-window, 2-window, and 5-window no-prefetch schedules before falling back to the proven one-window Method 8 profile. - Type2_1/Type2_2: GCC-4241N/GCC-4242N are identified as experimental DIC Type2 shapes, but this branch does not yet claim DIC parity for their moving-cache behavior. The Type1 base address comes from the DIC source behavior for GCC-4160N/GCC-4240N. Method 8 now honors the selected profile's memory-window count, so Type1 reads/cache-validates one 16-sector block per request instead of assuming the Type3/Type4 five-window cache layout. GCC-4243N and GCC-4244N remain on Method 8 by default. GDR-8050L is split into a modified-firmware GC/Wii 0xE7 path: stock GDR-8050L firmware is still expected to use the Xbox path only, while a cross-flashed/modified GDR-8050L with 0xE7 memdump added can use Method 8. The proven GDR-8050L fallback is one window/no-prefetch; this build probes guarded multi-window no-prefetch speed profiles and reverts to the proven single-window path if an accelerated read fails. GDR-3120L Xbox ripping support remains on the separate explicit vendor lock/unlock path and is not described as GC/Wii support. 2026-06-29 / HLDS 0xE7 Windows volume guard --------------------------------------------- * The existing Xbox FSCTL_LOCK_VOLUME-style guard is now exposed as a shared FriiDump volume lock helper. * HLDS 0xE7 GC/Wii paths apply the guard before disc seed retrieval, so Windows Explorer/AutoPlay is less likely to interrupt GCC-4160N/GCC-4240N Type1 seed reads with an "insert a disc" prompt. * The guard is warning-only: if Windows already owns a transient handle, FriiDump logs the failure and continues so the hardware read result remains authoritative. 2026-06-29 / HLDS 0xE7 AutoPlay warning ------------------------------------------------ * Added an explicit Windows AutoPlay warning before the HLDS 0xE7 GC/Wii volume-lock and seed-retrieval phase. * GCC-4160N Type1 testing showed the volume lock works, but Windows AutoPlay can still open an "insert a disc" dialog and interfere until AutoPlay is disabled and File Explorer/dialogs are closed. * The warning is printed for all non-Xbox HLDS 0xE7 GC/Wii profiles before FriiDump attempts the shared volume guard. HLDS 0xE7 validation summary and observed speeds -------------------------------------------------- For HLDS 0xE7 GC/Wii runs, FriiDump now prints a compact validation summary at the end of the run. The summary records the selected profile, cache base, memory-window count, seed-read status, seed-retrieval elapsed time, dump status, STOP UNIT status, duration, and an observed average speed computed from the ISO payload size and elapsed dump time. The hash comparison remains manual: compare the printed hashes against the known-good target for the test disc. Seed retrieval timing note: normal GC/Wii seed cracking is usually a seconds-to-tens-of-seconds step, with the original technical note describing the brute-force portion as roughly 30 seconds on the old reference path. Experimental HLDS 0xE7 profiles can take longer because this fork may also probe cache profiles and guard against Windows polling. This build does not add a hard seed timeout because aborting a blocked optical-drive command from inside FriiDump is less safe than letting Windows/drive firmware return or letting the user cancel with Ctrl+C. As an operational rule, a seed phase above about 5 minutes is suspicious, and above about 10-15 minutes should usually be treated as a failed profile/drive state: cancel, confirm AutoPlay/File Explorer are closed, power-cycle or tray-cycle the drive if needed, and rerun with the log preserved. Observed Sonic Mega Collection (US) fleet results so far: | Model | Firmware | HLDS profile | Cache base | Windows | Result | FriiDump final displayed rate | Duration | Notes | | --- | --- | --- | --- | --- | --- | --- | --- | --- | | GCC-4244N | B103 | Type3 | 0x80000000 | 5 | PASS | 2184.83 MB/h | 2294.36 s | First confirmed GC dump; Dolphin playback confirmed. | | GCC-4243N | A102 | Type3 | 0x80000000 | 5 | PASS | 2534.09 MB/h | 1522.95 s | Confirmed matching Sonic hashes after resume/retry work. | | GCC-4160N | 0010 | Type1 | 0x00a13000 | 1 | PASS | 1613.08 MB/h | 3127.98 s | AutoPlay had to be disabled; volume guard OK; hashes matched known-good Sonic dump. | | GDR-8050L modified | 0012 | GDR-8050L modified 0xE7 single-window proven fallback | 0x80000000 | 1 | PASS | 776.49 MiB/h / 782.59 MB/h | 6455.22 s | Cross-flashed/modified firmware with 0xE7 memdump; hashes matched Sonic. Current build adds guarded speed probes. | Known-good Sonic Mega Collection (US) target hashes: ``` CRC32 01b52739 MD5 85a525df1481d0ad67d8761f832dca12 SHA-1 06eb6d15b4d7f90ec0fed9ce9a77db41358d74ed SHA-256 30098da93f5de9ece8da44f8afdfb85cf9bcdc24d77131221e64e3038a529010 ``` Use this table as an observed fleet log, not a promise that every firmware revision of a model behaves identically. HLDS GDR-8050L modified 0xE7 note (2026-06-30): A cross-flashed GDR-8163B running modified GDR-8050L firmware with 0xE7 memdump added reached seed retrieval and dumped the first 320 sectors, then failed at sectors 320..335 when treated as a normal five-window Type4 cache. A later single-window/no-prefetch run completed Sonic Mega Collection and matched the known hashes at roughly 776.49 MiB/h / 782.59 MB/h. This build keeps that single-window path as the proven fallback, but adds a speed probe before seed cracking: 3-window no-prefetch, 2-window no-prefetch, 5-window guarded no-prefetch, then fallback to one window. If an accelerated GDR-8050L profile later fails during a dump, FriiDump logs the failure and reverts to the proven one-window profile for the rest of the run. Stock GDR-8050L remains an Xbox path, not a GC/Wii memdump drive. GDR-8081N experimental 0xE7 probe layer ----------------------------------------- GDR-8081N is now recognized as an experimental HLDS 0xE7 GC/Wii candidate. Unlike GDR8082N/GDR816x, it was not in the confirmed DIC dump list, so FriiDump does not hard-code it as a normal Type4 drive. It starts as `GDR-8081N experimental 0xE7 probe` and, during seed retrieval, tries small sector-0 validation reads across these cache profiles: - Probe A Type4-derived: base 0x80000000, 5 windows. - Probe B single-window: base 0x80000000, 1 window. - Probe C Type1-base: base 0x00a13000, 1 window. - Probe D moving-cache candidate: base 0x7fff7f00, 1 window. 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. GDR-8050L speed-probe visibility note: Builds after the seed-timer package report the modified GDR-8050L as `speed-probe pending` at initial drive-info time, then print each guarded candidate during seed retrieval. If all accelerated candidates fail, the run visibly selects the proven single-window fallback. Probe v2 note: The GDR-8050L speed-probe-pending profile now defaults to Method 8, so the probe branch is actually exercised by default. Seed cracking now fails the run if the experimental 0xE7 profile probe cannot validate a cache candidate, instead of continuing after an unsupported/failed probe. The first visible probe message starts on a fresh line after the seed-retrieval prompt for easier log review. HLDS 0xE7 logging note: GDR-8050L modified-0xE7 read schedule selection is logged once per run/profile selection, not once per read chunk, to keep long dump logs readable. FriiDump HLDS 0xE7 probe-v2 log-once cleanup ------------------------------------------------ The GDR-8050L modified 0xE7 selected schedule is now reported by the profile probe only. The per-read Method 8 path no longer prints the schedule line for every 16-sector chunk. ## HLDS 0xE7 scan mode for GDR-8081N and other experimental drives This branch adds a fast discovery mode for experimental HLDS HIT 0xE7 drives: ```powershell .\friidump.exe -d f: --hlds-e7-scan -T 0 --scan-log "gdr8081n_e7_scan.json" $zip = "friidump_gdr8081n_e7_scan_results.zip" if (Test-Path $zip) { Remove-Item $zip -Force } Compress-Archive -Path .\gdr8081n_e7_scan.json,.\friidump.log -DestinationPath $zip -Force ``` The scan mode does not crack GameCube/Wii seeds and does not dump disc data. It is intended to avoid long failed seed-retrieval runs while discovering whether a drive exposes a usable HIT 0xE7 cache/memdump base. It performs small cache-fill reads, tries a bounded set of candidate memory bases, captures raw-sector header/tail bytes, scores expected DVD raw sector IDs, and writes a JSON report. For GDR-8081N the first candidate set includes known Type3/Type4 bases, nearby 0x80000000 offsets, Type1/GCC-4160N neighborhood bases, low SRAM aliases, and a firmware-mapping sanity candidate. Future analyzer work should use firmware control-flow around the 0xE7 handler and live scan deltas to rank candidates instead of treating firmware/disassembly mapping base as the drive SRAM cache base.