• 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

Compgeke

Well-known member
Does the CD emulation support 512 byte sector reads? It's an issue with real CD drives on Unix machines and not dealing with real CDs on those would be great.

 

Byte Knight

Well-known member
While my primary focus is Macs, there's no reason MacSD cannot work on other SCSI platforms.  It is being tested on Amiga, SGI, Sun, RS/6000, etc by others.  I will describe it as unsuitable for applications supporting human life (as are its individual components and the SD card).  Nobody should be using this in a traffic light.  Everything else is fair game.
Well there goes my plans for it...  :lol:

I've got a SCSI card on the way so I'll test it out with the Apple II once I get it up and running on my vintage Macs.

 

NJRoadfan

Well-known member
It depends on what SCSI card is in the Apple II. The Apple made cards (Rev. C and the High Speed SCSI) should be "fine" provided that a device on the bus provides termination power as Apple's cards don't provide it without modification. The RamFAST SCSI card is the tricky one. It uses a not-so kosher implementation of SCSI where the controller does not assign itself a SCSI ID on the bus. This has been known to trip up actual hard drives in the past.

 

ymk

Well-known member
Does the CD emulation support 512 byte sector reads? It's an issue with real CD drives on Unix machines and not dealing with real CDs on those would be great.


CD reads are currently limited to 2048 byte sectors.  If 512 byte reads are added, it will most likely be as a third device type rather than a 300i option.  Which (fairly common) drives use 512 byte sectors?

The Apple made cards (Rev. C and the High Speed SCSI) should be "fine" provided that a device on the bus provides termination power as Apple's cards don't provide it without modification.


That is an important point since there's a risk of damage if termination power is not provided.

 

Compgeke

Well-known member
CD reads are currently limited to 2048 byte sectors.  If 512 byte reads are added, it will most likely be as a third device type rather than a 300i option.  Which (fairly common) drives use 512 byte sectors?
Basically any Toshiba or Plextor can. XM-5401B, PX-40TSe, etc, etc. I know Sanyo can not for sure (used in some LaCie drives). The CR504/CD600i iirc is jumperable too, using the 2nd from the far right jumper to enable 512 byte sector support. The 300i might also support that, but I don't remember off the top of my head. 

 

tt

Well-known member
I figured I should chime in.  I actually know the guy who makes these great boards.  He even sent me an early prototype for testing purposes.  I, for one, am thrilled that an alternative to SCSI2SD exists that is more Mac friendly.  I've had tons of issues with them so finding one exclusively for the Mac is wonderful.  That said I did get the SCSI2SD to work in *some* of my systems but they hated the Mac SE & SE/30 for whatever reason.  So, if anyone is on the fence, you really should consider MacSD. 
This is good to hear!! I had gone ahead and ordered one, so I am looking forward to trying it out.

You just drop in drive images and update a text file right on the SD card, right? It reminds me of Basilisk (emulator) where you edit the prefs file to tell it what disks to load and CD-ROM etc.

Edit: Now I see @ymk has joined, welcome! 

 
Last edited by a moderator:

ymk

Well-known member
Several updates have been released over the last week adding:

  • Direct partition mapping for HDD devices, breaking the 4GB barrier.
  • Support for external LEDs.
  • Independently adjustable brightness for on-board and external LEDs.
  • Increased CD audio resolution and gain for 33/48/57MHz modes (12.45-13.28 bit).



You just drop in drive images and update a text file right on the SD card, right? It reminds me of Basilisk (emulator) where you edit the prefs file to tell it what disks to load and CD-ROM etc.

Edit: Now I see @ymk has joined, welcome! 
Thanks!  That is indeed how it works.

 

tt

Well-known member
The MacSD has arrived and have been trying it out for the last few days. I think it's a very interesting take on SCSI emulation. For instance, I played some music on it through the audio out jack with a hybrid bin/cue file of "The Manhole". I have been working through some stability issues with transferring files from my modern machine and switched to a Linux based workflow from now, which might be better in the long run for back-up and archival. Fragmentation of the drive is something you want to avoid. I am still testing it out and hoping to find it stable enough to start transferring more stuff onto it from my stash. 

 

Cory5412

Daring Pioneer of the Future
Staff member
Direct partition mapping for HDD devices, breaking the 4GB barrier.
I'm curious about this, because it sounds like this would sort of negate the main reason to go for the MacSD, which is the operational simplicity. Not needing to format cards in a particular way in particular. Is there ultimately any plan to switch over to or allow exfat as an alternative?

I still haven't really had time to review the documents so maybe this isn't as complicated as I thought, or, if this is an edge case, then it might not really matter how complicated it is.

I have been working through some stability issues with transferring files from my modern machine


Hmm, what kinds of stuff was happening?

