PDA

View Full Version : Why not a 5 1/2" usb floppy?



Casey
July 28th, 2017, 05:16 PM
If this is off topic, let me know. This seemed like the place to ask.

We all know usb 1.44Mb floppy drives are all over the place. In fact they're nearly disposable. You can get a new one, free shipping, for less than $10 eBay these days.

My question is this: the 360/1.2m floppy drives were in many ways very similar to the 720/1440 floppy drives. Yes, there were speed differences between 360k & 1.2M and so on, but looking at the back of those drives, they aren't that different. In fact I have a couple of 3.5" drives which run off of edge connectors quite nicely once you snap on an adapter.

So why do we have a 720/1440 usb drive, but not a 360/1.2m usb drive? The circuitry inside the drive box? No one ever anticipated a need for a 5 1/4" usb floppy drive? The 1.44 was all that was seen as needed?

While I'm on a rant, why not a usb-to-serial adapter? Even usb 1.0? I know the later aftermarket 16550 UARTs could handle a healthy amount of throughput. It would be nice to plug a usb thumb drive into an adapter on an old XT or 286 system.

Yes, we have Glitch's excellent 8-bit IDE adapter, but I'm very poor these days, so I'm dreaming. If I had the money, I'd get an IDE adapter, a DOM for storage, then Startech's front-panel compact flash to IDE bay for sneakernet. At least I assume that the glitchworks adapter can handle 2 devices at once...

krebizfan
July 28th, 2017, 05:35 PM
Market demand for non 3.5" drives was very small. 1998, 4 thousand 8" drives and 40 thousand 5.25" drives were sold compared to 113 million 3.5" drives.

One of the early USB to floppy drive chips* was designed to take normal 3.5" high density drives. It supported out of the box 640 kB, 720 kB, 1.2 MB (both common variations), 1.44 MB and the documentation claims that changes to the driver 2.88 MB and floppy tape could be supported over USB. I think with that chip and driver source making an enclosure with 5.25" or 8" drives or any other Shugart style drive would have been possible. Probably would need external power. Later USB floppy drives streamlined the design and focused only on the common PC formats.

* It was a microcontroller, RAM, and standard floppy controller attached to USB. Relatively expensive. Check for SMSC USB97CFDC if you want to know more.

NeXT
July 28th, 2017, 05:39 PM
I've questioned the same for the USB 5.25" floppy drives. In the earlier days it literally was USB glue and a floppy controller. These days I think it is a hybrid of the USB glue also implimenting the controller but that also makes it hard-coded to support only 3.5" floppy drives. I know someone else at one point did make their own 5.25" floppy drive to USB adapter but it was severely limited in what it could do, plus read-only.


why not a usb-to-serial adapter? Even usb 1.0? I know the later aftermarket 16550 UARTs could handle a healthy amount of throughput. It would be nice to plug a usb thumb drive into an adapter on an old XT or 286 system.
Because it isn't that easy, unfortunately. Now there is rather simple ISA cards for adding the absic features of a USB port to a PC or clone. Lo-tec at the least has the designs available.

Stone
July 28th, 2017, 05:39 PM
While I'm on a rant, why not a usb-to-serial adapter? Even usb 1.0? I know the later aftermarket 16550 UARTs could handle a healthy amount of throughput. It would be nice to plug a usb thumb drive into an adapter on an old XT or 286 system.I'm pretty sure that USB is only available with PCI.

Do you know of any USB configurations with ISA?

krebizfan
July 28th, 2017, 05:46 PM
I'm pretty sure that USB is only available with PCI.

Do you know of any USB configurations with ISA?

There are ISA cards with USB ports that have been discussed here before. http://www.vcfed.org/forum/showthread.php?39340-USB-on-an-8-bit-ISA-Bus-it-is-possible!!! is one such thread.

General purpose card http://www.simtec.co.uk/products/EB1161ISA/intro.html

gslick
July 28th, 2017, 05:50 PM
There were the USB97C100 (device only) and USB97C102 (device and 5 port hub) parts which didn't have an integrated FDC. The datasheets show a floppy drive application using an external 37C78 FDC.

http://www.keil.com/dd/docs/datashts/smsc/usb97c100.pdf
http://www.keil.com/dd/docs/datashts/smsc/usb97c102.pdf

Back around 2000 I saw a dev board that was something like a USB-ISA bus bridge. It might have been based on the USB97C100. I don't know of any commercial products that actually used the USB97C100 / USB97C102. Seems like an interesting device.

Stone
July 28th, 2017, 06:24 PM
There are ISA cards with USB ports that have been discussed here before. http://www.vcfed.org/forum/showthread.php?39340-USB-on-an-8-bit-ISA-Bus-it-is-possible!!! is one such thread.

General purpose card http://www.simtec.co.uk/products/EB1161ISA/intro.htmlSorry, I meant something that works with DOS and doesn't require any loss of hair or teeth! :-)

KC9UDX
July 28th, 2017, 06:26 PM
I have USB on a Zorro 2 bus....

I once ordered a 5 USB floppy drive along with a laptop from Dell. The laptop showed up but no drive. I called and complained and they said they were sorry but those were no longer available. That was in 2001 or 2002.

Chuck(G)
July 28th, 2017, 06:29 PM
Don't know about 5.5 inch floppies; I've never seen one. But 5.25" floppies on USB are possible, just not in much demand.

Casey
July 28th, 2017, 07:38 PM
Sorry, I meant something that works with DOS and doesn't require any loss of hair or teeth! :-)

Very much so! :)

SomeGuy
July 28th, 2017, 08:23 PM
Another big problem with USB based 5.25" floppy drives is that they would completely fail to run much of the copy protected 5.25" titles. That is, if you could even get the drive accessible in DOS.

There were fairly few 720k and 1.44mb copy protected titles, so this was less of an issue with 3.5" drives.

It would also not be compatible with many disk utilities that bypassed BIOS and tried to use the FDC directly. Same issue for 3.5" disks though.

Of course there was the whole compatiblity mess between 1.2mb drives and writing 360k disks. Vendor's probably would not have wanted to be bothered with that headache.

Not to mention many "oddball" formats, and the older 160k/180k/320k IBM formats. I'd dare say a USB 5.25" drive would likely choke on some of these.

Add to that that real desktop computers kept a genuine FDC on them for quite a while. It has really only been the last so many years that finding such older computers in the wild has become somewhat difficult.

krebizfan
July 28th, 2017, 09:23 PM
If one really wants a do everything reader for screwy PC formats, the optimal solution would be to build a small PC clone to handle the drive and network it to the modern PC that wants to use the data.

Existing USB drive designs could be modified to handle roughly 90% of disks with relatively little work if the proper chips and source code to the driver are available.

All fairly moot since even the USB floppy drive is on its way out.

Chuck(G)
July 28th, 2017, 10:38 PM
There were fairly few 720k and 1.44mb copy protected titles, so this was less of an issue with 3.5" drives.

Both IBM and Microsoft distributed 3.5" HD media before the move to CD with oddball formats that are anathema to USB 3.5" drives around 1994-95 For example, IBM XDF format used 4 sectors per tracck--one 8K, one 2K, one 1K and one 512 byte. This gave a capacity of 11,776 bytes per track, the equivalent of 23 512-byte sectors, where the standard format uses only 18. Microsoft DMF used a more straightforward format, shrinking the inter-sector gap and putting 21 sectors of 512 bytes. Neither is loved by 3.5" USB drives. This created so much havoc that both companies offered to swap the extended density formats for standard 1.44MB on request.

Neither format was intended for anything other than software distribution (i.e. read-only).

Al Hartman
July 29th, 2017, 02:23 AM
While not USB, a Micro-Solutions 3.5" external Parallel port floppy drive will work fine with a 5.25" drive. You simply pop the case, remove the circuit board and attach it to your 5.25" drive.

You'll need an external power supply for the floppy, but those are out there.

You just run the utility that comes with the drive and select what kind of drive is attached.

You can also find older Micro-Solutions 5.25" Backpack drives on eBay now and again.

But I do wish someone would help make the software for this adapter write as well as read: http://shop.deviceside.com/prod/FC5025

Xacalite
July 29th, 2017, 08:10 AM
KryoFlux allows to connect 5.25" (and other) FDDs to modern computers via USB.

But KryoFlux isn't an FDC, so it doesn't perform any processing to the data read from/written to diskettes, it only passes the raw data to/from the host.
The upside is: support for all possible floppy formats.
The downside is: you can't simply copy individual files from/to diskette, you need to read/write whole diskette images.

Chuck(G)
July 29th, 2017, 08:35 AM
It shouldn't be difficult to implement a read/write USB FDC using a modern MCU, which would allow for the host side to use generic USB drivers.

However, generic USB would have to follow standard conventions, meaning that you'd have 1.2MB and 360K standard 512-byte sector MFM support with no deviation. That might limit the appeal.

