Raspberry PI PICO ATARI ST Hard Drive Emulator (WIP)

[exxos]

Problem with seek commands being missed?

Code: Select all

CMD_READ        tgt=0 lun=0 (0x08:03:2e:34:0a:00) (00)
CMD_WRITE       tgt=0 lun=0 (0x0a:03:2e:35:0a:00) (00)
CMD_READ        tgt=0 lun=0 (0x08:03:2e:35:0a:00) (00)
CMD_WRITE       tgt=0 lun=0 (0x0a:03:2e:36:0a:00) (00)
CMD_READ        tgt=0 lun=0 (0x08:03:2e:36:0a:00) (00)
CMD_WRITE       tgt=0 lun=0 (0x0a:03:2e:37:0a:00) (00)
CMD_READ        tgt=0 lun=0 (0x08:03:2e:37:0a:00) (00)
CMD_WRITE       tgt=0 lun=0 (0x0a:03:2e:38:0a:00) (00)
CMD_READ        tgt=0 lun=0 (0x08:03:2e:38:0a:00) (00)
CMD_WRITE       tgt=0 lun=0 (0x0a:03:2e:39:0a:00) (00)
CMD_READ        tgt=0 lun=0 (0x08:03:2e:39:0a:00) (00)
CMD_WRITE       tgt=0 lun=0 (0x0a:03:2e:3a:0a:00) (00)
CMD_READ        tgt=0 lun=0 (0x08:03:2e:3a:0a:00) (00)
CMD_WRITE       tgt=0 lun=0 (0x0a:03:2e:3b:0a:00) (00)
CMD_READ        tgt=0 lun=0 (0x08:03:2e:3b:0a:00) (00)
CMD_WRITE       tgt=0 lun=0 (0x0a:03:2e:3c:0a:00) (00)
CMD_READ        tgt=0 lun=0 (0x08:03:2e:3c:0a:00) (00)
CMD_WRITE       tgt=0 lun=0 (0x0a:03:2e:3d:0a:00) (00)
CMD_READ        tgt=0 lun=0 (0x08:03:2e:3d:0a:00) (00)
CMD_WRITE       tgt=0 lun=0 (0x0a:03:2e:3e:0a:00) (00)
CMD_READ        tgt=0 lun=0 (0x08:03:2e:3e:0a:00) (00)
CMD_WRITE       tgt=0 lun=0 (0x0a:03:2e:3f:0a:00) (00)
CMD_READ        tgt=0 lun=0 (0x08:03:2e:3f:0a:00) (00)
CMD_WRITE       tgt=0 lun=0 (0x0a:03:2e:40:0a:00) (00)
CMD_READ        tgt=0 lun=0 (0x08:03:2e:40:0a:00) (00)
CMD_WRITE       tgt=0 lun=0 (0x0a:03:2e:41:0a:00) (00)
CMD_READ        tgt=0 lun=0 (0x08:03:2e:41:0a:00) (00)
CMD_WRITE       tgt=0 lun=0 (0x0a:03:2e:42:0a:00) (00)
CMD_READ        tgt=0 lun=0 (0x08:03:2e:42:0a:00) (00)
CMD_WRITE       tgt=0 lun=0 (0x0a:03:2e:43:0a:00) (00)
CMD_READ        tgt=0 lun=0 (0x08:03:2e:43:0a:00) (00)
CMD_WRITE       tgt=0 lun=0 (0x0a:03:2e:44:0a:00) (00)
CMD_READ        tgt=0 lun=0 (0x08:03:2e:44:0a:00) (00)
CMD_WRITE       tgt=0 lun=0 (0x0a:03:2e:45:0a:00) (00)
CMD_READ        tgt=0 lun=0 (0x08:03:2e:45:0a:00) (00)
CMD_WRITE       tgt=0 lun=0 (0x0a:03:2e:46:0a:00) (00)
CMD_READ        tgt=0 lun=0 (0x08:03:2e:46:0a:00) (00)
CMD_WRITE       tgt=0 lun=0 (0x0a:03:2e:47:0a:00) (00)
CMD_READ        tgt=0 lun=0 (0x08:03:2e:47:0a:00) (00)
CMD_WRITE       tgt=0 lun=0 (0x0a:03:2e:48:0a:00) (00)

