exxos's Atari, Amiga & retro forum

It seems like it might be enough to test the updated GAL on its own then, in a vanilla machine and just try a bunch of things including the speculative bus-mastery (blitter, SCSI, floppy etc.) although that probably needs custom tests made.

If no existing software gets upset - except demos for timing reasons alone - then probably its 'okay' even if there are weird outlier problem cases like blitting the dsp (I'm not sure Atari would have worried about that one anyway).

I will put a note on my site later with the updated firmwares.

Was just looking at GALs.. Hard to really find. Problem being, most are fake speeds now. Finding a reliable source of -12 or -10 could be a problem for people. I went though all this with my STE boosters and 22V10D-7 GALS. Most were fake, and 100 were "dummy chips" and I ended up having to speed test every single one.. which was no fun at all.

exxos wrote: 29 Oct 2026 13:04 Was just looking at GALs.. Hard to really find.

Is the one Suavek identified and used in ReFalcon an option? Looking at his BOM on GitHub he has:

C302833-001 Atari EE PLD 7NS U68 G16V8 1 Microchip ATF16V8C-7PU

This seems to fit?
https://www.mouser.co.uk/en/ProductDeta ... AF16V8C7PU

viking272 wrote: 29 Oct 2026 13:17 Is the one Suavek identified and used in ReFalcon an option? Looking at his BOM on GitHub he has:

C302833-001 Atari EE PLD 7NS U68 G16V8 1 Microchip ATF16V8C-7PU

This seems to fit?
https://www.mouser.co.uk/en/ProductDeta ... AF16V8C7PU

Right, problem is, I tried those on my STE boosters (22V10) and could never get them to work regardless of what I did. IIRC pin 4 is a power down pin and I couldn't find anyway to avoid that issue. There seemed to be nothing in the PLD or programmer settings to stop the power down feature. In the end, I just avoided using pin 4, but later avoid the ATF versions as they just didn't seem to give as clean edges as the older Lattice chips.

So my advice would be to avoid those as if I have run into problems, others may as well and then likely their falcon will start doing weird things..

Found what I said before..
viewtopic.php?t=46&start=390#p14616

Yep, I think Atmel still make GAL equivalents.


BW

I've ran DFB1X in DISABLED mode (new U68 still in play) , GB6, DSPBENCH look as expected. But they may not be looking for the right things anyway.

Trying ACE TRACKER, now oddly I am now hearing some "ticking" randomly in the music which sounds like "static pops".

DFB1X ENABLED. ACE plays fine.

DFB1X DISABLED - ticking is back even without loading any song..

So that poses a bit of a problem doesn't it.. :roll:

EDIT:

Now I see that "black screen of death" for the first time ! ohhh actually moving the mouse and its back.. some sort of built in screensaver ?!

EDIT: Tried what I think is the original U68 firmware and still ticking in the audio.. weird..

Will "borrow" the U68 out of the other falcon I have here to see if that does the same..Yes it does :WTF:

So, you need a GAL which waits one bus cycle when selecting the DSP then, the same as the original does with the CPU?

stephen_usher wrote: 29 Oct 2026 14:49 So, you need a GAL which waits one bus cycle when selecting the DSP then, the same as the original does with the CPU?

False alarm. Removing the 10ns extra SDMA delay on my clock patch seemed to fix the problem.

Current DFB1X firmware V106 and U68 updates are now on my main page for people to try.

https://www.exxosforum.co.uk/atari/last ... ex.htm#DSP

So, how do you write the firmware on the DFB1X?