Xacalite
July 30th, 2017, 07:08 AM
Come to think of it, the perfect solution would be "USB FDC + KryoFlux in one".
The FDC part supporting standard formats as regular USB storage, plus the option to sample flux reversals via some special software.

SomeGuy
July 30th, 2017, 09:19 AM
Personally, I would just settle for an all-in-one applicaiton that enabled simple drag and drop.

Right now if I want to write some random files using a Kryoflux, I must first master a floppy image with my files using Winimage, then feed it to HxC to convert it to a Kryofluyx stream, then write it with the Kryoflux command line tool.

With the proper software this could all be done in one step just using the current Kryoflux or SuperCard Pro devices.

I think developers are hesitant to implement something that looks like a USB floppy drive to the OS, both because of the limiting factors, and the worry that Microsoft might pull the plug.

But there is little technical reason why there could not be a drag-and-drop style disk image manager that reads and writes through the current KF and SCP libraries. Sort of something with a front-end like WinImage, the converting power of HxC, and automatic interactive reading/writing through KF or SCP. It would be limited to reading and writing an entire track at a time, file system management would be in the software, flux decoding/encoding would still all be done in software, and the user might have to explicitly specify things like disks type. But that would have the advantage that many other non-DOS disk formats could potentially be supported. Practically speaking, that would be a metric-f-ton of work, which is why no one has done it.

I think the HxC software was trying to grow in to something like that. I recall it can do some file management, and has some integration with the SCP, but those parts are primitive and clunky.

Chuck(G)
July 30th, 2017, 09:25 AM
Well, there are those of us (myself included) who don't use Windows unless we absolutely have to.

Stone
July 30th, 2017, 09:36 AM
Well, there are those of us (myself included) who don't use Windows unless we absolutely have to.Out of curiosity what are the processes or operations for which you have found Windows to be absolutely necessary?

I asked Chuck but everyone who has something of interest to add should feel free to chime in.

Chuck(G)
July 30th, 2017, 11:25 AM
There are some older tools for now-obsolete MCUs and CPLDs that run only on Windows, as far as I can tell. I tried running under Wine, with no success.

alecv
August 1st, 2017, 09:02 AM
So why do we have a 720/1440 usb drive, but not a 360/1.2m usb drive? According to the UFI standad there is no 1.2Mb 5" format for USB floppy !
http://www.usb.org/developers/docs/devclass_docs/usbmass-ufi10.pdf
p 4.5.3. There is also unknown Japanese floppy 3.5" 1.2Mb.

Studying spec carefully shows you can temporary change a floppy geometry with
UFI command: FORMAT UNIT. So real 1.2 drive with Floppy-USB bridge will work
for a short time after format a: /t:80 /n:15, until diskette change and then
switch back to 1.44.

Chuck(G)
August 1st, 2017, 09:29 AM
The Japanese 1.23MB format is 8x1024 byte sectors per track. So, not a good candidate.

However, a 360K floppy drive should work using the 720K parameters--same data rate and number of sectors per track.

But again, why? Who but someone without a legacy floppy controller on an abundant "tweener" would want to spend money on this?

eeguru
August 1st, 2017, 09:45 AM
I did use my 3.5" USB floppy drive I had laying on the shelf to create and alter MS-DOS boot disks for a vintage machine by plugging it into my Linux box. Was quick and convenient - especially so as my tweener was down due to a corrupted flash image. If that vintage machine happened to only have a 5.25" boot drive, the process would have been slower via PC-NFS drive mount.

Cases do come up.

Chuck(G)
August 1st, 2017, 10:04 AM
Your Linux boxes don't have 5.25' drives? Mine do. ;)

Stone
August 1st, 2017, 10:37 AM
Your Linux boxes don't have 5.25' drives? Mine do. ;)Hmmmmmm, 5.25' drive... that must be a really bix box you have! :-)

krebizfan
August 1st, 2017, 11:07 AM
The YE-DATA USB floppy drives support AT-style 1.2MB plus an 8 sector track 640 KB. https://www.yedata.com/multi/download/FDUS-521019_C.pdf Get source code to the matching driver and the necessary chips and most of the work involved in creating USB 5.25" drive is already done. Figure out a way to do 40 tracks and single-sided read/write and common PC formats would be supported. Would need a different driver for high density and double density 5.25" drives.

Chuck(G)
August 1st, 2017, 12:03 PM
Be careful. Unless you've actually got one of these drives, this may or may not be true. Back around 2001, I contacted YE over their published specs (I was enthusiastic over finding them). They admitted that much of it was whole cloth, copied from their existing legacy drive specs.

That may have changed, but the conversation sticks in my mind.

nzoomed
August 2nd, 2017, 04:20 PM
USB floppy drives sadly are not as good as an internal floppy drive.
Annoying thing is my computer which is fairly modern to have a floppy controller, only supports one floppy drive!

USB ones apparently wont read older 720K floppy disks also.

Im hoping there will be a solution soon that will see a USB or PCI express floppy controller card come to the market for vintage computing.
There are a few read only solutions out there currently, but we as enthusiasts need something for our modern computers.

Its good i can still actually use a 5.25 drive on my modern win7 computer, but the BIOS only allows one drive.
I have read that the winbond IO chip on the motherboard will support two drives, but the pin for the second drive is physically disconnected on the motherboard!
Stupid to go to all the effort to put a floppy controller on the motherboard, for the sake of one pin the second drive is unusable.

I know all motherboard manufacturers are different, but perhaps if it is wired correctly on the motherboard all thats needed is a BIOs mod?
IDK, but its a PITA to swap drives on the cable and restart the PC.

The technology exists today to make it happen, just need someone with the right skills to do it.
I would happily contribute to any kickstarter project for such a card that would do this.

flashedbios2012
August 8th, 2017, 07:14 AM
Supporting one drive on a modern motherboard is understandable, but check this out:

I ordered 3 BRAND NEW IN BOX Intel SE440BX-2 Motherboards from eBay. I plan on building a Pentium 3. Anyways, even the bios on THOSE boards, supports only 1 floppy drive. The only way you can get it to show the option for a 2nd drive is disable the onboard floppy controller, and insert an ISA Floppy Controller.

Unknown_K
August 8th, 2017, 08:44 AM
I have enough machines with 5.25" drives not to really need a USB external, but it would be cool to have. Now an external dual 5.25" USB enclosure that could duplicate or image ANY floppy format for ANY system would be cool.

Xacalite
August 8th, 2017, 03:01 PM
Now an external dual 5.25" USB enclosure that could duplicate or image ANY floppy format for ANY system would be cool.
If you're looking for KryoFlux, you know where to find it.

Zippy Zapp
August 8th, 2017, 03:30 PM
Supporting one drive on a modern motherboard is understandable, but check this out:

I ordered 3 BRAND NEW IN BOX Intel SE440BX-2 Motherboards from eBay. I plan on building a Pentium 3. Anyways, even the bios on THOSE boards, supports only 1 floppy drive. The only way you can get it to show the option for a 2nd drive is disable the onboard floppy controller, and insert an ISA Floppy Controller.

Is it this one?: http://www.ebay.com/itm/391838842732

I have one of these and I couldn't get the floppy controller to work with any drive. 3.5 or 5.25 drive. Sees the drive and tries to access it but it fails. let me know how yours works. I didn't try updating the BIOS. And I suppose it could be a bad chip or FDC. I threw in an ISA multi-function card that I had and it works with the Floppy no problem.

Unknown_K
August 8th, 2017, 03:59 PM
If you're looking for KryoFlux, you know where to find it.

Nope, a stand alone smart unit that will copy or image anything without me having to do anything. I have a Central point DOB.

Casey
August 8th, 2017, 07:04 PM
USB floppy drives sadly are not as good as an internal floppy drive.
Annoying thing is my computer which is fairly modern to have a floppy controller, only supports one floppy drive!

USB ones apparently wont read older 720K floppy disks also.

I picked up an external USB floppy unit which reads 720k fine, but doesn't want to format that capacity. That's plugged into my main system running Win7 Home Premium. It seems to format 1.44 fine.

Casey
August 8th, 2017, 07:09 PM
I have enough machines with 5.25" drives not to really need a USB external, but it would be cool to have. Now an external dual 5.25" USB enclosure that could duplicate or image ANY floppy format for ANY system would be cool.

That was the thinking that got me starting this thread. :) Alas, looks right now the most effective method of transferring data is either finding a vintage network card, or glitch's CF to IDE adapter.

Casey
August 8th, 2017, 07:12 PM
Supporting one drive on a modern motherboard is understandable, but check this out:

I ordered 3 BRAND NEW IN BOX Intel SE440BX-2 Motherboards from eBay. I plan on building a Pentium 3. Anyways, even the bios on THOSE boards, supports only 1 floppy drive. The only way you can get it to show the option for a 2nd drive is disable the onboard floppy controller, and insert an ISA Floppy Controller.

Hmmm. Looks like I should keep at least one of my two Athlon systems then, since they both support 2 floppies. :)

