Introducing ZuluSCSI Blaster - now with More Cowbell!

[David Cook]

the fallback modes are a bit more fiddly than the "classic" equivalents.

Very interesting. Given the faster-clocked CPU, the non-DMA mode must really stink.

architectural limitation on either the software or hardware side that made implementing the DMA untenable.

Apple patched it out in the leaked source. Not sure if it was ever renabled.

; <57> 04-22-90 csd
; commented out the installation of SCSI DMA so we stop trashing
; hard disks on the IIfx.

movea.l SCSIGlobals,a1 ; point to SCSI Manager globals
move.l #250*10000,G_Reserved1(a1) ; set up 250ms byte-to-byte timeout
leaROM ROMFastWriteOSS,a0
; move.l a0,jvVFWO(a1) ; use DMA code for SCSIWBlind
leaROM ROMFastReadOSS,a0
; move.l a0,jvVFRO(a1) ; use DMA code for SCSIRBlind

 

[Arbee]

I've been told the issue was that they couldn't get DMA to play nice with System 7 virtual memory. So if VM was on you'd get random trashing of disks and memory. That isn't *that* hard of a problem, and they obviously did work it out later for the PowerMacs.

Incidentally, 04-22-90 is almost a month after the IIfx shipped. So presumably the machines initially shipped with an enabler that allowed DMA to work and they very quickly got complaints. Would be interesting to dig up that enabler, but I have very little hope of it happening.

ETA: DMA was never enabled for the IIfx in Mac OS. All the way out to 7.6.1, the end of the line for 68030, it uses the PIO fallback.

 

[David Cook]

So presumably the machines initially shipped with an enabler that allowed DMA to work and they very quickly got complaints.

I am considering hacking that code back in to see what happens.

 

[David Cook]

Back on the topic of this thread. I encountered something a little weird.

On a completely recapped IIsi, with the Blaster attached externally and an internal Quantum ProDrive, the SCSI doesn't work. The ProDrive won't even spin up.

* If you plug a power cord into the Blaster, then everything works fine.
* If you use the ZuluSCSI v1.1 (no power cord) instead of the Blaster, then everything also works fine.
* If you remove the ProDrive, the Blaster works fine without the power cord.

So, maybe a difference in inrush current or power requirements? Maybe I'm just pushing the power limit on the IIsi? Not a big deal. Just worth noting.

 

[zigzagjoe]

Back on the topic of this thread. I encountered something a little weird.

On a completely recapped IIsi, with the Blaster attached externally and an internal Quantum ProDrive, the SCSI doesn't work. The ProDrive won't even spin up.

* If you plug a power cord into the Blaster, then everything works fine.
* If you use the ZuluSCSI v1.1 (no power cord) instead of the Blaster, then everything also works fine.
* If you remove the ProDrive, the Blaster works fine without the power cord.

So, maybe a difference in inrush current or power requirements? Maybe I'm just pushing the power limit on the IIsi? Not a big deal. Just worth noting.

AFAIK the IIsi lacks internal termination power entirely - I'm kind of curious how the other zuluscsi board is working at all unless it's managing to backfeed enough power from the logic board's termination or something equally odd.

It should have external termination power AFAIK so your primary case there ought to work though. Might be worth probing the internal power rail of the zuluscsi in both positions to see what you find.

 

[David Cook]

AFAIK the IIsi lacks internal termination power entirely - I'm kind of curious how the other zuluscsi board is working at all unless it's managing to backfeed enough power from the logic board's termination or something equally odd.

It should have external termination power AFAIK so your primary case there ought to work though. Might be worth probing the internal power rail of the zuluscsi in both positions to see what you find.

Both the ZuluSCSI v1.1 and Blaster were connected externally with the ProDrive internally. Yes, ZuluSCSI works from external term power ("Designed to be powered via SCSI termination power when provided by the host").

When I pulled the ProDrive, I added in an internal terminator that includes a hard drive connector to obtain power internal power from the internal hard drive connector.

 

[David Cook]

Thought it would be worth posting Blaster performance on the Quadra 605 (w/Bolle 128KB cache and 40 MHz overclock). Reached 4.5 MB/sec!

 

[jovianartifact]

What makes it "Blaster"? I saw the thred and thought "sound blaster".

 

[finkmac]

because it blasts the bits

 

[rabbitholecomputing]

What makes it "Blaster"? I saw the thred and thought "sound blaster".

Support for 16-bit CD audio emulation, for starters. The current optional DAC boards sell for $5

But as @finkmac also points out, it blasts the bits

 

[paws]

I finally ordered one from your European distributor + a DAC board, but then they came back and said they were sending me a new 2026 version instead with a built-in DAC? Seems cool! I can't seem to find a list of differences, though?

Also, I'm really curious about the I2C control board that's mentioned in the README in Github, but I can't find a detailed description of the hardware anywhere? Is this a product that's underway or maybe something I could put together myself?

 

[rabbitholecomputing]

I finally ordered one from your European distributor + a DAC board, but then they came back and said they were sending me a new 2026 version instead with a built-in DAC? Seems cool! I can't seem to find a list of differences, though?

There isn't one yet. The changes are minimal. The firmware is exactly the same. There are some improvements to the efficiency of the power supply circuitry, but the most noticeable change is that the new ZuluSCSI Blaster Rev2026 board has a laid-down DAC and a footprint for the optional RM2 Wi-Fi module, which can be soldered down either by an end user or from select resellers (including Rabbit Hole Computing, directly). In the EU, https://www.serdashop.com/ZuluSCSI-Blaster sells ZuluSCSI Blasters with RM2's soldered down as an optional extra.

When we designed the original ZuluSCSI Blaster a year+ ago, the RM2 was not yet commercially available, so we couldn't design for it, which is why the radio module was a physical add-on board.

Also, I'm really curious about the I2C control board that's mentioned in the README in Github, but I can't find a detailed description of the hardware anywhere? Is this a product that's underway or maybe something I could put together myself?

The 5.25" control board is Open Source Hardware, and you can produce your own if that works best/most economically for you. We've recently published the hardware design and gerbers under the CERN OHL-S V2 license, and this is publicly available at https://github.com/rabbitholecomputing/Zulu-Control-Board-I2C-OSHW

For some example screenshots of what things actually look like when using the control board, see the latter portion of the ZuluSCSI README