exxos's Atari, Amiga & retro forum

Hi all.

I've resurrected my 'cut down' second board in my current Falcon booster iteration. This one has a new ground-up firmware and I've managed to fit everything into a 144 macrocell CPLD. Which I'm really pleased with.

Everything works well and stably with one exception: DSP access again.

DSP was the last thing I got working on my first version of the board and I discovered some different timing constraints on it by inspecting the GAL equations and the DSP is the only thing on the board with an 8 bit bus. Once I made allowance for those, everything worked. This board: no such luck.

I'm hitting my head on a wall, here. I'm tempted to just say DSP is not supported on this board and call it a day, but can anyone see anything wrong from the below traces? I've also put the analyser on the various pins of U44 and, to me, they look in order.

Symptoms are that TOS4 nor EmuTOS can boot as they sit in an endless loop waiting for a status change. It seems to read from the DSP correctly. A longword read from FFA200 (first trace) returns 00 12 06 0f, after boot. But this *never changes*.


The second trace shows a longword write to FFA204. As I understand it a write to FFA207 should trigger a change in FFA202, but that doesn't happen.


@mikro was very kind and provided me with a test program (atari.tos) when I was debugging the first board that would produce output even if the OS didn't support the DSP -- this too just sits in an endless loop with the cursor flashing.

Can anyone see anything obvious in these, or suggest something else I should check?

Thanks,

BW.

PS. CAPITALS are Falcon-side lines. lower case is external 030-side lines. RW is shared. dsp_access is for identification. The clock line is only really valid during the dsp_access phase.

Doesn't the DSP run off its own clock ? Can't remember offhand. Just thinking you may be syncing your CPU clock to the 16mhz bus.. But then you got a whole mixed bag of timing issues if the DSP is running on its own clock. I guess you could cheat and link your CPU clock to the DSP at least to rule out related issues.

exxos wrote: 28 Jul 2021 23:44 Doesn't the DSP run off its own clock ? Can't remember offhand. Just thinking you may be syncing your CPU clock to the 16mhz bus.. But then you got a whole mixed bag of timing issues if the DSP is running on its own clock.

Yeah the DSP has its own free-running 32MHz oscillator. It goes literally no-where else, so the on-board CPU can't be sync'd with it either. Doubt it's that.

My thinking is it might more likely be to do with the GALs (which do have a XCPUCLK dependency) and not quite being in sync with them, but last time I checked I was within 5ns of the board clock -- which I thought was pretty good.

Because I'm a fun and exciting kind of guy, I spent my lunch reading the 56001 data sheet. I haven't come across any clock dependency at all on the host interface, but there is a fair amount on timings of the various host lines (HRW, HEN, HADD, etc). I'm going to dig the scope out this evening.

BW