View Full Version : Northstar DOS

December 1st, 2014, 06:22 PM
Hey everyone! I'm new to this forum, but you may see more of me going forward. I have always been a computer geek, and Mr. Fixit, but with my new project I'm in over my head (for now). I grew up using an 8088 as my first computer, and learned a lot...liked it so much I taught myself BASIC and spent a whole month writing a GUI for my 8088. Later I took a few programing classes in college (ASM & C mostly), but I'm far from proficient these days.

Okay, so my project I'm working on now predates my earlier machines. It's an IMSIA 8080 that I picked up at a government auction 20 years ago. I'm just now getting around to working on it. It seems to be functional and has two Shugart single density 5.25" drives that spin up nicely. I'll post more details in the future, but for now I'd really like to find a Northstar DOS v2 boot disk. The machine has a Northstar MDC-A4 board, and I have an original paper manual for Northstar DOS f2f that should work nicely with it...but no floppy.

Any advice would be most welcome, and I look forward to sharing more info on this machine as I figure it out.

December 2nd, 2014, 06:50 AM
...like to find a Northstar DOS v2 boot disk...have a Northstar MDC-A4 board...original paper manual for Northstar DOS f2f...but no floppy...

I have a NorthStar MDS, the same product. I bought the light blue box and board kit for the $699 price of 1978 or '79. Still have everything including a lot of NS diskettes.

Information on Northstar:

NorthStar System Disks:
You might find a system floppy image on "Dave's Old Computers" website; I don't have the URL, but it appears in a lot of searches. I think he has a section for installation floppy images and a subsection of NorthStar. Its denoted as "NSI" type format and I think he has a driver for that.

December 2nd, 2014, 09:45 AM
JDallas: Thanks for the great link! Even a complete decompilation of NSDOS v2 Rev 3, which is the exact manual I have that came with the machine, including penciled in I/O routine corrections (I wish the disk came with it too...). I'm sure this will be handy if I can figure out a way to compile it and write it to a single density hard sector disk.

It's odd, the card is labeled MDC-A4, yet the manual for the board is labeled MDS-A. Are these designations synonymous, or do you think I might have the wrong manual for the board? I'll see if I can attach a photo of the board to this post.

December 2nd, 2014, 11:43 AM
At one time these guys 'http://www.athana.com/html/diskette.html' sold hard sectored floppy disks. I don't see any on their website anymore - but it might be worth an e-mail if you know what you want. They may have some boxes going spare...


December 2nd, 2014, 12:26 PM
...complete decompilation of NSDOS v2 Rev 3...including penciled in I/O routine corrections...way to compile it...write it to a single density...
If you want to combine efforts to re-enter printed code, I'm game.

Idea. Maybe we can write a new driver to allow it to use soft-sectored floppies by timing sectors from the index pulse?.

I messed with the driver code some back in the day... I think it relies on the micro driver to recognize the index pulse and then count the sector pulses to determine when to start a read or write. If that's true, a new driver could calculate and count to where the hard sectors should be.

...It's odd, the card is labeled MDC-A4, yet the manual for the board is labeled MDS-A...
I think I've run into this before.. I think MDS is the System; MDC is the controller card.

December 3rd, 2014, 06:34 AM
JDallas: Hey thanks much for your offer of help. I will be grateful for any assistance. I won't be ready for any hard core work for few weeks as I have some prior commitments to clear up first, but I'm certainly going to learn all I can in the meantime.

Your idea of modifying the driver for the controller is interesting. I'm picturing this thing being hard wired rather than software driven, but I really have no idea. If I were to need hard sector disks it sounds like they're hard to find. I searched eBay and found a few sales over the past few months, but nothing current. Nothing on Amazon. Tried a recommendation from a forum and Google insists the site is infected with malware, so I assume they went out of business and a malcontent bought the domain.

I did come across some talk about making hard sector disks by punching more holes in a soft sector disk. Has anyone had luck with this technique? Also, if I do find hard sector disks, can I write to them using a soft sector drive/controller, or do I need to find someone with a working and bootable hard sector system to create my boot disk?

