PDA

View Full Version : Hard Sector 5.25" Floppies (Yet again...)



deramp5113
January 25th, 2018, 08:19 AM
So it looks like Dave at Athana took himself out of the floppy disk business and sold his inventory to Tom over at http://floppydisk.com. Tom has about 200 of the 5.25 inch 16 hard sector disks remaining, and as we already know, zero of the 10 hard sector disks.

I have a good inventory of 5.25 inch 16 hard sector disks as well, so these don't seem as rare as the 10 sector disks. So here's my thought:

An in-line virtual sector generator (VSG) works pretty well for using soft sector media with controllers that expect 10 or 16 hard sectors as long as the drive has low instantaneous speed variation (ISV). In general, the newer half-height drives with direct drive hub motors work well with a VSG. The older full-height drives with belt driven motors are a bit more hit-or-miss when used with a VSG. Unfortunately, most of the older systems with a hard sector controller used full-height drives, so it would be nice to be able to reliably use full height drives with these older systems.

So what about adding a mode in the VSG that makes a 16 hard sector disk look like a 10 hard sector disk? Instead of getting just one timing data point per revolution, the VSG would get 17 data points per revolution and could much more accurately generate the 10 virtual sector pulses. While 16 sector disks are rare compared to soft sector media, for the size of the hobby community that needs hard sector disks, the known inventory of 16 sector disks is relatively large.

Thoughts?

Mike

Dwight Elvey
January 25th, 2018, 09:05 AM
That might work. It is not a hard problem, even for an Arduino. No need to make a special board, just make cable with an Arduino Maple hot glued to it.
Still, I think punching old 360 disk is best.
Dwight

Chuck(G)
January 25th, 2018, 09:10 AM
A silly question, so please forgive my density.

Why bother with floppies at all? A suitable emulator can handle any hard-sectoring scheme you can dream of without all of the mechanical issues.

How long do we expect our inventory of media to remain viable? I was a bit surprised over the weekend when formatting up some 5.25" NOS shrink-wrapped media at how many were showing problems on the inner tracks. I can attribute this only to age-related degradation.

deramp5113
January 25th, 2018, 10:29 AM
A silly question, so please forgive my density.

Why bother with floppies at all? A suitable emulator can handle any hard-sectoring scheme you can dream of without all of the mechanical issues.

How long do we expect our inventory of media to remain viable? I was a bit surprised over the weekend when formatting up some 5.25" NOS shrink-wrapped media at how many were showing problems on the inner tracks. I can attribute this only to age-related degradation.

I expect my inventory of media to last until I the day I die or I am too senile to know what I'm doing ;)

My preference for the old machines I restore is using the drives the computer was used with in its day. To me a big part of the experience is handling the floppy and enjoying the various noises the drives make. Most hard sector controllers are from the day of full-height drives and the computer cabinet or external drive cabinets are cutout for the full height drives. The newer 1/2 height drives are very reliable when using the VSG with a hard sector controller, and frankly, the majority of my full height drives also work fine with the VSG, but I'm considering this "10 from 16" hard sector feature to provide a way to make the full-height drives as reliable as the 1/2 height.

Mike

Chuck(G)
January 25th, 2018, 11:26 AM
One problem with the full-height drives is that being belt-driven with open-loop speed control is that the speed is a lot less reliable.

I tried to do a hard-sector generation with one using a small PIC microcontroller a few years ago and found that the speed variation on the full-height drives was too great. Half-height, direct-drive spindle motor drives were fine. So I dropped the project, seeing as how most folks would want to use the FH drives.

SomeGuy
January 25th, 2018, 11:28 AM
I was a bit surprised over the weekend when formatting up some 5.25" NOS shrink-wrapped media at how many were showing problems on the inner tracks. I can attribute this only to age-related degradation.
Were those high density 5.25" disks? I've seen many with inner track issues both reading and formatting, including disks that I knew were well stored. Really odd thing is that after retrying a number of times they eventually start reading, re-formatting, and testing fine.

Chuck(G)
January 25th, 2018, 11:31 AM
No--plain old "360K' duplicator-grade floppies. I haven't checked what we used back then, but I think they were Maxells.

glitch
January 25th, 2018, 11:42 AM
What happened with the disk punching project?

deramp5113
January 25th, 2018, 12:22 PM
One problem with the full-height drives is that being belt-driven with open-loop speed control is that the speed is a lot less reliable.

I tried to do a hard-sector generation with one using a small PIC microcontroller a few years ago and found that the speed variation on the full-height drives was too great. Half-height, direct-drive spindle motor drives were fine. So I dropped the project, seeing as how most folks would want to use the FH drives.

I actually have very good luck with most full height drives and the VSG I created. The VSG syncs to the rotational rate of the disk drive and adjusts each revolution with a running average. And while most full height drives I have are reliable with the VSG, not all are. Reliable operation is not tied to a particular drive brand or model. If a given belt-driven drive is reliable with the VSG, it tends to stay that way. If a particular drive is not reliable with the VSG, it tends to stay unreliable.

