While I await the new Yellowstone v2.1 PCBs, I’ve been spending more time on testing. With my hacked-up v2.0 PCB, most things are working pretty well, especially with DOS3.3, ProDOS, or game disks. I can connect any odd combination of drives to the Yellowstone card, and expect that it will behave more-or-less correctly, but of course there are still a few bugs. Here’s what I’ve been working on recently.

 
Laser Bugs

Yellowstone supports booting from drive 1 or drive 2, but I noticed that if both drives were 5.25 inch floppies, then attempting to boot from drive 2 would always crash the computer. To find the cause, I had to go digging deep into the Laser ROM on which Yellowstone’s core disk routines are based. After some effort, I identified this as a bug in the original Laser ROM. With this drive configuration, if booting from drive 1 failed, it would prepare to boot drive 2 but never actually load anything from the disk. Then it would attempt to run the code in the uninitialized memory buffer where track 0 sector 0 was supposed to have been loaded. Doh! This is a surprisingly severe bug to find in a successful product from a major company in the 1980s, but maybe expectations were different back then.

I found another Laser-related bug in the 3.5 inch drive support. Although Yellowstone was already working OK for 3.5 inch drives, the disk I/O sounded like a panicked chicken or one of The Muppets. While reading from a disk, the 3.5 inch drive made an odd mechanical sound several times per second, which was not present when using the same drive with other disk controllers. I eventually tracked this down to the 3.5 inch / 5.25 inch switching behavior. After every sector read from the 3.5 inch disk, the Laser ROM routine was switching back to 5.25 inch mode before exiting, only to immediately switch back again for the next sector. This was causing the drive to turn on and off rapidly. I’m not sure how that made it through anybody’s QA process, because it made an obvious unpleasant noise.

With the Apple IIgs, if you boot the computer with a DOS3.3 disk using another controller card in a higher-numbered slot than Yellowstone, then Yellowstone’s ROM initialization code will never have an opportunity to run. The motor detectors for Yellowstone’s slot will never get enabled, so the IIgs won’t slow to 1 MHz when attempting to do I/O with Yellowstone’s drives. The result will be a garbled mess. Fortunately this is pretty obscure, and it only affects software based on DOS3.3 and not ProDOS, and where Yellowstone is not the primary boot device. I don’t think there’s any complete fix, but there are several possible work-arounds, including manually running the initialization code with PR#x for Yellowstone’s slot number.

 
GS/OS

Some other bugs I’ve identified, but not managed to fix yet. Most of them are related to GS/OS. When sitting at the desktop, GS/OS makes a Status call for each drive every 800 ms. I assume this is so it can update the GUI, and change a disk’s icon when it’s been swapped or removed. But this creates a problem for Yellowstone. Part of the data that’s returned by a Status call is the size of the disk. For 3.5 inch disks, the size is different for single-sided 400K disks and double-sided 800K disks, but it can’t know which type of disk is in the drive until it tries reading it. So every 800 ms, the drive spins up to read the disk and see whether it’s double-sided, over and over forever. It’s very distracting, and other disk controllers don’t have this problem. The Yellowstone Status call handler is going to need more smarts to cache the disk info instead of re-reading the disk each time, and to know when the drive must be checked again after a disk swap.

Yellowstone 5.25 inch drives currently aren’t working great with GS/OS, because GS/OS doesn’t know they’re 5.25 inch drives. It thinks they’re some new type of drive that supports standard API calls and that just happens to be 140K in size, so it treats them the same way as 3.5 inch drives, including the every 800 ms status call. But 5.25 inch drives can’t work that way. If you boot GS/OS while having a 5.25 inch disk in the drive, then everything works OK at first. But if you remove that disk and insert another one, GS/OS won’t know about it. If you click on the 5.25 inch drive icon, it’ll ask you to reinsert the original disk and there’s no way switch disks. If you boot GS/OS while having an empty 5.25 inch drive connected, it will complain that the disk can’t be read and needs to be initialized. If you cancel that, then the 5.25 inch drive disappears from the GS/OS desktop, never to be seen again.

