Raspberry PI PICO ATARI ST Hard Drive Emulator (WIP)

[exxos]

These are DRQ vs CLK8.

220MHz ( basically the same as ultrasatan timing wise ) - Generally works

IMG_0601.JPG

150MHz - Generally fails

IMG_0602.JPG

I also did some experiments with altering the pull-up R301 (DRQ inverter output)


1K DRQ - default
fall 10ns
rise 100-150ns
-failed on creating folder.


500R DRQ
10ns fall
~60ns rise.
-folder creates - copied several files, failed on HDUTIL.APP. pressing retry continued.


220R DRQ
rise 10ns
-failed on creating folder.

So even changing the rise time can make or break this problem it seems.

How it looks, DRQ must actually fall on the 8MHz clock high in order to avoid whatever this problem is.

It must just be a colossal fluke that ultrasatan does this when the Pico drive does it differently and fails.

Don't get me wrong I'm not blaming the drive or the booster for these problems, it is something very peculiar happening with the STE timings somehow when used in this very specific hardware setup.

I do also remember having problems with such signals with Gigafile on a otherwise stock STFM machine. I ended up putting capacitors on the signal which solve the problem at the time. So maybe this problem, whatever it is, is more problematical than I first thought.

It is slightly interesting Atari change the arrangement of the inverter on DRQ. on the original STFM it as a pull-up resistor on its input and is a "push pull" inverter feeding the DMA directly. However on the STE, it is a open collector inverter with the pull-up on its output. Maybe they were just gate saving but there could be other reasons as well I guess.

[ijor]

But it seems to be a issue with the RW signal. I know I had a right time with ultrasatan when I developed my booster. The fix just seemed to be keeping in 8mhz on BR,BG,BGACK. it had to be all 3. I never figured out why back then.

The timing of the RW signal during the actual DMA transfer is not very important. If you have problems with RW they might be related to the command sequence when the CPU writes to the external controller.

How it looks, DRQ must actually fall on the 8MHz clock high in order to avoid whatever this problem is.

DRQ is an asynchronous signal. The relation with the clock is, or at least should be, irrelevant. What matters is the relation with the other signals, mostly with ACK.

[ijor]

It is slightly interesting Atari change the arrangement of the inverter on DRQ. on the original STFM it as a pull-up resistor on its input and is a "push pull" inverter feeding the DMA directly. However on the STE, it is a open collector inverter with the pull-up on its output. Maybe they were just gate saving but there could be other reasons as well I guess.

I think it is just for saving an extra gate, as you are saying. I see no reason for an open collector buffer.

[exxos]

It's annoying because I only have a two channel scope , so it is difficult to get ACK on there as well. But it is in sync with the 8MHz clock as expected. Though it falls in the middle of the CLK8 high, not on a edge. Not saying anything is wrong with that is merely a observation.


Looking back at the DRQ vs CLK8. Ultrasatan has DRQ high for longer :shrug:

us.jpg

vs PICO DRIVE

bban.JPG

Now ACK vs DRQ on ULTRASATAN.

BLUE = ACK
YELLOW = DRQ

NOTE - I am measuring DRQ on the inverter output.

USDRQACK.JPG

PI DRIVE 220MHZ

bban.JPG

[Badwolf]

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

Only just catching up on this thread and have started build up a set of boards for this I made back in December. I may be able to do some tests to help out at some point.

Question, though, as I'm not 100% au fait with the ST(I will be testing on an -E)'s DMA system, and I'm going to concentrate on the write corruption, initially:

If the theory is that DMA transfer is still active even after BGACK has gone high and is therefore being messed about by other data on the bus, ending up with dodgy data on the disc, this should be detectable on the DMA-side, shouldn't it?

Wouldn't triggering on HDCS (pin 9) and monitoring for changes on the other lines whilst this chip select line is active be the place to start? Work back from what's found then.

Cheers,

BW

