search

lgblgblgb / xemu

Emulations (running on Linux/Unix/Windows/macOS, utilizing SDL2) of some - mainly - 8 bit machines, including the Commodore LCD, Commodore 65, and the MEGA65 as well.
https://github.com/lgblgblgb/xemu/wiki
GNU General Public License v2.0
208 stars 32 forks source link

MEGA65: AnotherWorld port (preview) for MEGA65 has a display issue #304

Closed lgblgblgb closed 2 years ago

lgblgblgb commented 3 years ago

The great AnotherWorld port to MEGA65 has a very interesting display issue: at the right side of the screen a fixed part of rectangular area is flickering. Very strange, indeed, as it's always a fixed and well bounded, and relative small area of the screen where there is problem.

So far, I know, that AnotherWorld uses two screens (ie, different video memory addresses), rapidly changing between them. The flickering is caused because only one screen has this problem, the other is not. I have no idea though why, and why only a part of the screen still! Probably it has something to do with character attributes being different between the two screens, and Xemu does not do the very same what MEGA65 do, thus effecting the result.

An old issue

In issue #289 there was a more serious problem with running AnotherWorld on Xemu, that has been resolved, but this more minor (but still very annoying) bug remained. There are other partial information fragments which may can help here as well. Or not ;)

hernandp commented 3 years ago

Downloaded the D81 and successfully Reproduced on latest ROM. Very interesting.

hernandp commented 2 years ago

Tested with current Xemu next, still happens.

lgblgblgb commented 2 years ago

Tested with current Xemu next, still happens.

Yeah, I haven't tested since a while, but assumed that it's still a problem. To be honest it seems to be quite an odd problem. I didn't want to bother you with that while working on other (maybe more important) issues, but for sure you can take it, if you wish. Once I've tried to debug it, but I have gave up after half on a hour or so, always I have/had "priorities" to do something else, brrrr :-/

hernandp commented 2 years ago

No problem, I must work with the GOTOX issues first (probably they are a bit tricky)

lgblgblgb commented 2 years ago

No problem, I must work with the GOTOX issues first (probably they are a bit tricky)

@hernandp Understandable, especially because whatever problem this is, never encountered a bug/report/issue by anything other than AnotherWorld, so for me, it doesn't seems to be top priority at least. Anyway, we'll see if me/you have time in the future to investigate.

lgblgblgb commented 2 years ago

New information from Majikeyric: he has concluded that the problem only appears when glyphs are from the memory area which would be the "C65 colour RAM", ie the 2K area at $1F800. Having a second look, it seems my original thoughts here failed badly. Ie, my plan was to update both of "real fast RAM" and the "colour RAM" when writing that memory area, so they are in sync, but the in VIC-IV emulation some don't need to check special cases all the time. However looking at the source, as far as I can see now (and remember my code ...) it's not the case! So probably this is the only problem which secretly could effect many other things as well.

Big thanks to Majikeyric for his notification about the possible root cause here.

My plan: I will check if it's really the problem. If it is, I make a fix, also closing this issue, and opening a new one, since then this problem is a wider problem than only AnotherWorld, and it's just a fortunate that no other developer has faced it yet. Also a TODO for me: check is configure problem is related (ie, Xemu cannot run configure since a while for unknown reason, and since it's in the colour RAM by default on power-up, it's very much a suspect now in my eye).

hernandp commented 2 years ago

Nice finding! Maybe we can craft some quick test program?

El jue, 20 oct 2022 a las 8:21, LGB @.***>) escribió:

New information from Majikeyric: he has concluded that the problem only appears when glyphs are from the memory area which would be the "C65 colour RAM", ie the 2K area at $1F800. Having a second look, it seems my original thoughts here failed badly. Ie, my plan was to update both of "real fast RAM" and the "colour RAM" when writing that memory area, so they are in sync, but the in VIC-IV emulation some don't need to check special cases all the time. However looking at the source, as far as I can see now (and remember my code ...) it's not the case! So probably this is the only problem which secretly could effect many other things as well.

Big thanks to Majikeyric for his notification about the possible root cause here.

My plan: I will check if it's really the problem. If it is, I make a fix, also closing this issue, and opening a new one, since then this problem is a wider problem than only AnotherWorld, and it's just a fortunate that no other developer has faced it yet. Also a TODO for me: check is configure problem is related (ie, Xemu cannot run configure since a while for unknown reason, and since it's in the colour RAM by default on power-up, it's very much a suspect now in my eye).

— Reply to this email directly, view it on GitHub https://github.com/lgblgblgb/xemu/issues/304#issuecomment-1285354543, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABEFMBOSAF4R5DXBTUDTZQ3WEETJXANCNFSM5F4VXLZQ . You are receiving this because you were mentioned.Message ID: @.***>

lgblgblgb commented 2 years ago

Closing this issue and moving to #361 as it's a more generic issue than only being AnotherWorld-specific.

lgblgblgb commented 2 years ago

Nice finding! Maybe we can craft some quick test program?

@hernandp Oh, just noticed your message here, after closing the issue. In short, well, I am not planned to do a test for this, since it's kind of straight-forward to do, after I realized what is the nature of problem, I would assume it's a VIC-IV emulation bug (what else can be? hehe ....), surely it's hard to imagine a memory management/decoding issue, since those would "surly effect almost anything so the machine wouldn't even 'boot'". Well we see, assuming things are not the best approach always ...

lgblgblgb commented 1 year ago

Though it seemed to be a VIC-IV emulation issue, it was not but a memory addressing issue! For more, see: #361

hernandp commented 1 year ago

Good catch @lgblgblgb!