DFB1r4 design discussion thread

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

Re: DFB1r4 design discussion thread

Post by Badwolf » Fri Nov 12, 2021 10:09 am

Two steps forward, one step back.

The configuration that was working (and playing BadMood) Wednesday, doesn't work now. It *almost* works. It's better than it was before and DMA2DSP passes throughout, which is why I didn't pick this up yesterday during SDRAM testing.

Basically the symptom is that the DSP works for a bit but then fails or gets out of sync somehow. It's not consistent in its location, though.

I get the feeling some timing element is right on the edge of working and when the moon's in the right phase it works but when a cat farts in Tokyo, it doesn't. Infuriating!

I may have to take a couple more steps back and try some funky timing experiments again. I'm also contemplating linking (my) AS and (the mobo's) XAS directly. This would preclude any DMA, but if it works, I could try a gating it with a MOSFET rather than running the line through the CPLD?

I did some timing analysis on the DFB1r3 (the infamous board that works where all else fails) and that has a delay between AS and XAS of 14.5ns. This board has a delay of 15.5ns. Is this the smoking gun?

BW
Falcdate Use the internet to work around dead Falcon NVRAM battery
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
DFB External 030 and AltRAM for the Falcon (under development)

User avatar
exxos
Site Admin
Site Admin
Posts: 16571
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: DFB1r4 design discussion thread

Post by exxos » Fri Nov 12, 2021 10:47 am

Badwolf wrote:
Fri Nov 12, 2021 10:09 am
I did some timing analysis on the DFB1r3 (the infamous board that works where all else fails) and that has a delay between AS and XAS of 14.5ns. This board has a delay of 15.5ns. Is this the smoking gun?
I thought you experiment with that not long ago and removed the delay totally ?
https://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxoshost.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 ~

Badwolf
Posts: 636
Joined: Tue Nov 19, 2019 12:09 pm

Re: DFB1r4 design discussion thread

Post by Badwolf » Fri Nov 12, 2021 12:24 pm

