DFB1r4 design discussion thread

General discussions or ideas about hardware.
User avatar
JezC
Posts: 2081
Joined: Mon Aug 28, 2017 11:44 pm

Re: DFB1r4 design discussion thread

Post by JezC »

Badwolf wrote: Tue Oct 19, 2021 5:22 pm Aha. the difference there is that Stephen's demonstrably the best person to fix HDL issues with the TF range. I have no qualms in admitting I'm not! :D
You're probably being a bit too modest there - no-one will know your design as well as you do (unless they reverse engineer it, of course!) :mrgreen:
Whereabouts are you & do you have a PGA 030 & a few 30-50MHz oscilaltors kicking around? I could send you the final iteration of the rev3b for testing if you fancy. It needs the PSU to be unseated in a clever measure to stop you hanging on to it too long :lol:
I'm in North Yorkshire - I have a couple of TF536 boards (one built up by PhilC & one awaiting delivery of some scarce parts...thanks to the current shortages! :x ) - I'd have to check which oscillators I have access to but I do think I've got a few in that range (not sure of the exact values without checking though).
No worries about the PSU being relocated...that might even cause me to fit the Exxos one I bought a year or more ago... ;)
Would only really be a go/no-go, though, as there's no more dev going on on that firmware but it would be nice to get a feeler for the level of specificity of these boards to my Falcon.

BW
Makes sense - you need to divert effort onto the latest & greatest, I completely understand.
Like you, having any additional information about how transferrable the design is might well help guide your next steps...no point spending ages on it if it won't easily work on any other system!

No rush from my perspective..but happy to try & help as/when I can (while I try to fix my H4 & H5 boards...and recap/repair all the other ST & Amiga systems)... :lol:
terriblefire
Moderator Team
Moderator Team
Posts: 5368
Joined: Mon Aug 28, 2017 10:56 pm
Location: Glasgow, UK

Re: DFB1r4 design discussion thread

Post by terriblefire »

Badwolf wrote: Tue Oct 19, 2021 5:22 pm
Aha. the difference there is that Stephen's demonstrably the best person to fix HDL issues with the TF range. I have no qualms in admitting I'm not! :D
I've said im useless and an idiot on many occasions. Nobody listens. Even when I dont sell stuff i get threatened that i am a manufacturer and that the law says i need to warranty stuff for 6 years. There was a particularly nasty fellow had a go at me earlier this year on every Amiga group because i wouldnt fix an issue like right now.

Other times when people cant solder they take it out on me that "You have designed turbocard... you should know how to fix".

Ultimately this is why things are the way they are with the TF1260.. very few complaints because the idiots arent allowed to built it. At least not yet.
———
"It is not necessarily a supply voltage at no load, but the amount of current it can provide when touched that
indicates how much hurting you shall receive."
User avatar
Badwolf
Posts: 2231
Joined: Tue Nov 19, 2019 12:09 pm

Re: DFB1r4 design discussion thread

Post by Badwolf »

JezC wrote: Tue Oct 19, 2021 5:48 pm No rush from my perspective..but happy to try & help as/when I can (while I try to fix my H4 & H5 boards...and recap/repair all the other ST & Amiga systems)... :lol:
Alas, I'd forgotten I'd started cannibalising that board so it's not a goer at the moment.
terriblefire wrote: Wed Oct 20, 2021 8:51 am
Badwolf wrote: Tue Oct 19, 2021 5:22 pm Aha. the difference there is that Stephen's demonstrably the best person to fix HDL issues with the TF range. I have no qualms in admitting I'm not! :D
I've said im useless and an idiot on many occasions. Nobody listens.
We might listen, but we might not believe. ;)

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
JezC
Posts: 2081
Joined: Mon Aug 28, 2017 11:44 pm

Re: DFB1r4 design discussion thread

Post by JezC »

Badwolf wrote: Wed Oct 20, 2021 3:25 pm
JezC wrote: Tue Oct 19, 2021 5:48 pm No rush from my perspective..but happy to try & help as/when I can (while I try to fix my H4 & H5 boards...and recap/repair all the other ST & Amiga systems)... :lol:
Alas, I'd forgotten I'd started cannibalising that board so it's not a goer at the moment.
Never mind...if you want me to check it at a later point/on a different revision etc, just let me know! It's almost certain to be before I build up my second TF536 board (and use up my 'spare' 68030 PGA)...
terriblefire wrote: Wed Oct 20, 2021 8:51 am
I've said im useless and an idiot on many occasions. Nobody listens.
We might listen, but we might not believe. ;)

BW
Absolutely...all humility aside, if TF is that useless, what hope for (most of) the rest of us? ;)
User avatar
Badwolf
Posts: 2231
Joined: Tue Nov 19, 2019 12:09 pm

