jtkcpu not running fast enough

[rp-jt]

The CPU is not finishing processes during blanking, leading to some gaps in lines (reported in #787)

Making possible the use of 96MHz clock or cen==1 in jtkcpu could solve this issue

[rp-jt]

Using the 96MHz clock, the ALU is not able to finish calculations in time, leading to compilation errors.

To fix this, I tried registering the result obtained in the ALU and delaying other processes adding one clock enable before the result is stored. I tried this through the alu_busy signal, but this does not stop the count of addr in the ucode module.
Important signals like ni (new instruction) are dependent on the addr value, and, for shorter programs, for example, trying to add a cen cycle this ways leads to ni activating before the correct ALU-result can be stored.

Without delaying the rest of the CPU, the slack obtained in the timing report for compiling registering while registering the ALU outputs on a flip flop is -5.382 ns. The report indicated issues with z_out in cc_out, so we tried registering everything else but that bit, solving that issue but letting others show up.

Using another approach to decrease calculation time, I tried simplifying the ALU mux by unifying all op values leading to the same calculations in a single register that enables or disables the processes in continuous assignment. Setup slack obtained was around -6.437, indicating that this registration of op should probably be also done in other modules for this to work.

It would entail several changes for the CPU to work at 96MHz, meanwhile, it is being used in other games without problems with 48 MHz. We will try the other approach (working with cen==1), to check if it might be a better solution

[rp-jt]

In the branch jtkcpu/cenwait in commit 45926b7, we can find another approach to solve the issue. With these small changes, the cpu can also run using a fixed or variable cen input.

The jtframe_gated_cen module usually compensates pauses after a busy state with a faster cen output to keep the average as intended. However, when the intended cen is half of the clock's frequency (as it is the case in mentioned #787), this compensation is not possible, due to it being designed to not send out two cen signals in a row. To test the changes applied in the mentioned commit, a similar approach removing the blockage has been used, so several cen output signals can be active in a row if necessary.

In cenwait (45926b7), when input cen==1, a wait state is added every time the address is changed. This allows the processes in the ALU to finish before the next cen/cen2 cycle. Nevertheless, always adding a wait state independently from the operation causes only ~10% speed increase for a 48MHz 100% duty cycle clock versus a 48MHz 50% duty cycle (cen=50%) case. The wait states take away most of the gain from doubling the duty cycle. This is not enough to fix the issue reported in #787