Posts by LGB-Z

Thanks for the answer. I see, fair enough, probably I would try that too, so I can have the experience if I were you. I am about to put at least a warning (till it's usable), so there is a more clear feedback that is not yet implemented.

Freezer has never worked in Xemu yet. So it's still something I must solve sometime in the future, of course. Probably it's a hard thing to solve, I would guess, since it requires many things to be emulated quite well, which is not needed at all for most other "normal" programs (ie, for freezer many hypervisor specific functionality missing or so - what I can guess now).

By the way just for curiosity, what would you use freezer for, in an emulation? I guess not as useful as on a real MEGA65, as many things can be controlled via menu etc, instead of the FREEZER (surely not the "freezing slots" feature). It's not that I want to argue on the importance Xemu to be able to use freezer (as an emulator should emulate everything to be complete and good), just I am curious to see the usage patterns and the reasonings of Xemu users, so I have better idea what should be the priority in the development, etc.

Quote from SkulleateR

English is not a problem here And you're right, since I've not been to the download page, I didn't even know there ARE other versions

Well, yes, nature of "work-in-progress" open source model projects, there are tons of branches with different maturity from the context of different features/plans/etc, surely at one point in the future: "there can be only one" (till another round of development follows ... ehmm). In contrast, closed source software usually means you see only the end product (but in this way: later, when it's ready, if Xemu is closed source, I guess no Xemu at all till for some years from now hehe ... considering the state of "ready" when even MEGA65 itself is not "ready"). So these are not exactly different versions (ok, you can name those that way if you really want) but development branches.

Branches "next" and "master" is really bad in terms of VIC-IV emulation, "merger" should be used for some sane result. Actually this fact is advertised on the download page, but for sure, for some wants to _compile_ Xemu and not just download binaries (and no raspi version built, so it's understandable ...) it's not very clear, I have to admit. Again, as in the other thread sorry for the English answer.

Sorry to answer in English, but I don't speak German, and I even used google translate to be able to understand the discussion here. Since you want to _compile_ Xemu you don't need only the GTK3 libraries but the development version as well (surely if you also _compiled_ VICE with GTK3, then it's fine). As README of Xemu says, you need to have the "libgtk-3-dev" package (I believe at least, it's the same on raspi as well).

Just to mention for curious ones, it may worth to try the "merger" branch of Xemu at usual download place: https://github.lgb.hu/xemu/

In the last 2-3 weeks we had very intensive work with Shallan , who writes test programs (and test results + analysis on the nature of problems) and I try to fix bugs and differences in Xemu (especially in the kingdom of VIC-IV for now) compared to the real hardware (moreover he even had some direct contributions as well) in that branch. Though for sure, there can be stability problems (it's not guaranteed it won't crash), and that branch requires more CPU power to run, but unfortunately it's the nature of emulation: more precise emulation needs more CPU power to do so. hernandp will join the work too, he has some "real world things" to manage at the moment, but it's important to note, that this work now is based on his code written to replace my very first and very crude preliminary VIC-IV emulation initially (which is still used in the master and next branches btw).

Of course I can't say everything is resolved for now (or even that there can't be regressions and some more "bad" versions temporary in that branch), but this code even now is far more compatible than "hmw" (Hernan's experimental VIC-IV branch) was. Of course this work will be the "default" version some time in the future. The focus is still on getting better emulation of MEGA65 "advanced" features (thus maybe not so much about "C64 mode", for example) which were emulated bad, or even missing, or being changed. Since there is active work on this branch, it's sometimes quite possible to have more new versions within an hour or so, and other interesting happenings, this is just the nature of an active/open development model of an open source project.

Note, that the priority - so far - with emulation is not about the "C64-featues" at all, since those C64 titles can run very well in a C64 emulator Instead, most of the work is on emulating MEGA65 features better, especially since these are wanted to be used by people and try it even before having any real MEGA65 (including Nexys board) or as a help development for MEGA65 (and not for C64), etc etc. Surely, on the long run, every feature should be emulated well (at least as well as MEGA65 can do), it's just there are more things to do than time to do it, so there must be a priority list on development.

At the other hand, if someone really want to try C64 games for example, it's still better if they try the hmw branch instead, or - if really brave - the one called "merger" (these are the bottom last two one on the download page).

Quote from Snoopy

Quote from huedrant

Great! Any advice for a Raspberry A+/B+? Is there a chance to have a MEGA65 running on one of these, maybe without the fancy VIC-IV functionalities?

I only have a Raspberry Pi 400 here to try out. In principle, the Xemu should also run with weaker Raspberrys. However, I would only recommend the xc65 (C65 emulator). It's fast enough on the Raspberry.

At least I don't know that you can switch off the VIC-IV properties of the xmega65 to achieve a faster performance. Maybe LGB-Z , the developer of the Xemu, can write something about this?

Why, you've already summarized things quite well Commodore 65 emulation indeed, is kinda OK. I would say, MEGA65 emulation should work as well, till the point somebody wants to establish "MEGA65 fast" (~40MHz) mode where the power of Raspberry PI is not so much enough any more to run the emulation in real time (still can be used, just slower than it should be). I haven't tested Xemu in Raspberry pi "since ages", so I don't know the current situation to be honest ... But the next branch of Xemu for example about MEGA65 emulation (so not hmw ...) uses a VIC-IV emulation which is so crude, it cannot be done too much with "less VIC-IV fancy stuff" So if that can't run real-time either on Raspberry, then we can't do too much, since then it's the CPU emulation performance (etc , ...) is the bottleneck. Though for sure, never say the final word, I have some unfinished works (currently not in the priority list unfortunately) to re-structure memory access emulation (and also CPU emulation) which can (just guessing now!!!) speed up CPU emulation significantly in the future.

Other than these, it's kinda interesting idea to have a "crude" VIC-IV emulation layer as well for "slow" computers. However the problem that where you draw the line. Emulated MEGA65 should "boot" and at least BASIC, and things should work, this already needs quite substance of VIC-IV emulation (even if crude) and then we would have double work to maintain two kind of VIC-IV emulations, "crude but fast" and "better but slower" :-/ But surely, it's very much depends what we think about "without the fancy VIC-IV functionalities" Without ANY video output, it would be much faster I guess, for example But that's not so much useful.

Quote from will

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

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

Not only C65 had removed cassette routines (from C64 mode as well) but it's true for hardware level as well. The C64's "CPU I/O port" (realized by VIC-III on C65 for real, but it does not matter too much here) on C65 does not even have functional bits for tape functions, only the lower 3 bits works, needed for memory banking. Surely, on MEGA65 - in theory - it would be possible to "re-add" them, and then the software support as well in some form ... I guess.

You don't need to upload D81s, right click into the emulator window, and select FD D81 -> Attach user D81. However be aware that it seems there is a bug in the ROM itself (so not MEGA65 or Xemu related at all, but original C65 problem) which causes disk corruptions if you try to write onto the disk.

As hernandp mentioned, the "long awaited" merge of the "two divergent main branches of Xemu" is finally on its way (both of us are working on this). Though it will take some time till it reaches at least the maturity of both of the branches, also both of the feature-set to be implemented without any major bug. Currently it's totally unusable for any general purpose emulation tasks, other then for those involved in emulation development.

Quote from FeralChild

Actually, I would prefer .Z register to stay 0 all the time, it causes portability problems as described above. One of the reasons I've decided not to reuse Commander X16 DOS after all.

Actually, I'm tempted to use TBA as a replacement of LDA #$00 in the ROM, but I'm a little bit scared

But then you lose the power of another index register. Also MEGA65 uses Z register, eg with the "32 (well 28 ...) bit linear addressing mode" (yes, you can modify the 4 byte long ZP pointer but if need to "travel" few bytes relative to ZP, much faster to say INZ ...), and also the "Q" opcodes, when AXYZ forms one 32 bit register, so anyway Z will be modified. But surely, if you mean about portability in a way that you won't use MEGA65 features anyway at all, these are not legit reasons as on 65C02 STZ stores zero for example, end of story.

Quote from Snoopy

It means that STZ on the 65C02 always stores zero into the memory and on the 65CE02 the exact same command with the exact same opcodes stores the value of the z register into the memory!

If Z was set to 0, STZ behaves the same on the 65CE02 as on the 65C02.

Knowing and remember this can save you days of debugging while trying to use a 65C02 code an the C65/MEGA65! I know what I'm talking about!

Yes, that was the intent, to extend/enhance 65C02 (thus maybe the "E" in "CE" ... compared to "C") to be compatible. That is, while Z register is zero and not touched, it's totally compatible with 65C02 in this topic. Also, addressing mode of 65C02 (ZP) (without any index register involved) was changed to (ZP),Z in 65CE02. Again, while register Z is zero, it's the very same thing, compatible, but you can opt in using Z as a "true" index register on 65CE02. In my opinion is quite clever, to re-use existing opcode to offer more, but still providing compatibility as well. Btw, STZ also exists on 65816, the same story it simply means "store zero" there.

Quote from Snoopy

I had a little chat with a colleague after the business part this afternoon. Among other things, about software and how expectations have changed here.

Specifically, we also talked about the MEGA65 and the game "Tristam Island", which can be bought for around 4 USD.

My colleague refuses to buy the game on principle, because he understands the MEGA65 as "open source" and he expects that from the software too. So available for free and with source code.

I was a little amazed when I heard that. I can't understand that at all.

Just because the MEGA65 project is open source doesn't mean that you have to get everything for free (the hardware also costs money and not a little) and then you get also the source code freely available.

In any case, I have no problem if someone wants money for his software and I can also understand if someone does not release the source code.

It is still my decision whether and what I want to buy and it is also the decision of the author whether he wants some money and whether he releases his source code or not. There should be no compulsion behind it, not on both sides.

I think I am not alone here with my view? Or do you expect that all software for the MEGA65 "must" be without charge and with free code?

Display More

That's indeed a strange view. Linux is free and open source (but surely, we must be careful what "Linux" means, usually only the kernel, or we refer for a Linux distribution more, often mentioned as "GNU/Linux" since many tools/components - other than kernel - is from the GNU project ... though those components are open source as well), but surely there are commercial software for it, you must pay for, and no source code at all for them. In fact, leaving open for commercial titles are important since there can be some bigger projects some people want to have money for. Now the choice: not to allow them, and we will miss those, or have them (but not free) so everybody can decide at least it worth to pay for, or not. I think the second is better. The "platform" being open source it's just the "platform", not the things other people writes for. But as it's said, sure, your colleague can decide if he wants to pay or not for a given a software, there is no problem here. The problem more, if somebody misunderstand things and feels "fooled" that it's a trap: "but it was said it's fully open source, now it's a trap, that I must pay for some software still, after I thought it's completely free and I jumped in the project?".

In fact, something "being open source" does not mean too much for the 99% of the people, since they have no value on having the source, if they don't know what to do with the source code Imagine how much people would use Linux, if they have only source code, and not actual builds, distributions etc (which installers, binaries, packages ...). Also, worth to mention, there are software which are open source, still not free, technically.

Honestly the logic of your colleague it's like when you're informed there is a free-to-use road built, and then he cries that he needs to BUY a car also the the fuel, it's not open at all ... Surely the software case of this story is still better since there are "free cars" (ie software) to use on the platform, just not all of them are that.

Personally I feel khmm errr indeed almost everybody knows where to download those ROMs free of charge, but if someone wants to be really "nice" and legal, why they just can't pay for it, especially that this way the copyright holder gets some money at least Though hmm maybe that would cause some issues to try to ban "download free" kind of ROMs, if it's official that you can buy it. So I'm really not sure ...

I would wait for 69-SUPER-SEX though ;-P [sorry ...]

These are interesting questions. However as far as I feel, even if it's not the "open-rom" with all the own goodies it's already not "pure c65" ROM, ie using MEGA65 extensions to work, and would not work on a C65. For example, direct manipulating bitplanes are not possible in the C65-compatible way, since those are in bank4/5 now, which is not possible on C65 (and thus meaning some problem if a program directly want to access bitplanes in the memory bypassing BASIC routines to draw etc). Also, kind of "dos wedges" were common even in the C64 era (though indeed, not "original Commodore" things). That's however a good question if there can be a "pure C65 ROM" would work even on a C65 "only" with fixing some of the bugs, and unimplemented details of the original ROM. I can't answer this, but as far as I feel, it's maybe too much to ask, nobody has that amount of time to take care "only-C65" versions when the all project is about MEGA65. But I can be wrong, and I don't mind here at all if I am wrong

I would say, it should work, as it "speaks" the IEC protocol like 1541 and other "usual" drives, and MEGA65 also has an IEC port. So in long term, I see no difference between using Pi1541, SD2IEC or "real vintage IEC drive". However keep in mind, that currently AFAIK there are some issues with IEC on MEGA65 in general, but hopefully sooner or later those will be (maybe are? ...) fixed.