Building an STe536

[exxos]

Oh, you do your own bus arb?

Other than what I already mentioned not really no..

Anyway, I meant what I was demo'ing in that video. There's evidence the problem isn't coming *out* of bus relinquishment as stacking delays on the end of a cycle don't have any effect, whereas putting the brakes on the second BR asserts (could be mid-cycle) does improve things.

What I found a few months ago with my new STE booster tests, was that speeding up (I think) BGACK, so the CPU switches to 32MHz helped. It seemed to be more at the end of the cycle where the problem occurs. I think the CPU has a lot of "internal messing about" at the end of of BG cycle, which may or not be related.

I did document this on the forum *somewhere* as well. But ultimately while that trick did help, I found it not be ultimately reliable..

To me that says the mystery lies at the *start* of the bus arb cycle. But got knows what it could be.

Yes been through all this for years :lol: :pullhair: :stars: :crazy:

I suggest you get it stable on the STFM first really as things are easier timing wise. The STE is "next level chaos".

Problem with the STE is it doesn't like the 8MHz being out of sync either as you can trigger DMA issues yet again.. That is what I fixed on my STE booster recently.. The 2.2K bus pullups and HC CPU help as it changes the DMA timings by up to about 22ns, so you can "afford" to have a 8MHz clock delay in theory up to that amount.

However, while the pullups and HC CPU there to solve DMA issues.. And when you have a PLD/GAL etc, you can add delays by like 10ns.. then 3ns for the schmitt trigger.. another 3ns to smooth the CPU clock.. You basically end up at square one again...

Again this is why I developed this new board.. viewtopic.php?p=116390#p116390 to counteract the delays of the buffers and GAL. On the flipside, if you removed the 2.2K bus pullups, you "lose" about 10ns and your screwed again.

@terriblefire's clock switching code is a verilog genius really in solving the clock sync issues. While I don't fully follow what he did, I think the gist is basically running the 8MHz clock via a shift register clocked with the 100mhz clock. This way, you can advance or retard the internal CPU clock timing based on what point you pick off the shift registers outputs. So the more delays you have on the 8MHz clock logic, you just tap off a earlier shift register output and the CPU 8MHz ends up in perfect sync with the system 8Mhz (or damned close!) .

[Badwolf]

What I found a few months ago with my new STE booster tests, was that speeding up (I think) BGACK, so the CPU switches to 32MHz helped. It seemed to be more at the end of the cycle where the problem occurs. I think the CPU has a lot of "internal messing about" at the end of of BG cycle, which may or not be related.

Do you mean pulling BGK high harder? It's is asserted by the secondary bus master, so I don't think you can speed up disassetion per se.

But to me that's really confusing as if I *never* shift up, there aren't any problems. But if i shift up 8 bus cycles (at least 4000ns) later, it doesn't help.

Perhaps all that just means to show these aren't the same issue, although they look like it.

I suggest you get it stable on the STFM first really as things are easier timing wise. The STE is "next level chaos".

I've stopped trusting my STFM as I think it has other issues. I've never had a speaker hooked up to it so only found out the other day that the YM chip is knackered, for example. The STE has your nice schmitt trigger too. ;)

Problem with the STE is it doesn't like the 8MHz being out of sync either as you can trigger DMA issues yet again.. That is what I fixed on my STE booster recently.. The 2.2K bus pullups and HC CPU help as it changes the DMA timings by up to about 22ns, so you can "afford" to have a 8MHz clock delay in theory up to that amount.

Hmmm. Well yes, there will certainly be quite some delay on my clock. But if it's delayed at 8MHz it doesn't seem to be a problem...

@terriblefire's clock switching code is a verilog genius

That's an idea -- I couldn't use that approach on DFB1 as the Falcon has 8 and 16MHz modes, but the ST/E doesn't. It would allow a completely instant clock switch too (mine can take a couple of [the slow] cycles to complete).

Anyway, I thought my issue was close enough to be relevant to Steve's, but I may be barking up the wrong tree.

BW

[exxos]

Do you mean pulling BGK high harder? It's is asserted by the secondary bus master, so I don't think you can speed up disassetion per se.

I mean switching to 32MHz at the end of the BG cycle, but I don't recall off hand it that was on BG or BGACK. But that only helped maybe 50% anyway.

BTW - You also need to check P100 is 1.2K on the STE.. Those are the BG pullups etc

But if i shift up 8 bus cycles (at least 4000ns) later, it doesn't help.

It won't help. Been through all that before. You'll still out of clock sync regardless how many cycles you shift along.

Anyway, I thought my issue was close enough to be relevant to Steve's, but I may be barking up the wrong tree.

There are multiple "angles" to DMA issues. Be it changing the CPU, pullups, DMA chip, then mix on top PLD delays etc. Your problem may well be something entirely different, I can only really say what I witnessed myself over the years. Maybe you discovered some new DMA problem.. I really would not be surprised the way bugs pop up on these machines year after year..

I don't know what problem @Steve has currently, but his machine is "significantly different" to what my machine is despite him using the same style motherboard. If he cannot get anywhere, he will have to send me the booster and his motherboard and I will try swapping things around, like trying his booster on my motherboard etc. Then compare the motherboards to see whats up. It could may well be a 8MHz clock loading issue for example. I don't have any other working STE motherboards to try it on. Its why I sent one to steve to build and try out. I need to change stuff like reset switches and simm sockets on pretty much all the STE boards I have here.. just not enough hours in the day... Ultimately if we cannot get his working and stable, then I may just have to shelve the STE536 until I have more time to test on more machines.

[Badwolf]

But if i shift up 8 bus cycles (at least 4000ns) later, it doesn't help.

It won't help. Been through all that before. You'll still out of clock sync regardless how many cycles you shift along.

But exactly the same amount out of sync as I am if I always run at 8MHz. Which works. So I'm not convinced by the sync argument.

But perhaps I'll get a probe on it later on and try the patented Stephen Leary 'shift sampling' technique.

BW

[exxos]

But exactly the same amount out of sync as I am if I always run at 8MHz. Which works. So I'm not convinced by the sync argument.

But perhaps I'll get a probe on it later on and try the patented Stephen Leary 'shift sampling' technique.

But if your going with TF's clock switching code, that does the sync properly, if you don't believe sync in the issue, then there's no point in trying TF's code...

[Badwolf]

But if your going with TF's clock switching code, that does the sync properly, if you don't believe sync in the issue, then there's no point in trying TF's code...

No harm in trying it. But you're right: don't think it's clock skew.

BW

[Badwolf]

Not to hijack this further, I've moved over here:- viewtopic.php?f=112&t=7149

[terriblefire]

@terriblefire's clock switching code is a verilog genius really in solving the clock sync issues. While I don't fully follow what he did, I think the gist is basically running the 8MHz clock via a shift register clocked with the 100mhz clock. This way, you can advance or retard the internal CPU clock timing based on what point you pick off the shift registers outputs. So the more delays you have on the 8MHz clock logic, you just tap off a earlier shift register output and the CPU 8MHz ends up in perfect sync with the system 8Mhz (or damned close!) .

i was very very drunk.

[exxos]

Fixed up @Steve's STe536. Will document what I found later.

[Steve]

Thank you!