PDA

View Full Version : Can an AT FDC be persuaded to recognise jumpered Drive 0?



RickNel
May 13th, 2011, 08:59 PM
I understand that the AT floppy controller basically assumes any FDD to be drive B: (or Disk1 in Shugart terms), and drive A: is synthesized by the "twist" reversing pins 12-16 before the end connector on the connector strap.

My pair of 360kb 5 1/4 FDDs are configured, s-100 style, with jumpers setting them as disk0 and disk1, and a terminating resistor pack on disk1 . When I connect their common 34-pin cable to an AT FDC, only Disk1 (B:) can be accessed regardless of whether the strap connection is made before the twist or after the twist.

I want to be able to access Disk0 (A:)without having to pull everything to bits to reconfigure the hardware on the drives themselves.

I could draw the drive select jumpers out to a switch outside the case so that I could reverse the jumper selection remotely. The 16-pin terminating resistor pack might be more problematical to switch.

Anyone done something like this?

Rick

Druid6900
May 13th, 2011, 09:02 PM
Use an untwisted cable.

Chuck(G)
May 13th, 2011, 09:13 PM
Two signals are switched in the IBM PC style of drive connection. Not just the drive select, but the motor control (which isn't qualified by drive select) is independently handled by the twisted cable.

Since, at least in theory, the drive interface is driven by open-collector drivers, you could tie both motor lines together without harming anything--and manage the drives by drive select only. Or you could switch both motor control and drive select using a single DPDT switch.

Your choice.

Some DTC and Ultrastor controllers gave the option of using a "flat" cable, with only a single motor control line that allowed four (count 'em, four) drives on the same cable.

RickNel
May 13th, 2011, 09:20 PM
@ Druid - Thanks, but I don't think the straight cable is the answer to this problem. I already tried it before posting (see 2nd paragraph of original post). This is about the way that the AT controller identifies disks by cable twists rather than by hardware jumpered IDs.

@ Chuck - I'll look at that two-line switch option, sounds good. Since that would mean only one drive at a time, perhaps the terminating resistor won't be an issue?

Rick

Chuck(G)
May 13th, 2011, 09:50 PM
Rick - I'd probably swap the 150 ohm terminators on both drives for 470 ohm ones and leave them in on both drives.

Later drives (e.g. 1.44M) get away from open-collector drivers and use tristate buffers with a weaker pullup (e.g. 2.2K) on input lines.

"Terminator" while largely valid for things like SCSI bus and MFM hard drives; what's used on floppy drives tends to be more of a "pullup"--you need it somewhere.

modem7
May 13th, 2011, 09:52 PM
This is about the way that the AT controller identifies disks by cable twists rather than by hardware jumpered IDs.
Well, technically speaking, it's both, since in addition to the appropriate cable twist, both drives must be set to the second drive-select position. I'm sure you know that. I'm just clarifying this for later (inexperienced) readers of this thread.

MikeS
May 13th, 2011, 10:17 PM
I missed the crucial point; what do you want to do, i.e. why not just move the DS jumper on 'disk 0' to '1' as usual? Is there a reason why they have to be jumpered as 0 and 1 instead of both as 1?

RickNel
May 13th, 2011, 10:58 PM
Ok - to recap, I need to set up this pair of drives, screwed down in closed S-100 cabinet, to operate in 2 modes:

1. Normal = S100 configuration=untwisted cable, disk0, disk1+terminator/pullup
2. PC access = untwisted cable, disk1(A) or disk1(B) - PC FDC recognises disk0 or disk1 as B: according to switchable disk ID configuration.

The reason for avoiding twisted cable is to save having to physically re-plug the drive edge-connectors to switch between the states.

This limits PC access to only one drive at a time. Since the purpose of PC access is drive testing and data transfer, this limit doesn't matter.

As a first attempt, I'll leave the terminators in place on (real) disk1. If that doesn't serve the pullup function, I'll try Chuck's resistor changes. Docs on the s100 FDC controller are pretty clear that termination has to be on the last disk on the cable (as with SCSI).

When I've got it right, I'll post to the forum blog.
Rick

MikeS
May 13th, 2011, 11:36 PM
Ah, so you're using the same cabinet with an AT and an S100 system. But at some point you must have separate cables coming from the two controllers, no?

I'd think that it'd be as simple as opening up the AT FDC connector and making three changes: disconnect cable pins 10 and 14, connect FDC pin 10 to FDC (and cable) pin 16, and FDC pin 14 to cable pin 10, leaving the pull-up on drive B where it presumably is now.

Chuck? Confirm or BS?

MikeS
May 14th, 2011, 01:08 AM
Just tried it, seems to work fine. PC, straight cable, drive0=a:, drive 1=b:

Is that what you wanted?

5693

Chuck(G)
May 14th, 2011, 09:08 AM
Mike's basically got it--wire-OR the motor controls, so that a low signal on either pin 16 or pin 10 turns on the AT interface turns on both motors. Wire DSx (pin 10, 12, 14 or 6) however it suits your needs.

FWIW, there's nothing magic about drive select jumpers on floppy drives. On the drive, one side of each jumper is connected to the appropriate pin on the interface connector and the other side of the jumpers are all tied to together. So even if you had a cost-reduced modern 3.5" drive that has no DSx jumpers or switch, you could modify the cable to have the drive respond to whatever drive select your system required. In fact, you could have a single drive respond to several drive selects, but I don't know what that would get you.

Eudimorphodon
May 16th, 2011, 08:04 PM
In fact, you could have a single drive respond to several drive selects, but I don't know what that would get you.

According to my rusty memory that's exactly how Tandy wired external drives for the TRS-80 series machines. (A Tandy drive would respond to any of four drive select lines, so drive position was determined by which teeth were missing from a cable's edge connector. It accomplished the same thing as IBM's twisted cable, ie, eliminated the need to tamper with the drives when installing a new one.)

Of course, when I had my model I in the 90's I dispensed with the toothless cables and used double sided drives out of cheap government surplus 5150/5160s manually jumpered to the correct position. (At the time I could buy a two drive PC for $10. Those were the days.)

MikeS
May 16th, 2011, 08:34 PM
It accomplished the same thing as IBM's twisted cable, ie, eliminated the need to tamper with the drives when installing a new one.)Actually it's quite possible that the reason for the twist was not so much the drive select issue but the ability to turn the motors on and off independently, especially considering the marginal power supply in the original PC.

Chuck(G)
May 16th, 2011, 10:31 PM
Actually it's quite possible that the reason for the twist was not so much the drive select issue but the ability to turn the motors on and off independently, especially considering the marginal power supply in the original PC.

I've heard it posited that the original 5150 couldn't handle two floppy drives with motors on with the 63.5W PSU, but it worked just fine--and if that really was the case, the motor line control register would have been binary (i.e. 2 bits for 4 drives rather than 4), so it would be impossible to have more than one motor on simultaneously. And that requirement would have gone away with the 5160, which had a more generous power supply.

However, since IBM decided to use drives without head-load control (it was available as an option on drives very early on), I suspect the motor control was to minimize media wear.

Eudimorphodon
May 17th, 2011, 01:39 PM
Actually it's quite possible that the reason for the twist was not so much the drive select issue but the ability to turn the motors on and off independently, especially considering the marginal power supply in the original PC.

I've read the "don't have to tamper with the drives" excuse as being the reason in period literature but I've honestly always been a little suspicious of it since you still have to pull the terminating resistor pack off/install it on one of the drives. That's at least as hard as changing a jumper pin and you've opened the machine anyway.

The "no tamper" reason made a lot more sense in the TRS-80's instance. (They got around the terminating resistor issue by selling the customer a "first drive" package which came with the cable and terminating resistors installed, while additional drives were sold under a different SKU and lacked terminators. The documentation of course specificied that the "Drive 0" was special and always needed to be at the end of the cable.)

RickNel
May 17th, 2011, 06:26 PM
I've posted to my "Fumbling Forward" blog with my personal solution on this, with pictures and description of what I built.

Mike - I made a cable to your suggestion and it worked for IMD (low level) but not for 22DISK. I'm not sure what checks the PC BIOS, or 22DISK itself, might be making that tell it when a drive is ready or not for read/write ops. In any case, I opted for a physical switch on Disk Select, which serves my purposes with a standard PC floppy cable. Using standard PC FDD cable also means I only need to unplug at the drive end of that cable, not the motherboard end if using a special cable. So on balance, a kludge that works for me...

Happy that along the way I also drew out some erudite discussion of this interface :) !

MikeS
May 17th, 2011, 07:08 PM
...Mike - I made a cable to your suggestion and it worked for IMD (low level) but not for 22DISK. I'm not sure what checks the PC BIOS, or 22DISK itself, might be making that tell it when a drive is ready or not for read/write ops. That's odd... I believe Chuck has some experience with 22DISK ;-), maybe he has an insight?

