Warning: This description is lengthy and technical. The punch line (TLDR) is that ECS runs the drives at about 285rpm rather than 300rpm and that messes with a lot of tools.
I had previously done some work on the two drives in this unit but neither of them was good. One had a dud tacho in the spindle motor. I had previously used the other to copy some of the disks, but I was not sure how well it was working.
The other two were very dirty:
- Blew out the leaves, webs, dust
- Cleaned out the grease on the door lock and head shaft and re-greased.
- Cleaned heads
- Replaced missing felt in top “head”.
I put both viable drives on ImageDisk and formatted a disk on each and then ran an alignment test. All good. Then I swapped the disks and not all was good. There was a discrepancy on tracks 76 to 77. This resolved with cleaning the lead screw.
The format is interesting; 80 tracks on a 77 track device for a start. There are no physical sectors – just tracks with each track having a CRC. According to the technical manual each track has 6144bytes of data with two bytes of preamble and a single byte sync. The checksum is 2 bytes. The total count is 6149 bytes. This means that if one bit is out the whole track is dead. There are 48 logical sectors.
That gives 491k on a single sided disk cf 180k on an IBM single sided disk or 6.144k per track compared to 4.6k for IBM. That’s 4:3. How? There is no sector overhead and the whole track is used – very tightly. At 250k/s this data would take 197ms to write. One rotation at 300rpm takes 200ms so this is tight.
According to the Micropolis manuals, the drives spin at 300±6rpm. The period can be as small as 196ms. The normal bit rate for double density 5.25” drives is 250k/s. That’s 49kbit/track or 6.127kB/track. That means that there would not be enough space for the ECS track data.
I imaged all the disks using the Sorcerer single drive unit and greaseweazle v4. It was a struggle to gets disks to operate reliably with the sorcerer and I can’t be 100% confident that the single drive unit is perfectly aligned. It has been working fine for reading and making sorcerer disks though. The Sorcerer drive runs very close to 300rpm.
Looking at the fluxes with the HxC software, it appears that the bit rate is a little higher than the “standard” 250kb/s. Instead of seeing intervals of 4, 6, and 8us (as expected for 250k MFM coded data), there intervals are 3.8, 5.6, and 7.4. This is reading “factory” disks at about 300rpm. This is about 265kbit/s. That’s 52kb/track or 6.49kB/track which is sufficient to hold the documented track data.
| Nominal 4us | Nominal 6us | Nominal 8us | |
| Disk 10 (299rpm) | 3.8 | 5.6 | 7.4 |
| Disk 11 (299rpm) | 3.8 | 5.6 | 7.2 |
| Disk12 (298rpm) | 3.9 | 5.5 | 7.4 |
So the data rate for the ECS system is higher than the norm or, noting that both of the drives seemed to be running quite slowly, it is also possible that the data rate is normal but rotational speed is lower.
Regardless, I would expect that reading and writing with the same drive would preserve the data rate ie the archive drive speed should not matter.
I tried some experiments:
Sorcerer drive =300rpm
ECS Drive = 277rpm
In principle, it is possible to write SCP images back to disk, but in practice the errors pile up. It’s usually better to convert to HFE and then back to SCP which has the effect of “tidying things up”. HFEs can also be used in a gotek.
The HxC software may handle the strange timing well – or it may not. It’s hard to say. It certainly gets confused about rotational speed when using the track analyser. It looks like to tries to change RPM to correct the data rate.
a. Read disk 31 using sorcerer drive to SCP.
b. Convert to HFE. This averages the timings – 7.75us.
c. Write HFE to sorcerer drive. This writes clean timings to disk.
d. Read back using sorcerer drive.
e. Convert to HFE.
f. Surprise result: The data rate has increased again. I smell a rat; 7.75us is now 7.5us.
a. Read disk 31 using sorcerer drive to SCP.
b. Write SCP to sorcerer drive.
c. Read back using sorcerer drive.
d. Convert to HFE. Same result: The data rate has increased again. 7.75us is now 7.5us. This cuts HxC out of the loop. This is a greaseweazle thing!
a. Read disk 31 using sorcerer drive to SCP.
b. Convert to HFE.
c. Write HFE to ECS drive.
d. Read back using ECS drive.
e. Convert to HFE. Another surprise result: The data rate has slowed down. 7.75us is now 8.0us. The drive is running slow: 277rpm.
a. Read disk 31 using sorcerer drive to SCP.
b. Convert to HFE.
c. Write HFE to Sorcerer drive.
d. Read back using ECS drive.
e. Convert to HFE.
f. Another surprise result: The data rate has slowed down. 7.75us is now 8.1us. The drive is running slow 277rpm, whereas the sorcerer was very close to 300rpm.
I had expected that the data rate would be preserved if I wrote to and read from the same drive. It was not. I still can’t work out exactly what is going on here, but I suspect that greaseweazle is correcting the data rate to 250kb/s when it writes.
It eventually dawned on me that I could observe the data rates on the real machine and I could also have it write to a floppy disk. This quickly confirmed that the data rate is 250kb/s so the drives were definitely intentionally set up to run slowly.
I suspect (pure speculation!) that the original design forgot to allow for inaccuracy in the rotational speed (it is not clear whether the time during the index pulse is useable). Using nominal timing, the available period is 200ms. At 250kb/s this is 50000 bits or 6250 bytes. Recall that 6149bytes need to be written, giving only 100 bytes or 3ms margin.
Perhaps variation in rotational speed or in the index pulse timing caused issues in practice, and the remedy was to drop the rotational speed by 5%. This does have the effect of increasing the bit density on the media by 5% and, given that 80 tracks are used rather than the specified 77 this makes the bit density on the inner tracks much higher than other computers. Track 68 on this machine has the same bit density as track 77 on others eg the sorcerer. This could be expected to make the inner tracks less reliable than other computers.
It turns out that ECS printed up new strobe labels with 21 ticks instead of 20 and stuck them on the drive band wheel so that the drives could be easily adjusted to about 285rpm. This combined with the use of 3 tracks above spec probably means that the specified bit density is very high on the inner tracks.
If I write the disk back using the sorcerer drive and then use the disk in one of the slow ECS drives, then the data rate will be lower than the original. This is odd indeed.
If I write the disk back using a slow ECS drive and then use the same drive, the data rate will be correct. Also odd, but perhaps convenient.
Unfortunately, the data rate produced by the Goteks (with FlashFloppy) using the HFE created with the sorcerer drives is incorrect. The cleanliness of this data seems to allow them to generally operate anyway, but they are less than ideal.
The disks have been re-imaged using 285rpm. These images can be written back at 285rpm and all is sweet. The HxC software struggles with the low disk speed. Sometimes it works, sometimes it crashes, but mostly it just processes the data incorrectly so it is no good for HFE conversion. The bit streams are fine though, so maybe one day it will be good. I created HFEs using greaseweazle, and they work fine in the goteks – generally better than the 300rpm versions.
3 of the drives appear to be working ok. The last one has a tacho fault in the spindle motor. It can be a spares unit. One unit had a cracked power connector solder joint. That is probably a result of the constant connecting and disconnecting.
One had a screw broken off (holding the base cover). I drilled it out. It wasn’t pretty. I ended up redrilling and tapping the holes for 4mm screws (some of the originals were missing anyway. I think the covers and screws (and possibly taps) were an ECS thing anyway.
Alignment is tricky. The usual goto is Imagedisk, but it doesn’t recognise the ECS formatted disk. I have chosen a gold standard drive – one that seems to work well with existing disks – and have used it to write an “alignment disk”. This disk has been formatted in imagedisk. I only had to adjust one drive.
Note that one of the drives is a later version that is not covered by the schematics in the maintenance manual.
The images have been sent to Alan Laughton to add to the Microbee Technologies File Repository. Because the disk format has not been deciphered, the files have not been extracted.