Slow DSP investigation with DFB1

[Badwolf]

With the recent reports of problems with Cubase Audio when doing D2D work and persistent trouble with Acetracker I think it's time to do some more investigation into DSP accesses with DFB1.

Armed with a new DSP host port testing program from @dml, the knowledge there's an intentional slight delay to address strobe assertion when accessing the DSP and measurably longer chip select assertion on the DSP itself when using DFB1, I've hitched up the logic analyser and started probing about.

The first thing that I've stumbled upon is that I don't understand how the DSP_DS signal is generated by U68.

From the GAL listings on dev-docs we have the line:-

Code: Select all

 DSPDS      = AS * DSP * DL1AS * /A5 * /A4 * /A3;

Here are the pertinent declarations. AS, DSP and the address lines are inputs:

Code: Select all

	/AS		=  3,
	/DSP		=  6,
	A5		=  7,
	A4		=  8,
	A3		=  9,
	
	DL1AS.r		= 15,
	/DSPDS.t	= 14,

DL1AS is a register and DSPDS is combinational.

Interestingly AS, DSP, and DSPDS are declared as negative assertion, but DL1AS isn't. I don't know quite what effect that has, but presumably not what I was expecting as when we look at the stock Falcon's trace:

Screenshot 2025-10-30 at 20.35.41.png (115.82 KiB) Viewed 334 times

We can see that DL1AS goes low (I wanted to say asserts, but I don't know if that's right with the declaration above?) at the first positive clock edge after AS asserts. As expected.

We can then see that DSPDS asserts 20ns or less afterwards. This makes sense as DSP is low throughout and we can assume the address lines are behaving if the DSP is being triggered at all.

So far so good -- although I'm still a little confused by the DL1AS seemingly being treated as negative assertion in that equation when it's not declared as such, but I'm not exactly au fait with CUPL.


However where I'm really confused and asking for help is when we turn our attention to what the trace looks like with DFB1 enabled:-

Screenshot 2025-10-30 at 20.41.43.png (99.7 KiB) Viewed 334 times

Firstly it's obvious that the whole DSP host access cycle is much slower. About half the speed, in fact. This, I suspect, is the root of the problem we're seeing with Acetracker et al, but that's not the nub of my question. Yet.

We can see that, sure enough, DL1AS goes low at the next positive edge after AS goes low, but the next step, DSPDS going low, doesn't occur immediately. It's delayed about 80ns for no reason I can see.

It's a combinational output, always enabled with the key terms met (OK, technically I've not shown the address lines to keep the sample rate up, but they're all measured low).

WTF? Anyone with a better understanding of GALS, CUPL or the system in general give me any idea as to what's afoot here?

Is the U68 dump accurate, do we know? Could there be any other reason I'm missing?

This probably won't be the final smoking gun, but I'd say it may be up to 50% of the problem.

Cheers,

BW

[exxos]

I don't think that's CUPL code. I did *somewhere* write down the syntax conversions on the forum.. Will try and find it so it makes more sense..

Though this is why I thought the problem is the GAL clock would be out of sync with the system clock because of the PLD delays on the DFB1. But I need to look at if the clock is even being used yet...

EDIT:

Asked grok (yeah so sue me)

Code: Select all

/*
  WinCUPL translation of:
  FALCON 030 V1.0 - U68 - May 30, 1997
  Original: GAL16V8
  Notes:
   - Original used names like "/BGK" to indicate active-low nets.
     For legal WinCUPL identifiers I removed leading slashes; see the pin map comments below.
   - Tristate (.t) / registered (.r) annotations from the original are preserved as comments.
*/

Name     = F30_U68;
PartNo   = 16V8;
Device   = 16V8;

/* Pin map from original (left side is original name, right side is this file's identifier)
   Original pin names with leading "/" were active-low in your listing.
   Format: original_name  => this_identifier   (pin number)
*/
 /* /BGK    => BGK       (pin 2)    - originally named "/BGK" (active-low) */
 /* /AS     => AS        (pin 3)    - originally "/AS" (active-low) */
 /* /BG30   => BG30      (pin 4)    - originally "/BG30" (active-low) */
 /* AXDSP   => AXDSP     (pin 5)    */
 /* /DSP    => DSP       (pin 6)    - originally "/DSP" (active-low) */
 /* A5      => A5        (pin 7)    */
 /* A4      => A4        (pin 8)    */
 /* A3      => A3        (pin 9)    */

/* Outputs (original had tristate/register annotations)
   HIGHZ.t  = pin 19   -> HIGHZ (tristate control originally)
   EDSP.t   = pin 18   -> EDSP (tristate)
   DLYAS.r  = pin 17   -> DLYAS (registered)
   DL2AS.r  = pin 16   -> DL2AS (registered)
   DL1AS.r  = pin 15   -> DL1AS (registered)
   /DSPDS.t = pin 14   -> DSPDS (tristate, original name had leading '/')
   /BMODE.t = pin 13   -> BMODE (tristate, original name had leading '/')
   /CPUBG.t = pin 12   -> CPUBG (tristate, original name had leading '/')
*/

/* Declare inputs and outputs */
Inputs  = BGK, AS, BG30, AXDSP, DSP, A5, A4, A3;
Outputs = HIGHZ, EDSP, DLYAS, DL2AS, DL1AS, DSPDS, BMODE, CPUBG;

/* Boolean equations
   - Keep combinational feedback exactly as original (will infer latches where necessary).
   - Use ! for NOT, & for AND, | for OR.
*/

/* HIGHZ.e = VCC; HIGHZ = CPUBG + BGK * HIGHZ + AS * HIGHZ; */
HIGHZ = CPUBG | (BGK & HIGHZ) | (AS & HIGHZ);

/* EDSP.e = VCC;
   EDSP = AS * AXDSP * DSP * /A5 * /A4 * /A3;
   Note: original used /A5 /A4 /A3 - so here those are inverted with !
*/
EDSP = AS & AXDSP & DSP & !A5 & !A4 & !A3;

/* DLYAS = AS * DL1AS; */
DLYAS = AS & DL1AS;

/* DL2AS = DL1AS; */
DL2AS = DL1AS;

/* DL1AS = AS; */
DL1AS = AS;

/* DSPDS.e = VCC;
   DSPDS = AS * DSP * DL1AS * /A5 * /A4 * /A3;
*/
DSPDS = AS & DSP & DL1AS & !A5 & !A4 & !A3;

/* BMODE.e = /HIGHZ;
   BMODE = /HIGHZ;
   (original uses inverted HIGHZ to drive BMODE)
*/
BMODE = !HIGHZ;

/* CPUBG.e = VCC;
   CPUBG = BG30 * /AS * /DL2AS;
   (both AS and DL2AS inverted in original)
*/
CPUBG = BG30 & !AS & !DL2AS;

END

So DL1AS just seems to be a pulse stretching code for AS.

Normally the GAL clock is used with flipflop registers like FF.d or something like like.. so as there doesn't seem to be any.. can't be clock related. But .t can be a toggle register in CUPL. Which would be clocked. But I assume no clocked events in that GAL ...

Might make it easier to label the ns on your images... But as they just seem to be GAL propagation delays, they shouldn't change...

[Badwolf]

Though this is why I thought the problem is the GAL clock would be out of sync with the system clock because of the PLD delays on the DFB1. But I need to look at if the clock is even being used yet...

All the .r (registers) are clocked, I think. .T ones are tristate combinatorial.

Asked grok (yeah so sue me)
DSPDS = AS & DSP & DL1AS & !A5 & !A4 & !A3;

This would seem to imply DSPDS is active any time AS is high -- ie most of the time.

I think Grok can do one.

BW

[exxos]

All the .r (registers) are clocked, I think.

Yeah can you scope the other DL lines ? Can confirm if they are in sync with the clock then..

Then you could lift pin 1 and connect to 32MHz and see what dies

EDIT:

