Page 25 of 26

Re: DFB1r4 design discussion thread

Posted: 02 Dec 2021 13:35
by exxos
Badwolf wrote: 02 Dec 2021 13:27 Mmm. I suppose it would answer whether the fabric can work at the clock frequency, but not necessarily if the chip can handle the stress of being selected more often.
Yep. If the FPU is just sat there most of the time "idling" at 64Mhz not really doing anything.. But then does something complex like division which would need a lot of clock cycles which could heat it up to the point of failing. Again I would be assuming that the fractal program would be hammering the FPU like crazy, but it's also being stalled by the CPU programming it more slowly, So it could be enough to tip the balance.

Badwolf wrote: 02 Dec 2021 13:27 I've had some really funky results with different programs and different combinations. I think I need to gate AS, DS and the DSACKx lines -- even if it costs some cycles -- as I don't want to be introducing artefacts with my CPU clock switching nor my HIGHZ switching.
Yeah this is what we need to rule out. If the FPU fails the FPU test program running 50Mhz (or whatever) with the stock 16Mhz CPU.. It is pretty much case closed.

I guess another test if it does still work, just heat it up and see if the tests failing match what you are seeing fail with your accelerator. It may give some clues.
Badwolf wrote: 02 Dec 2021 13:27 I'm very pleased it's got this far, though, to be honest! The new PLCC sockets you sent me are *far* more reliable than whatever I got off RS.
:bravo: :cheers:

Re: DFB1r4 design discussion thread

Posted: 03 Dec 2021 10:00
by Badwolf
exxos wrote: 01 Dec 2021 17:40 I did these tests a while ago https://www.exxosforum.co.uk/atari/last/FPU/index.htm
That Fract program doesn't seem to run under EmuTOS, which is annoying as I have a DMA-free build of EmuTOS I'd like to use for FPU test benching.

It fails with "Whoops not a display!"

Anyone know what's wrong and if I can patch it?

BW

Re: DFB1r4 design discussion thread

Posted: 03 Dec 2021 11:28
by exxos
I guess you would have to contact them on the mailing list and report the problem.

Re: DFB1r4 design discussion thread

Posted: 03 Dec 2021 11:33
by Badwolf
exxos wrote: 03 Dec 2021 11:28 I guess you would have to contact them on the mailing list and report the problem.
One of the secret EmuTOS ninjas has already been in touch!

Faster than a speeding bullet, those fellers. :lol:

BW

Re: DFB1r4 design discussion thread

Posted: 03 Dec 2021 12:05
by czietz
Fixed with this EmuTOS snapshot 20211203-115515-0b57c787 (or any later version), available at https://sourceforge.net/projects/emutos ... snapshots/.

Note that this fractal program, while not a GEM application, still uses AES functions and as such does not run from the EmuTOS early console. (The one reached by pressing [Esc] at the boot screen.) You have to boot to the Desktop so that AES gets initialized. That had me confused for a few minutes.

Re: DFB1r4 design discussion thread

Posted: 03 Dec 2021 12:17
by Badwolf
czietz wrote: 03 Dec 2021 12:05 Fixed with this EmuTOS snapshot 20211203-115515-0b57c787 (or any later version), available at https://sourceforge.net/projects/emutos ... snapshots/.
Thanks, secret ninja. :lol:
Note that this fractal program, while not a GEM application, still uses AES functions and as such does not run from the EmuTOS early console. (The one reached by pressing [Esc] at the boot screen.) You have to boot to the Desktop so that AES gets initialized. That had me confused for a few minutes.
That was my first guess when I saw it (I had it in the auto folder), but then it did it from the desktop too.

Thanks for looking into it, Christian. :-)

BW

Re: DFB1r4 design discussion thread

Posted: 05 Dec 2021 19:25
by Badwolf
exxos wrote: 02 Dec 2021 13:35
Badwolf wrote: 02 Dec 2021 13:27 I've had some really funky results with different programs and different combinations. I think I need to gate AS, DS and the DSACKx lines -- even if it costs some cycles -- as I don't want to be introducing artefacts with my CPU clock switching nor my HIGHZ switching.
Yeah this is what we need to rule out. If the FPU fails the FPU test program running 50Mhz (or whatever) with the stock 16Mhz CPU.. It is pretty much case closed.

I guess another test if it does still work, just heat it up and see if the tests failing match what you are seeing fail with your accelerator. It may give some clues.
OK, I'm not going to dive down this rabbit hole much further, but here's what I've found so far.
  • DML's test program (FPUTEST) is the gold standard. Its results are consistently repeatable for a given configuration.
  • FPU clock speed is the biggest factor in failure of tests. I couldn't conclusively demonstrate a link between changing CPU speed and FPU failure modes changing.
  • Using programs that employ the FPU to test it is rarely sufficient. Most programs only use a few functions. The most common ones are quite far down the failure list.
  • FPUCLK > CPUCLK is reliable with a direct AS/DS/DSACKx connection and 1k2 pull-ups.
  • FPUCLK < CPUCLK is reliable within certain limits if DSACKx is handled by the CPLD such that the DSACKx lines to the CPU are always driven, rather than switching to high impedance.
  • The difference between CPUCLK and FPUCLK values can't be too extreme when the FPU is slower, even with gated DSACKx lines. A factor of two is fine. A factor of three isn't.
  • Only one of my 68882 chips could run at 40MHz, but not 48. One could sustain 25MHz but not 36. One could handle 16 but not 25. All are labelled as 40s.

So going forward I'm going to route DSACKx from the FPU via the CPLD and let the user supply a second oscillator if they prefer. I might even provide a CPUCLK/2 option.

BW

Re: DFB1r4 design discussion thread

Posted: 05 Dec 2021 22:21
by Badwolf
Bit of a milestone today. DFB1 is, as far as the stated goals for the project are concerned, feature complete.


Here's the state of the board. I'll have to dig it out and show you the bodge wires on the back at some point!

IMG_4905.jpeg


Here's how it fits with the original (recapped) PSU in place.


IMG_4908.jpeg


And with the keyboard.

IMG_4907.jpeg


And the whole ensemble.


IMG_4909.jpeg


Comparing like for like (as I have to run NVDI to disable the blitter, so this is comparing an FPU'd up stock Falcon running NVDI):

IMG_4903.jpeg

This is with TOS from the motherboard. There's an onboard ROM option as well which gives a 250% speed boost on the ROM access, but I've EmuTOS on there at the moment.


Now it's time for a bit of Muntzing before contemplating the next spin of the board, I reckon!

BW

Re: DFB1r4 design discussion thread

Posted: 05 Dec 2021 22:46
by exxos
Pretty darn good ! Bit slow on RAM access though ?

Re: DFB1r4 design discussion thread

Posted: 06 Dec 2021 08:24
by JezC
Looks very promising @Badwolf.


:thumbup: :coolpics: :goodpost: :cheers:
Any more plans for future developments beyond a spin of the PCB?