exxos's DFB1 trials

[Badwolf]

EXPERIMENTAL FIRMWARE! @exxos

Seems worse :(

Did you change your git files over the past couple of days, some of the code looks different now...and OPTION2 no longer works :roll:

Yes, the git repo is under development. The 'release' is the current stable build.

https://github.com/dh219/DFB/releases

Specifically https://github.com/dh219/DFB/releases/d ... B1_1.0.zip

The firmware was working for me, but when I took out the board to add the bodge wires, the board itself has stopped working (even with FPU removed and stock firmware in place).

IMG_6011.jpg

Perhaps I've got a low impedance path somewhere there. I haven't cleaned it up properly yet. Pretty sure they're the right pins.

BW

[exxos]

ah, just re-read your previous post, so I need to do those bodge wires with the new firmware.. not done that yet.. just trying to get my workflow back to what it was a few days ago so I can do some more experiments.

[exxos]

@Badwolf Did the bodge wires and flashed your test firmware but now it does not boot up at all.

Took the bodge wires out and put the default firmware back in and running again.

Just tried delaying DSACK from the FPU and it crashes on the first test again.. I really don't get it. Delaying DTACK should not make any difference whatsoever.

[Badwolf]

ah, just re-read your previous post, so I need to do those bodge wires with the new firmware.. not done that yet.. just trying to get my workflow back to what it was a few days ago so I can do some more experiments.

It should boot up without the bodges, but not pick up the FPU.

That said, there were other firmware upgrades in there that aren’t fully tested, so I’d not worry about it yet.

Delaying DSACKx ought to be fine, AAUI, but just make sure you’re doing them as two separate traces this time.

Anyway, you said there was instability when you probed FPU dsack, so a delayed instability would still be unstable.

BW

[exxos]

Hmmm.. the plot thickens...

IMG_0248.JPG

[Badwolf]

Oh, I'm an idiot.

I forgot to take the FPU_DSACK term out of the main DSACK assignment meaning that when I bodged those wires across I created a latch. :oops:

BW

[exxos]

Oh, I'm an idiot.

I forgot to take the FPU_DSACK term out of the main DSACK assignment meaning that when I bodged those wires across I created a latch. :oops:

I am currently trying to work out if I am a idiot or a genius currently :lol: But I think the jury is always out on that one :lol:

IMG_0249.JPG

So is there any actual FPU benchmark programs to verify I am not being fooled here somehow ?

[dml]

\o/

[Badwolf]

So is there any actual FPU benchmark programs to verify I am not being fooled here somehow ?

Interesting!

Gembench will give you a perfectly good indication of effective MHz (although not relative performance as it only tests a subset of operations and the 32 bit bus doesn't seem to make any difference).

BW

[exxos]

Using the fractal program.. https://exxosforum.co.uk/atari/last/FPU/index.htm

A stock Falcon with different FPU clock speeds..

Code: Select all

16mhz MB clock - 65.105 seconds
16mhz oscillator - 63.139 seconds
25mhz MB clock - 51.37 seconds
32mhz MB clock - 46.115 seconds
50mhz oscillator - 44.98 seconds
64mhz oscillator - 44.70 seconds

As I am using a 40MHz OSC.. somewhere around 45 seconds would be the figure..

Back to the DFB1 with OPTION2 enabled. So basically emulating the same tests as above. (16MHz falcon with overclocked FPU)

IMG_0251.JPG

Looks right on the money there.


Now without OPTION2:

IMG_0250.JPG

32 seconds.. So clearly blown past a stock machine. Even with a overclocked FPU 8-)

I've got 3.645 seconds in GB6. But don't currently have a stock reference file for the Falcon with FPU.