exxos blog - random goings on

[exxos]

Been playing around with the booster timings and this is a overlay of the clock and ROM_CS.

The scores overall were all about 20% slower, all I had was a extra 32MHz clock delay on AS. (keeping it in 8MHz a fraction longer)

But what is interesting is ROM_CS and the CPU is still at 32MHz but the overall system performance has suffered. Pretty bizarre why that would happen

The actual ROM test in GB6 dropped to about 266% from 309% ordinarily.

IMG_0631.JPG (78.24 KiB) Viewed 1171 times

[exxos]

Bloody chair snapped again! Not my welds to blame this time but the piston itself it seems!

Why does everything have to be absolute complete garbage these days

IMG_0643.JPG (196.95 KiB) Viewed 1136 times

I'm getting too old for these constant heart attacks

Don't buy from here then I guess
https://www.ebay.co.uk/itm/323014138309

[exxos]

I've been looking into the DMA issues with the v1 STE booster and the pico harddrive in this thread viewtopic.php?f=13&t=5913

Now the drive problems are fixed. I will move the investigation here to my blog in order not to clutter the other thread up.

In summery. There is multiple odd things going on with the booster and STE. But the problem only shows up during DMA cycles. I have tried a million things but the problem remains unsolved.

What I have found out,is when using the booster as basically a CPU relocator, no pull-ups or clock buffering and original CPU,the STE fails to boot at all. The only fix was placing 68R in the clock line.

More problematic is it appears even a slight delay of 6ns is enough to start causing DMA issues. Once the CPU gives up control of the bus, the CPU does nothing. It's not a problem with any busgrant signals. I've even delayed them all to no avail.

There does seems to be some thermal aspect relating to the GAL as I can copy sometimes thousands of files and then it will just die. Freezer spray on the gal seems to help. But it still fails at 8mhz speeds.

I've tried 33pf on the 8mhz clock and the STE fails to even get to the desktop half the time. It only clamps the ringing on the clock. It's voltage doesn't suffer all that much.But it shouldn't be so sensetive like that in the first place.

I've still to try some extra pull-ups on some signals yet. But I'm thinking the GST simply can't drive the clock properly. Or something DMA related is extremely sensetive to the CPU having a slight clock skew.

My only thoughts are to buffer the 8mhz clock from the GST.Which would be tricky. Or try and resync the clock on the CPU after it's been buffered. Maybe generate my own 8mhz clock from the 16mhz one. I should be a few NS quicker than the GST , so by the time it's buffered, it might all be back in sync again.

While all this seems to be the classic DMA type of problem, it has little to do with the DMA version. In fact the so called "good DMA" actually makes the problems worse. So whatever this dma problem is , it's a new one it seems and doesn't seem to have any particular cause. Which makes finding a solution rather problematic.

[exxos]

A random thought. I wonder if BR to the CPU doesn't get requested in time and something screws up .

One common thing between 8mhz and 32mhz is that I slow down on busgrant stuff. I have tried all sorts before but that was with older Pico firmware. So while slowing the CPU during bus master cycles makes sense, in not running the CPU at 32mhz. Maybe I should run the CPU faster during bus grant cycles to counteract the slow down of the CPU reacting to BR on a delayed clock.

Simple to try I guess when I get back home tomorrow..

[exxos]

Trying a new random idea. It seemed to copy these files once fine, now waiting for them to all copy again. Normally it will start corrupting odd files and the filecopy will fail eventually. But its done this so far without failing.. Probably work fine tonight and fail first thing when I try it in the morning.. Normally how these things go

IMG_0644.JPG (49.86 KiB) Viewed 1037 times

[exxos]

The chair repair isn't go well. Can't ge the bloody old piston out even though I put copper slip grease on the thing last time. Hitting the bottom with the hammer is just bending the metal

IMG_0649.JPG (268.86 KiB) Viewed 999 times

IMG_0648.JPG (229.69 KiB) Viewed 999 times

Where it snapped is no wonder. The metal is so bloody thin!

IMG_0652.JPG (199.1 KiB) Viewed 999 times

IMG_0651.JPG (211.99 KiB) Viewed 999 times

IMG_0650.JPG (217.99 KiB) Viewed 999 times

[HigashiJun]

A real crap...

I had a lot of cheap chairs like yours and they all broke after 5~6 months...

[Badwolf]

A random thought. I wonder if BR to the CPU doesn't get requested in time and something screws up .

You should be able to safely delay BR by just under 1 microsecond without any ill effect.

During DMA cycle the CPU is dormant so the problem is unlikely to be *within* the bus cycle itself so the problem (if it really is CPU-related) is likely going to be at the beginning or the end of the bus relinquishing process.

Assertion of BGACK alone is* enough to turn off the CPU during bus master transfer. The cpu will pick back up when BGACK is released.

I know you've experimented with delaying BGACK on release (so your processor doesn't pick up too soon). That shouldn't really be needed at 8MHz, but at 32, it may be.

So you could have a look at the start. Is BGACK getting any undue delay coming through from the mobo? You *could* try asserting CPU BGACK on CPU BG + MOBO BGACK. Ie. early.

BW



* This is true of the 030, with which I am most familiar. I admit to not checking this explicitly for the 68k.

[exxos]

You should be able to safely delay BR by just under 1 microsecond without any ill effect.
....
* This is true of the 030, with which I am most familiar. I admit to not checking this explicitly for the 68k.

*should* yes. But something screws up with the CPU with the delay which can only be busgrant related as the CPU doesn't do much else. What I have done now is enter 32MHz on BGACK and its filled my 200MB partition up twice without tripping up once. Though I think BGACK is more complicated than one tends to think.

I guess BR comes to late, ends up tripping over to the next clock cycle, then everything is late after that. I suppose BGACK could still be low (for to long) and then it trips up and sees BR again for the next bus cycle, but the CPU may still see BGACK from the previous cycle. Its only a guess. But hard to say without a deeper LA readings of it all, which I don't really have time to do.

br2.PNG (55.65 KiB) Viewed 985 times

br1.PNG (52.71 KiB) Viewed 985 times

[exxos]

Getting the piston end from out the chair base was a pain. I had to hook it from the bottom with a M10 bar and get a washer and they not on the end which was also a pain. Benny gave me leveraged to pull it out.

Anyway all back together again. Chair seems higher than it was before even though I ordered a slightly smaller height piston from before

IMG_0653.JPG (256.33 KiB) Viewed 1013 times

IMG_0654.JPG (266.24 KiB) Viewed 1013 times

IMG_0655.JPG (274.22 KiB) Viewed 1013 times