BlueSCSI on Macintosh Portable

[JDW]

Okay, no replies. That means, I need to clarify to provoke people to reply!

When I said the ACT LED was flashing in my previous post, I meant in that special way it does when WIFI is active, not when there is disk activity.

Seems pretty clear there is a wake-from-sleep bug taking place here that is tied to WIFI. I never get the freeze on wake when WIFI is not active (when that special LED flashing is not present).

Again, I would love to hear your thoughts on this. Thanks!

 

[JDW]

Well, I have confirmed the problem exists in System 7.1 too.

The problem is Wake from Sleep causes a Freeze under 1 condition: WIFI was active (as per the special flashing of the BlueSCSIv2 "ACT" LED) when you put the machine to Sleep.

Before I installed the DaynaPort drivers, I tested Sleep extensively. No freezing on Wake, EVER!

After I installed the DaynaPort drivers and got everything setup, I get a consistent freeze 100% of the time if and only if the ACT LED on BlueSCSIv2 is flashing in that special way it does when you have initiated WIFI access (even by simply using PING). But if you don't initiate any WIFI access, the ACT LED will not flash continually, and under that condition you can Sleep and Wake without a freeze.

The problem is, once you initiate some kind of WIFI access, there's no way to manually stop that ACT LED from flashing, except to Restart. So effectively, you can no longer Sleep your Portable (or allow it to auto-sleep) if you initiate any kind of WIFI access via BlueSCSIv2 with PICO W.

It would be great if the root cause of this bug could be nailed down and fixed.

It would also be good if another Portable owner could kindly do the same confirmation I did.

 

[Paolo B]

So, I switch to this thread for sharing the latest updates about the issues I was having with the BlueSCSI v2 v2022.12a Wi Fi on my M5120 Portable.
Brief recap: after attempting the pull up resistors mods for preventing the system from crashing upon wake up from sleep, my BlueSCSI unit just stopped working. Eventually, I could identify that the Pico W board was toasted.
Root cause: unknown. In fact, I must amend my previous statement and confirm what remarked by @Androda, i.e. it's almost impossible to invert the polarity of the power connector. So, the Pico board did not get busted by accidental polarity swap.

Anyhow, switching to a new Pico W did not change the situation: the Pico would not be recognised when connected via Usb. I thought I busted another one. However, as last measure before throwing everything into the bin, remembering the experience of @JDW I desoldered it and - surprise - it was perfectly OK. So, the issue must have been on the board side. Everything was looking OK, clean and neat. Nonetheless, as last resort before giving up I washed the board with hot water and dish detergent. And - voilà - it just sprung back to life as new.
Must have been some residual flux or whatever under the connectors shorting or messing up the signals.
So, next step has been of course re-doing the "3 resistors" mod. This time everything worked. Except... the Portable still crashes all the times, absolutely no difference compared to previous situation.

Any suggestion on what to test next (likely: hardware-wise) is more than welcome.
Portable M5120, 5 Mb RAM, System 7.1.1. BlueSCSI v2 2022.12a Firmware 2024.04.02, powered by 5V / 12 V derived from Portable inner SCSI interface, according to the scheme available in the "Resources" section of this forum.
Thanks!

 

[Androda]

So, the issue must have been on the board side

I don't know what causes this presumption. The BlueSCSI PCB does not connect to the Pico's USB data pins on a 2022.12a hardware version. The only common connection is ground, as the USB ground flows through to the Pico's ground pins.

This situation has come up a few times in the BlueSCSI support Discord server, where it appears that a Pico will not program unless it is removed from the BlueSCSI PCB. Several times now, people have tried different USB cables and different computers and that has resolved the problem.

Naturally this situation has never happened for me locally so I've been unable to duplicate it to try and work through to a cause. I run Linux on various computers from Lenovo, Asus, etc and don't use modern Apple hardware (Intel or their newer ARM stuff). It could be that more recent Apple devices are simply less compatible with USB 1.1 which the Pico speaks, or there could be a variety of other reasons for which I am unable to test.

 

[Paolo B]

I don't know what causes this presumption. The BlueSCSI PCB does not connect to the Pico's USB data pins on a 2022.12a hardware version. The only common connection is ground, as the USB ground flows through to the Pico's ground pins.

This situation has come up a few times in the BlueSCSI support Discord server, where it appears that a Pico will not program unless it is removed from the BlueSCSI PCB. Several times now, people have tried different USB cables and different computers and that has resolved the problem.

