-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support MEGA65 R5 #82
Comments
The plan is to develop and test on this repo, and then later (or concurrently) merge in the changes to the M2M framework. The following list is taken from sy2002#19 and expanded: For R4 the following applies:
For R5 the following additionally applies:
|
For our convenience: Here are the two links to the filtered lists of M2M issues and C64 issues that are currently IN SCOPE for V5.1 of the C64: C64 issue tracker M2M framework issue tracker |
Re. HDMI: The physical HDMI connector has a pin called "+5V" where the source (i.e. the MEGA65) must supply power. On the R3 board this is done programmatically from the FPGA via the HDMI driver chip U10 = TPD12S016PWR. But on the R4 board the pin on the HDMI connector is hard-wired to the +5V power supply on the board. So the FPGA is not involved at all. |
Closing this issue because our Alpha 3 version includes everything but SDRAM and RTC: Both will be after V5.1. We have separate GitHub issue for these two features. |
This enhancement is tightly coupled with this enhancement of the MEGA65 framework: sy2002#19
Currently, there are a lot of open questions and for the time being (given the limited amount of time that we currently can invest into the C64 core) it might be valid to look at the MEGA65 R4 support of the C64 core as independent from the enhancements of the M2M framework: The open question is:
Quick and dirty C64 or "do it right" in the M2M framework?
This is the first question that needs to be answered. And both possible answers are absolutely valid and have pros and cons.
From a release perspective, right now it looks like the best thing would be to just use the V5 core - no additional enhancements - and no real "new release": Just offer on the FileHost a new ZIP that also supports R4: The whole thing would be "Version 5.1" of the core on the FileHost that supports R3/R3A and R4: We would not change the field-proven R3/R3A binaries (
*.bit
and*.cor
) but "just" add R4 binaries to the distribution.The text was updated successfully, but these errors were encountered: