The Lite-On DH-16D2S is much easier to find and cheaper than the DH-16D1S, which is on the GD-ROM compatibility list (https://wiki.redump.info/Optical_Disc_D ... ty:_GD-ROM). It was an OEM drive in many HP/Acer PCs and uses the same 2007 MediaTek platform (MT1309E, 256 KB SPI flash, read offset +6), so I looked at whether it could read GD-ROMs too.
Flashing the D1S ZZ00 directly bricks it because the bootloaders differ. I recovered the drive with a CH341A on the W25X20. So I worked out what ZZ00 changes and ported that to EH33, the HP firmware. I’m calling it GDxx for now. Apart from the READ CD gate, the D2S needed seek fixes for:
the outer HD area beyond minute 110;
the HD start, via a waypoint;
an overshoot into the HD lead-in that made the seek loop bounce until timeout.
On native SATA, with official redumper using --rings, DATA_C2_SUB, --drive-read-offset=6 and --skip over the LD/HD gap, a GD-ROM dump matches redump on all tracks and the cue. So far one clean disc is fully verified; a heavily scratched one doesn’t match yet.
DH-16D2S with a ported GD-ROM firmware mod: first results
Re: DH-16D2S with a ported GD-ROM firmware mod: first results
Technical details (GD07 vs. stock EH33)
366 bytes differ, all in flash banks 1 and 2. Bank 0, bank 3 and the bootloader are untouched, so the drive always boots and can be reflashed. Addresses below are bank:code address; code 0x4000-0xFFFF of bank n is at file offset 0x8000 + n*0xC000 + (addr - 0x4000).
Read gate (bank 1)
857E — READ CD only enters the read engine when the status is 1. A GD only mounts its LD area, so every HD LBA is out of range. A stub at F577 lets an out-of-range READ CD through when the LBA is >= 45000. It also lets through a 256-sector window after the LD lead-out, so redumper can find the write offset.
85C5 — a data sector requested as CD-DA used to fail with 05/64. Now it goes through the read engine and comes back raw and scrambled (stub at F5C9). Without this, redumper’s fallback from CD-DA to data mode left the following audio reads 3 sectors off, with no error.
8517 — the “LBA+150 < 6 → 05/21” check is removed, so the start of the pregap can be requested.
Seek (bank 2)
AD3A — the seek dispatcher capped the target minute at [0x8017] = 110. The HD area ends at 122:04, so seeks past LBA ~499350 failed; the sequential read stopped at 544892. The cap is now 122.
A358 / A3EE / A432 → F405 — the near-seek tables are indexed by minute and have only 110 entries. Above minute 109 they read neighbouring data and produce negative or huge jump counts. The index is now clamped to 109.
E654 — the direction check reads the same [0x8017]. It is set to 123 to stay consistent with the cap.
B10F → F451 → F411 — a far jump from the LD area straight to the HD start tends to land in the unrecorded gap; the position read then fails and the seek gives up. For a GD (LD capacity < 45000) with a target in minutes 10-15, the first jump now goes to LBA 65000 and continues inward from there. F451 handles negative-LBA (lead-in) targets: it shifts minutes by +5 so that 99:59 and 00:00 are adjacent in the jump calculation.
DF19 → F47B — this decides whether the Q relative time can be used as the current position when TNO = 00. Stock only uses it if bit 0x27.5 is set, and that bit is actually the multi-session flag. Otherwise the position is taken as 0, and the bank-0 seek loop then kicks 100 tracks outward.
In the CD lead-in, rel minutes 95-99 are now accepted.
In the GD HD lead-in, Q rel time is 151:xx and ends at 151:28:74, right before 10:00:00. There the position is reported as 09:58:50, so the loop takes one short outward jump instead of bouncing between ~46200 and the lead-in until a 6 s timeout. This was the main cause of the slow, sometimes failing first seek to LBA 45000.
Strings (bank 1): revision in INQUIRY, the KEY-DATA table and ATA IDENTIFY.
Not changed / not possible
The CD seek loop itself sits in bank 0 at 0x5979. Our flasher writes bank 0 last, and the drive resets after the bank 3 commit, so bank 0 never gets written. Everything above works around that loop from bank 2.
Lead-in sectors stay unreadable. The decoder matches on the Q absolute field, which holds TOC pointers in the lead-in. Track 1 pregap is readable down to about -145.
366 bytes differ, all in flash banks 1 and 2. Bank 0, bank 3 and the bootloader are untouched, so the drive always boots and can be reflashed. Addresses below are bank:code address; code 0x4000-0xFFFF of bank n is at file offset 0x8000 + n*0xC000 + (addr - 0x4000).
Read gate (bank 1)
857E — READ CD only enters the read engine when the status is 1. A GD only mounts its LD area, so every HD LBA is out of range. A stub at F577 lets an out-of-range READ CD through when the LBA is >= 45000. It also lets through a 256-sector window after the LD lead-out, so redumper can find the write offset.
85C5 — a data sector requested as CD-DA used to fail with 05/64. Now it goes through the read engine and comes back raw and scrambled (stub at F5C9). Without this, redumper’s fallback from CD-DA to data mode left the following audio reads 3 sectors off, with no error.
8517 — the “LBA+150 < 6 → 05/21” check is removed, so the start of the pregap can be requested.
Seek (bank 2)
AD3A — the seek dispatcher capped the target minute at [0x8017] = 110. The HD area ends at 122:04, so seeks past LBA ~499350 failed; the sequential read stopped at 544892. The cap is now 122.
A358 / A3EE / A432 → F405 — the near-seek tables are indexed by minute and have only 110 entries. Above minute 109 they read neighbouring data and produce negative or huge jump counts. The index is now clamped to 109.
E654 — the direction check reads the same [0x8017]. It is set to 123 to stay consistent with the cap.
B10F → F451 → F411 — a far jump from the LD area straight to the HD start tends to land in the unrecorded gap; the position read then fails and the seek gives up. For a GD (LD capacity < 45000) with a target in minutes 10-15, the first jump now goes to LBA 65000 and continues inward from there. F451 handles negative-LBA (lead-in) targets: it shifts minutes by +5 so that 99:59 and 00:00 are adjacent in the jump calculation.
DF19 → F47B — this decides whether the Q relative time can be used as the current position when TNO = 00. Stock only uses it if bit 0x27.5 is set, and that bit is actually the multi-session flag. Otherwise the position is taken as 0, and the bank-0 seek loop then kicks 100 tracks outward.
In the CD lead-in, rel minutes 95-99 are now accepted.
In the GD HD lead-in, Q rel time is 151:xx and ends at 151:28:74, right before 10:00:00. There the position is reported as 09:58:50, so the loop takes one short outward jump instead of bouncing between ~46200 and the lead-in until a 6 s timeout. This was the main cause of the slow, sometimes failing first seek to LBA 45000.
Strings (bank 1): revision in INQUIRY, the KEY-DATA table and ATA IDENTIFY.
Not changed / not possible
The CD seek loop itself sits in bank 0 at 0x5979. Our flasher writes bank 0 last, and the drive resets after the bank 3 commit, so bank 0 never gets written. Everything above works around that loop from bank 2.
Lead-in sectors stay unreadable. The decoder matches on the Q absolute field, which holds TOC pointers in the lead-in. Track 1 pregap is readable down to about -145.
-
donutbruit
- Posts: 73
- Joined: Thu Jun 18, 2026 1:06 am
Re: DH-16D2S with a ported GD-ROM firmware mod: first results
Great work! You should also see about what's needed to get it working with dreamdump and maybe even do a pull request.