Request to add compatibility for Magic Desk Plus
C64/Amiga emulator with shader and runAhead
Brought to you by:
piciji
You might consider adding the management of this project:
https://github.com/crystalct/MagicDeskPlus
Thanks
Anonymous
I'm adding it to the to-do list and will try to schedule it for after the Amiga 68020 emulation, provided no one else has taken it on by then.
Hi PiCiJi,
Just a quick update: I have already implemented MagicDesk Plus support in Denise.
Everything is working well so far, including the SRAM/EEPROM persistence, although I'm still doing some additional testing (currently under macOS only).
Once I'm happy with the results, I'll submit the patch.
Claus
nice,
There will be another release at the end of August before I start working on the Amiga 68020 CPU. Maybe we can get it included.
Hi!
I was wondering if you plan to use one of the existing 68020 emu engines or make a completely new one?
In the case of the first one I asked AI: What's the best 68020 emu engine?
AI: The best Motorola 68020 emulation engines are Musashi, Moira, and UAE/WinUAE.
Then AI asked me what project I needed it for?
The project would be implementation of 68020 into Denise emulator.
AI: Integrating a 68020 into the Denise emulator requires a core that perfectly matches its strict cycle-accurate design, runAhead latency reduction, and internal deterministic architecture. Denise's custom Amiga component implementation uses detailed inter-instruction timing clocks.
AI: The Best Fit: Moira (Shared DNA, RunAhead Compatibility, Clean Abstraction)
PS. That would be it in short, otherwise the answers would be longer.
Cheers
This is not a forum. It becomes difficult to capture information relevant to the ticket when irrelevant topics are discussed.
Sounds like a bot to me, especially because it’s so general and about Amiga, whereas the thread is about a C64 thing.
Regards,
Retronic-Designs
To be honest, it's partly your fault as well for mentioning Amiga 68020 emulation twice.
The bots are really getting better and better. lol
Peter
It's more likely to be a troll.
The troll found some more bugs in the emulator but he doesn't care anymore.
^_^
I have opened a ticket for VICE, and attached the patch for it there.
I also will attach the patch for Denise here.
I have tested the patch on both machines, macOS and Windows. So far I did not see any crashes or other problems.
And normal Magic Desk cartridges are still working as expected.
Hi,
Since the card receives a new ID and has a more complex architecture, it should be assigned its own category in Denise.
The Magic Desk (Standard) version can remain as it is.
A new category also offers the opportunity to make the interface more user-friendly. The Final Chess Card serves as a comparable example.
EEPROM and SRAM data should not be stored within the ROM file itself.
For example, EEPROM files containing game saves are distributed online for GMOD2.
These would not be interchangeable if the copy-protected ROM is included.
For MDP, multiple slots could now be set up to accommodate future modules:
MDP ROM 1:
MDP ROM 2:
MDP SRAM 1:
MDP SRAM 2:
MDP EEPROM 1:
MDP EEPROM 2:
Some UI adjustments (program/media) will likely be necessary—see the Chess Card.
SRAM and, especially, EEPROM should always be optional. I like the idea of using battery-backed SRAM as a RAM disk, but I find the EEPROM unnecessary. Especially in emulation, there is hardly any reason to assign an EEPROM file.
Addendum: Denise features a separate UI for generating empty files—such as disk, tape images, as well as Flash or EEPROM for GMOD2 or battery-backed SRAM for the ChessCard. I plan to rework this globally later so that a "shortcut" button for creating an empty image appears right next to the SRAM/EEPROM/etc. selection button within the individual CRTs UI; otherwise, some users might not find the creation UI.
Changes that might affect you: GMod2 now has its own category. This simplifies the code, and some of Cart's virtual methods have been removed.