Not sure I quite follow your blog, especially how you use a standard PC FDD cable (with a twist) with your S100 box, but as long as it works...

I had to resort to switches back in the days of multiple floppies and tape drives on the same port.

Chuck(G)
May 17th, 2011, 09:57 PM
Let's see your diskette.cfg file...

RickNel
May 18th, 2011, 01:51 AM
Mike - If the blog is unclear I'd like to clarify it. Can you put any queries in the blog "comment" box for me to address?

The cable situation is that untwisted=everything looks like Disk1 (B) to the PC, twisted=everything looks like Disk0 (A) to the PC. The physical switch lets me present either physical disk as Disk0 or as Disk1 to the PC, so the PC can see them one at a time, whichever cable config is presented. Since there is no difference, its just simpler to use the standard PC cable.

Chuck suggested earlier switching both DSx and MONx. I haven't needed to do that. OR-ing the motor controls makes both drives visible, but not both readable.
Chuck - I'm away from workshop at present but I'll post the diskette.cfg when I get back there.

MikeS
May 18th, 2011, 10:37 AM
Well, mainly I'm curious why switching the DSA line in the FDC cable would not work with 22disk, or how the FDC could even know that it was not the standard twisted-cable configuration.

What was a little confusing is that although you switch (swap) both drives, you don't mind being able to only use one of the two at a time with the PC.

