Xemu new "stable" release #348
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Thanks to Paul, I had to realize that MEGA65 in hypervisor mode always use VIC-4 I/O mode, regardles of any KEY register ($D02F) manipulation. Previously it caused me much headache, as hyppo's source still contains I/O mode adjustments, so I supposed it's needed. It turned out, those code should be from the past when it was really needed, but it's not anymore. It also explains some anyomaly that C128 speed (1/2MHz) control was bad in Xemu: in VIC-2 I/O $D030 register controls that. And hyppo did write something into $D02F, so Xemu thought it's time to go back to VIC-2 mode (when reality MEGA65 would not, regardless of that ancient usless $D02F writing opcode which should be removed from Hyppo), and after that writing $D030 would refer the C128 speed control register indeed, while Hyppo has the intent to write VIC-4 specific $D030 instead. Now, C128 speed control register is examined by me and compared to a real MEGA65 to have the same bit meaning (and not the opposite), also the exact behaviour of reading that register. Moreover, after this relative small change, it seems freezer in Xemu started! :-O This is the first ever time it did _anything_ inside Xemu, so it's a good start ;)
Playing with Freezer starts in Xemu now, I've notice, that we can see lots of undecoded memory accesses. It turned out, there is a memory area for 1541 implementation, containing space for 1541's 4K RAM and 16K ROM. Though now I don't emulate any of these, I insert a simple "stub" for 4+16=20K of "something" in the memory decoder, to make the code happy and warning-free ;)
* 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
Xemu till now used a very ugly 16x16 pixel font for OSD. It's chunky, and even if it meant to have bigger resolution than 8x8 fonts, still worse somehow. For more serious usage, some 8x8 font would be better. Meanwhile, many places in Xemu, there is need for "VGA" kind of fonts, especially for 8x8 one (like the "matrix mode" in MEGA65 emulator). My idea: move OSD layer to to use this font, also providing it for other purposes anyway, besides the normal OS layer, simplifing code and somewhat reduce the size of the result binaries. Also, I've added some new API for the OSD layer to be used for the OSD menu project.
Required some #224 ...
Allow Xemu to be compiled and run on HaikuOS. Minor changes only: * my configure script now detects Haiku and define as "UNIX" (surprisingly it works well) * use -lnetwork when linking for "BSD socket" stuffs * deactivate root check (Haiku is single user, so ...) * using 'open' instead of 'xdg-open' (like on MacOS) Note: there is no (not yet?) Haiku native GUI, though the new OSD GUI can be used of course (as on every platforms). First appeared in the hyppo branch as commits: b79ecce f104c28 08b2a5b
Enabling the call to SDL_Quit() fixes the "does not exit" bug in Haiku.
CORE/SDL: Enabled SDL_Quit() in shutdown_emulator()
also exposing those via the UI menu
* Also introducing to use dlopen/etc functions if available (configure change) * Plugins using this interface: https://github.com/lgblgblgb/xemu-pluginguis
First try, sprite-sprite and sprite-fg collision, also IRQ generation - if the corresponing IRQs for these are enabled of course.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Changes:
-gui osdcommand line option, orgui = osdconfig file line (useful if you don't like native GUIs or if you have special scenarios like running Xemu on top of raw framebuffer on a raspberry-pi, or you use Xemu on non-Windows, non-Mac, non-UNIX-like OS)*,/,+,-on the numeric keypadRegression:
#198 (comment)
Though normally it shouldn't happen (needs overwriting I/O registers by a DMA session) but even then it shouldn't happen to hit this fatal error!