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 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.
As far as I can tell there are only a few signals actually in play. But there are two failure modes:-

Mode 1; no write:

The DSP is meant to latch data on the rising edge of its chip select signal if RW is low, irregardless of the state of the CPU Clock (the CPU clock doesn't come near the DSP, and its own clock is, I believe outside of this process).

That CS signal is driven from the GALs by a combination of the address bus, the current state of AS and the state of AS in the *previous* cycle (this is, I think, the only clock depdenency and the source of the timing issues).

AS goes high (signalling when CS should dessert) once DSACK0 has been asserted, which is triggered from XDTACK from the motherboard, which is driven by almost exactly same logic as CS.

So, in total, the expansion interface lines involved in writing to the DSP are, I believe:
  • XAS
  • A[23:8]
  • XRW
  • XDTACK
  • XCPUCLK
    and the data bus
  • D[31:24] (8 bits).
All my probing suggests these are behaving as they should (the obvious one I watched was XRW as that's a straight through whereas the others went by CPLD).

I'm unconvinced by data bus instability as *any* successful write [even gibberish on the lines] should yield a change in the DSP registers.

Mode 2; partial success:

Certain combinations of delay time in the CPLD cause DMA2DSP and my sample ATARI.TOS program to pass but more complicated (eg. FRAC_DSP.PRG or BADMOOD) DSP demanding programs to fail.

Because of that odd old-AS dependency in the GALs, I've had to slow down access to the DSP (two consequtive cycles takes around 600ns instead of around 300). This could be the cause of it, but I suspect not as this technique did work in one of the previous boards.

I can get some builds where there is the occasional (once or twice per screen) failure in DMA2DSP suggesting it's not random (bus) noise, but related to the timing of the lines still.

I think we can probably again consider address bus noise unlikely as access to all other parts of the motherboard works, and I can scope the CS signal (which the address bus drives) clearly enough.

Again it seems to come down to timing, but timing of what? I can see the AS, CS, XDTACK, RW lines all appear clean, and, again, only CS, A and RW are meant to matter to the DSP, so something still remains unresolved.
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.
This, or a variation on this (for the DSP) is probably worth doing as there are so few lines involved.
It is quite possible you are just falling victim to a unstable bus. A slight bit of wrong capacitance or inductance in the wrong place and everything goes to crap.
I can't rule it out, but I also can't see how it would only affect the DSP and how even gibberish is being ignored.
OTHO 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..
Mmm. I don't have bus isolation, but I have delayed assertion of the motherboard copy of XAS until long after the CPU assertion of AS without joy. As mentioned above, I actually have to do this anyway because of the annoying GAL clock-based interference in the expansion port's communications.
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.
Certainly I can give that a go -- just because I can' see a mechanism for it to have an effect doesn't mean it's not worth trying!

Cheers,

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: 23499
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: DFB1r4 design discussion thread

Post by exxos »

Badwolf wrote: Tue Nov 16, 2021 4:52 pm Certain combinations of delay time in the CPLD cause DMA2DSP and my sample ATARI.TOS program to pass but more complicated (eg. FRAC_DSP.PRG or BADMOOD) DSP demanding programs to fail.
But that can be bus noise again. The STE can pass hard drive diagnostic tests all day and work perfectly well. And every single time you save newdesk.inf it will corrupt the SD card.

It's down to combinational faults on the bus. When accessing the DMA continuously it all works fine. But when you start accessing DMA interleaved with ROM access.. it is like a "seesaw" on the bus causing it to malfunction. Similarly, if you test the ROM's, they will pass perfectly fine all day.

Of course like you say though, it could simply be a timing problem somewhere. If you can get a program to mostly work, and you took various pins with your scope on X1 And it starts failing more, then you at least have a starting point to work from.

There is just no way to know without starting to rule something out. I'm always going to be biased to bus noise as it is being a thorn in my side like the past 20 years :roll: Some STFM's always seem to have most issues on D4 for some reason, for example.

In any case, I don't know why you would not be able to write to the DSP full stop. But if the GAL logic is slow, and your CPU board logic is obviously not going to be, it is possible one of the high address lines ( or wherever the DSP is in the memory map) Would have some noise where it does not affect CS, simply too slow, but your board could react to it and change the address so it is not actually accessing the DSP at all.

There is a lot of problems with these machines. You simply cannot assume absolutely anything. And again just because DSP CS in active, does not actually mean that is the address the CPU is trying to write to. I have had crazy crap like this happen to me in the past.
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
sporniket
Posts: 956
Joined: Sat Sep 26, 2020 9:12 pm
Location: France
Contact:

Re: DFB1r4 design discussion thread

Post by sporniket »

Driven by despair, if there is enough remaining space and pins in your CPLD, I would remove the GAL, reimplement it in the CPLD and wire the signals somehow.

User avatar
frank.lukas
Posts: 660
Joined: Fri Jan 19, 2018 11:52 am

Re: DFB1r4 design discussion thread

Post by frank.lukas »

Do you know about the Mighty Sonic ?

https://wiki.newtosworld.de//index.php? ... y_Sonic_32

... there are some wires at the GAL ...
User avatar
exxos
Site Admin
Site Admin
Posts: 23499
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: DFB1r4 design discussion thread

Post by exxos »

Wasn't that sort of thing done with the original Afterburner accelerator? I think the general word on the street was that taking control of the bus for a different CPU was not "thought of" back then. Similar that the you pins to isolate the motherboard processor was done back then and not done now.

So I think better practices were just developed since then. But as to what those wires actually connect to would be interesting to know..
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 »

Well, guys -- I've had a bit of an interesting find, and possibly a breakthrough.

I got the breadboard out to try some of the experiments @exxos and I were discussing, but @sporniket mentioning re-implementing the GAL reminded me I was going to try feeding my own chip select into the DSP.

So I breadboarded the GAL, flywired it but tapped off the DSP_CS line to my board and passed it through the CPLD.

IMG_4864.jpeg
IMG_4864.jpeg (197.27 KiB) Viewed 1685 times
Screenshot 2021-11-16 at 20.51.03.png
Screenshot 2021-11-16 at 20.51.03.png (26.01 KiB) Viewed 1685 times


Feeding the output of the GAL back to the board didn't work. Why? Only think I can think of is the 10ns delay is enough to stop the DSP sampling the writes.

Screenshot 2021-11-16 at 20.52.06.png
Screenshot 2021-11-16 at 20.52.06.png (13.57 KiB) Viewed 1685 times

OK. What if I terminate the output assertion short? Desperate measures, eh?

Screenshot 2021-11-16 at 21.03.18.png
Screenshot 2021-11-16 at 21.03.18.png (13.31 KiB) Viewed 1685 times

Well, bugger me -- it works flawlessly!





Now, obviously this is not a solution: I can't easily intercept the GAL's DSP_CS line. But perhaps I can sneakily play with the XAS line to terminate this early? I'm not sure, but I have a new line of inquiry.

Thanks everyone -- kicking ideas around can certainly help. :-)

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: 23499
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: DFB1r4 design discussion thread

Post by exxos »

:bravo:

But also how odd. How many ns are you finishing the cycle early by ?
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: Tue Nov 16, 2021 10:17 pm :bravo:

But also how odd. How many ns are you finishing the cycle early by ?
Cheers! :)

It varies. I'm actually enforcing it to assert for only half a clock.

So, on stock, it's by about 50ns:

Screenshot 2021-11-16 at 21.03.18.png
Screenshot 2021-11-16 at 21.03.18.png (13.31 KiB) Viewed 1679 times

But on the DFB1 (slower cycle b/c of the GALs), it's huge -- something like 140ns.

Screenshot 2021-11-16 at 22.23.43.png
Screenshot 2021-11-16 at 22.23.43.png (580.83 KiB) Viewed 1679 times

The problem, of course, is that if I terminate XAS early, XDTACK will also terminate early. This is probably fine for writing, but I may need to have a separate read and write logic.

Anyway, at least I now have that 'smoking gun' I was looking for.

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: 23499
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: DFB1r4 design discussion thread

Post by exxos »

Bonkers. If the GAL is just being used as a address decoder should not be acting so slowly.

What are all the other signals on the GAL doing ?

Actually it doesn't have AS30 on the GAL ?

Also have you checked those signals on a scope not a LA ?

While its on breadboard, can you simulate the address with jumper wires and see the time from address to DPS_CS is like ?
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: Tue Nov 16, 2021 10:37 pm Bonkers. If the GAL is just being used as a address decoder should not be acting so slowly.
It's not just one GAL, it's a complicated birds nest taking in, AFAICT, 3 of the 5 GALs on the board. U44 is just the last one in the DSP_CS chain.

See the image from post https://www.exxosforum.co.uk/forum/viewt ... 140#p73085

The final chip select signal is driven by the address lines on that chip and DSPDS.

DSPDS comes from U68 and is driven by three other address lines, AS, a one-clock-delayed AS [which is where the slow cycle time comes from when using the expansion port, we have to wait for this to reset] and another signal called XDSP.

XDSP comes from U67 and is derived from four address lines and the FC lines.
What are all the other signals on the GAL doing ?
The other signals generate the DSACK0 line (which is further delayed by it being translated to XDTACK before I see it) plus some interrupt handling logic. These don't seem to be timing critical from my board's point of view (in fact I've synthesised DSACK0 completely without reference to XDTACK during my experiments).
Also have you checked those signals on a scope not a LA ?
I have. I can't find anything wrong other than it now appears the termination of the cycle can't be more than 10ns before DSP_CS goes high.
While its on breadboard, can you simulate the address with jumper wires and see the time from address to DPS_CS is like ?
Ach, sorry -- have taken it all up now. The address decoding is spread over all those GALS, though. I imagine it's sub 10ns, though. I think it's the release time that's key.

Here's my theory: in stock configuration, U44 generates DSACK0. That goes directly to the onboard chip. The cycle terminates on time, AS goes high. AS going high immediately deasserts DSPDS, which (within 10ns) deasserts DSPCS. Everything's happy. Latency is low.

In external bus master configuration, however, DSACK0 is generated but has to be translated (again by the GALs) to XDTACK. My CPLD then has to translate that back into DSACK0 for my CPU [have I mentioned the braindead expansion interface in the Falcon recently?]. That's a 20ns delay. Then the bus cycle ends (probably a clock cycle late, remember the clock is also behind by 15ns) and AS is deasserted. AS has to be translated to XAS by the CPLD (another 10ns) before the GALs can drop DSPDS and then the cycle above takes over. With all the logic delays combined, the cycle takes twice as long and deassertion is probably *so* delayed that, I don't know, perhaps the address lines are no longer valid? Maybe RW has gone high?

I was unable to prove the above with the scope -- the address and RW lines did seem valid for a reasonable time after DSPCS went high, but who knows? Perhaps the DSP's clock is involved in the sampling process, even if the data sheet doesn't say so. Then there could be up to 35ns additional delay before data is latched.

With all the cumulative delays above, is it possible that's what's happening? It would tie in with the speed optimisation being marginal whereas density simply failed.

So my next trick will be to attempt to drop XAS artificially early whilst the processor still has yet to have seen DSACK0. That should keep the address and RW lines asserted long enough for sampling.

...that's assuming it can fit into block FB5, which was full.

One for tomorrow. :lol:

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”