Another idea , is do a minimal DFB1X firmware, hardwire the CPU clock to the system clock.. This way the CPU and system 16Mhz are in sync. I was going to try that at some point to see if that told us anything.

[Badwolf]

All the .r (registers) are clocked, I think.

Yeah can you scope the other DL lines ? Can confirm if they are in sync with the clock then..

Then you could lift pin 1 and connect to 32MHz and see what dies

I don't actually think clock skew is a problem. AS1DLY follows exactly the path we'd expect and the other ones aren't in the pertinent equation. The GALs trigger on the rising edge of the clock, which is normally far away from any signals even with a slight skew.

Related to that, here's what happens if the DSP AS hold off code is removed from DFB1's firmware.

Screenshot 2025-10-30 at 21.22.03.png (146.84 KiB) Viewed 310 times

The AS->DL1AS delay is now down to (under) half a clock cycle but 'proper' DSPDS still fails to assert on time (the arrow).

The circles highlight the glitches (presumably) from previous assertions. Chaos.

So I'm also inclined to think the AS holdoff is unlikely a primary factor either.

I'm edging towards the opinion that those equations aren't actually correct and there is (at least) another term in the DSPDS line.

BW

[exxos]

I'm edging towards the opinion that those equations aren't actually correct and there is (at least) another term in the DSPDS line.

I suspected that with the MSTE GALs. I tried burning one from such recovered files and the MSTE was unstable afterwards.

I could try and convert and compile that GAL to CUPL and see if it behaves the same ? There are likely 25ns GAL delays in the mix as well..

Also your CLK is all over the place, sampling rate issues on the LA ? So we might not be seeing proper readings anyway. I'd prefer seeing such timings on a scope...

[Badwolf]

I'm edging towards the opinion that those equations aren't actually correct and there is (at least) another term in the DSPDS line.

I could try and convert and compile that GAL to CUPL and see if it behaves the same ? There are likely 25ns GAL delays in the mix as well..

Also your CLK is all over the place, sampling rate issues on the LA ? So we might not be seeing proper readings anyway. I'd prefer seeing such timings on a scope...

It's only a 50MHz sampling rate (20ns), but we're dealing with unexplained delays of 100, 120ns. The scope can't monitor all the equation inputs and will still tell me it's between 100 and 120ns late.

If it gets down to it I'll get the big LA out which can do 150MHz, IIRC, but I don't think it's needed at this stage.

BW

[Badwolf]

Oops. Broke a couple of legs off U44. Will have to call it a night there.

Rats.

BW

[dml]

Is the U68 dump accurate, do we know? Could there be any other reason I'm missing?

You could perhaps flash one and confirm it behaves the same as the original.

I suspect the dumps are good - or at least, there are good dumps available and I think the originals are not protected from readouts. I flashed the whole set at one point and still have them in foam somewhere - or they might be in one of the machines. I could try to locate them and run the test with those?

[Badwolf]

Is the U68 dump accurate, do we know? Could there be any other reason I'm missing?

You could perhaps flash one and confirm it behaves the same as the original.

Yes, good idea. I think I have some GALs lying around from when I thought my other Falcon board was dead. There are JEDs in that ZIP too which might work even if we can't compile the source.

Incidentally I was using the GALs from that other Falcon board in mine as I swapped them during testing and never swapped back. What I thought was a bad socket may have been a bad pin. Basically the GND pin on U44 fell off when I took the chip out. One of the other pins is shorter than the rest and the DSPDS pin which I was interested in was so brittle it snapped when I tried to lift it.

So I hope the JED is alright for U44 as this one is very much on its last legs.

I suspect the dumps are good - or at least, there are good dumps available and I think the originals are not protected from readouts. I flashed the whole set at one point and still have them in foam somewhere - or they might be in one of the machines. I could try to locate them and run the test with those?

Thanks, but I'm not sure that would be needed yet. It would be very nice to be able to compile that file into a flashable image and see if it behaves the same, though.

I need to figure out what software it is. I had assumed WinCUPL, but Exxos has me worried it's not now. U44's in a completely different language too!

BW