DFB1r4 design discussion thread

General discussions or ideas about hardware.
User avatar
Badwolf
Posts: 2231
Joined: Tue Nov 19, 2019 12:09 pm

Re: DFB1r4 design discussion thread

Post by Badwolf »

exxos wrote: Tue Nov 23, 2021 10:50 pm Not sure why it's at 3.3V unless you're driving it high from the PLD ? It should never be driven high anyway. Only 0V and Z. So something doesn't sound right there as it should be 0V and 5V (or nearas) even when being driven from those PLDs ?
Ah, I do drive high to get a clean edge. I then keep it high all the time I'm bus master (as why not?), but I could try switching it to open drain configuration.

I did implement drive high-for-one-cycle-then-go-high-z last night, but that didn't have any effect.

I was under the impression the processor itself drove the bus cycle lines all the time unless it had relinquished mastery -- certainly none of my designs so far have ever had a pull up on the external 030's AS line.

BW
DFB1 Open source 50MHz 030 and TT-RAM accelerator for the Falcon
DSTB1 Open source 16Mhz 68k and AltRAM accelerator for the ST
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark
User avatar
Badwolf
Posts: 2231
Joined: Tue Nov 19, 2019 12:09 pm

Re: DFB1r4 design discussion thread

Post by Badwolf »

Sometimes one things leads to another.

Christian dropped me a note to tell me a story from his past about signal integrity. This got me thinking about how few control lines are actually involved when I speak to the DSP. Really it's only AS, UDS, LDS (outbound), XDTACK and XCPUCLK (inbound).

Previous experience suggested the clock, and DTACK were fine, but I'd observed fiddling a bit of capacitance here and there on AS had caused things to go in and out of working.

So I started re-routeing some pins on the CPLD so I could add some inline termination to AS, UDS, LDS. I did AS first and... it worked.

It worked really well. Really stably. Even accelerated.

So I tried different termination settings. It all still worked. Even a straight wire worked. So it must be timing again... It occurred to me that by driving AS from the other side of the CPLD, there was an inherent delay from what I had before -- but I didn't see how that could affect things.

My UDS and LDS wires, however. They take their cue from the XAS line. But that was now an input! So OK, it's a delay on the UDS and LDS lines relative to the AS line that helps things.

But I experimented with this before. A (practically) zero delay didn't help. 10ns made things almost work. 20ns -- too much. But this was done with trying to trigger on a faster clock edge and it wasn't really reliable. I couldn't really see how UDS asserting a few nano seconds here or there would affect the GALS, which is to whom I speak, though.

Then it hit me. It's not the assertion (falling) edge. It's the rising edge! All my experiments with flip flops had varied the falling edge, but the rising edge was always shut off by AS going high. But delaying the deassertion of UDS and LDS must be the answer!

I thought back to when the DSP samples the data. At the rising edge of DSP_CS. That edge is driven almost entirely by AS. But UDS and LDS drive the A0 line! If AS deasserts, takes UDS and LDS with it. A0 will be undefined as DSP_CS goes high some nanoseconds later!

Aaarrgh! What a fool I've been all this weeks!

So I rigged up a quick flip flop that did my delay experiment in reverse. Assert UDS/LDS simultaneously, but only deassert LDS and UDS the clock edge after AS deasserts.

as_x_uds_full.png
as_x_uds_full.png (10.04 KiB) Viewed 2154 times

BadMood has now been running for an hour in 50MHz accelerated mode.

Thanks to Exxos, Christian and everyone else who's chipped in with ideas on this. I think (and hope) this is finally it and I can move on to the FPU.

I am an absolute idiot.

BW
DFB1 Open source 50MHz 030 and TT-RAM accelerator for the Falcon
DSTB1 Open source 16Mhz 68k and AltRAM accelerator for the ST
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark
User avatar
exxos
Site Admin
Site Admin
Posts: 23496
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: DFB1r4 design discussion thread

