17 Jul
2018
17 Jul
'18
5:39 p.m.
> 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.
<Pedantic>
<Over-simplified>
<!-- Chuck, Tony, Liam, and others can list errors and "lies to children"
-->
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.
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. 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.