I think maybe it's just semantic nitpicking, but I wouldn't say that "everything looks like" disk A/B to the controller; in fact with a straight cable the FDC can only use B:, and only as a drive jumpered as drive B (exactly the same as the Shugart standard as used in the S100 box) by activating motor on and drive select B.

What is non-standard in the PC is that selecting A: activates drive select C and turning on the motor activates drive select A (instead of motor on), so obviously with a straight cable it can not access any drive as A: no matter what the jumpers are set to. The twist in the cable reroutes the drive select and motor signals so that selecting A: actually accesses a drive jumpered as drive B and turns on the motor; the suggested cable mod is like a twist but accesses drive A instead of B (and parallels the motor on signal) so it should be completely transparent to the FDC.

But as I say, if it works that's all that counts.

Chuck(G)
May 18th, 2011, 10:42 AM
I'm getting very confused here--words do a lousy job of describing what's going on. How about some diagrams, at least?

MikeS
May 18th, 2011, 01:43 PM
I'm getting very confused here--words do a lousy job of describing what's going on. How about some diagrams, at least?Let's see if I got it right:

I think he made a home-made M-M gender changer for the end of the straight cable coming from the drives (jumpered as 0 and 1) into which he plugs either the straight cable to the S100 box or the twisted end of a cable to the PC.

I think the switch is a DPDT switch, one pole per drive; each common connects to one of the respective drive's DS-common jumper pins and each throw to the respective drive's DS0 and DS1 jumper pins, but opposite from each other.

Tried to draw a diagram, but...

Have I sort of got the picture?

Chuck: Any idea why the mods I suggested for a straight cable would work with IMD (and DOS) but not work with 22disk?

Chuck(G)
May 18th, 2011, 02:01 PM
Chuck: Any idea why the mods I suggested for a straight cable would work with IMD (and DOS) but not work with 22disk?

But if DOS works with both drives, the culprit must be something in diskette.cfg.

Like I said, what's actually been done is leaving me a little bumfuzzled...

RickNel
May 19th, 2011, 05:29 AM
Here's a diagram of the two cross-connect schemes. I can't see any logical reason why Mike's schema isn't working for me.

http://www.vintage-computer.com/vcforum/attachment.php?attachmentid=5948&d=1305808973

I have been able to use either a straight cable or standard PC twist cable to see one drive at a a time, so it seems that the two Motor On signals may be issued in parallel at the controller and become active when ANDed with disk select. Or perhaps MON is only issued after DS is checked. Is that a possibility?

I'm also wondering if patching MONA to MONB at pin 16 might screw up a test loop somewhere in the controller logic.

Mike - were your tests with a pair of 5.25" disks jumpered as DS0 and DS1? I'm trying to isolate any issue in the way I have built this.
I did more tests today and looked hard at the cable - there are about 8 ways to get the orientation wrong on an IDC plug.

Chuck - what "diskette.cfg" are you interested to see? Here is my cpmdisk.def module (in readable form) that works with 22Disk:

