MEGA65: Xemu/MEGA65 development plan

[lgblgblgb]

Xemu/MEGA65 development plan

As MEGA65 seems to be more and more popular partly because the "media" (YouTube videos, etc), there is some further force now about better emulation of MEGA65. Besides this fact, surely, the issue would be valid otherwise as well, it's "just" an extra push. The goal of this summary is try to summarize the main problems and possible solutions, with the ability others can comment, make suggestions below. To solve problem(s), first we must define the problems and goals. Then it's needed to find plans/solutions, even multiple ones, then selecting one. Also there should be some priority list about the problems to "attack". To make it worse, some problems may be related, and the "logical" priority would make it much more complicated to solve more issues on the longer term than the seemingly (from user point of view) "logical" way (ie, "what is more important for the user").

Currently, even this description is WIP, and can change any time!

Please help to add more "boarder scope" problems (not just small issues), or more information / ideas on the existing ones!

Main problems (not small/smaller ones!)

Partly because I know, partly because of feedbacks I see the following main problems:

• Xemu/MEGA65 is too fragmented, some features exists in one branch but not in the other, and vice-versa, impossible to enjoy all the latest emulation development at once.
• Main concern: lack of decent VIC-IV emulation in the main branch(es), ie. lack of merge of Hernan's work. MEGA65: integrate Hernan's ideas/work on VIC-IV enhancements with the possibility of re-factoring meanwhile #29
• Even with Hernan's fork: Xemu/MEGA65 is aiming only scanline level of precision in emulation (note: maybe it's not even possible to go for pixel level, IIRC the dot clock is around 80MHz, emulating that with also the need of CPU/DMA/audio/etc would be too much for even a modern PC??)
• Current Hyppo in Xemu/MEGA65 is too old, causing problems with some disk access specific traps, and maybe other problems as well. MEGA65: adopt more decent hyppo #140
• SD-card emulation is not accurate, maybe a reason for freezer to fail to be activated. MEGA65: SD-card controller emulation should work with freezer, fdisk and "regular usage" at least #81
• Current memory decoding scheme is slow, very hard to understand, maintain, and develop further, makes it hard to develop related issues (like Q-register implementation, Hernan's fork merge). MEGA65: introduce faster, shorter, more compatible, easy to maintain/understand/modify/follow memory and I/O decoding #209
• CPU emulation lacks many new MEGA65 opcodes, especially the ones involving 32 bit operations and also the Q register. MEGA65: emulation of CPU 32bit virtual Q register and related opcodes #202
• Audio emulation is kind of bad, there is no timing at all, DMA audio is not even tested, features missing. There is not even some coherent idea how to handle audio emulation at all within the Xemu core, in general. MEGA65: implement DMA audio and OPL3 emulation #127 CORE: Brainstorming on ideas how to extended Xemu's core for audio sync/timing/emulation #90
• Some DMAgic features are missing, the emulation is kind of messy anyway. MEGA65: re-factor F018 emulation, adopt new MEGA65 enhanced mode options, plus other changes #198
• CIA emulation does not even handle all what a real 6526 CIA can do, and certainly don't know about MEGA65 extensions. To be worse, CIAs have the smallest time step of a whole scanline, cannot generate IRQs on more fine steps, always rounded to scanline boundaries
• Development/distribution model is "confusing", "dev" branch is not really "dev" but "next-stable", random branches carries most of the development (at least from my side), not even the same one on longer term, with confusing names ...

Also see these:

• List the MEGA65 issues: https://github.com/lgblgblgb/xemu/issues?q=is%3Aissue+is%3Aopen+label%3Atarget%3AMEGA65
• Bug summary in status/project: https://github.com/lgblgblgb/xemu/projects/2

Beyond scanline precision

Almost impossible to do even on a very fast PC, because of the relative high (~80MHz?) dot clock of MEGA65 and other things to emulate as well other than VIC-IV (also very demanding like CPU clock is 40.5MHz with "MEGA65 fast").

Proposal: stick with scanline precision for now, even that is not yet merged back to mainstream Xemu. In the future though some sub-scanline feature can be thought. Like at least border and background colour changes can be tracked with exact timing. Maybe an acceptable compromise between "scanline precision only" and "pixel level accurate emulation". Also, it can be useful though to collect what kind of beyond scanline precision can be useful and worth the effort (consider: needed CPU power to emulate, and human resource / priority to deal with these problems instead of working on other features). Another idea: use a "change queue" (events) to changed register values with precise "timestamps" during CPU/DMA emulation and use them during the scanline rendering to accurate take account of those changes (the performance bottleneck of an emulator to "break" the loop of the CPU and VIC emulation all the time into more fine time steps).

Priority: relative low, it's much more important now to have all the VIC-IV merged, optimized, fixed compatibility with known examples (like YAPED32 #212), and so on.

[lgblgblgb]

Currently, "vic" is in sync with "dev". "next" has been created to be the future "next master". Some strange issues must have been fixed with getting current branch on the used Ci services (Travis and Github actions).

[lgblgblgb]

CIA: now has "linked" 32 bit counter mode for CIA: 4b70a29