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.

Sign up for GitHub

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

Jump to bottom

MEGA65: re-factor F018 emulation, adopt new MEGA65 enhanced mode options, plus other changes #198

Open
lgblgblgb opened this issue Sep 22, 2020 · 14 comments
Open

MEGA65: re-factor F018 emulation, adopt new MEGA65 enhanced mode options, plus other changes #198

lgblgblgb opened this issue Sep 22, 2020 · 14 comments
Assignees
@lgblgblgb
Labels
alternative solution cleanup-maintainability emulated feature emulation precision enhancement optimization REGRESSION target:MEGA65 WIP
Projects
MEGA65 emulator project
Milestone
MEGA65 new mem+I/...

Comments

@lgblgblgb
Copy link
Owner

lgblgblgb commented Sep 22, 2020 •
edited

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

  • Support for MEGA65 new enhanced mode options for line-drawing and similar

"Not now" (or never?):

  • NEW: as of 2021/Jan/27: and even for C65!! "XY MOD" mode intended for bitplane (and bitmap?) memory layout, see: implementation of XY MOD for DMA transfer MEGA65/mega65-core#351 It is unclear that MEGA65 will support this currently, and when ...
  • MEGA65 supports special FDC related DMA modes to copy "flux" directly. It does not make too much sense in case of an emulator, so probably I won't be able to support that, though some warning would be nice to see)

Unknowns:

  • How exactly stepping is calculated on MEGA65? We have C65-style hold/dec/inc info, also M65-style (enhanced mode DMA option) integer+fractional step byte values
  • In "CPU address" DMA mode, only DMA address list is read by this policy or all memory operations? If the second, my implementation is very wrong!
  • It seems MEGA65 disables the I/O for the time of DMA when (?) it's by "CPU address". Not sure how it works, my implementation clearly lacks this!

DONE:

  • Support for MEGA65 transparency (DONE as of 2021/Jun/7)
  • Support for cross 64K boundaries (not C65 compatible behaviour, but this what MEGA65 does it seems), but having 1Mbyte boundaries instead
  • Support for $D706 triggered DMA lists, where list address is by CPU address
  • Support for $D707 triggered "code in-line" DMA list: CPU's PC is used to fetch DMA list bytes, and CPU's execution flow continues after the last read list byte automatically when DMA session is done: In-line DMA jobs MEGA65/mega65-core#580
  • Re-factoring DMA emulation, killing all the bits of the old C65/M65 emulator dual-usage heritage of the DMA emulation source code, also killing remains of the old-MEGA65 behaviour when some registers were used for functions now controlled by enhanced-mode DMA sessions only

Regressions:

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:

  • Fork DMA emulation for C65 and M65 ( done in commit: 9d829e8 )
  • Clean C65's forked one to have only the C65 related parts left, other clean-ups, kill M65 specific cases ( done in the same commit as above)
  • Rewrite the M65 part, with all the new features keeping in mind, without C65 legacy what M65 does not want to deal with anyway (like 64K wrapping)
@lgblgblgb lgblgblgb self-assigned this Sep 22, 2020
@lgblgblgb lgblgblgb added this to the MEGA65 new mem+I/O+VIC milestone Oct 13, 2020
@lgblgblgb
Copy link
Owner Author

Also see #209 since on MEGA65 at least, there is a deeper connection between DMA jobs and memory decoding.

@lgblgblgb lgblgblgb mentioned this issue Dec 7, 2020
Closed
@lgblgblgb
Copy link
Owner Author

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 lgblgblgb changed the title MEGA65+C65: re-factor F018 (DMAgic) emulation, adopt new MEGA65 enhanced mode options MEGA65+C65: re-factor F018 (DMAgic) emulation, adopt new MEGA65 enhanced mode options, plus other changes Dec 14, 2020
@lgblgblgb
Copy link
Owner Author

lgblgblgb commented Jan 27, 2021 •
edited

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 ;)

@lgblgblgb lgblgblgb pinned this issue Mar 28, 2021
@lgblgblgb
Copy link
Owner Author

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 ;)

@lgblgblgb lgblgblgb added the WIP label Mar 28, 2021
@lgblgblgb lgblgblgb moved this from TODO to In Progress in C65 emulator project Mar 28, 2021
@lgblgblgb lgblgblgb moved this from TODO to In Progress in MEGA65 emulator project Mar 28, 2021
lgblgblgb added a commit that referenced this issue Mar 28, 2021
@lgblgblgb
M65+C65: fork F018 DMA emulation for C65+M65 #198
9d829e8 
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.
@lgblgblgb
Copy link
Owner Author

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 #ifdefs.

