Raspberry PI PICO ATARI ST Hard Drive Emulator (WIP)

[exxos]

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)

I did wonder that but I could not find any which already to plug in and go kinda thing :(

But you see the problem is, it works perfectly well with ultrasatan. There should be no difference between any hard drive is used because the ST takes care of everything.

It implies it is the hard drive at fault. That could be the case but it only does it when the booster is involved, even at 8MHz.

Is very difficult to get any sort of idea where the fault is actually emanating from :( It seems to stem from a tiny delay on the 8MHz clock.

I do have one of the old school hard drive somewhere. I did consider plugging that in but what exactly a lot of room to plug such stuff in currently :roll:

[Steve]

I remember reading (I forget where, I think one of the people on this forum) mentioning that the pull-ups on the Ultrasatan were so large they were surprised that it wasn't damaging the host machine. Not sure if that is a factor, just something that stuck in my memory.

[exxos]

I remember reading (I forget where, I think one of the people on this forum) mentioning that the pull-ups on the Ultrasatan were so large they were surprised that it wasn't damaging the host machine. Not sure if that is a factor, just something that stuck in my memory.

I remember that also.

I did look at the schematic for ultrasatan the other day..

Capture.PNG

Its clamped to 3.3V via a zener diode.

So 5V on the DMA port, -3.3V zener, 1.7V / 220 = almost 8mA. Certainly could be a factor but little bit difficult to prove.

It could be acting as some sort of termination type of thing but the signals on the data lines are not really that bad anyway.

[exxos]

Saying that.. :roll:

The "hi" seems to only be 1.6V overall.

IMG_0584.JPG

I'll shove a pullup on it see what happens.


EDIT:

Difficult to really tell at this point if the bus is actually been used or not while I'm capturing :roll:

IMG_0585.JPG

EDIT2:

Seems ok during a transfer. This was without a pullup on a data pin.

IMG_0586.JPG

Is a lot more stable and a lot less noise with the pull-up though.

IMG_0588.JPG

[exxos]

I swapped out the booster for a completely different one because the original is getting rather mangled.

This will ironically seems to be working at 8MHz. Whereas the previous booster did not. Likely just a fluke more than anything though.

I did small experiments with the 8MHz clock again. Adding 33pF onto it causes the blitter to malfunction in diagnostic tests. I remember having all sorts of troubles with the clock during booster development :roll:

Indeed I posted some clock problems in my blog a couple days ago we seem to be aggravating problems as well.

[exxos]

Another thing I forgot to mention as well.. WRITES during 32MHz mode seem to work better with the PI running 220MHz. It seems to complete successfully that way. The default speed is 150MHz.

However READS do not work at all. I have to swap to 120MHz for reliable autobooting and reads.

I don't really see why speeding up the PI has anything to do with anything. It does marginally speed up the DRQ / ACK timing.

A couple days back I did wonder if the timing was relating to the 8MHz clock somehow. Like if there was any relation between DRQ and the 8MHz clock high and low.

[exxos]

While experimenting with delays here and there..

This is BGACK (BLUE) and RW (YELLOW)
where the rise time on RW is very slow. Using RW in my code to keep 8MHz for longer tends to work.

IMG_0590.JPG

However if I extend BGACK to a similar time, the hard drive malfunctions again.

IMG_0591.JPG

So I don't think it is some weird issue relating to the CPU grabbing the bus to fast after a DMA cycle completes.

I already added a pull-up on RW, but I forget the results but I will retest again and post here for future reference.

IMG_0593.JPG

EDIT:
So with the 1K on RW (works out about 550R!) it copied my test files fine on first try.. will do some more copies...

EDIT2:
Copied a load of files from the floppy and hard drive and loaded all fine. When doing the sector test it failed rather quickly. :roll: But I will add in RW into my code again see if it gets past it..

EDIT3:
Its passed my sector test program on first pass this time.

I think with the CPU running at 32MHz even with 1K on RW, it still takes 100ns to get to even 3V. With the booster cycles running at 32ns per cycle, then the CPU might be trying to do a read while the RW line is still actually "low" causing it to go nuts.

[ijor]

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.

That's very strange and it shouldn't happen when you have a strong pullup. I'm not familiar with this disk emulator. Is this signal buffered or driven directly by the microcontroller? Conceivable, if not buffered, it might not have enough driving power for stronger pullups.

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 ?

I would need to double check the exact bus timing. The timing of the control signals is simple, but I would need to check the internal MMU and DMA logic for the timing of the data bus itself.

I know that you don't like trace analyzers too much, but tracing the relevant signals during the whole dma sequence might be helpful here.

[ijor]

I would need to double check the exact bus timing. The timing of the control signals is simple, but I would need to check the internal MMU and DMA logic for the timing of the data bus itself.

Replying to myself, I realized that what matters here is the timing of the 74LS latches ... So by the time BGACK is released the data bus should have been floating (and pulled up) for almost a whole cycle already.

[exxos]

@ijor the signals are all buffered.

Yeah I gave up with LAs as the software was always crashing and the hardware died to easily. Maybe a more expensive one be better but they cost a fortune :( I'm not sure they be accurate enough for such things either.

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.

So I think the timing of ultrasatan is slightly more consistent in that it seems to mostly issue DRQ around the falling edge of the 8mhz clock.

The pi drive is a lot more random on where it hits the 8mhz cycle.

I think when DRQ is loaded with X1 probe it shifts it from the clock edge more and causes more issues.

Similar when I use 220mhz pi clock it tends to work better and the timing of DRQ looks more like ultrasatan.

Timing of DRQ shouldn't matter of course. But whatever is going on inside the GST is causing a timing difference on the RW signal . Something is borderline somewhere.

For example, if DRQ arrives in the middle of the 8mhz cycle on a high or low, it seems to cause RW going high to be delayed enough to upset the booster, as it's synced to the 8mhz clock.

If DRQ arrives near the falling 8mhz clock edge, then the RW rise (I assume) is slightly quicker and doesn't upset the booster. This is why I think ultrasatan works as it's always near a clock falling edge, the pi drive is a lot more random.

From RW to BGACK , it looks like RW goes high exactly when BGACK goes high. That makes sense. Adding a pullup on RW speeds up the rise of RWna lot, but it doesn't solve the problems.

However, if I have a clause in my code to keep in 8mhz during a low on RW, then the booster runs a fraction slower, but the hard drive then works fine.

I tried keeping in 8mhz longer after BGACK goes high, I kept BGACK to the CPU low for about 60ns more, but the drive still failed.

At this point I get confused :(

I can only assume for whatever reason, the hard drive with DRQ timings, causes the RW signal to skew or have a longer rise time at some point after a dma cycle.

Note that the booster itself can run all day without issues. The issues only show up on a hard drive DMA cycles. But like I said earlier, speeding up RW high clearly shows a huge improvement in the rise time, but it has zero effect on the booster speed or reliability of the hard drive.

And yet if I use RW to delay 32mhz mode, it all works fine. As the booster shows a slight slowdown, it has to be seeing RW low , when nothing is accessing the bus even ( AS high).

Only thing I can do is try a even lower RW pullup value, the only idea which makes sense is RW is slower to go high after a dma cycle than anyother bus cycle. And it's linked to the timing of the DRQ signal somehow. Which doesn't make sense :lol:


EDIT:
Also just 6ns delay on the 8mhz clock ,even when the CPU is running at 8mhz only, can also cause the same problems. So it's not exactly limited to the booster either. Some CPUs behave that way, others don't. Some don't work then work later on. It seems to be down to borderline timings and tollerences again :roll: plus the 001 "good DMA" agrivates what ever the problem is and works a lot worse than the -38 "bad DMA".