...Come to think of it, what sort of IDE does the 440bx chipset support? You might end up with better hard drive performance with a separate controller.

Chuck(G)
August 8th, 2017, 09:14 PM
I picked up an external USB floppy unit which reads 720k fine, but doesn't want to format that capacity. That's plugged into my main system running Win7 Home Premium. It seems to format 1.44 fine.

Don't depend on Windows to provide good driver support. Try ufiformat under Linux. With a Sony USB drive, I can format 1440K, 1232K (NEC PC98 ), 720K and 640K. With the same drive, Windows will only format 1.44MB.

With the driver hassle, why does anyone who's serious about this stuff still use Windows? :huh:

Dwight Elvey
August 8th, 2017, 09:32 PM
You might also look at the Gotek using HxC's software.
He supports a number of 5.25 formats.
Dwight

Caluser2000
August 9th, 2017, 12:16 AM
Don't depend on Windows to provide good driver support. Try ufiformat under Linux. With a Sony USB drive, I can format 1440K, 1232K (NEC PC98 ), 720K and 640K. With the same drive, Windows will only format 1.44MB.

With the driver hassle, why does anyone who's serious about this stuff still use Windows? :huh:Each to there own I guess Chuck. I can't imagine owning a system without a floppy drive :) Its not like you need a powerful system to run Linux on either.. any old Pentium through PIII should do. Even a nasty ol P4. mformat works well enough. Its quicker than formatting in Dos as well.

Stone
August 9th, 2017, 03:28 AM
I picked up an external USB floppy unit which reads 720k fine, but doesn't want to format that capacity. That's plugged into my main system running Win7 Home Premium. It seems to format 1.44 fine.Try the operation from a Command Prompt.

I simply use, 'format A:', and it works fine with both of my USB floppy drives.

Chuck, have you tried this method?

Dwight Elvey
August 9th, 2017, 05:43 AM
I should note that in the past, I've found that if the disk is
already formatted at a different density than you want the
program won't format it to a new density. I've had to erase
the disk first.
Dwight

Stone
August 9th, 2017, 06:00 AM
By erase the disk you mean destroy the existing format, don't you?

Chuck(G)
August 9th, 2017, 07:20 AM
Ideally degauss with a bulk eraser. Radio Shack used to sell an inexpensive one for erasing VHS tapes. Don't know what's available now, but the RS ones do show up on eBay.

Stone
August 9th, 2017, 07:30 AM
I've used a neodymium magnet from an IDE drive.

NobodyIsHere
August 9th, 2017, 08:20 AM
If this is off topic, let me know. This seemed like the place to ask.

We all know usb 1.44Mb floppy drives are all over the place. In fact they're nearly disposable. You can get a new one, free shipping, for less than $10 eBay these days.

My question is this: the 360/1.2m floppy drives were in many ways very similar to the 720/1440 floppy drives. Yes, there were speed differences between 360k & 1.2M and so on, but looking at the back of those drives, they aren't that different. In fact I have a couple of 3.5" drives which run off of edge connectors quite nicely once you snap on an adapter.

So why do we have a 720/1440 usb drive, but not a 360/1.2m usb drive? The circuitry inside the drive box? No one ever anticipated a need for a 5 1/4" usb floppy drive? The 1.44 was all that was seen as needed?

While I'm on a rant, why not a usb-to-serial adapter? Even usb 1.0? I know the later aftermarket 16550 UARTs could handle a healthy amount of throughput. It would be nice to plug a usb thumb drive into an adapter on an old XT or 286 system.

Yes, we have Glitch's excellent 8-bit IDE adapter, but I'm very poor these days, so I'm dreaming. If I had the money, I'd get an IDE adapter, a DOM for storage, then Startech's front-panel compact flash to IDE bay for sneakernet. At least I assume that the glitchworks adapter can handle 2 devices at once...

In the past I've thought about this problem and thought an ideal hobbyist type solution would be a simple SBC board with an 8 MHz Z80, WD2797 FDC, a 16550 UART + TTL to USB converter cable, and 32KB RAM & 32KB ROM. It would require a driver for the PC side (MS DOS, Windows, Linux, etc. ). I think I designed something very similar to this a several years ago. The specific code to support various disk formats would reside in the 32KB ROM.

I think this would be simple and cheap without having to redesign the FDC. Also the WD2797 allows for whole track raw reads of floppy disks which the NEC 765 type FDCs generally do not allow. That should allow for a lot of flexibility to support many diverse and unique formats. Maybe not quite as capable as a Catweasel or Kyroflux but close and better than the usual PC floppy controller.

This could easily support 3.5", 5.25," and 8" drives at least and probably other sizes too as long as they follow the Shugart Floppy interface "standard".

Dwight Elvey
August 9th, 2017, 08:39 AM
By erase the disk you mean destroy the existing format, don't you?

yep
Dwight

nzoomed
August 14th, 2017, 02:34 PM
Supporting one drive on a modern motherboard is understandable, but check this out:

I ordered 3 BRAND NEW IN BOX Intel SE440BX-2 Motherboards from eBay. I plan on building a Pentium 3. Anyways, even the bios on THOSE boards, supports only 1 floppy drive. The only way you can get it to show the option for a 2nd drive is disable the onboard floppy controller, and insert an ISA Floppy Controller.

Ive seen USB to ISA adapters on ebay, does anyone know if these would work on a modern PC if i connected a floppy controller to it?

Its nice to have drag and drop support in windows.

Casey
August 14th, 2017, 02:39 PM
Try the operation from a Command Prompt.

I simply use, 'format A:', and it works fine with both of my USB floppy drives.

Chuck, have you tried this method?

Haven't tried that yet, thanks for the suggestion!

I did find out it boots quite nicely by accident. I had a Windows update which required a reboot, and since I need to visit the bathroom I selected "reboot now" and went my merry way.

When I came back I was shocked to see a text screen, white on blue. ZOMG, the dreaded BSOD!! No, it was actually the first screen for MS-DOS 6.22 setup. I had forgotten that there was a floppy in the drive (which was plugged into the usb port). It not only booted, but started the setup program. Didn't think that would happen on a modern system, but there you go.

Since I didn't want to install MS-DOS 6.22 over my Win7 system, I quit the setup program and rebooted normally. Just thought y'all would get a chuckle out of that...

mR_Slug
August 14th, 2017, 06:28 PM
I've never had a USB floppy drive, so I don't really know why they are desirable over a tweener. Is it just compactness? A low-tech approach could be to build a tweener out of a "book PC" or some other small form-factor PC. Linux+samba and an IDE SSD, and you've got a networkable Floppy drive. If you don't like linux+samba you can swap that with MS-DOS+MS network client. Either way you share the floppy, and mount it as a SMB share. This doesn't add much more bulk to an already bulky 5.25" FDD.

Caluser2000
August 14th, 2017, 06:55 PM
I can see a USB fdd can be handy. Some times its just easier to copy directly to a floppy.

Stone
August 15th, 2017, 03:22 AM
I can see a USB fdd can be handy. Some times its just easier to copy directly to a floppy.Yes, definitely.

Lately, though, I've been using a USB flash drive to get files to my tweener. It just holds way more for when I need to transfer more than 1.44 MB.

Malc
August 15th, 2017, 03:45 AM
Lately, though, I've been using a USB flash drive to get files to my tweener. It just holds way more for when I need to transfer more than 1.44 MB.

Yup, That's what i use, It's So much easier / convenient, Though i can see a USB 5.25" floppy would be very handy too, What i'd really like to see is an ISA > USB card with working drivers incorporated into the XUB, That would be great.

Stone
August 15th, 2017, 03:57 AM
My tweener has four PCI and three ISA slots so I've got a PCI USB card in it for the flash drives.

Casey
August 19th, 2017, 09:19 AM
I've never had a USB floppy drive, so I don't really know why they are desirable over a tweener. Is it just compactness? A low-tech approach could be to build a tweener out of a "book PC" or some other small form-factor PC. Linux+samba and an IDE SSD, and you've got a networkable Floppy drive. If you don't like linux+samba you can swap that with MS-DOS+MS network client. Either way you share the floppy, and mount it as a SMB share. This doesn't add much more bulk to an already bulky 5.25" FDD.

It's nice having a relatively modern system that can access 1.2M, 360K, and 1.44/720k drives all at once. I have an Athlon 1.4Gz which can handle either XP or 98se nicely, either of which allows me to network to that system and drop disk images there.

VERAULT
September 7th, 2017, 04:27 AM
Lynchaj, if you can build it and write the driver, Ill preorder one now! I would love to have the use of a 360K/1.2Mb floppy via usb! I bought the Kryoflux for over $100 US and it doesnt do what I need.

NobodyIsHere
September 7th, 2017, 09:58 AM
The project is long dead. If someone wants to take it up I will search my archives to see if it can be resurrected but otherwise just let it be forgotten.

