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
Here's a pic of it:
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.
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.
The next step will be to add dummy data transfers and then after that, actual communication with the SD card.
Smonson's untitled simple harddisk project
Re: Smonson's untitled simple harddisk project
Looks like a great start as usual @Smonson . If you need any help breaking it, then let me know
If it ain't broke, test it to Destruction.
Re: Smonson's untitled simple harddisk project
Very interesting approach - I will be following your progress with great interest!
Re: Smonson's untitled simple harddisk project
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.Smonson wrote: ↑Thu Jul 16, 2020 2:29 pm 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
Re: Smonson's untitled simple harddisk project
Again a nice project from mister Smonson
I guess the ATARI ACSI/DMA Integration Guide is your new bedisde book
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
I guess the ATARI ACSI/DMA Integration Guide is your new bedisde book
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
Re: Smonson's untitled simple harddisk project
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.
Re: Smonson's untitled simple harddisk project
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.derkom wrote: ↑Thu Jul 16, 2020 4:21 pm 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.
Re: Smonson's untitled simple harddisk project
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?
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
- Posts: 5661
- Joined: Mon Nov 13, 2017 7:19 pm
- Location: Oxford, UK.
- Contact:
Re: Smonson's untitled simple harddisk project
Surely ACSI is just using the SCSI command set as host adapters are pretty dumb and merely interface with the SCSI bus directly?
Intro retro computers since before they were retro...
ZX81->Spectrum->Memotech MTX->Sinclair QL->520STM->BBC Micro->TT030->PCs & Sun Workstations.
Added code to the MiNT kernel (still there the last time I checked) + put together MiNTOS.
Collection now with added Macs, Amigas, Suns and Acorns.
ZX81->Spectrum->Memotech MTX->Sinclair QL->520STM->BBC Micro->TT030->PCs & Sun Workstations.
Added code to the MiNT kernel (still there the last time I checked) + put together MiNTOS.
Collection now with added Macs, Amigas, Suns and Acorns.
Re: Smonson's untitled simple harddisk project
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)
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)