Re: DFB1r4 design discussion thread

Post by Badwolf »

OK, so I'm turning my attention back to the DSP. Why does it work with *only* one board an no others? Must be a quirk of the clock delays, I figured, but instead of trying to replicate that quirk, let's do some measuring.

Noting the details of my investigation here as a record for others.

Firstly, what are the symptoms?

Basically writes don't work. Writes to the DSP data port do not have any effect on the status registers meaning the OS or any other DSP-enabled program tries to write a program to the DSP and sits and waits forever for its acknowledgement.

How do we know?

The way the DSP is exposed to the system there are eight bytes at FFA200 to FFA207. The first four are registers, the latter four are for data (technically only the last three, byte FFA204 is ignored). For the data bytes, nothing happens until a write to FFA207 triggers action.
The most obvious indication of activity on the DSP is after a write to FFA207, the register at FFA202 should change.

By way of example, on a vanilla system after a clean boot, FFA200.l reads:

Code: Select all

00 12 06 0f
Writing anything to FFA207 causes that to change to:

Code: Select all

00 12 02 0f
This is the important feedback the system needs to know how to respond next. When writing to the DSP from my card, 16MHz, 06 never changes.

The DSP is connected to the system with only an 8 bit port. Data lines 31-24 are therefore active and the CPU needs DSACK0 to be asserted. This means that when using the Falcon expansion bus special attention must be paid to DSP access as for all other motherboard accesses, DSACK1 is asserted when a DTACK is received from the GALs. Secondly, a different algorithm must be used for UDS and LDS. Fortunately these are all seen to be logically sound as a) reads work and b) one board does work with this logic.

Now possibly because the DSP is odd like this (or possibly because it was a later addition to the spec?) its chip select, data strobe, DTACK and other control lines are not handled by COMBEL: it has its own GAL, U44, although it interacts with the main GALs in a few ways:

Screenshot 2021-10-28 at 19.52.17.png
Screenshot 2021-10-28 at 19.52.17.png (261.59 KiB) Viewed 1893 times

U44 is responsible for issuing the DSP's CS and DS signals and generating the DSACK0 line (which ultimately generates the XDTACK line I see on the expansion port).

According to the 56001's data sheet, the Host Enable pin is of most obvious interest:
Host Enable (HEN)
This input enables a data transfer on the host data bus. When HEN is asserted and HR/W is high, H0-H7 become outputs, and DSP56001 data may be read by the host processor, When HEN is asserted and HR/W is low, H0-H7 become inputs and host data is latched inside the DSP when HEN is deasserted. Normally a chip select signal, derived from host address decoding and an enable clock, is used to generate HEN. HEN may be programmed as a general purpose I/O pin called PB12 when the Host Interface is not being used. This pin is configured as a GPIO input pins during hardware reset.
The HEN pin is the XDSP_CS line from U44 and HR/W is the system's RXW line.

To my mind, therefore, it must be all about XDSP_CS.

Here's what we get when we compare XAS (the CPU's address strobe) with XDSP_CS and the clock (stock Falcon):

Screenshot 2021-10-28 at 20.08.27.png
Screenshot 2021-10-28 at 20.08.27.png (15.95 KiB) Viewed 1893 times

But here's what we see when my external card tries to write to the DSP (at Falcon 16MHz speed):

Screenshot 2021-10-28 at 20.06.59.png
Screenshot 2021-10-28 at 20.06.59.png (14.66 KiB) Viewed 1893 times


Something is very awry!

Now, on the face of it, unless RXW is going high too soon (it's not), I can't see why this still wouldn't work -- albeit in slow motion. But the delay between AS being asserted and XDSP_CS going low is odd. Equally, not shown here, DSACK0 basically mirrors XDSP_CS so why is it taking so long for AS to go back high again?

So I'm going to go away and review the GAL equations and perhaps start messing with my timings. Perhaps emulating my own DSACK0 rather than waiting for the motherboard.

I'll let you know how I get on, but any ideas welcomed.

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

Re: DFB1r4 design discussion thread

Post by exxos »

That is odd. Its like your card is running at half speed, BUT, if CS is controlled by the GAL, then what triggers the GAL to slow down ?!

I can only suggest you get the LA on all the control pins on U44 to see if you can get some clues. But overall, being slow shouldn't really matter anyway.
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 Oct 28, 2021 9:11 pm That is odd. Its like your card is running at half speed, BUT, if CS is controlled by the GAL, then what triggers the GAL to slow down ?!

I can only suggest you get the LA on all the control pins on U44 to see if you can get some clues. But overall, being slow shouldn't really matter anyway.
There is an intentional delay built into the assertion of AS when accessing the DSP. This is because there's a clock dependency in the GALs -- the chip select has a component based on the delayed AS signal and it picks up the old AS before it's properly deasserted.

Here's how it looks without that:
Screenshot 2021-10-28 at 22.45.10.png
Screenshot 2021-10-28 at 22.45.10.png (12.07 KiB) Viewed 1868 times

Properly messed up.

This only affects the gap between AS going high and going low again, and only when accessing the DSP.

It shouldn't affect cycle speed (and indeed doesn't):
IMG_4829.jpeg
IMG_4829.jpeg (235.63 KiB) Viewed 1868 times