One thing I'm curious, and, this is both for anybody who has one of these and perhaps specifically for @ymk is what this device is like in terms of write caching, a known weak point of the SD cards in general and in general for SCSI2SD usage you want to buy the highest end SD card you can, to improve performance and stability, even in scenarios where you're buying cards rated for hundreds of megabytes/second of transfer in order to ultimately get about ten megabytes/second of transfer out of it. (At least on the scsi2SD v6.)

On my v6, I ultimately got to a point where day to day operations were stable but doing bit mostly out-of-the-ordinary tasks like stuffing or unstuffing very large datasets on the local storage could cause problems. I need to revisit that at some point -- although in the 8600 in particular it's a little bit moot because I really should get that a better disk or put a SATA card in. (That scsi2SD will be cascaded down to my Power120 or 6100/66.)

 

ymk

Well-known member
I'm curious about this, because it sounds like this would sort of negate the main reason to go for the MacSD, which is the operational simplicity.
How does an additional feature negate anything?  You may have your own "main reason", but buyers have had varied priorities and uses.

For whatever reason, you seem determined to pigeonhole MacSD as a toy while protecting SCSI2SD's market share:  

I feel like it would be fair to describe it as explicitly to the exclusion of other platforms and applications where scsi2sd is also used


In the ebay finds thread, you posted:

One thing that is a bummer for 040s is that disks on this device have a maximum filesize of 4GB due to the underlying FAT32 system, so, SCSI2SD is a better choice for any scenario on an 040 where you want a lot of disk space.


And in this thread:

As I understand it, A/UX supports "big" volumes poorly anyway, so the thing that makes me not want to put it in, like, my own 840 (I'd use bigger volumes) aren't that big of a deal for A/UX.


So now that your own main objection, and a "bummer" has been resolved, you still try to spin it into a negative.

I'm not here to change the mind of someone who has quite clearly, already made his up.

 

tt

Well-known member
I have been working through some stability issues with transferring files from my modern machine
 

Hmm, what kinds of stuff was happening?
I was using a Win10 VirtualBox install to format a 16gb SD card and transferring files either within the VM or from the OS X host machine. I was mainly editing the macsd.ini file while the card was mounted in OS X. The SD card in the MacSD would either not load disk images properly or freeze up. I am still observing some freezing which happens to be occurring with HyperCard across 3 different CD images, but I am not sure if its an image file issue or the hardware (MacSD or otherwise). There was an instance where the fragmented status light went on and the machine froze. Due to these issues, I switched to using a SBC with Linux to do the formatting and file transfers. That seems to be better but I need to run it a little more and want to test it with my emulator disk images.

 

ymk

Well-known member
What type of images does this support?  Full drive, e.g. multiple partitions in one file, or one partition per file?  I looked in the manual and wasn't sure.  I'm Steve from http://www.savagetaylor.com/2018/01/05/setting-up-your-vintage-classic-68k-macintosh-using-a-scsi2sd-adapter/, and I was wondering if my existing SCSI2SD or floppyEMU images would work


Hi Steve.  I've been using your 7.5.5 and 6.0.8 images, and they work well.  Thanks for putting them together, they are very useful.  I have not tried your floppyEMU images.

A full drive on the SCSI side is stored as a file on the FAT32 partition on the card, or as an entire raw primary partition on the card.

The CD emulation supports cooked images (.iso/.toast/.cdr/etc) and raw .bin images with a CUE or TOC index.

 
Last edited by a moderator:

Realitystorm

Well-known member
The SCSI2SD files have both the mac driver and partition information in the file.  The floppyEMU file doesn't include either, that file is just a single partition and is used with the floppyEMU's HD20 emulation.  I'll update my site to say my SCSI2SD images work with MacSD

 
Last edited by a moderator:

Cory5412

Daring Pioneer of the Future
Staff member
My apologies for the confusion. It's worth noting that several of your quotes are from before you joined in and before we had some information you've brought to us available. Also, before several software updates.

I have now read the documentation, and, sure enough: there is now a way to build and use >4GB volumes with the MacSD. This was added after some of your quotes where I said that no support for big volumes was a bummer.

However, doing so does, in fact, kind of negate the (at least implicit, but I believe this has been stated) benefit of the MacSD relative to the other extant options, which is that configuration and operation are simple. An explicitly stated reason for excitement for the MacSD is the configuration simplicity, which using it this way changes, to a certain extent. From what I've seen here (and, keep in mind, I'm on this web site, I'm not in your inbox, so I know what people on 68kmla.org wrote in a place where I could see, not what people told you directly) the main interest is in that ease of configuration.

It's not quite to the level of configuring a SCSI2SD, but, it's still kind of a bummer for people who wanted big volumes and all of that simplicity.

In terms of considering it as a toy: This is a vintage Mac hobbyist web site. Our namesake is, at absolute minimum, drinking age, and minus one person who joined in the last two years, nobody here is doing serious work on these things. All of it is toys.

But in terms of pigeonholing the MacSD as a "Mac" product, well:

  • It is literally called MacSD
  • It explicitly emulates the Apple CD300 CD-ROM drive
  • It explicitly emulates hard disks in such a way that Macs do not require third party partitioning tools.



Overall:

I don't intend to steer potential customers away from your product, but in a meta-discussion about extant SCSI hard disk replacement options, it's worth considering the properties of each solution and how those properties become pros and cons. Every tech purchasing decision, ever, involves compromise and a balancing of factors such as cost, functionality, convenience, and performance. I don't have any commercial interest in any of these products, and I'm not shopping for anything like this at the moment, I happen to have bought some SCSI2SDs a few years ago when they were the primarily available solution.

MacSD and SCSI2SD are very different solutions on those front, and different people here have different needs.

Incidentally, @ymk, let me or @wthww know if you want your account converted to a vendor account, or if you'd like to make a new account to use as a vendor account and use this one for general participation.

 

dcr

Well-known member
However, doing so does, in fact, kind of negate the (at least implicit, but I believe this has been stated) benefit of the MacSD relative to the other extant options, which is that configuration and operation are simple. An explicitly stated reason for excitement for the MacSD is the configuration simplicity, which using it this way changes, to a certain extent. From what I've seen here (and, keep in mind, I'm on this web site, I'm not in your inbox, so I know what people on 68kmla.org wrote in a place where I could see, not what people told you directly) the main interest is in that ease of configuration.
The first thing, in my opinion, that would help would be if they had multiple examples of hard drive configurations, including partitioning, using >4GB volumes, etc.  Some of us need to see example code before we "get" it.  ;)   To me, it doesn't seem terribly complicated to configure the MacSD.  But, for someone with no experience with anything like that, I can see where it may be an issue.  More examples would help in that regard.  But, the other possibility I am wondering about is if they were able to do an online configuration tool.  The .ini file is basically just a text file, so I wouldn't think it would be too difficult to put together a web form or process whereby you check boxes and fill in text fields with the options you want, then that's processed with PHP or something similar and it spits out an .ini file you can download and copy to the SD card.  I wonder if that would be beneficial for people that want easy configuration.  They wouldn't have to do the .ini file themselves; they'd only need to follow a step-by-step process to indicate how they want it configured.

