• Please review our updated Terms and Rules here

Northstar DOS

In my experiments, the case with a running "average" of 1 was essentially what you are considering: Compute the next sequence of sector times based on the period of the just completed full rotation. For the case of my particular drive, the most accurate sector tracking was actually obtained with a running average of the last 8 full revolutions. More samples responded to too slowly, fewer samples had more jitter. This was an optimized solution for this particular drive as a different drive did better with 4 samples.

I should probably add, that with my experiments, I used a hard sectored floppy with one scope probe attached to the sector/index output of the drive and a second scope probe monitoring the virtual sector output from my microcontroller. This allowed me to monitor the variance between the real sector pulses and the virtual pulses. What I did not measure directly was the repeatability of the virtual sector positions. This was my next step, in which I was going to track virtual pulse offset from the real sector pulse for each of 32 sector positions. The fact that I could reliably read/write the same soft sectored disk on the same drive using just virtual sector pulses indicates the repeatability wasn't too far off, however, it was clear I was on the hairy-edge of being able to read the original hard sectored disk without using the drive's sector pulses.

As seen with the HSFE - and even with the addition of intelligence in the pulse timing generator - the interchangeability of the media will probably be worse with belt driven drives than with drives that have a more stable direct-drive design.
 
One possible enhancement on the Average of 1 technique would be to collect the trend of index-to-index periods to spot if its increasing or decreasing and perhaps cast a predictive factor into the calculated map of sector pulses for the next revolution. Even a wavering pattern adds to its predictive placement.

- - -

Another factor in how well it might work on one hard sector count or another is the amount of gap space between the physical sectors. Its reasonable to expect that 10 hard sectors will be more forgiving that 32 hard sectors. The NorthStar MDS has a duration after the sector pulse where it detects a status bit from a polling loop and then starts to look for the sector so its likely to be more forgiving than 32 sectors which would have less space and require a quick response.
 
Last edited:
Yes, the SD Northstar is much more forgiving than the 32 sector 8" Altair drives I've been referring to.

With the SD Northstar, the read "hunt" period starts about 384us (480-96) into a 1024us period of zeros. This allows about -384us to +544us of jitter.

With the Altair drive, about -154us to +175us of jitter can be tolerated. In addition to being a tighter window, this also has to work across 32 sectors without a re-sync pulse instead of just 10.
 
On your Altair 8 inch drive with 32 sectors configuration, I'd assume most of the errors during Average of 1 algorithm, would be in the latter sectors on the track as potential speed changes since the last index mark are more cumulative.
 
Last edited:
JDallas said:
On your Altair 8 inch drive with 32 sectors configuration, I'd assume most of the errors during Average of 1 algorithm, would be in the latter sectors on the track as potential speed changes since the last index mark are more cumulative.
Click to expand...

Yes, exactly.
 
An interesting observation:
The North Star MDC-A4 runs the READ_DATA signal through the same 74LS14 as the HOLE (index+sector) signal.

If the micro can recognize the SYNC byte encoded pattern in raw form, it could use that timing to re-synchronize the following sector's synthesized sector pulse.

Now the position of the sector would be updated at sector granularity instead of index pulse granularity. That would be particularly advantageous to maintain sector synchronization on 32 sector format as it would correct away any cumulative speed differential from the last index pulse.

For general clarification, detecting the SYNC of a sector is, of course, too late to change the sector pulse of that sector because SYNC happens after the sector pulse. The value is that SYNC could better establish where the following sector pulse should be, and negates the predictive position error caused by any rotational speed changes. But the "too late" condition isn't a problem when the first sector is timed off the index pulse and has very little differential accumulated by rotational speed.

This would radically lessen the problem of later sectors on the track being out of sync and experiencing unusable jitter.

Note that writing a formatting command program, for soft-sectors it might format a track and then read the gap between the last sector's SYNC and the INDEX pulse to assure that the distance is not overly distorted by speed changes. If its out of range, reformat the track.

- - - -
The useful question is, can a micro detect the raw SYNC pattern without supporting logic glue and thus maintain the circuit goal of remaining within the 74LS14 dual in-line package profile. It would take some clever coding and a good micro but today we have speed advantages. might even use SPI register of the micro with an edge detect interrupt in a combination never intended.

- - - -
You might check your hard-sector controller(s) to confirm if it too has the READ_DATA signal on the same 74LS14 input; odds are that it does because hard-sector controllers are of a design time where less FDD signals were utilized. Just the pinouts will change among various FDC board designs. Document the brand/boards/74LS14 pin-outs for board you check.

On the North Star MDC-A4 the pins are:
pin 01 [ -o|>- ] 02 ........for HOLE (index+sector)
pin 13 [ -o|>- ] 12 ........for READ_DATA

