• Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.

SillyTinySCSI - Smallest SCSI emulator! (ZuluSCSI OSHW)

zigzagjoe

Well-known member
I've found a bug that seems to affect Quadra/newer machines. The symptom is when extension loading completes in system 7.5 (ish) and displays the finder, the mac soft locks (mouse still moves) and the light on the tiny goes solid. Interestingly the System 7.5 disk tools disk doesn't seem to have this issue.

I think it is related to the newer SCSI controllers on Quadras - all Compact macs tested so far seem OK along with Mac IIx and IIsi. Not sure *why*, as the SCSI interface between it and the Zulu Pico is identical, but I am hoping it is correctable by firmware.

I got a quadra board and replicated the issue so I am working on it...
 

gogopuffs

Well-known member
Any chance you're tempted to port this to a BlueSCSIv2 variant? I wonder about the interchangeability of these SCSI emulators.
 

zigzagjoe

Well-known member
Any chance you're tempted to port this to a BlueSCSIv2 variant? I wonder about the interchangeability of these SCSI emulators.

There isn't a lot of hardware difference between the two designs, to the point where @aperezbios ported the ZuluSCSI firmware to run on BlueSCSI boards. BlueSCSI V2 is a direct derivative of the ZuluSCSI code with a slightly different hardware implementation though necessarily very similar since they both use the Pico and want to interface to a SCSI bus.

So, in my eyes, there's not really a need to make a hardware derivative of bluescsi as it would be simpler to make a variant of the bluescsi software. AFAIK, most of the changes on bluescsi are to support the use of their closed-source file transfer utilities within Mac OS - I don't see why it wouldn't be possible to just add what software features those utilities require to the zulu firmware. Though, being at the mercy of the bluescsi project for the closed-source macos software would be..... not ideal.

Yay! My SillySmallSCSI arrived in the mail!

I feel dumb though, I didn't realize there were so many options for firmware https://github.com/ZuluSCSI/ZuluSCSI-firmware/releases/tag/v2023.11.27 - which one do I use for this? I would guess https://github.com/ZuluSCSI/ZuluSCS....11.27/ZuluSCSI_Pico_DaynaPORT_2023-11-27.uf2 since it is PicoW-based and DaynaPORT is for the WiFi.

Awesome! Yes sir - ZuluSCSI Pico DaynaPort is the one you want. You can upload either the .bin file by putting it on the SD card and applying power, or you can directly upload the .uf2 file by holding the program button near the tip of the Y on the back of the device while inserting the USB.
 

zigzagjoe

Well-known member
I have identified the problem with the faster macs. Unfortunately, it looks like this will affect anything with a 53C96/94 SCSI chip - basically, anything Quadra and up. 68030 and older macs seem to be OK (IIfx may be an exception).

I made a minor mistake while removing initiator support, and the long and short of it is if the ATN line is used it causes one of the buffers to change direction when it shouldn't. Older Macs don't seem to use ATN - so no problem. But the newer ones definitely do, though they only begin doing so inexplicably late in the boot sequence (right when finder starts up). At which point things break.

The is the rework required. Lift pin 1 of the buffer on the top side of the board, and bodge it over to pin 20 (VCC). This can be done using a thin exacto blade - heat pin 1, then slide the blade underneath.

I'll be reaching out to anyone who purchased one to either coordinate shipping back to me (at my cost) to do the rework or a partial refund if you're OK with it as is.

1701665880148.jpeg1701665889328.jpeg1701665908146.jpeg
 

ClassicGuyPhilly

Well-known member
Yup, several reboots, multiple drive volumes, and copied over several gigs of data via Appletalk over Ethernet. All good and stable. I'm using a 32GB SanDisk Extreme
 

zigzagjoe

Well-known member
I've got another batch of these cooking at JLCPCB, I'll post a note in the trading post forum when they're ready. No functional changes other than addressing my mistake with the ACK line that required rework for function in new machines, and some ease of assembly tweaks. Also, the LED may be a smidge brighter.

I'm again leaning towards offering them in preassembled form primarily as there's still some close quarters soldering.... we'll see.
 

hideehoo

Member
I've got another batch of these cooking at JLCPCB, I'll post a note in the trading post forum when they're ready. No functional changes other than addressing my mistake with the ACK line that required rework for function in new machines, and some ease of assembly tweaks. Also, the LED may be a smidge brighter.

I'm again leaning towards offering them in preassembled form primarily as there's still some close quarters soldering.... we'll see.

Did you ever do a validation build of your V2 design? Looking to throw a few boards on my next JLC order.
 

eharmon

Well-known member
I have identified the problem with the faster macs. Unfortunately, it looks like this will affect anything with a 53C96/94 SCSI chip - basically, anything Quadra and up. 68030 and older macs seem to be OK (IIfx may be an exception).

I made a minor mistake while removing initiator support, and the long and short of it is if the ATN line is used it causes one of the buffers to change direction when it shouldn't. Older Macs don't seem to use ATN - so no problem. But the newer ones definitely do, though they only begin doing so inexplicably late in the boot sequence (right when finder starts up). At which point things break.

The is the rework required. Lift pin 1 of the buffer on the top side of the board, and bodge it over to pin 20 (VCC). This can be done using a thin exacto blade - heat pin 1, then slide the blade underneath.

I'll be reaching out to anyone who purchased one to either coordinate shipping back to me (at my cost) to do the rework or a partial refund if you're OK with it as is.

View attachment 66180View attachment 66181View attachment 66182
Huh. With my Quadra overclocked I get that behavior with standard ZuluSCSI, sometimes...unbelievably hand-wavy conjecture, but is it possible even standard boards have a race condition with this behavior?

I wonder if that's when it's pivoting from SCSI Manager (ROM) to SCSI Manager 4.3 (System), or if it has to do with the storage drivers loading.
 

zigzagjoe

Well-known member
Did you ever do a validation build of your V2 design? Looking to throw a few boards on my next JLC order.

Yep, it's good. Note that LCSC is out of 74LVTH245s so you would need to populate them yourself, can't seem to even preorder them at the moment.

Huh. With my Quadra overclocked I get that behavior with standard ZuluSCSI, sometimes...unbelievably hand-wavy conjecture, but is it possible even standard boards have a race condition with this behavior?

I wonder if that's when it's pivoting from SCSI Manager (ROM) to SCSI Manager 4.3 (System), or if it has to do with the storage drivers loading.

While the failure point during boot could be similar, it'd be a different root cause.

On the V1, while simplifying the original design I made a small wiring mistake leading to the need to bodge it. Best I have been able to tell, that specific point at boot (post extension loading, finder starting) is when SCSI starts doing asynchronous IO / possibly with a side of DMA, and the way the 53c96 driver is coded it begins using the ATN line at that point. Due to that error I had, that caused one of the buffers to change direction which... broke things rather badly.

Wouldn't be impossible that this change of behavior could provoke other issues, though.

Also working on a sister design to the Tiny SCSI: SlimSCSI, so named as it's the same height as the DB25 connector. not flush fitting, but will be compatible with machines the Tiny won't fit on.

1708296693151.jpeg
 

Jockelill

Well-known member
Huh. With my Quadra overclocked I get that behavior with standard ZuluSCSI, sometimes...unbelievably hand-wavy conjecture, but is it possible even standard boards have a race condition with this behavior?

I wonder if that's when it's pivoting from SCSI Manager (ROM) to SCSI Manager 4.3 (System), or if it has to do with the storage drivers loading.
Yep, it's good. Note that LCSC is out of 74LVTH245s so you would need to populate them yourself, can't seem to even preorder them at the moment.



While the failure point during boot could be similar, it'd be a different root cause.

On the V1, while simplifying the original design I made a small wiring mistake leading to the need to bodge it. Best I have been able to tell, that specific point at boot (post extension loading, finder starting) is when SCSI starts doing asynchronous IO / possibly with a side of DMA, and the way the 53c96 driver is coded it begins using the ATN line at that point. Due to that error I had, that caused one of the buffers to change direction which... broke things rather badly.

Wouldn't be impossible that this change of behavior could provoke other issues, though.

Also working on a sister design to the Tiny SCSI: SlimSCSI, so named as it's the same height as the DB25 connector. not flush fitting, but will be compatible with machines the Tiny won't fit on.

View attachment 69945
Nice job!! Really like this devices!!!

Also interesting to read about the ATN-issue. I've been banging my head since last year trying to get the ROM disk driver (basically Rob Braun's old driver but with necessary modifcations) to work on Quadras. I've gotton to a point where it is very reliable on my Q650 with 328MB RAM and a BlueScsi V2 2023.09, but if I put in a mechanical hard drive or a SCSI2SD, it will not boot the rom disk driver (Zuluscsi works). Last week I got a batch of the latest revision of BlueScsi's and interesting enough it actually hangs while booting at basically the same point you describe above, when ATN gets activated. Maybe this could at least be a partial explaination on why the rom disk driver does not work properly on the Quadras.
 

zigzagjoe

Well-known member
I find the gerber file for the PCB but could you make a components parts list for mouser?

I have attached an iBOM. It contains both LCSC and Digikey part numbers.
You will also need some surface mount headers. PN for those should be HDR100IMP40M-G-V-SM-ND

Nice job!! Really like this devices!!!

Also interesting to read about the ATN-issue. I've been banging my head since last year trying to get the ROM disk driver (basically Rob Braun's old driver but with necessary modifcations) to work on Quadras. I've gotton to a point where it is very reliable on my Q650 with 328MB RAM and a BlueScsi V2 2023.09, but if I put in a mechanical hard drive or a SCSI2SD, it will not boot the rom disk driver (Zuluscsi works). Last week I got a batch of the latest revision of BlueScsi's and interesting enough it actually hangs while booting at basically the same point you describe above, when ATN gets activated. Maybe this could at least be a partial explaination on why the rom disk driver does not work properly on the Quadras.

Yeah, it does seem like a different "paradigm" kicks in at that point in time - I think it's when the system begins to allow some background processing and uses async SCSI access if possible. Inside macintosh might have more detail on what's happening, i bet. That definitely sounds like bluescsi is doing something wrong, though. Does the access LED get stuck on?
 

Attachments

  • SillyTiny R2 iBOM.zip
    174.1 KB · Views: 2

eharmon

Well-known member
I have attached an iBOM. It contains both LCSC and Digikey part numbers.
You will also need some surface mount headers. PN for those should be HDR100IMP40M-G-V-SM-ND



Yeah, it does seem like a different "paradigm" kicks in at that point in time - I think it's when the system begins to allow some background processing and uses async SCSI access if possible. Inside macintosh might have more detail on what's happening, i bet. That definitely sounds like bluescsi is doing something wrong, though. Does the access LED get stuck on?
Hopefully not confusing things by referencing my similar issue (but I really think they're all around the same root issue), the ZuluSCSI access light definitely gets stuck on.
 

zigzagjoe

Well-known member
Hopefully not confusing things by referencing my similar issue (but I really think they're all around the same root issue), the ZuluSCSI access light definitely gets stuck on.

That sounds identical, if the light is stuck on it sounds like it's stuck in the middle of an operation, the exact same as what I had happen. You may want to turn on debug logging to capture where it's dying, as it shouldn't be happening.
 
Top