VERAULT
September 7th, 2017, 12:24 PM
I got my hopes up for nothing! Shame!

VERAULT
September 7th, 2017, 02:18 PM
those are some interesting figures,. I understand now why there is no demand. But implementing a common tool which can connect and utilize old drives on a new platform would still have a small demand from this crowd.

nzoomed
September 16th, 2017, 03:45 AM
I just bought this off ebay
http://www.ebay.com/itm/1-44-MB-1-4MB-USB-FLOPPY-DISC-DRIVE-34PIN-ADAPTER/232476218561?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2057872.m2749.l2649
It works fine with my 1.44 drive, but wont format or read 720K floppies, so doubt it will work with a 1.2MB 5.25 drive. Might be possible with the right driver or perhaps it needs a whole new chip. Its probably some FGPA, but there is no writing on the chip anywhere.

NobodyIsHere
September 20th, 2017, 08:45 AM
Well I found my previous design for a USB to FDC project. It is a schematic only apparently left over from discussions on this same subject we've had previously. As described the schematic is a Z80 CPU, 32KB EEPROM, 32KB SRAM, 16650 UART and a WD2793 FDC.

The design is essentially a mish mash of parts of the SCSI2IDE project (which worked) and the S-100 ZFDC project (also worked). The USB is implemented using a Sparkfun TTL serial to USB cable which is cheap and ubiquitous component. A good portion of the software already exists in the form of the S-100 ZFDC firmware on John Monahan's site however it would have to be modified somewhat to work with this project.

Are people interested in pursuing this option? I can help produce a prototype PCB but we'd need someone(s) to pull together the Z80 software and also a Windows driver.

I am sure there will be people rushing to advise that the project should be a FPGA MCU Blah Blah Blah design but unless they are willing to actually execute their recommendations I don't see it happening. Using a vintage electronics approach it would be fun and simple and just do the job at hand without a lot of added extras and relatively simple software. Certainly this topic has been discussed many times before and nothing ever seems to come of it. I think the KISS approach would work and am willing to at least make a board but it still needs software to complete.

The WD279x is a good choice for this because it supports "TRACK READ" function which none of the NEC765 derivatives can do to my knowledge. The WD279x can read a whole track into memory at once which would be very helpful for exotic soft sector formats, 3.5", 5.25", and 8" disks, etc.

Chuck(G)
September 20th, 2017, 09:16 AM
The WD279x is a good choice for this because it supports "TRACK READ" function which none of the NEC765 derivatives can do to my knowledge. The WD279x can read a whole track into memory at once which would be very helpful for exotic soft sector formats, 3.5", 5.25", and 8" disks, etc.

Say what? The 765 and relatives can indeed read either multiple sectors (i.e. matching sector IDs) or an index-to-index track read ignoring sector ID headers.

You're aiming to use way too much hardware to do the job. 5V tolerant MCUs can do the job for much less cost in both real estate and BOM (for exmaple, an STM32F4 MCU has 192K of SRAM, USB and ethernet and a potload of GPIO, along with something like 8 32-bit DMA channels. Even the crufty old Microsolutions Backpack drive uses an 8051, an 8477 and a 16K SRAM--and that design is over 20 years old.

NobodyIsHere
September 20th, 2017, 09:53 AM
Are you willing to make the board? That would make everyone happy and I'll retire my idea. I don't see anyone lining up to implement any solution yet. Lots of talk but no action.

The WD279x can raw read a whole track at once not just multiple sectors. The NEC765 needs a sector header to start its read process but the WD279x can just read the whole track in one action. It's a big difference.


Say what? The 765 and relatives can indeed read either multiple sectors (i.e. matching sector IDs) or an index-to-index track read ignoring sector ID headers.

You're aiming to use way too much hardware to do the job. 5V tolerant MCUs can do the job for much less cost in both real estate and BOM (for exmaple, an STM32F4 MCU has 192K of SRAM, USB and ethernet and a potload of GPIO, along with something like 8 32-bit DMA channels. Even the crufty old Microsolutions Backpack drive uses an 8051, an 8477 and a 16K SRAM--and that design is over 20 years old.

Chuck(G)
September 20th, 2017, 10:28 AM
The WD279x can raw read a whole track at once not just multiple sectors. The NEC765 needs a sector header to start its read process but the WD279x can just read the whole track in one action. It's a big difference.

I know that--I've been programming the WD17xx series since the line first came out. But to what end is the raw track read useful in a USB sense? How would that be used?

What would be the appeal for this thing? Most "tweeners" can handle 5.25" floppies. Guarantee me 250 users and I'll see what I can do.

NobodyIsHere
September 20th, 2017, 12:48 PM
Do I get a guarantee? That's hilarious! No wonder nothing gets done. More talk, no action.

The WD2793 is very flexible for all sorts of soft sector formats AND the design is proofed out already as part of the ZFDC.

That was my point before, we don't need to design anything new just re-use existing designs with minor modifications.

Based on this conversation, I will assume no one will do anything yet again on this topic. The perfect truly is the enemy of the good enough.

Al Kossow
September 20th, 2017, 12:55 PM
Do I get a guarantee? That's hilarious! No wonder nothing gets done. More talk, no action.


And who died and made you boss?
You also forgot to mention you expect this to all be open-sourced.

NobodyIsHere
September 20th, 2017, 01:21 PM
Yup, more of the same. I offer a legitimate solution and willingness to help and the response is empty criticism. I guess you get what you deserve.

I will open source my hardware design and post the files which is true for all of my designs. I'd expect the same for the software.

Next time you wonder why so few vintage computer projects actually get off the ground take a look in the mirror.

Al Kossow
September 20th, 2017, 01:38 PM
Next time you wonder why so few vintage computer projects actually get off the ground take a look in the mirror.

You're talkin' to the WRONG person to fling THAT dung at, kid.

mR_Slug
September 20th, 2017, 03:02 PM
I'm sorry this is in the middle of drama. I feel like a kid where all the adults are arguing. Is it at least possible to see the design?

I'd be quite interested in building something around the Z80. Problem is I usually lack motivation (and knowledge/time) unless it's actually does something useful. I like projects using old technology. I really want to obtain or build a floppy emulator, but a vintage one. They sold a few around 1981-2 for the IBM PC. I understand you can buy a new one and modify it, but I like old designs. Perhaps this would give me better understanding of what's involved. If you built/programmed loads of this stuff in the '80s I can understand you asking the question of "Why would you want to do that?". The way I look at lynchaj's design is: I get to build something useful AND learn a bit about the Z80. If you already know how to design/program a small system with a Z80, I guess the second aspect is not really appealing.

Anyway I'll be rocking back and forward in my safe-space:-)

NobodyIsHere
September 20th, 2017, 03:17 PM
Well, let's see. Go back and read the OP's original post. How many actual steps have been taken to genuinely solve the problem? i.e. lack of a general purpose USB floppy drive that supports legacy formats? What do you offer? Personal attacks. That's not helpful.

Then I have the temerity to suggest a solution which would also be a fun vintage computer project. This problem has come up many times before so its been thought through. The parts already exist and so does most of the software. So I post my idea and I have a schematic and what happens? Does anyone even ask for the schematic or discuss the design? No, they go straight for the complaints, empty criticism, and personal attacks.

You see it doesn't matter WHAT design I would have posted some people only want to complain and criticize and won't lift a finger to actually help the OP. I could have suggested the latest FPGA with ARM core and it would have gotten the exact same reaction. But that design has all the same problems previous programmable chip transition counter designs (catweasel, kryoflux, others) have. They have closed software that's maybe OK for certain point solutions but can't be used in a general manner... like what the OP asked about.

I know the transition counters are difficult to write software for because I've done it (hard sector formats like NS, VG, HZ, etc.). If it were easy there would be a USB catweasel that worked just like the OP wants it to but it doesn't exist. Same for Kryoflux, etc. Little or no software support because their closed designs.

So if anyone is actually interested in helping the OP just let me know.

NobodyIsHere
September 20th, 2017, 03:19 PM
You're talkin' to the WRONG person to fling THAT dung at, kid.

Right back at ya

NobodyIsHere
September 20th, 2017, 03:35 PM
Is it at least possible to see the design?

Finally, a sensible response.

Pls send me a PM with your address and I'll email them to you. The forum doesn't allow attachments of the size needed to post the PDFs.

The schematic is kind of crude but complete. It would not be hard to make a PCB.

Chuck(G)
September 20th, 2017, 04:04 PM
Look, I'm not here to start a fight. But I don't need a USB 5.25" drive adapter, much less one that uses obsolete technology. (Does anyone still make the WD2793?). And if I had to use a WD chip for a 5.25" drive, it'd be a WD1772-PH-2; much less external logic, can drive the floppy directly without interface logic and even does high density--and has your beloved "read track" function, all in a 28 pin package. (Yes, I've used them; still have an ISA board with one I designed).

