Yellowstone Bugs
I’ve discovered a troubling problem with the Yellowstone disk controller for Apple II, and I’m unsure how to debug it. When it’s functioning as a Liron clone, Yellowstone isn’t playing nicely with other cards like a stock Disk II controller card. While booting from a Prodos 1.9 disk image using a Disk II controller in slot 6, Prodos crashes midway through booting if the Yellowstone card is present in slot 5. This happens even if there aren’t any drives connected to the Yellowstone card. It’s not 100% reproducible, but happens maybe 90% of the time. Yet everything works fine if I repeat the test with a real Liron controller card instead of the Yellowstone card. That means it’s my problem, and not the Liron designer’s.
I believe what’s happening is this: the Apple II scans the slots beginning with slot 7, and moving towards slot 1, looking for cards with a bootable ROM. It finds the Disk II card in slot 6, and jumps to its ROM code. That code loads sector 0 from the Prodos disk, displaying the splash screen shown in the photo. Then before Prodos has finished fully loading, the Apple II resumes the scan and jumps to the Yellowstone ROM code for slot 5. This code should look for attached Smartport devices, find that there aren’t any, and return. But somewhere during the execution of that ROM code, or during execution of the Prodos code just afterwards, something goes wrong. The Apple II stops and displays a system monitor prompt. Crash.
Where do I begin, with a bug like this? I don’t really know anything about the inner workings of Prodos, or even about the ROM code on the Yellowstone card, since I simply copied it verbatim from the Liron card without really studying it. That means I can’t easily figure out what the computer is trying to do at the moment it crashes.
My first guess is that I’m experiencing data bus contention, and the Yellowstone card is interfering with the Disk II card. The Disk II controller card and the Yellowstone card might both be attempting to put data on the bus at the same time, interfering with each other, and causing wrong values to be read from ROM code. But it’s hard to imagine how Yellowstone could be driving the bus at the wrong time. The output enable logic is pretty simple, and the Apple II already provides each slot with its own fully-decoded enable signals /DEVICE and /IOSELECT. There is a region of the Apple II address space that’s shared by all cards, and that uses a shared /IOSTROBE enable signal, but the Disk II card doesn’t use that address space.
My second guess is the reverse of the first: the presence of the Disk II card is somehow interfering with the Yellowstone card, exposing a flaw in the Yellowstone design that doesn’t appear when Yellowstone is the only card present. Maybe it’s somehow causing Yellowstone to malfunction. But I can’t really imagine what could cause that.
A third possibility is a problem caused by Prodos itself, rather than by the Disk II card. Maybe the first portion of Prodos alters some memory locations or sets some interrupt timers, or changes the system state in other ways that cause the Yellowstone boot ROM to fail. But it’s unclear why such an issue wouldn’t also affect a real Liron controller card in the same way.
A final possibility: maybe there’s a hardware problem with my Apple IIe, and there’s not enough juice to power two cards simultaneously, or the logic board is flakey. In the past on this same computer, I’ve occasionally seen similar crashes to the system monitor while booting Disk II software, long before Yellowstone even existed. Coincidence, or clue?
I’m scratching my head, trying to think what I could do to help troubleshoot this further, but I don’t have any great ideas.
Read 44 comments and join the conversation44 Comments so far
Leave a reply. For customer support issues, please use the Customer Support link instead of writing comments.
A good clue: with a real Liron card in slot 6, Yellowstone in slot 5, and no disks attached to either one, the Apple IIe crashes into the system monitor immediately at power-up. That means this problem has nothing to do with Prodos, or the Disk II card specifically.
Does it happen when trying to load DOS 3.3 software? (which doesn’t know about Smartport devices at all)
Does it happen when trying to load ProDOS 2.x or any other versions of ProDOS?
I believe the crash is happening while Yellowstone is executing its own ROM code. Here’s my reasoning: With Liron in slot 6, Yellowstone in slot 5, and no disks attached, the computer should run the Liron ROM, then the Yellowstone ROM, then finally the built-in ROM. There’s an LED on the Yellowstone card that lights when its ROM is accessed, and it flashes briefly every time I try this test. I think that means the Liron ROM is executing without problems, because if it weren’t, the Apple II would never get to the Yellowstone ROM and flash the LED. So it’s probably crashing somewhere during execution of the Yellowstone ROM, although it might also be afterwards, during execution of the built-in ROM.
Why would the presence of another inactive card cause Yellowstone to malfunction when executing its ROM code? Fanout problems, maybe? Or maybe the Yellowstone signal timing is already on the cusp of failing, and the extra capacitive loading of the other card pushes it to failure? Total speculation.
Flaky power can cause all kinds of problems like this, but that seems unlikely since the Yellowstone card probably draws less power than the real LIRON due to the much smaller parts count. Have you tried it with the Yellowstone in slot 7? When it fails to boot with no drive attached error do a PR#6 and see if the same problem happens.
I’m not 100% sure, but once the autostart ROM finds a bootable device, it stops scanning slots. ex: if there is a Disk ][ card with a boot disk in slot 6, the boot sector and operating system takes over, the boot ROM at $C500h (slot 5) is never executed. ProDOS is likely probing the card at the crash point, that’s why I was curious to see the results of DOS 3.3 booting.
If you suspect a ROM mapping issue, take a look at the docs for how $C800 ROMs are mapped. (Page 132: http://www.applelogic.org/files/AIIETECHREF2.pdf ) Any access to a slot’s ROM space should map its full 2kb ROM to $C800h. All cards must clear their mapped ROM at $C800 if there is an access to $CFFFh.
Any way you can try it in a different //e? The fact that you’ve seen similar crashes without the Yellowstone makes me suspicious it may have a subtle error. I’m assuming your //e is a non-Platinum Enhanced model? Maybe try it in a IIgs just for curiousity sake… Possibly try it with different ProDOS versions… 2.4 maybe?
Also curious to know what would happen if you boot from the Yellowstone in Slot 7 or Slot 6 with the Disk ][ controller in the next lower slot?
What happens with 2 Yellowstone’s? Is there a way to hold any drive in reset to test if the power draw of a second card is the culprit?
My hunch is there’s a hardware problem with the Yellowstone card. It seems that nearly any combination of Yellowstone plus another card will crash, even if there are no disks attached to the system. So I was wrong to suspect Prodos – it has nothing to do with Prodos or the contents of any disk. I tried Yellowstone with a Disk II card, with a Liron card, and with a Grappler card (a printer card) that doesn’t even have any autostart ROM. In all cases, there’s a crash about 95% of the time if the Yellowstone ROM is allowed to execute. The other card can be in a higher or lower numbered slot.
@Chris M: Yes, I originally suspected a problem with the mapping from $C800 to $CFFF that you describe, since it’s probably the easiest way for a flaw in one card to cause incompatibility with a second card. That looks unlikely now, given these test results, but I’ll keep looking at it.
I only have this one Apple IIe for testing, but I can also try it in a IIgs. I also only have one Yellowstone card.
A couple more theories:
5. The Yellowstone output buffer to the data bus (a 74LVC245 chip) is too weak to drive the inputs of multiple cards. With multiple cards present, the voltage levels don’t rise high enough, and data is occasionally read incorrectly. Counter-example: with Disk II card in slot 6, Yellowstone in 5, and no disks attached, the computer spins forever at power-up looking for a slot 6 disk. If I interrupt it with Ctrl-Reset and then type PR#5, it responds with NO DEVICE CONNECTED. So two cards are present, and the Yellowstone is working fine.
6. The Yellowstone card needs some time to “warm up” at power-up, maybe to fully initialize the FPGA or to bring the card’s 3.3V supply to full voltage. Attempts to access the card within the first few milliseconds after power-up may result in errors. This would explain why the counter-example from theory #5 works, even though all other examples of two cards seem to fail. Counter-example: in the original “booting Prodos” test shown in the photo, several seconds elapse between power-up and the moment Yellowstone is accessed and crashes. That seems to rule out this theory.
Both power supply issues and logic level issues should be clearly visible on a good oscilloscope.
I did some testing in an Apple IIgs, and now I’m fairly sure the Yellowstone card is failing due to the electrical presence of the other cards on the bus, rather than any kind of logic error or bus contention. With the IIgs, you can put cards in slots 1-6 but disable them in the control panel, so they’re never enabled and don’t do anything. With Yellowstone in slot 7, those do-nothing cards caused crashes. And the frequency of crashes increased with the number of cards:
Yellowstone + 1 other card: no crashes
Yellowstone + 2 other cards: crashes abut 50% of the time at power-up
Yellowstone + 3 other cards: crashes 100% at power-up
I’m not sure why this is happening, but it seems I can rule out the computer itself as a cause. It’s probably either my 74LVC245 failing to drive the data bus voltage high enough, or else signal rise/fall times being degraded due to capacitive loading on the bus. There’s no good place to hook an oscilloscope probe to the bus, but I’ll figure something out. The 74LVC245 has a 3.3V supply but is 5V tolerant. For logical HIGH voltages, it should drive the data bus all the way to 3.3V, which is well above the 5 volt 74LS series threshold of 2.0V for a logical HIGH.
Quite by accident, I also discovered that a real Liron card doesn’t work in the IIgs when the system speed is set to “fast” (the default setting). Doh! That’s a shame, because it means even if I get Yellowstone’s Liron-clone mode working, it won’t be possible to add a second Smartport to a IIgs unless you change the system speed to “normal” aka slow. Here are my test results on the IIgs, experimenting with different system speeds, controller cards, and drives:
Fast speed, Yellowstone card, Unidisk 3.5: doesn’t recognize disk
Fast speed, Yellowstone card, Floppy Emu Smartport mode: smartport checksum error
Fast speed, Liron card, Unidisk 3.5: doesn’t recognize disk
Fast speed, Liron card, Floppy Emu Smartport mode: smartport checksum error
Normal speed, Yellowstone card, Unidisk 3.5: doesn’t recognize disk
Normal speed, Yellowstone card, Floppy Emu Smartport mode: smartport checksum error
Normal speed, Liron card, Unidisk 3.5: boots from Unidisk
Normal speed, Liron card, Floppy Emu Smartport mode: boots from Floppy Emu
One last headache: I discovered that when I make changes in the IIgs control panel, like changing the system speed or enabling a slot, those changes reverted to the defaults if I turned off the computer for about 5 seconds. There’s probably a settings battery on the IIgs logic board that’s long dead, but I can’t see one anywhere.
The IIGS clock battery is soldered into the board; https://i.imgur.com/XUZbJ0o.jpg it’s the purple thing on the left. 3V CR123A with solder leads.
You might do better with something like the SN74LVC8T245 – http://www.ti.com/product/SN74LVC8T245 – which has dual input rails & so can actually drive to near-rail voltages on both sides. The swing speed of the LVCs (given the high load of older inputs when compared to new) might not be fast enough?
There are 16bit variants of the chip http://www.ti.com/lit/ds/symlink/sn74alvc164245.pdf that support 5.5V max
The Carte Blanche used 32bit bus switches IDTQS34X245Q3G.
The GoDIL uses 24bit FET bus switches with 5V level shifter http://www.ti.com/lit/ds/symlink/sn74cb3t16211.pdf
-Jonas
Ah ha, the IIgs battery was hidden under the power supply!
Thanks for the references to alternative bus drivers, I’ll check them out. From my review of the 74LVC245 datasheet, it seems that it should work, so I’m uncertain what the problem is. I need to find time to examine the signals in detail with the oscilloscope. It also occurred to me that maybe I need a bigger 3.3V voltage regulator on the card. It’s a 300 mA LDO regulator, but maybe that’s not enough.
You know the 3.3V regulator is a possibility. I wondered why you used such a small one when I first looked at it. But to be fair, I generally probably grossly over-size things like that because I don’t know enough to pick the optimal size. Maybe more capacitors too in case it is a momentary draw sagging the power? Anyway, I’m really hoping it turns out to be something not insurmountable.
One other question… the 74LVC245 that you are using on the D0-D7, how are you driving the OE or G pin on that? Bus timing on Apple II cards can sometimes be sensitive to how that chip is enabled. If you look at the schematics of a lot of Apple II cards it is often driven by the Apple II bus I/O Select line, but on others they run several of the select lines into 74LSxxx logic. In some cases I’ve read that some devices need 1 or 2 TTL delays before enabling OE. I’m not the best expert on designing Apple II cards… but it is a thought…
The OE comes from the FPGA, and more-or-less mimics the equivalent logic from the Liron card. It’s possible there’s a problem there, but it doesn’t really fit the evidence of more errors with more cards present.
This is going to be challenging to debug. For some of the relevant signals, there’s no good place to physically attach a probe. They’re just tracks on the PCB, or tiny leads on a surface mount chip, or fingers on an edge connector that already has a card in it. I may need to build a new version of the Yellowstone card that has these signals brought out to test points so I can examine them.
I don’t really have the right equipment for this either. What I really need is a multichannel mixed signal oscilloscope. I have a 4 channel analog scope, but that’s probably not enough to examine all the relevant signals at once. My 8 channel Saleae Logic Pro can capture analog and/or digital data, but the analog bandwidth is only 12.5 MHz, so it’s not a very clear picture of what’s happening in the analog domain.
One odd discovery: merely connecting the Saleae Logic Pro to a few data bus signals greatly reduces the frequency of errors and crashes, from 100% to about 20%.
From the data collected with the Saleae Logic Pro, the Yellowstone card’s 3.3V regulator looks fine. Voltage is constant at about 3.27V. And I think the 74LVC245 is driving the data bus to a sufficiently high voltage: I see the bus reaching between 3.1V to 3.6V highs and 0V lows during periods that I believe are Yellowstone output data. I’m not sure how it exceeds 3.3V – overshoot?
Here’s my plan: I’m going to use a 16 channel digital logic analyzer to capture every signal I can, when Yellowstone is working correctly. I’ll do this several times, and verify the trace is exactly the same each time. Then I’ll add more cards to force it to crash, and run again with the logic analyzer. By comparing the two traces, I can hopefully pinpoint the exact place where what’s happening deviates from what’s supposed to happen. This won’t tell me WHY yet, and I suspect I’ll need to examine the analog waveforms for that. But if I know the exact time delay from the reset signal to the point of error, I can re-run the test with a 4-channel analog scope to examine the signals at that exact moment. *crosses fingers*
When driving a logic 1 onto the Apple bus, the 74LVC245A should drive the bus lines just as well as a 74LS245 (as used on many cards). If I were designing such a card myself, I might use a 74LVT245 instead. You should be able to try the 74LVT as a drop-in replacement for the 74LVC245A.
I don’t think it’s likely that the bus buffer itself is the problem. I would be more suspicious of the logic (and timing) of the signal that controls the enable and direction of the bus buffer.
Sounds like a pretty good plan. I also think what Eric Smith is saying makes sense, as it is similar to what I was saying as far as the logic of the OE, and as he says the DIR pin on the ‘245.
What’s the essential difference between the LVC245, LVC245A, and LVT245?
From looking at the data sheets the things I noticed…
74LVC245: “Latch−up Performance Exceeds 250 mA”
74LVT245: “Latch-up protection exceeds 500 mA per JESD78 class II level A”
and “No bus current loading when output is tied to 5 V bus” which I don’t see on the LVC245 datasheet.
So it seems like if bus loading is the problem the LVT245 might be the answer.
Anyway, being as I said, not the greatest mind or most experienced designer, I might be inclined to upgrade the 3.3V regulator to the next larger size and switch the LVC245 to LVT245 and then if it still doesn’t work I’d be pretty sure it had to be a timing issue. But that’s probably a kind of neanderthal approach. I don’t have much in the way of testing equipment so primitive techniques are how I have to do things.
The other thing that has me curious… your odd discovery that connecting the Saleae Logic Pro seemed to reduce the errors. When you hook that up are you introducing a tiny bit of capacitance to the circuit? Maybe you need more or larger capacitors? I\’ve certainly heard of a lot of cases where board debugging issues were solved by adding or upping the value on capacitors. Again, it is kind of an approach of throwing parts at a problem, but as I said, I\’m not the most sophisticated at this.
To interface to LS series logic, you should really be using the LVT245 instead of the LVC245. The logic high level out of a LS series logic device is not enough to always read high on the LVC part.
You should check the input thresholds on the FPGA as well. You want TTL level inputs, not CMOS level. If the FPGA isn\’t reading the control signals correctly, it could be turning on the bus buffer when it shouldn\’t be on and cause the crash that way.
Jerry, I respectfully disagree. What you are saying would be true for a 74HC buffer, but the min Vih spec of the 74LVC245A (from either TI or Nexperia) is 2.0V when running from a 2.7V to 3.6V supply, exactly the same as min Vih as TTL parts in the Apple, including 74LS. The 74LVC family is specifically designed to be capable of interfacing to 5V TTL.
I expect that Steve is using 3.3V for the FPGA Vccio, in which case the FPGA outputs are perfectly fine for controlling the 74LVC245A buffers.
Similarly, the FPGA-side outputs of the 74LVC245A will swing quite close to 3.3V, and won’t have much loading, so they will be well within the input specs of the FPGA then its inputs are configured for 3.3V CMOS.
If any Apple bus signals were fed directly into the FPGA, without on-card buffering, that would be a huge problem, but I doubt that Steve is doing that.
My main reason for recommending the 74LVT245 over the 74LVC245A was higher output drive, which could be a problem on a heavily-loaded Apple II data bus. However, I don’t think that’s likely to be the problem Steve is seeing, because the conditions under which it is failing don’t have most slots filled.
@Jerry I don’t think that’s correct. With a 3.3V supply, the LVT245 has the exact same Vih and Voh as the LVC245. I don’t see why the LVT245 would offer any advantage over the LVC245 with respect to logic levels. Maybe I’ve misunderstood. As for the FPGA, it’s only connected to LVC245 buffers using 3.3V CMOS-level logic at both ends, and isn’t directly connected to any TTL bus signals.
Well, I guess my memory is bad. I thought the Vih levels were different on the LVC. The design I did with those parts was about 18 years ago.
Sorry about that. That\’s what I get for not opening the datasheet.
Maybe reach out to CuriousMarc for use of some the scopes and probes you need. With all the work done on the Alto project and his other retro hardware he may be willing to help.
You can also consider the ABT series of bus drivers. These are 5V parts (with 3.3v-compatible CMOS inputs) that provide even more drive than the LVC, 64ma vs 24ma. However the LS driver that is installed in the computer itself is only rated for 32ma, IIRC, and it can drive a full house of eight cards. (What, you thought you only needed five cards for a full house?) 🙂
Personally I think your problem is that there\’s just not enough power available. I don\’t see any power capacitors on your board, the Apple slot doesn\’t supply especially good power to begin with and then you have a tiny voltage regulator as well. And it looks like a two layer board so your power plane might not be all it could be.
Maybe you can bodge a reasonable size electrolytic cap across the output of the voltage regulator without even having to print a new pcb. You could even connect it with loose wires if you can\’t fit it on the regulator itself. Put one on the input too.
As for test points. Get a breadboard card (reactivemicro has these, or fleabay) and plug it into another slot. Now you can easily tap into the actual bus signals and see what is really going on from the perspective of the Apple rather than the card. It seems like your on-card signals are probably working so what you really need to see is the bus anyway.
Hi Fluffysheap! I like ABT parts and they are great for many applications, but they aren’t suitable here because the outputs can drive above 3.3V, which is fine for the Apple II side but can damage the FPGA.
LVT is the 3.3V version of ABT, and for most purposes is as good or better than ABT. The exception would be when you need to drive the output to close to 5V, rather than 3V, for example when driving 4000-series CMOS or 74HC, 74FC, or 74AC inputs, but that is not the case in the Apple II. Note that normal TTL, including 74LS common in the Apple II, does not generally drive above 3.7V, and the TTL and MOS chips in the Apple only require Vih min of 2.0V.
The 74LVT245B actually even has better output low drive than the 74ABT245B, 64mA vs 32mA, though 32mA should be sufficient in the Apple II. For comparison, the 74LS245 that is commonly used as a data bus driver on Apple II cards is only rated to sink 24mA, but works just fine.
I previously worried that LVC output drive on the Apple side might not be high enough with a heavily loaded Apple bus. However, I was wrong since the 74LVC245A is rated to sink 24mA, the same as the 74LS245. Also,from the description, the problem occurs even with not too much loading, so I still don’t really think that is the problem.
Apologies if this is a double post, first try didn’t seem to go through.
Yes! You are completely right. I am using an ABT driver in my project because I’m only driving onto the bus with it, not bidirectional. But of course this is bidirectional and so it would not work.
OK, now onto the next idea, if anyone is still willing to listen to me after that last mistake. More of an elaboration, really because I’ve mentioned ground bounce before but here’s my latest thought, after reading again that you measured 3.3v solid at the regulator output.
All your logic is 3.3v so you aren’t referencing the 5v power rail at all. The voltage regulator touches it but nothing else does. The regulator keeps your electronics at 3.3V, but it isn’t especially picky about how. If its ground floats, it doesn’t care at all as long as the gap between its ground and its + input is at least 3.3 plus whatever margin it needs.
So your logic, which is just naturally all properly bypassed but only to the local 3.3v, could float up and down by a volt and a half and it wouldn’t even notice, because it’s all relative to the regulator only and not to the Apple. The only thing keeping these voltage levels in sync with the Apple is that one lonely ground pin.
So when you drive the bus, you’re driving up to 8 lines and you have only one line holding ground at the right level. Ground is lower impedance than the bus of course, and it will settle back down, but during the short (for a 1MHz system) critical 50ns or so that you have to set up the data bus, it wouldn’t surprise me if ground on the card was a half a volt or more different from ground at the bus transceiver on the motherboard. And this would be enough that your low signals are more like floating signals.
Ironically, a stronger drive could actually make the problem worse!
So today we have a worse power situation than they did back in the 80s, because at least their power supply was the real power supply.
This should all be pretty easy to check out, at least. Hook one probe to the ground pin on the bus transceiver on the motherboard, and the other to your local ground, I guess the regulator is probably the only thing big enough to get a probe on, though the driver itself would be better. And see how much the difference is at the time the problem occurs.
Lots of good suggestions here. Obviously I need to find time for more testing so we can see what’s really going on. Probably something quite obvious and dull.
I’ve posted a schematic at https://www.bigmessowires.com/wp-content/uploads/2018/02/yellowstone-schematic.png
The voltage regulator is 300 mA which I think is sufficient. The Lattice software estimates FPGA use at 20mA and most of the LVC245s should use similar or less. The LVC245 that drives the bus may use more – I wasn’t sure from the datasheet – but worst case if all eight outputs sourced 24 mA that would be 192 mA.
There are 10 uF ceramic bulk capacitors on both the input and the output of the voltage regulator.
It’s certainly possible the regulator or bulk capacitors or ground connection are insufficient, but from my limited testing I didn’t see any sign of this. I never observed the 3.3v supply fluctuating with respect to the Yellowstone ground or the Apple II motherboard ground. I didn’t test it extensively though, nor test it at more than one point on the board, so I might have missed something.
A couple of easy tests based on the above suggestions would be to run an extra ground wire to the motherboard, and solder a larger electrolytic capacitor across the 3.3V supply. I’ll probably try both of those.
What is your 3.3V regulator? It obviously must be an LDO. Some LDOs are finicky about minimum and maximum bypass capacitance and ESR.
What are your equations for EN245?
Over dinner I was discussing the problem with a friend, and it occurred to us that the LVC245A might actually turn off too fast and violate required hold times on the data bus. However, that seems like it would get _better_ with more cards on the bus, rather than worse, due to increased bus capacitance.
Fluffysheap wrote “Ironically, a stronger drive could actually make the problem worse!” It shouldn’t. The driver won’t sink more current than the sum of the input source current of the loads, which should be well under the 24mA rating of the LVC245A. Similarly the drivers won’t source more current than the sum of the input sink currents of the loads. The driver could be rated at 100A, but is still only going to source or sink based on the loads. (That’s basically a function of the resistance of the inputs of the loads to Vcc and GND, but the input resistances are nonlinear, so they specify maximum input currents instead.)
A high-power driver can cause more problems if there is a short circuit, though.
Where you run into trouble with drivers is more a matter of their propagation delay and output edge slew rate. The faster those are, the higher the transient current drawn from the power supply will be when the driver is first enabled, or it’s input changes state. Fast slew rate can also cause ringing, but that should settle because Apple II bus timing is so slow (by modern standards). If slew rate is a problem, going to 74LVT buffer might make it worse, as LVT probably has even faster output slew rate than LVC, though I haven’t checked. Unfortunately the data sheets don’t usually specify the output slew rate independently of the propagation delay.
As I pointed out in another post, it might be that the LVC245A turns off too fast and data hold time is violated. I think that’s somewhat unlikely, but worth checking.
I’d recommend making sure the data bus LVC245A has really good bypassing. I’d put a 0.1uF ceramic cap as close to the GND pin as possible, with as short a lead to +3.3V as possible.
One minor comment on the schematic. On the next rev, I’d suggest adding buffering of all of the signals that are driven from the FPGA to the drive connector. That will avoid any possible problems due to TTL inputs on the disk drive wanting to pull the interface signals up to +5V (or possibly third-party devices that might actually have pullup resistors on some signals).
\”I also discovered that a real Liron card doesn’t work in the IIgs… it won’t be possible to add a second Smartport to a IIgs\”
Is this important? The Liron card is nearly useless in a IIgs because the built-in Smartport is a superset of the Liron functionality anyway. And there\’s no problem with attaching several drives to one Smartport. I think the theoretical limit is 128 or something.
A second card is useful in the IIgs when it becomes impractical to daisy-chain all the different drives you’d like to have, due to the Apple II’s rules for the order the drives must appear in the chain. It also make it possible to do things like attach two Floppy Emus, which isn’t otherwise possible.
I found a little time for more testing, back in the Apple IIe again. Testing with Yellowstone in slot 5, and a Disk II controller card in slot 4, with no drives connected to either one.
1. Connecting an extra ground wire between the Yellowstone card and a chip on the motherboard helped a lot. The frequency of crashes after reset dropped from 90% to 20%.
2. I’m almost certain the crash is happening during execution of the Yellowstone ROM code, rather than Yellowstone somehow causing an error in the other card. During a normal boot, the logic analyzer shows a 93ms period of near-continuous Yellowstone ROM access, which is probably running the ROM code to look for an attached drive. During a boot where the computer crashes, this ROM access lasts a much shorter random-seeming amount of time. I measured times of 0.19ms, 1.57ms, and 28.5ms.
This helps narrow the possible causes. My guess is it’s probably a voltage level issue, but it could also be a timing issue (maybe a hold time violation as suggested above) that’s influenced by voltage or capacitance changes. Unfortunately this is all the time I have to look into the problem for the moment.
I finally found a little time to hook up the scope. It had been so long since I last used it, I’d mostly forgotten how.
Using a ground point on the Apple II motherboard as the ground reference, I measured Yellowstone’s ground and 3.3V supply. It doesn’t look good. At the moment when /IOSELECT is asserted (the Apple II wants Yellowstone to put ROM data on the bus), there’s significant ringing on Yellowstone’s power rails, lasting about 80 ns. The peak-to-peak of the ringing is 680 mV for Yellowstone ground and 460 mV for 3.3V. This was measured at a point on the card opposite from the LVC245 chip that drives the data bus, since it was the only spot I could attach scope probes. Still, that looks like a smoking gun right?
Well, maybe not. During periods when the Apple II is idle and there’s no card access happening, I measured the exact same ringing on Yellowstone’s ground and 3.3V. Aargh, why?? See the scope plot here, where blue is GND and pink is 3.3V:
https://www.bigmessowires.com/wp-content/uploads/2018/02/DS1Z_QucikPrint1.png
For reference I should repeat this same test on some standard Apple cards, since a certain amount of noise/ringing is unavoidable. But I can’t explain why there would be this much supply ringing relative to Apple II ground, even during periods where Yellowstone isn’t accessed and is doing “nothing”.
To answer the earlier question, the voltage regulator is a Micrel MIC5504-3.3YM5-TR. I don’t recall that it had any special requirements for bypass capacitor ESR.
For comparison I repeated the Yellowstone scope test on a standard Disk II card’s GND and +5V, during a time when the system was idle. The Yellowstone card wasn’t installed in the computer. Peak-to-peak ringing on the Disk II card’s GND was 600 mV and on +5V was 280 mV: less than with Yellowstone, but still pretty bad. So… I’m not sure what to make of this.
That’s surprisingly bad for the Disk II card.
What sort of power quality is coming out of the Apple power supply? It’s 35 years old and might have bad caps. You might find that the scope detects bad power that wasn’t apparent with whatever you were testing before (a DMM?)
What condition are the card slots in? They might be corroded from age. Check the resistance between a pin on a card in the slot and the equivalent pin on the motherboard bus driver or power supply.
This could explain why you have sporadic crashes even with genuine Apple hardware.
—
I admit I hadn’t considered the case of multiple floppy emus. I guess that might be a common thing for you – I didn’t think anybody would need more than one at a time. For the drive order restrictions, I don’t know. IIRC the only restriction is that 5.25″ drives have to be at the end. Annoying if you are trying to mix them with floppy emu or something else that doesn’t have an output, but 5.25″ controllers are common and you could just as well put them on one of those.
Hi Steve!
any updates on the Yellowstone card?
Hey Steve,
I know this is about 4 years old….but, I’m curious if this was ever solved?
The reason I’m asking is I have a similar issue with the Yellowstone card crashing the system. My setup is as follows. Apple//e Platinum
Slot 7 – Microdrive/Turbo (ReactiveMicro)
Slot 6 – Empty
Slot 5 – Yellowstone (3.5″Drive)
Slot 4 Mouse Card
Slots 3-1 Empty
It Crashes every time there is no disk in the drive, even if no drive is attached. On power up or on ctrl-OA-Reset.
If I have a bootable disk in the 3.5″ it still crashes on power up, however oddly on ctrl-OA-Reset it will boot from the 3.5″ attached to the Yellowstone in slot 5. Completely ignoring the Microdrive/Turbo in slot 7.
If I pull the Yellowstone card out. It all works as designed and boots from Slot 7 every time.