It is currently doing sector test again and it just simply does not fail.

[stephen_usher]

It is currently doing sector test again and it just simply does not fail.

But what about seek->write->seek->read cycles? We pretty well know that the read/write is working but if the seek is messing up the writes will be to the wrong place on the drive.

[exxos]

But what about seek->write->seek->read cycles? We pretty well know that the read/write is working but if the seek is messing up the writes will be to the wrong place on the drive.

Problem is , what programs would I use to specifically test for that ?

This is a failed copy.

Code: Select all

TEST_UNIT_READY tgt=0 lun=0 (0x00:00:00:00:00:00) (00)
CMD_WRITE       tgt=0 lun=0 (0x0a:00:0a:28:08:00) (00)
CMD_READ        tgt=0 lun=0 (0x08:00:0a:68:08:00) (00)
CMD_READ        tgt=0 lun=0 (0x08:00:0a:70:08:00) (00)
CMD_WRITE       tgt=0 lun=0 (0x0a:00:0a:70:08:00) (00)
CMD_WRITE       tgt=0 lun=0 (0x0a:00:0a:68:08:00) (00)
CMD_READ        tgt=0 lun=0 (0x08:00:0a:28:08:00) (00)
CMD_WRITE       tgt=0 lun=0 (0x0a:00:0a:28:08:00) (00)
CMD_WRITE       tgt=0 lun=0 (0x0a:00:00:b8:08:00) (00)
CMD_WRITE       tgt=0 lun=0 (0x0a:00:00:48:08:00) (00)
CMD_READ        tgt=0 lun=0 (0x08:00:0a:28:08:00) (00)
TEST_UNIT_READY tgt=0 lun=0 (0x00:00:00:00:00:00) (00)
CMD_WRITE       tgt=0 lun=0 (0x0a:00:0a:28:08:00) (00)
CMD_READ        tgt=0 lun=0 (0x08:00:0a:78:08:00) (00)
CMD_READ        tgt=0 lun=0 (0x08:00:0a:80:08:00) (00)
CMD_WRITE       tgt=0 lun=0 (0x0a:00:0a:80:08:00) (00)
CMD_WRITE       tgt=0 lun=0 (0x0a:00:0a:78:08:00) (00)
CMD_READ        tgt=0 lun=0 (0x08:00:0a:28:08:00) (00)
CMD_WRITE       tgt=0 lun=0 (0x0a:00:0a:28:08:00) (00)
CMD_WRITE       tgt=0 lun=0 (0x0a:00:00:b8:08:00) (00)
CMD_WRITE       tgt=0 lun=0 (0x0a:00:00:48:08:00) (00)
CMD_READ        tgt=0 lun=0 (0x08:00:0a:28:08:00) (00)

[Badwolf]

Which sounds logical (software) rather than physical (hardware), as why would the hardware care?

That's the problem as well. Because ultrasatan (two different variants of it) work fine and also they old spinning metal drive works fine. Plug in the Pico drive and it will fail. So you think it is the driver at fault ? but how ?

No, I don't think it's the driver, but there's too large a stack to narrow down the problem.

It could be an unimplemented command, a command taking too long or too short compared to what's expected. Anything really. Could be a corrupted read all the way back at the start resulting in GEMDOS having the wrong filesystem information and so ballsing things up later on.

You simply can't tell. It's a necessary final test, but it can't really be used to identify the problem.

That is the one I have been using. It did reliably fail up until today.

Which is why I was thinking a dedicated (non-driver, non-filesystem, non-vectored) test program that can manifest it is needed.

Yes but other than file copies does not seem to be any programs to specifically test this problem.

I'll have a look at Jookie's program (not familiar with it), but we may need to write something.

What's the situation with a different driver (eg. ICD, EmuTOS)?

BW

[exxos]

What's the situation with a different driver (eg. ICD, EmuTOS)?

We tried other drivers, still same problem. I've not Tried EMUTOS. I stopped using it TBH.

There has been one "fix" I did in the GAL code. but oddly when I tested it only worked in 32MHz mode. In that I did not allow 32MHz while RW was low. That seemed to greatly help. But that in itself does not make much sense because /AS has to be low by something to drive RW low anyway. This is why I went through all the rigmarole of adding a extra pullup on the RW line etc as it was rather sluggish to rise. However it did not help. But ultimately I gave up with that GAL method.

At one point it worked at 8MHz WITH the RW clause, and did not work without it. There were all this was that 8MHz, so how could even affect anything ? it was at that point I removed the GAL and just jump at the input and output clocks. And it still failed to work reliably. Which then brought me on to the only real difference is the buffers on the clock. Because again on my early booster research I had no end of problems with the 8MHz clock. It really does not like 33pF on it. But it is a little "stiff" so not sure if that's replicating the problem easier, or creating a new one.

The only other thing I have noticed, which was actually on the STFM during my SEC booster work, is that there seemed to be some problem relating to A1. At one point I actually run it via the PLD which seem to solve a lot of weird problems. Though later testing I actually removed it because I could not replicate the fault again. But with me switching between various machines all the time it is possible it could still show its ugly head at some point.

Currently I am only testing in 32MHz mode because that is I assume a greater failure point than 8MHz. In fact I just tested it and 8MHz mode is now working ( it wasn't all of last week or the week before). Is like the fault keeps changing all the time :roll: But saying that, this particular booster board is a different one than I was using the previous couple of weeks. But it is still the same revision & CPU & GAL. So that could be the reason for different behaviour as of the past couple of days.

[exxos]

I guess if anyone is good at coding who could write a quick test program for me may help. Even if it is just writing a bunch of random folder names continuously. If I could AutoBoot that, then at least I could go around the CPU probing everything on X1 to see if it makes things worse on any particular pin.

[stephen_usher]

The easiest program to write would write consecutive 32 bit values being the location in the file and make the file, say, 1MB in size. Then seek to a random place in the file and read the data, checking to see if the value read equals the “address” in the file. This is effectively “read own address” as used in memory testing.

[exxos]

The easiest program to write would write consecutive 32 bit values being the location in the file and make the file, say, 1MB in size. Then seek to a random place in the file and read the data, checking to see if the value read equals the “address” in the file. This is effectively “read own address” as used in memory testing.

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 ?

Currently sector writes reads verify works. It's when copying folders where it messes up.

I'll go pester jookie for a bit :lol: was talking to him a few months back for a new test program anyway..

[dad664npc]

HDtest03 on my setup (STE) does not fail. I have left the read/write verify loop running for several hours and did not notice a single R or W error (highly possible that I missed such an event as I wasn't watching for that amount of time lol) - would be nice to have a version that didn't print anything other than an error. Likewise, the sector fill works. I have added a sector dump command to the PICO shell which shows the written data on the sd-card. If it's correct there, then the IO transfer definitely worked.

Screenshot 2023-05-18 at 06.16.46.png

Same results are yielded in TOS1.62 and 2.06 running the accelerator at 8MHz only. But the TOS file writes fail somewhere.
I too can replicate what exxos has seen, in that a cold startup, writes work for a few minutes before corruption starts.

[exxos]

I think TOS uses long word accesses and the test program doesn't @dad664npc though the program was failing to me originally. It would only write the first sector then go nuts.

As the reason for a sensetive DRQ isn't yet know , I may try and run it though a latch to sync it to the 8mhz clock to see if there is a fluke timing glitch somewhere.