It is time to make a esay emulator of the MEGA65.
It would increase software for the C65.
It is time to make a esay emulator of the MEGA65.
It would increase software for the C65.
??? Why did you open a new Thread ?
Aren't you satisfied with the answer in your first one here:
@commodorecracow Your post here is a bit confusing. First of all, yes, there is already a thread about this. But anyway: you wrote about a "Mega65 emulator" then you stated it may help to have more software for the C65.
It's not clear for me, that you mean about only the C65 feature-set then, or the tons of things on top of it too, what Mega65 can provide. For example, in Xemu, there are more emulators, a C65 and a M65 too (among others, for example Commodore LCD too, which is in fact much more rare than C65 - it's estimated only five machines exists - and I wrote the first emulator - which was ported into my Xemu as well - which is capable of emulating it - with the original ROM dump I have from Bill Herd Commodore ex-engineer).
Second, I have the feeling that the point of your post is "easy", meaning that Xemu is "too hard". Well, that's probably true, but for a software development (the name of this thread) a programmer should have enough knowledge to deal with this problem. You can't do it much easier, as a real mega65 hardware would also require to construct your SD-card, it's not so different than the emulator itself.
Paul makes wonderful work btw to make things more easy, ie SD-Card "partitioner and formatter" built-in, but still you do the ROM yourself. In case of an emulator is always harder. Think about this: kickstart of Mega65 is "built-in" in the bitstream what FPGA got. However that's not so nature for the emulator, and it's really not the same as for a C64 emulator to have the C64 ROMs, since Mega65 kickstart changes every week almost at this phase of development with other things too.
Conclusion: I think, if someone want to do something now, he/she need to accept that in this phase, there is no an absolute "easy way" to do (and anyway, a software developer/programmer should be smart enough to solve these problems) by the nature of the "problem" and the development phase of both of the hardware platform and Xemu too.
But anyway, please do not feel my comment as being offensive or anything. If you have more detailed points what you mean, I could provide better answer maybe. Just keep in mind, that it's a hobby in free time for me (I mean Xemu) and basically a single man project. Also, currently it's more important to work on the emulation itself rather than making it easier to use or more user friendly. What would you do with an emulator which is extra user friendly and easy to use but lack of almost everything in the sense of emulating the Mega65? :)
And, I think too, that the other thread would be better place to talk about the emulator. "C65 software development" is also a nice topic to have, but it should be about the actual programming of C65 (or M65?) and not too much about the emulator, at least not "directly". Well, this is - for sure - an "IMHO" kind of statement from me, which is true for my other opinions as well :)
there will never be a lot of software for C65 - its that simple :)
Maybe (if it is not too difficult to implement, or not already too late to do so) the MEGA65 might include a backward compatible C65 operating mode in itself. For example, if you turn on the machine in its native mode, and type in a GO65 command or something alike, that (similarly to the GO64 one) re-configures the machine as a pure C65 system: by permanently disabling all MEGA65 changes/extensions and the additional features.
Then it could also have a C65 "emulator" on its own.
@rosettif Actually, M65 boot into "C65" so no need for "GO65". If you think about the extra features M65 provides you need to enable VIC-IV I/O mode first, so you can access the extra I/O registers and features needed for M65-specific things (what I can see here: actually M65 is a greatly enhanced C65, so it's the logical step in my opinion, even the case is planned to be C65-like). You can say - for sure - to switch into C64 mode though, with "GO64" which was also part of C65. That has several problematic aspects on a real C65, for example the read-modify-write opcode works different (which is one of the major C64 compatibility issues, eg the well known trick to acknowledge VIC interrupts on C64 based on the RMW behaviour), also the timing of VIC-III is different (and one of the most interesting part: as far as I can remember, VIC-III changes mode only at the end of a character line). Oh yes, and the different CPU, lack of "illegal opcodes" etc. Again, I can say, that in my opinion it's kind of nice that these can be "cured" on M65 at least, to have a better (even if not perfect) C64 mode than C65 could provide (that's nothing compared to the C128's C64 mode of course). But the important point here, that an M65 behaves like a C65 after booting. Though, still, to be able to use M65 (or an emulator) you still need to attention to provide the system needs which is one thing over a real C65: mostly the SD-card stuff so that M65 can "boot" at least. For Xemu I plan here to create an SD-card image file (and making it default) if it cannot be found and no option is given to use some other non-default one. With this, the preparation work is not so much different than any other emulator, there you need to get ROMs (for example a C64 emulator) as well, anyway!
@LBG: It was just a quick idea from me (and maybe wrong, of course) as for seeing people demanding always backward compatibility with their already existing and known, old things.
It looks like a good idea in this respect to have those improvements on C64 mode for instance (to use the 6510 instruction set + original timing + VIC badlines + etc. á la DTV).
It might be a similarly good idea (or might not) to also preserve the original C65 behaviour as it is now for the future (only for the "safety" in a convenient way) along with the new one.
Just consider that something like the "mono check" for sound design & audio mixing.
@rosettif What "mono check" is? You mean about the problem (I found this annoying too) when only one SID is uses and you hear from only left/right then? With headphones it's quite unpleasant experience. It can be addressed somehow, just hmm the problem here, that if you introduce something "against" it, it will have different behaviour than on the real M65 :-O Maybe that problem should be solved there, and an emulator just needs to follow what it wants to emulate then :)
Having a separated C65 emulator btw is cool. First of all there is no "C65" as a single standard. That machine is never released or finished. Even at hardware level there are differences. A C65 (only) emulator should emulate an "average" C65 or better, most of the versions really exists, with allowing to choose. And yes, "preservation" of the development platform (ie: C65) is a nice thing to do. At the other hand, and M65 emulator (or M65 hardware itself too) it's "just" want M65 is decided to implement as "C65" in its own sense. For example M65 fixed the RMW behaviour for better compatibility in C64 mode, but it's not the case of a real C65. And so on (the plan to have "CPU personalties" maybe bound to I/O mode is like this, it can greatly improve the C64 mode compatibility but again, it's something never existed on a real C65). Also, trying to emulate C65 is also cool, that it's more simple than the M65, so it's easier to even try new things out at emulator level/emulation techniques which is anyway "close enough" what M65 may want too.
What I see more or less to be true: as C65 is not a "single" platform, and not even easily accessible (it would costs a lot to buy a C65, but there is not so much good C65 emulators either out there, afaik mame/mess can emulate it, I've never tried, but only several years ago) so what M65 does here may create the "C65 standard" in some form what never existed for real before because of the lack of finished development of C65 by Commodore. It's another question that it even extends it, creating a second new "standard" ie the M65.
I really like C64DTV, by the way. I really miss the continuity of that platform. I've had chat with Jeri Ellsworth once, and she stated that the major problem not having enough time to really do what she wanted over the basic design principle that it should run the games what it was shipped with. All the new features she pushed in was essentially an "optional" feature, and I think it's only her attitude to even put in, as nothing would use it in its default entity it was sold for (ie run games it was shipped with, all the other stuffs of usage meant to be "hacking" by the user than the "normal" purpose already). This is more or less true for some critical point of C64 compatibility as well. If it could run the desired on-the-flash software it was OK (even if it means to modify the games when it was more easy, I guess). Anyway, what she told me, that she would really like to release it as a more "computer form" factor, with finished features (ie overscan mode, some compatibility/timing differences with real C64, etc etc) and more number + more easy "hacking". Just she doesn't own for real the Verilog sources, as it was a contract stuff to make it. Or something this I had the idea about after reading her messages (I can be wrong to interpret all of these after a short chat, so please do not take my word that she really meant all of this!). But, what I wanted to say, C64DTV for one aspect had more easy task: it's basically a C64 + enhanced stuff. And C64 is a quite well defined notion how it should work on deep hardware levels. It's somewhat more complicated in case of C65, so M65 too, where M65 is basically a C65 + enhanced stuff originally.
Again, these are only my personal thoughts and feelings, as always.
Oh, and what I wanted to write with DTV as a major point: M65 at least open source, while DTV is not so much ...
@LGB: Sorry, I was not reflecting on the emulators, just my general thoughts about the "C65 Software Development" theme here. Mentioning the "mono check" was an abstract parallel for relation between the C65 and the MEGA65 - like a sound engineer when making a stereo mix, he always needs checking the mono compatibility of that (for radios and other sound systems). Similarly, when developing for the MEGA65, it might be useful to be able to be comfortably checking backward compatibility with all possible other implementations of the C65 environment(s), for the safety (or vice versa, when developing for the C65, checking if it also runs on MEGA65). Sorry for the misleading. :) I didn't know what the intention of mentioning these two things together was here; only saw this topic coming up and threw my personal point of view on top of that.
Your friendly neighbourhood moderators: Deft, gardners, MARCOM