Raspberry PI PICO ATARI ST Hard Drive Emulator (WIP)

[stephen_usher]

Wouldn't that be almost the same as dumping known bit patterns to the drive and reading them back like jookie's test program does anyway ?

If his program just does a contiguous read then it possibly doesn't. Reading random words from the file requires rapid, multi cylinder seeks between reads. This is both testing for lost seeks and miscalculation of the location when doing seeks.

I know from experience with my Apricot HD simulator using a Pico that with an off-by-one error in my cache code meant that in certain situations one byte would not be written and that was a head scratcher as to why the files were being corrupted.

[dad664npc]

The ACSI commands are the same for TOS and the HD test programme - they are both using 6 byte commands

[dad664npc]

Wouldn't that be almost the same as dumping known bit patten's to the drive and reading them back like jookies test program does anyway ?

If his program just does a contiguous read then it possibly doesn't. Reading random words from the file requires rapid, multi cylinder seeks between reads. This is both testing for lost seeks and miscalculation of the location when doing seeks.

I know from experience with my Apricot HD simulator using a Pico that with an off-by-one error in my cache code meant that in certain situations one byte would not be written and that was a head scratcher as to why the files were being corrupted.

There aren't any seeks in the generic sense. sd-cards are addressed by sector number (LBA). So just read/write commands with a LBA

[Badwolf]

I got my own board (@dad664npc's version from December) assembled and flashed yesterday. It doesn't work, but I was expecting this as it uses the TXB0108 chips spec'd at the time which are now not believed to work.

However I do now want to debug it, so will be trying to learn a bit about ACSI and how the design hangs together. If I learn, find or write anything possibly useful I'll chip in.

My board does spit out debug spam onto the USB serial port successfully, so I've a foot in the door. I think it's failing to read the SD card, so the chat two and from the ST is immaterial at present.

In terms of a test program, the first thing that springs to mind is to write something that replicates the ACSI commands that are seen to fail and do so repeatedly, checking for a discrepancy. The fact you (@exxos) have a log of commands sent during a failure is extremely useful for this.

I wouldn't bother with anything that tries to write to files or drives (reliant on GEMDOS and the driver), but go down into the weeds early doors.

BW

[exxos]

I tried syncing DRQ to CLK8 but was unsuccessful in changing anything :(

There is still a mystery of why DRQ is extremely sensitive. I thought running it through a DFF may help or make it worse but it changed nothing. Theoretically you should not do anyway, but I really had no other avenues to explore.

I have basically hit a wall because there is simply nothing else for me to try.

IMG_0618.JPG

IMG_0619.JPG

I could see a potential hiccup, where keeping the CPU in 8MHz based on RW low would potentially help, and it does. But this unfortunately does not explain the issues with 8MHz mode. Which seems to be ironically working fine again now. :roll:

Capture.PNG

I thought I figured it out back in this post viewtopic.php?p=100387#p100387 but guess its difficult with the faults being so random :(

I tried adding 33pF back to the 8 MHz clock again. It failed repeatedly to even get to desktop. Signal does not look any much different other than the over and under shoots are slightly less.

EDIT:

Now the display has gone into a funky disc even though it looks like the ST is still trying to boot.

IMG_0620.JPG

I wonder if the 33pF Is adding a slight delay where it then misses its "time slot" for RAM accesses.

[stephen_usher]

There aren't any seeks in the generic sense. sd-cards are addressed by sector number (LBA). So just read/write commands with a LBA

The ACSI interface will be using CHS addressing however.

[dad664npc]

Nope

Screenshot 2023-05-18 at 10.58.46.png

[exxos]

Going back to 220MHz tests. On boot up.

Code: Select all

RESET
RESET
RESET
RESET
CMD_READ        tgt=0 lun=0 (0x08:00:00:00:01:00) (00)
CMD_READ        tgt=1 lun=0 (0x08:00:00:00:01:00) (02)
CMD_READ        tgt=1 lun=0 (0x08:00:00:00:01:00) (02)

Then get 4 bombs. Though writes (at least in general) have worked better at that speed.

[exxos]

I too can replicate what exxos has seen, in that a cold startup, writes work for a few minutes before corruption starts.

Do you also get this at 8MHz with either the original or beta GAL firmware ? I've lost track.

Been doing testing with another revised firmware and I think is just be easier to release the tweaked GAL firmware for anyone who ends up with similar issues. It seems to be working at both 8MHz and 32MHz speeds now.

The problem is I'm just going around in circles with all of this. For some bizarre reason, it seems like the RW timings gets screwed up with some drives but not others. As to how it can go from a DMA cycle to a RW timing skew is beyond me. But after spending the best part of three weeks on this, I am just getting nowhere, and if the tweaked GAL firmware offers a workaround and it seems to work, then that will just have to be the fix for now.

[dad664npc]

I am back to using the original GAL firmware. Writes are corrupted in both 8 MHz and 32 MHz