Then the question would be how many people need such a tool versus how many can figure it out on their own?

Disclaimer: I have no commercial interest in any of these products either.  I have two SCSI2SDs for my machines.  I would consider a MacSD the next time I need such a device.

 

ymk

Well-known member
But, the other possibility I am wondering about is if they were able to do an online configuration tool.
It has crossed my mind.  The problem of incorrectly entering filenames, etc remains.  I'll add more to the documentation about partitions.  For now, here's an example:

Code:
[2:hdd]        ; Map SCSI ID 2 to MBR partition 4
partition=4
 

dcr

Well-known member
The problem of incorrectly entering filenames, etc remains.
You have that problem manually doing the .ini file too.  But, in the case of an online configuration tool, you can put up a big bold red (or whatever) warning to double-check the filenames before submitting.

I'll add more to the documentation about partitions.
Cool.  Thanks!  Though, in my case, I'd most likely have a pretty basic setup.  I'm just throwing ideas out there to hopefully make it easier for people who want to use those other options but still want relative simplicity.

 

ymk

Well-known member
However, doing so does, in fact, kind of negate the (at least implicit, but I believe this has been stated) benefit of the MacSD relative to the other extant options, which is that configuration and operation are simple
This is not "SCSI2SD for dummies".  If features I add to this product conflict with what you think it is or should be, you are mistaken.  Most of my customers already had a SCSI to SD solution.

But in terms of pigeonholing the MacSD as a "Mac" product, well: 
I've sold to non-Mac users and will continue to.  Don't concern yourself with it.

I don't intend to steer potential customers away from your product, but in a meta-discussion about extant SCSI hard disk replacement options, it's worth considering the properties of each solution and how those properties become pros and cons.
That discussion is best led by people who have actually used the device, or at least bothered to read the documentation before speculating.

I'll let you know about a vendor account.

 

Mk.558

Well-known member
With regard to >4GB images, I'm curious what the demand for that is like. Only '040 Macs will officially run volumes over 4GB,


I'm curious about this. Apple says that 7.5.2+ supports up to 2TiB. Is their KB article an error?

Any color LED can be used, however current is only around 1mA so I recommend using a modern, high intensity type.  Brightness will be adjustable through the config file.


If I'm not seriously mistaken, a typical T1-3/4 LED, red, uses about 20mA when operating on a 100% duty cycle (or...just on). I don't have it immediately available but if I'm recalling correctly green, blue and especially white require more to reach full brightness. Now the LEDs used in 1989 were not particularly bright, and were probably not driven at full power either, but I couldn't help but notice that 1mA is probably barely enough to forward-bias the LED.

 
Last edited by a moderator:
Top