SCSI2SD Project - anyone interested ?

[Paralel]

Would it be possible to fool it into thinking it's an Apple drive without infringing on Apple's drive ROM copyrights?

 

[NJRoadfan]

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.

 

[Paralel]

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.

 

[dougg3]

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

 

[Paralel]

People are welcome to do whatever they want, I just thought I'd mention it as a word to the wise just in case.

 

[mmcmaster]

biggmessofwires:

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.

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 ?

Have you considered making the firmware emulate an Apple drive so we can use the stock Drive Setup/Apple HD SC Setup with it?

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

 

[dougg3]

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!

 

[mmcmaster]

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.

 

[bigmessowires]

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.

 

[Trash80toHP_Mini]

I see I'd forgotten to mention that I'm interested in getting one as well.

 

[markyb86]

Is there a technical reason why CF cards are easier to adapt for SCSI than SD cards?

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.

 

[Trash80toHP_Mini]

That makes a lot of sense to me. IDE->SCSI would be almost identical to a standard ISA->SCSI interface card, which probably(?) opens up a lot more design examples than just the ACARD solution. There must be a lot of Linux open source code hackage available to apply to such a project.

But i'm a code noob, so take that WAG for what it's worth.

 

[NJRoadfan]

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?

SD cards are patent encumbered devices. The "open" SPI interface is very slow. Having straight IDE gives folks the option to use whatever kind of storage device they want.

 

[Gorgonops]

The downside of an IDE interface is it takes quite a few more wires (massive understatement) than an SD card. I've been looking at (okay, given the amount of hobby time I have, fantasizing about) building a couple different (insert 8 bit computer name here)->CF drive interfaces and an absolute minimum interface requires about 16 lines if you intend to use the "8 bit mode" that CF cards support, two dozen if you're using the full 16 bit data bus. (Which you'll have to if you want to support regular IDE devices.) You'll need a few more if you wanted to use DMA or interrupts. If you're using a neat and modern MCU for your design you'll be dedicating a lot of GPIO pins for that. (Also, you often get good built-in SPI support in those same MCUs.)

If you're working with a more oldschool bus-oriented CPU then Compact Flash does have its advantages over SD, however. They're practically trivial to interface with most 8 or 16 bit CPUs with just a couple pieces of TTL glue and you're running a parallel bus anyway so there's no additional pin count penalty.

 

[mmcmaster]

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

bigmessowires, I meant 240 kiloBYTES per second, using a class 10 card. SPI running at 24MHz at the moment. I'm not bit-bashing SPI though - I'm loading 4 bytes at a time into a FIFO buffer, and letting the hardware clock out bits to the SD card without software intervention.

I suspect the SD card writing itself is actually closer to 2 megabytes per second, and I'm being limited by poor throughput on the pure-software SCSI interface. I timed the current SCSI interface at 449KB/sec by commenting out the SD card write methods. I'm halfway through addressing that by moving the SCSI single byte read/write method into the programmable logic of the PSoC chip, and feeding it with the magical FIFO buffer.

I have currently reserved the first 8 devices for people who have sent private emails or PM's asking about payment (which won't be until I have the PCBs ready). Trash80toHP_Mini, did you want to go on the reserved list ? The initial order was only for 10 PCB's, as there is a small risk that I stuffed something up and will have to modify the layout.

I also have the 3d printed bracket made, but I need to locate an M3 tap to see if I can screw it into a standard 3.5" drive bay with standard screws (the smaller type, as used on optical drives). I do NOT intend on supplying the bracket, as it's easy enough for people to print it themselves, or get someone local to them to print it via makexyz.com

 

[bigmessowires]

bigmessowires, I meant 240 kiloBYTES per second, using a class 10 card. SPI running at 24MHz at the moment. I'm not bit-bashing SPI though - I'm loading 4 bytes at a time into a FIFO buffer, and letting the hardware clock out bits to the SD card without software intervention.
I suspect the SD card writing itself is actually closer to 2 megabytes per second, and I'm being limited by poor throughput on the pure-software SCSI interface. I timed the current SCSI interface at 449KB/sec by commenting out the SD card write methods. I'm halfway through addressing that by moving the SCSI single byte read/write method into the programmable logic of the PSoC chip, and feeding it with the magical FIFO buffer.

240 KB/sec sounds about right for class 10. I know I'm starting to sound like a broken record here, but before you spend too much more time optimizing the software side of your SCSI interface, you may want to do a simple SD performance test where you write 100 blocks full of random data to the SD card. That will tell you the best case possible performance, if the software interface were infinitely fast. I hope I'm wrong, but I suspect you may find it won't go much faster than you've already got it, without switching from SPI to the proprietary 4-bit interface.

 

[techknight]

Even though its protected by patents/NDA, etc... Hence "Secure" digital memory. I assume thats what they mean by that anyway. could be wrong....

isnt it possible to reverse-engineer, or find code out there that utilizes the proprietary interface?

 

[Trash80toHP_Mini]

Reserve list is better for me anyway, I'm not an Alpha tester kinda hacker on this stuff.

Beta CMOS DIP was more my speed back in the day. :I

 

[mmcmaster]

Even though its protected by patents/NDA, etc... Hence "Secure" digital memory. I assume thats what they mean by that anyway. could be wrong....
isnt it possible to reverse-engineer, or find code out there that utilizes the proprietary interface?

Yes, there is code and information out in-the-wild the used the proprietry interface. eg. see http://opencores.org/project,sdcard_mass_storage_controller. But it would be SLOWER than the simple SPI interface unless it was implemented in hardware (eg. an FPGA), as there are now more serial outputs to control.

dougg3 previously suggested switching to a NXP LPC177x or LPC178xA microcontroller, which has the required hardware interfaces. This would certainly perform better, but I am keen to continue down the current path, since I already know the device is fast enough for my own personal use-case (ie. I can boot my old macs, and run some old games).

 

[mmcmaster]

I know I'm starting to sound like a broken record here, but before you spend too much more time optimizing the software side of your SCSI interface, you may want to do a simple SD performance test where you write 100 blocks full of random data to the SD card.

A little bit of skepticism is healthy :b&w: I've done a quick test whereby I modified the code to write 20 sectors to the SD card for every 1 sector requested. Each SD card write command would be passed 8192 * 20 = 163840 bytes.

The test:

$ sudo dd bs=8192 count=100 if=/dev/urandom of=/dev/sdd oflag=dsync
100+0 records in
100+0 records out
819200 bytes (819 kB) copied, 23.6144 s, 34.7 kB/s

The overall rate is therefore 819200 * 20 / 23.6144 = 677kB/s. Certainly not as much as I had hoped for :-(