BlueSCSI on Macintosh Portable

[Androda]

Mod boards have shipped, once those arrive I'll test the updated firmware some more and update the listing again. I already changed it to point at this thread for clarity on the speed decrease.

Likely will have two options after testing, "Plain" and "Switchable". Then going forward, future PCB runs will all have the switches.

 

[ScutBoy]

I have not been able to pull out my backlit Portable to test; would this same issue happen with the MacEffects card?

 

[Androda]

I have not been able to pull out my backlit Portable to test; would this same issue happen with the MacEffects card?

Assuming the issue is caused entirely by the size of the expansion card, yes. It should have the exact same problem.

Or in other words, the Portable seems to slow down with expansion RAM cards above a certain size due to what is either a hardware or software bug in the Portable itself.

 

[ScutBoy]

Assuming the issue is caused entirely by the size of the expansion card, yes. It should have the exact same problem.

Or in other words, the Portable seems to slow down with expansion RAM cards above a certain size due to what is either a hardware or software bug in the Portable itself.

That seems totally logical to me, but I was hoping there was maybe a lucky exception

 

[alxlab]

I wouldn't knock trying other high capacity RAM cards. Who know. Maybe one of them might have some kind of trick.

 

[pocketscience]

I have a collection of pretty much all Portable RAM cards.. that I'm aware of anyway. I will try find some time and document the experience with each.

 

[SuperSVGA]

I'll order one of the new cards and see if I can do some testing, since I can't replicate the exact issue on my other cards.

I'll also try and setup a BlueSCSI v2 and see if I can narrow down the exact issue, I have a suspicion of what it might be but will need to test it to be sure.

 

[Androda]

OK, the mod boards arrived and they look pretty nice. 4 wires to points on the card and it presents the four RAM size modes listed before.

 

[Androda]

The RAM card listing in my shop has been updated with a dropdown.
Basic: No switches, always 7 megs of RAM (Except M5126, that one sees 3 without a jumper wire)
Switchable: Reworked boards similar to the above picture, until I run out of these and then all in the future will have the switches by default.
ReworkService: If you want to send your card back to have the firmware updated and switches installed, this is the option for you.

I'm testing a batch of switched boards now, should be listed soon.

 

[SuperSVGA]

Just got my test boards in, still need to do some more experimenting but:

Here's the 7MB card after sleep with manually generated /DTACK:

You can actually push it even further since the RAM is fast enough by generating /DTACK even sooner:

Still need to get around to doing some testing with the BlueSCSI.

 

[Androda]

That's pretty cool, free CPU accelerator from simply running the expansion RAM faster. Maybe I can stick that into the CPLD somehow, another pin for great acceleration...

 

[SuperSVGA]

So I did some more testing with the BlueSCSI v2, and I believe the issue is the transceivers or buffers are asserting control lines as the SCSI controller initializes, because the SCSI controller initialization is happening before the RP2040 finishes initialization.

Here's the BlueSCSI v2 startup:

Here's the original Conner drive for comparison:

Zooming out a little on the BlueSCSI from wake:

It's around 330ms until BSY de-asserts. I believe that's around 5 million clock cycles at 16MHz, or maybe 200,000 CPU instructions.


Here's what happens with another device on the chain providing termination externally:

The moment the BlueSCSI gets power, the transceivers assert the control lines.


And for another test, here's what happens when you have another device on the chain, put the Portable to sleep, disconnect the BlueSCSI then wake from sleep:

If you reconnect the BlueSCSI at this time, everything works as normal.


I'm guessing if you could just keep the transceivers/buffers from asserting SCSI lines until the RP2040 is ready or delay their power up, it would likely resolve the issue.

 

[Androda]

This is basically what I expected. The RP2040 microcontroller designers made the rather strange design decision to put all IO pins into "pull down" mode at chip startup. This means that the control line (not data) transceivers pull lines low until execution enters our userland code out of the RP2040 framework.

Had the microcontroller been a bit more "normal" and set all IO pins to input mode by default, I don't think this would have been an issue. We might be able to change the platform initialization code to set the IO pins earlier, it's just a question of whether that would be early enough.

 

[JDW]

My question pertains to BlueSCSI v2 on the 5126 Backlit Macintosh Portable.

A friend very kindly and generously mailed me a populated BlueSCSIv2 board which has a connector for use with the SCSI ribbon cable of a Macintosh Portable. (Sorry, no photo, as I left it at the office.) So unlike other BSv2 boards I've see which require an add-on adapter board for the Portable, this BSv2 I have is designed especially for the Portable so you can only plug in the smaller SCSI ribbon cable connector used by the Portable. (Not sure if that is a private fork of BSv2 or something official, but the fact is, it was what was shipped to me.)

Now, my 1st question centers on the PICO, because even though the BSv2 shipped to me was mostly populated, it does NOT have a PICO installed.

Is it perfectly OK to use the PICO W on a BSv2 when used on a Macintosh Portable, backlit or not? In other words, there is nothing that says we must only use the regular PICO (without WIFI), correct?

Another question...