I have a MDC-ADx schematic that has HOLE on pin 03, but need to confirm READ_DATA is also there.
 
Last edited:
Yes, scanning read data in real time to generate intra-revolution sync points improved virtual sector timing, however, I was back to "flying blind" during writes - especially for routines that write consecutive physical sectors.
 
Yes for reads, its ok, and for writing nonconsecutive sectors, it would be ok its but still good for short blocks of X% of a rotation where the cumulative motor variance isn't a problem. The problematic case is as you identified, the long consecutive write.

That could be fixed if the controller firmware was modified to do odd numbered sectors from a block during one rotation, even numbered sector in the next, when consecutive sectors exceeded a threshold. With odd/even passes you'd always have one sector read to SYNC up on before doing the next write.

Of course the irony in using read_data to create a sector pulse is that the micro is almost becoming a FDC of its own; though just looking for a SYNC pulse pattern for single or double density encoding could be done quicker can decoding data on the fly.

Perhaps the theoretical proof that hard-to-soft sector conversion is inherently unsound is that if the sector's written syncs become the over-riding sector position update, then as writes of data occur on the original formatted pattern, they'll migrate with speed variation and in doing so, affect the chain of all track sectors downstream. Given enough time they could compact to an impossible separation or expand beyond the index period or partial strings of each. The sector spacing could undulate around the track.

To avoid that, you'd have to uphold the index-period plan and only allow slight deviation from it. As the 74LS14 doesn't know if the stream is for READ or WRITE mode, it can't hold writes to a more strict placement. You'd almost have to include a reposition sector command in the driver to curb track undulation. That doesn't sound like it would be very stable.

SOLUTION: Firm-Sector Header Detection for Stable Hard-Sector Hole Emulation
I think the ultimate answer lies in the format step. To prevent sector creep you have to do what soft-sector and SMD winchesters, and other do: Use a sector header that is only written at the time of the format, except use a special sync character as the FSH (firm sector header). Then micro in the 74LS14 socket detects that and issues the sector pulse for the controller to work completely as before. Write sector data would remain tied to a fixed point on the track.

The nice advantage to writing a FSH during format is that the definition of its unique FSH sync character could be something easier in pattern for the micro to detect. That micro can also use its predictive sector hole map of the track to determine when it starts reading the READ_DATA signal to detect the FSH character.

This might not work of track formats that have little gap space as a long running sector write may overwrite the FSH. That can be calulated with a spreadsheet of mine for determining gap sizes in soft-sectored formats... just needs to be modified for the hard-firm-sectored pattern.
 
Last edited:
Hard sector controllers don't typically turn off the write gate signal until the next sector pulse is received. This means you can't scan read data looking for the soft sector mark to decide when to send that pulse.
 
PART 1: Formatting a new soft-sector floppy with firm-sector marks.
======

Given:
(1) A hardware modification can intercept the HOLE signal and monitor READ_DATA.
(2) The modification is independent and cannot be directly controlled by the host.
(3) Timed synthetic-sector-holes eventually lead to sector-migration failure over time.
(4) Hard-sector controllers typically require a sector pulse before allowing track writes.

Objective:
(1) Format a new soft-sector floppy with firm-sector marks to replace the physical sector holes.
(2) Describe a process to format the tracks with firm-sector marks and thereafter with sector data.
(3) Describe the function of the modification to support this process without direct host control.

Process: This excludes soft-sector tracks with firm-sector marks already written.

This process describes the method of performing a low-level format on a soft-sector floppy so it can be used with the chip replacing modification to run with hard-sector floppy controllers. it writes firm-sector marks on all the floppy tracks consistent with the positions of a normal hard-sector holes.

This low-level format process is described below:
Let "mod" refer in all cases to the chip replacement modification board discussed in this thread.

(1) When a new soft-sector floppy is inserted into the drive and selected, with the motor is spinning up, the "mod" can already identify that a soft-sector floppy is in the drive by the missing pattern of index+hard sector holes.

(2) When the drive is up to speed based upon index-to-index period, the mod first operates in the normal mode of reading firm-sector marks in the Read_Data signal and creating sector pulses on each such event. For a formatted soft-sector floppy, it would operate normally as a hard-sector floppy. Note the firm-sector marks written to the track during format, avoid eventual sector-migration caused by timed-sector-pulses.

(3) When the mod discovers the lack of firm-sector marks, it flips to low-level-format mode by providing timed-synthetic-sector-pulses based upon the previous two factors: 1) The Index-to-index period, and 2) The timing from the last index pulse. In this mode, it also looks for firm-sector-marks and if found, switches back to normal on the next index pulse.