But using inexpensive modern technology, in my opinion, is the way to go. Reading and writing floppies isn't rocket science--heck, even a full implementation of a WD1772 exists in a corner of an FPGA and is used in the Firebee.

I've been skunked before by people claiming that there's a ready community of people who'd jump at a product, if only I'd do it. The most memorable one was where I spent my time working on a driver, getting it all checked out and ready, shipping a copy to the requester (who claimed to represent a large community) and not even getting a single follow-up--not even from the original guy.

If it turns out that there are only 5-10 people out there who really want this thing, then they can code and test it out themselves. I have no use for one and life is too short for me anyway.

(FWIW, you don't even need a PCB for this--development boards are available for less than $12 shipped).

NobodyIsHere
September 20th, 2017, 04:32 PM
files posted here

https://www.retrobrewcomputers.org/forum/index.php?t=msg&th=212&start=0&

mR_Slug
September 20th, 2017, 06:25 PM
I'm looking over the design, I will have to check out the S-100 ZFDC.

So as I understand it the 16550 connects to the USB-to-Serial thing and an SD card. What is the SD card for? Is the plan to have a disk image loaded either via serial or SD card?

I'm a bit confused by the P19, P20 and P21. Is the 50-pin P19 the 8" floppy interface? and what is P20-21? They all look like they have floppy signals on them.

I'm just brainstorming an alternative architecture here, but would it be several orders of magnitude more difficult to build a USB-to-ISA device? Perhaps with a driver that would make it appear to DosBox/PCjs/VirtualBox or something similar? Then you could just plug in a FD controller and access it from in there. But you could also do it with an ST-506 controller or whatever. I think the LPC bus would kinda work, but IIRC it has problems with DMA or interrupts. It would seem like a device that would have countless uses.

eeguru
September 20th, 2017, 07:12 PM
I don't get throwing a Z80 and all the supporting hardware at the problem just to talk over a serial port; especially for cost sensitive applications. You might as well just re-purpose an old PC motherboard to plug the floppy drive into and write a x86 binary to proxy I/O over COM1: (or use any of a dozen existing RS-232 file sharing apps). I don't get how a Z80 SBC is any better than using a tweener machine?

If you want to write the Z80 firmware and support apps and own it, I support you. But I think there are easier (and cheaper) ways to skin the cat(weasel).

Plasma
September 20th, 2017, 07:31 PM
I'm looking over the design, I will have to check out the S-100 ZFDC.

So as I understand it the 16550 connects to the USB-to-Serial thing and an SD card. What is the SD card for? Is the plan to have a disk image loaded either via serial or SD card?

I'm a bit confused by the P19, P20 and P21. Is the 50-pin P19 the 8" floppy interface? and what is P20-21? They all look like they have floppy signals on them.

I'm just brainstorming an alternative architecture here, but would it be several orders of magnitude more difficult to build a USB-to-ISA device? Perhaps with a driver that would make it appear to DosBox/PCjs/VirtualBox or something similar? Then you could just plug in a FD controller and access it from in there. But you could also do it with an ST-506 controller or whatever. I think the LPC bus would kinda work, but IIRC it has problems with DMA or interrupts. It would seem like a device that would have countless uses.

FYI there is already a USB to ISA adapter (http://arstech.com/install/ecom-prodshow/usb2isar.html) available. Dunno if it works with floppy controllers though.

Stone
September 21st, 2017, 02:29 AM
Only $149. :-)

eeguru
September 21st, 2017, 03:35 AM
So as I understand it the 16550 connects to the USB-to-Serial thing and an SD card. What is the SD card for? Is the plan to have a disk image loaded either via serial or SD card?
Forget the SD card. The whole design is a carry over from Douglas' SCSI2IDE. Which was itself based on a commercial product that he designed decades ago. And his only hammer for everything was a Z80. The bit-banged SD card through a UART was so slow it was practically unusable.


I'm a bit confused by the P19, P20 and P21. Is the 50-pin P19 the 8" floppy interface? and what is P20-21? They all look like they have floppy signals on them.
P20 and P21 are 1x17 single row headers that collectively make up a standard PC 34-pin floppy header.

NobodyIsHere
September 21st, 2017, 08:18 AM
Hi, yes the TTL serial to USB adapter connects to the UART directly. I still need to add header pins.

The SD is left over from the SCSI2IDE project. I haven't decided to mark it DNP or remove it yet. The SD interface is slow but essentially free since it uses otherwise unused pins. Good for small user programs but not much else. Possibly archiving floppy images since they are so small.

I don't have the schematic in front of me but the P19 is an 8" floppy interface (50 pins). P20 & P21 together are a 5.25" interface (34 pins). It is a reused component from the ZFDC.

ISA to USB would be much more complex and if you want to do that it is a completely separate project. I am only offering what's gone before on the USB to FDC project.


I'm looking over the design, I will have to check out the S-100 ZFDC.

So as I understand it the 16550 connects to the USB-to-Serial thing and an SD card. What is the SD card for? Is the plan to have a disk image loaded either via serial or SD card?

I'm a bit confused by the P19, P20 and P21. Is the 50-pin P19 the 8" floppy interface? and what is P20-21? They all look like they have floppy signals on them.

I'm just brainstorming an alternative architecture here, but would it be several orders of magnitude more difficult to build a USB-to-ISA device? Perhaps with a driver that would make it appear to DosBox/PCjs/VirtualBox or something similar? Then you could just plug in a FD controller and access it from in there. But you could also do it with an ST-506 controller or whatever. I think the LPC bus would kinda work, but IIRC it has problems with DMA or interrupts. It would seem like a device that would have countless uses.

NobodyIsHere
September 21st, 2017, 08:24 AM
The problem with the FPGA & MCU approaches is they don't scale into a flexible general purpose device like the OP asked about. The Catweasel is a great example. It requires scarce, custom written software to do even the simplest thing. There is very little open source Catweasel software other than what Tim Mann posted and even that is far from general purpose. Similar for Kryoflux and others. It's not like it hasn't been tried its that the approach requires such complicated sophisticated software it just doesn't work. The beauty of reusing the mish-mash of SCSI2IDE and ZFDC is the software is mostly already available. And completely open source. Not as powerful as Catweasel or Kryoflux but with the raw track read function much more capable than the stock IBM PC NEC765 derivatives. Also this hardware already exists and has been shown to work. This is a modest extension of proven designs versus some "pie in the sky" great idea which will likely never get made much less software written for it.




I don't get throwing a Z80 and all the supporting hardware at the problem just to talk over a serial port; especially for cost sensitive applications. You might as well just re-purpose an old PC motherboard to plug the floppy drive into and write a x86 binary to proxy I/O over COM1: (or use any of a dozen existing RS-232 file sharing apps). I don't get how a Z80 SBC is any better than using a tweener machine?

If you want to write the Z80 firmware and support apps and own it, I support you. But I think there are easier (and cheaper) ways to skin the cat(weasel).

NobodyIsHere
September 21st, 2017, 08:33 AM
No, the SCSI2IDE was my idea and my design based on a conversation on CCTALK about diminishing 50 pin SCSI-1 hard drives. I thought it could be done and I am sure many others have had similar ideas. Douglas Goodall tried to build one (unsuccessfully) and posted some pictures. Wayne (?) built the prototype boards and wrote the software to make the project work. Douglas had little if anything to do with the SCSI2IDE project and its not a derivative of anything except maybe reused some ideas from my Z80 SBC. It did and does work as a SCSI-1 and SASI replacement drive tested on IBM PC clones and Amigas. Never a raging success but I thought it did OK. At least that board got made.

ZFDC was a collaborative project between John Monahan and myself. It started as a discussion about an S-100 intelligent floppy drive controller with local memory and it turned into the ZFDC. I liked the WD2797 FDC for some reason which I forget but we settled on the WD2793 mostly because I had some laying around. I think the one pictured on John's webpage actually is one I gave him. John wrote the firmware and monitor software.



Forget the SD card. The whole design is a carry over from Douglas' SCSI2IDE. Which was itself based on a commercial product that he designed decades ago. And his only hammer for everything was a Z80. The bit-banged SD card through a UART was so slow it was practically unusable.


P20 and P21 are 1x17 single row headers that collectively make up a standard PC 34-pin floppy header.

eeguru
September 21st, 2017, 09:44 AM
Thanks Andrew for clearing up my memory on the SCSI2IDE project. I will point out it has since been done better thanks to Michael McMaster. And that's all that is being suggested: different design approaches.

From my own history of observation, I've noticed you take the least bit of criticism as someone trying to take a dump in your spaghetti. That's not what is happening here. You have wrongly criticized approaches using MCUs and FPGAs that I could start a 20 page thread debating. Yet you get bent out of shape when people question your hard work. Especially towards the artificial intelligence presence called Chuck G. - who cannot possibly be human as he contains 10 times all the Wikipedia electronics knowledge known to man in one person(ality).

I will point out, you haven't offered a solution to the OPs problem either. As far as I can tell, you have not written and are not willing to support a firmware for your SBC that proxies floppy I/O over serial nor have you offered up a comprehensive host software for any OS that talks to it and processes disk images. If you are willing to do that, eg. drive this project to completion, I'll give you as many at-a-boys as you want. Until then, you haven't provided anything more than anyone else here in the gallery. But thanks for your participation.

On the SBC idea, I would think taking the schematics of the two boards below, routing them together, and modifying Dave's excellent Image Disk firmware to run out of ROM and talk to a UART would be as close as your Z80 idea. But it still needs someone to officially make it a 'thing':

https://github.com/skiselev/micro_8088
http://www.malinov.com/Home/sergeys-projects/isa-fdc-and-uart

Chuck(G)
September 21st, 2017, 10:42 AM
@eeguru. No, I'm just old and decrepit, not particularly smart. :)

eeguru
September 21st, 2017, 10:47 AM
@eeguru. No, I'm just old and decrepit, not particularly smart. :)

You're a walking encyclopedia. I'll buy you a beer if you are coming to VCF-PNW.

Chuck(G)
September 21st, 2017, 11:09 AM
You're a walking encyclopedia. I'll buy you a beer if you are coming to VCF-PNW.

Thanks, but crowd mashups aren't my thing. I appreciate the offer, however! :)

NobodyIsHere
September 21st, 2017, 05:58 PM
Well I fully support projects that are faster, better, and cheaper. I look forward to any and all USB 5.25" floppy disk projects.

I guess we'll see in a few months when this topic is raised again whether anything happens or if its all just hot air.

If anyone wants to collaborate on the USB2FDC concept you know how to reach me.

lowen
September 22nd, 2017, 06:28 AM
Say what? The 765 and relatives can indeed read either multiple sectors (i.e. matching sector IDs) or an index-to-index track read ignoring sector ID headers.

WD2793 (and similar) can do multi-density on one track. 765 cannot, to the best of my knowledge (but I always reserve the right to be wrong). TRS-80 Model I and Model III dual-boot disks use this 'feature' of the Western Digital controllers to allow a single-density track 0 sector 1 to co-exist with a double-density track 0 sector 1 on the same floppy. The magic is in the WD's Force Interrupt command, and the 'long-form' Write Track method of formatting, which allows great flexibility in what goes on the disk (you can even do mixed sector sizes in one track, if you want to get really crazy).



You're aiming to use way too much hardware to do the job. 5V tolerant MCUs can do the job for much less cost in both real estate and BOM...

If you want to 'retrobrew' it you use the old WD controllers. If using older hardware isn't necessary, well, the Kryoflux uses an Atmel MCU. The STM32 series would be a good choice. You just need appropriate I/O drivers and the code to read and/or write. I think a Z180-based unit would be really cool, but I'm very much a Z-80-family kind of guy.

I personally would like to see a fully open competitor to Kryoflux, but my project stack is full enough that until I need to make one for my own use I'm not likely to put out too many cycles in the near future (having too much fun doing the CPU280 revival!).

Chuck(G)
September 22nd, 2017, 09:14 AM
Multi-density on one track? I'm not exactly sure what that means. Do you mean multi-modulation or multi-data rate? And exactly (don't worry, I know how to program the thing), give details of what you're talking about and how you go about doing it.