With a standard Disk II controller card, or the built-in disk port of an Apple IIgs, 5.25 inch drives have a different behavior than other types of drives under GS/OS. It doesn’t attempt to access the drives or check their status until you choose to open them. As I recall, it also shows the 5.25 inch drive with a separate icon from the disk that’s in the drive. I’m not sure how to force GS/OS to treat Yellowstone 5.25 inch drives the same way, or if it’s even possible. The behavior may be determined by a signature check of the disk controller’s ROM, and if it looks like a Disk II controller, it’ll use the special 5.25 inch drive behavior. There might be a work-around if you’ve booted GS/OS from another drive and disk controller, and are then accessing one or two 5.25 inch drives using the Yellowstone card. But if Yellowstone is your only disk controller, with a Smartport hard drive at D1 and a 5.25 inch drive at D2, I’m not sure what the solution might be.

 
Floppy Emu

The Floppy Emu disk emulator has been my go-to testing device for use with Yellowstone, and I’ve found a couple of bugs with it too. When Floppy Emu is configured as a Unidisk 3.5 drive, but no disk is inserted yet, it displays a menu for selecting a disk. During this time the disk emulation is paused, and if the computer queries the drive, it will appear unresponsive. If you’re planning to boot from the emulated Unidisk 3.5 then you’ll probably never notice this, but if you use the Yellowstone card to boot from a ProDOS disk in another drive, then ProDOS will fail with a “Relocation/Configuration Error” mid-way through booting when it queries the Floppy Emu and gets no response.

In researching possible solutions for the GS/OS Status Call, I also realized that Floppy Emu isn’t correctly emulating one of the Sony 3.5 inch drive’s internal registers called SWITCHED. I had never found any documentation about this, so years ago when I created the emulator framework, I made this register always return zero. But now I realize that’s wrong. After experimenting with a real 3.5 inch drive, I see how it’s supposed to work. At power-on the SWITCHED register should be zero, and it should change to 1 if a disk is ejected automatically or manually with a paper clip. Software can set the value back to zero again. This probably explains why a few old Macintosh games like Dark Castle don’t seem to recognize when a new disk has been inserted, when they’re run from a Floppy Emu.

 
It’s not a Bug, it’s a Feature

With the exception of the GS/OS items, I think most of these issues should be possible to fix, and if I’m wrong then they’re at least easy to identify and work-around. But I’m a little worried about 5.25 inch drive handling under GS/OS. Hopefully it’s just a matter of providing the right flags in response to the Status call and other API calls. I suppose it’s not the end of the world if it never works, since most people who are running GS/OS with Yellowstone will have a separate Disk II card or the built-in disk port for their 5.25 inch drives. But I’d love to make this combination work if I can.

Throughout Yellowstone’s development, I’ve struggled on and off with mysterious problems related to the JTAG programmer. When the programmer is connected to the Yellowstone card, and I turn the computer off and on again, strange things sometimes happen. The Apple IIGS will boot to a screen of green and pink checkered squares, or will beep continuously, or simply freeze. This condition will often persist across multiple on/off/on cycles of the computer’s power switch. Unplugging the JTAG programmer finally returns everything to normal.

I assumed the JTAG programmer was somehow back-powering the Yellowstone card, which in turn might even have been back-powering the computer. When the computer was off, but the JTAG programmer was on (it’s a USB device connected to my PC), it looked like a small amount of power was being provided by the JTAG programmer to the Yellowstone card. In the past I made some half-hearted attempts to troubleshoot the issue, but never really got anywhere, and stopped worrying about it. Yesterday I took another look at the problem.

The JTAG programmer connection has six pins: VCC, GND, TCK, TMS, TDI, and TDO. The VCC pin is used by the programmer to sense the target board’s voltage, so it can set the level of the other data signals properly. Under normal conditions, that means a small amount of current is flowing from the Yellowstone card’s 3.3V supply rail through the VCC pin to the JTAG programmer.

 
Experiments

