Slow DSP investigation with DFB1

[ijor]

It may not work, there may be a good reason why that delay's there, but I'm casting my mind back to the dim and distant past when I was researching how to do a board like DFB1 and the BMODE (bus mode) flag sticks in my mind as indicating when things are slowed down to emulate a 68000 bus. The expansion port is described as a 68000 bus. I never really identified what exactly was slowed down.

Bus cycles with BMODE signaling a "classic" 68K mode take one extra clock cycle. Combel asserts DTACK one cycle later. However I'm not sure if this is a direct consequence of BMODE being high, or just because AS is asserted half cycle later.

[Badwolf]

See attachment. You will find:

• F030_U68.pld source file for WinCUPL (with corrections)
• F030_U68.jed compiled from this source

Thank you very much @pakman! I'll have a play with those as soon as my faster GAL arrives.

BW

[Badwolf]

Bus cycles with BMODE signaling a "classic" 68K mode take one extra clock cycle. Combel asserts DTACK one cycle later. However I'm not sure if this is a direct consequence of BMODE being high, or just because AS is asserted half cycle later.

Thanks, @ijor. I think this may the first time I've actually seen that occurring.

I think the slow down we're seeing on the DSP host port is 50% down to the extra AS delay cycle on the chip select line and 50% down to this delay to dtack.

I assume BMODE is a active low as it's driven open collector. That does mean I can't force it high. But perhaps more GAL shenanigans might prove the point and open the door to a fix, nonetheless.

BW

[ijor]

Thanks, @ijor. I think this may the first time I've actually seen that occurring.
I think the slow down we're seeing on the DSP host port is 50% down to the extra AS delay cycle on the chip select line and 50% down to this delay to dtack.
I assume BMODE is a active low as it's driven open collector. That does mean I can't force it high. But perhaps more GAL shenanigans might prove the point and open the door to a fix, nonetheless.

BMODE is activated (high) in Blitter transactions, probably on all DMA transactions, but didn't check. Active low or high in this case is a matter of convention. I assume the GAL uses XBGK for this purpose, but didn't check the equations.

[exxos]

Has anyone considered if the GAL code is a earlier or later version of U68 ? I wonder after looking at the file dates.. Maybe meaningless but maybe worth a try to see what happens ?

Capture.PNG

Inside the files themselves

JED - 03.06.1997, 14:55:08
GAL - FALCON 030 V1.0 - U68 - May 30, 1997


I also run a simulation on the delay chain..

cct.PNG

I skewed /AS to just before and after the 16mhz clock edge to illustrate what I mean.

11.jpg

22.jpg

This is why I don't think it should be dismissed as being a contributing factor. Since the DFB1 entire CPU cycle will be delayed by like 10ns or whatever. It would miss the rising edge of the clock and gives totally different results. The LA doesn't have enough resolution to tell the full story. But it does clearly show your a clock behind right at the start like my simulation shows.

[Badwolf]

This is why I don't think it should be dismissed as being a contributing factor. Since the DFB1 entire CPU cycle will be delayed by like 10ns or whatever. It would miss the rising edge of the clock and gives totally different results. The LA doesn't have enough resolution to tell the full story. But it does clearly show your a clock behind right at the start like my simulation shows.

I understand but DFB1 artifically delays assertion of AS when talking to the DSP (which I'm taking into account when analysing this). Given that delay (tens of ns) I don't think propagation delay is a significant factor (yet!).

BW

[Badwolf]

I got some interesting results last night.

First using @pakman's JED I flashed my existing (15ns) GAL again and this time it worked. I don't know if it didn't like that previous JED or whether there was another issue that caused me to to suspect the GAL (one of the socket pins actually broke off -- it came out on the leg of the GAL leaving the bottom part soldered in! I performed an extraction of that last bit and replaced the pin with a donar leaving the socket intact. It could have simply been making an intermittent connection).

Anyway, with the GAL working, I built the CUPL file that @pakman, again, supplied and verified it produced the same JED content.

Now I started tweaking. I removed the second clock delay on the DSPDS assertion when HIGHZ is active and again, success.

My DSPBENCH results went from about half speed (46-54%) to two thirds speed 66%. That was a little disappointing as I was hoping to get to 75%, but with the artificial AS delay in there and the spectre of BMODE, perhaps not surprising.

It was enough to get a good minute or so's playback out of ACETRACKER before the dreaded CPU Overload message, however. I could even carry on using the machine after that error which was not the case previously. I loaded up another song and again got about a minute in.

OK, so progress. BMODE next. I effectively disabled BMODE assertion (both on DFB1, which holds it down when master and in the GAL). I couldn't detect any change to DSP or RAM speed. Perhaps DMA is slower? Didn't measure it. I remain unsure as to the practical effects of BMODE, despite the theory.

I might do the opposite and hold BMODE low throughout and see if that has any measurable effect, but I ran out of time yesterday.

After that it'll be wiring up the logic analyser again and see where the missing 33% (an extra two bus cycles if my maths is correct) is coming from now. I suspect a significant chunk of that is the AS hold off, but is there anything else? TBC.

BW

[Badwolf]

BMODE is activated (high) in Blitter transactions, probably on all DMA transactions, but didn't check. Active low or high in this case is a matter of convention. I assume the GAL uses XBGK for this purpose, but didn't check the equations.

Thanks Ijor. It's directly linked to the HIGHZ output in the GALs, which is derived from the bus arbitration, like you suspect.

It doesn't seem to have any effect on STRAM or DSP access speeds when allowed to float high, however. DFB1 (normally) pulls it low during its time as bus master -- which I think I inferred from the serivce manual's description and from simply observing what GALs did when the onboard 030 is active -- but I've not yet found anything measurable that changes with its state.

Cheers,

BW

[exxos]

It was enough to get a good minute or so's playback out of ACETRACKER before the dreaded CPU Overload message,... I loaded up another song and again got about a minute in.

That's the same behaviour @whomper reported a while back. Though I don't get that on my machine. IIRC it just "dies" on the CPU overload right from the start.

Now I do wonder if those REV A machines have the same U68 code... Will see if I can test my U68 with @JezC U68 as I still have his machine here.. Be useful to confirm Atari didn't change U68 from REV A to C/D at least..


EDIT:

Both seem the same. So thats good at least..

Capture.PNG

BUT nothing like the U68 posted earlier...

2.PNG

Maybe code-protected ? :shrug:

[JezC]

It was enough to get a good minute or so's playback out of ACETRACKER before the dreaded CPU Overload message,... I loaded up another song and again got about a minute in.

That's the same behaviour @whomper reported a while back. Though I don't get that on my machine. IIRC it just "dies" on the CPU overload right from the start.

Now I do wonder if those REV A machines have the same U68 code... Will see if I can test my U68 with @JezC U68 as I still have his machine here.. Be useful to confirm Atari didn't change U68 from REV A to C/D at least..

Sure, no worries from me about checking as much as you can... still looking like at least the end of next week before the most urgent family matters are dealt with (visiting youngest at university for her birthday, moving all the possessions of the eldest out & into her new flat down south, more emptying of my Mum's house while it hopefully continues to go through probate...)

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