[exxos]

If the theory is that DMA transfer is still active even after BGACK has gone high and is therefore being messed about by other data on the bus, ending up with dodgy data on the disc, this should be detectable on the DMA-side, shouldn't it?

I'm not sure that is the current theory now... There are multiple problems and angles how to look at all this stuff.

I think the booster is affected by the timing of the DRQ signal depending on how it catches the 8MHz clock. And that timing is somehow screwing up the timing of the RW signal.

[exxos]

Going to try some spinning metal drives. Cannot get the bottom one to register though :cry:

Also taken out that bloody "good dma" as it was causing my floppy drive to malfunction :roll:

IMG_0607.JPG

IMG_0608.JPG

Though HD11 finds a drive it is disabled me from partitioning it or anything :shrug:

Now it's switched itself into German for no reason at all :shrug:

Maybe time just to put the spinning metal drive back on the shelf before I go down another rabbit hole :lol: :roll:

EDIT:

This is DRQ vs 8MHz

IMG_0609.JPG

IMG_0610.JPG

EDIT2:

Same during sector writes.

IMG_0611.JPG

IMG_0612.JPG

Sector test passes fine on this drive as well.


EDIT3:

Original Ultrasatan (black box type)

IMG_0613.JPG

IMG_0614.JPG

So:

DRQ on a spinning metal drive is to be on the CLK8 rise edge mostly.
DRQ on ultrasatan is mostly on the midpoint of the CLK8 HI.
DRQ on ultrasatan (black box) is mostly on the rise or high of the CLK8 HI.
DRQ on the Pico drive is mostly on the fall of the CLK8.

So it seems DRQ can be issued up to about 50ns after CLK8 goes high, anything longer and it causes wright fails.

:dizzy:

[Badwolf]

I think the booster is affected by the timing of the DRQ signal depending on how it catches the 8MHz clock. And that timing is somehow screwing up the timing of the RW signal.

OK, so what's the path from DRQ to the booster (ie. the CPU)?

From what I can see DRQ is completely asynchronous. Its activation is completely unaware of the clock and it only goes to the DMA chip. Presumably it influences the RDY signal, however, which goes to the MCU.

From prior work, we know the DMA cycle is unlike the completely secret behind-the-scenes shifter memory access, so the only way for the MCU to interrupt the CPU to to take over the data bus (it doesn't take over the address bus, IIRC, as it uses its own direct MADx lines) is to start a bus arbitration cycle. BR going low being the cue here.

So the difference from BR going low to actual data exchange (BG, BGACK, data) can be quite long. Possibly more than one bus cycle (RMW?), so I can't see there could be any toe-treading going on there, as the system has to sit and wait nicely normally.

At the tail end, BGACK goes high and the booster starts up again. Well, like you said, perhaps the booster gets involved a bit early. But you've added a full 8MHz cycle delay to that. That ought to rule out any issue there, but to be completely sure, you could always increase that to four 8MHz cycles (16 32MHz cycles), which would be the equivalent of a full bus cycle. Easy enough to try for a quick win.

Then what remains? The only obvious candidate I can think of would be a bus arbitration issue with the booster at the front end. Perhaps it's issuing BG too quicky for the chipset to get its house in order? Perhaps going high-z too late? I'd probably lean towards the former as 1) it's a 32MHz booster so will react quicker to a bus request and 2) it's a 32MHz booster so you'd think it'd go high-z faster, not slower!

I can't see any other connection between the DRQ line and the booster.

You could throw your DSTB1 in there and see if that experiences the same problem? Slightly different booster design.

BW

[exxos]

OK, so what's the path from DRQ to the booster (ie. the CPU)?

None really. DRQ goes to the DMA, which the the data transfer on the bus. That is pretty much it. Other than the GST issues ACK to acknowledge it has transferred the data.

