LCIII (3) BlueSCSI strange behaviour

[XKSTEVE]

Hi All, Hope you are all well and having fun with your retro computers.

I seem to have 2 issues with my LCIII and a BlueSCSI desktop 2023.10a with a PicoPi 2W flashed with v2024.12.08.

Machine is as the title says an Apple Macintosh LCIII with OS7.5.5 and Open transport 1.3 networking.

The first issue is that the LCIII chimes on startup but then losses sound once booted to the desktop. I can browse the internet ok and it connects to WiFi fine but the sound just stops and even does not chime on restart, although it still does ofter shutdown power cycle. I can also see my shared drives on my Macintosh Iici (OS 7.6, Open transport 1.3, bluSCSI desktop2022.12a firmware 2024.12.08 and cNET ethernet card).

The Second issue is that I use Apple's LocalTalk Bridge to allow communication between my LocalTalk and Ethernet connections on the Iici. As soon as the LCIII connects to my LAN the Bridge on the Iici disables itself with a "Number conflict error".

Just to clarify the Iici, LC475 (Quadra 605) LCIII, SE and LCII all work fine together on the network (Iici and LC475 have ethernet cards, LCII and SE are LocalTalk via Printer ports as was the LCIII before I fitted the blueSCSI.

Has anyone else had these issues? I did a search on google but don't see anyone else with these specific problems.

I have tried using the older MacTCP networking but that had even more issues talking to the Iici which I put down to it having Open Transport. Any suggestions welcome.

 

[eric]

I don't believe these issues related to using a BlueSCSI - though it's always good to go through the troubleshooting guide completely to rule easy things out.

I'd start wit the basics - making sure it's recapped, voltage from the PSU is good, no crud around the sound chip, and a RAM test.

 

[XKSTEVE]

I don't believe these issues related to using a BlueSCSI - though it's always good to go through the troubleshooting guide completely to rule easy things out.

I'd start wit the basics - making sure it's recapped, voltage from the PSU is good, no crud around the sound chip, and a RAM test.

Hi Eric, Hope you're well.

Thanks for your input - always appreciated.

Like you I don't think this is a blueSCSI issue as I have never had issues with any of the many units I own (from v1 to current model). I think it is software related.

Machine is recapped as is the PSU. All voltages are good and provide stable and good current rating. Logic board was caught before battery failure or cap leakage and probably worked before I recapped it (dunno did not test it prior to rework and ultrasonic clean). I was going to create the SD using initiator mode (that is so cool) from the original HDD which still works fine. but ended up doing a disc copy.

I have been playing around with this machine for a couple of days including this morning and the sound was not working after multiple reboots and restarts but.... as your reply notification came in, it just started working again.

Only changes I have made is to replace the BlueSCSI.ini and the Network file on the SD root. No changes just replaced and indeed the log file seemed to be reporting that the network was starting up successfully before that... However this was odd because before replacing them I had to manually connect using the wifi DA. I did double check those files were plain txt not rtf files that were just renamed (don't know if that is a requirement - just made sense.)

I have checked the wifi extender (AirPort 2) which is on a shelf about 3 feet away from the LCIII; that all checks out ok.

I'll let the LC III run for a while and see what happens. I was getting disconnection issues to the Iici but this seems fixed now (Was the wifi extender I think but not sure as I just rebooted it).

I have not got as far as testing the LocalTALK bridge.cpt yet and will look at that later once I confirm the other issue has gone away.

I did read the troubleshooting guide but nothing there jumped out.

Best regards

Steve

UPDATE: Many hours later and everything is still working. I will test the bridging tomorrow.

 

[XKSTEVE]

UPDATE:

Think I have sorted the sound issue out. Removed the sound chip as I could see something around the pins, cleaned it and refitted. Not only does it now work all the time (was intermittent) but the sound is now louder. Did not see this behaviour before I replaced the HDD. Could It be a load issue?? or did I just luck out with a coincidence??

Still can't get The LCIII (or LCII) to work with Apple LocalTALK Bridge 2.1 (ALB2.1) with the blueSCSI pico 2W - guess its just a thing. ALB2.1 Works with the Fallon card installed.

Log says my disk images (2) are fragmented and I have followed the advice on the GitHub twice and with different SD cards (both formatted with the recommended settings and software). Should I be concerned? Are there any other tricks to try?

Defiantly going to buy some more of the 2024.10a and fit pico 2W - What an Awesome device.

 

[Nycturne]

UPDATE:

Think I have sorted the sound issue out. Removed the sound chip as I could see something around the pins, cleaned it and refitted. Not only does it now work all the time (was intermittent) but the sound is now louder. Did not see this behaviour before I replaced the HDD. Could It be a load issue?? or did I just luck out with a coincidence??

Seems more likely to be coincidence. With the stories of removing/resoldering the sound chip fixing sound after working on the board (recapping, or in your case, replacing the HDD), it makes me wonder somewhat naively if we are seeing weak solder joints on this chip. Flex or heat could be the tipping point to a cracked/failed joint in that case, and it would explain why resoldering the chip fixes it.

Log says my disk images (2) are fragmented and I have followed the advice on the GitHub twice and with different SD cards (both formatted with the recommended settings and software). Should I be concerned? Are there any other tricks to try?

Are you loading up the SD card from a modern MacOS? I noticed with Sequoia that Disk Jockey produces hda files with extended attributes. These extended attributes being written to an hidden file on FAT/ExFAT are another source of ‘interruptions’ when trying to copy the file that can cause fragmentation. I banged my head a bit on this one earlier in the week myself.

 

[OneGeekArmy]

That's interesting. I'll see if I can strip extended attributes altogether (I don't need them on the disk images DJ creates).
I don't know whether I can instruct macOS to not create them afterwards, though.
I'll take a look.

 

[Nycturne]

That's interesting. I'll see if I can strip extended attributes altogether (I don't need them on the disk images DJ creates).
I don't know whether I can instruct macOS to not create them afterwards, though.
I'll take a look.

It looks like macOS has changed how the quarantine attribute works for sandboxed apps a while back, attaching them to all files accessed by those apps. Just in case the app is trying to write to a file that happens to be an executable script or the like I guess. Meaning you need to intentionally remove them (if possible).

From https://eclecticlight.co/2020/10/29/quarantine-and-the-quarantine-flag/

The addition of quarantine flags to files which have never been downloaded from the Internet appears to be a relatively recent behaviour, but has now been seen to occur in macOS Sierra and later.

❯ xattr -l HD10_512\ 4000MB.hda
com.apple.quarantine: 0082;67645315;Disk Jockey;

I also probably should have added the workaround is to use 'xattr -c <file>' to remove any extended attributes before copying to the SD card in my first reply for the OP. I have to do this with CD images as well as they will have quarantine flags on them too.