Jump to content

MacSD: Trip Report


Recommended Posts

I recently bought a MacSD, and since there has been a certain amount of interest in the community about it, I thought I'd dump some observations and notes here about it, since I'm pretty pleased with it.  This isn't going to be anything as organised as a review, and I'm not even going to try to overcome my own methodological biases, so please bear this in mind.  This is not journalism, it is notes.  Noticeably, I value flexibility over raw performance, so I have only put limited energy into benchmarking, for example.  I am also not going to talk much about pricing or value for money, because that's incredibly subjective.  I feel like I got value for money out of it, though.  I am also not qualified to comment on the electronic design of the thing, so this will be very much from a user's point of view.  Also: this is all based on a couple of days of reasonably extensive fiddling, but I have not put this under heavy load by any reasonable definition.

 

tl;dr: This is a nicely and sensibly designed tool, with good quality-of-life features.  It provides a great deal of flexibility, and for an application where you want to be able rapidly to reconfigure or rejig what's being exposed via SCSI, this is great.  In fact the whole "meta" aspect of using the device is much nicer than any of the other new SCSI devices I've used, which includes things like firmware updates being very smooth, an error LED on the board that flashes specific error codes when something is wrong, an LED that displays whether termination power is working on the bus, and separate SCSI and SD activity LEDs.  There are currently a couple of interoperability rough edges in the firmware I've come across (as of version 0.9.2), which I'll note below.  I've already reported these upstream, and they should be reasonably easily fixable (they are not technically bugs in the MacSD firmware, it's working as the documentation says it does, it's just that ... there's a couple of places that behaviour is a bit surprising.)  In general, this is a decent option, and I think it should definitely be considered especially by people who either like to reconfigure their macs frequently or who have just got their first classic mac and want to bootstrap it easily without having to have another classic mac to play with.  To use this as a "install as a replacement hard disc and then ignore it" would be to waste a lot of its features, though, and other options are likely more cost-effective for the same performance in that case.

 

 

To start with: The MacSD arrived quickly and well-packed.  It came with quick start instructions, a mount for a 3.5" drive bay already attached, and a 16GB SD card full of goodies.  Think similar kind of stuff that BMOW provide with the Floppy Emu, just for a newer generation of Mac.  This includes a number of games which show off the CD drive emulation.  This card is "ready to go" and, notably, includes a minimal System 7.5.5 and 6.0.8 installation ready to boot.  This isn't one of those customised emulator images you see floating around which one either loves or hates, it's more like a glorified disk tools image for preparing and installing the "full" version of the OS.  In other words, the kit provides everything needed to bootstrap a classic mac which currently has no OS, without needing to go hunting on the Internet (modulo a couple of notes below about power and SCSI cables).  This is a good design decision.

 

 

I tested this with:  LC I, II, III; IIsi; IIfx; Quadra 700, 950.  I have not yet worked up the energy to dismantle any of the compacts to try it in.  I only have laptop-class PowerMacs, and have not yet tested it with any of these.

 

 

Physical design and connectors:  The SCSI connector is in the middle of the board, rather than on one of the edges, which I'm not a great fan of, because on a number of Macs, this means that the hard disc ribbon cable that comes with the machine can't actually reach the SCSI port on the MacSD.  I had to use a longer one in the LCs and the IIsi, and the 700 was a stretch.  Other than bus power, the only way to get power into the board is through the micro USB port.  This was only a problem on one of the models I tried it with (the IIsi), where it needed more power.  I ended up using a molex to micro USB (ew) cable I knocked up a while back, but for a future hardware revision of the board, having a power connector might be a nice update.

 

 

First steps:  Connecting it to a Mac and just powering it on (making sure termination is right, of course) just worked as the instructions said it should.  On all the Macs I tried it in except the IIsi, it could work fine without any prosthetic power.  On the IIsi (and I tried two different logic boards, so I think this is this model as a whole), I had to provide +5v.  The one I had came with firmware 0.7.0.  I immediately upgraded this to the latest (0.9.2 at time of writing), which I strongly recommend, mostly because it makes error reporting work a lot better.  The firmware update process was easy; you put the firmware file on the SD card (making sure to delete all the old ones first) and power up the MacSD with the BL jumper set to on.  The lights flash a bit, and when they stop, you power it off and put the jumper back.  The instructions for this were clear and correct.  Sensibly, it will not attempt a firmware update if you have multiple firmware versions on the card, so you can't end up installing a different firmware than you meant quite as easily.

 

 