__________________________-


BEGIN IMS2 IMS 5000 CP/M - DSDD 48TPI 5,25"
DENSITY MFM ,LOW
CYLINDERS 40
SIDES 2
SECTORS 16,256
SIDE1 0 1,9,2,10,3,11,4,12,5,13,6,14,7,15,8,16
SIDE2 0 1,9,2,10,3,11,4,12,5,13,6,14,7,15,8,16
ORDER CYLINDERS
BSH 4 BLM 15 EXM 1 DSM 151 DRM 63 AL0 080H AL1 0 OFS 2
END
__________________________________________________ ____________--

Rick

Chuck(G)
May 19th, 2011, 06:57 AM
Rick, your cable looks okay for a traditional controller. [Motor On] is not conditioned on the drive select. Accessing either A or B should cause both motors to run. There is a possibility that your controller (you didn't specify what it was) is a later version that uses totem-pole outputs rather than open-collector. If that's the case a couple of general-purpose signal diodes in series with the lines coming from the PC on pins 10 and 16 should isolate the motor-control outputs, allowing either 10 or 16 to pull the motor line low. But somehow, I don't think that's what's going on if this is a vintage system. At any rate, a logic probe will tell the story.

DISKETTE.CFG talks about a special file used by 22Disk to describe unusual drive configurations (e.g. secondary controllers, oddball drives, etc.) Attached is the file that you should have as reference.

RickNel
May 19th, 2011, 04:36 PM
Thanks Chuck,

The $10 PC I'm using for this has a Gigabyte commodity P2 motherboard - I haven't checked out what FDC chip it is using but I'll do so and experiment.

So far I haven't been using any diskette.cfg file with 22disk, and since I have been able to use it effectively to access a single default drive I have not seen the need for it. I'll investigate further.

I had wondered about isolating 10 and 16 from each other with diodes - that's another think to try.

Chuck(G)
May 19th, 2011, 06:26 PM
Rick, here's something to try with DEBUG to see if the drive motors/select are working right. Note that the BIOS timer will turn the drive off after a couple of seconds. Your entries are in boldface; comments are in italic.


C:>DEBUG
-o3f2 1c should turn drive A: motor on and select the drive (LED on)
-o3f2 2d should turn drive B: motor on and select the drive (LED on)
-o3f2 0c turns both drives off
-q quits to DOS

RickNel
May 20th, 2011, 01:35 AM
Confession Time: Since my last post I have taken a giant leap backward. While running the IMD alignment test, I forgot to stop the test before flipping the DS selector switch. Both drives went into coffee-grinder mode and are no longer responding to any command past Motor On.

I've checked all the test-points and see that the control signals MON and INDEX seem to be OK, but there is no data communication with system controller - either the S100 card or a PC controller.

A scope shows only a bit of fuzz on the TP3,4 that should be the amplified differential read signal, but the units do not respond to any command after Motor On.

Chuck - running the DEBUG commands above activates motor on, but drive select is not acknowledged and no LED lit.
System boot sequence also turns both Motors On, but nothing beyond that.

I'm trying to track down schematics for the TM-100-2 controller boards - a search showed a thread a few years back where somebody had them.

Any suggestions on where to start tracking down the failures? Weird that they both went simultaneously. If its helpful, I can post a photo of the board layout.

Rick :(

Chuck(G)
May 20th, 2011, 09:10 AM
The TM-100-2 schematics are wandering around, as is the Sam's guide for it.

Let's take a look at what's happening with drive select. Basically, the drive select jumpers feed into IC 3E (a 7407), one section of which feeds one end of the activity LED; the other end of the LED is tied to +5 through R48, a 300 ohm resistor. So, if you ground pin 3 of IC3E, the LED should come on. If it doesn't, try replacing IC3E.

MikeS
May 20th, 2011, 10:09 AM
Ouch!
Hard to see how anything to do with DS or MotorOn could permanently damage both drives; you sure are coming up with mysteries ;-)

Sams:
http://members.dodo.com.au/~slappanel555/manuals/Tandon_TM100-2.pdf

All sorts of stuff (patience, site is slow):
http://maben.homeip.net/static/S100/tandon/diskette/

The most complete IMO (with notes!):
http://maben.homeip.net/static/S100/tandon/diskette/Tandon%20Tandon%20TM-100-1%20Flexible%20Disk%20Drive.pdf

RickNel
May 21st, 2011, 06:14 PM
Thanks again - I am now armed with all these docs.

Mike - re mysteries - I now believe my bad was worse. While trying cable configs, I think I mistakenly installed a whole strap upside down - that is, a 34-pin "twist" which among other things would have cross-connected MonA to Trk0, MonB to Step, DSA to Wdata, DSB to WrEn. Hence the "coffee-grinder" drive responses?

Chuck - by your suggested test 2E is OK, the LED comes up when grounded.

Armed with the SAMS docs, I followed their test sequence for "read fail" and it seems all the data read section checks out OK.

If the problem is in the step-motor control section, then initialisation would fail, hence no drive ready. I'll check through that section next time I get to the bench.

MikeS
May 21st, 2011, 06:28 PM
Thanks again - I am now armed with all these docs.

Mike - re mysteries - I now believe my bad was worse. While trying cable configs, I think I mistakenly installed a whole strap upside down - that is, a 34-pin "twist" which among other things would have cross-connected MonA to Trk0, MonB to Step, DSA to Wdata, DSB to WrEn. Hence the "coffee-grinder" drive responses?Still odd; since everything is open-collector it's pretty foolproof even if you ground signals or connect outputs together. Have you tried just getting one drive working with the other completely disconnected?

We should have followed the If It Works Leave It Alone principle... ;-)