From what I can see DRQ is completely asynchronous. It's activation is completely unaware of the clock and it only goes to the DMA chip. Presumably it influences the RDY signal, however, which goes to the MCU.

Yep.

Though something screws up somewhere relating to the DRQ timing.

From prior work, we know the DMA cycle is unlike the completely secret behind-the-scenes shifter memory access, so the only way for the MCU to interrupt the CPU to to take over the data bus (it doesn't take over the address bus, IIRC, as it uses its own direct MADx lines) is to start a bus arbitration cycle. BR going low being the cue here.

Aside from the CPU giving up the bus to DMA, the CPU does nothing during DMA access.

So the difference from BR going low to actual data exchange (BG, BGACK, data) can be quite long. Possibly more than one bus cycle (RMW?), so I can't see there could be any toe-treading going on there, as the system has to sit and wait nicely normally.

Somewhere in the thread I extended BGACK by about 60ns.. that is the time RW signal seems to accept the booster for. But made no odds. So I don't believe it is a bus grant related issue any more.

At the tail end, BGACK goes high and the booster starts up again. Well, like you said, perhaps the booster gets involved a bit early. But you've added a full 8MHz cycle delay to that. That ought to rule out any issue there, but to be completely sure, you could always increase that to four 8MHz cycles (16 32MHz cycles), which would be the equivalent of a full bus cycle. Easy enough to try for a quick win.

I have very limited what I can do in the GAL. 4x 32mhz clocks is about as good as I can do.

Like I posted earlier, it seemed like after BGACK goes high, RW is still low for about 60ns depending where you want to take a logic one from. But at the speed the CPU is going could easily conflict with the RW signal on the CPU. this is why I added a 1K pullup on RW to speed it up. which it did. But it did not change anything at all. So it is like RW is affected but not after a DMA cycle. It could just be in general. But if it was in general, why does the booster even work to start with and only screws up after a DMA cycle :lol: :roll:

Then what remains? The only obvious candiate I can think of would be a bus arbitration issue with the booster at the front end. Perhaps it's issuing BG too quicky for the chipset to get its house in order? Perhaps going high-z too late? I'd probably lean towards the former as 1) it's a 32MHz booster so will react quicker to a bus request and 2) it's a 32MHz booster so you'd think it'd go high-z faster, not slower!

I already tried messing with all that stuff about a week ago. I only just started posting this info on the forum a couple days ago because it was getting too complicated not to write all this down properly :lol: :roll:

But the bottom line is whatever combination of BR,BG,BGACK, CPU SPEED, makes no odds whatsoever.

I can't see any other connection between the DRQ line and the booster.

There isn't. We don't necessarily even need to have the booster into generate the problem. Even the booster in 8MHz mode can fail. But ironically adding RW into the "slow down" clause also seems to work. Which there is no way in hell that has anything to do with anything because it is all 8 MHz anyway. It's why I went down another rabbit hole of rise and fall times etc.

The only clue to it all is that when the 8MHz clock gets delayed even by few ns (The CPU can just be direct in the STE as normal) it is generally enough to replicate the problem again.

Also I said somewhere earlier placing the scope probe on X1 on DRQ can cause things to malfunction. It can even happen on the 8MHz clock. They generally I was using a 33pF there. But there could be for the factors involved.

Basically there seems be a lot of things right on the border for some tolerance somewhere.. It is finding what that borderline timing is which is the problem.

You could throw your DSTB1 in there and see if that experiences the same problem? Slightly different booster design.

I could probably try that in the future but confused enough as it is without throwing more hardware into the mix :lol:

[exxos]

Been doing more testing with the original black box ultrasatan and the timing on this one is all over the place.

I guess this kind of rules out my theory with DRQ. Even though it is still known that the timing of that signal is causing problems somehow still.

IMG_0616.JPG

IMG_0615.JPG

IMG_0617.JPG

Back to square one I guess :(

But basically the problems are only seeming to be with the PICO drive now :shrug: