• Please review our updated Terms and Rules here

Floppy disk drive emulator for Sol-20

Old_hitech

Experienced Member
Joined
Dec 30, 2016
Messages
112
Location
Ventura CA
Does anyone make a floppy disk drive emulator for the Sol-20 computer? I've been looking for actual floppy disk drive and controller card for a while, but have yet to see these for sale anywhere, except for the Helios drive which in most cases is very expensive and have a finicky reputation.
 
The North Star double density controller and a couple of 5.25" drives was a very popular addition to the Sol-20. Far more so than the Helios. You can use a couple of 5.25" full height drives or a couple of 48 tpi half-height drives.

Mike
 
The double density card comes up from time to time on ebay, like this one in the completed listings:

https://www.ebay.com/itm/S-100-Nort...=true&nordt=true&rt=nc&_trksid=p2047675.l2557

It is a matter of waiting and watching to get one, unless one is for sale by a forum member.

For my SOL-20 I use this card along with two new old stock IBM drives, and Mike's VSG.

I got my disk drives from ebay.

I wrote an article about the drives and putting them in a box with a power supply, which also powers the VSG, but it comes powered by a battery too. Mike supplies the VSG assembled & tested too, which is helpful to eliminate variables with the initial setup.

Also with the Northstar card it pays to clean up the IC sockets & pins to make sure it is reliable. One day one of my Northstar cards just stopped because one of the socket claws was damaged and had a poor connection to an IC's pin. I test the socket claw tensions with a single pin from a defunct IC soldered to a wire handle, to make sure they are good, sometimes they were damaged by rough insertion of an IC, especially the TI type of socket.

http://worldphaco.com/uploads/EXTERNAL_DUAL_5.pdf

