exxos's DFB1 trials

[Badwolf]

Found the feker!!!

Woohoo!

And a $50 credit is better than a poke in the eye with a sharp stick too.

Albeit it's probably cost you £200 in man-hours

BW

[exxos]

So I have @JezC REV A board now. Someone needs a new reset switch ! and a new RTC ! and clock patch !

IMG_3853.JPG (302.33 KiB) Viewed 214 times

I will replace the clock patch after I have scoped the signals, and finished the below stuff to make sure I can direct compare to different clock patches..

Anyway, the stock Falcon seems to work with ACETRACKER fine. DSPSDMA tests fine.

With the DFB1X, the screen seems to be losing sync (its not great on my old monitor to start with on interlaced) but its a lot worse. But if timings are tight on ACETRACKER then that's to be expected I guess.

I tried 16MHz mode on DFB1X, screen sync issues gone.. But it only played about 20 seconds then seemed to "die".

This video I load the song play.. after a few seconds it dies.. I reload the song.. same again... "CPU overload" But why ? @dhedberg any ideas what's going on there ?






Retest with 50MHz (screen losing sync) - no "lockups" though

[Badwolf]

This video I load the song play.. after a few seconds it dies.. I reload the song.. same again... "CPU overload" But why ? @dhedberg any ideas what's going on there ?

I've seen that a few times. Too few CPU cycles between DMA requests on account of the bus arbitration overhead?

BW

[exxos]

I've seen that a few times. Too few CPU cycles between DMA requests on account of the bus arbitration overhead?

I feared that as well We can't really do much about software which is "counting cycles" to that extreme. I also just been wondering if the Falcon MB ROM waitstates could be a factor somewhere.

I suspect at 50MHz it "recovers" enough to work, but then as the timing is all over the place, it screws up the video sync.

This REV A, looks like its had the SDMA changed at some point. Soldering looks a bit "crusty" and looks like a pad repair/bodge has been done also.

IMG_3859.JPG (339.51 KiB) Viewed 209 times

EDIT:

In actual fact one pin was barely even holding on and it was intermittently stopping the falcon from booting up

New clock patch fitted, DSP2SDMA test works, ACETRACKER working currently (no DFB1X yet) . Just making sure stock is working fine.

[exxos]

So this is the SDMA clock before and after the V3 exxos patch was fitted.

sdma.png (125.53 KiB) Viewed 198 times

sdma2.png (109.51 KiB) Viewed 198 times

IMG_3857.JPG (375.77 KiB) Viewed 195 times

IMG_3861.JPG (261.02 KiB) Viewed 195 times

I need to measure the capacitance on the SDMA trace to see if there is anything any different there as well... Though I still suspect people who got "bad results" must have bad probes or something causing the signals to look bad.

EDIT:
REV A is about 67pF
REV C/D is about 65pF.
So no difference there which is good.

EDIT2:
So ACETRACKER at 50MHz with the DFB1X still behaves the same with screen losing sync.

ACETRACKER screen doesn't seem to judder as much with the DFB1X in 16MHz mode which is odd.
So now playing 16MHz mode and still get the CPU overload as before. Oddly now the screen fact is totally stable.. So maybe DSP access causes the "screen judder". No idea .. Again maybe @dhedberg could tell us more.

TL;DR, Clock patch hasn't made any difference with anything (which is good as it rules out a few things). But of course the new clock patch has MUCH cleaner signals and not like 3v negativing ringing etc! So it's still a win anyway.

[exxos]

I tried CUBASE on The REV A board, oddly it doesn't come up screen corruption after loading the song, the song "played" but random noises and after about 1 min it locked up. This is with the DFB1X.

So even though I can't remember the conversation now @whomper , Id say theres no difference between REV A and REV C/D boards and even though clock patches are a issue in their own right, I don't think these current issues are motherboard revision or clock patch related. So good some things can be ruled out, but not really any further at this point unfortunately.

I wonder if we overclocked the DSP at a higher clock it would claw back some cycles somewhere @Badwolf

