OK. Your attempt seems correct to me. If the branch is correctly taken, the instruction at 1AE0 (a write of 0x10 to WR0) resets the interrupt. Maybe worth to check tomorrow if that write indeed happens. Immediately after that, the ROM code updates the mouse position.
Just to be sure, you updated this too? Maybe a RR2A vs. RR2B typo?
Ah, no, the issue is that your SCC runs at 8MHz and the CPU takes 4 clocks for a R/W cycle: the register index gets reset to zero before a read completes and hence reads the wrong value.
I think the fix is to transfer
rindex only if ASn is high (deasserted) here:
if (cpu_as_n) rindex <= rindex_latch;
This way the index change side effect is deferred until after the end of the read or write.
if (cpu_as_n) rindex <= rindex_latchchange is not working if that it prevents register 1 from being written.
There is an sdram simulator here, in the Mini Cortex test bench:
Note that it only does 512KB of sdram as written, but making it larger is simple tweak.
Maybe for a test it is easier not to simulate the mouse, but to generate eg. x1 directly and have a minimal test program in the ROM.
If I have time tomorrow, I'll see if I can set up a test bench using the simple M68K system and the SCC code.
Also apio might not be using --compress on ecppack.
Nice, I will look at that. the bit files are many times bigger
Hello everyone, I'm having a bit of an issue trying to build a project for ULX3S using Yosys/NextPNR (under apio). NextPNR seems to be complaining about combinational loops:
ERROR: timing analysis failed due to presence of combinatorial loops, incomplete specification of timing ports, etc.
But I don't seem to find what loops is it referring too. Forcing nextpnr to run ignoring errors, it throws this warning around 30 times. I thought it was because of how I handle FSM states but trying to follow a more "conventional" approach didn't seem to fix those. Doing so I got a seeming valid bitstream but in the FPGA it didn't work as expected (most of the signals didn't come out the expected ports at all), even though the simulations looked OK to me. So I think these timing issues could be the problem.
It's the first time that I try to create something for the board and I'm a bit lost on how to fix these issues... if anyone could help taking a look at the design and see if there's something obvious I might be missing I'd really appreciate it: https://github.com/jdesiloniz/ulx3s_numeric_display/tree/main/rtl
Thanks a lot!
clk_divider.vdoesn't create that issue and I could synthetize and run a small blinker on the ULX3S based on that without issues.