I have images of about 5 different Dreamdisk floppies obtained from the owner of the only known remaining Sorcerer/Dreamdisk setup.
These were made with a device called a FloppyIO created by Microbee Software Preservation Project as .DSK files in CPCEMU flavour. Because most of the images contain personal files there is only one, the "master", currently in circulation.
This is where I have got to with about a week or investigating why the recreated board isn't writing to disks, or at least to Goteks.
1. On one (only) of the images I got a BDOS error "disk is read only error" or similar. I looked this up and found that the STAT command can tell you if a disk is RO. None of the Dreamdisk floppies have STAT but I have it only some images for a Sorcerer with a Digitrio controller. According to STAT the disk is mounted? R/W.
2. Does CP/M think the disk is write protected? A: I don't see the Write Protect signal from the drive going active low. It stays pulled high by the resistor array (which is not on the schematic of the original board BTW but shouldn't matter).
3. I thought perhaps there is a difference between the original board and the recreation that was blocking writing. With an MSO connected to some of the more interesting lines on the buffers between the Dreamdisk and the Gotek I can see that the board
is in fact trying to write data to the Gotek. The Write Gate goes low and you can see data flicker on the Write Data line if you do something like:
(write 4 blocks of data to the disk with the filename MIKE).
The signal on write does look a little different to read so I thought perhaps some schematic or layout issue is causing data to be read at 5.25 inch data rate but written at 8 inch rate. However looking at the various lines which control the write bitrate I can't see anything changing between read and write. From what I understand of how the WD2793 works the variable capacitor and the trimpots do not affect the writing of data they only control the PLL used in read. So it shouldn't matter what position these are in. It is my understanding that Write Precompensation wouldn't be getting used on 5.25 inch floppies.
4. It does seem that the
Drive Select lines are not changing when you use SETDISK to configure multiple drives. The Drive Select lines A, B, C, D all stay low. So if you have two Goteks they both try and put data on the Read Data line. I may not be fully understanding how SETDISK works but I would have thought that if I told CP/M that Drive A is the first unit and B the second and then I do a DIR: that the drive select lines should change. Even so I can't see why, if this is actually inappropriate behaviour, the it could affect writing to disk when you only have one Gotek on the 34 way ribbon cable. The SIDE line does toggle a bit as the different areas of the disk are read so this contradicts the idea that these signals on Port48 aren't being correctly decoded. This observation is however what led me to dig into the 5/8 select logic.
5. When testing with the SAVE command it never completes - the Sorcerer freezes. If I RESET the machine I can no longer boot off that .HFE image and I need to select a different one off the stick. Trying to write to any of the disk images results in that image becoming unbootable and you get a BDOS error. You need to copy fresh files over before you can boot again and continue testing. I don't know if this is what jl was seeing?
Tonight I had a brainwave and decided to inspect the .HFE files that no longer boot in the HxC floppy emulator software. I expected to see them messed up. I was surprised to see no evidence of corruption in the form of CRC errors. If I am using the software correctly there are
no bad blocks being shown on any of the images but the images are being changed in a way that prevents booting. (I should try using SETDISK to overlay a B: drive on the first Gotek and by swapping sticks see if I can still get a directory on the these altered HFE files).
Conclusion
So apart from the drive select symptom which could simply be misdiagnosis on my part (I have not yet tried to directly write to the latch using monitor or BASIC commands) I can't see evidence of anything at the electronic level causing a problem. This makes me suspect the disk images themselves. Do they have some pathology that when CP/M tries to find empty space to write a sector it writes in the wrong place (on the system or directory track?) and this clobbers the disk. Or when updating the directory after writing the sector(s) it messes it up.
As mentioned the images were created with the Floppyio and the disk definition arrived at by trial and error. Success being defined as it works in MAME and you can extract sane directory listing via cpmtools and extract large text files (.MAC .PRN) etc that appear intact. It is possible that there is some subtle issue in the disk definition that only shows up when trying to write to these .DSK files. jl and CM have both been successful in writing to the disk images using cpmtools to put new files on them which suggests they are fine but is it possible that the .DSK files and slightly funky and the cpmtools definition is undoing that funkiness leading to clean directory listings and text files.
Some next steps:
1. Image the physical media again, this time using a Kryoflux, as this is the reference standard. Create new HFEs and see what happens.
2. Convert .DSK to .MFI and trying writing to these disk images in MAME.
3. Try connecting a real floppy drive. Unfortunately I don't have any backup copies of Dreamdisk disks on physical media and I don't want to risk those originals that have not been returned to their owner.
P.S. if you try and SAVE only 1 or 2 blocks you don't get a BDOS error but neither do you get your file on disk. Perhaps CP/M only verifies larger transfers.
