davidgiven / fluxengine

PSOC5 floppy disk imaging interface
MIT License
357 stars 69 forks source link

Testing Out a New Fluxengine with IBM Floppies #224

Open ajacocks opened 3 years ago

ajacocks commented 3 years ago

I am attempting to test out a Fluxengine that I have just finished building, by writing and reading some 3.5” and 5.25” IBM floppy images, to verify that everything works. I have the Fluxengine attached to a 3.5” 1.44MB floppy drive, as drive 0, and a 5.25” 360kB floppy drive, as drive 1.

Writing to the 1.44MB drive seems to work:

$ sudo ./fluxengine write ibm --ibm-preset-1440 -i /net/zeus/raidstore/iso-images/microsoft/ms-dos/Retail/Microsoft\ MS-DOS\ 6.22\ \(3.5\)/Disk1.img
reading 80 tracks, 2 heads, 18 sectors, 512 bytes per sector, 1440 kB total
Writing to: :d=0:s=0-1:t=0-79
  0.0: Using FluxEngine with serial number D401021906153294
199 ms in 79939 bytes
  0.1: 199 ms in 90607 bytes
  1.0: 199 ms in 84154 bytes
  1.1: 199 ms in 79840 bytes
  2.0: 199 ms in 79496 bytes
...
 78.0: 199 ms in 75873 bytes
 78.1: 199 ms in 75857 bytes
 79.0: 199 ms in 75876 bytes
 79.1: 199 ms in 75856 bytes

And reading works, too, but the read-back image isn’t identical to the original:

$ diff /net/zeus/raidstore/iso-images/microsoft/ms-dos/Retail/Microsoft\ MS-DOS\ 6.22\ \(3.5\)/Disk1.img ./dos622_disk1.img 
Binary files /net/zeus/raidstore/iso-images/microsoft/ms-dos/Retail/Microsoft MS-DOS 6.22 (3.5)/Disk1.img and ./dos622_disk1.img differ
$ file /net/zeus/raidstore/iso-images/microsoft/ms-dos/Retail/Microsoft\ MS-DOS\ 6.22\ \(3.5\)/Disk1.img ./dos622_disk1.img/net/zeus/raidstore/iso-images/microsoft/ms-dos/Retail/Microsoft MS-DOS 6.22 (3.5)/Disk1.img: DOS/MBR boot sector, code offset 0x3c+2, OEM-ID ")^<9sIHC" cached by Windows 9M, root entries 224, sectors 2880 (volumes <=32 MB), sectors/FAT 9, sectors/track 18, serial number 0x14ec0f67, unlabeled, FAT (12 bit), followed by FAT
./dos622_disk1.img:                                                                           DOS/MBR boot sector, code offset 0x3c+2, OEM-ID ")^<9sIHC" cached by Windows 9M, root entries 224, sectors 2880 (volumes <=32 MB), sectors/FAT 9, sectors/track 18, serial number 0x14ec0f67, unlabeled, FAT (12 bit), followed by FAT

Writing 720k floppies on that drive seems to work, as well, but reading is an issue:

Reading seems to be somewhat problematic:

$ sudo ./fluxengine read ibm -s :d=0 -o dos500a_disk1.img
Reading from: :d=0:s=0-1:t=0-79
Using FluxEngine with serial number D401021906153294
  0.0: 247.43 ms in 68352 bytes
       1 records, 0 sectors; 
       0 bytes decoded.
  0.1: 247.266 ms in 69696 bytes
       3 records, 0 sectors; 
       0 bytes decoded.
  1.0: 248.089 ms in 69824 bytes
       3 records, 0 sectors;
...
 79.0: 247.947 ms in 62080 bytes
       0 records, 0 sectors; 
       0 bytes decoded.
 79.1: 247.748 ms in 62016 bytes
       6 records, 0 sectors; 
       0 bytes decoded.
Autodetecting output geometry
H.SS Tracks --->
No sectors in output; skipping analysis
writing 0 tracks, 0 heads, 0 sectors, 0 bytes per sector, 0 kB total

