• Please review our updated Terms and Rules here

Linux/BSD for 4 floppy drives

SpidersWeb

Veteran Member
Joined
Feb 16, 2012
Messages
2,701
Location
New Zealand
Just after some suggestions here, I'm planning to use a 386 or 486 (or whatever is needed) + primary and secondary (separate) floppy controllers.
Ideally I want to be able to:

- ssh or telnet in
- support the secondary floppy controller
- be able to "dd" raw images to various formats
- able to access or provide a network share accessible by either Windows or newer Linux systems (probably Ubuntu)

I haven't picked or built the hardware I want to use yet, just want an idea of OS options and also if anyone knows of any information regarding a secondary controller.

It's not something that's necessary, but I figured it'd be a fun project. I've got 5.25 DD 40 + 80 track, 5.25HD, and 3.5HD drives to put in.
 
Of course after posting that, I immediately discovered afterwards that you can add floppy=two_fdc to LILO for most distro's in that era and get 4 floppy support.

But still after recommendations.
An added bonus for me, would be being able to write 3.5" DD disks double stepped too (yey IBM PC JX). I know some of the older distro's had a /dev/fd entry for each format type - not sure if that'd help or not.
 
Are you sure that the JX double stepped? I thought it single stepped out over 40 tracks before stopping leaving the other 40 tracks unused.
 
Using Linux "dd" would be extremely limiting. You would only be able to write 100% compatible 1.44mb, 1.2mb, 720k, and 360k disk images. I'd be very surprised if 160k, 180k, 320k, or DMF formats would work.

If you really need to run headless, you might consider using DOS with something like PC Anywhere. That should let you run tools like ImageDisk, Teledisk, or Copy II PC. (Have not actually tried that, some tools may prevent serial or network I/O during operation). If that worked, it would give you access to many more disk formats and even some copy protected formats. Although if you are dealing with copy protections, a Kryoflux or SuperCard Pro is recommended.
 
Are you sure that the JX double stepped? I thought it single stepped out over 40 tracks before stopping leaving the other 40 tracks unused.

Yes, can absolutely 100% guarantee it's double stepped. I had to make my own boot disks to get my JX running.
I guess being 1984 they were imitating how the IBM AT wrote 360KB disks.

A later (1986 or 1987?) BIOS update allowed full 720K access, I do have another JX system with that ROM installed.

Using Linux "dd" would be extremely limiting. You would only be able to write 100% compatible 1.44mb, 1.2mb, 720k, and 360k disk images. I'd be very surprised if 160k, 180k, 320k, or DMF formats would work.

If you really need to run headless, you might consider using DOS with something like PC Anywhere. That should let you run tools like ImageDisk, Teledisk, or Copy II PC. (Have not actually tried that, some tools may prevent serial or network I/O during operation). If that worked, it would give you access to many more disk formats and even some copy protected formats. Although if you are dealing with copy protections, a Kryoflux or SuperCard Pro is recommended.

Cheers for the feedback. I can probably live with those drawbacks if necessary. 99% of the time it's just things like DOS boot disks, or writing images of software that I own but the disks have gone sour. I'd like to push it as far as I can but ultimately it's just a fun excuse to build a semi-vintage 'nix based system that'll serve some purpose in the workshop.

I'll also get some geek joy out of writing scripts to improve the process. For special cases I can pull out a PC with DOS.

Edit: oh and headless isn't necessary. I kind of just realised I don't want to have to walk across the room each time I change a disk - so I'll just put it under the workbench and hook it to the KVM.
 
Last edited:
In theory, you could run DOSEMU on the machine and allocate access to the IO ports that the internal drives, and the drives hooked up to the secondary controller are attached to. This is assuming that both fake floppy drives are disabled in DOSEMU. However, you will need to load a TSR that simulates your usual INT 13h handler and uses the same port areas while also supporting more than two floppy drives.

DOSEMU is laughably worser than DOSBox at this point, but at least this suggestion could be given a try.
 
I can tell you that it's more complicated than that. Many of the direct-hardware packages (TD, IMD) are also timing-sensitive. Anything that steals time slices is going to bollix things up.
 