exxos wrote:
Fri Nov 12, 2021 10:47 am
Badwolf wrote:
Fri Nov 12, 2021 10:09 am
I did some timing analysis on the DFB1r3 (the infamous board that works where all else fails) and that has a delay between AS and XAS of 14.5ns. This board has a delay of 15.5ns. Is this the smoking gun?
I thought you experiment with that not long ago and removed the delay totally ?
No, that was the clock (XCPUCLK pin on the expansion header wired directly to the external 030's clock pin). It seem to have little effect.

I've subsequently started to think it's about XAS assertion timing, but I can't prove it as I couldn't measure any difference between the (not at all working) density optimised build and the (occasionally working) speed optimised build.

It really is very puzzling indeed!

BW
Falcdate Use the internet to work around dead Falcon NVRAM battery
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
DFB External 030 and AltRAM for the Falcon (under development)

Badwolf
Posts: 636
Joined: Tue Nov 19, 2019 12:09 pm

Re: DFB1r4 design discussion thread

Post by Badwolf » Fri Nov 12, 2021 7:59 pm

Right. So I've built an EmuTOS ROM image that doesn't do DMA up to and including the desktop. No blitter, no floppy.

I've disabled all external ROM and SDRAM on my board.

Verified that the DSP problems still exist in this configuration.

Confirmed. Some DSP programs work. Frac_DSP fails consistently.

Disable CPU clock generation and feed it direct from the motherboard.

Result: hangs initialising the DSP.

So this is interesting. By getting the clocks *more* in sync, the DSP goes back to its read only failure mode.

Leaving the clocks tied, connect AS and XAS (the CPU and the motherboard) directly.

Fails with gibberish on the DSP port

OK, I wasn't expecting that. The Falcon boots happily to the desktop as it sees the status changing on the DSP port and thinks it's working, but nothing works.

This is interesting. The only remaining lines that are not directly connected are UDS, LDS and the DSACKs. Unfortunately all of these do need to go through the CPLD as they're translations (bloody stupid Falcon expansion port!)

The expansion port asserts only one reply: XDTACK. That needs to go to the CPU's DSACK0 when accessing the DSP and DSACK1 at all other times.
The CPU only asserts one data strobe: DS. The expansion port however has two. UDS and LDS. The CPLD needs to work out which one to assert.
So these have to go through the CPLD.


I think I'm going to have to scope these all out again in their current state now to see if I have an 'aha' moment. The next obvious thing to try would be to gate *all* these signals off the same clock, but I tried that once before without success. Still, you'd think it must be some combination of that...


BW
Falcdate Use the internet to work around dead Falcon NVRAM battery
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
DFB External 030 and AltRAM for the Falcon (under development)

Badwolf
Posts: 636
Joined: Tue Nov 19, 2019 12:09 pm

Re: DFB1r4 design discussion thread

Post by Badwolf » Fri Nov 12, 2021 10:08 pm

This is with AS <--> XAS and CLK <--> XCPUCLK hard wired.

Look at this unholy s**t show:

Screenshot 2021-11-12 at 21.50.48.png
Screenshot 2021-11-12 at 21.50.48.png (24.53 KiB) Viewed 317 times

Here's my interpretation of the above.

Screenshot 2021-11-12 at 21.50.48 copy.png
Screenshot 2021-11-12 at 21.50.48 copy.png (159.95 KiB) Viewed 317 times

Since I now have no control over XAS or the clock, the only thing I can really play with now is the link between XDTACK and DSACK0. I don't see how holding it off will help, but I'll try it. It could be the best bet is to second guess XDTACK assertion -- assert it early (after a fixed number of clock after XAS) to ensure XAS is terminated on time?

It's amazing this *ever* worked! :shock:

BW
Falcdate Use the internet to work around dead Falcon NVRAM battery
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
DFB External 030 and AltRAM for the Falcon (under development)

User avatar
exxos
Site Admin
Site Admin
Posts: 16571
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: DFB1r4 design discussion thread

Post by exxos » Fri Nov 12, 2021 10:29 pm

I've had that as well. Normally slapping 1K on DTACK pullup sorts it out.

But it's also why I delay DTACK reaching the CPU as much as possible. Wherever the point is where a standard cycle would terminate DTACK, I would back off a little bit something like 50% back through the previous cycle. So what happens is the CPU terminates the bus cycle, then the chipset will see CPU_AS goes high, release DTACK on the current clock edge. It is why synching to a clock edge does not generally work.Because if you terminate on a edge to early, the CPU will start a next cycle, and you end up with the sh*t show like you got. When you let the CPU terminate the bus cycle just before a clock edge, the motherboard chipset will see CPU_AS going high and terminate the cycle, everything is happy. If you complete the bus cycle too late, it is generally when you end up with like 80% RAM speed etc.

I'm not very good explaining stuff unfortunately...
https://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxoshost.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 ~

Badwolf
Posts: 636
Joined: Tue Nov 19, 2019 12:09 pm

Re: DFB1r4 design discussion thread

Post by Badwolf » Sat Nov 13, 2021 12:18 am

exxos wrote:
Fri Nov 12, 2021 10:29 pm
I've had that as well. Normally slapping 1K on DTACK pullup sorts it out.
That's worth trying: it's a one minute job: doesn't have any effect, sadly.
But it's also why I delay DTACK reaching the CPU as much as possible. Wherever the point is where a standard cycle would terminate DTACK, I would back off a little bit something like 50% back through the previous cycle.
I think I've understood what you've said about this before, but perhaps I've been wrong.

Reading the following:
So what happens is the CPU terminates the bus cycle, then the chipset will see CPU_AS goes high, release DTACK on the current clock edge. It is why synching to a clock edge does not generally work.Because if you terminate on a edge to early, the CPU will start a next cycle, and you end up with the sh*t show like you got. When you let the CPU terminate the bus cycle just before a clock edge, the motherboard chipset will see CPU_AS going high and terminate the cycle, everything is happy. If you complete the bus cycle too late, it is generally when you end up with like 80% RAM speed etc.
I'm thinking this only works at higher clock speed, or inverted? Mine's at mobo speed here. Otherwise I can't see how delaying DSACK0 can result in the cycle finishing on time when it finishes late without delay.

My suggestion was to finish it early by synthesising DSACK0. Unfortunately last time I tried that didn't work -- although, thinking about it, perhaps I was still aiming for density optimisation back then.

Here's the 'normal' cycle, for reference.

Screenshot 2021-11-13 at 00.08.01.png
Screenshot 2021-11-13 at 00.08.01.png (24.37 KiB) Viewed 287 times

The cycle terminates 10ns after the clock edge. As close to on the edge as you can get, I suppose. That needs DSACK0 asserting before the *previous* negedge.

Let me see what I can cook up.

BW.
Falcdate Use the internet to work around dead Falcon NVRAM battery
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
DFB External 030 and AltRAM for the Falcon (under development)

User avatar
exxos
Site Admin
Site Admin
Posts: 16571
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: DFB1r4 design discussion thread

Post by exxos » Sat Nov 13, 2021 12:35 am

Ah sorry I missed your using the MB clock. I mean in that case there shouldn't be any difference over using the MB CPU ? I assume you pretty much just have the CPU on your card and that's it kinda thing currently ?
https://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxoshost.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 ~

Badwolf
Posts: 636
Joined: Tue Nov 19, 2019 12:09 pm

Re: DFB1r4 design discussion thread

Post by Badwolf » Tue Nov 16, 2021 3:12 pm

exxos wrote:
Sat Nov 13, 2021 12:35 am
Ah sorry I missed your using the MB clock. I mean in that case there shouldn't be any difference over using the MB CPU ? I assume you pretty much just have the CPU on your card and that's it kinda thing currently ?
Yeah.

AS --> XAS (direct)
CLK <-- XCPUCLK (direct)
DS -> CPLD -> UDS / LDS
DSACK[1|0] <- CPLD <- XDTACK

Doesn't work.

No way to bypass the CPLD for the the bottom two unfortunately as they don't map 1:1.

So it's back to experimenting with delays, I think. I simply can't find the smoking gun!

BW
Falcdate Use the internet to work around dead Falcon NVRAM battery
Smalliermouse ST-optimised USB mouse adapter based on SmallyMouse2
DFB External 030 and AltRAM for the Falcon (under development)

User avatar
exxos
Site Admin
Site Admin
Posts: 16571
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: DFB1r4 design discussion thread

Post by exxos » Tue Nov 16, 2021 3:31 pm

Normally this is the point I start to do "finger on board" various places to see if I can narrow it down to any particular signals.

Similarly using the scope on x1 slots next to capacitance onto various signals. And even using a fly lead with a 2.2K resistor on it to 5V then simply going across every CPU pin.

It is quite possible you are just falling victim to an unstable bus. A slight bit of wrong capacitance or inductance in the wrong place and everything goes to crap.

When I revised one of my V2 booster layouts, I went to great lengths and even hardwired everything from the DIP CPU socket to the PLCC CPU.. It was about the time I was fighting bad sockets, but just extending the CPU bus like 1 inch was enough to make the thing unstable. This was in part why I started pushing changing the bus resistors to 2.2K. Machines would either work or stop working when the diagnostic cartridge was plugged in for example.

As to why I never heard of anyone changing the resistors in their Falcon yet is still strange. I think it is quite literally just a fluke that things work when they do. So I think a lot of people who design stuff are not simply aware of these problems. Of course if customers have the odd crash here and there they will probably think nothing of it anyway.

OTOH maybe designers did find such problems and do some elaborate workaround for it. For example when AS30 goes low, the bus is supposed to be stable. But maybe actually has not settled yet. In which case may be isolating the whole bus from the PLD internally (not really sure if that is even possible) to unload a few pF from the bus, then enable it several ns after AS30 goes low with the assumption it has actually settled at that point. I'm just thinking out loud really..

From years of upgrading these machines, changing the bus resistors is pretty much the root of all evil. At least for the ST series. As to if this is your problem or not.. I think it may be time to just bodge on some 2.2K's on the bus and see what happens. At least then you can rule out that problem.
https://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxoshost.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 ~

Post Reply

Return to “HARDWARE DISCUSSIONS”