Naturally this situation has never happened for me locally so I've been unable to duplicate it to try and work through to a cause. I run Linux on various computers from Lenovo, Asus, etc and don't use modern Apple hardware (Intel or their newer ARM stuff). It could be that more recent Apple devices are simply less compatible with USB 1.1 which the Pico speaks, or there could be a variety of other reasons for which I am unable to test.

Good to know that. However, fact is that I could not program (not even mount) the Pico before desoldering it, cleaning the board, soldering it back, cleaning everything back again. By chance or not, it is now not missing a beat when I try to mount it on my Mac. Could have been something else, sure.

Btw, I was wondering if it would be possible to socket somehow the Pico for this exact reason, as desoldering is not ehm… very practical.

As for the hardware, I have just one mini USB cable which is fully functional with the many devices I have, and I use a relatively recent “trashcan” Mac Pro. Don’t have any other hardware for making additional testing.

 

[JDW]

I have just one mini USB cable which is fully functional...

"Fully functional" in terms of "data transfer" is key, and I know that is what you mean here. Even so, if you every decide to buy another "data" cable as a backup, it's a good idea. There are charging-only cables that screw up everything. I hate those and try to trash them when I find them. The data cables can provide data and charging.

Eventually, I could identify that the Pico W board was toasted.
Root cause: unknown...
Anyhow, switching to a new Pico W...

Just to clarify, you got your BSv2 working, but you said you toasted one PICO W but the new one in your BSv2 is now working. So you confirmed without any doubt the previous PICO W was and still is dead?

Btw, I was wondering if it would be possible to socket somehow the Pico for this exact reason, as desoldering is not ehm… very practical.

Yes. The PICO will be raised up higher, but that shouldn't be an issue in the Portable, but your bracket is probably different from mine so I don't know how high up your board sits in the bracket.

Short Socket Headers for Raspberry Pi Pico - 2 x 20 pin Female

These Socket Headers alone are, well, lonely. But pair them with the Raspberry Pi Pico, and you're in business!These headers are particularly cute and tiny with a body ...

www.adafruit.com

... the Portable still crashes all the times, absolutely no difference compared to previous situation.

You can boot off a real floppy disk and/or the FloppyEMU, correct? Meaning, only the BSv2 is a problem? If so, what about booting from another SCSI device, either internally or externally? Be aware that termination of a real HDD can be an issue. If you attached an external HDD, make sure it is terminated.

 

[Paolo B]

"Fully functional" in terms of "data transfer" is key, and I know that is what you mean here.

Yes, correct. Data cable, tested working on other devices.

Just to clarify, you got your BSv2 working, but you said you toasted one PICO W but the new one in your BSv2 is now working. So you confirmed without any doubt the previous PICO W was and still is dead?

Yes, out of the two I had (the plain Pico and the Pico W I successfully replaced like as soon as the Wi-Fi option became available), the plain one has the voltage regulator busted, the W one seems to output the correct voltage, but there's no way to mount it.

Short Socket Headers for Raspberry Pi Pico - 2 x 20 pin Female

These Socket Headers alone are, well, lonely. But pair them with the Raspberry Pi Pico, and you're in business!These headers are particularly cute and tiny with a body ...

www.adafruit.com

Thanks for the link, it's exactly what I was looking for!

You can boot off a real floppy disk and/or the FloppyEMU, correct? Meaning, only the BSv2 is a problem? If so, what about booting from another SCSI device, either internally or externally? Be aware that termination of a real HDD can be an issue. If you attached an external HDD, make sure it is terminated.

After replacing the Pico W with a new one and after cleaning the board thoroughly, everything is now back in working order. Same as new. However, despite the pull up resistors modification, the Portable is still crashing in exactly the same way as without the mod.
I read 3.3V sharp at the pins. However, when I put the Mac on sleep, it goes to 0V and then it takes some seconds before getting back at 3.3V after waking it up. In the meantime the Mac has already crashed.

 

[JDW]

...despite the pull up resistors modification, the Portable is still crashing in exactly the same way as without the mod.
I read 3.3V sharp at the pins. However, when I put the Mac on sleep, it goes to 0V and then it takes some seconds before getting back at 3.3V after waking it up. In the meantime the Mac has already crashed.

Not being a BSv2 designer, I am ill equipped to comment about why that happens, but perhaps @Androda can share some thoughts when he has some time.

The only thing I can share is my experience with my 2023.03a "forked" BSv2 (with PICO W). The resistor mod seems to have worked for me. Even so, I never tested my BSv2 in the Portable prior to the resistor mod to see if it crashed on Wake from Sleep (probably would have). My board is "forked" only because Joakim Larsson created a very slightly modded version that puts the Portable's 34-pin SCSI connector on it. So no need for adapters. It was a gift from him to me. He isn't commercially selling these. He made some, had an extra, and very graciously sent me one. i added a PICO W to it, then did the resistor mod, then tested, and it worked in my 5126 Portable. (Well, only if there is no WIFI activity happening when I Sleep the Portable. If there is, WIFI activity when I Sleep my Portable it freezes on Wake. If no WIFI activity, it wakes just fine. Androda gave me a diode-isolated wire fix for that which works great, but I'm afraid to leave it installed because I would need to use a male pin in the PDS connector, and if it ever slips out, it would possibly short on something.)

Anyway, Joakim sent me a ribbon cable too, but the connector fit so tight that it broke apart when I removed it, so I purchased this cable off EBAY, which is a very nice cable, just like the SCSI cables Kay Koba makes, but this one is ready made with 34-pin connectors already attached. Wire's are soft and separated in places, which lets me easily wire-tie them similar to the stock SCSI cable.

 

[Androda]

I read 3.3V sharp at the pins. However, when I put the Mac on sleep, it goes to 0V and then it takes some seconds before getting back at 3.3V after waking it up. In the meantime the Mac has already crashed.

Hmm, do you mean the 3.3v line "slowly rises from 0 to 3.3v" like 0.5v, 1v, 2v, etc. or that it rapidly jumps from 0 to 3.3 but it takes a long time to come back on?

I've done some testing over lunch and discovered a very interesting behavior on the Portable.

If you put it to sleep, wait a little bit, then wake it back up the power LED on BlueSCSI comes back on very rapidly after wake-up. Something like a second or less.

If you then put the Portable back to sleep, wait a bit, and wake it up - the power LED does not come back on until disk access is necessary. I was able to move windows around in the Finder and such without making SCSI power come back on. But when disk access was needed to load About This Macintosh, the BlueSCSI power LED turned on and disk access continued as usual.

So the Portable is capable of operating without any power to the SCSI bus at all when awake. And only summons the SCSI bus when necessary.

Same as new. However, despite the pull up resistors modification, the Portable is still crashing in exactly the same way as without the mod.

I don't have any way to debug this unfortunately. My BlueSCSI sleeps and wakes without issue after the resistor modification. And later BlueSCSI units are sold with that modification on the PCB directly.

 

[Paolo B]

I just did a quick check: first, I monitored the voltage at the GP19 pin. The voltage raises very quickly to 3.3V as soon as the Mac is trying to access the disk during boot sequence. It stays at 3.3V sharp all the time. When I put the Mac on sleep, it drops to 0V almost instantaneously. On wake up, it also goes back to 3.3V super quickly.
However, the voltage on the GP27_A1 pin varies "erratically" during the boot phase and then it stabilises at 3.3V as the boot is complete, disk mounted, Mac just waiting for inputs. When I put the Mac on sleep, it drops to zero very quickly. When I wake it up, it remains at 0V for a few seconds, during which the Mac is redrawing the desktop. It then goes to 3.3V, but at that point the machine has already crashed.
Short video here:

 

[Androda]

GP27_A1 pin

Just to double check, you are referring to GPIO #27? That GPIO pin is controls the SCSI BSY signal and is not expected to have a consistently high or low voltage. The SCSI protocol will cause that pin to bounce around from high to low rapidly.

The only place to reliably check 3.3v regulation is the 3V3(OUT) pin number 36 in this diagram: https://learn.adafruit.com/assets/99339

All other pins labeled GP will fluctuate as the SCSI protocol or SD protocol dictates and can't be used to verify regulator functionality.

 

[Paolo B]

Just to double check, you are referring to GPIO #27? That GPIO pin is controls the SCSI BSY signal and is not expected to have a consistently high or low voltage. The SCSI protocol will cause that pin to bounce around from high to low rapidly.

Yes, I did measure GP19 and GP27 (video): aren’t those the two pins which should be kept up by the resistors?

 

[Androda]

aren’t those the two pins which should be kept up by the resistors?

The pull resistors situationally hold those pins high. It's expected that both of them are able to transition between high and low as needed.

When the Pi Foundation created the RP2040 microcontroller they made one design decision which I think is completely wrong. All GPIO pins are "pull down" by default when the chip is booting up and loading configuration. Compare that to something like an STM32 which "floats" all GPIO until initialized (unless the GPIO pin has a default function).

SCSI uses inverted logic. 0v means "logic 1". 2.85v means "logic 0". Thus the pull-down (pull to ground) nature of the RP2040 meant certain SCSI control lines were being held in an invalid state before all the setup code could complete. This invalid state was causing issues when waking from sleep.

The added pull resistors assure that during RP2040 startup the SCSI control lines are not put into an invalid state. Later in normal operation these pins can transition between high and low voltage as needed.

The duration of "pull up is necessary" time ought to be measured in milliseconds as the firmware runs through the usual startup sequence.

 

[Paolo B]

Thanks for the clear explanation. I would like to have the time for deep diving into the complete documentation of Pico and BlueSCSI board, but indeed I don’t have any.

I did the same check measuring 3V3 (OUT) pin. What happens is that it quickly goes to 3.3V on start up. When I put the Mac on sleep, it takes some time for dropping to zero, kind of asymptotic decay. When I wake the machine up, the voltage remains at zero for that couple of seconds it takes the Mac for refreshing the screen and redrawing the desktop. Then it goes to 3.3V, but it’s too late, so to speak.

I am wondering if it has anything to do with the fact that I power the machine with the battery (no supercapacitors, as I guess both you and @JDW are using)...

 

[JDW]

I am wondering if it has anything to do with the fact that I power the machine with the battery (no supercapacitors, as I guess both you and @JDW are using)...

Indeed, I have no lead acid battery at all to use, which is why I purchased the Battery Eliminator from @Androda .

But as I have said in other threads, the Battery Eliminator has one important consideration. It acts as a never draining battery that has no charger (ac adapter) attached. That is somewhat amusing because it in fact only works with the AC adapter attached.

The downside is that any software which REQUIRES you to connect the AC Adapter in order for it to work will NOT WORK with the Portable Battery Eliminator because, like I said, the Eliminator acts as a Battery without AC Adapter attached.

None of that should matter in your case, @Paolo B , but I cannot say if there are different voltage fluctuations with the Battery Eliminator because I have no lead acid battery to test. And the wire harness that normally connects to a lead acid battery and then connects to the motherboard is totally disconnected. That motherboard connection is entirely replaced by the wire harness coming from the Battery Eliminator.

 

[Androda]

It's quite unlikely that use of the battery eliminator would cause different BlueSCSI behavior. As has been mentioned, it acts as a forever-charged battery. The Portable's power system is designed to run off the battery anyway, with the power adapter acting only to recharge the battery when system load drops below 1.5 amps.

What may be more likely is that the BlueSCSI board was damaged when the 3.3v regulator on one of the Picos failed and started pushing over 4 volts. The Pico has been repeatedly replaced with no effect, which points to the rest of the BlueSCSI hardware as suspect.

 

[Paolo B]

I don’t think the BlueSCSI board is damaged, it seems to work flawlessly.

I just did some quick test measuring the voltage directly at the molex on the 5V rail.

With the power supply connected, on wake up the voltage is restored only after the initial refresh of the desktop is completed (the warning window leaves a blank space which needs to be redrawn), whereas when I run solely on the battery, the voltage is restored immediately and before the desktop is refreshed (actually, it never gets refreshed, the Mac crashes before).

I will reinstall the OS, let’s see…

 

[Paolo B]

I took my bench PSU and powered the BlueSCSI independently from the Portable.
Issue gone: when the board is constantly powered up, there's no crash, I can put it on sleep and wake it up indefinitely.

So, I'd conclude it's not just a matter of pull up resistors, but also about the way the Mac is powered. There seems to be some kind of "inertia" delaying the 5V going live when the Portable is powered as originally intended, i.e. by a lead-acid battery with or without the external PSU.

And other SCSI devices (I only have MO drives at hand) behaves totally similarly, causing the machine to crash on wake up.

So, I am now wondering whether the original Conner drive had some special feature in the rom or whatever or if something is missing in my adapter cable: should the +5 V termination power be live?

 

[SuperSVGA]

So, I am now wondering whether the original Conner drive had some special feature in the rom or whatever or if something is missing in my adapter cable: should the +5 V termination power be live?

The Conner doesn't have anything special for termination, just pull-up resistors connected to the SCSI +5V.

 

[Paolo B]

The Conner drive was specifically designed to be a SCSI 0 ID device, somehow hard locked. The internal connector on the Portable does not map the TPWR SCSI pin 26, I assume because there is no need. However, regular 50 pin SCSI devices do use this pin, including BlueSCSI. Now, the adapter I have doesn’t feed any voltage to the pin 26. However, I tried to close the BACK_FEED jumper, but nothing changes.

I’d say the Mac is trying to access the SCSI device before it is powered up, hence the crash. I would speculate the working logic for the Portable was considering some strict sequence in the wake up procedure for allowing all peripherals to get ready before accessing them. In the end, it was the first machine of its kind.