Using the 360k drive (#1) also has issues:

$ sudo ./fluxengine read ibm -s :d=1 -o dos500_disk1.img
Reading from: :d=1:s=0-1:t=0-79
Using FluxEngine with serial number D401021906153294
  0.0: 250.987 ms in 50624 bytes
       0 records, 0 sectors; 
       0 bytes decoded.
  0.1: 251.126 ms in 69120 bytes
       22 records, 11 sectors; 1.98us clock (505kHz); 
       logical track 0.1; 4608 bytes decoded.
  1.0: 250.931 ms in 69760 bytes
       22 records, 11 sectors; 1.98us clock (504kHz);
...
H.SS Tracks --->
0. 0 X.......................................
0. 1 X.......................................
0. 2 X.......................................
0. 3 X.......................................
0. 4 X.......................................
0. 5 X.......................................
0. 6 X.......................................
0. 7 X.......................................
0. 8 X.......................................
1. 0 ........................................
1. 1 ........................................
1. 2 ........................................
1. 3 ........................................
1. 4 ........................................
1. 5 ........................................
1. 6 ........................................
1. 7 ........................................
1. 8 ........................................
Good sectors: 711/720 (98%)
Missing sectors: 9/720 (1%)
Bad sectors: 0/720 (0%)
writing 40 tracks, 2 heads, 9 sectors, 512 bytes per sector, 360 kB total

So, it seem to be able to read most of the disk, but not the first sector of the first 9 tracks.

Writing doesn’t seem to work, at all:

$ sudo ./fluxengine write ibm -d:d=1:s=0-1:t=0-39 -i /net/zeus/raidstore/iso-images/microsoft/ms-dos/Retail/Microsoft\ MS-DOS\ 5.00\ -\ 360K/Disk01.img:b=512:c=40:h=2:s=9
reading 40 tracks, 2 heads, 9 sectors, 512 bytes per sector, 360 kB total
Writing to: :d=1:s=0-1:t=0-39
  0.0: Error: track data overrun

Thanks for all the hard work! This is an amazing device.

davidgiven commented 3 years ago

Could you try fluxengine test voltages with both drives plugged in, and then just the 3.5", and then just the 5.25"? Also try reads that way. I've seen oddities with two drives connected simultaneously, probably caused by termination issues.

ajacocks commented 3 years ago

With both drives connected, we get this:

$ sudo ./fluxengine test voltages
Using FluxEngine with serial number D401021906153294
Output voltages:
  Both drives deselected
      Logic 1 / 0:  0.64V / 5.00V
  Drive 0 selected
      Logic 1 / 0:  0.65V / 5.00V
  Drive 1 selected
      Logic 1 / 0:  0.65V / 5.00V
  Drive 0 running
      Logic 1 / 0:  0.64V / 5.00V
  Drive 1 running
      Logic 1 / 0:  0.65V / 5.00V
Input voltages:
  Both drives deselected
      Logic 1 / 0:  4.88V / 4.98V
  Drive 0 selected
      Logic 1 / 0:  0.00V / 4.88V
  Drive 1 selected
      Logic 1 / 0:  0.03V / 4.88V
  Drive 0 running
      Logic 1 / 0:  0.00V / 4.88V
  Drive 1 running
      Logic 1 / 0:  0.04V / 4.88V

With just the 3.5, I get this:

$ sudo ./fluxengine test voltages
Using FluxEngine with serial number D401021906153294
Output voltages:
  Both drives deselected
      Logic 1 / 0:  0.09V / 5.00V
  Drive 0 selected
      Logic 1 / 0:  0.09V / 5.00V
  Drive 1 selected
      Logic 1 / 0:  0.09V / 5.00V
  Drive 0 running
      Logic 1 / 0:  0.09V / 5.00V
  Drive 1 running
      Logic 1 / 0:  0.09V / 5.00V
Input voltages:
  Both drives deselected
      Logic 1 / 0:  4.92V / 4.98V
  Drive 0 selected
      Logic 1 / 0:  0.00V / 4.88V
  Drive 1 selected
      Logic 1 / 0:  4.98V / 4.99V
  Drive 0 running
      Logic 1 / 0:  0.00V / 4.88V
  Drive 1 running
      Logic 1 / 0:  4.99V / 4.99V

With just the 5.25, I get this:


$ sudo ./fluxengine test voltages
Using FluxEngine with serial number D401021906153294
Output voltages:
  Both drives deselected
      Logic 1 / 0:  0.56V / 5.00V
  Drive 0 selected
      Logic 1 / 0:  0.56V / 5.00V
  Drive 1 selected
      Logic 1 / 0:  0.56V / 5.00V
  Drive 0 running
      Logic 1 / 0:  0.56V / 5.00V
  Drive 1 running
      Logic 1 / 0:  0.56V / 5.00V
Input voltages:
  Both drives deselected
      Logic 1 / 0:  4.92V / 4.98V
  Drive 0 selected
      Logic 1 / 0:  4.99V / 4.99V
  Drive 1 selected
      Logic 1 / 0:  0.04V / 4.88V
  Drive 0 running
      Logic 1 / 0:  4.99V / 4.99V
  Drive 1 running
      Logic 1 / 0:  0.04V / 4.88V

Thanks!

davidgiven commented 3 years ago

Honestly, that looks pretty normal. Any luck trying a read with just one drive attached?

hharte commented 3 years ago

Hello @ajacocks ,

Regarding the mismatched image after writing/reading back, I did notice an issue with some 5.25" drives that could possibly be addressed with write precompensation. The inner tracks would not read properly after being written. Sometimes they would read on retry. I also tried using GreaseWeazle to read/write using the same drive, and found that enabling write precompensation in GreaseWeazle helped. Unfortunately, the precompensation aglorithm in FluxEngine's Fluxmap::precompensate() did not help; in fact, it made things worse.

After reading an article describing that different amounts of precompensation were optimal for different brands/models of drive, I switched to another brand 360K floppy drive (to an Alps drive from an IBM external 360K drive) and it works fine now.

Also, I added some presets for reading and writing 5.25" floppies in PR#227 which seem to work well for me.

ajacocks commented 3 years ago

I will give these a shot.

I'm generally not quick to change cabling since my enclosure is pretty tightly packed. I should probably pull everything out until I have all the bugs out, but I haven't done that.