sy2002
commented
12 months ago On the above-mentioned "MAX10: Reset-detection": When refactoring this for R4 support, we must be very careful and for example (and this might be just one example) not forget something like this: https://github.com/MJoergen/C64MEGA65/commit/9cf78fae212d12e06f43bbe785779d8feab7c98c Quoting the commit message:
fixed jerky joystick on R3 machines
Since the MAX10 fix, R3 machines had jerky joysticks. The fix is to use the debounced reset signal from the MAX10, which is slightly concerning because this means, that on R3 machines, the reset signal seems to jitter and this jitter did reset the joystick debouncers which lead to the jerky joystick movements.
Here is Paul's first "bring-up" post:
https://c65gs.blogspot.com/2023/06/mega65r4-bring-up.html
This article shows: This is a lot more than just "changing a few FPGA ports in the XDC file":
As soon as we start to think about the architectural enhancements and feature enhancements that are necessary to support the MEGA65 R4, we need to read all Paul's posts (revisit blogspot and see if there are more than just the one mentioned above) and other info sources (incl. MEGA65 source code)in detail: We need to come up with a list of things that need to change or that need support in the R4.
We also need to think about implications on the level of a core: Can the M2M framework abstract-away things like the changes in the IEC port? Or the amount of memory and HyperRAM vs SDRAM? If yes, then M2M supports IEC from then on and for example the C64 core would not need any notion of "is a R3/R3A or R4 running?" otherwise it would, i.e. cores would start to become machine-type-aware
Some early first thoughts in random order (and as written above: This list needs to be heavily scrutinized):
*.d64with the right date/time when the core writes to a disk image: We need to support 3 different RTCs as it looks like: Original M65 R3 RTC, "workaround R3 RTC" and new R4 RTC)