How does this work? I disassembled the JTAG programmer to see. Its output stage consists of a 74HC244 and a 74HC07, both of which are powered directly from the VCC pin of the target board. That ensures the output signals will be at the right voltage level. So far, so good. But I also saw several resistors (pull-ups?) between the VCC trace and other signals on the JTAG programmer PCB. Some of these go back to the programmer’s own 3.3V regulator, or to I/O signals from the programmer’s built-in microcontroller. With a multimeter, I measured about 1.4K ohms between the programmer’s 3.3V supply and the VCC trace for the target board. So when the target is off, it will be back-powered by 3.3V through 1.4K ohm from the programmer. That’s not great, but the true situation is likely worse, because there’s probably also additional unwanted current coming from the microcontroller I/O signals depending on what state they’re in, and the effective resistance may therefore be lower.

I put everything back together, reconnected the JTAG programmer, but did not turn on the Apple IIgs. With the computer still off, I measured the voltage on Yellowstone’s 3.3V supply rail, and saw 1.3V. Then I measured the voltage on the 5V supply rail and saw 0.5V. Doh! I’m not certain how the FPGA and the computer will behave with those low voltages, as they’re certainly too low to run anything normally, but they may be enough to keep some components half-alive in a strange zombie state. Then when the power is turned on, those components don’t initialize normally, and weird things happen. I’m not sure exactly what the mechanism is, but holding the supply at 1.3V instead of zero when the device is off certainly seems like it could cause strange behavior.

The solution seemed obvious to me: put a diode between the 3.3V supply and the VCC pin on the JTAG header. That would allow current to flow out to the JTAG programmer during normal use, but prevent current from flowing in on the VCC pin when the computer is off. The JTAG programmer would see a voltage that’s a diode drop below 3.3V, so the JTAG signals would also be the same amount lower, but the signals should still be plenty high enough to work. To my poor Yellowstone board that’s already suffered so many cuts and patches, I made one more cut and patched in a 1N914 diode.

With the diode installed, JTAG programming still worked normally. The mysterious green/pink checkerboards seemed to have disappeared. With the computer off, I measured 0 volts on Yellowstone’s 3.3V supply rail – hooray! But unfortunately I’d celebrated too soon. While the diode seemed to fix the problem when the JTAG programmer was connected in its default power-up state, it was a different story after exercising the JTAG programmer a bit. I found that if I turned on the computer, used the JTAG programmer to update the FPGA, and then turned off the computer again, Yellowstone’s 3.3V supply rail showed 1.25V and the IIGS would freeze when turned on again. What??

 
Phantom Power

My experiments ended there, but I suspect the difference is due to the state of the TCK, TMS, and TDI pins. If these are low, then my diode on VCC fixes the problem. But if any of these are high, as they may be after concluding a JTAG operation, I suspect that Yellowstone is being powered through the TCK, TMS, and TDI pins.

How? Like many ICs, Yellowstone’s FPGA has clamp diodes on its input pins. Under normal use, the diode is meant to protect the input buffer if the voltage ever rises too high. It’s just a built-in diode from the input pin to the VCC supply. But when the FPGA is off, this means the chip can actually be powered by supplying a voltage at any input pin, which will raise the VCC supply rail to a voltage that’s a diode drop below the input voltage. This is called “phantom power”, and there’s plenty of discussion about it on the web. It’s not something you want to do intentionally, because the clamp diodes aren’t designed for this purpose, and can’t handle very much current. But in my case, unwanted phantom power seems to be the cause of the problem.

But wait: if the TCK, TMS, and TDI signals are coming from that 74HC244 chip I mentioned, and that chip is powered from Yellowstone’s VCC (which is at 0V thanks to the diode I added), then how can those three signals ever be high? My theory is that the 74HC244 is itself being phantom powered by the JTAG programmer’s microcontroller.

Is there a way to fix this? Additional diodes probably won’t help here, because the direction of current flow is the same for the normal case and the problem case. The only simple fix I can think of is to add a dummy resistor between Yellowstone’s 3.3V supply and GND, guaranteeing a minimum load of at least a few milliamps regardless of what the other chips on the board are doing. That way even if some phantom power is applied, the load will be enough to prevent the 3.3V supply rail from rising high enough to cause trouble, because the phantom power can’t (presumably) supply more than a couple of milliamps at most.