Good luck!

Chuck(G)
May 21st, 2011, 07:46 PM
Chuck - by your suggested test 2E is OK, the LED comes up when grounded.

Armed with the SAMS docs, I followed their test sequence for "read fail" and it seems all the data read section checks out OK.


Uh, there's something else going on. The DSx pins are connected right to the input side of IC3E driving the LED. If the LED doesn't come on when you access it, the problem is further upstream.

RickNel
May 22nd, 2011, 06:46 PM
I've come back to thinking I need to replace IC 3E on both drives.

I tracked through data read and motor control circuits and everything was within spec up to any point where a signal is tied to Disk Select ("out" on the SAMS schematics). I realised Disk Select was not being propagated from 3E, the 7407 hex buffer right at the connectors.

The DS signal is supposed to go low (true), but stays high. Signals coming from the controller are conditioned with pull-ups of 5v through 150-300ohm resistors, so if one of those resistors is shorted, the signals could be held high. I didn't find any shorted resistors, but I might have missed something so haven't ruled that out completely. I can't work out why the activity LED doesn't light up when earthed at 3E pin 4 - unless those LEDs have also been blown through over-load somewhere along this sorry saga.

Meantime I've ordered some 7407s (parts are hard to find here), so the project goes to back-burner till they arrive - 2 weeks or more.

Rick

RickNel
July 24th, 2011, 08:39 PM
I'm bumping this just to confirm that I have got the "Mike's Twist" patched 34-pin cable to work as described and found what was stopping it on my hardware.

I had made 3 different hardware errors that blocked the signals in different ways - probably the buffer chips were OK all along.

Thanks Mike and Chuck for pointing to the working solution to my original post.

For any interested in the build process and my errors and corrections, I've posted the details in the "Fumbling Forward" blog on this site.

Rick

MikeS
July 24th, 2011, 10:05 PM
Thanks a lot for the follow-up, Rick; so often you spend time on someone's problem and never know how it finally turned out (not to mention that a "thanks" is always appreciated ;-) ). The 'drive swap' switch is a good idea in any case; as a matter of fact I had one of those in one of my old PCs before BIOSes had a swap option.

You know, when we talked about this back in May I started wondering why you couldn't just effectively parallel the two computers and I was actually going to try it (but of course never did ;-).

Chuck, are ya reading this? Am I once again missing some crucial aspect or could you indeed just connect the two controllers and drives together? I kinda envision a male bulkhead header connector crimped in between the S100's controller and drives and mounted on the back panel, and a modified cable from the PC to that connector.

Chuck(G)
July 24th, 2011, 10:20 PM
Chuck, are ya reading this? Am I once again missing some crucial aspect or could you indeed just connect the two controllers and drives together? I kinda envision a male bulkhead header connector crimped in between the S100's controller and drives and mounted on the back panel, and a modified cable from the PC to that connector.

If you have SA-400 conforming drivers (i.e. open-collector 7438 type, pulled up with 150 ohms) and you can coordinate access such that only one controller has a drive select active at any time, then it should work.

