Slow DSP investigation with DFB1

[whomper]

CUBASE loads, but won't play anything unless I connect up my SCSI drive, and can't be bothered tonight

This looks great! Finally I may be working with DFB1X enabled and Cubase after all. To date I need to disable DFB1X when I work with Cubase.

[exxos]

This looks great! Finally I may be working with DFB1X enabled and Cubase after all. To date I need to disable DFB1X when I work with Cubase.

Would be useful if you could test I probably won't have time the next few weeks to mess about with it again.

[whomper]

I have the programmer but have only F16V8BQL-15, both ATF and 15ns. It may seem this part's performance is not enough.

I'll need to order GALs, so will take some time.

[iluvator]

I can confirm that Cubase audio is now performing exactly as it should, with no issues whatsoever.
Before applying the fixes, I was still able to record and play back audio, but I experienced audio clicks and pops. Visually, I was also getting a few strange random horizontal bars and dots on the main screen.
Interestingly, I first tried replacing the GAL without updating the DFB1X firmware. Even at this stage, all the CAF issues disappeared.
Even more interestingly, I used a 15 ns GAL, as that was the only one I had available. At this point, my DSPBENCH results were higher than those obtained with the original GAL, but still somewhere in between, rather than reaching the 99–102% figures.
I subsequently updated the DFB1X firmware to v1.06, and the DSPBENCH results were then exactly the same as those reported by EXXOS.
And, of course, Cubase still records and plays back flawlessly!
Congratulations to everyone involved in making this happen!

[exxos]

I can confirm that Cubase audio is now performing exactly as it should, with no issues whatsoever.

Awesome !

Before applying the fixes, I was still able to record and play back audio, but I experienced audio clicks and pops. Visually, I was also getting a few strange random horizontal bars and dots on the main screen.

Do you have a clock patch because that sounds like a clock patch issue.

Interestingly, I first tried replacing the GAL without updating the DFB1X firmware. Even at this stage, all the CAF issues disappeared.
Even more interestingly, I used a 15 ns GAL, as that was the only one I had available. At this point, my DSPBENCH results were higher than those obtained with the original GAL, but still somewhere in between, rather than reaching the 99–102% figures.
I subsequently updated the DFB1X firmware to v1.06, and the DSPBENCH results were then exactly the same as those reported by EXXOS.

It sounds about right because timings have to be changed in the DFB1X and the GAL..

And, of course, Cubase still records and plays back flawlessly!
Congratulations to everyone involved in making this happen!

@Badwolf was the powerhouse behind that work.

[viking272]

This is great news!

@exxos, do you sell or can you sell the u68 GAL?
I have searched the store but couldn’t see it.

[exxos]

@exxos, do you sell or can you sell the u68 GAL?
I have searched the store but couldn’t see it.

Its not on sale on my store.. Partly because I can't find any GALs. I've got the Atmel ones in my mouser basket but i had given up trying to program them as the power down pin was always enabled. But I've got a different programmer now. So worth another try.

Secondly. I'm not totally sure who's worked on the GAL code. It looks like the reverse engineering came from the lightning team via @Pacman. But It's not my work to sell and i wouldn't without permission.

But also it needs more testing yet and I suggest people just reprogram their falcon gal. That's what I did.

[Badwolf]

Holger, @pakman (pakman with a K not a C), did the reverse engineering from the original chip data and provided me with the test JEDs I sent you.

I used these as they were closer to the originals than the work I'd previously done but I had previously got to 100% just fiddling with the equations available on dev-docs (viewtopic.php?t=8042&start=40#p136438).

Pakman verified those equations were actually wrong (at least one intermediate pin is inverted from measured behaviour), but users have been flashing those chips for years, so I suspect it cancels out within the logic somewhere.

I chose to go with Holger's equations for this test as I just trust them more.

We can ask for permission to ship programmed gals with DFB1Xs, but I've not heard back from him for a long time. I hope he's OK.

BW