• Please review our updated Terms and Rules here

Roland D-20 decoding the mysterious floppy format.

trondl

Member
Joined
Dec 9, 2019
Messages
35
Although this is technically a synthesizer, I hope no-one gets offended by me posting this here.

Disclaimer: I'm no good at programming. I can read some code, but in no way able to write something from scratch.
I'm a service technician so am fully able hardware wise.

I've finally decided to hopefully break this mystery, once and for all since no-one has done the work as I know of yet.
With help from FluxEngine-David (hjalfi?), progress has been made but we're far from the goal.

Service manual is found here (pages 7, 10, 13 and 17 are of interest) : https://soundprogramming.net/manuals/Roland_D-20_ServiceNotes.pdf
EPROM dumps attached, both the oldest and newest version (with priority on the C ROM).

Facts / claims:
David found that the brother240 (Brother Word Processors) is the closest format when analyzing my flux dumps;
meaning GCR, SSDD, most likely half/micro-stepping using 4 phase inputs instead of /STEP (coincidentally a Brother branded motor) and also most likely a different CRC.
The half-stepping part causes bad reads on a Greaseweazle, thereby bad / partial flux dumps.
Have tried to format a floppy as brother240, but I get "Illegal Disk" when trying to read on the D20.
Most likely (and hopefully) a FAT-ish file format.
The FDC (IC6) and sequencer CPU are on a separate board unique to the D20 together with EPROM C.
The FDC is a Moero u78152-a (good luck finding the datasheets) on the CPU board, and the drive itself has an epoxy clad Moero BX7468 controller on the drive.
Luckily, the D-20 service manual has all the pin descriptions.
There are 3 EPROMs on the unit itself, but I believe that the only EPROM relevant to the floppy is the last one (C), as that is on the CPU / sequencer board with the floppy controller, also the other relatives D5, D10 and D110 which don't have a sequencer or floppy drive don't have a third EPROM.
The GCR conversion lookup-table should be in ROM C somewhere?

Someone has earlier attempted to break some of the code from the EPROM (google translated for convenience) which should be a good starting point:

Goal:
Get a valid flux dump of the floppies and decode the "files", which are most likely SysEx and MIDI data in some form.
Ideally from the Moero drive itself to rule out faults.
Locally on the synth itself, you can save as Sound (SysEx-ish?), Drum pattern (MIDI-ish?) or Song (MIDI-ish?), each indicated with it's own .(icon) when saving.
Build something that can translate the "files" if in some way it's not directly compatible.

Plan / Ideas:
Use an arduino as an FDC on the drive itself, micro stepping manually and use my DSO to scope for the actual tracks then sample with the ardino, or if an easy task, do it automatically.
I'm no good at coding, but I may be able to tweak values etc.
In other words: Is this an easy task code-wise?
Controlling the drive itself shouldn't be that hard?
 

Attachments

  • D20 firmware 1.00.zip
    48.5 KB · Views: 4
  • Roland D-20 firmware new mainboard 1.12(1.11).zip
    67.9 KB · Views: 3
So, those Brother drives have poor alignment. The quarter-stepping feature is to allow them to adjust to match the alignment of the tracks on the disk. However, when you format a disk with them, they just start at a fixed offset from the beginning of the disk, and this doesn't always line up with the track alignment of a modern drive. Hence the problems reading them on modern drives. On the Brother word processors the solution is to format a disk with FluxEngine on a PC drive, so guaranteeing alignment, and then use the word processor itself to copy the data from the poorly-aligned disk to the correctly-aligned disk. Then you can copy the data off with the FluxEngine.

The first step with the D-20 is to get a good flux image. If you've got multiple synthesisers, try making disks with each one. If one of them works then that will save on having to build hardware. The flux image you sent me decodes well enough with the Brother decoder that I would be astonished if the format wasn't some variant.