It seems that if you own any kind of Macintosh Portable, you must go to the following web page, then click the Mac Plus "quick preset" button, then download that INI file, and copy that to your PICO or PICO W board, correct?

BlueSCSI ini

ini.bluescsi.com

INI file content:

[SCSI]
System=MacPlus

Thank you.

 

[Sideburn]

I think that’s just the “desktop” version of bluescsi board…

The v2 with a Pico W can do WiFi so your portable can get online and wirelessly AppleShare to another WiFi Mac with AppleTalk and AppleShare enabled and so other network things.

System 6.0.8 will be pretty limited compared to 7 just in terms of software like web browsers, term programs to connect to BBS’ etc. and 6 is ideal for the portable…

It’s been a while but I dialed my portable in with software that works as well as did some wireless file sharing etc. I can get it out and post again with more details. Seems I ran into some snags trying to use browsers and terminal programs and was limited to just using it for file sharing on my portable but my memory is foggy now. I may have also been able to remote control it with Timbuktu… Once I get it back out it will come back to me.

I have since converted all of my 68k Mac’s from standard BlueSCSi to BlueSCSI WiFi. It’s very cool and JCS has a D/A that lets you switch on the fly between access points (SSID’s) just like a modern Mac OS

You must used MacTCP if using system 6 which means you need to manually set it up instead of using DHCP but no big deal.

Here’s some info: https://bluescsi.com/docs/WiFi-DaynaPORT

*yes you are correct and your INI is setup right for a portable. To enable WiFi you need to add a couple more likes and put in your SSID and password so it can connect to your access point.

 

[Androda]

A friend very kindly and generously mailed me a populated BlueSCSIv2 board which has a connector for use with the SCSI ribbon cable of a Macintosh Portable. (Sorry, no photo, as I left it at the office.) So unlike other BSv2 boards I've see which require an add-on adapter board for the Portable, this BSv2 I have is designed especially for the Portable so you can only plug in the smaller SCSI ribbon cable connector used by the Portable. (Not sure if that is a private fork of BSv2 or something official, but the fact is, it was what was shipped to me.)

To my knowledge there does not exist an official BlueSCSI V2 PCB which is explicitly for the Mac Portable's oddball 34 pin SCSI connector. That means this is a hardware fork basically. We didn't make a Portable-specific PCB to avoid stocking machine-specific variations. There are too many systems with oddball connectors, and adapters seems like the better way to go. Pictures of the board they sent you would be appreciated.

Is it perfectly OK to use the PICO W on a BSv2 when used on a Macintosh Portable, backlit or not? In other words, there is nothing that says we must only use the regular PICO (without WIFI), correct?

This is going to depend on the PCB design, and is probably a good question to ask the person that sent you the PCB. We don't know what hardware differences there are between this and the official designs. It's possible to design a board which works with the Pico but not the Pico-W.

System=MacPlus

Correct, the Macintosh Portable requires the Mac Plus setting in the INI config file. It's a little bit odd, given that the Portable is close to the SE in terms of system architecture but ended up talking to the SCSI bus like a Plus does.

 

[Sideburn]

Ahh yes to clarify my portable has Androda’s BlueSCSI v2 with WiFi for desktop: https://androda.work/product/bluescsi-v2-desktop/ as well as the Macintosh portable adapter: https://androda.work/product/macintosh-portable-adapter-for-bluescsi-v2/

* I then jumpered power from the floppy drive to the BlueSCSI to solve the wake from sleep issue that started this thread.

 

[JDW]

So I did some more testing with the BlueSCSI v2, and I believe the issue is the transceivers or buffers are asserting control lines as the SCSI controller initializes, because the SCSI controller initialization is happening before the RP2040 finishes initialization.

If we ignore the RAM card slowdown issues mentioned earlier in this thread and just focus on what you are describing when BlueSCSI v2 is used, what is the end result in terms of how BSv2 operates with the Portable? Does this cause BSv2 to lockup? Noticeably slow down? Or does it seem to operate normally to the end user?

 

[Androda]

There are two issues present which were causing the "wake from sleep" problems.

First, the Pi Foundation decided to make all IO pins on the RP2040 default to "pull down" mode. This means that instead of simply "floating" (not changing the electrical state of their connections), they actively pull the signal to ground. This is unhelpful for SCSI which is an active-low bus (meaning "low" is logic 1 and "high" is logic 0). This is a very odd design decision given that things such as the STM32 default to floating.

I had simply gone with their pull down system and added a small pull resistor to the PCB to guarantee the default state of certain control signals. Turns out those defaults were not correct for waking from sleep. BlueSCSI Desktop PCB designs since 2023.09a have the correct pull resistors set and should not cause issues with waking from sleep. Similarly the latest PowerBook design (2023.10a) has the proper pull resistors.

 

[JDW]

BlueSCSI Desktop PCB designs since 2023.09a have the correct pull resistors set and should not cause issues with waking from sleep. Similarly the latest PowerBook design (2023.10a) has the proper pull resistors.

For people with 2023.08 BlueSCSIv2 designs (see attached PDF schematic) which resistors need to be changed, and to what values, to avoid trouble when used on a 5120 or 5126 Macintosh Portable?