I think this is a much better approach than forcing buyers to flash their own GALs.
Can all registered uses please login, even just for a few minutes..
It helps build a picture where our "good traffic" is coming from..
Thanks :)
It helps build a picture where our "good traffic" is coming from..
Thanks :)
Slow DSP investigation with DFB1
Re: Slow DSP investigation with DFB1
Sounds plausible. Centurbo II (which also accelerates DSP, data bus, CPU etc) basically pulled all GALs out and replaced their functionality on its own board.
I think this is a much better approach than forcing buyers to flash their own GALs.
I think this is a much better approach than forcing buyers to flash their own GALs.
Re: Slow DSP investigation with DFB1
Well, it didn't take long for someone to find something to complain about. Was expecting something from you like this in fact already.mikro wrote: Thu Oct 29, 2026 3:27 am Sounds plausible. Centurbo II (which also accelerates DSP, data bus, CPU etc) basically pulled all GALs out and replaced their functionality on its own board.
I think this is a much better approach than forcing buyers to flash their own GALs.![]()
Nobody is forcing anyone to flash anything. The DFB1X works exactly as it always has without it. This is an optional fix for an Atari design quirk that also hits the CT60, and it took BW, pakman and a fair few evenings to track down.
As for the Centurbo II approach, ripping out all the GALs and replacing them with a board and bodge wires is hardly what I'd call elegant. Swapping one socketed GAL keeps the machine original, costs pennies, takes seconds, and can be put back to stock just as quickly. It fixes the problem at the source, in the chip where Atari put the extra delay in the first place. A stock machine without a booster behaves exactly the same with it fitted.
Personally I'd rather change one chip than redesign half the motherboard, but each to their own.
Re: Slow DSP investigation with DFB1
The details are interesting.
A two-clock delay for a CPU on the expansion bus might have been accidental but we don't really know. It seems like a one-clock delay though was at least intentional since it is how the onboard CPU sees things and probably Atari was well aware of it.
So what now might break with a zero-clock delay? Getting ACE to work is already a good indicator of safety but it would be interesting to see if anything else gets upset with this change.
There could have been some kind of interaction with Videl or DMA which needed an extra wait (zero delay could put glitches on the screen or onto SCSI if the DSP is selected without delay?). I'm speculating of course but it's the kind of thing that would have them bodge a waitstate into the GALs before calling it good.
Does this GAL patch work equally well on a Falcon without anything on the expansion bus or does it cause problems? What effect does it have there?
(BTW I'm not criticising the work/result - which is great
I'm just curious to know if Atari was trying to address a problem here or if it just fell out of other changes. And the new GAL FW doesn't work on a vanilla machine I suppose that could be part of the answer at least)
A two-clock delay for a CPU on the expansion bus might have been accidental but we don't really know. It seems like a one-clock delay though was at least intentional since it is how the onboard CPU sees things and probably Atari was well aware of it.
So what now might break with a zero-clock delay? Getting ACE to work is already a good indicator of safety but it would be interesting to see if anything else gets upset with this change.
There could have been some kind of interaction with Videl or DMA which needed an extra wait (zero delay could put glitches on the screen or onto SCSI if the DSP is selected without delay?). I'm speculating of course but it's the kind of thing that would have them bodge a waitstate into the GALs before calling it good.
Does this GAL patch work equally well on a Falcon without anything on the expansion bus or does it cause problems? What effect does it have there?
(BTW I'm not criticising the work/result - which is great
d:m:l
BadMooD d/l: https://www.leonik.net/dml/sec_bm.py
SVO30 d/l: https://www.leonik.net/dml/sec_svo30.py
Q2 engine d/l: https://www.leonik.net/dml/sec_q2.py
AGT project: https://www.leonik.net/dml/sec_agt.py
Atari page: http://www.leonik.net/dml/sec_atari.py
YT: https://www.youtube.com/@dmlTPT
BadMooD d/l: https://www.leonik.net/dml/sec_bm.py
SVO30 d/l: https://www.leonik.net/dml/sec_svo30.py
Q2 engine d/l: https://www.leonik.net/dml/sec_q2.py
AGT project: https://www.leonik.net/dml/sec_agt.py
Atari page: http://www.leonik.net/dml/sec_atari.py
YT: https://www.youtube.com/@dmlTPT
