BlueSCSI v2 - DaynaPORT WiFi!

[JDW]

@alexADB
Before doing anything else today, I used my DMM in Continuity Check mode to touch every adjacent pair of pins. None were connected together.

After that, my Hakko FR-301, combined with the fresh solder I had applied when soldering-in the PICO W, made quick work of desoldering the PICO W. I then pressed the white button and at the same time connected a known-good data cable between my late 2015 17" 5K iMac (running Mac OS Mojave) at the office. What do you know... It mounts properly as "RPI-RP2"!

I now have one question...

Should I copy the *.uf2 file to it before I solder it back to the BlueSCSIv2 board?

The reason I ask is because the INSTRUCTIONS say that after you copy the file to the PICO W board (while mounted on the BlueSCSIv2 board), it will then auto-eject from the Mac. But I don't know if that Auto-Eject function (and whatever else it does behind the scenes) is exclusive to the PICO board (which means it can be done desoldered from the BSv2), or if the BSv2 board works that magic through the PICO. That's why I would appreciate knowing if copying the file to the PICO while desoldered from the BSv2 board is OK, or if it's a big NO-NO.

Thanks!

 

[alexADB]

That is good news! At least one step further
I think the described upgrade mechanism is the standard Pico way to do it. So AFAIK you can install the firmware when the Pico is not yet soldered to the Blue SCSI board.

See here e.g. https://micropython.org/download/RPI_PICO_W/

Good, that you have this tool. Desoldering the Pico without something like that was such a pain.

 

[JDW]

Perfect advice. Thank you!

I just copied to *.uf2 file to the PICO W and it ejected, as expected. The tiny GRN LED nearest the USB connector flashes 5 times repeatedly. I will solder it back to the BSv2 and then test later tonight.

I appreciate your help.

 

[alexADB]

That sounds very good! Fingers crossed that your Mac will like it. Good luck and you‘re welcome

 

[JDW]

Fingers crossed that your Mac will like it.

One last question before I solder the PICO W onto the BSv2...

When I put back the regular PICO on the BSv2, the pins make good contact, such that I can press the button on the PICO and connect the USB cable to my Mac. And as is the case with the PICO W, the regular PICO too causes both LEDs (marked "PWR" & "ACT") to light solid as long as the USB cable is attached. Do both LEDs light solid on your BSv2 when the PICO is connected to your computer via USB?

The reason I ask is because when I attached my BSv2 with PICO W (soldered) to my Mac IIci yesterday, it wouldn't boot and both LEDs were lit solid the entire time. Normally, the ACT LED flashes and is not lit solid. My fear is, unless there is a good explanation for both LEDs being lit solid, I may end up re-soldered this PICO W and find the result to be exactly the same.

 

[Androda]

One last question before I solder the PICO W onto the BSv2...

When I put back the regular PICO on the BSv2, the pins make good contact, such that I can press the button on the PICO and connect the USB cable to my Mac. And as is the case with the PICO W, the regular PICO too causes both LEDs (marked "PWR" & "ACT") to light solid as long as the USB cable is attached. Do both LEDs light solid on your BSv2 when the PICO is connected to your computer via USB?

The reason I ask is because when I attached my BSv2 with PICO W (soldered) to my Mac IIci yesterday, it wouldn't boot and both LEDs were lit solid the entire time. Normally, the ACT LED flashes and is not lit solid. My fear is, unless there is a good explanation for both LEDs being lit solid, I may end up re-soldered this PICO W and find the result to be exactly the same.

Allow me to explain.

The RP2040 microcontroller used on these Pico boards has one design decision that strikes me as fairly dumb with how modern systems work. When the chip initializes and starts up, every GPIO pin is set up in "pull down" mode. This means every pin tries to pull the signal down to ground. Naturally this is problematic for SCSI where "pulled down" means "this signal is active" (it's an inverted bus where high means false or 0 and low means true or 1).

Every other microcontroller I know of starts with all the GPIO pins in "floating" mode meaning that they are not pulled up to a high signal or down to a low signal. The pin waits for configuration before doing that sort of thing.

Your Pico-W sounds like it was in an "uninitialized state" when tried on the IIci because the firmware was not flashed to it. The firmware is necessary for proper operation, because the RP2040 doesn't know what to do without it. Without the firmware, every output signal was "pulled low" by default as is set up in the RP2040's internal boot ROM, and that's why the ACT LED was on all the time.

ACT is connected to the "BSY" output signal that is used to indicate to the SCSI bus that BlueSCSI has been selected and is in communication with the host device. Without the firmware to tell the RP2040 what to do with that pin it sits low forever, and remember that "low" means "true" so ACT lights up and stays lit indefinitely.

We have had a small number of reports of this sort of thing, where the Pico stick doesn't seem to want to accept firmware. In the other cases, several USB cables were tried until one worked. It should not be necessary to remove the Pico from the BlueSCSI base board before it will show up via USB and accept firmware. I reflash test boards regularly while installed with no issues.

 

[JDW]

@Androda
I sincerely appreciate your kindness in providing such a detailed explanation!

QUESTION
I downloaded this *.uf2 file from this page. Those UF2 files are the "firmware" you spoke of in your post, correct?

If so, it is good because it's installed on my PICO W. At least, I think it is installed because it mounted on my Mac and after I copied the UF2 file to the mounted PICO W, it ejected.

I will now solder the PICO W back to the BSv2 and test later tonight after work.

 

[JDW]

Well, I guess the UF2 file must indeed be the "firmware" mentioned by @Androda because I just finished soldering the PICO W back to the BSv2 board and then tested on our PowerMac 9600 at the office, using the excellent OverEasyII SCSI adapter by @Stephen . Booted the 9600 right away into System 7.6.1!

I still need to test on my IIci tonight, but it just dawned on me that my IIci has external power attached, rather than just using the SCSI cable alone. Is +5V and GND even needed on the IIci? I'd not thought of it before because the IIci came with a green-colored BSv2 (with PICO W) attached inside, and it had the +5v and GND connected. But that should have anything to do with the trouble I've been seeing, since the green colored BSv2 always worked just fine.

Hmmm...

Anyway, I will test on the IIci tonight and report back then.

 

[Androda]

@Androda
I sincerely appreciate your kindness in providing such a detailed explanation!

QUESTION
I downloaded this *.uf2 file from this page. Those UF2 files are the "firmware" you spoke of in your post, correct?

If so, it is good because it's installed on my PICO W. At least, I think it is installed because it mounted on my Mac and after I copied the UF2 file to the mounted PICO W, it ejected.

Correct. As mentioned on the Updating Firmware page of the Wiki, the ".uf2" files are the firmware.

You can tell that it's installed onto your Pico by applying power without an SD card present. The Pico's LED will flash 5 times, pause (with LED off), and then loop again with the 5 flashes. It does this forever until an SD card is detected.

I still need to test on my IIci tonight, but it just dawned on me that my IIci has external power attached, rather than just using the SCSI cable alone. Is +5V and GND even needed on the IIci? I'd not thought of it before because the IIci came with a green-colored BSv2 (with PICO W) attached inside, and it had the +5v and GND connected. But that should have anything to do with the trouble I've been seeing, since the green colored BSv2 always worked just fine.

I suspect that the IIci does not need floppy power. But it's fine to leave that connected, and probably a good idea when WiFi is in use. The floppy power connector will be more able to provide the large bursts of current that WiFi needs, as the bare SCSI cable provides only "termination power" which is intended for termination specifically and has a lower value fuse.

 

[JDW]

Correct. As mentioned on the Updating Firmware page of the Wiki, the ".uf2" files are the firmware.

You can tell that it's installed onto your Pico by applying power without an SD card present. The Pico's LED will flash 5 times, pause (with LED off), and then loop again with the 5 flashes. It does this forever until an SD card is detected.



I suspect that the IIci does not need floppy power. But it's fine to leave that connected, and probably a good idea when WiFi is in use. The floppy power connector will be more able to provide the large bursts of current that WiFi needs, as the bare SCSI cable provides only "termination power" which is intended for termination specifically and has a lower value fuse.

I’m happy to report it is now working in my IIci as well. So I guess when telling people how to swap out their PICO for a PICO W, it’s important to tell them to first update the firmware on the PICO W and then after that solder it down.

I also tested both of my BSv2’s without the power connector and it was able to browse the web just fine, but I can see the logic in what you said about it being even better to have dedicated power attached.

Anyway, I’m very pleased that my upgrade to the PICO W was ultimately successful. And of course it is all thanks to the excellent help that I received here! I really appreciate that very much, and hope my experience helps others who wish to walk in my footsteps.

 

[alexADB]

Cool, that it works now! Congratulations! As much as I remember you can update the firmware even when the pico is soldered in. But it must not be connected to the SCSI interface, maybe.

 

[Androda]

Cool, that it works now! Congratulations! As much as I remember you can update the firmware even when the pico is soldered in. But it must not be connected to the SCSI interface, maybe.

As mentioned before, I regularly update the firmware on test units without removing the Pico from the board. Generally I remove it from the SCSI bus, then do the USB update method.

 

[eric]

I've been busy with irl things this week but I almost always update while it's connected to the bus.

 

[JDW]

I can only say with near 100% certainty that my soldering job was not the issue to the problem I reported earlier. After I installed the firmware, that was the resolution to the problem. Whether that firmware install be done in the PICO W alone or while soldered to the BSv2 board, that shouldn't matter. When I tested the fresh PICO W without the firmware upgrade, I got both LEDs lit and it wouldn't boot. But with the latest firmware, it then started to boot.

 

[Androda]

After I installed the firmware, that was the resolution to the problem. ... When I tested the fresh PICO W without the firmware upgrade, I got both LEDs lit and it wouldn't boot. But with the latest firmware, it then started to boot.

A Pico W that does not have the firmware installed cannot function as a BlueSCSI. The firmware is what makes everything work. Did that Pico W have firmware installed when you first tested in the IIci?

 

[JDW]

A Pico W that does not have the firmware installed cannot function as a BlueSCSI. The firmware is what makes everything work. Did that Pico W have firmware installed when you first tested in the IIci?

No, it did not have the firmware installed before I soldered the PICO W to the BSv2. And after it was soldered, I connected the USB cable, but as I said in my earlier post, it would not mount and therefore I could not copy any firmware to it. I then desoldered it and was able to copy the firmware file to it, and after that I soldered it back and tested and it worked fine. And like I said, I’m nearly 100% sure that my first desoldering and soldering job was quite nearly perfect.

 

[Sideburn]

I got some time in today to try out the latest firmware with a BlueSCSI DB25 and a pico W.
I set it up so it connects to my router and I can watch it connect form my iPhone when I power it on.

It works well under System 7.1 with Open Transport (I used the installers on the "HD4 BlueSCSI v2 PicoW Setup.hda" disk image).

But I have not been able to get it to work with MacTCP.

• When I tried it on a clean System 7.1, I can get as far as ping working when I ping my local ip, or 1.1.1.1 or 8.8.8.8. All good there but as soon as i try http in a browser the DNS lookup fails an no pages will load.

• I then tried the Macintosh Portable (MacTCP is required here because Open Transport needs an a 68030 or higher) with either System 7 or System 6, the mactcp ping tool complains that it cant see the macTCP driver. I verified that the blueSCSI is connected to my network so theres no problem there. Not sure how to resolve it.

** Another issue I had not related to wifi really but but the BlueSCSI itself when copying files..

I had two disk images mounted on the same card.. One was the "HD4 BlueSCSI v2 PicoW Setup.hda" and my other was "HD3-Backup-1GB.img".
When I selected multiple folders from the PicoW Setup disk and copied them to my other drive, the copy session started and it gets about 1/3rd of the way through and then gets a -192 error and the SD card is shot.. all data is gone and i have to reformat it. I tried several times and could reproduce it each time..

When I copied the contents one folder at a time then I had no issues. So it was somehting to do with copying a large bulk of data...
There was only a problem when copying from the "BlueSCSI v2 PicoW Setup." when copying from one bluescsi to another theres no issues at all. not sure what that was all about

 

[Sideburn]

Ok my bad on MacTCP it looks like… just got it working on system 7.1. It uses much less ram and seems zippier than OT. A good choice for a ram starved PowerBook 180.

that multiple folder copying thing is still a mystery. Just wanted to put it out there incase someone wanted to try to reproduce it and fix it if it’s a bug

 

[Sideburn]

So the only thing holding me back from installing a pico W internally for Wi-Fi in the PB180 instead of an external db25 is two things.

• The initial wifi connect has been a bit spotty. As mentioned I can monitor it connecting from my iPhone app upon powering up the BlueSCSI before plugging it into the PB. Some times it takes several power cycles until it connects to my router.

Also, if the connection drops in never re-connects and I have to reboot.

• Need a way to edit the SSID and password without having to open the PB back up and pulling the SD card. That control panel looks like it might resolve that.

Otherwise this is super impressive. Awesome job guys. I love it. It’s fast too in my opinion.

I’ve downloaded a ton of zips and .sits from Macintosh garden as well as my own webserver. I get around 30 to 50k per sec. About a minute a megabyte or so I think. Acceptable!

I’ve FTP’d to my file servers, Telneted to some BBS’s (including kludge), got file sharing setup but killed a BlueSCSI when swapping out the pi to a pico w so that has to wait (my desolder was good but I think it still killed a trace or two. It can’t find the SD card anymore).

A perfect solution for getting files onto a PowerBook since you have no access to the SD card.

I setup a Netscape with a white background, turned off all the extra buttons and set the nav ones to text only. Changed the fonts to 10pt monoco, and turned off JavaScript and you’ve got a pretty decent browser for frogfind and Macintoshgarden.

sweet!

 

[Androda]

** Another issue I had not related to wifi really but but the BlueSCSI itself when copying files..

I had two disk images mounted on the same card.. One was the "HD4 BlueSCSI v2 PicoW Setup.hda" and my other was "HD3-Backup-1GB.img".
When I selected multiple folders from the PicoW Setup disk and copied them to my other drive, the copy session started and it gets about 1/3rd of the way through and then gets a -192 error and the SD card is shot.. all data is gone and i have to reformat it. I tried several times and could reproduce it each time..

When I copied the contents one folder at a time then I had no issues. So it was somehting to do with copying a large bulk of data...
There was only a problem when copying from the "BlueSCSI v2 PicoW Setup." when copying from one bluescsi to another theres no issues at all. not sure what that was all about

This is interesting, and strange. I believe there have been reports in the past of SCSI drivers not playing nicely together and causing corruption like this. If you use SCSI Director Pro and install the same driver on both images, does this data copy corruption issue still happen?

The SCSI driver being "hidden" is a huge frustration, especially given that some of them seem to be incompatible.