Slow DSP investigation with DFB1

[stephen_usher]

Let's face it, the Falcon030 was rushed out the door as a minimally viable product before it had really come out of prototype stage to try to save the company.

[charon030]

On atari-home.de a user confirmed that the same issue exists on the CT60:

https://forum.atari-home.de/index.php/t ... #msg275361

[exxos]

On atari-home.de a user confirmed that the same issue exists on the CT60:

https://forum.atari-home.de/index.php/t ... #msg275361

Thanks for sharing that.

There was something I saw somewhere about some logic from the CT2 or something which may help solve the problem ? Not had chance to read a lot of posts lately.

[Badwolf]

• The issue is per Atari's design;
• It will affect any solderless accelerators (unless they happen to also replace a GAL) -- it's been observed on the CT60;
• @pakman has been very kind into looking into what can be done on the GAL side and I have some work to do on that front, but I've not had time to do it yet;
• The DSP isn't 'running slow' but communication to the DSP is slower than usual. Any program that relies on tight timing on the CPU against the DSP could be affected;
• DFB1(X) has a disable jumper to accomodate such programs. This is inelegant, but effective.

BW

[viking272]

Hi BW,

There were a few elements from the above list that were being looked at? I wonder if there was any further findings?

[Badwolf]

There were a few elements from the above list that were being looked at? I wonder if there was any further findings?

I kind of reached a bit of a dead end, to be honest.

Basically, with Pakman's help, I had a combination of DFB1 firmware mods and GAL mods that would show 100% results on the host port test and almost full speed on all the other tests too (I suspect some are just down a little because of the bus arbitration), but effectively the problem as discovered was eliminated.

However I couldn't verify that it was working because unfortunately Acetracker doesn't like the clock switching and so despite not necessarily hitting a DSP limit any more, the screen mode changes that accompany selecting music file normally cause the screen to blank rendering the test impossible.

Cubase Audio was the other application we'd seen problems with. I couldn't make the cracked version I had work properly anyway. I didn't have the DSP dongle and I didn't know what I was doing anyway.

I don't remember if I actually got around to setting up the SCSI image. It's possible that's the only real issue to testing it, but I think it was unstable under acceleration anyway (again, possibly the clock switching).

On top of that the firmware changes necessary weren't backwards compatible with an unmodified GAL meaning they'd need to use a jumper. Which means repurposing an existing one. Which again affects backwards compatibility.

Certainly I can put together some test firmware and a GAL Jed for U68 (I think) if anyone else would like to give it a try, but with the two main use cases being a bit hit and miss anyway, I didn't think it was really worth chasing hard at the moment.

A user would have to have 1) DFB1 (not X), 2) the ability to program its firmware 3) a spare GAL16V8-15 and 4) the ability to program said GAL.

But tap me up again here if you have all the above and would like to try it out!

Cheers,

BW