Smonson's untitled simple harddisk project

[Smonson]

So I've been messing around with a simple fixed disk project (a background task while waiting for stuff to come in the mail), I think it's basically the same as Jookie's SatanDisk actually, although I don't own a SatanDisk nor have I looked at any of the fine details of how it works. I just know it's an MCU with some kind of CPLD/FPGA to interface with the DMA bus. I am in no way attempting to rip off Jookie's idea, I just like to work things out on my own, as you may have noticed if you've seen my other posts. I'll document this project in this thread, for better or worse, for the interest of other forum users.

So I started off with just hooking up an AVR to the ASCI bus, and bit-banging a few things, but I pretty soon realised there's no way it can react fast enough to work, so I gave up on that attempt. That was last year. At that time I quickly learned why you need an FPGA.

My second prototype, which is where I'm up to now, adds a low-cost FPGA (MAX-V 5M40Z which is crazy cheap at only 90 US cents! But hard to solder as it has a pad on the bottom) into the mix. I just put a large plated through-hole under the chip and insert the tip of the soldering iron into that hole from underneath to melt the solder. That's probably not the ideal way to do it but it has worked so far :D

pth.jpg

Here's a pic of it:

sd1.jpg

I used some through-hole parts because I assumed I was going to be adding bodge wires, and I was right - I've had to add two - although unfortunately I still had to connect them to the FPGA (in the middle of the board) which is super tiny. Subsequent to this pic I had to add a second one.

sd2.jpg

I added a breakout in the middle of the cable for my cheap ebay logic analyser - and it's a good thing I did because I have relied on that thing extremely heavily.

The good news is, I don't think I need to add any more wires, because the physical communication part seems to be working OK now. I have only implemented TEST UNIT READY and INQUIRY at the moment, but the ST is communicating with it, both in command-mode transfers and in data-mode. I think you need to implement about 6 or so commands for it to be deemed a real working device.

sd3.jpg

The next step will be to add dummy data transfers and then after that, actual communication with the SD card.

[PhilC]

Looks like a great start as usual @Smonson . If you need any help breaking it, then let me know :lol:

[JezC]

Very interesting approach - I will be following your progress with great interest!

:goodpost:

[derkom]

But hard to solder as it has a pad on the bottom) into the mix. I just put a large plated through-hole under the chip and insert the tip of the soldering iron into that hole from underneath to melt the solder. That's probably not the ideal way to do it but it has worked so far :D

Have a look at the OSSC schematics for a similar, but different approach to this. It's got the same central large hole you've done, and then a grid of much smaller holes around. If you put flux down on the component side before you put the chip down, it'll do a really good job of sucking solder up through the holes and tacking on that heatsink.

[beel1]

Again a nice project from mister Smonson :D
I guess the ATARI ACSI/DMA Integration Guide is your new bedisde book :D

During the lockdown I tested RaSCSI with great results, so I was thinking of using the RPI to take care of the ACSI/SCSI conversion but I think it's a bit ambitious :D

[Smonson]

Again a nice project from mister Smonson :D
I guess the ATARI ACSI/DMA Integration Guide is your new bedisde book :D

Thanks @beel1 , yeah I have been mainly working from that document. Fortunately it's well written and easy to follow, until the SCSI spec which is absolutely awful.

[Smonson]

Have a look at the OSSC schematics for a similar, but different approach to this. It's got the same central large hole you've done, and then a grid of much smaller holes around. If you put flux down on the component side before you put the chip down, it'll do a really good job of sucking solder up through the holes and tacking on that heatsink.

That's interesting, I didn't think of that. I've just bought a small toaster over and am going to try the classic DIY reflow oven trick. If that works out I might also have a third option.

[Smonson]

OK, I've got a question or two that someone more knowledgeable might know the answer to. I've been using the ICD Pro driver disk as a test utility (I'm a cheapskate), but I'm a bit confused about it.

1) Do ICD Pro compatible drives use a different protocol from ACSI? - I see references to LUNs and things like that which are not described in the Integration Guide. Also, despite appearing in the IDCHECK and HDSTART utilities, in most of the other tools such as the partitioner, it tells me there are no drives present.
2) I do not see any command in the ACSI command set that can tell the host how big the device is. However surely the host needs that info when partitioning the device. I see total capacity info in screenshots of partitioning/formatting software - is that because ACSI is actually rubbish and no drives actually use it?

[stephen_usher]

Surely ACSI is just using the SCSI command set as host adapters are pretty dumb and merely interface with the SCSI bus directly?

[beel1]

Maybe you can start first with Atari's AHDI?
ICD made ACSI-SCSI adapters known for their extended SCSI commands set support (group 1) using 2-bytes commands (IIRC $1F+group1 command byte) where ACSI is limited to 5bits commands (group0)