Apple SmartPort Pin Directions
How can you deal with signals that might be inputs or might be outputs, in a way that’s safe and won’t damage sensitive electronics? In my last post I described three different types of Apple II family floppy drives. Since then, I’ve started looking further into SmartPort emulation for the Floppy Emu, which would extend 800K floppy and hard drive emulation support to the Apple IIc and IIgs. The required pinout on the D-SUB 19 pin connector is almost the same as what’s currently used by Floppy Emu, but not quite identical (inputs to the computer marked in bold):
| Pin | Floppy Emu | Macintosh | Apple II+/IIe | Apple IIc | Apple IIgs |
| 1 | GND | GND | GND | GND | GND |
| 2 | GND | GND | GND | GND | GND |
| 3 | GND | GND | GND | GND | GND |
| 4 | GND | GND | GND | GND | /3.5DISK * |
| 5 | N.C. | -12V | -12V | -12V | -12V |
| 6 | +5V | +5V | +5V | +5V | +5V |
| 7 | N.C. | +12V | +12V | +12V | +12V |
| 8 | N.C. | +12V | +12V | +12V | +12V |
| 9 | N.C. | N.C. | /ENABLE2 | /EXTINT | /ENABLE2 |
| 10 | PWM | PWM | WPROT | WPROT | WPROT |
| 11 | PHASE0 | PHASE0 | PHASE0 | PHASE0 | PHASE0 |
| 12 | PHASE1 | PHASE1 | PHASE1 | PHASE1 | PHASE1 |
| 13 | PHASE2 | PHASE2 | PHASE2 | PHASE2 | PHASE2 |
| 14 | PHASE3 | PHASE3 | PHASE3 | PHASE3 | PHASE3 |
| 15 | /WREQ | /WREQ | /WREQ | /WREQ | /WREQ |
| 16 | SELECT | SELECT | +5V | N.C. | SELECT * |
| 17 | /ENABLE | /ENABLE | /ENABLE1 | /ENABLE | /ENABLE1 |
| 18 | RD | RD | RD | RD | RD |
| 19 | WR | WR | WR | WR | WR |
Comparing the Floppy Emu pinout to the IIc and IIgs, a few pins must change from computer outputs to computer inputs. And a few other pins marked with * take on a new bidirectional behavior, being used both to control the floppy drive and to sense the type of the connected drive. All the non-power pins for Floppy Emu are connected to a CPLD, and can be switched from inputs to outputs with a firmware change, so by itself that’s not a problem. The trouble arises if you want to use a single Floppy Emu board on different computers at different times, functioning in different modes. If the Emu is configured for the wrong mode for the computer it’s presently attached to, it could damage both the Emu and the computer. Sooner or later somebody (or me) would make that mistake.
Let’s look at what this means for SmartPort emulation on an Apple IIc or IIgs. On the IIgs, pin 4 is no longer a ground pin, but instead is used to switch between Apple 3.5 drives and other types of drives. We’re not trying to emulate an Apple 3.5 drive yet, so we can safely ignore that difference and continue to use pin 4 as GND. On the IIc, pin 9 is an external interrupt. We don’t need that for SmartPort emulation, which is fortunate because it’s not even connected on the Floppy Emu end.
Pin 10 is the main problem. On the Mac, it’s an output from the computer, but on the whole Apple II line it’s an input. It either indicates the disk’s write-protect status (normal disks), or serves as an ACK signal (SmartPort). If the Floppy Emu is configured to output a WPROT or ACK signal on pin 10, and is connected to a Mac that outputs PWM on pin 10, the two chips will fight each other and cause damage. Zap!
Pin 16 is also a problem. On the Mac and the Apple II/II+/IIe, it’s either an output from the computer, or a +5V connection that will look like a constant logical 1 output. But a SmartPort device turns things around, and uses pin 16 on its daisy-chain port to determine if the next device in the chain is also a SmartPort device. It has an internal pull-up on the daisy-chain pin 16, and it checks the value on that pin. If it sees 0, that means the next device is also a SmartPort device, and if it sees 1 it means it’s not a SmartPort device or there is no device present. The IIgs may behave the same way, although I’m not sure. So in order for Floppy Emu to be detected as a SmartPort device, it may need to output 0V on pin 16. That’s another potential for two chips fighting. Zap again!
Playing It Safe
The question is how to make an Apple II SmartPort mode firmware for Floppy Emu, while avoiding potential electrical damage if you accidentally set the wrong mode on the wrong computer.
Caveat Emptor – I could do nothing. As long as you switched into Apple II mode after connecting the Emu board to an Apple II, and switched into Mac mode before disconnecting from the Apple II, you would never have two chips fighting on the same line. But that’s a poor solution. What if you borrowed a Floppy Emu from a friend for use with your Mac, and you didn’t know what mode it was in? Or you just plain forgot?
Physical Adapter – I could build a small passive adapter that sits between the computer and the Floppy Emu board. An inline resistor of about 100 to 330 ohms on pin 10 should prevent possible damage if two chips were fighting. The same solution would probably also work on pin 16, although correct functioning would depend on the value of the SmartDisk pull-up resistor and the logic threshold of the chip it used to sense the value of pin 16. But I’d really like to avoid requiring an adapter if I can. It would be so much nicer if you could just plug your Floppy Emu straight into your IIgs or IIc and have it work.
Detection – Maybe I could somehow detect whether the attached computer is an Apple II or a Mac, and only switch pins 10 and 16 to outputs after confirming it’s an Apple II. That sounds good, but how? Is there a way with the existing hardware that the CPLD could tell if pin 10 is being actively driven with some value, instead of just floating? Or maybe try to detect a SmartPort reset state before switching the pin directions? I’m not confident the SmartPort reset state won’t also be triggered accidentally by Mac drive logic like the HD20 control routines.
Button Push – I could require the user to push a button to “confirm” Apple II SmartPort mode, each time the Emu board was reset, before switching the pin directions. That would be a little inconvenient, and would still have some potential for damage if you pressed the confirmation button when you shouldn’t have. But it’s the best solution I’ve thought of thus far.
Read 7 comments and join the conversation7 Comments so far
Leave a reply. For customer support issues, please use the Customer Support link instead of writing comments.
You could also:
1. Make Two different Floppy EMUs
2. Make a Deluxe Floppy EMU with two DB-19s(One on each side)
3. Add a physical switch
Yeah, those are kind of the in the same boat as a physical adapter. I’d really like to do something that works for people who already have the Floppy Emu, with the current hardware, and no adapters needed. But maybe that’s not realistic, and an adapter wouldn’t be the end of the world if it were small and cheap.
What’s the behavior of the PWM signal on pin 10 that the Mac outputs? If you can count on it toggling at power on, I think you could create logic in the CPLD to detect if a Mac is present or not. I’d suggest configuring pin 10 as a tri-state, bidirectional IO in the CPLD with an internal pull-down. Then, set the default state of the IO at reset to be tri-state (output buffer disabled), and sample the input signal in the CPLD. If you see a 0 to 1 transition (or several of them), then you can assume that a Mac is connected and is driving the pin. Use that determination to set an internal signal indicating you’re operating in ‘Mac Mode’, and use that signal to customize any other behavior necessary.
I’m not sure about pin 16 – I’d need to think about that some more.
I’m a little worried about pin 4 too. Your table indicates that it’s an output from the IIgs, used to switch between 5.25 and 3.5 inch floppy modes. If that’s the case, then there will be times when the computer tries to drive that line high – but it’s a GND on the Floppy Emu side. Even if that didn’t cause any damage to the computer, it seems like it could cause functional issues (if not now, then certainly in the future if/when you add 3.5″ support). I don’t have any background on the floppy interfaces or protocols, so I’m not sure.
Good ideas, Mike Everhart. Pin 4 should be safe – I read somewhere that the IIgs has a built-in inline resistor on that pin, for exactly the reason you mentioned. 19-pin 5.25 drives like the Apple 5.25 drive have pin 4 connected to GND internally, and can still be connected directly to the IIgs.
Testing for a toggling behavior on pin 10 might work, and could be used to switch the direction of pins 10 and 16. I’d need to look at it on a scope. One concern is that I’m fairly sure the PWM toggling won’t begin until after the Mac finishes its RAM check (if not even later), which can take as long as a minute or more on some systems. So during that period, the Emu might incorrectly conclude the computer was an Apple II. So while toggling could be a positive indicator for Mac mode, I think lack of toggling isn’t necessarily a positive indicator for Apple II mode.
Unfortunately the XC9572XL CPLD on the Emu board has no options for configurable pull-ups or pull-downs. So with an Apple II, reading pin 10 would be reading a floating input. I think the CPLD may have a “keeper” setting for inputs though, which might be almost as good.
With the keeper pin 10 would only appear to toggle if it was actively driven in a toggling fashion. On power-up the CPLD actually has a pull-up on the pin before the keeper activates, so if the computer was using pin 10 as an input, it would see it as high until the CPLD’s pin’s output enable activates.
Could you defer the mode of pin until after you detect a step pulse? Surely the PWM is active during the head seek to find track 0 and it wouldn’t make sense to attempt a write operation without knowing the head position first.
Yes, I can defer switching the pin mode until some positive “this is an Apple II” indicator appears. But a step pulse on pin 10 is a positive “this is a Mac” indicator. I could wait some period of time, and if no step pulse is observed during that time, conclude it’s an Apple II. But that method could fail if a Mac took an extraordinary long time to complete POST at startup (some take over a minute), or if the Emu board were reset while the Mac was already on and no disk activity was occurring. I need to find a positive indicator for the presence of an Apple II, but short of adding some new external hardware, I haven’t been able to think of one.
Hello,
I use Teac55 GFR drives (34pin) on one cable.
Is it possible, to connect the emulator on the 34pin cable parallel to one drive and use the drive select.
Or do I need a Apple disk controller with 20 pin connector?