lgblgblgb added a commit that referenced this issue Apr 7, 2021
@lgblgblgb
MEGA65: try to fix DMA for sticky options problem
e316c53 
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 ...
@lgblgblgb
Copy link
Owner Author

Not yet part of rewriting but there was the ugly bug above, fixed in commit e316c53

lgblgblgb added a commit that referenced this issue Jun 7, 2021
@lgblgblgb
Implement DMA transprent write #198
1b00924
@lgblgblgb
Copy link
Owner Author

Still, it's a hack more ... :-/

lgblgblgb added a commit that referenced this issue Jun 7, 2021
@lgblgblgb
Implement DMA transprent write #198
2c16e76
lgblgblgb added a commit that referenced this issue Jun 12, 2021
@lgblgblgb
MEGA65: Implement DMA transprent write #198
573b7b4
lgblgblgb added a commit that referenced this issue Jun 14, 2021
@lgblgblgb
MEGA65: do 1M warp around instead of 64K #198
8e9fb86
@lgblgblgb lgblgblgb moved this from In Progress to Rejected in C65 emulator project Sep 27, 2021
@lgblgblgb lgblgblgb removed this from Rejected in C65 emulator project Sep 27, 2021
@lgblgblgb lgblgblgb changed the title MEGA65+C65: re-factor F018 (DMAgic) emulation, adopt new MEGA65 enhanced mode options, plus other changes MEGA65: re-factor F018 emulation, adopt new MEGA65 enhanced mode options, plus other changes Sep 27, 2021
@lgblgblgb
Copy link
Owner Author

lgblgblgb commented Sep 27, 2021 •
edited

C65 and MEGA65's DMA emulations are now separate entities in Xemu, thus I exclude C65 from this issue from now on.

lgblgblgb added a commit that referenced this issue May 4, 2022
@lgblgblgb
M65: DMA cleanup/reorg/bug-fixes/enhancements #198
ffb3a9a 
* 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
@lgblgblgb
Copy link
Owner Author

lgblgblgb commented May 21, 2022 •
edited

https://discord.com/channels/719326990221574164/781481205639020554/977324642438111235

This is kinda scary, as it shouldn't be even possible to hit that sanity check failing ...

fatal

fatal2

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 in_dma variable for everything, so it must be gone away ... The change is not committed yet at this point, soon it will be!

@lgblgblgb lgblgblgb mentioned this issue Jun 13, 2022
Merged
lgblgblgb added a commit that referenced this issue Jun 16, 2022
@lgblgblgb
M65: implement CPU-addr DMA-lists #198
3c7f169 
* 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!)
@lgblgblgb
Copy link
Owner Author

Note about #366 , where it turned out MEGA65 implemented DMA I/O mode only for $Dxxx addresses so for real it's a mixed mode I/O and memory ...

lgblgblgb added a commit that referenced this issue Feb 9, 2023
@lgblgblgb
M65: fix DMA I/O mode #366 - 1Mbyte alignment #198
c77f01a 
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.
@lgblgblgb
Copy link
Owner Author

lgblgblgb commented Feb 10, 2023 •
edited

Observation on $D653 and $D654 also the reg_dmagic_withio signal: MEGA65/mega65-core#668

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 hypervisor.c which should be refactored a bit with dma65.c as well not to use the dma_registers array but basically construct everything on-the-fly, and the only external variable from dma65.c in this respect should be the list_addr stuff.

@lgblgblgb
Copy link
Owner Author

lgblgblgb commented Feb 13, 2023 •
edited

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

@lgblgblgb
Copy link
Owner Author

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.

lgblgblgb added a commit that referenced this issue Feb 13, 2023
@lgblgblgb
MEGA65: refactoring DMA emulation code #198
2c06289
lgblgblgb added a commit that referenced this issue Feb 15, 2023
@lgblgblgb
MEGA65: refactoring DMA emulation code #198
9084f2d
@lgblgblgb
Copy link
Owner Author

DMA line drawing test program: https://github.com/MEGA65/mega65-tools/blob/master/src/tests/test_290.c

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@lgblgblgb lgblgblgb

Labels
alternative solution cleanup-maintainability emulated feature emulation precision enhancement optimization REGRESSION target:MEGA65 WIP
Projects
MEGA65 emulator project
In Progress
Milestone
MEGA65 new mem+I/O+VIC
Development

No branches or pull requests
1 participant
@lgblgblgb