Raspberry PI PICO ATARI ST Hard Drive Emulator (WIP)

[exxos]

As a bit of a future thought. I wonder if people would be interested in cases for these things in any shape or form ?

I could design a STL (at some point) and release it freely so that people could print their own. And/or have a small batch of them made in China. Though I am not sure what the costs of that would be or what people would be prepared to pay for a enclosure.

I could print them on my own 3-D printer but I think I would just limit that to prototypes more than anything.

[jfceklosky]

Cases would be nice. Please post the STL files so that people can print their own or farm it out to a company like JLBPCB.

I have used them for devkit based Fujinet cases and they did a great job with them.

[shift838]

Are these PICO Pi units available for purchase yet, I did not see them on the store.

[exxos]

Are these PICO Pi units available for purchase yet, I did not see them on the store.

We are still building a batch up.

[exxos]

I have been doing some more testing and run into a problem when my V1 STE booster is used. The problem does not seem as simple as to blame the booster or the hard drive.

Basically it ends up with hard drive corruption during writes, but reads are not reliable either. This only happens when the booster is installed. But also the problem does not happen at all with ultrasatan.

I have been looking at the various timings between both hard drives and long story short while there is differences there is nothing we should really matter. Signals all look basically fine quality wise but I've even done various tests with that also.

Oddly when the scope is on X1 on the DRQ signal screws up even more. Switching to X10 It is more stable. But I cannot see any relation or difference between the PI drive and ultrasatan. I even added a extra 1K pullup on it, made no odds.

Even running the booster in 8 MHz mode still manages to cause the problem. I've even taken the GAL Out of the booster and hardwired the clock to CPU. The only thing there thing like a 6ns delay on the 8MHz clock due to the buffers. This seems enough to cause problems.

I have had problems with the 8MHz clock on the STE before, I have tried adding some small capacitance and resistance on the line but sometimes I think it makes things better and other times I think it makes it worse. It is difficult to tell.

Another problem as the CPU has very little to do with DMA cycles past the bus grant cycles. I have tried delaying BGACK to the CPU by a few 32MHz clocks and it does give the appearance that it helps and indeed witness the same thing with other tests.

It is like the DMA cycle has not actually completed even though BGACK has gone high and there should be theoretically nothing using the bus at that point. But "stalling" the CPU generally seems to help. But again why ?

With the CPU being delayed slightly on the clock you would think if anything it will be better as it is not actually running faster which could potentially cause problems. But that does not seem to be the case.

I have pretty much tried everything I can think of over the past week and ran out of ideas. The anything which does seem to help in my case is speeding up the PI clock on writes, and slowing it on reads. But this did not help with dad664npc tests. Plus I'm now seeing corruption running at whatever speeds now than I was last week.

Incidentally we are using the -38 DMA. but again I remind people that it works fine with ultrasatan, and for those who say change it to the "GOOD DMA".. That does not work either. In fact its actually worse :roll:

So unintentionally we seem to have uncovered a new "DMA BUG" by the looks of it :roll:

So if anyone has any ideas as to what is possibly tripping up here and please let me know because I am out of ideas. Maybe @ijor My be more familiar with timings with all this stuff ? But this is of course on a STE.

EDIT:

Forgot to mention that I kept the CPU clock in 8MHZ longer during 32MHZ mode based on if RW was high or not. Waiting for it to go high seemed to help. But that doesn't make sense why it worked in 8MHz mode as it was all 8mhz anyway.


EDIT2:

Also my current test keeps BACK low to the CPU for a extra 4x32mhz clocks. It seems to help in 8MHz mode. But fails in 32MHz.

The "feel" I get is the bus is still in use after a DMA cycle, despite BGACK going high.

The problem with that theory is that ultra Satan works every time perfectly..

[exxos]

I've done some more testing.

Adding RW into the switching code seems to help with 32MHz modes. It seems something is too slow in releasing the bus or RW at some point.

Adding a extension to BGACK helps with the 8MHz mode.

BGACK does not appear to cause any slowdown. But when RW is in the equation then there is a small drop of several percent in most of the scores in GB6.

I also suspect the problem can be replicated even without the booster in just adding a few pF onto the 8MHz clock on the STE motherboard. X1 probe seems enough with the booster fitted even at 8MHz to cause more issues.

I can only assume something is screwing up internally in the GST relating to the 8MHz clock and likely bus grant stuff.

[sporniket]

I remember correctly, some democoders/68k guru ( like @troed if memory serves me right) craft some sequences of read+write (or write+read ?) to optimise the bus throughput (I mean, one of the sequence means that the 68k keeps the bus for itself instead of giving a chance to process a bus request, or something like that).

Could it be that kind of behaviour that triggers what you saw ?

[exxos]

I remember correctly, some democoders/68k guru ( like @troed if memory serves me right) craft some sequences of read+write (or write+read ?) to optimise the bus throughput (I mean, one of the sequence means that the 68k keeps the bus for itself instead of giving a chance to process a bus request, or something like that).

Could it be that kind of behaviour that triggers what you saw ?

Don't know about that thing..

Though all I am doing is copying files on the GEM desktop from floppy to C: drive.

I tried a completely different booster and hardwired it to 8MHz and it worked. Started swapping CPUs around the fault follows the CPU. Could simply be down to tolerances or something else.

Loading 8MHz with the CPU directly in the MB doesn't trigger the problem either.

I must have spent like 50+ hours on this problem so far :(

[exxos]

Pretty bizarre. One CPU consistently came up 2 bombs on the very last file copy. I put my scope on A1 on X1 and it then passed a few times. Remove the probe and it was not crashing any more. Went to the loo, came back. Then a row of bombs on the screen.

[Steve]

It might be worth throwing another type of hard disk emulator into the mix, for another reference point. The open source ACSI2ST based on the Bluepill would be a good idea. If you verify whether that works or not, will give you more data to understand why. Plus since it is open source, you can see how it operates (and have other experts on hand to try and diagnose)