Tracks -> 1 2 3 4 5 6 7 H.SS 012345678901234567890123456789012345678901234567890123456789012345678901234567 0. 0 .????..?..?......B........BB.....??..BBBBB??BBB????B?B?BB???BBB???B??????????? 0. 1 ..B....B..................B.B....B?..BB.?.??B??????BB??B???BB????????????????? 0. 2 .......BB.................B.B....BB..BBBB.?B??B????B?BBB?B??BB?B??B???BB?????? 0. 3 ...B...BB.B....B...B........B....?BB.BBBBB???BB?B??BBBBBB????B?????????B?????? 0. 4 .......B...........B......B.B....BBBBBBBBBB???B?B??BBBBB?BB?BB???????????????? 0. 5 .......?...........B......BBB...BBB..?BB?B??????B??B?B?????B?B???????????????? 0. 6 ...B...B?...........?.......B....?...BB.?BB?BB?B?B?BBBB??B???BB????????BB???B? 0. 7 ...B...?...........?.......B.....BB..??BBB???BB?B?BB?B??????BBB????????B?B???? 0. 8 .......?B......B.........B..B....?BB.BB.B.B?B?B???BBB?B??B??B?B?????????????B? 0. 9 .......?...........?......B.B....?B.BBBBBBB??BB?B??BBB?.B??????B??B??B????BB?? 0.10 ...B...BB........................B?BB?B.?.??B?B?B?B.BBB?BB???BB?B?BB?????????? 0.11 .............?.....B......B.B....BB.BBB.BB??BB?BB??BBB?BB???B?????????????????

(. == good sector, B == sector with bad CRC, ? == missing sector)

Once you get a good decode, then we can start reverse engineering the format.

I've actually had vague thoughts of rebuilding the FluxEngine hardware, using a RP2040 instead of a PSoC5, given that the PSoC5 is unobtainable. This would annoyingly require custom wiring as the pinouts from the floppy drive connector to the dev board don't match, but the upside is that it might be possible to support this kind of quarter-stepping drive as well. Too many projects, not enough time...
 
I've been handling Brother 120K and 240K disks for years. Why the re-engineering? I've shared information before. FWIW, I still use a Catweasel for that. I keep a couple of mis-adjusted 3.5" drives around to handle the misalignment. Works well enough that my average is around 100% recovery.
 
Yes, that would be me you shared it with! But here we're trying to figure out the Roland D20, about which very little is known --- if you know anything about this, that would be awesome...

The story is that while doing the Brother work I found a blog article which mentioned the same FDC chip. So when someone sent me a Roland D20 flux image I tried decoding it with the Brother decoder, and it sort of worked, as you can see from the map above. So it seems very likely that it's either the same format or is a variation of it. The first step is to try and get a clean enough decode to be able to figure out the details, and then try and reverse engineer the filesystem format.
 
Thanks for chiming in!

I’ve actually started to think that one of my DD drives from my pile might actually be sacrificed for this job, and might also have a higher probability of being properly realligned if I should need it, compared to a HD drive.
Also, DD would make reading some of the HD floppies with leftover FAT12 tracks in between easier?

Or is my idea of using an arduino as an FDC for the original Moero drive simpler than it sounds? I see FDC projects available which should make the base line already done, sans controlling the stepper and such. I’m stil no good at coding though.

Chuck: You mean sending a flux dump or a floppy? I’m in Norway, and shipping is an arm and three leggs at the moment.
 
I read the Brother WP floppies on Teac FD235HF--the thing to watch out for is the user sending in HD floppies. You have to cover the density aperture if you want to read those in an HD drive. I've not found that a DD drive (e.g. Teac FD235F) works any better.

I mean a real floppy, not a flux image. If there are alignment issues, I want to see them first hand and compensate. Sorry, but I don't use Kyroflux or Greaseweazle or DeviceSide, or the Apple flux device or Fluxengine--they all work the same way, but I don't want to bother with writing a conversion filter to my tools' format.
 
I don't have enough floppy drives to dare risk changing the alignment. As a not-very ept hobbiest I know that while I'm quite capable of misaligning a drive, putting the alignment back again afterwards is a lot harder... I have actually wrecked a difficult-to-source Amstrad NC200 drive by removing the wrong screw which causes the head sled to come loose from the drive screw. I'm going to have to build some custom tooling to fix that as I need to move the entire sled, rather than just rotating the stepper motor.

Regarding driving the Moero drive from a stepper: driving the stepper motor shouldn't be that hard, as there ought to be existing software for it. The tricky bit is doing the capture. You'll most likely want to hook the data line up to a proper logic analyser. I can easily add a FluxEngine importer to let it decode the results. You'd start the capture, and then step through all 40x4 tracks with a second or so between each one to produce one huge datastream, and then FluxEngine can pull out all the clean sectors. The Brother disk format has both the sector number and track number in the sector header so that's easy.

The tricky bit is you'd have to do all this yourself, as it's not something which can be done remotely...
 
I don't have enough floppy drives to dare risk changing the alignment. As a not-very ept hobbiest I know that while I'm quite capable of misaligning a drive, putting the alignment back again afterwards is a lot harder... I have actually wrecked a difficult-to-source Amstrad NC200 drive by removing the wrong screw which causes the head sled to come loose from the drive screw. I'm going to have to build some custom tooling to fix that as I need to move the entire sled, rather than just rotating the stepper motor.

