Raspberry PI PICO ATARI ST Hard Drive Emulator (WIP)

[dad664npc]

From responses to my new-member post, it seems a few of you are interested in my Raspberry PI PICO implementation of an HDC emulator.

I know there are a few solutions out there already, and a ton of work has been done on this in the past, but, typical of me, I'm late to the party... by several years.

Anyway, I purchased my ATARI 520ST on a whim a month or two ago. Now I have it, what am I gonna do with it? I know, I'll build a disk controller! That was pretty much my thought process.

Without rambling on anymore, I have made myself an HDC emulator, working on the very cheap Raspberry PI PICO. R/W speeds aren't particularly the best. With the uSD card clocked at 20 MHz, I see -

Code: Select all

CPU f       Transfer Rate   Access Time
133 MHz     571 KB/s.        2.5ms
200 MHz.    604 KB/s.        2.5ms
250 MHz     618 KB/s.        2.4ms
300 MHz.    635 KB/s.        2.4ms

Measurements taken running AHPT94.PRG

I'll gladly share my design if there is interest.
It's built on Vero-board, no professional boards made lol.
Cheers
Steve

IMG_20221029_050442.jpg

[Steve]

I'd be very interested in how this design works alongside different ST models to see if the drive ever becomes corrupt. As you've been away @dad664npc you may not be aware of the constant struggles users have with drive emulators like the Ultrasatan and others, where the file system can randomly become corrupted. This often looks to be an issue with the ST itself and not so much the drive emulator, but in regards to the Blue pill drive emulator varient one of the developers 'masteries' tweaked the firmware many times and seemed to find the 'sweet spot' for STe compatibility. So on one side you have many fixes for the ST itself, like bus pullup changes, HC CPU swap, DMA chip swaps etc - but then on the other side you have drive emulators tweaking their firmware to overcome the issues. So the problem is probably partly due to the aging components in the original system but also perhaps it may also be to do with certain tolerances in the ACSI spec on the drive emulator side. These issue are more prominent on STe models but also do appear on STfms from time to time.

[dad664npc]

Thanks for your reply. Unfortunately, I don't have access to any other ATARI models.
It took a while to get the signal timings working, but am happy that it works on my machine. I am looking in to why RW speeds are poor. It isn't CPU bound, meaning the bottleneck is the read/write code or the SPI interface.
As for corruption, now that I have the timings sorted, I think I'm okay. I certainly experienced write problems though initially, and resolved the issue by introducing a needed delay at the end of each DMA byte transfer. I read somewhere, a delay of 240ns minimum is needed before taking DRQ low again. However, I have reduced the delay to 120ns which works for my machine. Of course, as you say, this figure may need altering for the slowest machines.

My ST does not have ANY mods done except for the 4MB RAM upgrade I purchased from here two weeks ago.

[sporniket]

Nice work, did you use PIO to implement the ACSI protocol, or did you just bit-banged the ACSI port as quickly as the pico's arm core can go ?

[dad664npc]

I tried PIO for the command decoding, which worked, but didn't offer any benefit and to be honest, I felt less flexible. Not bit-banging either. Just loop waiting for A1 low then read the bytes (parallel) as they come in. The DMA transfers are in a tight loop of course, but handshaking goes on along with a small delay after each byte is transferred. The interface works happily with the PICO clocked at 100MHz and returns 550 KB/s

[tzok]

Do you know ACSI2STM? It has a few interesting tricks. One of them is injecting a driver, so a regular FAT16 formatted card will boot, no need to install any driver on it.

[olivier.jan]

Great work, this looks very promising ! Performances can’t really be compared with other solutions, from what you write you only have spent a few weeks on this while other solutions have been refined over years.
One of the great advantages of your solutions :Pi pico is available, which at the moment is not the case for other products.
So, yes, a lot of interest for this solution. What are the other chips you’re using(apart from the level converters) ?

[dad664npc]

I have looked at other solutions to see how they implemented the command monitoring, in particular, the extended commands. My priority was/is to make a simple reliable interface. I feel that has been accomplished. So, I can look at adding complexity and features now. Note of course - this has only been working for a few days on the PICO lol, so can argue, it is a little too soon to judge reliability :D

Initially, I didn't think the PICO would be suitable and in actual fact, I used an OLIMEX board I had in my "Man Tin" - https://www.olimex.com/Products/PIC/Dev ... e-hardware - a PIC32 MCU. This has 5v tolerant inputs, so I wired up an IDC connector directly to it. I had something working pretty quickly and was getting 900+ KB/s. Maybe I'll come back to this if the PICO won't perform.

The circuit is very simple - two tri-state octal bus transceivers (74LVC245) and one open-collector non-inverting buffer (74LS125). The PICO does not have 5v tolerant GPIO pins. The data-bus transceiver was wired so the ACSI RW signal drove the chips direction - this meant A & B sides had to be wired backwards i.e. B = ACSI bus, A = PICO GPIO. I later found out this to be bad! I don't believe the B side to be 5v tolerant so the A side signals (when reading) looked very odd which caused inconsistent command byte results. Also, I was introducing latency by enabling and disabling the chip and when reading the chip data sheet, noted the direction switch latency. As soon as I replaced this chip for a bidirectional level shifter, it burst in to life.

I have now seen a better chip for the design - TXB01DBDQSR, but these chips aren't available in DIL packaging

[tzok]

Pi Pico is great, because it is small, inexpensive, easily available, and doesn't require any specialized programmer. So any DIY project using Pico is "destined for success". PICs on the other hand never really was popular amongst entry level "makers", and was wiped out by inferior ATMega, thanks to Arduino boards.

[dad664npc]

I have found an image which has 5 partitions and boots the HD using ICD driver - Atari_ST_Games_Petari_20181212_ACSI_1_6GB_4+4x400MB_ICD
The few games I have tried to run, fail. Is this typical? or could this be a problem with my hardware/software implementation?