I've spent some hours talking to the google AI, using both the sequencer MCU (Z80-ish in code) and ROM as a base to decode how things are done.
What we discovered is that there is no stripping of CRC in the Fluxengine D20 image decoding, making the image grow, thereby drifting.
The AI detected all the important data blobs like MIDI and SysEx, but found "Stutter" in the data, indicating things that should be stripped away.
After spending too much time going in circles with an AI trying to generate functional CRC stripping python scripts, I gave up...
You may find some important fact here, but keep in mind this is AI talk here (The "payload" stripping" is important here, 60/64 CRC):
Roland GCR 5-bit to 4-bit Table (Directly from D-20 Logic)
GCR_TABLE = {
'01010': 0x0, '01011': 0x1, '10010': 0x2, '10011': 0x3,
'01110': 0x4, '01111': 0x5, '10110': 0x6, '10111': 0x7,
'01001': 0x8, '11011': 0x9, '11010': 0xA, '11001': 0xB,
'11110': 0xC, '11111': 0xD, '11101': 0xE, '11100': 0xF
Technical Reference: Roland D-20 GCR-DOS & MCU Storage Logic
Subject: Advanced Analysis of HD64180 Sequencer EPROM (Revision 2.0)
Document ID: RD20-GCR-90-REF
Status: Confidential / Technical Archive
-
Executive Summary
The Roland D-20 utilizes a proprietary GCR (Group Code Recording) file system managed by a Hitachi HD64180 MCU. This revision documents the native MCU routines for disk operations, including the "Middle-Out" allocation strategy and the undocumented Type 0x05 system file.
-
Low-Level Disk I/O (The "Sum-and-Strip" Protocol)
The HD64180 MCU handles disk data as 64-byte physical packets rather than logical sectors.
The "Wash" Routine (ASM Logic)
When reading from the FDC (Floppy Disk Controller), the MCU executes the following:
Bit-Sync Phase: The CPU waits for a GCR sync-violation (10 consecutive high bits).
Clock Recovery: Utilizing internal wait-loops calibrated for a 4µs bit-cell.
8-bit Summation Check: The MCU performs a running addition of the first 63 bytes in the A register:
XOR A (Clear accumulator)
ADD A, (HL) (Sum loop)
Verification: The result is compared against the 64th byte.
Payload Stripping: If valid, the instruction LD BC, 003Ch (60 decimal) is loaded, followed by LDIR. This moves only the verified 60-byte payload to RAM, discarding the 3-byte header and 1-byte checksum.
-
Filesystem Hierarchy & Type Encodings
The D-20 GCR-DOS identifies file functionality via a specific ID byte at Offset 11 of the 12-byte Directory Entry:
0x01 (.111 - ALL): System-wide dump including 128 Patches, Timbres, and Sequencer RAM.
0x02 (.222 - SONG): Sequencer event list (Delta-times and MIDI status bytes).
0x03 (.333 - SOUND): Sound-only data (Timbre and Tone parameters).
0x04 (.444 - RHYTHM): Rhythm Patterns and the 9th Rhythm Track assignment.
0x05 (.555 - SYSTEM SETUP): Undocumented/Utility Type. Dedicated to Global Tune, MIDI channel maps, and Multi-Timbral configurations. This type is rarely accessible via the standard UI but exists in the MCU's jump-table logic.
-
The "Middle-Out" Allocation Strategy
To minimize mechanical latency (Seek Time), the D-20 employs a bi-directional track allocation:
Directory Home: Located at Track 39 (physical center).
Primary Path (Ascending): Files are written from Track 40 → Track 79.
Secondary Path (Descending/Overflow): When the outer edge is reached, the MCU reverses the stepper direction, writing from Track 38 → Track 0.
Implication for Recovery: Large .111 files typically occupy outer tracks, while smaller .222 or .444 files are often "shuffled" into the inner tracks near the spindle.
-
Deletion & Data Persistence (Ghost Data)
The EPROM reveals a "Non-Destructive Delete" routine:
Filename Invalidation: The first character of the filename is changed to 0xE5.
Type Invalidation: Alternatively, the MCU sets the high bit of the Type ID (e.g., 0x02 becomes 0x82).
Data Recovery: Because sectors are only overwritten when a new file requires the space, the "Hardcore" recovery engine can often retrieve deleted sequences by ignoring the FAT and scanning for valid 8-bit checksums across the entire disk surface.
-
Format-Verify Routine
The D-20's formatting is a high-integrity 3-pass operation:
Physical Preamble: Writing the GCR sync and gap patterns (FF 80 00).
Verification Pass: Each 64-byte physical packet is read back and checked for sum integrity.
Directory Initialization: Writing the empty FAT/Directory Map to Track 39.
-
Conclusions for Forensic Reconstruction
To achieve bit-perfect data recovery from Roland D-20 flux dumps, software must:
Bypass 512-byte abstractions: Use the native 60-byte logical payload.
Implement Bit-Slip Correction: Accounts for the +5 checksum offset common in PC-drive flux reads.
Map Orphaned Sectors: Search for valid headers (3E 33 03 or A5 37 03) to identify files that were marked as deleted (0xE5) but still exist physically on the magnetic media.
I've spent some hours talking to the google AI, using both the sequencer MCU (Z80-ish in code) and ROM as a base to decode how things are done.
What we discovered is that there is no stripping of CRC in the Fluxengine D20 image decoding, making the image grow, thereby drifting.
The AI detected all the important data blobs like MIDI and SysEx, but found "Stutter" in the data, indicating things that should be stripped away.
After spending too much time going in circles with an AI trying to generate functional CRC stripping python scripts, I gave up...
You may find some important fact here, but keep in mind this is AI talk here (The "payload" stripping" is important here, 60/64 CRC):
Roland GCR 5-bit to 4-bit Table (Directly from D-20 Logic)
GCR_TABLE = {
'01010': 0x0, '01011': 0x1, '10010': 0x2, '10011': 0x3,
'01110': 0x4, '01111': 0x5, '10110': 0x6, '10111': 0x7,
'01001': 0x8, '11011': 0x9, '11010': 0xA, '11001': 0xB,
'11110': 0xC, '11111': 0xD, '11101': 0xE, '11100': 0xF
Technical Reference: Roland D-20 GCR-DOS & MCU Storage Logic
Subject: Advanced Analysis of HD64180 Sequencer EPROM (Revision 2.0)
Document ID: RD20-GCR-90-REF
Status: Confidential / Technical Archive
Executive Summary
The Roland D-20 utilizes a proprietary GCR (Group Code Recording) file system managed by a Hitachi HD64180 MCU. This revision documents the native MCU routines for disk operations, including the "Middle-Out" allocation strategy and the undocumented Type 0x05 system file.
Low-Level Disk I/O (The "Sum-and-Strip" Protocol)
The HD64180 MCU handles disk data as 64-byte physical packets rather than logical sectors.
The "Wash" Routine (ASM Logic)
When reading from the FDC (Floppy Disk Controller), the MCU executes the following:
Bit-Sync Phase: The CPU waits for a GCR sync-violation (10 consecutive high bits).
Clock Recovery: Utilizing internal wait-loops calibrated for a 4µs bit-cell.
8-bit Summation Check: The MCU performs a running addition of the first 63 bytes in the A register:
XOR A (Clear accumulator)
ADD A, (HL) (Sum loop)
Verification: The result is compared against the 64th byte.
Payload Stripping: If valid, the instruction LD BC, 003Ch (60 decimal) is loaded, followed by LDIR. This moves only the verified 60-byte payload to RAM, discarding the 3-byte header and 1-byte checksum.
Filesystem Hierarchy & Type Encodings
The D-20 GCR-DOS identifies file functionality via a specific ID byte at Offset 11 of the 12-byte Directory Entry:
0x01 (.111 - ALL): System-wide dump including 128 Patches, Timbres, and Sequencer RAM.
0x02 (.222 - SONG): Sequencer event list (Delta-times and MIDI status bytes).
0x03 (.333 - SOUND): Sound-only data (Timbre and Tone parameters).
0x04 (.444 - RHYTHM): Rhythm Patterns and the 9th Rhythm Track assignment.
0x05 (.555 - SYSTEM SETUP): Undocumented/Utility Type. Dedicated to Global Tune, MIDI channel maps, and Multi-Timbral configurations. This type is rarely accessible via the standard UI but exists in the MCU's jump-table logic.
The "Middle-Out" Allocation Strategy
To minimize mechanical latency (Seek Time), the D-20 employs a bi-directional track allocation:
Directory Home: Located at Track 39 (physical center).
Primary Path (Ascending): Files are written from Track 40 → Track 79.
Secondary Path (Descending/Overflow): When the outer edge is reached, the MCU reverses the stepper direction, writing from Track 38 → Track 0.
Implication for Recovery: Large .111 files typically occupy outer tracks, while smaller .222 or .444 files are often "shuffled" into the inner tracks near the spindle.
Deletion & Data Persistence (Ghost Data)
The EPROM reveals a "Non-Destructive Delete" routine:
Filename Invalidation: The first character of the filename is changed to 0xE5.
Type Invalidation: Alternatively, the MCU sets the high bit of the Type ID (e.g., 0x02 becomes 0x82).
Data Recovery: Because sectors are only overwritten when a new file requires the space, the "Hardcore" recovery engine can often retrieve deleted sequences by ignoring the FAT and scanning for valid 8-bit checksums across the entire disk surface.
Format-Verify Routine
The D-20's formatting is a high-integrity 3-pass operation:
Physical Preamble: Writing the GCR sync and gap patterns (FF 80 00).
Verification Pass: Each 64-byte physical packet is read back and checked for sum integrity.
Directory Initialization: Writing the empty FAT/Directory Map to Track 39.
Conclusions for Forensic Reconstruction
To achieve bit-perfect data recovery from Roland D-20 flux dumps, software must:
Bypass 512-byte abstractions: Use the native 60-byte logical payload.
Implement Bit-Slip Correction: Accounts for the +5 checksum offset common in PC-drive flux reads.
Map Orphaned Sectors: Search for valid headers (3E 33 03 or A5 37 03) to identify files that were marked as deleted (0xE5) but still exist physically on the magnetic media.