Unlike previous timed-synthetic-sector-pulse descriptions, these low-level-format mode pulses are early so that a firm-sector-mark can be written onto the track such that the mark completes at a position coincident to the normal placement of a hard sector hole. This firm-sector-mark is to be read by the mod to immediately issue its synthetic-sector-pulse to emulate a normal hard-sector hole. The firm-sector-mark is never rewritten and thus its position on the track is constant and thereby solves the timed-sector migration problem.

(4) The host's low-level format program writes each track in turn with firm-sector marks substituting for hard-sector holes, making appropriate steps and head selections until all tracks are those low-level formatted.

(5) After this low-level format has been completed, the floppy is formatted with the normal program or command that formats the hard-sector floppies in the host system, with the mod present.

Notes:
(1) This won't work for formats where the end of normal data sectors run under sector holes. There will possibly be some formats that thus will not work with this solution.
(2) The position of the low-level format sector pulses will be unique to various floppy configurations.
(3) Re-Low-level formatting is discussed in part 2. It requires a method to make the mod revert to low-level format mode even though it would detect firm-sector-marks on the track.

Update:
I confirmed as an example MOD board that a Texas Instruments MSP430F20xx micro in a 16pin surface mount quad flat pack at 200mils squared fits easily within the 200mil body profile width of the 74LS14. The micro is best positioned rotated 45 degrees and takes up the body space of a 6pin DIP with room to run traces.

A TSSOP-14 version of the 74LS14 is 200mils in length and around 250mils in width and is best positioned rotated 90 degrees to stay within the 74LS14 DIP's body profile of 200mils. Both of these components have clearance to support a 14pin DIP packaging to replace the original 74LS14 in the hard-sector controller.

Update: The Texas Instruments 74LS14 is offered in a SSOP-14 that is a littler too large for comfort. I try it out to evaluate the clearances, while looking for other vendors and potential "little gates" substitutions.

Note that putting the MSP430 series micro in the MOD, doesn't yet mean that its a good choice. That micro selection is still required. I'll try to attach an image later showing the fit over a 74LS14 DIP.

PCB Layout:
I'll do a quick little PCB layout of the board with the READ_DATA signal also tied to the above mentioned micro. I plan to make a synthetic-soft-sector version of firmware first to assess how well that will work on a North Star MDS hard sector controller. The same board should thus also be able to run firmware developed for firm-sector-marks if that is deemed worth pursuing.

Note that this PCB Layout will be placed on the edge of a prototype layout and thus piggy-back the prototype's delivery, so these snap-off MOD boards won't be available quickly. I can put several pinout versions of the MOD on the edge of the board so if you want to assure your type of hard-sector controller is represented, submit the name of the system and controller along with the pin number of the 74xx14 into which the floppy disk drives cable's "Hole" or "Index" or "Sector" signals enter the 74LS14.

For best advantage, also supply the pin number of the 74LS14 to which the FDD's READ_SIGNAL is connected. It helps too if you include the format information like Floppy size, single or double sided, how many hard sector holes, and the size of the data in each sector if you know it.
 
Last edited:
Here's some additional food for thought: The last known source for "new" hard sector floppies is Athana. Come to find out, the last time Athana manufactured 10 or 16 hard sector floppies was around 1993. So what we've been buying all these years was actually manufactured in 1993 (though John at Athana points out the disks are still guaranteed). Anyway, Athana is now officially out of 10 sector floppies and will never be producing them again - no matter how much money is thrown their way. However, they still have a couple thousand 16 hard sector disks in stock, so for the vintage computing market (pretty much the only market left), this is essentially an endless supply.

So... maybe a simpler solution is for the virtual sector device to require 16 hard-sector floppies and convert the 16 real pulses into 10 virtual pulses. Shouldn't be hard to do with a software "PLL" - e.g., 500us is a common divisor for 16 and 10 sector intervals.

Mike
 
I think the jitter may be more of a precision artifact in the timed synthetic hard sector pulse implementation. I'll make a version of this in the MOD and test it.

The true solution is to manufacture a punch. Not a mass production punch, just to do the job cleanly one floppy at a time. That provides an infinite number of hard-sector floppies as long as soft sector floppies can be purchased. I might just have that machined and just offer converted packs of floppies.

The 16 hard-sector floppy MOD the create 10 sector pulse timing, would improve placement on the track and could implemented easily. I'll include that in the MOD as an option.
 
Last edited:
I used IC to measure pulse timing using a 500ns LSB. Virtual pulses were generated by OC by adding to the previous output compare value so software generates no timing error.

I'll generate data this afternoon tracking 32 separate values for the 32 sectors on the track to see if the timing "error" is consistent given a particular sector number.
 