Of course, what I just said is the problem if you want to share drives between two active computers, you have to figure how to coordinate accesses; not just one system accessing at any one time, but also both systems knowing what cylinder the drive heads are on, etc.

The other issue is that when you get into the arena of modern controllers, where the controller is on someone's "Super I/O" chip, the drivers are often three-state, not OC, which can lead to some issues if you don't have accesses precisely coordinated.

MikeS
July 25th, 2011, 11:25 AM
Yeah, I'm of course assuming 'vintage' open-collector drivers all around and keeping activity completely separate on the two machines, but given that, I don't see why you couldn't just plug the AT into the back of the S100 box and leave it plugged in; CTL-C should reset CP/M's logical drives and since there's no DC signal the AT should also be able to reset and keep track of where it is.

Shouldn't be any different from hot-swapping the cables with the present setup.

But don't blame me if you try it and it scrambles a crucial disk, Rick ;-)

Chuck(G)
July 25th, 2011, 01:12 PM
Mike, that would be an interesting retro project--shared storage among several systems with different architectures via the floppy. Sort of a poor man's network. You'd need some way to coordinate things, say with an RS-232 link, or maybe you could repurpose a line in the connection (e.g. write protect) to do signalling.

RickNel
July 28th, 2011, 04:08 PM
Not sure that I'm ready to tempt fate again just yet, but "hypothetically"...

Maybe sharing access to the drives on Mike's model could be as simple as inserting tri-state buffers at the point of interconnect, such that MON and DSx would not be visible to the external machine if the drive was active on the internal machine, and vice-versa? Or some other XOR logic. You might only need it on the DS lines, so drive B could be driven by a PC while drive A was busy talking to momma. Then everybody could share that massive 300k storage medium!
Rick

Chuck(G)
July 28th, 2011, 04:20 PM
Rick, as I said if it's a standard SA-400 type of interface, you can share drives without special circuitry. All outputs are open-collector with passive pullup, so it doesn't matter who's driving them.

MikeS
July 28th, 2011, 05:51 PM
Rick, as I said if it's a standard SA-400 type of interface, you can share drives without special circuitry. All outputs are open-collector with passive pullup, so it doesn't matter who's driving them.Yeah, I'm not sure we're on the same page, Rick; I don't think it'd be feasible to actually access the drives simultaneously from both computers at the same time without some pretty fancy switching logic, but as long as you take care to only access the pair from one computer or the other (as you do now) it should be possible to connect the two computers and the drives together in parallel with only a compatible male header plug and not have to unplug and plug the two cables every time you switch computers.

I think I may try this myself; it'd make it really convenient to archive or recreate & test diskettes from the same PC/terminal emulator, especially since my S100 systems have both 5.25DD and 5.25HD emulating 8" on the same cable.

RickNel
July 31st, 2011, 04:33 PM
I'll be interested to hear how you go with that, Mike.

I was thinking that if you had two powered-up FDD controllers in parallel with one set of FDDs, the patch in your "twist" cable that puts AT pin 16 to Shugart pin 10 might tell a Shugart controller that both DS0 (FDD A) and DS2 (FDD C) were selected simultaneously. With a flat cable without that patch, as we know, you would have AT controller access only to DS1 (FDD B), though you could use a hardware A~B switch solution to compensate for that.

Again, maybe it would be enough to make sure that none of your drives were hardware-configured to DS2, but I'm not sure about what feedback you would get on other signal lines with two controllers in parallel.

That's why I was thinking that some quite simple XOR logic on DS lines, such as tri-stating buffers enabled by the MON lines from each controller, would permit permanent parallel hardware connection, but prevent a controller from seeing a drive's DS so long as there was an active MON generated by the other controller.

A drive in use (MON low) would become available (by showing its DS) to the other controller only after completing the current operation and MON going high. Sort of like a COM port ready protocol.

Am I overlooking some other complexity?

Rick

