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

SCSI2SD Project - anyone interested ?

mmcmaster

Active member
Hi,

Is anyone interested in building or buying a homebrew SCSI-to-SD card adaptor ?

I have developed such a device which is already capable of booting and running

OS 7.5.3 on the old pizza-box macs. It also works as a normal SCSI-2 device

under Linux as well, so it should work on most platforms.

I'll be putting in a PCB order this week for the "final" version, and I can

order extra if others are interested. I haven't actually tested this version

of the PCB, but there are only small changes to the SCSI and SD interfaces

compared to the working prototype version.

I could supply bare PCB's for cost price (about $3 each plus shipping), or

completed boards for $45 AUD + shipping.

To build your own requires surface mount soldering and an expensive Cypress

Miniprog3 programmer. It's probably compatible with other SWD programmers via a

suitable adaptor, but no guarantees.

Full schematics, pcb layouts, and source code is available at the project page:

http://www.codesrc.com/mediawiki/index.php?title=SCSI2SD

Note that the source code is a little bit out-of-date, and will be updated to

support the current pinout and firmware updates over USB at the very minimum

before I would mail any PCBs.

I'll be testing out a 3d printed bracket this weekend, which will allow mounting

the device in a standard 3.5" hard disk bay. It's already printed, I just need

to see if I can tap some screw holes into the plastic.

The device uses a Cypress PSoC 5lp microcontroller to bit-bang the SCSI

interface. At some point I'll try to make use of the programmable logic

aspects of the PSoC to speed up the SCSI interface.

 

techknight

Well-known member
NICE bro....

Well, now that this is out there, im sure the code can be looked at and modified to make things efficient.

The problem with SD cards, is the only "public" protocol is the SPI based protocol and is very slow. The SD protocol is much faster but requires an NDA and license i think? I think the fastest solution is skip SD and use the USB stack on the chip and mass storage USB devices.

Also how to view schematic and PCB? it wont open in eagle.

 

mmcmaster

Active member
The USB stack on the chip is guest only. I couldn't find any microcontroller with a fast USB2.0 host, but that was proably 2 years ago now.

The SPI protocol will certainly be the limiting factor here. Theoretically it would be possible to implement the 4-bit protocol using the progammable logic on the PSoC, but I don't have the skills (or SD Card Association license) to do that. But in reality I think the performance of the SPI protocol will be OK for use with 68k macs. The read speed is already OK for running games etc - what it lacks in raw sequential throughput, it makes up in zero seek times for random access (when compared to an old mechanical drives).

 

techknight

Well-known member
aww crap. lol. I use eagle, and only familiar with eagle. Well ive used freePCB before, but never liked it. Plus what you developed in, doesnt run in windows. another killer. I dont use linux or any variant thereof so the usefulness of this project to me was just killed :-(

Granted, I tried linux and played with it back in the day but I found it so irritating and the errors cryptic so I gave up. and when I actually wanted to do something with linux it was a hop skip and a jump through hoops and stand on your head while touching your nose to get something configured to run, or to even install. lol.Then pray that everything still works afterwords. I am sure alot of that has changed now, but back then oh man..... Pre-configured hold-your-hand boxes are decent, especially in the server avenue. But if you wanted to run something on your own that wasnt in a package file, or configure something by hand, yea... forget it. I tried ubuntu and it wasnt as bad as what I was trying to get used to with mandrake 10, etc. But most of the actual "work" I do involves software that doesnt even run in linux. Then theres wine. but i never could get it working right without more cryptic unknown errors so again I gave up. its probably just me, but I just dont have the patience.

I do have MacOSX but its PPC only, I dont have an intel mac.

I guess i could virtual machine the crap but eh.

 

LCGuy

LC Doctor/Hot Rodder
I'd be very, very interested. :) And I see you're in Brizzy, too. Good to see an Aussie doing some 68k development. :)

 

bigmessowires

Well-known member
This sounds very cool! How is the data stored on the SD card? If I pulled the card and mounted it on my PC, would I see a Mac disk image or something else usable for exchanging files between PC and classic Mac? That often seems to be the biggest hurdle for people - they still have working Mac drives, but no way to move files on/off from the outside world.

 

Trash80toHP_Mini

NIGHT STALKER
I'd just like to chime in here to say welcome aboard, mmcmaster. How long have you been lurking about?

Fabulous project, it's great to have another developer in the barracks.

BMOW, it's great to have you active again as well, welcome back.

 

NJRoadfan

Well-known member
This sounds very cool! How is the data stored on the SD card? If I pulled the card and mounted it on my PC, would I see a Mac disk image or something else usable for exchanging files between PC and classic Mac? That often seems to be the biggest hurdle for people - they still have working Mac drives, but no way to move files on/off from the outside world.
Most modern Macs or HFS utilities should be able to directly mount the volume on the card as-is.

 

bigmessowires

Well-known member
Sounds great. And thanks, Trash80!

A couple more questions, after reading through your Wiki:

Are you seeing acceptable SD write speeds? The discussion on your Wiki seems to imply that the SPI clock speed will determine the transfer rate, but in my experience with Floppy Emu, it's the internal card operations that take most of the time. So you might transfer a sector to the SD card in 0.25 milliseconds, but then the card takes anywhere from 8 to 800 milliseconds to save it before it's ready to accept another sector.

