Slow DSP investigation with DFB1

[pakman]

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?

Just checked: U68.GAL and U68.JED don't match.
No way that U68.JED has been created from U68.GAL in this archive.
Logic equations for /DSPDS are different.

In order to get U68.JED the equation for /DSPDS need to be changed as:

Code: Select all

 DSPDS    = !HIGHZ & AS         & DSP & DL1AS & !A5 & !A4 & !A3
          #  HIGHZ & AS & DL2AS & DSP         & !A5 & !A4 & !A3;

Question: Which one (JED or GAL) is reflecting the real thing..

[dml]

I was wondering about this after BW's last response - I flashed from the JEDs only, not the other files.

So the JEDs seem to be good. The rest.... maybe not so much?

[Badwolf]

EDIT: Sorry, I missed the two posts above before I wrote this. Looks like perhaps that 3ns is important, then?



So I've tried a few things.

1) dump U68 using my TL866ii+.

This seems to work and returns reproducible results, but they don't look quite right.

Screenshot 2025-10-31 at 21.22.29.png

That's all ones, up until the end there. Yeah, nah.

Anyway, I tried flashing that to my GAL16V8D-15s. No dice. Won't boot.


2) use the U68.JED in the F030GALs zip.

That looks plausible with 1s and 0s mixed up a bit throughout, but similarly no dice.


Both methods verify OK and nothing's smoking, but I don't know enough about this sort of thing to work out where in the chain the problem now lies.

Could it be my 15ns GALs aren't fast enough? The Originals carry a '12' figure. Is that ns? Are my 15ns chips far too slow for this?

@dml and anyone else who's replaced GALs: what's your experience here, please?

Ta,

BW

[Badwolf]

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?

Just checked: U68.GAL and U68.JED don't match.
No way that U68.JED has been created from U68.GAL in this archive.
Logic equations for /DSPDS are different.

In order to get U68.JED the equation for /DSPDS need to be changed as:

Code: Select all

 DSPDS    = !HIGHZ & AS         & DSP & DL1AS & !A5 & !A4 & !A3
          #  HIGHZ & AS & DL2AS & DSP         & !A5 & !A4 & !A3;

Question: Which one (JED or GAL) is reflecting the real thing..

@pakman! You're a legend! Thanks very much for this.

I don't know how you did it, but if you'd like to elaborate, I'd love to see the full equations for the JED. I've spent a good chunk of time this afternoon trying to refactor the GAL listing into something WinCUPL can synthesise and failed. If they're just nonsense that makes sense.

What makes even more sense is the equation you've posted does indeed reflect what I'm measuring. There's an additional clock cycle delay on the DSP line when the HIGHZ mode is active. ie. when DFB1 is the bus master.

That's great insomuch as we can see one of the issues. It's less great in that there may not be a trivial fix.

Cheers,

BW

[dml]

Could it be my 15ns GALs aren't fast enough? The Originals carry a '12' figure. Is that ns? Are my 15ns chips far too slow for this?
@dml and anyone else who's replaced GALs: what's your experience here, please?

I'll check the ones I used and get back to you. I can even try booting with the U68 in place tomorrow.

(I used Lattice GALs but I don't remember the speed)

[dml]

Plot twist....

gals.jpg

The homebrew GALs are in my test machine. Apparently it's the Atari GALs which are stored in foam...

Anyway these certainly are faster chips. Possibly I was aiming for 12ns or better and found these...

[Badwolf]

Anyway these certainly are faster chips. Possibly I was aiming for 12ns or better and found these...

OK, grand. Cheers.

That's the next plan of attack then!

Here's my thinking: if I can get the GALs programming and working, the 'plug and play' experience to solve the DSP speed issue may simply be to distribute a replacement U68!

BW

[dml]

Here's my thinking: if I can get the GALs programming and working, the 'plug and play' experience to solve the DSP speed issue may simply be to distribute a replacement U68!

!

That might work and also avoids JTAG parties.

But if that did work, could it still work with the DFB1 jumpered in 'disabled' mode? Or too early to even guess?

[Badwolf]

!
That might work and also avoids JTAG parties.
But if that did work, could it still work with the DFB1 jumpered in 'disabled' mode? Or too early to even guess?

Well, that equation posted by pakman basically has an expansion port speed and a normal speed. We'd just be doing the normal speed for both.

It may not work, there may be a good reason why that delay's there, but I'm casting my mind back to the dim and distant past when I was researching how to do a board like DFB1 and the BMODE (bus mode) flag sticks in my mind as indicating when things are slowed down to emulate a 68000 bus. The expansion port is described as a 68000 bus. I never really identified what exactly was slowed down.

In a lack of coincidence BMODE is asserted when bus mastery is relinquished and it's driven by the HIGHZ flag.

I'm thinking *this* is that slowing down to which it referred. Could it potentially affect DMA? I can't see how, but maybe, sure. Will I jolly well attempt it? Also sure. :)

BW

[pakman]

I don't know how you did it, but if you'd like to elaborate, I'd love to see the full equations for the JED. I've spent a good chunk of time this afternoon trying to refactor the GAL listing into something WinCUPL can synthesise and failed. If they're just nonsense that makes sense.

See attachment. You will find:

• F030_U68.pld source file for WinCUPL (with corrections)
• F030_U68.jed compiled from this source