Mike

Chuck(G)
January 25th, 2018, 12:36 PM
My procedure was to hold off index signals until two full revs after the drive was selected, during that time, measure the rotational speed using a 16-bit timer(the first time to get a value, the second time to verify that the first is within tolerance. Repeat if the first two revs don't agree), then subdivide according to he number of sectors. I found it very unreliable when the host controller didn't allow for a generous amount of sync before starting the actual sector ID and data fields. I was running in 16-sector mode on 100 tpi MPI drives. Maybe those were the problem. At any rate, one doesn't easily find 100 tpi direct-drive floppy drives, which is why I gave up on the project. Still have the code somewhere...

Dwight Elvey
January 25th, 2018, 01:07 PM
What happened with the disk punching project?

I and a friend had some made. The alignment of the pieces was not as good as we'd like but they worked. Sometimes it would leave a little bit around the edge as the punch got dull. I made them with more constraint to pricing, keeping the price with shipping around $45. The SEBHC group made some new ones, closer to my original design that have better alignment. Norberto Collado had 10 of them made. He was selling them for $110. Check with the SEBHC group to see if he has any left.
Dwight

deramp5113
January 25th, 2018, 02:18 PM
My procedure was to hold off index signals until two full revs after the drive was selected, during that time, measure the rotational speed using a 16-bit timer(the first time to get a value, the second time to verify that the first is within tolerance. Repeat if the first two revs don't agree), then subdivide according to he number of sectors. I found it very unreliable when the host controller didn't allow for a generous amount of sync before starting the actual sector ID and data fields. I was running in 16-sector mode on 100 tpi MPI drives. Maybe those were the problem. At any rate, one doesn't easily find 100 tpi direct-drive floppy drives, which is why I gave up on the project. Still have the code somewhere...

Yes, handling drive selection and auto-detecting whether hard or soft sector media is inserted, and then generating the proper pulses, and all within the startup time and manner is difficult. I wrote a paper here: http://deramp.com/downloads/misc/virtual_sector_generator/startup%20and%20select%20issues.pdf

For both of the North Star controllers, you CAN'T hold off sector pulses because the FDC generates its own sector pulses (at a slightly slower rate) whenever a disk is not generating pulses. For the Micropolis controller (probably the 100tpi application you were working on?), software begins reading after 250ms no matter what the drive is doing, so you couldn't hold off that controller for long either.

Mike

Chuck(G)
January 25th, 2018, 02:28 PM
So on the NS controller, how does the controller tell when the drive is ready? If it uses a "drive ready" signal, then you hold that off, the same way the old Micropolis buffered-seek drives did. There are later half-height and 3.5" drives that block sector pulses until the drive comes ready.

deramp5113
January 25th, 2018, 07:57 PM
So on the NS controller, how does the controller tell when the drive is ready? If it uses a "drive ready" signal, then you hold that off, the same way the old Micropolis buffered-seek drives did. There are later half-height and 3.5" drives that block sector pulses until the drive comes ready.
With the North Star controllers there is no drive ready signal to the controller. With their DD controller, software waits for an index sync valid flag, and with the single density controller, software waits for 13 sector pulses to ensure index sync has occurred (both of these are after waiting for motor start-up time if the motor was just started).

The Micropolis hard sector controller originally used a drive ready signal when the board left the hub motor running all the time and the head was loaded or unloaded like was done with 8” drives. However, as detailed in the document referenced in my previous post, this was soon changed and the board was modified to stop the motor after a few seconds of inactivity like other 5.25”controllers. This mod also permanently asserted drive ready on-board and no longer used a ready signal from the drive.

The early drives used with these controllers didn’t support buffered seeks.

Mike

Chuck(G)
January 25th, 2018, 08:04 PM
So, back to my original statement, blocking (i.e. holding off or gating) sector/index pulses for two revs would do no harm, as the controller wouldn't see that the drive had come ready.

Correct?

"Drive ready" was an option on some early 5.25" drives. I've got some where it's a daughterboard with a 9602 one-shot, a 10-turn pot and a couple of resistors. Others either lacked it completely or incorporated it on the main drive PCB. Early drives also employed "head load" solenoids just like 8" drives. After you issued a head load, you waited 15-20 msec. or so for the head to quit bouncing before starting a write operation. Reads didn't matter--if the head was still bouncing, you'd get an error and pick up the data on the next rev after retrying.

deramp5113
January 26th, 2018, 06:23 AM
So, back to my original statement, blocking (i.e. holding off or gating) sector/index pulses for two revs would do no harm, as the controller wouldn't see that the drive had come ready.

Correct?

No, you can't just hold of index pulses for two revs. As mentioned in my previous post and detailed in the paper at, http://deramp.com/downloads/misc/virtual_sector_generator/startup%20and%20select%20issues.pdf, there are different issues to address with different controllers. For example:

1) The North Star controllers continue to generate internal sector pulses every 32.8ms in the absence of actual sector pulses. The single density controller does not have the "valid index" signal present on the double density controller, so software simply waits for 13 sector pulses to ensure index sync has occurred on the board. These 13 pulses would be satisfied by the internally generated sector pulses if the VSG blocked sector pulses and software would errantly begin peforming I/O at the 14th internal sector pulse.

2) Micropolis drivers begin I/O with the 1st sector pulse after waiting 250ms. If you blocked sector pulses for two revs (400ms), software would initiate I/O with the first sector pulse the VSG generated. However, since this is the first sector pulse received by the controller, there is a 15/16 chance the sector register is wrong at that point.