I have to say it is fun to try remembering the things I knew as a teen. Most of it has been lost :)

December 3rd, 2014, 08:58 AM
The controller is indeed hardwired for 10-sector floppies. Some of the Heathkit guys have looked into creating hard sector simulator hardware (derives 10 extra pulses from the index pulse, or I believe one of the advanced designs actually read sector headers from the disks).

If you can find enough disks to make it practical, these single-density North Star controllers are really solid. I've got a few running with various S-100 systems. Problems I've encountered have never been the controller's fault!

The first thing you'll want to do is determine whether your IMSAI is fully functional, including at least 16 KB of RAM. Then we'll need to know what your console I/O setup looks like -- if it's not compatible with the standard North Star console (Intel 8251 at specific ports, like the Horizon), you'll need to patch North Star DOS for your specific hardware. Then, you can either generate physical disks using Dave Dunfield's NST, or one of us (PM sent) can generate disks for you, to skip the initial "bare metal bootstrap" process.

December 3rd, 2014, 09:42 AM
...looked into creating hard sector simulator...
Its a simple sequencer. Catch a Index pulse, time the assertion of simulated sector pulses, constantly calibrate by the period between index pulses.

Maybe the others failed because they had no auto-calibration scheme when doing it in TTL hardware.

If you used a simple micro-controller with 10 pins or less, you could put more intelligence into it. For example, a micro could auto-calibrate with no additional circuitry assuring that sector pulses are proportional to the current index period. It might also encode in internal reall-time clock (RTC) value on the index pulse line when the drive motor was turned off... i.e. a phantom signal for RTC anytime the system micro wanted it.

The MSP430 is overkill but could do the RTC feature by adding a tiny surface-mount RTC crystal. A tiny PIC could also do the job without the RTC feature. Either way the add-on surface mount circuitry would likely fit within the TTL DIP profile so that a 74xx chip swap would be the only installation (ideally) for the simple version of synthesizing 10 auto-calibrated sector pulses per revolution.

You could then always unplug the add-in DIP circuit and put the original 74xx DIP back in the socket. No software changes required.

Taking it further (probably no real justification as the best pay-off is using soft-sectored floppies). you might add a higher storage format geometry. It would be nice to get more storage on each MDS floppy. Maybe a larger sectors size with a smaller sector count? Maybe adding 80 track drive support would be a transparent enhancement requiring only firmware driver changes. I did a 4x floppy storage increase via Rom hack to add 80 track double sided support in my Xerox 820s long ago.

I've got my MDS system at home now and will look through the schematics and documentation to see what is really feasible.

Using a tiny micro allows the possibility to bit-banged one of the drive control lines with a command semaphore to switch to perhaps 11 sectors a track instead of 10 or even 5 or 6 sector pulses for larger sector sizes. Its quite possible there is room for more data by some altered track geometry. The only hard sector floppies I recall being available were 10 and maybe 16 back in the day, so its quite possible 10 sectors was not optimal.

I'll have a better idea what track geometries are possible when I map-out a used NS floppy. Until then I'll do it the the long way via documentation and schematics.

However, I do remember working through the operations manuals and still believe that the micro just monitors MDC flags via the MDS code, and then starts reading or writing if a very crude manner. In this case the circuit simulator could be done, but only saves patching the code to do it without. It has the advantage of ease. To do switchable format geometries, obviously you'd have to modify the MDS drivers.

That auto-recalibration trick could be used in software too. Most systems won't have a CTC timer but I'll explore the MDC's schematics this weekend and see if a viable hack allows software only conversions. As I've designed real-time controllers most of my career, should be fun.