Deviceside, for a time, offered competition for the KF, but they seem to have gone quiescent (unless I'm behind in my news updates).

Al Kossow
September 22nd, 2017, 09:19 AM
Deviceside, for a time, offered competition for the KF, but they seem to have gone quiescent (unless I'm behind in my news updates).

you can still get deviceside but they are read only and the software is pretty clunky

closest competitor to KF is the SuperCardPro

https://www.betaarchive.com/forum/viewtopic.php?f=5&t=34032

Chuck(G)
September 22nd, 2017, 09:58 AM
FWIW, this is my current cheap "go to" MCU board:

STM32F4VE (http://www.ebay.com/itm/STM32F407VET6-STM32-Cortex-M4-Development-Board-NRF2410-FMSG-SD-Card-No-Battery-/201950756099?epid=25002737836&hash=item2f0533fd03:g:1QQAAOSwDtpZbiNZ)

Programming is a bit of a chore, as there's not a lot of documentation, other than a schematic and some forum discussion--and the STM32 peripheral programming documentation is often clear as mud (they really should rewrite the MCU manuals). But lots of memory, a fast 32-bit CPU, 5V tolerant I/O and other goodies for under $10 makes it hard to beat. Tools are open-source and free.

lowen
September 22nd, 2017, 10:09 AM
Multi-density on one track? I'm not exactly sure what that means. Do you mean multi-modulation or multi-data rate? And exactly (don't worry, I know how to program the thing), give details of what you're talking about and how you go about doing it.

Yes, multiple modulations on one track, FM on part of the track and MFM on part of the track.

Ok, you start by formatting track 0 mfm, with the Write Track command's data buffer containing a post-index gap as long as the complete FM partial track; probably half a track's worth of post-index gap, then you write the standard format for less than half the number of usual sectors (TRS-80 uses 256-byte sectors) as documented for the Write Track command. Write until complete.

Now, set a buffer for the FM partial track, and start a Write Track using the FM format for the write. When you reach the end of the partial track of data, issue a Force Interrupt (command hex code 0xD0), interrupting the Write Track partway through the format. If you have your timing right, you should still have post-index gap bytes (written with the MFM-mode Write Track) to spare before the first MFM sector. You don't even need a complete half-track of sectors, just sector 1 for the Model III or the Model I, and the rest of the code could start on track 1, in FM.

I need to dig up my Zaxxon creator disk from Guy Omer; the Zaxxon TRS-80 game was one of the ones that used this trick, and the Zaxxon disk creator code would have all the details on how to do the work.

You could, if you wanted to, start with the FM format and just tuck a single MFM sector right after the index; that would be the minimum requirement to get Model I and Model III boot (the Model I was single-density only (1771 controller); the Model III, while it was capable of both single and double density (1793 controller), it could only boot double-density (the boot ROM wouldn't even try to boot single-density)). Either Kim Watt or Vernon Hester would know a great deal more about this than I; Vernon Hester especially was the King of TRS-80 Disk I/O routines.

EDIT: If it helps any, the TRS-80 Model III used NMI-driven programmed I/O for the floppy controller interface (1793's data request issued a gated NMI; there was an enable bit in an output port to gate the DRQ NMI). Since the Model I cannot without extra hardware do double-density, the creation of the dual-mode booter floppy had to be done on a Model III or 4, both of which use the same NMI programmed-I/O. Using DMA to do this would be a different challenge.

Frogger was another game that did this, and used some weird track and sector numbers on the five program tracks (tracks 1 through 5) that were recorded FM; the only MFM sector on the whole disk was track 0 sector 1, but there was also a track 0 sector 1 FM sector.


Deviceside, for a time, offered competition for the KF, but they seem to have gone quiescent (unless I'm behind in my news updates).

Hmm. I'll have to check into that. Al, thanks for the pointer as well to the SuperCard Pro.

Chuck(G)
September 22nd, 2017, 10:23 AM
So, it's all dependent on timing. You can probably do the same thing with an FM-capable 765-controller on the PC. At least I've seen similar things. Simply gate your formatting using the drive-select bits in the control register. It seems to me that someone figured out a way to read Commodore 1541 floppies on a PC using two drives, by starting a Read Track using an absurdly long sector length on a conventionally-formatted floppy, then switching to the 1541-type floppy as soon as data starts arriving. You could start a MFM format, turn off drive select once it started, then turn it on again mid-revolution to write the rest of the track. Then make a second pass, formatting in FM again, turning off drive select when you reach the "splice" point and aborting the command. This works because the 765 drive select output isn't used on the PC.

As with the WD17xx/27xx, messy, but possible after a fashion.

Of course, neither will help with more exotic (e.g. MMFM or RX02) formats.

lowen
September 22nd, 2017, 10:57 AM
So, it's all dependent on timing. You can probably do the same thing with an FM-capable 765-controller on the PC. ... You could start a MFM format, turn off drive select once it started, then turn it on again mid-revolution to write the rest of the track. Then make a second pass, formatting in FM again, turning off drive select when you reach the "splice" point and aborting the command. This works because the 765 drive select output isn't used on the PC.

As with the WD17xx/27xx, messy, but possible after a fashion.

Hmm, using drive select to gate the write.... it would be interesting to see how the two techniques compared for transients on the track. With the 17xx method, the drive select and thus the drive electronics aren't being hit with a transient, and you have a continuous flux pattern as part of the MFM '4E' bytes written in the post-index gap 'under' the FM partial track.

IMHO the 17xx combination of long post-index gap plus the force interrupt is a bit more elegant than bit-banging drive select (timing, in particular, can be tighter with 17xx, since the 17xx Write Track's timing requires the formatter to know exactly what byte is being laid down and so the formatter can issue the Force Interrupt synchronously, but the 765 format isn't, as far as I know, byte-synchronous from the point of view of the formatter code (I reserve the right to be wrong!)). But it would interesting to try it both ways. How would you synchronize the drive select drop during format with the 765? You could use the sector skew to cause sector 1 to be halfway down the track or more, and only have to drop drive select on the second format pass; I would definitely be interested in seeing any implementation (I could probably do that on the CPU280, which uses a 765-type FDC, from CP/M in Z280 code.... might be a fun exercise).


Of course, neither will help with more exotic (e.g. MMFM or RX02) formats.

No, you need something more general-purpose like the MCU solution.

eeguru
September 22nd, 2017, 01:55 PM
No, you need something more general-purpose like the MCU solution.

SuperCard Pro and KyroFlux are closed/proprietary. Are there any MCU solutions that are completely open?

I've studied the Discferret code a bit and it seems to do the job of clocking in an entire over-sampled flux-level track, but the back-end seems a bit dated and slow. It also seems write features are a bit lacking.

eeguru
September 22nd, 2017, 02:07 PM
And back to Andrews's original points, you could implement the OP's desire today with the SuperCard Pro and just software. While the on-board firmware is closed, the USB protocol is fully open and documented here (http://www.cbmstuff.com/downloads/scp/scp_sdk.pdf). So, one could write a GUI application that caches a track at a flux level, decapsulates the sector payloads, interprets a file system, and presents a file browser to the user. When a user drops a file (link) into the GUI, it could do the reverse. Update the file system, change sector payloads, and write dirty cached tracks back out to disk at a flux level. A Linux FUSE app could do the same thing. The advantage of such a solution is the ability to read/write nearly any floppy format.

So hardware isn't an excuse for writing a really useful software driver/app. It already exists...

Chuck(G)
September 22nd, 2017, 04:11 PM
SuperCard Pro and KyroFlux are closed/proprietary. Are there any MCU solutions that are completely open?

I've studied the Discferret code a bit and it seems to do the job of clocking in an entire over-sampled flux-level track, but the back-end seems a bit dated and slow. It also seems write features are a bit lacking.

That's basically the way most of these things work. Use timer capture to read (many Cortex M3s have DMA capability, triggered by timer capture/ compare) and PWM to write. Brutally simple. The only real issue is memory, but many Cortex M4s have sufficient memory to hold a track's worth. Reduction to data bits is modulation-dependent, of course, as is recognition of IDAMs and such, but you have the sampled track in memory, so you're not pressed for time. Store track data on a flash device, and you can often beat real disk performance, unless you're interested in maintaining accurate mechanical timings. Some tweaking for precompensation (bit crowding) is usually necessary--more code, no change to hardware.

NobodyIsHere
September 22nd, 2017, 05:03 PM
The WD2793 is a fairly common chip and would greatly simplify any hardware design regardless of whether you used a GP CPU or an MCU. It is a very powerful chip.

http://www.findchips.com/search/wd2793

plus other sources like ebay, etc. There is no shortage of these chips and they are relatively inexpensive.

Take a look at the Catweasel Tim Mann code to see what it is like to write the code to read & decode the raw transitions. It really boils down to using statistics to distinguish the various timing values into buckets and reassembling the bit stream.

eeguru
September 22nd, 2017, 07:56 PM
But my point was there is already a product (SCP) that allows easy and documented USB access to the flux level of any disk, disk modulation, and disk format. The simple stock software just allows transferring whole tracks to/from an image file or another drive. You don't have to build any new hardware to write a better software interface to virtualize a flux level disk image as a drag and drop shared folder - which you still have to do with the Z80 SBC. So just skip the Z80 SBC and write the app using the SCP's USB protocol instead. Both solutions show up as a virtual com port so the application level interface is exactly the same.

Interpreting flux level images has nothing to do with statistics. It is a simple state machine and as you've already pointed out, there are numerous examples already. In practice data separators in FDCs are constructed with a small amount of logic (eg. 1970s) and operate on the same flux level input bit-stream from the head that a device like SCP is capturing and sending over USB.

Chuck(G)
September 22nd, 2017, 10:05 PM
Well, to be frank, getting from data to domain and the reverse isn't quite the same. "What you write is what you'll read" is only true in a limited sense. You have to compensate for ISV, bit crowding, jitter and all sorts of other things. In the 1970s and 80s, the best data separators were analog PLLs--I've got a multibus-sized board here where about a third of the board is a very good PLL data separator. The downside is that an analog PLL requires adjustment--and that slows down mass production. Various digital PLL-type circuits are around, some decent, others much worse. The advantage is that you plop them onto a board and they work--no adjustment required. So they're about the only type you see any more.

But transition-sampling records what the heads pick up and you can crunch that data to your heart's desire. Ideally, an FM (single-diensity) spectrum shows two peaks at f and 2f (you either have a clock bit and a "1" data bit or just a clock bit for "0"). MFM has 3 peaks (f, 1.5f, and 2f), but has double the data rate of FM for the same bandwidth. But it takes a better data separator.

If you look at the spectrum of data transitions read from a floppy, you'll see that the outer tracks look pretty clean and close to "ideal"--you get 2 or three well-defined peaks. As you move toward the center of the disk, the peaks spread and become less well-defined--and this is where a good data separator, be it digital or analog or software earns its money. This is, for example, why bad sectors on a floppy tend to occur in the inner half of a diskette--the work is harder.

In writing, the outer tracks are like shooting fish in a barrel. Move toward the inner areas of a disk, however, and bits written can cause already-written bits to move. Precompensation looks at the bit that's being written and the bit written before that and the next bit to be written (yesterday, today, and tomorrow idea) and adjusts the timing slightly so that bit shifts are compensated for. In legacy disk controllers, this is usually done with a shift register, looking at 3 bits in time and deciding how to adjust the clock. Before this type of precompensation, simply reducing the write current ameliorated the bit shifting somewhat--and can be used in conjunction with precompensation or not.

Software data separation can do something that digital and analog data separators cannot do--compensate for dropouts. If your software algorithm expects a pulse and none occurs, it can supply one. You may get a 1-bit data error, but at least the rest of the sector won't be garbage. If you're super-fancy, you can even try to guess the position of the missing bit and run the result against the sector CRC to see what works.

Really, there's nothing that software in an MCU can't do that an LSI floppy controller can. It also affords the ability to tackle nonstandard encoding schemes, which LSI floppy controllers do not.

But, you have to write the software. :) Fortunately, silicon is cheap and fast, so you can even be a bit sloppy nowadays. For example, the STM32F407 that I referred to earlier runs at 168 MHz (though some have run them up to 250 MHz), with 16- or 32-bit timers running at a speed of 84 MHz--and you've got half a meg of program memory. 3-stage pipeline and predictive branch, ADC, floating point and a DSP to boot. Throw that against a Z80.

NobodyIsHere
September 23rd, 2017, 05:40 AM
Chuck makes my case beautifully. Reading data off a real disk is anything but deterministic but rather a stochastic process. You use statistics in the form of histograms (see the Tim Mann Catweasel software) representing where the various FM or MFM transitions are "accumulating" and it is a statistical clumping which varies from one read to the next -- even on the same track of the same disk in the same session. I found when writing software for the Catweasel that you had to let the disk "warm up" with a few spins for a while to get up to speed and then read the track a few times. Sometimes they'd read only when the disk was cold or after it had been reinserted into the drive. Then use the bitstream decoder to run through the collected samples and reconstruct the sectors one at a time. Fortunately on the disks I was working on you could read the tracks many times and store up a batch and then reconstruct the sectors one at a time. Eventually just by almost pure chance you'd get one sector to read correctly after several tries and that'd be your "good" sector read. "good" meaning you got a full read of the sector and it matched the metadata & checksum and frequently a visual inspection.

My point is Chuck is 100% right on the nature of reading the diskette. It is as much art as science and not trivial exercise. You can simplify the whole design tremendously by using a good quality FDC like the WD279x and let it do all the hard work and just send you an nicely formatted stream of bytes.

Using the MCU simplifies the hardware design but makes the software design a whole lot more complicated. Software is the weak point of this approach and I'd say the Catweasel, Kryoflux, Disc Ferret (forgot about that one) and others proves that point. They've all been out for years and there is precious little open source software for any of them and none of them does what the OP is asking for.

Admittedly, the approach I am suggesting is great for soft sector formats like IBM PC and almost all of the CP/M and derivative like disk formats which all use FM or MFM. Basically anything that 22Disk can do on a PC and maybe a few more. It is not useful for oddball Group Code Modulation formats like Apple II, early Mac, C64, Amiga (I think, not sure) and exotic formats like Intel MMFM, RX02, some synthesizers, proprietary CAD/CAMs, etc. It also won't work for hard sector formats (VG, NS, HZ, etc.). However, for the cases it will work account for the vast majority of disk formats AFAIK. All the others together are a tiny fraction in comparison which also explains why they aren't all that well supported by the other transition counter designs like Catweasel, Kryoflux, Disk Ferret, etc.

NobodyIsHere
September 23rd, 2017, 10:15 AM
But, you have to write the software. :) Fortunately, silicon is cheap and fast, so you can even be a bit sloppy nowadays. For example, the STM32F407 that I referred to earlier runs at 168 MHz (though some have run them up to 250 MHz), with 16- or 32-bit timers running at a speed of 84 MHz--and you've got half a meg of program memory. 3-stage pipeline and predictive branch, ADC, floating point and a DSP to boot. Throw that against a Z80.

That MCU would a full blown PC not all that long ago. What I am saying is that with an FDC (with hardware PLL data separator built in to the WD279x) even a meager 8MHz Z80 is massive overkill for this job because it simplifies the software so much. Someone has to write all that cosmic software you are describing and as you know it is not easy nor a simple matter for hobbyists.

Oh by the way, the software to decode the various GCM, MMFM, hard sector, etc. and other oddball formats is completely different than the relatively straight forward soft sector FM and MFM cases which makes for even more software writing and maintenance.

Chuck(G)
September 23rd, 2017, 10:37 AM
There must be a psychological lesson here somewhere. I hate to sound like an old grandpa recalling walking 5 miles to school in 6 foot snowdrifts, but good heavens, the hardware is cheap, the development tools are mostly free (back in the 8080 days, who ever heard of an IDE with a graphic interface?), manuals are free and access to others of a like mind is virtually unfettered. How fast does your PC run, 3GHz? Back in the day, a supercomputer ran at 10MHz.

Maybe the answer is that people are mostly wasting time fooling with their smartphones or playing videogames.

barryp
September 23rd, 2017, 03:08 PM
I have (somewhere) a PCB with USB connector and 34-pin floppy drive connector that I have connected to a TEAC 5" 1.2MB drive to copy TI99 disks. IIRC, it works with many other formats too.

Chuck(G)
September 23rd, 2017, 03:25 PM
That doesn't surprise me--SMSC at one time produced a simple USB 1.0-to-Shugart interface chip.

Not long after that, drives with integrated USB made their appearance and the chip became irrelevant.

ETA: It was the USB97CFDC2-01 (http://www.keil.com/dd/docs/datashts/smsc/usb97cfdc2.pdf). If you could find a supply of them, the job would be considerably easier. You'll note that the chip itself is based on the 8051 MCU.

NobodyIsHere
September 23rd, 2017, 05:57 PM
Hey, if you guys are so enamored with an MCU only solution don't let me slow you down. Go ahead and design a board, write the software, and make it work.

If your ideas truly are better then it should no be a problem and will demonstrate its superiority and benefit the vintage computer community. I wish you all the best of luck.

I think there are some real technical and practical problems with the MCU only approach and the history of similar designs seems to support it. However maybe you all are different and have the secret to making it work.

lutiana
September 23rd, 2017, 06:03 PM
Let's keep it civil guys. I see the trend in this conversation going down a rabbit hole of personal attacks and non civil interactions. Stick to the topic and try your best to leave the emotion at the door.

eeguru
September 23rd, 2017, 06:22 PM
Can you not digitize the head output across several rotations then auto-correlate each rotations' data using the sector 0 marker as an index point? Auto-correlate the data enough times and the signal starts to amplify and the common noise starts to diminish? Then take the AC'd output and run it though a threshold detector and then a digital state machine?

Sorry I was under the mistaken impression the drive already amplified and did binary quantization on the signal. I understand a marginal peak could flip between rotations. But that is why devices like SCP give you 5 rotations worth for each track.

eeguru
September 23rd, 2017, 06:52 PM
Software is the weak point of this approach and I'd say the Catweasel, Kryoflux, Disc Ferret (forgot about that one) and others proves that point. They've all been out for years and there is precious little open source software for any of them and none of them does what the OP is asking for.


Because:
1) USB MSC spec does not include support for 5.25" disk formats. You'll never get plug and play support in modern OSes
2) Designers of such products are focused on an archive use-case and want to support flux level recording to maximize the usefulness of the product. Limiting supported modulation schemes and low-level formats limits the overall product potential
3) Making the HW as cheap as possible (including ease of sourcing) and off-loading the heavy lifting to code running on modern desktops reduces production costs and makes a solution more affordable opening up a wider user base.
4) In order to make a contextually aware file-based drag-and-drop GUI takes quite a lot of OS specific software development with limited ROI.
5) You can still met the OP's functional end with the current software - just with more workflow steps. eg. record an image, open it up in a tool, manipulate content, optionally re-write the image to a disk
6) As mechanical drives continue to fail and no new disk drives are being produced, the community is trending towards drive emulators (FD and HD) and network loading images to said emulators. This is amplifying point #2.

