• 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.

MacSD - new SCSI SD card emulation tool

Melkhior

Well-known member
@ymk What is the 'official' way of reporting bugs in the firmware?

I'm trying to install NetBSD/mac68k on the MacSD in my Quadra650 (works fine, ordered a second one for a LCIII!), I discovered that MacSD seems to answer SCSI commands on two different SCSI LUN (0 and 1) for every defined SCSI ID, thus confusing NetBSD. You can see in the picture below that drives sd4 and sd6 are 'real' drives as defined in macsd.ini, but sd5 and sd7 are ghosts on LUN 1 (before that, sd0 and sd2 are also real and sd3 and sd5 are also ghosts, I have four drives defined on ID 1 to 4).

netbsd.jpg
 

ymk

Well-known member
Hi @Melkhior. You can use the support email that shipped with your unit to report bugs, but I watch this thread as well.

Which firmware version are you running? LUN handling was changed in v0.11.0 to fix this issue in Win98/XP.

There are multiple mechanisms for LUN addressing, so I will have to set up NetBSD to see which one it uses.

Thanks for your orders and the bug report. :)
 

Melkhior

Well-known member
You can use the support email that shipped with your unit to report bugs, but I watch this thread as well.
I'll have to look more closely at the documents when the second one shows up then (current status being "Shipping Label Created, USPS Awaiting Item") :)
Which firmware version are you running? LUN handling was changed in v0.11.0 to fix this issue in Win98/XP.
I think it originally shipped with 1.0.0 or 1.0.1, I also tried after updating to 1.0.2 but got the same results. NetBSD is more likely to stress some less-used SCSI features, as it also run on multiple workstation/server-class systems that actually used multiple LUNs per ID back in the day...

Random things that could be useful if you have nothing better to do (just ideas, not requests! my only request is for MacSD to work with NetBSD/mac68k) :
(a) being able to use extended partition for drives, or using a partitioning mechanism on the SD that allows for more than 4 partitions, so as to be able to export more than 3 drives using this mechanism;
(b) being able to export drives using non-zero LUN for OS that supports this features, so that you can use a large SD card even on machines/OS with limited disk size by having more than 7 drives in total.

The partition mechanism is super convenient I think, because I can then read the Apple partition table in Linux from the 'real' partition and exchange data using 'hfsutils', e.g. if the SD card is on /dev/sda and my MacOS 8 boot disk is on partition 2 of the SD (so seen by linux as /dev/sda2), I can do e.g.:
Code:
sudo hmount /dev/sda2 2
sudo hcopy -r CWPro_2_Tools_199710.cdr :
And it's a lot faster than going through the network from the Mac (and it skips the copy necessary via MacSD commander when you put the data on the first partition).

Cordially,
 

ironborn65