But the devil is in the details. Under normal conditions a 1K resistor would create a continuous 3.3 mA load on the 3.3V supply, but with phantom power the situation is different. There’s already several kiloohms of resistance due to who-knows-what between the phantom power source and the Yellowstone supply rail, so adding what’s effectively a 1K pulldown resistor doesn’t change things very much. I calculated that I’d need a dummy load resistor of just a few hundred ohms to move the needle enough, and reduce the VCC voltage due to phantom power to a point where I could be confident it wouldn’t cause trouble. But a resistor value that low would put an unacceptably large load on the 3.3V supply during normal conditions.

There’s probably some clever solution here, but I’m not going to worry about it. This problem only affects me and my development work with the JTAG programmer, so I’ve decided to ignore it. It’s not an important enough issue to be worth additional time and effort, I think. But it’s an interesting little detour into unexpected failure modes of electronic devices.

July 21, 2017 – I began the first work on what would become Yellowstone, with some attempts at designing a Verilog model of Apple’s IWM chip. Four years have passed since then, and I’m still working on this project! Today version 2.1 of the Yellowstone PCB is nearly ready for fabrication. V2.1 contains a pile of changes and improvements based on my tests of V2.0 over the past weeks. Some of the highlights:

• Added 2.2K series resistors on the -12V supply for J1 and J2, to safely limit current if a Macintosh 3.5 inch drive is connected. (bypassable with a solder jumper)
• Inserted 33 ohm series resistors on the data bus lines, to reduce ground bounce caused by fast-switching signals
• Replaced the DIP switch for selecting Disk II mode with a firmware-driven activation
• Removed the DIP switch for manually routing /ENABLE2 to J1 or J2, in favor of a firmware-driven solution
• Routed /ENABLE2 through two open-drain buffers to the two drive connectors, so a pull-down from one drive won’t make the other drive think it’s enabled
• Routed the RD and SENSE signals from each disk connector independently to the FPGA, so it can tell which drive is responding and handle error conditions when they both respond at the same time
• Added a “recovery” jumper that connects A11 through a resistor to the FPGA’s SPI /CS input, to support in-system programming of mis-programmed or blank FPGAs.
• Added decoupling capacitors on all four power supplies
• Added more ground fills, and lots more vias connecting top and bottom-side fills
• Rerouted and widened power supply traces, and repositioned bypass capacitors
• Fixed a spot where D5 overlapped a power supply trace. Oops!
• Fixed an enable signal that was connected directly to +5V instead of with a pull-up resistor. Oops again!
• Fixed the wrong supply voltage connected to one of the chips. Oops a third time!

It’s been a long journey, but everything is finally coming together. If all goes well I may have a beta-ready board in a few weeks.

I’m working on what I hope will be the final hardware changes for the Yellowstone 2.1 PCB. Among these are changes to my capacitor usage and placement strategy. In my previous posts I discussed intermittent problems that looked to be caused by ground bounce, VCC sag, or both. Apple II expansion cards only have a single ground pin on the motherboard connector, so they’re prone to ground noise when signals with fast rise and fall times cause large transient currents. Among several methods that I’ve used for mitigating this problem, one not-so-obvious strategy is to add bypass capacitors on the +12V, -12V, and -5V power supplies, even if the card doesn’t use those supplies.

Apple IIgs Technote #68 says:

Right now Yellowstone doesn’t use or bypass the +/-12V supplies; it just routes them through to the disk drive connectors. -5V is completely unused, and there’s nothing at all connected to that supply pin. I had actually forgotten there even was a -5V supply. (Maybe this could be leveraged somehow for current-limiting of Macintosh drives?)

Why does bypassing unused supplies help anything? Even after doing lots of reading about current loops and ground bounce and impedance, I have to admit I don’t really understand it. I read a T.I. paper that discussed how bypass capacitors help reduce the area of current loops, but I don’t see how that’s true for bypass capacitors on unused supplies, where there’s no path back to the chip that’s sourcing or sinking current. The Apple technote mentions “improved ground by providing additional AC ground paths”, which makes a little more intuitive sense to me. I imagine the bypass capacitors as acting like tiny batteries that work to maintain the voltage between their two terminals. As long as +12V, -12V, and -5V are stable, then bypass capacitors on those supplies will work to keep local ground at 0V by sourcing or sinking small amounts of current as necessary.