I've built a SCSI2IDE board. At the time I did not have a lot of PTH 74xx series and sockets laying around. When I sourced the parts through distributors, the bill for parts alone was over $110 USD. WIth PCB and eBay purchases of the SCSI PHY and Z80, it was close to $150 assembled.

I still think dusting off a tweener PC and running ImageDsk and a PCAnywhere is already a better starting point than a Z80 SBC. But I'll digress. I look forward to the software solution you come up with Andrew...

lowen
September 23rd, 2017, 07:29 PM
Whee, this almost sounds like Mustang vs Camaro vs Corvette.....

For read-only and relatively inexpensive 5.25 on USB there is the $55.25 FC5025 from deviceside. I haven't tried it myself yet, but it looks interesting.

But I have a pair of Catweasels and a Kryoflux, so I'm set for now. I've archived all of my TRS-80 disks, but I still have the Catweasel MK4 installed in case I need it.

Chuck(G)
September 23rd, 2017, 09:30 PM
Can you not digitize the head output across several rotations then auto-correlate each rotations' data using the sector 0 marker as an index point? Auto-correlate the data enough times and the signal starts to amplify and the common noise starts to diminish? Then take the AC'd output and run it though a threshold detector and then a digital state machine?

Sorry I was under the mistaken impression the drive already amplified and did binary quantization on the signal. I understand a marginal peak could flip between rotations. But that is why devices like SCP give you 5 rotations worth for each track.