Investigations continue!

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 »

A little bit of old-school analysis coming up.

Scannable Document on 29 Oct 2021 at 09_20_40.png
Scannable Document on 29 Oct 2021 at 09_20_40.png (262.76 KiB) Viewed 1828 times

These are pins of interest on U44 versus the clock, plus the overall AS vs CS measurement (as seen earlier in the logic analyser). This is on the stock Falcon, known to work.

Scannable Document 2 on 29 Oct 2021 at 09_20_40.png
Scannable Document 2 on 29 Oct 2021 at 09_20_40.png (222.08 KiB) Viewed 1828 times

These are the same pins on the not-working card. Showing the same information we've seen above: the board needs one full clock cycle longer for the CS line to deassert to complete and, importantly it's taking longer between AS asserting and CS asserting, causing a doubling in cycle length.

I've tried fiddling with the clock to try to reduce clock skew by using a variant of Stephen's sample-and-delay technique, but a 100MHz clock doesn't seem good enough resolution to achieve that. The machine won't even boot if it's 5ns ahead, and 5ns behind doesn't change a thing. I don't think that's a go-er.

So, with the datasheet implying CS going high is the key event here, my attention turns towards the lag CS deasserting seen here:

composite.png
composite.png (132.87 KiB) Viewed 1828 times

Having a look at the equations it seems the key dependency for that CS line is AS:

Code: Select all

!DSPCS      = A23 * A22 * A21 * A20 * A15 * !A14 * A13 * !A12 * !A11 * !A10 * A9 * !A8 * !A7 * !A6 * DSPDS;
...
DSPDS      = AS * DSP * DL1AS * /A5 * /A4 * /A3;
...
DSP          = FC2 * FC1 * /FC0 * A19 * A18 * A17 * A16
              + FC2 * /FC1 * FC0 * A19 * A18 * A17 * A16;
So the obvious thing to try next is to shut down passing though AS after a certain number of clock cycles -- to try and get that DSP to latch on the right edge.

I'll try to figure out some logic to do that, but only when accessing the DSP.

All these extra logic paths are why I can't meet the timing in the first place, I imagine!

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

Re: DFB1r4 design discussion thread

Post by exxos »

I've had no end of trouble with /AS on the ST as well. I gave up trying to synchronise it and just did not bother in the end as it was causing more trouble than it was worth.

Problem being when you are running a asynchronous clock, you can only really synchronise to a rising edge for falling edge, but if you are a fraction behind in timings you end up waiting another complete 8Mhz cycle. By which time GLUE thinks nothing is using the bus, starts doing something else, then the CPU starts it cycle.. Does not end well :)

In fact on the TF536 I did, I think I only had a single CPU clock (50mhz) delay on /AS30 and nothing else. Of course this is not emulating the 68000 bus cycle. But it solves no end of problems with trying to synchronise things up. The clock delay was just simply there to allow GLUE to actually register nothing was using the bus " at some point" So it would release DTACK etc. GLUE only needs something like 20ns for that. So a CPU clock was good enough.

At the end of the day, the CPU is held off from accessing RAM or whatever if it is not allowed to access RAM anyway.
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: Fri Oct 29, 2021 9:34 pm In fact on the TF536 I did, I think I only had a single CPU clock (50mhz) delay on /AS30 and nothing else. Of course this is not emulating the 68000 bus cycle. But it solves no end of problems with trying to synchronise things up. The clock delay was just simply there to allow GLUE to actually register nothing was using the bus " at some point" So it would release DTACK etc. GLUE only needs something like 20ns for that. So a CPU clock was good enough.
The problem here, of course, is that I'm not just trying to fool GLUE (or COMBEL), but a completely separate bus slave in the DSP. It doesn't go through COMBEL at all. It's all GAL-based.

Which is why everything else works bar the bloody DSP!

I have managed to fool COMBEL fine (with two different approaches -- synchronous clock and the delayed AS/DTACK method). :-)

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
Post Reply

Return to “HARDWARE DISCUSSIONS”