Chuck(G)
July 31st, 2011, 05:48 PM
Consider this, remembering that all output signals are OC. Take the PC Floppy cable (http://pinouts.ru/Storage/InternalDisk_pinout.shtml) and lift the wire on pin 10 (MTR A) and connect it to pin 16 on your box's connector (http://pinouts.ru/Storage/5_12_floppy_pinout.shtml) (MTR B), leaving the wire already there connected (i.e. parallel them) to form MTR ON).

Finally, take the wire from pin 14 (SEL A) and connect it to pin 10 (DS 0) on your box's connector.

Thus, either motor signal from the PC will cause both drives to come on; drive A: will be the drive with DS0 jumpered and drive B: will be the drive with DS1 jumpered.

This essentially converts your PC to a "flat" cable interface.

MikeS
July 31st, 2011, 08:09 PM
<snippage>
This essentially converts your PC to a "flat" cable interface.I think we're going around in circles; didn't we just discuss all this complete with a picture way back in posts # 9 & 10?

@Rick: sorry, I don't follow your reasoning at all; controllers are the source of the DS and MON signals, they can't "see" it; DS2 (pin 14) is not connected at all to the AT controller (the cut wire in the picture) and only the AT controller knows that its pin 10 is connected to pin 16, so none of this is visible to the S100 controller & drives.

AT DS0 (pin14) connects to S100 drive & controller DS0 (pin10)
AT DS1 (pin12) connects to S100 drive & controller DS1 (pin12)
AT mutually exclusive MON0 (pin10) and MON1 (pin16), both connect to S100 drive & controller MON (pin16)

As long as you don't decide to use the drives at the same time from both computers, what's the problem?

I suppose you could cobble up some kind of mutual exclusion logic if you don't trust yourself to only use one computer at a time, but that's a little more than the simple addition of a connector that I was thinking of.

Chuck(G)
July 31st, 2011, 08:23 PM
Yeah, Mike, we've been here. I'm trying to convince Rick that the setup requires no additional active logic--it's basically a wiring problem.

RickNel
August 2nd, 2011, 06:50 PM
Right - I'm fully convinced now that the parallel hardware link will be OK without extra active logic, so long as the human "controller" is foolproof and doesn't ever let two machines try to access the same drive simultaneously - eg. have one machine trying to boot from FDD while the other is reading a directory. In Mike's proposed scenario (where he has a HDD masquerading as an 8" floppy) some disk operations could be quite long enough for the operator's mind to wander....

I have proven myself more than capable of that kind of error, so it will probably feel safer for me to maintain the mutually exclusive access to FDDs by physical plugging, unless the challenge of an active logic sharing solution nags at me.

On active logic - although Chuck and Mike have both said my controlled buffer proposal is not necessary (because you can rely on the human operator), do you have any comment on whether it would actually work, or if there is a better way than tri-state buffering, to isolate MON and/or DS signals from one controller when the drive is being accessed by the other controller?

Rick

Chuck(G)
August 2nd, 2011, 07:34 PM
On active logic - although Chuck and Mike have both said my controlled buffer proposal is not necessary (because you can rely on the human operator), do you have any comment on whether it would actually work, or if there is a better way than tri-state buffering, to isolate MON and/or DS signals from one controller when the drive is being accessed by the other controller?

Why do you care? Remember that the logic is open-collector, so there's no active pullup. There may be confusion between the systems driving things, but there will be no physical harm.

MikeS
August 2nd, 2011, 09:02 PM
Why do you care? Remember that the logic is open-collector, so there's no active pullup. There may be confusion between the systems driving things, but there will be no physical harm.I don't get it either; even if, how would you actually isolate them without pretty well multiplexing all the signals? What will isolating DS and/or MON signals accomplish? System A selects the drive and reads/writes away merrily; system B selects the drive and even though its DS and MON signals go nowhere, the drive is selected anyway by system A and system B happily tries to read/write, step etc.

I suppose you could isolate the two MON signals with a pair of diodes and use them to gate the other system's INDEX line.

But yes, physically swapping cables will certainly prevent any interaction ;-)

RickNel
August 4th, 2011, 04:45 PM
Thank you again, Mike. That's the sort of logical gating I was thinking about, but hadn't thought laterally enough. If system B is prevented from reading the INDEX pulse from a drive that is in use by system A, then system B's controller will return "Drive not ready" instead of proceeding to send conflicting signals to the drive.

Rick

Chuck(G)
August 4th, 2011, 05:09 PM
I'll throw a cockroach into the spaghetti.

I haven't checked with the datasheets for the WD17xx series of controllers, but the PC NEC 765-type controller doesn't need an index signal for anything but formatting. One of the old tricks for dealing with alien-format floppies that omit the IAM on the 765 was to isolate the index input to the 765 (i.e. make it NC), so that index pulses didn't cause the 765 to go "blind" for 500 Ásec. during the "PLL sync" time. The only operations that require an index pulse on the 765 are Format track and Read track because the controller needs to know where the track starts. Otherwise, not needed.