Yes, I routinely do conversions for non-standard media (i.e. not IBM 3740 or System/3 style, or hard sectored). Mostly my method is to start sampling at index and continue until the buffer fills up. That usually gets at least two revs and is enough to figure things out. Writing said oddball media is a little more complicated--for example, when writing hard-sectored disks, you ant to make sure that the original sectors are placed at the start of a hard sector, etc. But it's all doable and is no less reliable than using LSI chips of the time. All it takes is code--but said code written in C can easily be fast and compact enough.

NobodyIsHere
September 24th, 2017, 03:47 AM
Can you not digitize the head output across several rotations then auto-correlate each rotations' data using the sector 0 marker as an index point? Auto-correlate the data enough times and the signal starts to amplify and the common noise starts to diminish? Then take the AC'd output and run it though a threshold detector and then a digital state machine?

Sorry I was under the mistaken impression the drive already amplified and did binary quantization on the signal. I understand a marginal peak could flip between rotations. But that is why devices like SCP give you 5 rotations worth for each track.

Yes, it is kind-of sort-of what I resorted to with the Catweasel for hard sector disks except for the actual autocorrelation to build up a good signal to noise ratio. Instead I could use multiple track reads with varying results. Even when I could not get a full error-free track read I could usually get a sector or two to come through correctly which I would store and compare against from other track reads when that particular sector came through successfully. With enough track reads, the error variability moved around enough that I could piece together the whole track from many partial error-filled reads. Essentially most of the noise was random zero-mean junk which after enough track reads I could assemble a whole error-free track. After many reads if a sector consistently came back with an error it usually indicated a hard failure of the media which could be verified by visual inspection. Occasionally if the error was small enough I could fill in the missing bit or two and reconstruct the sector well enough to meet its checksum. I recovered hundreds of NS & VG hard sector disks this way and the archive probably exists somewhere on the internet.

Chuck(G)
September 24th, 2017, 07:48 AM
Also, if you're interested, see Phil Pemberton's DiskFerret work--he spent quite a bit of time on the data separation area.

NobodyIsHere
September 24th, 2017, 03:32 PM
I've updated the USB2FDC file set in the RBC thread. The circuit has simplified nicely and the PCB is a fairly loose but still small 6" x 5.25". Possibly could shrink further but for prototypes (if it comes to that) its better to have a "loose" board rather than everything closely packed together. I am tired of trying to convince the skeptics here so if you are interested in pursuing this option please contact me. Please note this approach is suitable for soft sector FM and/or MFM disks. Since it relies on the built in PLL data separator of the WD2793 it will not extend to hard sector, GCM, MMFM, or other exotic (but rare) formats.

https://www.retrobrewcomputers.org/forum/index.php?t=msg&th=212&goto=3525&#msg_3525