CD-ROM emulation:  Worked fine, in my testing, though I'm not really into CD gaming.  Disc images can either be ISOs for boring software, or BIN/CUE files for software with CD audio soundtracks.  You can make a list of disc images in the configuration file, and when one CD is ejected, the next one will automatically be inserted.  This is handy for multi-CD games.  The CD emulation does not support 512 byte sectors for UNIX-heads, but as far as I can see the MacSD as a whole will not run A/UX as far as I can see, so for the Mac side of things, this isn't really an issue.

 

 

Configuration: Configuration is done through an INI-syntax file.  It is straightforward and well-documented.  There's an opportunity here for a GUI tool to be written, but it's not really necessary.  Errors in the configuration are signalled by flashing the red ERR LED on the board some number of times; looking up how many times it flashes in the manual tells you the actual error.  These errors, in my experience, have been accurate enough and useful enough to track down what was wrong with my configuration.

 

 

Images, Filenames and filesystems: The primary way of dealing with both hard disc and CD-ROM images is to put them on a FAT32 filesystem on the SD card.  FAT32 interoperability has traditionally floundered on two points; its relationship with partition systems and long file names.  I don't think it's a coincidence that the two niggles I found in the firmware of the MacSD are precisely on these points, because they've been a headache for everyone else too.  Things to note, as of firmware 0.9.2:

 

  • The MacSD expects a Windows-style FAT32 partition, of type 0x0c.  MacOS X tools insist on setting the partition type to 0x0b.  As far as I know there's no difference in the actual filesystem in play within the partition.  Windows uses (used?) the difference to flag whether LBA addressing was in use or not.  I ended up formatting my SD card in a random Linux machine I had hanging around because I couldn't face trying to work out how to get MacOS to behave itself and do what I'd actually told it to.  Obviously once formatted, MacOS X could read from / write to it perfectly fine.  This should be a reasonably easy fix in a future firmware, and I wouldn't expect this behaviour to last.
  • MacSD's configuration file is case-sensitive as far as filenames go, which is not quite usual FAT32 behaviour, since most FAT32 implementations I've come across/tried to hack on have been (mostly) case-preserving but not case-sensitive.  This is not, in itself, a problem, except that it interacts interestingly with long file name implementations in modern OSes.  Long filenames (> 8 characters, 3 extension) work fine.  But if you create a file on the Mac, say, with a short filename (8.3 or less) and that filename is all in lowercase, the filename is actually inserted into the disc directory in all capitals, and is just displayed in lowercase.  This behaviour goes all the way back to PC Exchange, and certainly Windows 9x used to do it, too.  So this means that if you have a file called, for example, "hdd.img" on the SD card, you need to have that name in capitals in the configuration file, because OS X is hiding what the name of the file actually is, because it assumes FAT32 is case-insensitive.  Again, I expect this will get fixed.

 

As with FAT in general, filesystem fragmentation can become a problem.  OSes that are using it for file-level storage get around this by effectively amortising the slowdown over multiple filesystem calls.  MacSD does not really have this luxury, at least not if it wants to have a consistent latency and transfer speed; so instead, it indexes fragmented images when it powers on, before it exposes anything over SCSI.  If this takes long enough, things will pretty much just freeze up solid.  The MacSD does communicate when it's had to index fragmented files; there is an orange FRAG LED on the board.  If this goes on it is best to treat it as a 'this is probably working at the moment but might stop if you put more stuff on the SD card' light, and defragment or reformat your SD card.  In theory, perhaps this could be done with a background task, but honestly this isn't code I would want to write myself, so I don't blame anyone else's firmware for not including it :-).

 