Update: NorthStar MDS Documentation:
(1) NorthStar BASIC, Ver 6, Ver 6-FPB, Copyright 1977, Rev 5, booklet, 26 pages
(2) NorthStar Disk Operating System, Ver 2 Rel 3, Copyright 1977, Rev 5, booklet, 21 pages
(3) NorthStar Micro-Disk System MDS-A, Copyright 1977, Rev 5, booklet, 31 pages
(4) NorthStar Monitor, Ver 1, Copyright 1977, Rev 1, stapled set, 16 pages
(5) Release 4 System Software Changes, June 1978, stapled set, 10 pages
(6) Release 4 Software Errata Sheet, June 30 1978, 1 page
(7) Missing: Parts List has an "OEM Manual" that I checked as included back in 1978.

Above, (3), has the good stuff:
Parts List, Theory of Operation, Block Diagram, Commands, Status Bytes, Floppy Format, Software, Interrupts, Assembly and Check-out Instructions, System Integration, Schematics.

December 5th, 2014, 08:16 AM
JDallas: Sounds like some great ideas. I'm still leaning towards using 10 hard sector floppies, for authenticity sake, but it's looking like obtaining them may be difficult. So in the end your idea may be the best.

Dave2: I'm hoping to hear back soon from Athana. They've already told me they're out of them, but I'm hoping to find out if they plan on getting a new supply someday soon.

glitch: Thanks for the PM and your offer to help make a disk! I'll keep you posted on my search.

So from looking at the NST tools, it sounds like you can use them to load a DOS image into memory via a serial cable from another computer? Sounds complicated, but handy if necessary. Looks like a bunch of other useful tools in there too.

December 5th, 2014, 11:15 AM
NorthStar MDS Conversion For Soft Sectored Floppies:
The best candidate for a replacing a socketed chip with a tiny circuit board is component "7C", a 74LS174 hex flip-flop with clear. That component takes the combined index/sector pulses of a hard sectored floppy, and outputs a MDC clock synchronized version. Five other signals are likewise synchronized.

The "PCB" herein refers to the tiny printed circuit board that swaps into the socket "7C" location. The PCB circuitry is two surface mount components fitting within the profile of the original 16-pin chip. The PCB contains a substitution chip for the one replaced, and also a tiny internally programmed micro-controller to do the fancy sector stuff.

The substitution chip does the same function as the original for 5 of the 6 signals passing through. One input and output pair is instead routed through the micro-controller. That micro reads the index/sector pulse from the floppy drive, and either passes them through unchanged for hard sector floppies or inserts synthesizes sector pulses after the index pulse for soft sectored floppies.

This allows the NorthStar board to operate without knowing whether a soft sector floppy is actually in use. The micro makes any disk inserted look like a hard sectored floppy with 10 sector holes. Note that any disk inserted can only be used in the standard NorthStar format, or the floppy capacity enhancements mentioned next, if implemented.

Simple concept, tiny circuit layout, and easy swap-replacement. The challenge is of course in the micro-controller selection and firmware. But it not a hard, real-time controller application.

Other Possible NorthStar MDS Floppy Capacity Enhancements:
Note that as you increase the capacity of the floppy significantly, you'll need to address the addition of more directory space in the floppy. Setting that aside for now, here's a quick review of capacity enhancements that deliver the biggest addition with the minimum modifications.

The first easy hack is in the NorthStar OS to allow it to support 80 track floppy drives instead of just the original 35 tracks. The following shows the increased capacity:
89,600 bytes per floppy at 1 head, 35 tracks, 10 sectors, 256 bytes/sector in the original.
204,800 bytes per floppy at 1 head, 80 tracks, 10 sectors, 256 bytes/sector with 80 track support.

The next possible hack would be in hardware to support double-sided 80 track drives. As the Northstar MDS doesn't use the two-sided floppy signals, a means to control a Head Select signal would be needed as well as the connections to the floppy cable. I'll examine and post on this subject in more detail later
409,600 bytes per floppy at 2 heads, 80 tracks, 10 sectors, 256 bytes/sector at 80 track, double sided.