Post by exxos »

I am somewhat confused what's been done. If you have inline resistors which is what I was saying about the GAL etc to solve the ringing issue, why do you still have it on your scope image. The resistors are to prevent the ringing problem.

Secondly, inline resistors also slow down the signal the same as when you mentioned your scope caused it to go in and out of working. So we need to know exactly what caused it to start working.

Then you mention delaying UDS LDS, but is it that with or without the above taken into account ? What does the MB CPU do with the same signals ?
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
User avatar
Badwolf
Posts: 2231
Joined: Tue Nov 19, 2019 12:09 pm

Re: DFB1r4 design discussion thread

Post by Badwolf »

exxos wrote: Wed Nov 24, 2021 11:16 pm I am somewhat confused what's been done. If you have inline resistors which is what I was saying about the GAL etc to solve the ringing issue, why do you still have it on your scope image. The resistors are to prevent the ringing problem.

Secondly, inline resistors also slow down the signal the same as when you mentioned your scope caused it to go in and out of working. So we need to know exactly what caused it to start working.
Sorry if I wasn’t clear. No inline resistors now. Back to original configuration with one change to UDS/LDS timing: they now run on half a clock cycle beyond AS terminating.

Then you mention delaying UDS LDS, but is it that with or without the above taken into account ? What does the MB CPU do with the same signals ?
The MB doesn’t use LDS/UDS. It can assert A0 directly. This is all about making sure A0 is valid a smidge after AS’s rising edge.

Basically, when the expansion port is bus master, A0 = /UDS.

BW
DFB1 Open source 50MHz 030 and TT-RAM accelerator for the Falcon
DSTB1 Open source 16Mhz 68k and AltRAM accelerator for the ST
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark
User avatar
exxos
Site Admin
Site Admin
Posts: 23496
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: DFB1r4 design discussion thread

Post by exxos »

OK, so why doesn't the stock machine suffer the same fate ? Normally the CPU will will keep the address set until the cycle is terminated, in which case the only way I can see, if it's just down to the GAL being to slow to release DSP CS. As the cpu could terminate the cycle, but DSP CS could still be low.. On that basis, could you use faster GALs ?
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
User avatar
Badwolf
Posts: 2231
Joined: Tue Nov 19, 2019 12:09 pm

Re: DFB1r4 design discussion thread

Post by Badwolf »

exxos wrote: Thu Nov 25, 2021 12:12 am OK, so why doesn't the stock machine suffer the same fate ?
As I understand it, the address (and data) lines are still driven after AS and DS are negated until the next rising edge of the clock. That must be, on the stock system, enough time for the DSP to latch, else Atari could not have got away with their GAL implementation of DSP_CS.

So my system happily carries on asserting A1-23 and D16-31, but A0 is asserted by the GALs, which just pass through /UDS as A0. So when UDS goes high, a smidge later A0 starts falling *in parallel with* DSP_CS rising.

It's a race. If DSP_CS rises fast enough, it'll work. If A0 drops slightly faster, it'll only work on even numbers.

I could probably influence the timings slightly with my random extra bits of capacitance here and there. Even attaching an oscilloscope to the AS line was enough to knock it off kilter.

It also explains why I could read but not write. When I read, the CPU latches the data on the next falling clock edge after DSACK0 is seen. All the lines are stil properly asserted. I couldn't write, however, as writes to the DSP are only actioned when FFA207 is written to. An odd address! Remember high UDS = low A0 => even addresses only!

I've had my confidence in a tentative solution knocked back so many times that I'm touching wood left right and centre here, but so far this is all consistent.

I think I could probably even wind my extended assertion of UDS & LDS back half a clock to match the 030's assert-until-next-rising-edge behaviour.