Regarding driving the Moero drive from a stepper: driving the stepper motor shouldn't be that hard, as there ought to be existing software for it. The tricky bit is doing the capture. You'll most likely want to hook the data line up to a proper logic analyser. I can easily add a FluxEngine importer to let it decode the results. You'd start the capture, and then step through all 40x4 tracks with a second or so between each one to produce one huge datastream, and then FluxEngine can pull out all the clean sectors. The Brother disk format has both the sector number and track number in the sector header so that's easy.

The tricky bit is you'd have to do all this yourself, as it's not something which can be done remotely...
I have enough drives for my life time, and generic DD drives offer nothing more than what a HD drive can offer, if I understand it correctly.
The problem is that they're in another town, and I'm not going there until July.

I'll give this link a proper read, but he may be onto something:

Maybe this can actually be as easy as using the arduino to convert between /STEP /DIR and the "Two-phase driving pulses to step motor for head shift" PHA to PHD, with the option to set a positive or negative step offset , and Greaseweazle to handle the data?
Should be an easy breadboard hack if as easy as I imagine?
All the other signals should be there:
FRD - Pulse train from the disk
MTR - Motor on

The rest can be hardwired to Read Only

Moero.png
 
I don't have enough floppy drives to dare risk changing the alignment.
Can use a microstepper like I used to recover MFM hard drives with heads out of alignment. I just directly drove the stepper. For hard drives the track 0 sensing doesn't work properly since they use the stepper phase as part of track 0 sensing. Don't know if floppies do that.

http://www.pdp8online.com/mfm/microstep/index.shtml

My flux board has enough spare pins that I could control the stepper with it and adjust head position until I got a good read. Saved that offset for each head to use as the start position on the next cylinder.
 
I suspect that the CPU simply half-steps until it gets a good read after banging the head carriage into the stop. Essentially a copy of the Apple II logic, which also lacks a track-zero sensor. Some Apple II copy protection software recorded some tracks offset by a half-step.
 