(PS: when you string the two(or more) drives together on the same ribbon cable, don't forget to take the terminator resistor out of the first one/s in the chain).
 
Last edited:
I’m working on a solid state replacement for early disk drives. This will be a very low-level floppy drive emulation that simply records the flux transition pulses on the write data line during writes and then plays them back on the read data line the rest of the time. The unit needs to know nothing more than the rotation rate of the drive and the number of hard sectors (if any) to replace most any 8”, 5.25”, or 3.5” floppy drive.

Mike
 
I’m working on a solid state replacement for early disk drives. This will be a very low-level floppy drive emulation that simply records the flux transition pulses on the write data line during writes and then plays them back on the read data line the rest of the time. The unit needs to know nothing more than the rotation rate of the drive and the number of hard sectors (if any) to replace most any 8”, 5.25”, or 3.5” floppy drive.

I've been wondering about the possibilities for this myself, although it's a significantly more involved project than I've pulled off up to this point. The germ I've been pondering is if this could be done with the same "Blue Pill" hardware as the Greaseweazle; just load a track's worth of flux data at a time into the Blue Pill's meager RAM over USB and swap it out when the disk steps.

(Using a controller with more RAM than the Blue Pill would make it easier, probably.)
 
With many of the early controllers (e.g., hard sector controllers), you have no way to stall the controller or host software without making assumptions about how the controller works and/or how the host software uses the controller. To make a drive replacement that is truly universal, and therefore independent of controller and/or host software specifics, disk data has to be immediately available as fast as it is in a real drive. Essentially, this means the entire disk needs to be in RAM.

Mike
 
With many of the early controllers (e.g., hard sector controllers), you have no way to stall the controller or host software without making assumptions about how the controller works and/or how the host software uses the controller. To make a drive replacement that is truly universal, and therefore independent of controller and/or host software specifics, disk data has to be immediately available as fast as it is in a real drive. Essentially, this means the entire disk needs to be in RAM.

I was thinking specifically of a device that could work in the Northstar 10 sector Double Density controller, and the rough line of thinking was along the lines of:

1: My memory isn't certain on this so I should probably look up a datasheet, but my vague recollection is that old floppy drives like the SA400 usually had track-to-track stepping times in the 30ms-ish ballpark? (Just looked up the datasheet, it says 40ms plus a 10ms settling time.)

2: The quoted minimum latency for "full speed" USB is 1ms. If I assume that I need to transfer 10Kb of data for a track full of data the raw time necessary for that at 12mb/s is around... 7ms?

Maybe the actual time to play with is less than the 50ms the SA400 manual implies, but... there is still about a 4x gap between the minimum USB latency + theoretical data transfer time? Obviously all bets are off if there's a USB hub in the way that makes the transfer time less predictable, but in theory at least that's what made me think it might be doable?

Also, and I don't know if this saves it even more, at 300 RPM there's 200ms between full rotations. Does the Northstar controller want to see an "Index" pulse after stepping before continuing to read or write? If it does that gives you a full 1/5th of a second to shuffle buffers.

Obviously this wouldn't work in the case of something like an Apple II drive, where the index pulse means nothing and you can do half-steps while reading and writing to do crazy stuff like spiral tracks...
 
Recording flux transitions (just like a real disk drive) takes about 25Kb/track for a 300rpm drive. No attempt is made to decode the data. Otherwise, you'd have to make assumptions about how the controller encoded the data, bit order, etc.

Floppy drives with a 3ms step rate were available as early as the days of the North Star DD controller, so 3ms needs to be the design target. Adding heat settle time of 15ms after a step, by which time you should be spitting out the correct data, is a reasonable design target. No other read delays can be assumed.

Most hard sector controllers have a sector register that is incremented by the hard sector pulses and is sync'd by the index pulse. Sync is not lost due to a stepping operation. Data would need to be retrieved starting at the next expected sector and then wrap back around.

The kicker in all of this is writes. With a USB stick or SD card, the application has to tolerate random latency periods of 200ms by spec, easily over 500ms in reality. If a read is needed at one of these times, you're stuck. Even with a background thread doing writes, the high-priority read would still have to wait on the hardware to finish its write operation and the read has then failed.

After trying all sorts of things, the only answer I can find than makes no assumptions about controller operation or host software is to keep the disk image in RAM (or other zero-latency storage). A non-real time transfer from RAM to SD card or USB stick can take place whenever a new disk file is selected to "insert" into the drive, the power-off button is pressed, etc.

Mike
 
I’m working on a solid state replacement for early disk drives. This will be a very low-level floppy drive emulation that simply records the flux transition pulses on the write data line during writes and then plays them back on the read data line the rest of the time. The unit needs to know nothing more than the rotation rate of the drive and the number of hard sectors (if any) to replace most any 8”, 5.25”, or 3.5” floppy drive.

Mike

Will it support Micropolis/VG systems? If so that would be amazing! What's the plan, would it be a S-100 card with an SD card slot onboard? Or would it be an external device that interfaces to your existing FD controller? Would it have the ability to read disk images?
 
Recording flux transitions (just like a real disk drive) takes about 25Kb/track for a 300rpm drive. No attempt is made to decode the data. Otherwise, you'd have to make assumptions about how the controller encoded the data, bit order, etc.

I guess what I was envisioning wasn't actually a flux transition device, more along the lines of a conventional "higher level" floppy emulator. So strictly speaking it'd only have to store the actual sector data. (Looking in the Northstar manual a double density sector is 32 bytes of zeros, a sync character, 512 bytes of data, and a check character. Everything but the data itself looks not too hard to synthesize on the fly.)

Floppy drives with a 3ms step rate were available as early as the days of the North Star DD controller, so 3ms needs to be the design target. Adding heat settle time of 15ms after a step, by which time you should be spitting out the correct data, is a reasonable design target. No other read delays can be assumed.

I guess I can't find anything in the disk controller hardware manual that says anything about stepping time. Maybe that's up to the CP/M driver? I did find some assembly code for the boot PROM, and just scanning it... I find a part that says "Step out once, and delay (for 2 sector times) while it steps". Two sector times would be roughly (200ms/10) * 2, aka 40ms? My North Star has SA400s in it which would need that much time, was it normal for people to hack faster times into the CP/M driver?

Most hard sector controllers have a sector register that is incremented by the hard sector pulses and is sync'd by the index pulse. Sync is not lost due to a stepping operation. Data would need to be retrieved starting at the next expected sector and then wrap back around.

So that appears to be true. The controller has a special status bit that's lit up when it passes the "Index" mark so it does care where the "start" of the disk is, but it would certainly be possible, in theory, for CP/M to request a sector on the next track within the same rotation after the stepping pulse.

The really critical thing it seems to care about it, yes, it can *never* miss a sector pulse or have it delayed. If I'm reading the manual correctly it starts an aggressive timeout after the index pulse waiting for the first sector pulse and you'll get a hardware error if it doesn't get it and subsequent pulses on schedule. Whatever else a simulator for this does it has to keep spitting out pulses constantly.

The kicker in all of this is writes. With a USB stick or SD card, the application has to tolerate random latency periods of 200ms by spec, easily over 500ms in reality. If a read is needed at one of these times, you're stuck. Even with a background thread doing writes, the high-priority read would still have to wait on the hardware to finish its write operation and the read has then failed.

In the "GreaseWeazle" application the Blue Pill acts like a USB Full Speed *peripheral* to a host, that's what I was thinking with this idea. IE, the disk image(s) in use would be resident in RAM on whatever PC (it could be a raspberry Pi or whatever) that's driving the Blue Pill. So as long as whatever OS you're running there has adequate timeslice resolution latency should be possible to keep down to a few milliseconds. Or that's the thought, anyway.

I definitely agree with you that the timing constraints imposed by the inability to "fake" sector boundaries on a hard sector disk make directly running from flash (whether USB or SD) *really hard* and would probably pretty much necessitate onboard RAM in a stand-alone device.

Maybe the reverse-greaseweazle idea isn't worth pursuing given how easy it is to find ARM-based devices with a few MB of RAM onboard for a few bucks. (Bare-metal Raspberry Pi Zero would be an obvious possibility.) I just happened to have a couple Blue Pills lying around that I bought for a different project I haven't gotten to yet.
 
Yes, you can simplify things in a number of places if you make a storage solution specifically for the North Star double-density controller and for the host applications you intend to run (e.g., CP/M, NSDOS).

Mike
 
Will it support Micropolis/VG systems? If so that would be amazing! What's the plan, would it be a S-100 card with an SD card slot onboard? Or would it be an external device that interfaces to your existing FD controller? Would it have the ability to read disk images?

The device will be a small standalone board with a 50 pin and 34 pin header to accept the corresponding ribbon cable connector for an 8" or 5.25" drive. Most likely battery powered. The device will appear as two drives to the controller. The controller will think it's connected to two 8" or 5.25" drives. Disk images will be saved on a micro-SD card. A two line text display shows the name of the disk image in each of the two drives. Buttons let you scroll through a library of up to 100 disk images by tens or by ones.

I have tested my prototype version with Micropolis, VG/Tandon (DSDD "Micropolis"), Altair 8" and 5.25", North Star (SD and DD), Polymorphic, Tarbell (SSSD soft sector WD1771), and Vector Graphic 8" (DSDD soft sector WD1793).

Mike
 
I guess what I was envisioning wasn't actually a flux transition device, more along the lines of a conventional "higher level" floppy emulator. So strictly speaking it'd only have to store the actual sector data. (Looking in the Northstar manual a double density sector is 32 bytes of zeros, a sync character, 512 bytes of data, and a check character. Everything but the data itself looks not too hard to synthesize on the fly.)

The solution you described is used by this combination floppy and MFM hard drive emulator product:
https://www.drem.info
That device emulates the NorthStar and Heathkit hard sector floppy drive formats, in addition to many common soft sector floppy formats.
The MFM hard drive emulator built into the device has been designed to emulate a long list of MFM low level formats.
 
Last edited:
acb.jpg

Seriously when do you think it'll be ready? I never did get that Micropolis drive working that you were helping me with. This'd at least get that system up & running.
 
I planned on having lots of time starting in October to get some serious development done, but unfortunately, real life has gotten in the way. I finally had a bit of time this last week and started PCB layout.

Mike
 
I planned on having lots of time starting in October to get some serious development done, but unfortunately, real life has gotten in the way. I finally had a bit of time this last week and started PCB layout.

Mike

That's awesome! glad to hear it's still in the works.
 
Back
Top