Slow DSP investigation with DFB1

[exxos]

I'm almost ready to give up on this retirement lark and go back to work for a rest!

I hear'ya there !!

[Badwolf]

So a bit more work on this last night.

IMG_9406.jpeg (253.8 KiB) Viewed 175 times

The good news is that, by ignoring the feedback from the motherboard systems (the GALs) and just calculating my own DSACK0, I was able to happily pass the DSPBENCH tests and play a song on ACETracker.

It's still not scoring 100% yet, but I think I know what that is.

Also, this is using my modified GAL. I need to think about whether it'll work with the original as the DS strobe may simply happen too late.

My main source of concern is what corner cases does this approach not handle? Having worked through almost all the GAL equations I think it's pretty much blindly deterministic -- there's no hidden delays for video RAM access, for example -- but there may be for interrupts? I'm concerned by the IRQ/IACK dependency in the DSACK0 generation on U44. I'm not sure I understand it yet.

As I currently interpret it, it's just a gate to stop the DSP cycle stomping all over an interrupt in progress -- but I need to think through the ramifications of that. Why would it be needed in the first place? Does it therefore actually do something else?

Anyway, I hope this ends up being some progress!

BW

[dml]

That's an impressive update! O_O

As for the unknown dependency you describe - difficult to say. The DSP is tied in multiple ways for different kinds of exchanges, with hostport polling being only one way. There is also DMA in-and-out and hostport interrupts on both DSP and CPU sides. I'm not sure if which software uses all of these together (maybe ACE does?).

The DMA crossbar configuration also has handshaking and free-running modes - although, I think it is a sparse mapping so both modes are not available for every device-device connection available.

I suppose the only way to tell if any of this matters - without reverse engineering the purpose of every GAL signal (?) - would be to test as much as possible, maybe including Cubase Audio since it will probably be doing stuff nothing else is.

I realise this was not the most helpful of answers but OTOH... if ACE tracker is working and the new DSPBENCH is also working - probably a very good indication that other things will work too. I could probably add a host interrupt test to DSPBENCH but I'll need time to do that.

(Don't panic if BadMooD or SVO don't magically work now since chances to the DFB1 hostport bandwidth could easily skew that - I calibrated them against the DFB1 behaviour I get from my own machine).

[dml]

Forgot to add.... I would be surprised if you could hit 100% with any fixes unless the DFB1 clock is synchronous at a minimum, which would mean a fixed 48MHz clock. So I wouldn't get too bogged down in chasing that, versus making sure any improvement is software-safe ... the AB40 and CT60 also can't hit 100% I think, for various other reasons.

[Badwolf]

So, flushed with success last night and with a bit of a swagger I set about modifying the firmware to squeeze as many nanoseconds out of the 'stock' GAL configuration as possible.

Things have not gone so superbly! I'm really running into the effects of that dependency on the additional clock delay on the AS line when in 'HIGHZ' mode.

If I allow a new cycle to start when it ought I get a premature CS assertion as the damned thing is still using information from 125ns ago. If I trim too much off the far end data transfer is not stable as the CS assertion is too short (~20ns) as it has to wait that 125 before it commences. A little from column A and little from column B just means mess everywhere.

So I'm starting to come back to considering replacement GALs. But then how would I tell DFB1 that it can wind up the wick on the transfer speeds? Repurpose one of the option headers? That'd break backwards compatibility. Add a register? That would need another AUTO folder program.

Hmm.

I would very much like to know how CT60 handles all this, should anyone be willing to get an LA on it & if Doug's got the 060 build of the extended DSPBENCH with host port statistics publishable yet? (@dml?)

More thought required.

BW

[dml]

I'll try to set up the CT60 in the next day or two and make sure the test runs.

I don't have a LA so probably can't help there. I could do some very basic probing but I only have older test gear (think '90s CRTs' or earlier), not the newer fancy Rigol/Keysight stuff with big sample buffers - so probably someone else can do a far better job here...

[dml]

So that was annoying.

I set up the CT63 to debug this and I was just about there - and the CT63 is now dead.

Not sure what's wrong with it but it won't boot in 060 mode anymore - only 030 mode works.

The last thing I did was use the CT CPX to configure the NVRAM to boot at 640x400 because it was stuck in low res and making things difficult for boot testing. After that, it booted with 'CTCM not found' and after that single semi-successful boot, it now won't boot the CT60 splash screen anymore, just no display like it's stuck in reset.

So I can upload the last build that seemed to work but I won't be able to do anything else with it apparently! At least, not anytime soon.

[dml]

Here's the last work-in-progress version that (still) works on a plain Falcon but was also seeming to get through all the tests on the CT63 before it died.

Since the 060 was not exactly set up properly I can't be sure it was running with the cache enabled during the test so YMMV....

[dml]

On the CT63 - I got a splashscreen and half of a boot message while pressing down on the lower-left CPLD. The one I had problems with before.

Nnnnggghh!!!!!

Don't have time for this today - rabbithole for a different weekend.

[dml]

Have been messing with this to see if I can at least record one capture from the 060.

Now it's booting again but the CPX is complaining the temperature sensor cannot be read and shows 0'c. That's new.

Also the CTCM can't be changed from 66MHz (?) I set it to 80MHz, save it and reboot and its 66 on the splash screen.

I tried boot 1.05 and configured the CTCM without the CPX - and again I get a complaint about the temperature reading and still can't change the CTCM from 66. I have no idea what's wrong and I am running out of time and patience with it.

I can get to the desktop for now and will try to upload a capture but who knows if its correct or not!