There is still excess capacity in the floppy format but its unlikely to gain much more than another 100KB storage at the cost of more hardware modification. It gets to the point of diminishing return. That being the case, its reasonable to only implement the soft-sector hack and modify to NS OS to allow 80 tracks for 204KB capacity. The adventurous can add double-sided, to double that again to 409KB.

I'll write more about control options to set the Head Selection through the normal NorthStar controls.

December 5th, 2014, 07:20 PM
JDallas: That sounds plausible, but I have to admit that it is well beyond my abilities at this point. I'm just starting to get into programming micro-controllers with my son. If you were to get it working though, I'd bet there would be quite a few Northstar MDS owners that would want to buy a chip upgrade.

December 13th, 2014, 08:48 AM
...the card is labeled MDC-A4, yet the manual for the board is labeled MDS-A...

I pulled out my MDS-A system and confirmed that the board is labeled "MDC-A4" too. The silkscreen adds, "Micro-Disk Controller" to that identification.

December 13th, 2014, 09:24 AM

December 13th, 2014, 07:12 PM
Good link!

I'm in luck. A generous fellow offered to sell me a portion of his personal supply of hard sector disks. I think for now I'm going to proceed using those, but the mods you guys are mentioning may come in handy down the road. These disks are getting really rare. Someone could make some $ if they could manufacture a few thousand new ones.

December 13th, 2014, 07:26 PM
I think we have the same board JDallas. Only mine doesn't appear to have any changes implemented. I see no revision numbers, and its dated 1976. I wonder what those changes do?

December 15th, 2014, 07:38 AM
As an addendum:

The 10 hard sector disks were also used in the Heathkit H8/H17 combo. Late in the game they offered a soft sector option for the H89 that may have been called a Z-89-37.

December 16th, 2014, 05:03 PM
I'd certainly be very keen to try any mod you guys come up with.
Great stuff!


December 18th, 2014, 07:19 AM
I'm going to make a few snap-off boards for the soft/hard-sector mod I've described.

Tonight I'm going to do a quick little schematic and printed circuit board layout in Pads for the MSP430F200x and 74x14 TSSOPs to see if they fit within the normal chip profile of a through-hole DIP package of the existing chip on the NorthStar MDC-A4 board. If the tiny version of the MSP430 is too large, I'll look at other sparse pinout micros.

Previously I suggested replacing the 74LS174 with the snap-off board. I've decided to replace the 74LS14 instead. I had hoped to grab more signals on the '174 to add other features, but it doesn't seem worth the bother. Moving it to the 74LS14 has the advantage of making the micro's firmware a more universal solution for hard-sector controllers as 74LS14s are commonly used to read the signals from the floppy disk drive.

I looked at the North Star MDS series board: -A1, -A2, -A4, -AD, -AD3. The last two were the double density versions. The -A4 has the index+sector signal enter the '14 chip on pin 1 and out on 2. That's probably true of all the -Ax boards though I only have the -A4 schematics. In contrast the -ADx boards enter on pin 3 and out of 4. Thus it would be nice to have the board support either board type via the micro.

Single Density MDS boards (74LS14):
Ax: pin 1-->2 HOLE (index+sector)
Ax: pin 3-->4 TRACK0

Double Density MDS boards (74LS14):
ADx: pin 1-->2 (spare; not used)
ADx: pin 3-->4 HOLE (index+sector)

I'll look over some of the other hard-sector systems. They would likely use a 74LS14 in the same way, so the micro's firmware should be useful for them too, when placed on a snap-off board matching its 74LS14 pinout.

As there are six Schmitt triggered inverters on the 74LS14 chip, each gate with one input and one output, a universal solution would be to either do 6 versions of the tiny board where the micro intercepts the right inverter gate with its program, or make it jumperable via zero-ohm SMT resistors (aka a jumper). For now I'm probably just put the two NorthStar versions on the edge of each of my prototype boards.

The snap-off board will be built with Surface Mount Technology chips (SMT) using package size know as TSSOP. Two chips will be on the board, a 74x14 to to do the function of the original 74LS14 for 5 pairs of pins. That 74x14 will divert its index+sector output pin on pin of the micro - the micro will create the TTL level signal, INDEX+SECTOR. I'll use a micro that doesn't require a SMT crystal, maybe a Texas Instruments MSP430F200x. That has 10 I/O pins so I'd prefer something with less and still smaller; I'll look over several that should do this simple task.

Micro Required 2 I/O pins:
. . 1 input to read the drive's index+sector or index-only signal onto the MDC-A4. (Pin 1 of the 74LSxx?)
. . 1 output to write the sector pulses as if they came from a hard-sectored floppy. (Pin 3 of the 74LSxx?)

Micro Optional 2 I/O pins: Add two SMT LEDs to signal mode
. . 1 output to a illuminate a red LED when running in hard-sector mode
. . 1 output to a illuminate a green LED when running in soft-sector mode

As I've discovered other common hard-sector floppy hole-counts, I'll devise the algorithm to run for any given sector-count, and make 10,16 and 26 available by jumper if pins and board space allow.

Besides using the rotational speed of the last floppy revolution to recalibrate the synthetic hard-sectors, I think it should also use the last soft-sector index hole duration to recalibrate the synthetic hard-sector pulse durations. I'd rather do this on a micro that could implement it with counters and count-capture registers, but it likely loose enough that a multi-task code loop could suffice. Its tasks being roughly:

(A) On power-up:
. . (1) Initialize
. . (2) Set up Standby Mode: blinks both Sector Mode LEDs every 2 seconds (indicates board is alive)
(B) Standby Mode:
. . (1) Sleep loop supporting Standby Mode LED timing
(C) Activitity Wakup:
. . (0) Wake by a index+sector pulse.
. . (1) Setup on index-pulse inactivity time-out to return to Initilize Standby Mode.
. . (2) Set both Sector Mode LEDs ON to indicate detected index+sector activity.
. . (3) If not N additional pulses within spin-up window, return to Initialize Standby Mode.
. . (4) Sync up on Index if hard-sector pattern, else soft-sector Index only.
. . (5) Loop Timing next revolution, if in motor speed tolerance proceed
. . (6) Turn off both Sector Mode LEDs
(D) For detected soft-sector floppy:
. . (0) Turn on Soft-Sector LED (GREEN)
. . (1) Setup task to always measure index period to always recalibrate next rotation synthetic sector timing.
. . (2) Setup task to always measure index pulse duration to use as next rotation synthetic sector pulse duration.
. . (3) Loop creating sector pulses until index period out of calibration then goto Init Standby Mode.
(E) For detected hard-sector floppy:
. . (0) Turn on Hard-Sector LED (RED)
. . (1-A) either gate the index+sector pulse directly to the output pin, bypassing the micro (sleep mode), or
. . (1-B) trigger a level following output pin from the input index+sector pulse (ghost mode)
. . (2) Loop maintaining (1-x) state until index period out of calibration then goto Init Standby Mode.

ISSUE TO RESOLVE: Fast Selection of another drive under worst case situation.
(Status: Appears not to be an issue)
Definition: The situation here is when a floppy drive controller switches to another drive in mid-rotation. The mod-board doesn't know when drive select changes, but it can detect unexpected index+sector pulses appearing. Of course this only applies to floppy disk controllers designed for hard-sector floppies. The mod-board needs to assure that the controller won't start writing sectors on the newly selected drive, using the rotation remainder synthetic sector pulses.

First reason this condition never occurs is that hard-sector controllers must first fill and synchronizing sector count so that it never confuses the index pulse with a sector. It can only do that after one full rotation under the best conditions.

If a switch is made from a soft-sector drive to a hard sector drive, the mod-board will immediately detect unexpected index+sector pulses and then exit to establish the type of disk. In other words it gets out of the way quickly and works fine.

If a switch is made from soft-sector to soft-sector drives, the mod-board would continue supplying remaining synthetic sector pulses until it expects the next index pulse, if its not there, it will exit to establish the type of disk. That would deny one full revolution for the hard-sector controller to sync up on, so that's fine. The other case is the new soft sector index pulse arriving before the expect previous drive's index pulse, to which the mod-board exits as above to establish the type of disk.

This negates any problems, under the assumption of the hard-sector controller using a full revolution to sync its sector and notched index pattern. I think this is valid.

Note that it is assumed for now that synthetic sector pulses are never applied except with the index period is within rotational spec. This may violate some hard-sector controller's time-out conditions so should be considered.

December 18th, 2014, 06:45 PM
I like your idea of building the sector pulse injector right into the 74LS17 socket!

I've been down a similar road with 8" belt drive Shugarts with 32 hard sectors. I tried numerous techniques for syncing with the drive's rotational rate, but sector jitter was still substantial. I tried running averages from 1 to 64 full rotations and also tried additional intra-track adjustment using running averages from 1 to 32 sector times. However, sector jitter was still outside an acceptable range.

I got to thinking that the sector jitter may actually be more predictable than random based on fixed irregularities of the hub flywheel. My next step was going to be maintaining an average per sector across multiple rotations (i.e., 32 separate averages), but I was pulled off by more "important" projects and have re-visited this one.

Keep us posted!

December 18th, 2014, 08:36 PM
I considered averaging, its a quick calculation when you use powers of 2 samples, but the results are probably the cause of the jitter when you consider the problem this way:

(1) If a hard-sector floppy were used instead of a soft-sector floppy, the index+sector pulses are at fixed radial positions around the track and thus sectors are some duration following that event. So the pattern of sector and index pulses is fixed with only one variable, the instantaneous rotational speed.

(2) A solution for a soft-sector floppy has to assume that the speed of the motors are relatively stable over the course of 2, up-to-speed revolutions; (2/6ths of a second for 8 inch and 2/5s for 5.25). Given that, for a given index period, the next revolution should have one set of correct sector pulse patterns.

(3) Now if you induce averaging instead, you introduce variance around that correct sector pulse pattern, and thus increase the odds that they'll cause problems. That variance is the jitter. Supplying a more precise value will have less variance and the margins around it allow for some variance in the rotational speed from the last measurement.

- - -

So I conclude that the solution requires accurate timing of the previous index period and then mathematically recalculating the sector timing from that last measurement. Of course these are concurrent tasks, while one revolution is sector timed by the previous revolution, it is also measuring the current revolution for the next revolution's sector timing.

That can be done best with a micro with a counter with input pin triggered capture... can't have the code looping or polling as that adds jitter too. The counter and triggers keep it time-event synchronized, and the code sets up the next situation with the counter or events triggering it. The pulse transition timing requires automatically using a reload register value so that there is no variance in timing around the processor trying to reconfigure in at the event. Just put the next sector count in the reload register before its needed and the timing stays more precise.

Note that the mathematical, proportional timing of the sector pulses could be done two ways. You could focus on a particular drive type and sector count and build a quick look-up table for the sector timing, but taking the index duration and running it through a binary tree look-up for class ranges of significance determined by spread-sheeting the data before building the table.

However, to support the ability to do various sector counts per track, calculating the sector timing should be easy enough. Add to that the relatively slow speed of revolution and lots of processing time per sector event.

December 19th, 2014, 07:32 AM
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.

December 19th, 2014, 07:50 AM
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.

December 19th, 2014, 12:29 PM
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.

December 19th, 2014, 03:42 PM
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.

December 19th, 2014, 06:32 PM
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.

Yes, exactly.

December 21st, 2014, 05:19 AM
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.

December 21st, 2014, 06:53 AM
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.

December 21st, 2014, 08:16 AM
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.

December 21st, 2014, 06:45 PM
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.

December 28th, 2014, 07:33 AM
PART 1: Formatting a new soft-sector floppy with firm-sector marks.