I probably wouldn’t really care why it helps, and would just trust that it does, except that I need to know what types and values of bypass capacitors to use, in what locations. Without a better understanding of the theory of why it helps, I’m uncertain how to proceed.

The Apple technote specifically says electrolytic or tantalum capacitors, but doesn’t mention ceramic, which would normally be my go-to for this. I’m not sure why they omitted ceramic.

For the capacitor value, Apple doesn’t say anything. Is a standard 0.1 uF appropriate? I believe the 0.1 uF rule-of-thumb is related to the rise and fall times of typical ICs, and an assumption that the capacitor is placed within a few millimeters of the IC supply pin. But when there’s no specific chip being bypassed, how do you determine the appropriate value? Would a larger value like 1 uF make more sense?

Then there’s the question of placement. I can’t place the bypass capacitors near the IC supply pins, because there are no ICs using +12V, -12V, or -5V. Should I put the capacitors near the board’s supply pins on the motherboard connector? Or maybe in the middle of the board?

My best guesses are that a ceramic capacitor would be fine as long as its voltage rating is high enough, the capacitor should be placed close to the motherboard connector, and the value should be something like 1 uF or 10 uF. Or maybe multiple values with multiple capacitors per supply. I don’t want to rain down tons of extra capacitors though, because the number of discrete components on the PCB is already higher than I’d like.

I’ve been searching for a simple and reliable way to prevent a short-circuit on Yellowstone’s -12V supply when a particular type of Macintosh disk drive is connected. Connecting this drive results in a +5V to -12V short circuit, but if the short is removed, the drive otherwise works just fine. One obvious solution is to put a series resistor on the -12V supply connection. For example a 1.7K ohm resistor would limit the short-circuit current to a safe 17V / 1.7K = 10 mA. But a series resistor on the -12V supply for Macintosh drive protection would obviously screw up other types of drives, by making the supply appear to be something other than -12V volts. Obviously. Or maybe not so obviously.

When I actually tested it, I was very surprised by the results. As far as I know the -12V supply is only used by Disk II drives. A 1.8K series resistor on the -12V supply for a Disk II drive resulted in an apparent supply voltage of -8.7V, but the drive still worked fine. I then tried larger value resistors resulting in “-12V” supply voltages of -6.5V, -5.0V, and -0.8V, and everything continued to work. Even at +3.7V the drive continued working, but I/O was slightly slower than normal, suggesting that a high number of retries were happening. The drive finally failed after I reached 100K ohms and +6.9V for the so-called -12V supply.

How can this be? How can the -12V supply voltage accuracy matter so little? What is it used for?

Looking at the schematic for the analog board of a Disk II drive, -12V is only used in one spot, at one terminal of a 10K potentiometer at the bottom-right. It’s part of an analog reference adjustment for the MC3470, the drive’s floppy disk read amplifier circuit. Pages 7-119 to 7-120 of the MC3470 datasheet describe how it adjusts the differential amplifier that’s used to detect peaks in the AC signal from the drive’s read head.

As best as I can tell, if the -12V supply voltage is incorrect, it will result in “peak shift”. The boundaries between bits will appear to shift slightly forward or backward from where they’re actually located on the disk. A small degree of shift won’t cause any problems, but eventually it will reach a threshold where bits begin to be read incorrectly, resulting in errors.

For the past week I’ve been researching and discussing current limiting circuits, current mirrors, and supply switching circuits. Can I forget about all that stuff and simply put a 1.8K resistor in series with the -12V supply? These test results say “yes”, but I’m still somewhat hesitant.

Hesitancy #1 is because I don’t know what the worst case might be. Maybe my Disk II drive isn’t representative of others. Maybe there are other types of drives (DuoDisk? Two daisy-chained Unidisk 5.25 drives?) that use the -12V supply in ways I don’t know about, or that will result in bigger voltage errors for the same series resistance.