BW
DFB1 Open source 50MHz 030 and TT-RAM accelerator for the Falcon
DSTB1 Open source 16Mhz 68k and AltRAM accelerator for the ST
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark
User avatar
sporniket
Posts: 956
Joined: Sat Sep 26, 2020 9:12 pm
Location: France
Contact:

Re: DFB1r4 design discussion thread

Post by sporniket »

Hi, I am a bit of a noob here, but is there a datasheet of the DSP with more or less accurate/exact timing diagrams and all ? I am aware that datasheets are not The Book of Absolute Truth, but maybe some statements on the protocol expected by the DSP would help, especially when it confirms what happens in the working case (stock falcon), with the side benefits of maybe giving hints of how much leeway you have compared to the stock falcon.

I am under the impression that you are working totally in the dark, with no reference at all.

Anyway, if there is a datasheet with timing diagrams, does those diagrams verify/explains the working cases (your latest attempt, the stock falcon) and the non working ones (timing mismatches here and there) ?
User avatar
Badwolf
Posts: 2231
Joined: Tue Nov 19, 2019 12:09 pm

Re: DFB1r4 design discussion thread

Post by Badwolf »

sporniket wrote: Thu Nov 25, 2021 12:51 pm I am under the impression that you are working totally in the dark, with no reference at all.

Anyway, if there is a datasheet with timing diagrams, does those diagrams verify/explains the working cases (your latest attempt, the stock falcon) and the non working ones (timing mismatches here and there) ?
Hiya,

No. Not totally in the dark with the DSP: there is a datasheet and it states writes are latched on the rising edge of chip select (which I've mentioned a few times).

The in the dark bit is because the Falcon's CPU works one way, but an expansion port device has to work an entirely different way. Atari bizarrely decided the expansion port would emulate a 68K interface rather than provide direct access to the 030's interface.

Anyway, it just took me until yesterday to realise the implications of 1) Having A0 driven by the UDS line (see above!) and 2) data latching on the rising edge of the chip select line when they both normally occur simultaneously.

If someone hadn't kindly worked out the GAL equations in the past I'd be genuinely groping.

BW
DFB1 Open source 50MHz 030 and TT-RAM accelerator for the Falcon
DSTB1 Open source 16Mhz 68k and AltRAM accelerator for the ST
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark
User avatar
exxos
Site Admin
Site Admin
Posts: 23496
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: DFB1r4 design discussion thread

Post by exxos »

Badwolf wrote: Thu Nov 25, 2021 10:32 am So my system happily carries on asserting A1-23 and D16-31, but A0 is asserted by the GALs, which just pass through /UDS as A0. So when UDS goes high, a smidge later A0 starts falling *in parallel with* DSP_CS rising.

It's a race. If DSP_CS rises fast enough, it'll work. If A0 drops slightly faster, it'll only work on even numbers.
Great work in finding it :dualthumbup: curse of the Atari strikes again :lol:
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
User avatar
Badwolf
Posts: 2231
Joined: Tue Nov 19, 2019 12:09 pm

Re: DFB1r4 design discussion thread

Post by Badwolf »

Over six hours of AltRAM and DSP testing under the belt today. The occasional problem, normally on boot -- could be a oscillator sync issue -- but a cold start normally sorts it.

Here's what I've been up to, just to prove a point:- :D

IMG_4880.jpeg
IMG_4880.jpeg (186.95 KiB) Viewed 2035 times
IMG_4882.jpeg
IMG_4882.jpeg (282.04 KiB) Viewed 2035 times

(sorry for the woeful quality RGB cable -- I think it's actually a telephone extension cable I hacked!)

Next stop is the FPU. Last time I tried to get it working DSACK0 was as quiet as the grave...

BW
DFB1 Open source 50MHz 030 and TT-RAM accelerator for the Falcon
DSTB1 Open source 16Mhz 68k and AltRAM accelerator for the ST
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
FrontBench The Frontier: Elite 2 intro as a benchmark
Post Reply

Return to “HARDWARE DISCUSSIONS”