I can tell you that it's more complicated than that. Many of the direct-hardware packages (TD, IMD) are also timing-sensitive. Anything that steals time slices is going to bollix things up.
Funny that I just had that realization 10 minutes before I read your post. The only thing that I can think of now when it comes to using low level imaging for 5.25 drives on a 486 Linux computer is a Catweasel card. You can use the special low level writing tools, but reading and writing on high level is pretty limited; http://www.soundtracker.org/raw/cwfloppy/index.html
 
Linux supports virtually all possible floppy formats available for 82x72 floppy controller (FM and MFM).
There is fd-utils package:
https://fdutils.linux.lu/
https://fdutils.linux.lu/disk-id.html
It allow to use floppy controller directly and setup 82x72 parameters: number of sectors, tracks, floppy density, track gaps e.t.c. e.t.c.
You can also use pre-defined floppy formats in /dev

Unfortunately, most of modern Linux dictributivers has no this package (or limited amoutnset of utilities) and it shoud be compiled locally.
 
Unfortunately, it seems that mtools, as well as the regular floppy support in x64 Ubuntu is seriously broken. I've never gotten it to work on my system (currently 17.10). Usually the tools die with an error or simply hang, leaving the drive inaccessible.

I've read the various error reports and the attitude is "Who the heck is so backward to use floppy disks?"

I've had somewhat better results with BSD, but it's far from perfect.

Heaven help you if you are trying to get a floppytape drive (e.g. Colorado Jumbo) going on modern Linux. Not that floppytape support was that great even 10 years ago.

Just my experience.
 
Cheers guys.

fdutils looks good, and I experimented in a virtual machine last night and did a bit more digging on the predefined formats - which may cover almost everything I need by themselves (although I will compile in fdutils). One thing I'm curious about is the 360/720 format - which could be either 40 track double step, or 40 tracks in a row. I don't know what "stre" is, but it's 1 for both 360/1200 and 360/720. Not that it really matters, as long as 360/720 or 360/1200 causes the drive to double-step - that's good with me.

Code:
#		size sec/t hds trk stre gap  rate spec1 fmt_gap
360/360		 720     9   2  40    0 0x2A 0x02 0xDF     0x50
1200/1200	2400    15   2  80    0 0x1B 0x00 0xDF     0x54
[B]360/720		 720     9   2  40    1 0x2A 0x02 0xDF     0x50[/B]
720/720		1440     9   2  80    0 0x2A 0x02 0xDF     0x50
720/1440	1440     9   2  80    0 0x2A 0x02 0xDF     0x50
360/1200	 720     9   2  40    1 0x23 0x01 0xDF     0x50
720/1200	1440     9   2  80    0 0x23 0x01 0xDF     0x50
1440/1440	2880    18   2  80    0 0x1B 0x00 0xCF     0x6C

Also noticed there is heaps of support for weird formats, from the CoCo to the Commodore 1581. Pretty neat.

Unless someone has a better suggestion, my current plan is an early-ish Pentium with ISA + RedHat 7.1 (Kernel 2.4.2). Just need to see what I can dig up.

Chuck - yeah no plans to use a modern distro for this. Seems a bit rubbish that they leave broken code in there - should be maintained or removed.
 
Last edited:
Just had a read of floppy.c

360/720 is for reading a DSDD disk in a DSQD drive - so it's 40 track, 300rpm and double stepped - perfect.

Honestly I'm quite surprised, I figured I was going to end up needing to use a much older release.
 
Unfortunately, it seems that mtools, as well as the regular floppy support in x64 Ubuntu is seriously broken. I've never gotten it to work on my system (currently 17.10). Usually the tools die with an error or simply hang, leaving the drive inaccessible.
I've never even got it working on DeLicate Linux either. Trying to format a 360k drive gives me errors off the wazoo, if I dare even specify the correct format.
 
My main PC runs Ubuntu 16.04 LTS, and I have had mtools working successfully with a 1.4M 3.5" floppy drive - though the last time I tried it didn't work and I had to use a tweener system (I expect rebooting would have fixed it). Programs that directly access the FDC, like libdsk, sometimes work when mtools isn't so happy.
 
Back
Top