Nonsensical floppy setup

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
User avatar
mystran
Member
Member
Posts: 670
Joined: Thu Mar 08, 2007 11:08 am

Nonsensical floppy setup

Post by mystran »

Ok, so I'm trying to come up with a sane floppy driver.

For all practical purposes, I don't think I have any problem supporting drive0 in "primary" controller.... but...

What is this nonsense: commands to controller allow selecting one of 4 drives. In addition to this, several docs mention two IO addresses for two controllers, primary and secondary...

So... mm.. is this like 4 drivers per 2 controllers? Or is this like 1 driver/controller, and one just have to "know" where something is?

Like, if I want to support two drives, do I access them both with the primary controller, or am I supposed to access fd0 with primary, and fd1 with secondary controller?

...

Most simple drivers only deal with drive 0 in primary controller, and the less simple driver I found in Linux is a total mess (and actually has a comment telling it's a total mess).

...

Not that I can think of very good reasons why I would like to support more than one floppy (since floppies are almost dead) but...
The real problem with goto is not with the control transfer, but with environments. Properly tail-recursive closures get both right.
User avatar
Brendan
Member
Member
Posts: 8561
Joined: Sat Jan 15, 2005 12:00 am
Location: At his keyboard!
Contact:

Re: Nonsensical floppy setup

Post by Brendan »

Hi,
mystran wrote:What is this nonsense: commands to controller allow selecting one of 4 drives. In addition to this, several docs mention two IO addresses for two controllers, primary and secondary...
I think modern floppy controller chips were originally designed to support up to 4 floppy drives on a single cable (where the controller can control one of those devices at a time). However 80x86 PCs have only ever been wired to handle 2 devices on a cable.

It is entirely possible to have 4 floppy controllers with 2 devices each in the same system. It's very unlikely that anyone actually does now, but before CD-ROM was invented and software was being distributed on floppy disks these machines were more common (imagine creating 1000 copies of a piece of software that fits on 5 floppies).

Because the floppy controllers existed before plug & play, etc the first 2 controllers were assigned "standard" I/O ports, IRQs, etc. Other controllers used non-standard I/O ports, etc.

Also, there are other devices that can be connected to the floppy drive controller. Tape backup units are the main ones, but there were (Iomega) "zip" disks (which are/were like removable hard disks) and possibly other devices. There was/is also a higher capacity floppy disk format (marketted as "2 MB", but actually 2880 KB AFAIK - you'll see something called "perpendicular mode" in some of the floppy controller datasheets for this).

For a modular OS, I'd recommend having a "floppy controller driver" and seperate "floppy device drivers" (e.g. one for 1440 KB drives, one for 1200 KB drives, one for 2880 KB drives, one for each type of tape backup, one for those "zip" disk things, etc).
mystran wrote:Like, if I want to support two drives, do I access them both with the primary controller, or am I supposed to access fd0 with primary, and fd1 with secondary controller?
That depends on how the computer itself has been configured. One device per controller is obviously better (as each device can be used independantly), but modern computer retailers have tight profit margins and are more likely to put both floppy devices on the same controller to save themselves the cost of a $2 cable. ;)

There may be a way to determine if a device is connected (e.g. send it a "recalibrate" command and see if you get a time-out), but AFAIK there's no way to determine what sort of device it is. There are BIOS functions to determine what sort of device is where (which rely on settings from the user that are stored in the CMOS), but these are mostly crap (the functions don't support the variety and number of devices that could be present, and are mostly obsolete now).

This basically means you need some sort of configuration file that the OS uses to figure out what is where (e.g. a text file that includes information on which devices are connected to each controller, and the I/O ports, etc for non-standard floppy controllers).

An alternative would be to say the OS only supports systems with none or one 1440 KB floppy drive connected to the primary controller. This is avoiding the issue rather than solving the issue (but should be adequate for most modern computers).


Cheers,


Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
User avatar
mystran
Member
Member
Posts: 670
Joined: Thu Mar 08, 2007 11:08 am

Post by mystran »

Hmmh. I'm going to do the following then:

First I'm going to support one 1440 drive as the first drive of the first controller, detecting this by asking CMOS (reliable as hell, I guess, but better than nothing). Probably only 1440 disks as well at first.

After that works, I'm going to figure out how to detect 5.25" drive as the second drive of the first controller. I'd guess I just assume CMOS knows again. I have one such drive somewhere so I can test with real hardware.

Seriously though, once I've got one drive working, I guess I'll forget it for some time, and implement more interesting stuff like harddrives.

Anyway, thanks for the info. I'd guess that since almost any modern motherboard has exactly one connector for floppy drivers, there's also exactly one controller for floppy drives, and as such on modern machines it's probably waste of time to go to the trouble of figuring out how to support more. Maybe when I've got USB storage drivers working... :)
The real problem with goto is not with the control transfer, but with environments. Properly tail-recursive closures get both right.
Post Reply