How about actually treating this drive as an Apple ][ drive with a slight twist regarding the stepper?
Seems like this project might be a way to go?

How critical is knowing the exact pulse durations of a half step? There are standards, code in ROM or all done by the Moero controller?
Damage may be done with wrong timing?

I could probe during a format to see what comes up on the scope.
 
I have some news!
I also have a suggestion how we finally may do this dump without sacrificing a DD drive. More on this towards the end.

The news:
I've put my Arduino Mega 2560 to good use: Logic analyzer :LOL:
No streaming mode, but enough sampling time with low resolution (500Hz) to see how the stepper behaves roughly.
I've also attached the FRD / Read signal, but I guess much is lost in between the samples.
"Full" logs attached as OpenLogic Sniffer data (can be exported as .csv if needed in OLS).
I used OLS v0.9.7 SP2 from https://lxtreme.nl/projects/ols/

These images show the classic bump for track zero rewind before formatting, which looks very similar to how the Apple Disk ][ behaves in the same scenario?
Compare with the images at https://embeddedmicro.weebly.com/apple-2iie.html
D20 format rewind.png


D20 format begin.png

Have also verified some input states during read:
WCC (write current, we don't want to) 0V
WD
(write data, we don't want to) 0V
WG
(write or read? we want to read, also the default state when idle): 5V
MTR
(motor on) 0V


The suggestion:
I believe this small Arduino project aimed at dumping Apple Disk ][ DOS 3.3 floppies, which also supports "raw" mode, may "easily" be tweaked to do it's job:

This is where I need help:
The tweaks to be done to make treckr work (if at all possible)?
- Change geometry
- Step timings? Should have enough details and resolution in the attached logs
- Add flux level support, or is the RAW mode sufficient?
- replace the Apple GCR code with the Brother GCR code, or at least filter out FAT12 so only GCR is dumped.
- add code to keep the WCC, WD, WG and MTR in the right state. We only need reading.

Thanks for all the help and suggestions so far!
 

Attachments

  • D20 LA logs.zip
    6 KB · Views: 0
Last edited:
This might be a different chip than what you think...
MOERO U78152-A (M60012-0110)

The M60012 is a CMOS Gate Array by Mitsubishi and comes in a variety of packages, including a 40 pin DIP. Unfortunately it looks like a mask programmed device... However, perhaps one of the chip decapping services could be used to try and reverse engineer the chip. That would cost money and time and would require finding someone experienced in reverse engineering chips from high res photographs. The MAME team has folks that have done this.
 
Correction: WD (write data, we don't want to) 5V
The rest to avoid confusion:
WCC (write current, we don't want to) 0V
WG
(write or read? we want to read, also the default state when idle): 5V
MTR
(motor on) 0V
 
Last edited:
This might be a different chip than what you think...
MOERO U78152-A (M60012-0110)

The M60012 is a CMOS Gate Array by Mitsubishi and comes in a variety of packages, including a 40 pin DIP. Unfortunately it looks like a mask programmed device... However, perhaps one of the chip decapping services could be used to try and reverse engineer the chip. That would cost money and time and would require finding someone experienced in reverse engineering chips from high res photographs. The MAME team has folks that have done this.
Looks like how a cbm 1541 used its UC1 to control most of the drive with a PAL/GAL. Hopefully, we don't have to rely on it if the Arduino approach works.
I believe it is all about micro/halfstepping to find first track with GCR, then half/wholestep from thereon.
Step timings hould all be visible in the previous logs I posted, especially the one with reading.
That log contains the searching for content, then manually loading the content.
Worth noting is that there is no headknock when loading known content.
It seems like the controller knows where the head is, as there most likely is a track number encoded in the data.
 
I see now that the logs I posted didn't save the channel names :unsure:
Channels 0 to 3 is PHA to PHD and channel 4 is the READ signal (most likely unusable due to the low sample rate).
I hope someone here is willing to help me with adaptation of the treckr Arduino sketch.
 
Hjalfi: In fluxengine, apple2_drive is mentioned and an adapter needed for greaseweazle.
Didn’t find any detailed description of it though.
Could that be a solution?
 
I've now found a drive to sacrifice, a Samsung SFD-321B.
Easy access to the read amps, and of what I know, not a historical drive in any sense.
Before I start the adventure of turning that stepper ever so slightly, i did a test dump with the Greaseweazle (Attached to this post).
Amazingly, this drive made a much better dump than the previously used Newtronics/Mitsumi drive.
The readings were actually not that far of with only a few misses at the beginning and increasing at the second half of the media.
I used the "rolandd20" preset in FluxEngine and found that most of the tracks were seen as one track off, as in physical track 5 has track data for track 4.

This shouldn't cause any issues since all the tracks are available, considering when (if actually needed) I align for the media I don't have to go one track backwards?
Also, could this flux be enough to begin the CRC decoding?

Description of the dumps, all from "fresh" known working DD floppies:
uncal fmt empty 1 to 3: Dumps of three "erased" (not with an actual magnet), then formatted floppies. No actual data written to it.
uncal fmt A.- to 3: Multiple dumps of one erased (again, no magnet), formatted, then has all the data that was available in the D20 saved to it (Save All).
It was saved as "A.(three music related icons)", so it could have one filename extension or three files with different extensions (Patch, Rhythm and Sequence)
Should contain easily readable ASCII text as most of the data should contain presets with instrument names, f.ex. "AcouPiano1" although uncertain if that actual patch name is there.

I've also included the D20 factory sysex patches recorded as a MIDI file for reference as the hex data in some sections may look very similar, if not identical in structure.
SysEx messages starts with F0 and ends with F7. Not sure if F0-F7 is actually used, but there is a big chance it is.
 

Attachments

  • D20.zip
    6.5 MB · Views: 5
  • D1020ORIG.zip
    12.5 KB · Views: 6
Those are much better dumps! I can actually make out some kind of filesystem on them. On track 39, i.e. half way up the disk, there's this:

Code:
0001D400   00 52 4F 4C  41 4E 44 2D  47 43 52 44  4F 53 4E 00  .ROLAND-GCRDOSN.
0001D410   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................
0001D420   E5 20 20 20  20 20 20 20  20 20 20 20  20 20 00 00  .             ..
0001D430   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................
0001D440   E5 20 20 20  20 20 20 20  20 20 20 20  20 20 00 00  .             ..
0001D450   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................
0001D460   E5 20 20 20  20 20 20 20  20 20 20 20  20 20 00 00  .             ..

That looks like a directory if I've ever seen one, and the ROLAND-GCRDOS string indicates that these really are Brother GCR disks. That's really good news for Roland people, as Brother word processors are fairly easy to get hold of and are very likely a source for replacement drives. It also means that all the hard work of decoding and CRC reverse engineering is done. So, all that's left is to decode the file system.

So I'm going to guess that this is a set of 32-byte dirents, with the filename in the first 16 bytes and the data location in the second. The first entry is the disk label. 0xE5 is traditional for marking an unused dirent in CP/M so I think this is similar. That came from one of the blank disks, so looking at one of the used disks:

Code:
0001D400   00 52 4F 4C  41 4E 44 2D  47 43 52 44  4F 53 4E 00  .ROLAND-GCRDOSN.
0001D410   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................
0001D420   00 41 5F 5F  5F 5F 5F 5F  5F 5F 5F 33  33 33 00 00  .A_________333..
0001D430   01 02 03 04  05 06 07 08  00 00 00 00  00 00 00 00  ................
0001D440   E5 20 20 20  20 20 20 20  20 20 20 20  20 20 00 00  .             ..
0001D450   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................

Yup! That's a file and a list of blocks! Also like CP/M; I think they took inspiration. I can see the data starting here:

Code:
0001E100   46 61 6E 74  61 73 79 20  20 20 07 08  0F 00 30 37  Fantasy   ....07
0001E110   10 01 01 00  29 07 05 03  00 01 08 0C  20 32 0D 23  ....)....... 2.#
0001E120   32 31 40 07  28 40 10 06  1D 05 25 39  03 04 0D 19  21@.(@....%9....
0001E130   20 4F 5B 2F  27 30 1A 49  42 7F 08 03  00 01 04 16   O[/'0.IB.......
0001E140   17 1C 4E 4E  38 52 64 4F  24 2D 10 01  00 00 4A 07  ..NN8RdO$-....J.

I see three sorts of data; the above:

Code:
00021F00   00 00 18 32  0C 00 01 00  00 01 18 32  0C 00 01 00  ...2.......2....
00021F10   00 02 18 32  0C 00 01 00  00 03 18 32  0C 00 01 00  ...2.......2....
00021F20   00 04 18 32  0C 00 01 00  00 05 18 32  0C 00 01 00  ...2.......2....
00021F30   00 06 18 32  0C 00 01 00  00 07 18 32  0C 00 01 00  ...2.......2....
00021F40   00 08 18 32  0C 00 01 00  00 09 18 32  0C 00 01 00  ...2.......2....

That looks like MIDI, and I can find bits of it in your included MIDI file, but not all of it. Then it ends with stuff that looks like this:

Code:
00023F80   18 18 32 32  0C 0C 00 00  01 01 02 05  03 32 64 3C  ..22.........2d<
00023F90   49 6E 69 74  69 61 6C 20  50 61 74 63  68 3E 20 03  Initial Patch> .
00023FA0   02 18 00 30  01 30 18 18  32 32 0C 0C  00 00 01 01  ...0.0..22......
00023FB0   02 05 03 32  64 3C 49 6E  69 74 69 61  6C 20 50 61  ...2d<Initial Pa
00023FC0   74 63 68 3E  20 03 02 18  00 31 01 31  18 18 32 32  tch> ....1.1..22
00023FD0   0C 0C 00 00  01 01 02 05  03 32 64 3C  49 6E 69 74  .........2d<Init
00023FE0   69 61 6C 20  50 61 74 63  68 3E 20 03  02 18 00 32  ial Patch> ....2
00023FF0   01 32 18 18  32 32 0C 0C  00 00 01 01  02 05 03 32  .2..22.........2

That corresponds to the three 'file types' you mentioned. Interestingly, this is _prefixed_ with something which is clearly a file header:

Code:
0001E000   03 00 00 00  00 00 41 20  20 20 20 20  20 20 20 20  ......A
0001E010   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................
0001E020   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................
0001E030   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................

That's got another copy of the filename in it, plus a very suspicious-looking 3; three chunks of data in the file?

Looking back at the directory, there's a structure at 0x1de00 which looks like a bitmap. On the blank disk, it's:

Code:
0001DE00   FF 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................
0001DE10   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................
0001DE20   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................
0001DE30   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................

On the disk with the file on it, it's:

Code:
0001DE00   FF FF FF FF  FF FF FF FF  FF 00 00 00  00 00 00 00  ................
0001DE10   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................
0001DE20   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................
0001DE30   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................

That's an extra eight 0xff bytes, so I think that represents occupied disk blocks. Assuming the directory and bitmap occupy one block, as represented by the first 0xff, that makes a block 3kB. That's weird, because they're usually powers of two, but given that our file is eight blocks long, then it should end at 0x1e000 + (8*3*1024) = 0x24000, which matches what we see on the disk. So the maths check out. (Although I now notice that 3kB matches the track size.)

From this, I think I can write a read-only filesystem plugin for FluxEngine which allows extracting individual files, and I'll have a go at that. But I am very curious as to what the first half of the disk is used for. On the images you sent me, they're completely blank. Maybe block numbers loop round? Could you try filling a disk up to the brim with whatever junk you can find, and then imaging that?
 
Back
Top