Making a C64/C65 compatible computer
Friday, 2 September 2016
MEGA65 Emulator can run kickstart and disk menu
Just a quick post while I am on the road to share Gábor's latest progress on the MEGA65 emulator: It can now run kickstart and supports hypervisor traps and SD card access, sufficient to boot, and run the disk menu program (which makes heavy use of hypervisor DOS calls):
Subscribe to:
Post Comments (Atom)
Hi, thanks for blogging me :) Though to be honest, it seems directory reading trap for some reason stuck in hypervisor mode if no other files can be found in the root directory. Hopefully I can figure out soon, where is the problem :)
ReplyDeleteWhere can i download the emulator?
ReplyDeleteWell, you can, but beware, it's more intended for developers currently, ie debugging turned on, FPGA board switch #12 is emulated to be on (which really slows things down but by intent), and so on. Also (emulated) F011 disk I/O does not even work. However, here you are: https://github.com/lgblgblgb/xemu Maybe it's a good idea to tap on the "Wiki" tab to more information how it can be tried at all :)
DeleteHello, this is Richard Balkins. I am a software developer / video game developer among other things. In the meantime, I want to DL the emulator for testing. Eventually, I want to get one of these Mega65. By bringing this project to the mainstream Commodore community and eventually a good emulator available will make ability for people to support the games but also the Mega65. There is some things owning the real hardware will gain the user that is less achievable entirely in the emulation experience. For testing purpose during development, this is entirely fine.
DeleteI prefer not having to 'build' the emulator. I like the emulator already in ready to boot order like VICE even if it is in a Alpha version of the emulator and not perfectly set up. I'm using Windows 10 so 32-bit and 64 bit Windows executables should run.
Doing the builds can be a pain in the butt because I don't necessarily have the tool chain set up the way the build file expects and I don't want to go through that kind of headache. If I am writing a game, I have my hands full as it is.
This is not intended to criticize anyone but ideally I don't want to spend too much time trying to go through a bunch of hurdles to get an emulator running for testing a video game or other software.
I like the progress going so far.
That's an understandable opinion. But please note, that the project is in quite early stage. Now it's more important to work at all (and implementing more and more features, also M65 is kinda moving target still to be emulated "fully") rather than being user friendly, especially because currently it's more useful for "deeper" M65 developments than for "end users". Of course I plan later to form it in a way to be more user friendly, at least binary distribution for Windows, OSX and and popular Linux "favours" are planned. Also, currently, it expects from the user to construct the SD card image for themselves, which also can be a limiting factor for the end user. This will be also targeted, in a way that an "average user" can just start the emulator and that's all (though still providing the possibility for developers to do this according to their own way for special needs). So what you wrote is exactly that, what I also have as ideas for the future. Features like these are not so hard to implement after all, but since the whole emulator may be reconstructed before the "production phase" it's quite useless to try to deal with these issues *now*. The current development plan is like a "draft implementation", the performance can be increased a lot in the future, also the quality of the code.
DeleteOk.
DeleteAs for myself, I would like to get started with video game development even before Mega65 hardware is completed. It's a nice way to start development even before I have the actual Mega65 computer in hardware form. Games can have substantial lead time to make. Especially a brand new video game. It's not just porting a video game. I'd expect a good 12 or so months for a commercial grade (Commodore/Amiga standard) video game.
Nice.
ReplyDelete@LGB
When the emulator is more mature, it could together with prg studio become a way to develop and test software for the Mega65 - without owning the actual machine. this makes it possible to reach a larger audience. You may want to keep in mind that the current mega65 CPU is going to be replaced by a new one that is faster, more optimized, pipelined, and with 3 cores.
http://c65gs.blogspot.dk/2016/04/overview-of-new-cpu-design-as-of-today.html
Hi, I know about that for sure, I am great fan of Paul's blog since the beginnings, so I've read that :) To be honest, even the current CPU @ ~48MHz is problematic to be emulated with combined the VIC-IV etc features, I even doubt it can be done in real-time with full precision at least. Maybe I am just too sceptical here. However at @192MHz, even more cores, and much better IPC value (so the clock speed of the new core means much more performance improvement than just the 48->192 change would indicate), that's hmmmm let's say "not too realistic" to be emulated in real-time even not even on a "quite fast" PC. Currently my emulator is not so much usable for an "average" user, but surely, it's also intended for that purpose in the future, including other usages than "M65 developer material" too. What is sure, my current code is a big ugly mess, I have to admit that. I want to "basic" things works first, so I see the "big picture" better, also noticing the ways then to do it better, and applying aggressive optimizations.
DeleteCertainly doable with a JIT recompiler, but that's quite complex :)
Delete:) I also thought about JIT, though I can't say I am a master in this too much. However there are some problems with the JIT-like techniques. First, the frequent usage of self-modification on 65xx CPUs makes it kinda tricky to implement. Second, the "mixed" nature of 65xx address space (ie, something is I/O where it's handled like that, something is "only" memory, and that's even not a constant state but can be changed for example with MAP and the "CPU port" at loc 0/1). Third, though M65 is not so much C64 compatible in a cycle-exact way at 192Mhz for sure, we can't forget still to have some requirement on syncing emulated hardware elements, ie for some kind of raster tricks, etc etc when it's important to happens things after some amount of passed CPU cycles, and so. JIT is much better suits on the needs, when CPU has "free run" and the memory is more "intact" I mean in the manner of "modern standards", compared to the habits of a 8 bit system, what we LIKE ALL, of course, otherwise I wouldn't be here either to write :)
DeleteAll I can say is : Good luck with it!
DeleteAn emulator/debugger would be useful for cross deving, but I expect we'll be able to do everything, given time, on the machine itself. So no biggy if it's not perfect :)
How is that emulator working, from a technical point of view? Is it a complete re-implementation, or does it use the FPGA code somehow?
ReplyDeleteTechnically you may be able to use the same VHDL as some kind of "simulation" on a computer (as the "emulator") and that would be as accurate as the FPGA design itself. However it would be *painfully* slow to "emulate" that level. After all, FPGA is hardware, capable millions of things doing in parallel in theory, while in programming you can do one thing for real at a given time (well, if you have multiple CPUs, cores, hyper-threading etc, it's not a precise statement, however it's still nothing, and also it wouldn't work too much as a modern OS would not allow to keep multiple threads to be in sync at a precision we need). So the emulation itself is a re-implementation of M65. Think of it like a C64 emulator. From the internal view point, a C64 emulator is very different from a "wired C64 hardware". However what you need to emulate is more the "behaviour" a program can "notice", and it's kinda uninteresting what are the internal details. The implementation itself of the emulator is more about trying to aim the most efficient way to emulate the behaviour. But surely, it's not (yet, and may be never be) a "complete" re-implementation of an M65, just some features needed for M65 kickstart to be able to boot, etc. In the future, I try to implement more and more M65 features with better accuracy, but still there is a limit (especially for real-time emulation) of software emulation even on a "fast PC" to emulate a hardware ... Because of the reasons I mentioned above.
DeleteIf there is a C65 Emulator out there that can be implemented into VICE. Emulating the additional attributes /features of the Mega65 such as the enhanced graphics modes. There is already C64DTV and C64+SuperCPU emulation in VICE. There is a little bit of behavior emulation that you mention needs to be emulated for sake of the software to play along.
DeleteI have a C65 emulator too, not just M65. I considered VICE, but for me at least, it's not even understandable how to start a new emulated machine within a project, so I've decided to do at my own way. More information: http://cubed-borka.blogspot.hu/2016/05/my-commodore-65-and-commodore-lcd.html Currently, M65 is kind of different material, because its speed and features. I've already done lots of "optimization" (not in the "public" versions though since it does not even work in this form yet) by checking gcc's output in assembly, and I am also about re-write some parts in (64 bit x86) assembly which should cover the large majority of people with Windows, Linux or MacOS operating systems (though of course, the C implementation of the mentioned functions will be available still). I am a bit unsure about the future of boosting emulation speed, currently I stopped this sub-project, and I decided that emulation of features are more important *first*, it's useless to have a fast emulation if it can't run too much anything :)
DeleteHow is that emulator working, from a technical point of view? Is it a complete re-implementation or does it use the FPGA code somehow?
ReplyDelete