MEGA65: re-factor F018 emulation, adopt new MEGA65 enhanced mode options, plus other changes #198
Comments
|
Also see #209 since on MEGA65 at least, there is a deeper connection between DMA jobs and memory decoding. |
|
NEW: as of 2020/Dec/13: MEGA65 introduced not to warp DMA ops at 64K boundaries but within the 1Mbyte slice only. MEGA65/mega65-core#319 This is not C65 compatible, and Xemu still uses the 64K wrapping scheme. So I should modify to follow MEGA65 on M65 only (not for C65!). This comment is also put into the description above, in the hope I won't forget that this way ;) |
lgblgblgb
changed the title
|
NEW: as of 2021/Jan/27: and even for C65!! "XY MOD" mode intended for bitplane (and bitmap?) memory layout, see: MEGA65/mega65-core#351 This comment is also put into the description above, in the hope I won't forget that this way ;) |
|
NEW: as of 2021/Mar/28: new plan, fork the development of F018 to have separate code base for C65 and M65 emulation. This comment is also put into the description above, in the hope I won't forget that this way ;) |
Till now, M65 and C65 emulators inside Xemu shared a common F018 (DMA) emulation "core" with lots of '#ifdef's and other ugly tricks. However now I am at a status already when kind of fundamental things are changed in MEGA65, thus hacking a shared core makes it extremely hard to follow.
|
In commit 9d829e8 emulation of the F018 DMA chip has been forked and more/less parts removed from the C65/M65 versions which does not apply there. This way, I have more easy task to overview things without tons of emulation specific |
It seems an enhanced mode DMA's "megabyte slice selection" option remains active even for future DMA jobs, which is especially dangerous if it's a C65 DMA (without any option to set "slice"). Reported by Bit Shifter on Discord, with his new "EDMA" BASIC 10 (errr, BASIC 65) command implementation. This is only a try to fix it, really, the whole DMA emulation must/should be rewritten as of #198 ...
|
Not yet part of rewriting but there was the ugly bug above, fixed in commit e316c53 |
|
Still, it's a hack more ... :-/ |
lgblgblgb
changed the title
|
C65 and MEGA65's DMA emulations are now separate entities in Xemu, thus I exclude C65 from this issue from now on. |
* Code-cleanup from the splitting of C65/M65 common DMA emulation * More simple / shorter code at some places * Killing the "hack" mode which required before to work any decent MEGA65 emulation since years * Killing the old method to internally emulate an older MEGA65 DMA behaviour (see the hack above) * Killing the ugly macro'ism between io/memory mapper and DMA emulation * Killing some very old and useless comments, not even valid anymore * Simplifying the DMA chip revision keeping * Bug fix: do not warp around with DMA list reading on 64K/1M boundaries * Bug fix: reading DMA registers are more valid task now, before *all* registers got the status read ... * Enhancement: support for the enhanced option $90 for >64K DMA session lengths * Unfinished: DMA list reading by CPU mapping (the actual reading is not done yet, but detected) * Still TODO: line-drawing mode, maybe Shallan-spiral mode
|
https://discord.com/channels/719326990221574164/781481205639020554/977324642438111235 This is kinda scary, as it shouldn't be even possible to hit that sanity check failing ...
UPDATE (as for 2023/Feb/13): this seems to be a condition, when a very buggy program tries to overwrite DMA I/O registers itself from a DMA session. Though there is protection against that in Xemu, there was a two step "locking" which makes no sense and introduced some race condition anyway. At least this is my best guess. Currently I'll use only |
* Implementing $D706 triggered DMA session, when address is "CPU address" * Implementing $D707 triggered DMA session (in mega65-core it's not done yet, but planned!) meaning "in-line DMA": the address is from CPU PC automatically, only $D707 must be written, DMA list bytes read by PC, and after the DMA session, CPU execution continues after the last byte of the DMA list ($D706 is simply any 16 bit CPU address, not the PC based scheme!)
|
Note about #366 , where it turned out MEGA65 implemented DMA I/O mode only for |
For issue #366 : it seems MEGA65 implements the DMA I/O usage as a conditional one, ie a kind of mixed mode, when every $xxxDxxx during the DMA is I/O access when it was requested, but otherwise the normal memory access. I _guess_ this is not how it should work, but this is now how MEGA65 implements this, so let's follow the MEGA65 path For generic DMA issue #198 : the "DMA warps around in any 1Mbyte slice" was implemented since a while, but it seems to be buggy in Xemu. Hopefully I've fixed that now. Freezer seems to be able to resume (F3) the frozen task now, which was not the case before! Also some generic albeit small refactoring of the DMA code in general here and there.
|
Observation on For the former, I also have that as a comment in Xemu's DMA code as TODO (unknown function). For the first topic, it also touches the hypervisor enter/leave code in |
|
Yet another MEGA65-core observation: DMA status is always zero on MEGA65. It should not matter too much, as nobody can see its value during a DMA (when CPU is stopped, and DMA sessions are uninterruptible). The only esoteric case I can imagine, when a DMA session is made to copy its own status register to memory, and let the CPU examine that later. However it's kinda unrealistic scenario. See again this to learn more: MEGA65/mega65-core#668 |
|
As far as I see, basically two major things left for realistic goals: line drawing and maybe the "shallan-spiral" mode. Not sure, if it shouldn't be made as a separated issue already. |
|
DMA line drawing test program: https://github.com/MEGA65/mega65-tools/blob/master/src/tests/test_290.c |
Small fix for more sane debug output when DO_DEBUG_DMA is defined for some extra DMA information. Nothing here which should affect an average user, only in a very unlikely scenario: One limitation of DMA emulation in Xemu: enhanced mode option list is read in a blockling fashion, thus an "unended" list will stall the emulator (though it's unlikely not to meet a zero byte sooner or later in the memory). To avoid this (and also warn the user about something fishy is going on) there is a warning window in that case - as the number of enhanced mode options are limited, it's simply insane to have a very large option list, thus it's a certain sign of some bug in the software which produces this: better the user to know.
Small fix for more sane debug output when DO_DEBUG_DMA is defined for some extra DMA information. Nothing here which should affect an average user, only in a very unlikely scenario: One limitation of DMA emulation in Xemu: enhanced mode option list is read in a blockling fashion, thus an "unended" list will stall the emulator (though it's unlikely not to meet a zero byte sooner or later in the memory). To avoid this (and also warn the user about something fishy is going on) there is a warning window in that case - as the number of enhanced mode options are limited, it's simply insane to have a very large option list, thus it's a certain sign of some bug in the software which produces this: better the user to know.
|
The main and most important missing piece of DMA emulation is "line drawing mode", this is now a separate issue and handled there: #404 |
|
I'm closing this. The remaining issues should go into the corresponding specific issues, like #404 for the line drawing DMA mode, and so on. |
F018 DMAgic emulation is a shared resource in Xemu for C65 and MEGA65, though it compiles very differently for MEGA65 based on #ifdef's and such. However the emulation itself is very old, using a method for MEGA65, which is not supported by MEGA65 itself since maybe years. To bridge the gap, emulation has a workaround to mimic the old behaviour "simulated". Which is really confusing and error-proof. Also since then there are new MEGA65 DMA features (even a "new" C65 one).
Goals
"Not now" (or never?):
Unknowns:
DONE:
Regressions:
See: MEGA65: re-factor F018 emulation, adopt new MEGA65 enhanced mode options, plus other changes #198 (comment) comment(UPDATE: it is "probably" fixed, see the the comment)Implementation
For all of these problems, the logical choice is to rewrite largely the F018 emulation, by extending it also with the new features.
Seeing that C65 and M65 DMA is becoming more and more diverse and the original idea to have a common emulation core become making less and less sense (but causes very ugly and hard to follow code with tons of
#ifdefs) the only logical conclusion to do these:The text was updated successfully, but these errors were encountered: