exxos's Atari, Amiga & retro forum

It's only bloody Bad Mood working!


So here's what I think happened. I was routeing the CPU Clock through various external pins and passing it back in to add a bit of delay. That was actually bypassing the TIMESPEC commands I had in place. Which gave me a hint. I dropped all the timespec commands and applied blanket 'slow' transition speed. That's when we got the partial support working. Small LODs would work, but larger or frequently changing data ones would fail (like FRAC_DSP).

So I switched from Density optimisation to Speed. Now all the tests I've given it have worked. But that may be a step too far. I struggle to fit the SDRAM controller in with 'speed' optimisation set. Also the 'slow' edge transition may not like the higher speed operation required on the AltRAM side.

All this is with SDRAM disabled, you see. I decided to target the basics before turning my attention back to that hideous beast.

Anyway, softer edges but tighter times are the key. Why? No idea. Still don't think it *ought* to matter.

So progress at last, but it's not over yet. :)

BW

Badwolf wrote: 07 Nov 2021 22:56 So here's what I think happened. I was routeing the CPU Clock through various external pins and passing it back in to add a bit of delay.

Does that actually work though ? or wouldn't the compiler just optimise them out to a internal route ?

Badwolf wrote: 07 Nov 2021 22:56 So progress at last, but it's not over yet. :)

:bravo:

exxos wrote: 07 Nov 2021 23:07

Badwolf wrote: 07 Nov 2021 22:56 So here's what I think happened. I was routeing the CPU Clock through various external pins and passing it back in to add a bit of delay.

Does that actually work though ? or wouldn't the compiler just optimise them out to a internal route ?

I can't say it actually worked *well* -- the added delay was less than I was hoping for -- but it must work in theory. How would the compiler know that they were related externally?

I must admit to being perturbed by this speed optimisation dependency. Now I'm wondering which line that applies to and why. I know it'll come and bite me in the bum when I get back to SDRAM, so I'd rather not rely on that optimisation if I can figure out the real issue and account for it separately.

BW

Are you sure it's just simply not just noise on the clocks ?

exxos wrote: 08 Nov 2021 10:21 Are you sure it's just simply not just noise on the clocks ?

I've one clock in (XCPUCLK from the motherboard) and [at the moment] one clock out to the CPU. I've tried various in-line termination values on the output clock and I've even actually just wired the output pin directly to the input pin (output driven high-z, obviously). None of that made any difference.

So the only place I could think clock noise could be an issue would be on the input side? The XCPUCLK to CPLD line? Well I can scope it, I suppose.

What do you think the mechanism is that means speed optimisation works around this proposed noise? Genuine question so I know what to think about: I'm not an electronics engineer. :-)

BW

Badwolf wrote: 08 Nov 2021 11:15 So the only place I could think clock noise could be an issue would be on the input side? The XCPUCLK to CPLD line? Well I can scope it, I suppose.

What do you think the mechanism is that means speed optimisation works around this proposed noise? Genuine question so I know what to think about: I'm not an electronics engineer. :-)

Best to scope on x10 and really look at any glitches when trying to access the DSP.

Speed optimisations, this really depends what the compiler is doing. If things are that sensitive, then you probably have a timing problem in your code somewhere I would assume.

But also note and you sample system clock, you are inherently adding some delays anyway. So inverting the clock can sometimes be a quick workaround.

exxos wrote: 08 Nov 2021 11:20 But also note and you sample system clock, you are inherently adding some delays anyway. So inverting the clock can sometimes be a quick workaround.

Even when hard-wiring the mobo clock to the chip clock I couldn't find any delay/inversion offset that worked.

The only lines I can think that might be crucial are AS, UDS, LDS and the return DSACK0. I don't think anything else runs through the CPLD when accessing the DSP.

BW

Ah, balls.


I knew relying on that 'speed' option wouldn't last. Literally the first feature I re-enabled. Bah.

BW

Looks like I've managed to coax it back into working again. Phew! I've even got it switching at 40MHz.

But this is going to be the problem:
Specifically Function Block 5 has 52 of 54 inputs used. FB5 is the one that handles most of the motherboard interaction.

The big question left is will I be able to come up with an SDRAM controller that 1) works and 2) doesn't affect FB5!

FWIW, my FPU partially works. It fails the FPUTest process and won't run Quake, but it will run FPU-enabled Doom and draws fractals happily in FRAC.PRG. I suspect there's something not contacting properly in the crappy socket I've got fitted and some of the instructions are working. Or I've got a bad solder joint. Or I've wired up the bottom 16 lines wrong or something. The chip passes in the Falcon's mobo itself, after a reseat or two.

Anyway, I don't think that's down to my CPLD logic (at least I hope it's not), so I might leave it as it is and start thinking about SDRAM again.

Oh crud. :?

BW

I feel your pain there :( flashy clock ran out of space for more features I wanted to add, and I am already using the largest PLD in that series :(