Hesitancy #2 is because even if it works in tests, any error in the -12V supply voltage will cause some amount of peak shift, which might be the difference between a badly-degraded floppy disk working and not working. It’s a little like throwing away part of the noise margin for digital signals. It may still work fine for most situations, but when things are already working poorly for other reasons, it could be enough to tip the result into failure.

On the other hand, maybe the simplest solution is best. If it works in tests, even with series resistor values far larger than the ones I’d actually need for current limiting, then what’s not to like about this solution?

I’ve returned to the question of how best to limit the current from Yellowstone’s -12V supply. I discussed this earlier here and here, and had more-or-less settled on the idea of using a current mirror circuit. But now I’m taking a second look at possibly using JFETs or a purpose-designed CCR (constant current regulator) intended for powering LEDs instead.

Here’s a review of why this is needed. Yellowstone has two connectors for disk drives, and each drive is supplied with +5V, +12V, -12V, and GND. Some types of drives don’t actually use the -12V supply, and other types have the -12V supply pin internally connected to the +5V supply pin. Ouch! A picture may help clarify:

The idea is to insert some new component or circuit inline with pin 2 (the -12V supply pin) of each Yellowstone drive connector to prevent a short circuit when a Macintosh drive is connected. Keeping in mind there might be two Disk IIs connected, or two Mac drives, or one of each, or any combination with other drive types. The anti-short-circuit protection should happen automatically, without requiring any user switch settings or other manual configuration.

Ideally the solution would just disconnect pin 2 when a Macintosh drive is connected, but I don’t know any good way to do that. The next best solution is to limit the current through pin 2, to a level that’s high enough for a Disk II to operate normally, but low enough to prevent problems with the Macintosh drive.

Here are the requirements for the -12V supply connection, as I see them:

1. When a Disk II drive is connected, it should see a supply voltage as close to -12.0V as possible, since it uses the supply in an analog reference circuit. This means any resistors between the drive and Yellowstone’s -12V supply should be small, to minimize the voltage drop.
2. When a Macintosh drive is connected, the current should be limited to about 10 mA. The exact value isn’t critical, and anything from 5 mA to 20 mA is probably OK.
3. The two drive connectors should be isolated from one another, so a Mac drive at connector 1 doesn’t affect the -12V supply for a Disk II drive at connector 2.
4. The current limiting function should work automatically, without any control or reset logic.
5. Power dissipation in the current limiter should be as low as possible.
6. The current limiter should be built from commonly-available parts.
7. The current limiter should use the fewest possible number of parts, that are small and inexpensive.

 
Current Mirror

In my last post, I considered using a current mirror. In this circuit, a reference current is passed through a transistor, with two other transistors controlling the -12V supply current, one transistor per drive connector. It can be built with three matched BJTs or FETs, plus a single resistor for setting the current limit.

Here’s an example using FETs, with a Disk II drive plugged into the first connector and a Mac drive plugged into the second. The -12V supply current is shown for each drive connector. The current for the Disk II is nearly identical to the 2.4 mA that would be expected if no current-limiting circuit were present. But the current for the Mac drive is limited to 9.5 mA, instead of the many amps that would otherwise flow due to the short circuit.

A current mirror requires each transistor to have the same voltage threshold, gain, temperature, and other properties, else the current may be incorrect. This is where my difficulties begin. I went looking for a single IC package with 3 FETs, or maybe 4 FETs, in order to help ensure they’d all have matching properties. I learned that these aren’t common: you can find discrete FETs or dual FET packages, but beyond that it’s slim pickings. With the global shortage of semiconductors, I’d prefer not to rely on a part whose availability might be an issue in the future.

I could easily use two dual FET packages, or three discrete FETs, but then their temperatures and other properties might not be well matched. Given that I can tolerate an error of least 2x in the current, maybe this isn’t a big worry. I need to take a closer look at the FET datasheets to get an idea of how much the current might change if one transistor’s threshold voltage is 0.1V off from another’s, or one’s temperature is at 25C and the other is at 85C. Maybe it’s not a big enough issue to worry about for this application.

One small drawback of the current mirror is that it wastes 10 mA from the -12V supply to create the reference current, regardless of whether any of the connected drives actually use the -12V supply.

 
JFET

