exxos's Atari, Amiga & retro forum

charon030 wrote: 02 Dec 2025 20:59 Thanks for that explanation. But I don't think I got what you mean with "half-cycle of half-speed upon switch" and why this breaks at 8 MHz but works with 16 MHz.

The part where DFB1 crashes when acceleration is enabled but the system is set to 8MHz is proven. The reason for that, however, is conjecture.

When switching from 50MHz to 8 there is a period of around 250ns without a clock edge each time. One hypothesis is that perhaps this is too long and happens too frequently for the 030 to remain stable.

The workaround is that DFB1X simply doesn't allow acceleration when the bus is configured for 8MHz. DFB1 waits after reboot until it thinks it's safe to enable acceleration and will crash if you try to switch back to 8MHz when the machine is running.

BW

charon030 wrote: 02 Dec 2025 21:07 It's not urgent for me. Would it be possible to make a trial with a test-firmware for the CPLD that uses an extra delay cycle for flash accesses, once you have time again? I think it's just a one-liner to change in Verilog (see previous posts). At the same time I don't want to appear too demanding. But it would just be nice to have the NetUSBee usable with full performance of the accelerator. I don't care if access time is 80ns or 100ns. For 40 MHz it seems to be 100ns anyways.

It's not a huge issue. Will try and do it ASAP. I just want more than one way of "fixing" the problem.. its why I asked you to try the bus pullups.. If both methods fix the problem then more solutions is always better and confirms the problem more reliable than just 1 test.


EDIT

Badwolf wrote: 02 Dec 2025 21:13 The part where DFB1 crashes when acceleration is enabled but the system is set to 8MHz is proven. The reason for that, however, is conjecture.

When switching from 50MHz to 8 there is a period of around 250ns without a clock edge each time. One hypothesis is that perhaps this is too long and happens too frequently for the 030 to remain stable.

The workaround is that DFB1X simply doesn't allow acceleration when the bus is configured for 8MHz. DFB1 waits after reboot until it thinks it's safe to enable acceleration and will crash if you try to switch back to 8MHz when the machine is running.

BW

OK, got it! Thanks!

exxos wrote: 02 Dec 2025 21:18 It's not a huge issue. Will try and do it ASAP. I just want more than one way of "fixing" the problem.. its why I asked you to try the bus pullups.. If both methods fix the problem then more solutions is always better and confirms the problem more reliable than just 1 test.


EDIT

dfb1r5.zip

Wow, that was quick! I will give it a try soon. Thanks!

exxos wrote: 02 Dec 2025 21:18 It's not a huge issue. Will try and do it ASAP. I just want more than one way of "fixing" the problem.. its why I asked you to try the bus pullups.. If both methods fix the problem then more solutions is always better and confirms the problem more reliable than just 1 test.

I'm pleased to let you know that this firmware resolves the issue for me! I didn't observe any more freezes during boot with Flash/50 MHz CPU/NetUSBee connected to ROM-Port. I've tried like 10 times or so.
I don't have any bus pull-ups at hand, so I can't test this at the moment.

Another issue is that the XBOOT graphics are corrupted with the patched TOS version in the Flash (to detect TT-RAM). It seems that XBOOT is using the VDI functions of TOS for that, making use of the Blitter. Thus I can't have a faster HDDriver (running from TT-RAM) and error-free XBOOT at the same time. Same issue existed for SuperVidel (as I found in some other thread on Atari-Forum I think). But a solution could be to launch NVDI even before XBOOT.

Cheers!

Badwolf wrote: 02 Dec 2025 21:13 The workaround is that DFB1X simply doesn't allow acceleration when the bus is configured for 8MHz. DFB1 waits after reboot until it thinks it's safe to enable acceleration and will crash if you try to switch back to 8MHz when the machine is running.

Maybe this is a silly question, because I haven't thought things through: Have you ever considered to run the CPU constantly at 50 MHz and just do a clock-domain-crossing for the control signals (AS / D(T|S)ACK)? Could this even result in a boost as the CPU could/would latch data from the Falcon-bus a bit sooner? And the half-cycle for clock switching would be eliminated.

charon030 wrote: 03 Dec 2025 08:32 Maybe this is a silly question, because I haven't thought things through: Have you ever considered to run the CPU constantly at 50 MHz and just do a clock-domain-crossing for the control signals (AS / D(T|S)ACK)? Could this even result in a boost as the CPU could/would latch data from the Falcon-bus a bit sooner? And the half-cycle for clock switching would be eliminated.

I was also wondering about this (in principle, if not the exact how-to details).

The 030 pipelines/defers writes to a storebuffer so it can continue executing cached instructions very efficiently interleaved with writes. This improves as the ratio of the CPU clock increases vs the bus - more instructions can execute between the writes as they get slots to complete. It is a useful optimisation for graphics, audio and other operations involving a lot of sequential writing.

However if the CPU itself is switched down during those bus cycles the ratio drops as the operating window is smaller.

But I think I have already made enough headaches for BW and I'm happy with it as-is. Just interested to see if any discoveries/improvements happen along the way ;)

dml wrote: 03 Dec 2025 09:31

charon030 wrote: 03 Dec 2025 08:32 Maybe this is a silly question, because I haven't thought things through: Have you ever considered to run the CPU constantly at 50 MHz and just

I was also wondering about this (in principle, if not the exact how-to details).

Tried it. Didn't like the results. I couldn't make it work reliably as there are a few different bus timings involved on the Falcon and the fact the underlying clock can (and does) change from 8->16 added extra complexity.

In the end 'related' clock switching [which it really shouldn't be, it should be 'unrelated', but it was less effective] worked so well for most cases that I stuck with it.

I even tried PLL-based integer-multiple clock rate to allow for instantanous switching at a clock edge, but after all of that the shitty way I do it now was the most reliable.

And I'm a lowest hanging fruit kind of a guy ;)

BW

Badwolf wrote: 03 Dec 2025 10:07 I even tried PLL-based integer-multiple clock rate to allow for instantanous switching at a clock edge, but after all of that the shitty way I do it now was the most reliable.

I do prefer 100% reliability, over a 5-10% speedup and ~10% crashyness :)

Badwolf wrote: 03 Dec 2025 10:07 And I'm a lowest hanging fruit kind of a guy ;)

Funny that you consider yourself as that type of guy, after having developed an accelerator from scratch... :lol: