Skip to content
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

DMAs can't cross bank boundaries, but should #319

Closed
gardners opened this issue Dec 13, 2020 · 4 comments
Closed

DMAs can't cross bank boundaries, but should #319

gardners opened this issue Dec 13, 2020 · 4 comments
Assignees
Labels
bug Confirmed bug.

Comments

@gardners
Copy link
Contributor

(note that they should not cross MB boundaries, though)

@gardners gardners added the bug Confirmed bug. label Dec 13, 2020
@gardners gardners self-assigned this Dec 13, 2020
@lgblgblgb
Copy link
Contributor

Just to have my comment here as well, not just on discord, as far as I remember, Paul told me once, that this is by design, and c65's DMA should behave this way (as on c65 only the lower 16 bits are inc/dec'ed ...). I see a potential incompatibility if this "bug" wanted to be fixed. so then there should be some compatibility flag with c65 (or MEGA65 enhanced DMA option?) to select between behaviours. Though I am not really sure if any existing C65 programs exploited this feature, however I feel a bit uncertain if at more and more points we break C65 compatibility unconditionally in the name of "but this is more logical and easy to use" (which is indeed true, don't get me wrong!). So for me, it's not so much a bug, but instead a feature request. However it's also true, that I am not aware of any tests done on a real C65, if it's really a case there ...

@gardners
Copy link
Contributor Author

Hmm..., yes, could be true. I guess the question is whether there is any C65 code that assumes the C65 behaviour. My gut feeling is probably not.

@lgblgblgb
Copy link
Contributor

lgblgblgb commented Dec 14, 2020

well, not to troll here, but I feel, while you're absolutely right, virtually about everything, we can say "no code assumes that" since not so much C65 software at all exist. But it has some danger to really call MEGA65 as a C65 compatible computer after a while. Especially if some (real) c65 owner starts to dig in into MEGA65 with the hope that their real C65 can get much love and additional software this way, then "strict(er) c65 compatibility subset" of MEGA65 can be an important factor in the future even if it's not the case right now. Again, it's just my personal fear with this whole topic to remain c65 compatible. For example as far as I know, Snoopy on forum64 is kinda keen to write/have C65 titles and more interested in the C65 side "only" of MEGA65. Again again ;) as far as I feel about this situation ... Feel free to ignore my stupid comments, though, I have not so much a big problem with this change otherwise of course, and indeed, it's kinda a nice feature for MEGA65 not to be restricted so much with using the DMA ...

@gardners
Copy link
Contributor Author

I hear you, and I agree generally. That said, there will already be other compatibility problems to real C65s (and they have compatibility problems with each other). Indeed, there are at least 2 incompatible versions of the DMA controller in the field. So on this particular one, I think the risk is acceptable.

@lydon42 lydon42 added the cleanup Issue Cleanup - possibly already fixed issue label Jan 3, 2022
@lydon42 lydon42 closed this as completed Aug 18, 2024
@lydon42 lydon42 removed the cleanup Issue Cleanup - possibly already fixed issue label Aug 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Confirmed bug.
Projects
None yet
Development

No branches or pull requests

3 participants