Floppy Emu Update: Smartport Daisy-Chain Support
As of today, the BMOW Floppy Emu disk emulator now offers two different firmware versions for Apple II users: a normal version and a Smartport daisy chain version. You’ll find them both in the Firmware Downloads section of the Floppy Emu project page. Most people should use the normal firmware version, and it’s the default for newly-purchased hardware. The Smartport daisy chain firmware version is only needed in uncommon situations when:
AND
2. The Floppy Emu is plugged into the back of a BMOW Daisy Chainer or to the Apple Unidisk 3.5 drive, A2M2053.
If in doubt, get the normal version. You can switch freely between versions as needed. There’s no harm in using the “wrong” version, but some disk emulation details may not work as expected, and the normal version offers a higher level of protection against misconfigured disk drives. If you don’t care about the gory details, then just install the version you need, and have a nice day. But if you enjoy learning about low-level disk voodoo, read on.
Why Two Firmware Versions?
Why are there two different firmware versions? Why not have one version, with some kind of user-selectable option for Smartport daisy-chaining? That would surely be more convenient, but it wouldn’t do the job that’s required here. The essential difference between these two firmware versions is the default power-up configuration of Floppy Emu’s CPLD chip, before the Emu’s on-board code has even begun to run. By the time that code could check a user option and decide how to change the configuration, the critical moment where the configuration is relevant would have already passed.
The difference is specific to a disk I/O signal named SELECT. With the normal firmware, SELECT is always configured as a CPLD input, and an external measurement will appear to show a floating voltage. But if using the Smartport daisy chain firmware, SELECT is initially configured as a pull-down: an output driving a logical zero value. It’s later reconfigured as an input, or not, depending on the Floppy Emu’s selected emulation mode. This is necessary in order to support detection of daisy-chained Smartport and Unidisk 3.5 devices, when other devices of the same type check for daisy-chaining at power-up. This scenario is fairly rare: it only happens when two intelligent Smartport devices are daisy-chained together, and Floppy Emu is the second device. That’s what conditions 1 and 2 above mean. When Floppy Emu is the sole Smartport device, or its selected emulation mode is 3.5 inch or 5.25 inch floppy rather than Smartport, then the normal firmware is the way to go.
The Tale of SELECT
What’s all this business with SELECT? Isn’t it a bad idea to dynamically reconfigure an input as an output? I agree it seems dubious, but that’s Apple’s design. I discussed the mechanism in more detail a few years ago here. In brief, SELECT is an input for dumb 3.5 inch floppy drives, used to select between the two sides of the disk. For 5.25 inch drives, the same pin is a 5 volt power connection. But for intelligent Smartport and Unidisk 3.5 drives, the SELECT pin is hardwired to ground inside the drive. The SELECT pin on the Unidisk 3.5’s rear daisy chain port is connected internally to an RS latch. The latch is cleared during power-up, but if SELECT ever goes high the latch will be permanently set. So in order to convince the Unidisk 3.5 that the next daisy-chained drive is another Unidisk 3.5 or similar intelligent Smartport device, SELECT must be held continuously low from the first moment of power-up. The BMOW Daisy Chainer uses the same technique to detect the selected emulation mode of the Floppy Emu that’s plugged into it.
To meet that requirement of “continuously low from the first moment of power-up”, the Floppy Emu CPLD’s default configuration must pull SELECT low, even before the code on Floppy Emu’s microcontroller has begun to run. But if a pulldown isn’t wanted at power-up, a different default CPLD configuration is needed. That’s why this requires two different firmware versions for these two different behaviors.
All this input/output direction switching for SELECT can be problematic. We can blame Apple for this. Floppy Emu includes an inline protection resistor between SELECT and the CPLD, to guard against possible signal contention if the computer tries to drive a signal on SELECT at the same time the Floppy Emu activates the SELECT pull-down for daisy chaining.
What happens if you use the normal firmware in a setup with two daisy-chained Unidisk 3.5’s or other Smartport devices? Nothing harmful, but the second Smartport device (which in this case is a Floppy Emu) won’t be recognized correctly. The first Unidisk 3.5 drive will think the Floppy Emu is some other type of drive, and won’t pass along the required I/O signals during Smartport activity. This is also exactly what happens with some other vendors’ Apple II disk emulators: they don’t pull down SELECT correctly, so they don’t support Smartport daisy-chaining. Maybe you never noticed. This little detail is one important piece of giving Floppy Emu maximum compatibility.
Microamps and Milliamps
So what happens if you use the Smartport daisy chain firmware in a setup where it’s not actually needed? Why not just always use that firmware? That’s actually exactly what all prior versions of the Floppy Emu firmware have done since 2019. Though I never used the term before, all prior firmware versions were essentially Smartport daisy chain versions, and it worked fine. But a recent analysis convinced me it’s better not to include the SELECT pulldown behavior of the Smartport daisy chain firmware if it’s not actually needed.
The issue is the current that’s present on SELECT when the pulldown is active but the computer is trying to drive the signal high. The Floppy Emu’s inline resistor limits the current, and this seems to be exactly how Apple intended things to work. The Apple IIgs and the (dumb) Apple 3.5 Drive both include an inline resistor on the SELECT output for the same reason. But it’s still not good practice, and it creates a burst of comparatively high current (compared to the other disk I/O signals) whenever it happens. This may create EM noise and minor signal integrity problems elsewhere. Over the long term it may also start to degrade the silicon structures in the CPLD’s input; a milder form of the same concern I previously described here. This SELECT pulldown current can happen by mistake, when the Floppy Emu is configured for Smartport emulation mode but is connected to a Disk II Controller Card or other controller that doesn’t support Smartport. Or it can happen briefly during normal use, either during power-up or when multiple drives of different types are daisy chained, each one using SELECT in a different way.
To be clear, there is no extra current present on SELECT when Floppy Emu’s emulation mode is configured as Smartport or Unidisk 3.5, and it’s daisy-chained to the rear of another Unidisk 3.5 or the BMOW Daisy Chainer. That’s exactly how the pull-down is intended to be used. Nor is there any extra current in typical scenarios where Floppy Emu is configured as Smartport or Unidisk 3.5 and plugged into the disk port of an Apple IIc or IIgs. No issues there.
I may be overly paranoid and this extra current may be just a nuisance or totally harmless. Experience from the past few years says it’s a minor issue at best, but nevertheless I want to eliminate it where I can. Because the SELECT pulldown is only needed in uncommon cases when two Smartport devices are daisy-chained, I feel better having the default firmware just disable the pulldown completely, to get the most robust possible behavior. Those few people who need the Smartport daisy-chaining support can use the alternative firmware version where the SELECT pulldown is enabled as needed. Everyone can be happy.
Read 5 comments and join the conversation5 Comments so far
Leave a reply. For customer support issues, please use the Customer Support link instead of writing comments.
While I don’t know the details of everything that the Floppy Emu might plug into, TTL and NMOS devices really don’t mind if they’re trying to output high and an external device is trying to output a low signal; they’ll simply let the external device win. A planned first-party peripheral for the Atari 2600 (the Graduate) actually exploited this, having the 6502 output $FF while the peripheral grounded the pins that should be zeroes. NMOS devices may be damaged if they are driven hard to 5 volts while trying to output low, but that’s not the case here. Some CMOS devices may be damaged if they attempt to drive a high logic level into a dead short, or if they attempt to drive a high logic level into a load that consumes too much current for an extended period of time, but if current is limited to a reasonable level for a brief time I don’t see anything to worry about.
How much current or series resistance are we talking about here? With a 1K of series resistance, worst-case current would be 5mA, and worst-case power dissipation would be 6.25mA (at a voltage of 2.5V and a current of 2.5mA). While I might be slightly concerned about the possibility that some CMOS devices might suffer excessive wear if subjected to such conditions 24/7, I would expect that a 5V device which is capable of outputting 2.5mA at all would be beefy enough to withstand 6.25mA of power dissipation for a moderate duration, and devices that can’t stand that much power dissipation would pass even less current.
Thanks for the great analysis. It’s complicated, because the Floppy Emu could be connected to dozens of different types of disk controllers or built-in disk ports, and I’m not sure what logic families are used to generate the output signals in all of them. But I think the biggest risk is to the Floppy Emu driving the low signal (from a Xilinx CPLD), rather than to the computer driving the high signal. In the worst case, you could get the Floppy Emu driving low but connected to the computer’s 5V power supply, with a 330 Ohm resistor in between them. That’ll force the Floppy Emu pin to sink 15 mA. From what I know of the usage histories of boards that were RMA’d over the past couple of years, this may be correlated with a higher rate of board failures, though I could be wrong. The goal of the firmware change is to eliminate any possible concern with this.
Does the resistor need to be small enough to overpower anything in particular? Even if it would be good to have firmware avoid driving something low that shouldn’t be driven low, it’s also good to design hardware to minimize the risk of damage if such things do happen. Stress on the chip is apt to be more than proportional to the square of current, so increasing the resistor from 330 to 390 would likely cut stress by at least 30%, and increasing it to 470 would reduce the stress by more than half.
Yes, it needs to overpower a pull-up resistor in the daisy chain port of certain Apple disk drives. This was identified after the release of Model B and was addressed by changing the resistor for Model C in 2019. https://www.bigmessowires.com/2017/08/09/unidisk-3-5-daisy-chain-sad-trombone/
setup new floppyemu, worked fine as apple drive, but have //GS and wanted to run as HD in daisy chain. used spdc firmware, two parts. booted and floppy flashes red once, never seeks, no green light and floppyemu won’t boot. checked and rechecked a few times. disconnected emu, not my gs won’t read floppy 3.5 alone, same red flash. booted dish 0b030000. any ideas? I am 100% certain I powered gs off every time i physically disconnected or connected a cable.