Skip to content
LGB edited this page May 17, 2021 · 7 revisions

Frequently Asked Questions

Xemu is a MEGA65 emulator, right?

Not true. Xemu is a collection of emulators within my "Xemu framework". Though it's true, many people take attention only because of the MEGA65 emulator, and probably not interested in the others. So technically speaking some would say, which emulator in the Xemu project is meant, like "Xemu/MEGA65" or "Xemu/CLCD" is the MEGA65 or the Commodore LCD (CLCD for short) emulators inside the Xemu project

Why is the name "Xemu"? Are you aware about the Xbox emulator project named as "Xemu" as well? Shouldn't be your project renamed?

For the second question, yes, I've heard about it and it was surprising for me, since I am not interested in games/consoles (thus I missed emulators of them as well). So I originally named my project "Xemu" without knowing about the "other" Xemu. But for now I'm so used the name, I wouldn't like to change it. I think the possibility of confusion is rather small, since we're talking about very different kind of emulators. There is no meaning of "Xemu" too much, the full name is "X-Emulators" (note the plural form, and see the question of Xemu being a MEGA65 emulator only - hint: no it's not) by the way, "X" meaning "unknown" or whatever, or (my original intent) the habit, that in UNIX world GUI programs (running on top of X11) usually have names starting with "X" like "xterm" (a TERMinal running on top of X11). So, originally Xemu wanted to mean "collection of EMUlators running on top of X11, targeting UNIX-like systems (Linux, etc)". Though, for sure, since a while I've ported it to be able to run on Windows and Mac too.

How to say "Xemu"? Like "Zemu"?

NOOOOOOOOO! ;) If it is "Zemu" it would be "Zemu" and not "Xemu" :) It's "X-Emu", as the name of letter "X" then "emu".

I have (insert some problem here) problem with running Xemu on Windows or Mac.

You should be aware that I've never used Windows or Mac as my daily driver (not at home, nor in workplace), my port of Xemu to these projects are mostly done "blindly" not even using those OSes, just cross-compiling on Linux, or using some CI services to have access of Mac builder environments (at least for Windows, it's kinda trivial to cross-compile on Linux). Thus it's always hard for me to resolve non-UNIX-like-OS issues in general, as I am not even user of those OSes. It does not mean, I won't help or don't want to hear about problems like this, it's just a generic warning in advance about the possible bumpy road if you want to report issues like these.

Why Xemu emulators don't have some built-in debugger/monitor?

This is something I don't plan to do ever. The reason: my idea, that debugger/monitor must be an external entity, so people can write debuggers as they wish, there can be even multiple ones ("freedom of choice") by interfacing with Xemu (thus, ideally some can even develop "plugin" for some IDEs for example). Indeed, currently it would be problematic to write some, since most of the emulators in the Xemu project can't even provide such an interface (at least for now). To be more specific, this question is more frequent with the MEGA65 emulator in the Xemu project. There, the situation is even more specific. A real MEGA65 has a debug/monitor interface, and requires to have an external debugger on your PC/Mac. Since Xemu emulates MEGA65, the same approach must be provided. This means that we can have a common workflow, ie a debugger can attach to both of a real MEGA65 and an emulated (by Xemu) MEGA65, which is really nice and consistent. Also, there would be simply no man power to code internal-to-Xemu debuggers, I don't have even "man power" to code emulators well/quick enough ... For MEGA65, the "external" utility to be able to attach to both of real and emulated MEGA65 is m65dbg however that's not the scope of the Xemu project.

Are you a Linux-maniac and Apple+Microsoft hater? Since you always complain about problems with Windows or Mac and you don't use those.

No, I have no problem with those OSes (well, I have if I need to "fight" them, but that's another question), just those are not my choice, that's all. If I hate them, I wouldn't port Xemu to be able to run on them which required many hours of my life (as a port of my hobby activities, since Xemu is a hobby, and free of charge, open source software) to learn about Windows and Mac programming just for the purpose that I can provide Xemu for the users of those OSes. I don't need these OSes in my daily life, neither at my professional work, thus really, I learnt about them only for Xemu and their users. You really can't say then I hate them, or I hate users of these OSes.

Does MEGA65 emulation within the Xemu project "runs" the same core as the FPGA do in a real MEGA65? Can I "run" alternative cores of MEGA65 in Xemu/MEGA65?

No. Xemu/MEGA65 is not an FPGA emulator, but a MEGA65 emulator (to be precise, emulation of the core named "mega65-core" designed for the MEGA65 hardware platform). Emulating an FPGA in general is kinda impossible in real-time. There is a reason some projects use FPGA, if it is so easy to emulate an FPGA in general, nobody (well, not as much ...) would care since developing/using FPGA based solution in general are harder than programming a CPU and such. Xemu/MEGA65 is a "normal" emulator, just like a C64 emulator emulates the behaviour of a C64, and not the actual wires, electrons in wires, resistors, etc in a C64. The same for Xemu/MEGA65 it does not deal with the hardware level (which is the FPGA in this case) but "only" emulating the behaviour of the mega65-core. That also means of course, no, Xemu does not emulate other cores. Quite naturally, a C64 core on the physical MEGA65 hardware must be emulated by a C64 emulator. The ZX-uno core of MEGA65 must be emulated by a ZX Spectrum/Uno emulator. And so on ... This is also the reason I put the word "run" within quotes in the question: it's not really "running" a core, since "running" usually means running a software, while FPGA is a hardware, the "core" is not a software for this hardware, but a description of the hardware "wiring" done.

Clone this wiki locally