BlueSCSI does not boot Mac SE

Hi @zefrenchtoon ! Thanks for the help thus far. I've looked at both of those issues. I changed my SD card to a 64GB one that matched the speed setting (10). I formatted it with the special formatting tool on my MacBook Air M2, which took ages as it was over a USB 2.0 multi-memory card adapter. Then I added a pre-made image. When I tried it in the BlueSCSI it failed just as before. It doesn't crash if the PICO is powered by USB plugged into a Mac, but it does crash as described above when powered directly.

I think the next step is to try the discord server. OK, that didn't get very far. Clicking on "Accept Invite" just generates the error message in red:

1781119616389.png
Hmmm.
 
Hi @zefrenchtoon ! Thanks for the help thus far. I've looked at both of those issues. I changed my SD card to a 64GB one that matched the speed setting (10). I formatted it with the special formatting tool on my MacBook Air M2, which took ages as it was over a USB 2.0 multi-memory card adapter. Then I added a pre-made image. When I tried it in the BlueSCSI it failed just as before. It doesn't crash if the PICO is powered by USB plugged into a Mac, but it does crash as described above when powered directly.

I think the next step is to try the discord server. OK, that didn't get very far. Clicking on "Accept Invite" just generates the error message in red:

View attachment 100022
Hmmm.
Hum this is very strange.
I will try to share your post on discord to let them know you have these problems.
 
Here is the answer:
View attachment 100025


Question: is your PSU clean ? Is the 5V rail strong enough ?
It's a BlueSCSI v2 desktop that I intend to stick inside a standard SCSI enclosure, which I was doing to begin with. So, the intended chain of connections is: PowerBook1400 => Dock/SCSI adapter => Zip Drive SCSI cable (DB25 at either end) => SCSI Zip Drive => DB25 to Centronics SCSI cable => Pretty standard SCSI HD enclosure with its own power supply.

My initial tests prior to putting it in the enclosure appeared to work, they say to power it up via USB and no SD card and observe the 5x flashing sequence. Then reboot with an SD card in and check it doesn't do a 3x flashing sequence. I had done that, and I didn't see any activity on the latter test (but I'm pretty sure it had a steady green LED), so I though it was OK. I then I attached it to the SCSI enclosure and powered it with the Berg connector and of course it didn't show any activity, but a steady green LED. It was then, when I turned it off and checked the SD card I discovered it had crashed.

So, since then I've been using it outside of an actual SCSI enclosure and powering it over USB either via a Mac (which doesn't crash) or via a a USB power supply (e.g. an old Apple 2.1A USB-A PSU plugged into a USB-A to micro-USB cable). It's the latter case which crashes. It only has to power the PICO, the built-in BlueSCSI logic ICSs & the SD card in this case.

Does that help? I've added a discussion item!
 
Last edited:
@zefrenchtoon : I had an answer from a developer. It seems like it's an RP2040 B0 silicon issue.


He's asked me to compile it myself, so I'll need to update the sdk and probably Gcc!
 
@zefrenchtoon .

So, Eric got me to build BlueSCSI from source. I had quite a bit of faff installing the arm-none-eabi gcc tools version 14.2, because homebrew wanted to install gcc 15 and BlueSCSI expects gcc 14. Homebrew also provided links to Arm's toolchain, but only links to 15.2 for macOS ARM and 14.2 for macOS Intel. But I managed to deduce what the link for the .pkg needed to be for ARM. I downloaded and installed the .pkg; then followed the PICO setup instructions for assigning the PICO toolchain path (I also added a default path for arm-none-eabi).

Then I followed the build instructions for BlueSCSI. This actually worked first time..

Summary: 0 over fail threshold, 15 warnings, 1509 total functions

And it did generate a .elf:

text data bss dec hex filename
457560 0 120988 578548 8d3f4 /Users/julianskidmore/Development/pico/BlueSCSI-v2/build/Pico/BlueSCSI_Pico.elf

As well as a .uf2 in the output directory.

Then I was able to successfully test it. Here's the link to my comment on the testing:

https://github.com/BlueSCSI/BlueSCSI-v2/discussions/384#discussioncomment-17268612

So, next I'll be able to move onto some more ambitious uses!

[Edit: * I thought I'd provide the homebrew link for macOS ARM gcc 14.2 :

The homebrew page is:

https://formulae.brew.sh/cask/gcc-arm-embedded

The link to the macOS ARM, arm-none-eabi gcc tools 15.2 is:

https://developer.arm.com/-/media/F...hain-15.2.rel1-darwin-arm64-arm-none-eabi.pkg

And for macOS Intel, arm-none-eabi gcc tools 14.2 for Tahoe is:

https://developer.arm.com/-/media/F...ain-14.2.rel1-darwin-x86_64-arm-none-eabi.pkg

So, logically, macOS ARM, arm-none-eabi gcc tools 14.2 for Tahoe should be:

https://developer.arm.com/-/media/F...hain-14.2.rel1-darwin-arm64-arm-none-eabi.pkg

Which turns out to be correct!

Amazingly, Homebrew also provides a link to macOS Intel GoldenGate, arm-none-eabi gcc tools 14.2! Gosh, what clever bods ARM must be to achieve that ;-) !

Just in case anyone is wondering how these packages install arm-none-eabi. In fact the .pkg merely copies the tools to a location on your hard disk that you specify and by default that's the root, I think. I didn't do that, I specified my PICO directory. Then I had to edit my .bash_profile to modify my PICO_TOOLCHAIN_PATH to point to the parent directory of the bin directory (because the include and library directories are there too). I also added a direct path to the bin directory so I could use it directly. That's a bit more involved than one normally expects from Homebrew, which installs everything in its own directory, so as soon as a package has been installed, there's a path to it on the command line without you even having to exit and open a new shell.

]
 
Last edited:
Back
Top