This comes up every few years. Back a few years ago, I worked up a 10-sector synthesizer for 5.25" drives (don't remember the system). The method was pretty simple; after a seek, time the rotational speed of the disk, then generate sector pulses from that. The idea was that the speed of the disk will vary depending on the amount of "drag" the head places on the disk. Because that's proportional to the linear speed (or speed squared; I never did determine which) of the media under the head, outside cylinders will put more drag than inside cylinders on the motor.

The result was disaster. Those old belt-driven drives have horrible ISV ( instantaneous speed variation) characteristics, both from a mechanical (belt) and electrical (brushed motor, really poor tach control) standpoint.

The interesting thing is that it works much better with the direct-drive units and, of course, with 3.5" drives. But if you're really retro, that's not an option. I considered using an optical encoder on the spindle to give a better idea of hole position; you'd just count a certain number of pulses from index and Bob's your uncle, but never pursued it.

So, a good idea gone bad--one of many.
 
Here's some data from my tests on an 8" Shugart with 32 hard sectors. This drive has an AC motor with belt drive and a giant flywheel, so I'm sure it's more stable than a 5.25" belt driven drive.

As predicted, jitter between the same sector number on consecutive rotations is less than jitter between consecutive sectors on a single rotation. Standard deviation and max deviation is almost exactly 1/2 for the former/latter. This is because the flywheel is not perfectly round and this source of error occurs at the same places in each rotation.

I believe that even with the bad ISV of the DC motor and belt drive in older 5.25" drives, properly timed 10-sector virtual pulses can be generated from the more readily available 16 sector disks.
 
I just purchased another Northstar MDS-AD3 today so I could try out any solution you come up with. I'm open to testing as well if you need some help. My setup is a SOL-20 with dual NEC (non belt driven) drives. I also have some other drives I can try too, some belt drive like the SA400, and others direct drive.

:)

Phil
 
deramp5113 said:
...properly timed 10-sector...pulses can be generated from...16 sector disks.
Click to expand...

Absolutely. That's the easiest from a coding perspective:

A mapping of ten events, each being a16-sector number preceding each 10-sector pulse. Each map to a counter delay value to activate the next 10-sector pulse. Thus each synthesized sector is within 2/3s of a sector width of its reference point and thus removes theoretical motor induced jitter. That's easy to include as an option setting on the MOD board.

However, I don't think many people will understand the advantage of buying rare 16-hard-sectored floppies instead of extinct 10-hard-sectored floppies. Soft-sector solutions would be more vintage-consumer acceptable.

Nama said:
...purchased another North Star MDS-AD3......I could try out any solution you come up with...
Click to expand...

I think I already posted the pin-out of the MDC-AD3 controller's 74LS14 in regard to HOLE and READ_DATA signals. That pin-out can be supported as a 2nd MOD snap-off board.

I'll have extra snap-off MOD boards. While I'll program the MOD board, it's advantageous for others to test it with their drives and systems too. I'll have to add a means of loading firmware changes from emailed files.
 
Last edited:
I don't know what your development timeframe is, but I'll be in a position to obtain detailed sector timing from some sa400 drives in about three weeks using the same setup I've been working on with 8" drives.
 
I want to get some real-time data from the FDD's index+sector hole signal from various drives. That would dispel theory with empirical fact.

I think a dummy-floppy-drive attachment makes more sense (a cable-through for easy connection).

It could differentiate the drive select lines signals and accumulate timing data by individual drives. It would be able to collect much more than index-sector pulses.

I could implement that with another design and just populate the needed chips. It would just be easier code, same board.

I think it would be better to do a minimized version on the side with just the components necessary for a silicon-floppy drive with a USB portal for data-store transfer. Just do the firmware for signal timing-collection from the floppy cable for now.

If that could re-program the MOD boards during development... all the better.
 
Last edited:
I'm building a floppy controller for the Altair that is a drop in replacement for the original Altair FDC, but in addition to connecting to Altair 8" drives, it can connect directly to the more readily available and reliable Shugart drives (frankly most any 8" drive), and make those drives look identical to the Altair drive. Even the media is directly interchangeable with original Altair/Pertec drives. See http://youtu.be/GQfjZIp36co for a demo.

The floppy controller is run by a PIC24 series so I can easily use input capture to measure sector timing data directly from index holes. I'm waiting on a board turn that will include small adapter boards that convert the 50 pin IDC Shugart standard to Altair DB-37, Altair IDC-26, and to the common 5.25" IDC-34 cable. Once the IDC-34 adapter board is here, I can connect to most any 5.25" drive and measure whatever you need to see. I have several older-style 5.25" drives here (SA-400, Micropolis 1015 Mod-II, Tandon 100-4M) that are all DC motors with belt drives. I can measure sector jitter using 16 sector disks for you. Like you, I want to see the "real" answer.
 
You must log in or register to reply here.
Back
Top