Well-known member
I own SCSI2SD, MACSD and BlueSCSI (https://bluescsi.flamelily.co.uk/ ).
I'm very happy with the latter, it's the cheapest of them all and the fastest.
For what it matters it's also the smallest PCB.
You can copy images in it, no need to "dd".
The little drawback is that you must rename the image files, ok, I can live with it.
I'll abandon SCSI2SD in favour of BlueSCDI.

Just my two pence
 

ymk

Well-known member
Random things that could be useful if you have nothing better to do (just ideas, not requests! my only request is for MacSD to work with NetBSD/mac68k)

Aside from the duplicated devices, does mounting one work fine?

(a) being able to use extended partition for drives, or using a partitioning mechanism on the SD that allows for more than 4 partitions, so as to be able to export more than 3 drives using this mechanism;

You're right that it would solve that limitation, but I haven't seen much demand for this.

The partition mechanism is super convenient I think, because I can then read the Apple partition table in Linux from the 'real' partition and exchange data using 'hfsutils', e.g. if the SD card is on /dev/sda and my MacOS 8 boot disk is on partition 2 of the SD (so seen by linux as /dev/sda2), I can do e.g.:

Right, partitions are very nice to work with under Linux. I'm also a fan of hfsutils, for both partitions and file images.

And it's a lot faster than going through the network from the Mac (and it skips the copy necessary via MacSD commander when you put the data on the first partition).

Commander is great for moving files to an old Mac using a typical Windows PC or modern Mac, but not needed if you know your way around hfsutils.

My perception is that it's faster.

Keep backpedaling...

macsd_lido.jpg

Thankfully, we don't need to rely on perception. Everyone is entitled to their preferences, but you don't get to lie about a product, whether you own it or not. This is not a which-adapter-is-best thread. Other than trolling, what was the intention of your post? You were answering someone who already bought two MacSDs.
 

Cory5412

Daring Pioneer of the Future
Staff member
I'd also be interested in seeing your numbers.

I have never heard of anyone putting a SCSI disk replacer in and "feeling" like the machine is slower. This is likely because they all have near-zero seeks in comparison with stock hard disks.

The other good news is that Classic Mac OS itself isn't really very sensitive to disk speed and runs well on any of the available options. Most benchmarks measure and show benchmark numbers using large file sizes. MacBench 4's top default amount is 1-megabyte of data, for example. However, most computer usage involves rapidly and randomly doing very small reads, where low seek speeds on SSD solutions is more important than drag racing with big file transfers.

That said: In terms of raw numbers and drag racing: SCSI2SD v6 is the fastest SCSI disk replacer. The only consistently better option tends to be to get a UltraSCSI or SCA adapter and use a server disk from ~2000-2005 or so.

1228KB/sec read, 900KB/sec write, 1ms seek.

My SCSI2SD v6 in an 8600/300 gets roughly 7500KB/sec read and 4800KB/sec writes and the same near-zero seeks/accesses as all of the SD tools. Some other community members got better numbers than those. At those speeds they outperform stock Mac discs into the mid '90s. My Beige G3/300's stock 8-gig disk can just about top that at 11400KB/sec read and 11400KB/sec write. I don't have stock numbers from the Gen2 PCI PowerMac era on hand, however.

My macbench 4 numbers are here: http://vtools.68kmla.org/~/coryw/MacBench/
8600: http://vtools.68kmla.org/~/coryw/MacBench/8600-scsi2sdv6-disk-benches
Beige G3/300 8GB stock disk: http://vtools.68kmla.org/~/coryw/MacBench/coryw-disk-orig-kenpower
These are plain text files but poorly formatted, although they should open right up in MacBench 4. They're also on vtools in the public folder if you've got an account.

Some more SCSI2SD v6 numbers and some good SD cards to look for are posted at https://68kmla.org/bb/index.php?threads/cheap-ide-on-scsi-bus-solution.32521/ -- There's probably better SD cards since then, that thread is closing in on three years old.
 

Cory5412

Daring Pioneer of the Future
Staff member
Took a look at JDW's linked results.

It's super interesting how solid state has turned performance on its head. Any Mac can feel loads faster than when it was new based solely on seek times, and you don't have to spend an awful lot to get there.

On those benchmarks: Even though the MacSD is ~60-80% as fast at transfers as the 4-gig disk in these screenshots, it does ~120-150% better in "disk mix" which presumably relies a lot on seek times.

I think that the SE/30 is the limiting factor in those numbers, all of the transfer speeds are well under 500KB/sec, and we know the disk replacers can all do better. However this is basically a numerical confirmation that literally any of these tools is going to work just about equally well for any 68k Mac usage.
 

Melkhior

Well-known member
Aside from the duplicated devices, does mounting one work fine?
I didn't succeed in installing NetBSD at all. Using the 'new' method (installer running in OS8), the un-tar'ing process quite quickly fails with an SCSI error. I've also tried the 'old' method, but I only have access to the first two IDs (due to ghosting) and an attempt to install went a bit further but eventually failed - I can't remember exactly why (been at it intermitently for a while). It did success in downloading and installing some stuff (so it did succeed in mouting the filesystem and writing to it I suppose), but either it did not finish or I couldn't boot it.
 

ironborn65

Well-known member
My SCSI2SD v6 in an 8600/300 gets roughly 7500KB/sec read and 4800KB/sec writes and the same near-zero seeks/accesses as all of the SD tools. Some other community members got better numbers than those. At those speeds they outperform stock Mac discs into the mid '90s. My Beige G3/300's stock 8-gig disk can just about top that at 11400KB/sec read and 11400KB/sec write. I don't have stock numbers from the Gen2 PCI PowerMac era on hand, however.
I did not say; I have SCSI2SD v 5.2 which is slower then v6

PF
 

ymk

Well-known member
Firmware v1.1.0 is now available.

This update provides significant increases in both read and write performance.

Large reads on a PowerMac 6100/60 with MacSD at 57MHz now exceed 3.2MB/s (up from 2.3).
Writes are improved by ~500KB/s over previous firmware:
macsd57.png

v1.1.0 at 48MHz outperforms previous versions at 57MHz:
macsd48.png

At the stock 33MHz setting, reads approach 2MB/s, up from 1.3MB/s:
macsd33.png

The performance gap between the 33MHz and 57MHz settings narrows on slower Macs.

Added in v1.0.0...

For those who may have missed the v1.0.0 update, support was added for the MacSD Commander application, which allows easy file transfer from the SD card to volumes on the Mac:

1653258801051.png

 

ymk

Well-known member
Firmware v2.0.0 is now available.

This major release was in development for most of 2022 and adds more features than any other to date. A summary of new features:

MIDI interface and routing system
  • MIDI over SCSI using custom OMS driver (System 7+)
  • Works with OMS, QuickTime and MIDI Manager
  • MIDI over USB (bidirectional)
  • MIDI over MPU-401/SoundBlaster gameport or standard DIN ports (bidirectional)
  • MIDI to internal synthesizer
  • Add a MIDI output port to your Mac without tying up a serial port.

MIDI synthesizer
  • Sample-based synthesis
  • 32KHz, 13.75-bit stereo
  • Up to 32 voice polyphony
  • General MIDI instruments
  • Three reverb settings
  • Variable 3D depth effect
  • 13 drum kits, 500+ drums in total
  • Functions as wavetable add-on for SoundBlaster cards
  • Replaces QuickTime Musical Instruments, freeing up CPU cycles and improving music quality.

Temperature sensors
  • Connect up to 8 sensors through the expansion port

PWM fan control
  • Configure up to two PWM-enabled fans for fixed or temperature-based speed control

USB interface
  • Configure and monitor MIDI routing, synthesizer, temperatures, fan speeds, CD-ROM changer queue and more.
  • Non-interactive and terminal-based control.
  • Send MIDI data to a soft synth running on a Raspberry Pi, etc.
  • Standard MIDI and serial interfaces require no special driver.

MacSD's synthesizer providing the soundtrack for Gabriel Knight on an LC475, through MIDI manager and OMS:

Playing some 80s and 90s MIDI files through Arnold's MIDI player and OMS:

Works great with vintage PCs too:



Installed in an LC475, controlling fan speed based on CPU temperature...
1665183323069.png

...and also driving a MIDI output port. The LED indicates MIDI activity and the pink line out jack combines MacSD's CD/synthesizer audio output with the LC475's audio:
1665183554969.png

Added expansion port connections:
1665183234858.png

Special thanks:
@JDW - For featuring MacSD in his excellent videos and testing.
@Crutch and @cheesestraws - For assistance with 68K driver development.
@jajan547 - For selling me the mint 475 pictured.
@Realitystorm - For lots of useful Mac MIDI information and reviewing MacSD.
 
Last edited:
Top