Thread
SCSI2SD Project - anyone interested ?
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.
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.
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.
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.
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).
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).
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.
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.
gEDA runs on everything, including windows, so you have no excuse :b&w:
http://www.delorie.com/pcb/geda-windows/
The software is built using the Cypress PSoC Creator 2.2 (http://www.cypress.com/psoccreator/), which is Windows-only AFAIK. Although it looks like I'm out-of-date, and I need to update to the newly released 3.0 version.
http://www.delorie.com/pcb/geda-windows/
The software is built using the Cypress PSoC Creator 2.2 (http://www.cypress.com/psoccreator/), which is Windows-only AFAIK. Although it looks like I'm out-of-date, and I need to update to the newly released 3.0 version.
And installing and using Ubuntu these days is about as easy as Windows is.
I'd be very, very interested. 
And I see you're in Brizzy, too. Good to see an Aussie doing some 68k development.
And I see you're in Brizzy, too. Good to see an Aussie doing some 68k development.
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.
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.
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.
Most modern Macs or HFS utilities should be able to directly mount the volume on the card as-is.
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.
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.
Well the link said the software was linux only. Thats why I ranted a bit. Glad its windows compatible
The cpld/pic version looked promising but it appears like it went extinct. No activity in awhile.
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.
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.
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.
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.
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:
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:
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...
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...
Would it be possible to fool it into thinking it's an Apple drive without infringing on Apple's drive ROM copyrights?
All Apple's ROM does is change the device vendor ID from whoever made the drive to "Apple". There is nothing special about the drives otherwise. Never had a problem using the patched Apple HD SC Setup or the later versions of Drive Setup that dropped that silly ID check.
It seems like having a device give a declaration that something is "Apple" when it's not could be sticky, since said device is not "Apple". If Apple caught a whiff of it I can see them having an issue with a device saying something is "Apple" when it isn't. It seems like it probably isn't kosher since, as far as I'm aware, no one ever made a piece of hardware that did this. If it was kosher it seems as though it would have been done during the time that this hardware was still in wide use.
Better to just avoid the whole issue and use the patched HD SC instead and not risk the Eye of Apple settling on you.
Better to just avoid the whole issue and use the patched HD SC instead and not risk the Eye of Apple settling on you.
I disagree. First of all, it's just a text string you're returning. It's not like it's copyrighted code that you're bundling. Second, I doubt Apple cares anyway. Third, I think it would be really handy because it would be compatible with stock install CDs and whatnot.
Edit: Here is a really similar legal issue that ended up being decided in favor of the company that included the string "SEGA" without Sega's permission. http://en.wikipedia.org/wiki/Sega_v._Accolade
Edit: Here is a really similar legal issue that ended up being decided in favor of the company that included the string "SEGA" without Sega's permission. http://en.wikipedia.org/wiki/Sega_v._Accolade
People are welcome to do whatever they want, I just thought I'd mention it as a word to the wise just in case.
biggmessofwires:
I certainly haven't had any issues with the occasional high latencies that flash memory introduces - the SCSI disk drivers don't seem to have any fixed timeouts that I've run across yet. Did you use the ACMD23 (SET_WR_BLK_ERASE_COUNT) command before writing the data ?
Does anyone know the -exact- field that Drive Setup/Apple HD SC Setup checks ? I think I'll make that field a configurable option, stored in eeprom and set via USB. That way, people can change it to "Apple Computer, Inc." if they want (or shatever string Drive Setup expects).
I don't know with 100% certainty, but the MAME/MESS source code:
http://mamedev.org/source/src/emu/machine/scsihd.c.html
...seems to indicate that mode sense page 0x30 should return the string "APPLE COMPUTER, INC."
I like the idea of making it configurable!
http://mamedev.org/source/src/emu/machine/scsihd.c.html
...seems to indicate that mode sense page 0x30 should return the string "APPLE COMPUTER, INC."
I like the idea of making it configurable!
Awesome detective work dougg3! I've confirmed that mode page 0x30 and identifying as a Seagate ST225N drive is sufficient for Drive Setup to work without patches. I haven't made it configurable yet.
I spent too much time on the weekend dealing with a broken car waterpump, and not enough time on SCSI2SD xx( . I did manage to significantly improved write speeds to 240kb/sec, but I haven't added DMA support yet.
I spent too much time on the weekend dealing with a broken car waterpump, and not enough time on SCSI2SD xx( . I did manage to significantly improved write speeds to 240kb/sec, but I haven't added DMA support yet.
This is very exciting. Are there no other SCSI to SD converters out there already? I've seen several SCSI to compact flash converters, but that's not nearly as appealing, since CF cards aren't very common any more and mounting one on a modern PC for file copying may require extra hardware. Is there a technical reason why CF cards are easier to adapt for SCSI than SD cards?
mmcmaster, do you mean 240 kiloBYTES (KB) per second, or kilobits (Kb)? Assuming kilobytes, I'd love to know what method you're using to get that write speed on a class 4 card, since it's about 8x better than I was ever able to achieve. I'm using the SdFat library, which I think does send the SET_WR_BLK_ERASE_COUNT command before a multi-block write, but I should double-check. I looked at a couple of other SD libraries, and they all seemed to advertise similar write speeds.
Very cool project! I'm looking forward to getting one of these when they're ready.
mmcmaster, do you mean 240 kiloBYTES (KB) per second, or kilobits (Kb)? Assuming kilobytes, I'd love to know what method you're using to get that write speed on a class 4 card, since it's about 8x better than I was ever able to achieve. I'm using the SdFat library, which I think does send the SET_WR_BLK_ERASE_COUNT command before a multi-block write, but I should double-check. I looked at a couple of other SD libraries, and they all seemed to advertise similar write speeds.
Very cool project! I'm looking forward to getting one of these when they're ready.
I see I'd forgotten to mention that I'm interested in getting one as well. 
I think it's because they're interfaced similar to IDE. Since SCSI>IDE is already done, it's probably not too much to carry it over to CF.