Another approach to current limiting is to use a self-biased JFET. A commenter on one of my previous posts mentioned this option, but I never followed up on it. The basic idea is that a JFET is a “default on” device, but its drain-source channel can be partially closed by making the JFET’s gate-to-source voltage negative. The more negative you make Vgs, the further the channel is closed, until reaching the Vgs cutoff threshold where the JFET turns off completely. By adding a resistor at the JFET’s source terminal, and connecting it back to the gate, this behavior can be leveraged to make a current limiter. There’s a nice tutorial about this here.

The JFET’s I_DSS (its maximum drain-to-source saturation current) must be larger than the desired current limit. If the circuit can’t reach the current limit, because there’s a large external resistance like in the case of the Disk II drive, the behavior is less obvious to me. From my scrutiny of graphs in the datasheets, it looks like a typical JFET in this situation will behave like a resistor of about 80 ohms, in series with the external resistor used to set the current limit.

Yellowstone would use two independent JFETs for the two disk connectors, with no reference current needed or wasted. That’s nice.

The higher “on” resistance compared to a normal FET is less nice. Combined with the external resistor, it would create a larger voltage drop, so the Disk II drive would see a voltage like -11.7V instead of -12.0V. Maybe that’s still fine. I did a test earlier with a Disk II and a 100 ohm series resistor on the -12V supply, and it seemed to work OK.

It’s slightly complex to calculate what value of external resistor is needed to achieve a desired current limit. The formula depends on the current, the JFET’s I_DSS, and its cut-off voltage. The tutorial linked above has the derivation. Or you can eyeball it from the graphs in the datasheet, if a precise value isn’t needed.

I couldn’t find many widely-available dual-JFET packages, which is too bad. So a Yellowstone solution using JFETs would probably be built with two discrete JFETs and two resistors, to make a separate current limiter for each drive connector.

 
Constant Current Regulators

The JFET sounds intriguing, but then I stumbled across the concept of constant current regulators. From what I can tell, these CCRs are just the JFET plus resistor circuit described above, all wrapped up into a two terminal package that looks like a diode. CCRs are available in different types with different fixed current limits, and are typically used in LED driving applications. As far as I can tell, their behavior is identical to the JFET circuit with the discrete resistor.

Since a CCR is a two-terminal device, it would be very easy to use: just put one in series between the drive and the -12V supply for each drive connector. Boom, done. It’s too easy, I think I must be missing something.

This specific NSI50010YT1G CCR from ON Semiconductor looks nearly perfect, with a built-in current limit of 10 mA. The trouble is that right now it’s unavailable just about anywhere. There’s a 15 mA version in stock at Newark, but that’s still only a single supplier, and I’d rather have 10 mA than 15. I really like the idea of using a CCR, but it’s not going to work unless I can find one with an appropriate current limit, with good availability from multiple suppliers.

 
Power Dissipation

For any of the above solutions, when a Macintosh drive is connected and the current is limited to about 10 mA, the power dissipation must be considered. With +5V at the Mac drive end and -12V at the Yellowstone end, that’s 17V times 10 mA, or 170 mW of power. Most of the packages that I looked at have power dissipation limits close to that, or slightly higher. I’m uncertain how to optimize this, but probably I need to choose packages that are physically bigger (violating my requirement 7), and/or make the PCB pads very large so they can double as heat sinks. These kinds of power considerations are mostly foreign to me. I don’t want to make the PCB pads any larger than absolutely necessary, since board space is at a premium in the area near the -12V connections. If anyone has recommendations for package types or connection methods that would be better for dissipating a few hundred milliwatts, I’d love to hear them.

 
And the Winner Is…

I’ll do some more searching for CCR availability. If I can find one with the right properties and that’s widely available, I think that’s my preferred solution.

Otherwise I’ll probably stick with the original plan of using a current mirror and three FETs. I can build it with two dual FET packages plus a single resistor, leaving me with an extra FET available for some future purpose. I’ll do some more analysis and testing to try to estimate how much current error I might see if the reference current FET is in a different package than the FET that limits the current. As long as the answer is closer to 20 percent than 400 percent, it should be OK.