How did the toaster plate reflow soldering finally work out? Is that your preferred method now? I've always wanted to try that. Right now I'm hand-soldering TQFP-44 and TQFP-100 parts with a regular soldering iron, which is a major pain in the butt. It requires a lot of patience, a high-power magnifier, and steady hands. It's basically impossible if I've had any coffee in the past few hours :)

Did you get a solder stencil made up? I've never worked with solder paste either. I actually have a hot air reflow workstation, but have barely ever used it. Maybe I can find some pre-made TQFP-44 stencils, and use those to lay down solder paste to solder those parts with the hot air station, then do the rest of the parts by hand.

 

techknight

Well-known member
Well the link said the software was linux only. Thats why I ranted a bit. Glad its windows compatible :)

 

mmcmaster

Active member
Data is stored on the card in exactly the same way it any other SCSI disk device. hfsutils (http://www.mars.org/home/rob/proj/hfs/) can be used to access the data on Windows or Linux. I don't have a modern mac, but I would assume that it can access the data natively. You could either use a PCI SCSI controller to connect the adaptor+micro SD card, or just put the micro SD card into a card reader.

I've tried to ensure that the data can be interchanged between a physical mac and the BasiliskII emulator. Currently this requires pointing BasiliskII at a SCSI device as the disk emulation only understands individual volumes. When using Linux, the easiest way to do this (without a PCI SCSI controller) is to put the micro SD card into a USB memory card reader - a SCSI device is created for the USB mass storage device, which BasiliskII can then use. Use the "sg_map -i" (http://sg.danny.cz/sg/sg3_utils.html) command to determine the SCSI device associated with the USB card reader, and use that device name with the BasiliskII "--scsi0" option.

It would be possible to extend the software to act as a USB mass storage device directly., and I plan on doing this eventually. This will ensure the SCSI commands are handled in exactly the same way, whether using a physical mac or an emulator.

 

mmcmaster

Active member
SD write speeds are currently unacceptable (50k/sec). I'll spend time this weekend improving that using multi-sector write commands, adding DMA support, and bumping the SPI clock up from 16MHz to 25MHz. It is my belief that the multi-sector write command (CMD25) should overcome most of the latency issues. This is probably the largest risk to the project. In any case, I'll have an answer this weekend.

My preferred solding method is via a hotplate with a 5mm thick plate of aluminium on top. It works really well! I'm using a cheap thermocouple thingy with LCD display from ebay (~ $4.50) to keep an eye on the aluminium temperature for repeatable results. The thermocouple is attached to the alumiunium plate with some metal putty designed for repairing car exhausts. I haven't used a hot-air station before so I cannot compare the two methods.

I was using a kapton stencil bought from http://ohararp.com/stencils/ as I found it too hard to limit the amount of paste coming out of the syringes. The stencil works ok, but I still get a few bridges on the QFP part and have to clean it up with an iron. I'm going to try a stainless steel stencil next from www.smart-prototyping.com because it should be a little bit thinner, and it's cheaper than the kapton stencil when considering shipping costs.

 

bigmessowires

Well-known member
I'll be very interested to see how your SD writes turn out. For SCSI2SD, I think you'll only be concerned about average write speed. For my Floppy Emu project I had to meet a minimum write speed - if a block ever took more than about 20 ms to write, the Mac I/O operation would fail. From my experience, SD writes seem to be "pretty fast" most of the time, but every 10 or 20 blocks you'll see one block take 10x or 20x the average time.

Here are some numbers I collected, doing a 24 block transfer (12 KB of data), using the multi-sector write method. The times listed are the number of milliseconds for the entire 12K write operation.

class 10 card: 187, 180, 195, 44, 43, 42, 39, 39, 42, 39, 40, 50, 41, 39, 43, 48, 40, 43, 41, 40, 40, 40, 42.

class 4 card: 60, 354, 375, 375, 376, 378, 379, 377, 372, 376, 371, 44, 360, 369, 372.

You can see the class 10 card averages around 45 ms, or 267 KB/sec. The class 4 card averages 370 ms, or 33 KB/sec. These tests were done with an SPI clock of 4 MHz, I think. At that speed, the actual SPI transfer takes 24 ms, and the rest of the time is the card's internal write operation.

I'll check out those stencils, thanks! I would think the hot air station should work similarly to the toaster plate for this kind of work, expect with very small parts, the air may actually blow them off the board. :lol:

 

dougg3

Well-known member
Very cool project, mmcmaster! I'm definitely interested in trying it out! I was wanting to do a project very similar to this idea eventually, but the SCSI spec always scared me away.

Have you considered making the firmware emulate an Apple drive so we can use the stock Drive Setup/Apple HD SC Setup with it? I think that would be *awesome*!

There are some Cortex-M3/Cortex-M4 MCUs that have the native 4-bit SD interface built in, for example the NXP LPC177x and LPC178x. I do realize they aren't as cool as the chip you're using (with the programmable logic built in too), but it's another option if that ends up being needed...

 
Top