Hello, Guest the thread was called3.6k times and contains 35 replays

last post from LGB-Z at the

Q&A for the Xemu emulator

  • Btw, shouldn't we create another "generic" Q&A + wishlist or whatever topic for these kind of conversations? I mean this 'security question' thread is kinda misleading by its name, I think ...

    That's a good idea! Maybe a mod can change the topic? I can't change it. :thumbup:

    I guess I cannot change that either, but anyway there can be new topic open for general Q&A and bug reports or whatever at least by anybody. Though I am about the last person who is good in organizing things, so I should shut up :)

  • Btw, shouldn't we create another "generic" Q&A + wishlist or whatever topic for these kind of conversations? I mean this 'security question' thread is kinda misleading by its name, I think ...

    That's a good idea! Maybe a mod can change the topic? I can't change it. :thumbup:

    adtbm : Could you please change the thread topic to "Q&A for the Xemu emulator" or so? Many thanks!

    LGB-Z : Does Xemu support the output of both SIDs (stereo) or only one? Sadly the Nexys board only has mono audio output, so I can't hear stereo even if the FPGA has two SIDs implemented. :(

  • adtbm

    Changed the title of the thread from “Xemu - security question at F9 and F10?” to “Q&A for the Xemu emulator”.
  • Xemu supports two SIDs, left+right, though on MEGA65 emulation they're fixed and no mixer abilities. For C65 emulation, is kinda what it should do. Just SID emulation in general in Xemu has the problem that it takes account of SID register changes only at every audio buffer fill, which cause "strange and wrong" results, and absolutely render digi playback impossible ... :-/ at least for now.

  • Snoopy done

  • LGB-Z : Many thanks for your answer!

    I have another question: :whistling:

    Is there currently a way to connect/use the Xemu (xc65 or xmega65) to the net (via the host PC) (by simulating Ethernet or something like that)?

    Yes and no, mostly no ... I mean there is ethernet emulation, but not so much usable because:

    1. works on Linux only (OS specifc tun-tap interface usage)

    2. very bad threaded code, often fails ... :-/

    3. emulates the old ethernet behaviour of MEGA65 not the current design ... :-/

    4. even the problems I've described, the other problem that some may need a bit deeper network administration knowledge to make it work, like creating tap device before, and such

    And sure, since only MEGA65 has ethernet, not C65, only applies to the MEGA65 emulator not the C65. The code should be rewritten because of the problems above. I'm especially unsure what to do with Windows (or Mac) though.

  • LGB-Z ,do you think it takes a lot of effort to get the xmega65 to run slower? So instead of 100% speed e.g. only 10%, 1%, 0.1% (best freely selectable)? For the C64 there is a module called "C64 Schnecke" (C64 snail), which does exactly this: Slow down the C64 with a potentiometer down to "single step" mode or 0% (freeze).

    This would sometimes be quite helpful for debugging or just slowing down to see what is happening on the screen. :)

  • Yes, it's kinda possible, use a very slow PC to run Xemu ;) OK, seriously now: if you're OK to use the "fast clock" mode (ie, the ~40MHz) you have the value that at least you can override (from command line) what the fast clock should be with the -fastclock option. Yes, that's not the same as you describe, and it does not affect all the possible clock modes of MEGA65 (only in ' MEGA65 fast' mode), and not settable at run-time. Otherwise it wouldn't be too hard to implement this proposed feature in theory, in practice however, it's kind of annoying as there are lots of timing related code, and all of one should be connected with some possible "make it slower" factor, without endanger the timing interaction between certain sub-systems. But OK, fair enough, hopefully once I implement this too, just not too much the top of the priority list now, because of the works which should be done first ...

  • Is there a way to jump into a monitor like it can be done with VICE?

    In particular, I would like to view the status of the VIC-IV chip to see at what addresses are currently used for charset, sprites, etc. and to inspect memory areas.

    No, and never be, this is a design choice, and based on the fact that machines emulated by VICE and MEGA65 is very different from this perspective. In case of a C64 (let's say emulated by VICE) it's very legit question that you want an advanced debugger would not so much possible with a real hardware at all at least "that much". However MEGA65 is different, since it provides a way of communication for exactly this purpose. That is, if you have "real" MEGA65 you can still attach a "kind of debugger" to it, in the form of an USB cable to your PC/Mac, for example. Since Xemu needs to emulate the real machine which is already provides a way to do that, it's true for Xemu too, rather than creating a very complex solution to allow both of "internal" and "external" debugger to work. The other plus for external debugger that it's not part of the core emulation, so it's much more easy to develop independently, also even multiple ones based on the user needs. I talk mostly about m65dbg which can be used to be attached to both of a "real" MEGA65 and also Xemu. Though that's true, it's not exactly a GUI-heavy tool. One missing component (currently) in Xemu's MEGA65 emulation though in this topic, that it does not implement yet the so called "matrix mode" of MEGA65 which would allow kind of "internal debugger" in the form of a HUD-like shaded "console" in front of the video output. But actually it's kinda same as the "debugger connection" just can be used without an external tool then. Surely, I'm planning to implement matrix mode some time, but currently debugger related questions are at not so much high on the priority list, not because it's not important, but we have more serious problems currently left ...

  • Because it was in another thread here about user numbers, just here the question to LGB-Z : Do you actually have a statistic, how often the xemu has been downloaded from your site? At least an order of magnitude would interest me. Was that 100 times, 1000 times, 10,000 times?

    No idea if github pages has statistic information, since it's that, just by assigning an own domain name with it. So I don't know. Honestly it never even something I was thinking about before, but now - thanks to you ;) - I would like to know as well ;)