[Badwolf]

I wonder if we overclocked the DSP at a higher clock it would claw back some cycles somewhere @Badwolf

Not sure about the DSP. Still need to get to the bottom of it failing the cartridge test (which I'm slowly working towards), but I do wonder if there's a sweet spot of acceleration that would make Acetracker happy.

Eg, perhaps there are too few cycles between DMA accesses in 16MHz mode because of the arbitration overhead. Perhaps there are too many in 50MHz mode. So.. what if it could speed up to 19MHz, for example? Would a slightly faster clock offset the losses for switching and bus arb, for example?

I still have (somewhere) your dial-a-freq VCO. As and when I get time (ha!) I may try experimenting with that and Acetracker to see if I can rule that theory out.

BW

[exxos]

Not sure about the DSP. Still need to get to the bottom of it failing the cartridge test (which I'm slowly working towards), but I do wonder if there's a sweet spot of acceleration that would make Acetracker happy.

Eg, perhaps there are too few cycles between DMA accesses in 16MHz mode because of the arbitration overhead. Perhaps there are too many in 50MHz mode. So.. what if it could speed up to 19MHz, for example? Would a slightly faster clock offset the losses for switching and bus arb, for example?

IIRC 40MHz worked worse than 50MHz if that helps..

One possible way to rule out the bus-arb is to remove all that code, and go back to "hard wiring" the MB CPU HALT or whatever and try that.. but that would be a PITA anyway.

If CUBASE & ACETRACKER are timing sensitive which they appear to be, we might just have to make such as "unfixable" as its the old problem that developers pushed every cycle out of the machine.. When something gets in the way, it all goes out of the window.. Like demos on the ST which just refuse to run as they mostly counting cycles with stuff.. We can't really fix that problem.

I still have (somewhere) your dial-a-freq VCO. As and when I get time (ha!) I may try experimenting with that and Acetracker to see if I can rule that theory out.

Good luck

[Badwolf]

IIRC 40MHz worked worse than 50MHz if that helps..

Yeah, 40MHz would be way more cycles. I'd be aiming to see if there's a sweet spot that compensates for the dropped ones without falling off the other end of any cycle count expectation window.

One possible way to rule out the bus-arb is to remove all that code, and go back to "hard wiring" the MB CPU HALT or whatever and try that.. but that would be a PITA anyway.

Can't be done. Even ignoring the onboard CPU you need to go through the dance with the GALs. See my CPUless motherboard series.

If CUBASE & ACETRACKER are timing sensitive which they appear to be, we might just have to make such as "unfixable" as its the old problem that developers pushed every cycle out of the machine...

Yes, quite. But I'd like more evidence that fits the hypothesis or, perhaps more usefully, rules it out.

BW

[dml]

For what it's worth... I have noticed problems with ACE Tracker's display refresh on an unmodified machine. It glitches occasionally for 1 frame but it's a full-screen glitch - not the same as what is shown in the video above.

However it means ACE is doing something funny in the vertical blank that's probably not quite compatible with something.

In the video above, that looks like video interlacing (1 video frame only odd lines, 1 video frame only even lines) which is not toggling properly between frames so its showing all-odd lines for a period then all-even lines - that's the jumping effect when it changes.

The only thing that comes to mind here is the famous Falcon video double-vblank interrupt bug which was caused by some sort of reflection on the video connector or the circuitry behind it. It causes the machine to throw 2 interrupts instead of 1 on some video frames. There is a sort of software 'fix' or workaround for this - using a raster interrupt to mashall the vblank interrupt and kill the duplicates (and/or probably other ways) but this can happen with any Falcon.

So you might be seeing that, being aggravated in some additional way with the booster.

If the audio is cutting out though and other problems - maybe related, maybe just a separate problem?


BTW I had a suspicion at some point that the DSP host port is a bit slower with DFB1 running than on a normal machine but I haven't measured it. Could be complete nonsense - but I'll report what I find when I get the time to check it.