Powering up problem of ACA1234 + FPU in case "CPU frequency is set" at FPU Clock

Caution: Non registered users only see threads and messages in the currently selected language, which is determined by their browser. Please create an account and log in to see all content by default. This is a limitation of the forum software.


Also users that are not logged in can not create new threads. This is a, unfortunately needed, counter measure against spam. Please create an account and log in to start new threads.

Don't Panic. Please wash hands.
  • Hello


    I would like to report or have a question here about ACA1234+FPU. I'm experiencing in powering up problems of A1200 when using FPU and having a 33R resistor soldered at "CPU pads" of FPU Clock.


    The A1200 do not boot (just blank screen) till several power-off / power-on PSU cycles. I have to off/on the PSU by random count till A1200 boots. However when I switch the R33 resistor to "50Mhz" FPU Clock. The system boots all the time at first psu power-on switch.


    So for me the problem is solved/workaround by setting static 50Mhz. However I would like to know if it is know issue, have someone same experience or it is just my issue?


    Best ragards,

    Jaroslav Pulchart

  • As mentioned in the Wiki, there is no support for FPU installation on the ACA1234. By the description, it appears like the FPU is loading the clock line way too high, indicating that you have a fake FPU with a much larger mask than indicated on the writing. This is exactly the situation that I want to avoid by making the rule to not provide support for FPU installations: You mileage may vary, especially with the high amount of fake parts in the market.

  • I'm fine with the "no support for FPU installations" as I found a way how to make it stable. I'm opening discussion here about my problem where anyone can share experience, it can be used as knowledgeable. Isn't it fine?


    I'm curious why it shall work on static 50MHz without troubles and not with CPU Frequency? I would expect it will not work at all in case of "fake" FPU mask?

  • Again, this sounds like a load discrepancy: The "CPU clock" setting takes the signal directly from the CPU clock signal, putting two loads on it. This signal is generated by the CPLD, which can drive at least three loads at this speed and slew rate setting.


    The "static 50MHz" setting comes out of the 50MHz oscillator, bypassing the CPLD. If it works - good for you. If it doesn't, there may be two faults that occur: The clock divider misses a clock, which may harm the quality of the 25MHz signal, and the clock driver that passes the 50MHz clock to the CPLD may shift it's duty cycle to a level where the whole design drifts out of it's timing margins (though this is less likely, as the margins on 50MHz are quite high).


    Clock distribution and generation is pretty elaborate on the ACA1234. The design is essentially 8-accelerators-in-one, as every speed and every target computer requires slightly different timings, and also offers different opportunities for chip ram access optimization.


    Once again, I haven't seen any problems with the real FPUs that I have here. Problems I can replicate here only occur when I use overclocked 68882 and 68881 FPUs. What you're describing is a typical fake-chip-phenomenon.

  • I am also interested in user experiences with FPU clock settings.

    I bought MC68882RC50A from Amigastore, they wrote it fully tested and warranted.

    I was in plan connect it exactly like jaroslav.pulchart originally had - i.e. CPU speed.

    My ACA1234 is 50MHz version, yet without FPU installed.


    Jens - thanks for explanation. And I know, no warranty to FPU timing issues, just like to know experience.


    It looks more safer ( from physics point of view ) to connect FPU clock directly to 50 MHz, but it looks more systematic to connect it to CPLD ;-)

  • I bought MC68882RC50A from Amigastore, they wrote it fully tested and warranted.

    I wouldn't know how they identify the actual mask inside the chip. The measuring equipment would involve a logic analyzer with at least 500MSamples/s and an adapted accelerator, combined with the (undocumented) knowledge about the different FPU versions. I happen to have that knowledge, but I'm pretty sure that it's not public, otherwise we would have seen more 68030 accelerators with faster memory interfaces. So far, all the open-source attempts at making a 68030 accel are slower than what iComp has to offer, and I attribute this to the undocumented knowledge I have about the 68020/68030/68881/68882 chips.

    but it looks more systematic to connect it to CPLD ;-)

    I wouldn't say that - the FPU is slow as hell, and it's talking async on the bus. There is no actual clock synchronization between the two chips, but async bus termination: The FPU is connected similar to a peripheral chip, and it's actually memory-mapped with a dedicated address in CPU address space (FC0=FC1=FC2=1). I would therefore always clock the FPU at a speed that is safe with the specific die it has. The FPU does not care about the CPU speed at all.


    You will always decouple FPU and CPU clock if you choose the "Divide by two" clock, no matter what the clock source is. It should also work with "CPU clock" as source, but will of course result in 25MHz max. FPU clock.

  • I wouldn't know how they identify the actual mask inside the chip. The measuring equipment would involve a logic analyzer with at least 500MSamples/s and an adapted accelerator, combined with the (undocumented) knowledge about the different FPU versions. I happen to have that knowledge, but I'm pretty sure that it's not public, otherwise we would have seen more 68030 accelerators with faster memory interfaces. So far, all the open-source attempts at making a 68030 accel are slower than what iComp has to offer, and I attribute this to the undocumented knowledge I have about the 68020/68030/68881/68882 chips.

    I am pretty sure, that testing is 100% sufficient only if I testing whole complete, ACA+FPU. I accepting the reality, that both parts ( ACA+FPU ) are tested separatelly, so here is still chance of failure.

    And iComp master engeneering is the reason, why I bought ACA1234 and no other accelerator. Only I just need also the FPU, so I will try it.

    I wouldn't say that - the FPU is slow as hell, and it's talking async on the bus. There is no actual clock synchronization between the two chips, but async bus termination: The FPU is connected similar to a peripheral chip, and it's actually memory-mapped with a dedicated address in CPU address space (FC0=FC1=FC2=1). I would therefore always clock the FPU at a speed that is safe with the specific die it has. The FPU does not care about the CPU speed at all.

    Thanks for info, I thought they are synchronized. OK then, it looks the best way for me is to test it directly to 50 MHz, and if it will not works, go to 25 MHz.

    I will post the result here, but it will be after month or more.

  • So finally I receive my new a1200 and test ACA1234.

    First on clean os 3.2, than with MMU+68030.library ( not installed whole MMU package - here is some mismatch with ACAinit, it not works properly ) and in the end with FPU MC68882RC50A from Amigastore, frequency setted to 50 MHz directly, not derived from CPU.


    All works like a charm, busspeed is the same with all configuratations and libraries ( differs by 1 MB/s in max value ).

    Thank you Jens, perfect accelerator.

  • The last reply was more than 365 days ago, this thread is most likely obsolete. It is recommended to create a new thread instead.