Raspberry PI PICO ATARI ST Hard Drive Emulator (WIP)

[exxos]

I am back to using the original GAL firmware. Writes are corrupted in both 8 MHz and 32 MHz

Madness.

There is no difference in the beta firmware other than a clause to keep 8MHz low longer if it sees a write. But when forcing 8MHz mode, it makes no odds in firmware revision.

So can you confirm 8MHz and 32MHz works with my BETA GAL firmware ?

[dad664npc]

beta firmware is the same - both speeds exhibit write corruption. Remove the accelerator and all is good

[exxos]

beta firmware is the same - both speeds exhibit write corruption. Remove the accelerator and all is good

Thought you said was working the other day ? are you using your original drive firmware still ?

I guess I will have to dig out a external blitter motherboard, the same revision as you give that a try as well...

[dad664npc]

HDC firmware hasn't changed that much - I've added a dump command and changed debug prints here and there - I'll send you it

The accelerator firmware works when cold but soon fails.

[exxos]

The accelerator firmware works when cold but soon fails.

:dizzy:

So back to there is basically no point of releasing the new booster firmware because that clearly is not the problem.

I don't get it. I think is beyond my area of expertise to debug all this stuff :(

[exxos]

It seems @dad664npc setup works without the GAL and fails with, even though the GALs internal logic is just CPUCLK=CLK8; on a test firmware.


Measuring the delays across the first buffer on the booster. 6ns.

IMG_0622.JPG

The round-trip delay across both buffers and the GAL is about 13ns.

IMG_0623.JPG

So the GAL delay is only 1-2ns even though the GAL is stamped 15ns in this particular test.

So basically if the CPU clock is skewed by more than 10ns, the DMA starts to go nuts. :shrug:


So the solution is to remove one of the buffers right ? well not that simple because... https://exxosforum.co.uk/forum/viewtopi ... 514#p41514 I had various issues between motherboard revisions and solved this problem by adding the buffer :roll:

[Badwolf]

So you've got a CPU addon board (I shan't say accelerator, as it's running in 8MHz mode) which is showing data corruption issues with one hard disc emulator, but not another and the degree of those issues seems somehow linked to the system clock.

But there are at least two chips between anything the CPU does and the hard disc emulator and furthermore the hard disc emulator's data is transferred DMA, with the CPU high impedance, rendering the clock/CPU skew irrelevant at that point.

From what I can see the only overlap between the CPU and the data transfer at that point is access to the DMA chip's registers, the allocation of buffers in memory, the relinquishing of the system bus and the reaquisition of it again later.

So where could the clock dependency come in?

Well you've experimented with reaquisition of the bus quite extensively. We've already discussed how the relinquishing shouldn't really have a nanosecond timing sensitivity (as it's allowed up to a microsecond to hand things over, IIRC). Buffer allocation issues would be a fair old way down a chain of failing things if general memory access were being affected by clock skew.

So I think the only real place left to look is the DMA controller. What are its timings in relation to the system clock? Does it latch its registers on an edge that is now marginal as the CPU is driving the bus a fraction later?

Well that's possible, but then why the HD emulator dependency difference? There are buffers between the DMA port and all lines other than the interrupt, as I udnerstand things. Certainly nothing directly connected to the DMA chip to alter its timings by placing it under load or something like that.

So what are we missing?

BW

[exxos]

So what are we missing?

I have no idea.

I even connected the DMA clock to the buffered clock on the booster and made no odds. So 6ns delay on DMA did nothing.

I bypassed the first buffer on the booster and now the booster is chronically unstable.. This is why I added the buffer in the first place.. I'm just going around in circles.

I did mention earlier they thought that maybe it is tripping up because of RAM access. if the CPU is delayed by like 15ns then maybe it "misses" its time slot and with DMA in the mix...

But again why would this problem not show up with ultrasatan or another drive.

Assuming what is printed on the GAL is true. I have a 7ns GAL and @dad664npc has a 10ns one. But with my GAL only showing like 2ns delay.. it seems even just 1ns timing skew potentially be enough to upset things.

I'm thinking is just time to throw in the towel with all this because I've been at this for three weeks solid now in getting nowhere. Indeed I have learned a lot about different things but obviously something is incredibly sulky on the STE with the delayed clock was just is not going to be easily solvable.

I think the bottom line solution is I will just put that the booster may not be compatible with all DMA devices. I think the hard drive and the booster will work perfectly fine individually, but they just are not happy working together for whatever reason.

[exxos]

I think there are currently two problems going on.

Firstly the 8MHz clock delay which I have saved 6ns by removing one of the buffers.

However my GAL is 7ns and @dad664npc is 10ns.

Turns out the 10ns GAL causes a clock glitch :roll: Using this gal it is unstable in 32MHz mode.

IMG_0627.JPG

EDIT:

So I have had to do two versions of the GAL code, 7ns version and 10ns version.

But I have also realised there is a third problem where after a BGACK cycle I have to keep the CPU in 8MHz for a few cycles, else the floppy starts going nuts saying " your output devices not receiving data".

Current tests are using ultrasatan and the internal blitter STE currently...

I also feel like I have hijack this thread :roll:

:threadjacked:

[exxos]

Still no luck. :( I removed one of the clock buffers to shift the timing by 6ns and tweaked the code a million times. Tried a 7ns and 10ns GAL and more code changes. Nothing works.

Ultrasatan still works fine . I tested all the combinations with that as well. It did start failing to be recognised the past hour. Might be a bad connection but added the RW term in and it seems happy again either way.

@Steve has sent me a ASCI2SD drive to play about with. Hopefully it will come soon. Then can see if that has issues with the booster or not.