Mike

Chuck(G)
January 26th, 2018, 09:17 AM
Given (1), how does that NS controller determine that you have a disk in the drive? With no sector pulses or "Drive Ready" signal--forget the VSG--the controller would just start writing with no disk--and that's "normal"? Wow--that stretches credibility.

Or maybe we're still having a mis-communication here.

At any rate, my experiments showed that to have a reliable sector pulse, the position had to be within a couple of byte times every time, regardless of the drive. If one assumes a 4 usec bit time, you're talking about being able to position the sector pulse between drives within about 100 usec. I couldn't get that--and I doubt that anyone can. Perhaps the NS is sloppier on its requirements.

deramp5113
January 27th, 2018, 05:17 AM
Given (1), how does that NS controller determine that you have a disk in the drive? With no sector pulses or "Drive Ready" signal--forget the VSG--the controller would just start writing with no disk--and that's "normal"? Wow--that stretches credibility.

With the NS single density controller, software will consider the drive “ready” after the 13 sector count. This will occur without a disk inserted. A read operation will quickly fail as the hardware will not detect the sync character in a sector header, however, a blind write could be writing to a non-existent disk. Then again, writing to a disk without some sort of preceding read is not typical other than initializing a disk or maybe doing a disk-to-disk image copy. In these latter cases, the verify read will fail and produce an error as required.

Mike

deramp5113
January 27th, 2018, 05:45 AM
At any rate, my experiments showed that to have a reliable sector pulse, the position had to be within a couple of byte times every time, regardless of the drive. If one assumes a 4 usec bit time, you're talking about being able to position the sector pulse between drives within about 100 usec. I couldn't get that--and I doubt that anyone can. Perhaps the NS is sloppier on its requirements.

Yes, it is possible - I have numerous systems working this way - and no it’s not because the NS has sloppier timing requirements.

The typical hard sector layout used for both 10 and 16 sector formats (North Star, Polymorphic, Micropolis, Altair, Vector Graphic) provides about a 1ms leader and trailer prior to and following the payload of the sector. The 1ms leader is written with zeros and ends with the sync byte(s) marking the start of actual sector data. Read circuitry, in turn, has about a 500us ignore period after a sector pulse before sync hunt begins. The 500us ignore period combined with the 1ms leader of zeros allows about +/-500us of index alignment error between two drives.

With a VSG and soft sector media, variance in the virtual sector pulse position relative to the position of the actual sector data subtracts from this +/-500us margin. As already mentioned in my first, second, and third post in this thread, I have actually had pretty good results with the VSG even using belt-driven full height drives. For reference, this is with North Star SD, North Star DD, Micropolis, Altair mini-disk, Vector Graphic Tandon, and Polymorphic hard sector controllers. Belt-driven drives I’ve used reliably with the VSG include Shugart, Micropolis, Tandon, and Pertec 5.25” drives.

BUT... I do have some belt-driven drives whose ISV is too large and aren’t reliable with the VSG. No particular brand or model, no particular controller - just some drives won’t work reliably with the VSG due to large ISV. This is why I was considering generating 10 sector pulses from a 16 sector disk. This would get the outliers working as well.

Mike

Chuck(G)
January 27th, 2018, 09:14 AM
I'm glad it works for you--my tests were never that reliable across drives. The 13 sector delay count is pretty surprising--most drives of that time don't guarantee speed until at least 2.5 revs after motor power-on.

I almost exclusively read floppies, not write them, so the thing wasn't of that much use to me to pursue it much further--it was an experiment. I wonder how well your solution would work with 8" 32-sector floppies, however. Those generally have a much shorter preamble.

deramp5113
January 27th, 2018, 10:22 AM
The 13 sector delay is after timing out motor spin-up stabilization, or if a different drive is selected and the motor is already running. As I described earlier, counting through 13 sectors ensures that index sync has occurred and the sector register on the controller is correct.

Yes, it’s a totally different story with 8” floppies. The Altair format has just +/-200us tolerance (was originally just +/-160us). Way too tight for belt driven drives. However, I’ve found that VSG does work well with the direct drive DC motors in the Pertec FD400 drives used by MITS.

Mike