Large images (>4GB) can be used by sticking them in partitions on the SD card.  This is, I think, a sensible decision; it's not quite as easy or as straightforward from the user's point of view as implementing ExFAT, but I'm willing to bet that it makes the code more maintainable and reliable.  The partitions involved are just standard MBR partitions, so you don't need any specific tool or anything to make them; fdisk or Disk Utility on a mac worked fine for me.  This provides most of the benefits of the scsi2sd 6 approach of multiple mass storage devices, but using standard tools and SD card readers.  The downside is that you can't use nested partition tables, but for Mac use this is not really a problem in my opinion.

 

 

Benchmarks and performance: I haven't got any benchmarks.  MacBench on my main machine reports disc transfer rates that I know for a fact are physically impossible (not just for the MacSD, but in general), and this has rather eroded my trust in the tool.  The numbers I managed to get out of it that look about right are in line with the spec on the website, but I'm not going to promulgate those benchmarks or state them as fact, because some of the numbers in them are blatantly and totally wrong.

 

At least on the Macs I listed above, performance felt nice and snappy, though I didn't do anything particularly demanding with it.  Light use, a bit of source code editing, etc.  Latency is certainly fine, although it does take longer to come ready at startup, and thus longer to boot, than some of the alternatives.  This isn't really a problem, though, for me it was only a handful of seconds, not longer.  Fragmentation will of course slow this down (see above).

 

 

Edge case:  I have not yet successfully got A/UX booting on the MacSD, and I'm not sure it will work.  I think that when the SCSI bus is reset when the kernel comes up, the MacSD takes too long to become ready; MacOS will live with this and wait for it, but A/UX has a much shorter timeout, so it reports that it cannot select the disc and then panics because it doesn't have a root filesystem.  A/UX being notoriously picky about hardware is just a fact of life for those of us who use it, though, so I'm not entirely surprised by this.

 

Anyone got anything they particularly want me to try out? @Byte Knight, I believe you have one of these too (IIRC), anything you'd like to add?

Edited by cheesestraws
Link to post
Share on other sites
On 11/1/2020 at 9:47 AM, cheesestraws said:

Anyone got anything they particularly want me to try out? @Byte Knight, I believe you have one of these too (IIRC), anything you'd like to add?

 

Excellent review!  And now I know why formatted SD cards from my MacBook Pro won't work with the MacSD...

 

With the ability to also use this as a CD emulator, I felt that this would work better as an external device that I could use with several of my vintage Apples.  So I ended up putting mine in an Apple HD 20SC case with an SD card extension cable - you can see the project here.  The instant power-up and no need for external power is a huge plus with the MacSD.

 

The MacSD works exactly as it's supposed to with the included SD card (which was a nice bonus!).  I've even got it working with my Apple IIgs.

 

However, trying to create my own SD card has been frustrating.  Every time I try to make a new SD card full of CD images, I end up with a bunch of CD's that aren't recognized, even if I copy those CD images directly over from the included SD card.  Maybe this has to do with the case sensitive issue mentioned by cheesestraws.  Also, I've had several SD cards get fragmented despite having plenty of space left on them.  

 

Now I haven't upgraded to the latest firmware, so maybe this will fix some of my issues...

 

 

 

 

Link to post
Share on other sites
7 hours ago, Byte Knight said:

With the ability to also use this as a CD emulator, I felt that this would work better as an external device that I could use with several of my vintage Apples.  So I ended up putting mine in an Apple HD 20SC case with an SD card extension cable - you can see the project here.  The instant power-up and no need for external power is a huge plus with the MacSD.

 

I saw that and thought t looked really nice.  Mine is probably going to end up in an external enclosure, too.  I'd like it to be a proper Apple one but those aren't that common around here, alas.  Perhaps I should have mentioned it in the original review; I think that's another really good use for this, to maximise the usefulness of its feature set.

 

7 hours ago, Byte Knight said:

Now I haven't upgraded to the latest firmware, so maybe this will fix some of my issues...

 

What version are you on at the moment?  Error reporting is quite a lot better in 0.9.2 over the one mine came with (0.7.0), and generally it was a much smoother ride.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...