Why GoTEK SFR1M44-U100 is slow...

Tue Jul 17 16:39:39 CDT 2018

>> Just a question, you’re not expecting the Gotek to whizz files onto the 
>> Compaq are you?

On Tue, 17 Jul 2018, Grant Taylor via cctalk wrote:
> No, not as such.
>> It may be something modern emulating a floppy drive but it also has to 
>> emulate the floppy drive rotational speed so it should be the same speed as 
>> a real drive.
> I am guessing that there is some false hope ~> expectation on my part that 
> things might be a little bit faster than they were.
> That being said, there is every chance that this process was doing extra work 
> and likely verifying the format (I think format has a flag to test a floppy 
> as it's formatted), thus making it take longer.

<Pedantic>
<Over-simplified>

The MS-DOS VERIFY command meant that every time that a sector was written, 
the computer would then check the CRC, and confirm that it was a valid 
sector.  Contrary to popular ASSUMPTION, it absolutely did NOT compare the 
content of the sector with what it should be.  (re-read sector and 
compare?  Nope, just confirm that it is readable)  A drive with dead write 
electronics can "write" and VERIFY, simply because the unaltered previous 
content does VERIFY as valid sectors).

Some people would turn VERIFY OFF, and disable PARITY, in a performance 
attempt because they assumed that it wasn't actually doing anything.
Q: Do you want to know whether there are errors?

A FORMAT VERIFY that formats all tracks, and THEN verifies them is slower, 
but more reliable than format and verify of each track, since it is a 
recheck that each track is written on the correct cylinder.  A Format and 
verify before changing track, on a drive with broken stepper, could format 
and verify every track all on the same cylinder.

> I conceptually get that the GoTEK can't go any faster than the Floppy's IDE 
> (I thought floppy was a derivative of IDE.) bus can carry the data. I was 
> hoping to avoid some timings of the physical aspects of spinning the disk and 
> seeking.

Floppy interface (SA800/SA400 and derivatives) was long before the IDE 
("Integrated Device Electronics") hard disk interface, so the derivation 
is mostly the other direction.

The disk spins at 360 (8", 1.2M, NEC) or 300 (5.25", 3.5") RPM. (180RPM 
for Weltec 1.2M kludge to get 1.2M on XT; 600RPM for one of the Sony 3.5")

The data transfer rate was
125,000 bits per second (5.25" SD)
250,000 bits per second (8" SD, 5.25" DD, 3.5" DD, Weltec 1.2M)
300,000 bits per second (360K disk in 1.2M drive)
500,000 bits per second (8" DD, 1.2M, 3.5" HD)
1,000,000 bits per second (2.8M)

Each controller only supported some of those.
5150 was 250,000.
5170 (AT) was 250,000, 300,000, 500,000.
Spinning the disk at 300RPM, and transferring at 250,000 bps controlled 
the positioning of the bits on the track.
Spinning faster, even if only virtual, can't change that data transfer 
rate.  Well ALMOST not.  Weltec had a slower than normal drive to permit 
1.2M on slower controllers, and Sony had a 3.5" drive that sun at 600RPM 
requiring controller with faster data transfer rate).
To over-simplify, you can think of the rotational speed as being solely 
to match the controller data transfer rate; and therefore, not helped by 
this.

So, those preset data transfer rates in the controller are the sole 
determining factor of the speed that you will get.

On the other hand, SEEK could be improved.
You could probably get some minor speed improvement by tampering with 
the seek time parameters!  The computer waits after a "STEP" command to 
give the drive time to step and settle.  When IBM used the Qumetrak 142 
drives (PCJr), they had to release a new version of PD-DOS (2.10) to 
slow down that time for the SLOW-ASS drives.  Check out INT 1Eh (pointer 
to where those vaariables are stored)

So, other than the possibility of a faster virtual SEEK/STEP time, this 
will be exactly the same speed as a real floppy.

It also might be possible to create new firmware AND drivers on PC, that 
would fake being at 600RPM, to let the FDC use its 500,000 bps data 
transfer rate.  Or use the 1,000,000 bps rate on 2.8M capable controllers.

> I think I've been messing with virtualization too much that can simply do 
> things a LOT faster because more of the computer is emulated.  (This does 
> come with it's own problems too.)

yep.  that would also does away with the FDC data transfer rate 
bottleneck.
</Over-simplified>
</Pedantic>

> It will be interesting to see the track count on the OLED once I install it.

That will be a sweet add-on

>> Bit like watching a kettle boil :)
> Or watching paint dry.
Or grass growing.

--
Grumpy Ol' Fred     		cisin at xenosoft.com