(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.

(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.

(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.

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.

December 29th, 2014, 07:31 AM
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.


December 29th, 2014, 08:58 AM
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.

December 29th, 2014, 12:53 PM
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.

December 29th, 2014, 02:55 PM
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.

December 29th, 2014, 03:33 PM
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.

December 29th, 2014, 04:13 PM
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.



December 29th, 2014, 05:31 PM
...properly timed 10-sector...pulses can be generated from...16 sector disks.

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.

...purchased another North Star MDS-AD3......I could try out any solution you come up with...

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.

December 31st, 2014, 05:54 AM
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.

December 31st, 2014, 06:31 AM
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.

December 31st, 2014, 07:39 AM
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.

December 31st, 2014, 10:10 AM
If you have a capture mode counter on that PIC24 series micro, run the counter clock as fast as possible such that the sector hole interval doesn't overflow the counter range for rotational speeds of interest. If a sector interval would count over 2/3rds of a 16-bit counter range, you'll get the best accuracy.

If the micro can capture the counter value on a HOLE signal transition, that will give you the most accurate value; just let the counter automatically overflow-reload, so there are never any timing variances inserted as the micro tries to respond to an event or tries to reset the counter.

As long as the counter keeps ticking continuously and will automatically capture the counter value on every a sector pulse, the micro has plenty of time to capture the latest counter value and send it without affecting the timing. Keep the micro firmware out of the critical path of timing the interval values.

Re-calculating the overflow affected counts can either be done with the PIC as it grabs a value from the capture register or by the PC doing post-buffer processing. I usually stream lab test values to a PC and post-process them in C or in a spreadsheet. If its something I might want to do ofter, then I bother putting it into the firmware.

In firmware, you might want to disable the capture until the index to index timing gets up to speed. The slower speeds will overflow the counters and the interpretation of those values will look like the speed variance is all over the spectrum. On the spin down slide, its probably not worth the extra work to recognize the speed has dropped under speed. The data stream in post-processing will make that transition clear enough.

If each captured 16-bit counter value is sent with a sentinel character, the PC buffer would have a stream of 3-byte blocks. When the rotation is up to speed, that data can be processed to identify the index pulse and reframe the data to sets of revolutions. The revolution period can be summed from the hole interval counts.

A spreadsheet could take that for better analysis to look for speed variations among sets running in the same rotation intervals.

When collecting data, take several sets from the same drive floppy combination from select spin-up to motor shut down. Then add other floppies to see it they're a component of variance.

December 31st, 2014, 10:19 AM
Yep, that's exactly what I've already done with the 8" drive to gather detailed and accurate sector timing data. I had to bump up to a 500ns lsb to catch the full 5.2ms sector time on the 8" floppy. This same resolution can time the 12.5ms sector of the 16 sector disks I have.

January 18th, 2015, 03:35 PM
I'm able to work with 5.25" drives on my controller now. Using an old, belt driven SA-400, I'm able to run a 16 sector hard sector format on a soft sectored disk using a four revolution running average of revolution time to generate timed virtual sector pulses. Deviation from hard a hard sectored disk is as large as 175us on a sector, so while disks written on this drive read without issue, interchangeability between two drives is borderline.

In comparison, I tried several Teac 55-GFR 5.25" drives and the jitter vs hard sectors is less than 50us. These slightly newer 5.25" drives and a simple virtual pulse generator offer a very workable solution. I'm sure a 10 sectored version would generate similar numbers and results.

January 27th, 2015, 12:32 PM
Thats good news...sounds very promising.
I've been using the HFSE with my SOL20 and Northstar controller for the past year or so. Although it's generally fine for most things, I have noticed that it's certainly far from perfect. Sometimes I can't even get the machine to boot from a floppy, which seems strangely related to the time the drives have been running. I think that somehow the spin speeds vary once the drives have warmed up, causing a few issues. Turning the drives off and letting them sit and cool for a few mins usually solves the issue.

Anyway, my second N* controller card has arrived, so I'd be very keen to test out your hardware for 10 sector drives :-)