Raspberry PI PICO ATARI ST Hard Drive Emulator (WIP)

[exxos]

I stripped the booster right back until it is literally just a "nothing adapter" I broke the 8MHz trace to the CPU and hardwired it direct to the motherboard's 8Mhz clock ( the white wire on the left).

IMG_0633.JPG

Now the machine does not even boot up. It was literally seconds before when it was going by the GAL.

So literally just the PCB is stopping the machine from behaving correctly. I even took off the bus pullups just to make doubly sure. But these type of crazy problems why I added the resistor packs in the first place. :roll:

Previously I have noted a lot of strange issues relating to the 8Mhz clock on the STE which resulted in a lot of weird mods to be done in previous generations of he booster relating to the clock. But now I think the problem is much deeper somehow now.

But I think realistically this is getting into a much time-consuming project trying to diagnose why the loading on the 8MHz clock or even a adapter PCB is enough to screw things up. Something I don't really have the time or patience for at the moment.

So unless anyone has any simple ideas to try out ... I even tried reinforcing the grounding on the booster, adding various pullups and caps on various pins to no avail. But I did not try every pin is mostly around-the-clock and bus grant, DTACK/AS etc. I will go around all the CPU pins with the scope on X1 To see if there is any way of getting the machine to actually boot up. If that does not yield any clues then it is practically going to be impossible to diagnose. I think the chipset just simply sucks.

I am just going to conclude that there isn't a problem with the Pico drive. As to why it misbehaves with the booster and ultrasatan doesn't is pretty bizarre. Though knowing how timing sensitive the STE is now, I think it is just a monumental fluke that ultrasatan works and the pico drive doesn't.

EDIT:
So the scope probe on X1 on the clock cause it to boot up. So again that feking 8MHz clock! Also running the clock via 68R results in a boot up again. I think the clock simply has that many things it is driving that even a stock machine is at " tipping point" for it not to work.

[Badwolf]

EDIT:
So the scope probe on X1 on the clock cause it to boot up. So again that feking 8MHz clock! Also running the clock via 68R results in a boot up again. I think the clock simply has that many things it is driving that even a stock machine is at " tipping point" for it not to work.

Perhaps the next mandatory fix is a bloody great booster at the clock source, Falcon clock patch stylee.

I presume it comes out of the combined glue chip, though?

BW

[exxos]

Perhaps the next mandatory fix is a bloody great booster at the clock source, Falcon clock patch stylee.

I presume it comes out of the combined glue chip, though?

Yeah it comes out of the GST towards the top left :roll:

I think this is the problem when designers don't put proper termination to the clocks to all the chips :roll:

Back in my blog a few posts back I documented that 100R seem to solve the problems going to the DMA clock. later the problem was back again I think.

I'm not sure how easy it would be to buffer the 8MHz clock at source. It would certainly take the "feedback" away from the GST.. but we still have a mash up of "noise" all been combined across various chips across the motherboard anyway.

If there was somewhere around the CPU I could break it and use the buffer clock, it might be enough.. I mean we have the DMA,MFP,YM,1772, all feeding back on the clock "above" the cpu.. so offloading that chaos to a buffer might be enough.

Feking Atari never got the hang of clock traces it seems :lol: :roll:

[exxos]

@Steve's ACSI2SD arrived. Verified ultrasatan was working beforehand. Tried the new drive and it copied my test files without any problems.

IMG_0635.JPG

[Steve]

Am I right in thinking that if two modern external drives work OK, then it is more likely to be something Pico drive related? That's if logic has anything to do with this scenario :?

[exxos]

Am I right in thinking that if two modern external drives work OK, then it is more likely to be something Pico drive related? That's if logic has anything to do with this scenario :?

I think there is a lot of problems going on all at once.

I just got new firmware for the drive and seems a lot better.

However booster wise, ultrasatan has stopped working with my updated firmware for the GAL.

I'm currently trying to diagnose what the hell is going on.

[stephen_usher]

Am I right in thinking that if two modern external drives work OK, then it is more likely to be something Pico drive related? That's if logic has anything to do with this scenario :?

That's what I was thinking. It's obviously not quite meeting the standard ACSI timings or missing commands etc.

[exxos]

Now it seems ultrasatan is not working reliably :roll: I think because it is getting very hot in my room (26c currently) things are tending to break easier where it before they worked fine.

I did have issues with ultrasatan when I first did the boosters works, but found a solution which worked, but maybe that solution was not really a solution in the end, and the problem is actually with ultrasatan :roll:

However the Pico drive seems be working a lot more reliably now with the updated pico firmware. still not perfect. But I think it is more reliable than ultrasatan now.

It is overall difficult to form any sort of conclusion because it seems like every time I turn off the STE, the fault seems to change.

[stephen_usher]

Well, I think the UltraSATAN flies very close to the edge of working, which is why it's so fast. It probably breaks the (conservative) timings that Atari gave for the ACSI interface.

[exxos]

Well, I think the UltraSATAN flies very close to the edge of working, which is why it's so fast. It probably breaks the (conservative) timings that Atari gave for the ACSI interface.

Yeah so far it seems to be failing more than the other two.

I wonder with the booster running faster, if it does somehow break the ACSI timing even know the CPU doesn't directly have anything to do with DMA transfers.