Mega 65 emulator

Xemu by LGB has a MEGA65 emulator, which he works with me to track progress of the hardware, to keep it as current as possible.

The best would be a compilation from source, on Linux or UNIX like OS (including MacOS). The Windows version somewhat strange (mainly because I have no windows at all, so I just "blindly" ported to Windows, and I use cross-compilation done on LInux even to produce windows EXE files - that is, if you want to compile yourself for Windows only, you still need some kind of UNIX with SDL devel libs + gcc + usual UNIX tools to do). But anyway, you can try a somewhat older version eg from here:

https://bintray.com/lgblgblgb/…emu/current_version#files

Source repository:

https://github.com/lgblgblgb/xemu

Please note, that you need to provide the ROM, Mega65-kickstart, and even the proper SD-card image file by yourself. Till now it was mainly a tool more useful for Mega65 developers themselves: Though recently I have some plan to form Xemu into a more user friendly form, but it was not the top priority, but the ability that it can emulate Mega65 at all first (till a level which is enough for the purpose of the M65 development). So in nutshell: highly work-in-progress material ...

No, the SD card has FAT32 filesystem. I don't know how you mean that no windows program can read it, it should be. However it also has a partition table so it should be handled that way. About the Xemu binaries, I've already posted where they are in the previous post in this topic:

https://bintray.com/lgblgblgb/…emu/current_version#files

For example, xemu-binaries-win64.zip for 64 bit windows. That's true anyway, that these binaries and older than versions can be compiled from source _currently_.

Actually the mega65 emulator within Xemu does not even require those rom files at all. It only requires the C65 ROM but it's on the SD card image file.

@pmprog Unfortunately not Most of the emulator is was more about the "skeleton" of Mega65, CPU, memory addressing how it works etc, so it can boot with the default Kickstart what M65 has. Things like VIC-IV is just a "stub" to have the minimal functionality it needs to work for KS + C64 mode + C65 mode, to be able to get in. BUT. It does not mean of course that it won't change! Currently there are some heavy changes needed done with M65 recently, being incompatible with older versions. I have to realize that on the emulator level first, and making work. Then, it's - indeed - time for implementing parts eg VIC-IV "advanced" related stuffs, and so on. My previous work was the Ethernet emulation (it works in Xemu too, but only with Linux, since it needs low-level EtherTAP device attached to) which was need by me to write some code (for both of the board and Xemu) and learn about more on M65 ethernet things. The other problem, till recently, M65 development was in a bit "flux" that I was not sure what to really start to emulate to. Now it's kinda more clear than it was!! So it's really time soon

Freddy Honestly, I don't bother too much about installing since it's so a development phase thing ... But if you're serious about that, you can say "make deb", then you can use "dpkg -i build/bin/xemu_current_amd64.deb" or something like that to install, so at least even your package manager will know about it then, and it's installed that way. Note, that name of the binaries are different then (you can use "dpkg -L xemu" to check the package content if it's already installed), this "xmega65.native" etc, is for only being multi-platform, "native" means no cross-compiling (for windows cross compiling it will be xmega65.win32 or xmega65.win64 for 32/64 bit builds, but can be rename to exe files). The ugly and dirty "binary-level deb package creation" of mine also includes a script, so after installing xemu deb package you can run xemu-download-data (as root! eg with sudo) and it will download data files for you. But anyway, as I've written, it's not so much ready for general use, that's why I didn't even bother too much about any installer regardless of the platform (eg for windows, many people would expect some decent installer - though I am not a windows guy at all, I am lame with that, at least with Linux I have experience).

Key bindings are a bit lame, I have to admit. You can see the content of file xemu/c64_kbd_mapping.c which is the common source of C64/Mega65 keyboard handling as well. My plan is to do this configurable, now you must edit this file and recompile xemu ... Since xemu in fact can use config files (even now, though not so much used feature ...) I should connect some options to define keybindings, so one can find a more easy way to simply edit a config file for xemu to re-define keyboard (surely, it's still not the ideal, when some want use a GUI-like solution to configure everything, but still better than the need to edit a c file, and recompile the source tree ....).

Surely, things like C65 ROM stuffs, graphics modes, etc, is already not xemu related topic too much. Maybe you can try this:

https://github.com/MEGA65/c65-…ster/c65manualupdated.txt

But it's hard to tell sometimes what works and what not, these "preliminary" documents from Commodore may be incomplete, sometimes only means "plan", and sometimes, it varies from ROM version to ROM version if it works or not, the same way as documented or not, etc ... After all, C65 had never came out as a product, so only different stage of development ROMs are available, and also documentation is confusing what it refers for, what ROM version, or even just a future plan (or even just an outdated information for any available ROMs). Hard question, well, in nutshell, in my opinion.

I'm not sure how many C65 owners dumped their ROMs (or if here was a german version at all - I would find that unlikely, as it was a development process, I wouldn't start with localization at the first glance when hw/sw is not even near to be finished, but I can be wrong, for sure), I know about these:

ftp://www.zimmers.net/pub/cbm/firmware/computers/c65/

Sure enough, they are not all compatible with default Xemu (at least you need to specify DMA controller revision "A" or "B") but also true for real C65s: they were often incompatible with each other even on the hardware level, as the "surviving" C65s were actually kind of development, pre-production units at different stage of development, surely they differs at both of software and hardware level (so you can't exchange ROMs in a real C65 either easily if it was written for another hardware revision of the C65 project).

You may want to try with C65 emulator from Xemu (not M65 ...). Also you may need to specify DMA revision for Xemu/M65 since there are (at least ...) two known incompatible versions of DMA hardware in C65s, and some ROMs seems to use revision "A", others "B", it's not to easy to tell what you need to use unless you encounter strange behaviour when you try. Use -h parameter of Xemu/C65 emulator to learn how to specify emulated DMA F018 revision number.

http://c65.lgb.hu/dma.html

If you're interested, here is some blah-blah written by me about the DMA differences on the hardware level.

You can get the ROMs from:

ftp://ftp.zimmers.net/pub/cbm/c65/firmware/index.html

Hi! The keyboard map "error" is not an error actually, you don't need to worry, it just it tries to open that file for custom kbd mapping, but if it does not exist, no problem, it will use the default. The other problem is interesting:

ERROR: Couldn't create: Invalid argument

Honestly, I've never encountered (or heard somebody has this ...) problem. it means, windows API returned with EINVAL when Xemu asked it to create a 4Gbyte sized empty "sparse" file. What kind of filesystem do you use on that drive, regular NTFS? Is there enough free space on it? I guess it can be even a problem related to large file support somehow, but that shouldn't happen with any modern OS, especially not if you have any decent OS (so 64 bit, not 32 ...). In old times, it was problematic to have file sizes over 2Gbyte or 4Gbyte for obvious reasons (2G since the signed nature of file pointer on 32 bit, 4G if unsigned).

A very ugly workaround (though it would be better to know what the reason that Windows cannot create a large file!!) is to method that you create whatever file you can with that file, just be exactly 4Gbyte in size (ie: 4294967296 bytes exactly). But yes, sure, it's not normal that it can't do it as its own ... As you'll need to fdisk/format the SD card image anyway as the next step, in fact, it does not matter what that files contains it just need to be created, and here Windows fails at this point to do so, for whatever reason (Xemu tries to create a sparse file, which means, though size is 4Gbyte, it does not allocate 4Gbyte disk space at all, just what is really used after that when writing happens there. This is done this way to try not to waste 4Gbyte disk space just for have an emulator installed ...).

Was just curious and downloaded the zipped Windows64 binaries (stable)

Then started the xmega65.exe

During start he asks to create SD Card -> Yes , but he doesnt create it

My System: Windows 7 Pro 64bit, Enough Space on SSD for Image

WINDOWS: console is open

**** The Incomplete MEGA65 emulator from LGB ****

This software is part of the Xemu project: https://github.com/lgblgblgb/xemu

CREATED: travis@lgb on Linux 5.0.0-1031-gcp at Tue Jun 9 11:36:13 UTC 2020

CREATED: gcc-mingw64 7.3-win32 20180312 64LE for win64

VERSION: https://github.com/lgblgblgb/xemu.git HEAD 527c2b021966f6f9f2444c23d6402c141d1c19d2 20200609133347

EMULATE: MEGA65 (mega65): xmega65 (../../build/bin/xmega65.win64) for mega65 on win64 (win64) using x86_64-w64-mingw32-gcc

LICENSE: Copyright (C)2016-2020 Gábor Lénárt (aka LGB) lgb@lgb.hu http://lgb.hu/

LICENSE: This software is a GNU/GPL version 2 (or later) software.

LICENSE: <http://gnu.org/licenses/gpl.html>

LICENSE: This is free software; you are free to change and redistribute it.

LICENSE: There is NO WARRANTY, to the extent permitted by law.

FILE: @mega65-default.cfg cannot be open, tried path(s): C:\Users\KPC\AppData\Roaming\xemu-lgb\mega65\mega65-default.cfg

CFG: Default config file @mega65-default.cfg cannot be used

INSTALLER: not activated.

WARNING: *** NEW M65 HACK MODE ACTIVATED ***

Logging is disabled at compile-time.

Logging into file: not enabled.

SDL: no SDL subsystem initialization has been done yet, do it!

SDL version: (hg-12952:bc90ce38f1e2) compiled with 2.0.10, used with 2.0.10 on platform Windows

SDL system info: 64 bits LE, 4 cores, l1_line=64, RAM=16382Mbytes, CPU features: 3DNow=1 AVX=0 AVX2=0 AltiVec=0 MMX=1 RDTSC=1 SSE=1 SSE2=1 SSE3=1 SSE41=0 SSE42=0

SDL drivers: video = windows, audio = wasapi

Timing: sleep = usleep, query = SDL_GetPerformanceCounter

SDL preferences directory: C:\Users\KPC\AppData\Roaming\xemu-lgb\mega65\

SDL window native pixel format: SDL_PIXELFORMAT_RGB888

SDL renderer driver #3: "software"

SDL renderer driver #2: "opengles2"

SDL renderer driver #1: "opengl"

SDL renderer driver #0: "direct3d"

SDL renderer used: "direct3d" max_tex=16384x16384 tex_formats=3 (SDL_PIXELFORMAT_ARGB8888 SDL_PIXELFORMAT_YV12 SDL_PIXELFORMAT_IYUV)

GUI: no GUI was specified, using the first available one from this list: windows none

GUI: using "windows" (Windows API based Xemu UI implementation)

FILE: file @keymap-default.cfg opened as C:\Users\KPC\AppData\Roaming\xemu-lgb\mega65\keymap-default.cfg with base mode-set as fd=6

HID: 89 key bindings has been added as the default built-in configuration

FILE: @keymap.cfg cannot be open, tried path(s): C:\Users\KPC\AppData\Roaming\xemu-lgb\mega65\keymap.cfg

HID: cannot open keymap user config file (maybe does not exist), ignoring: @keymap.cfg

BIN: config "loadrom" as "C65 ROM image": pre-zero policy, clearing memory content.

BIN: config "loadrom" as "C65 ROM image": has no option override, using the previously stated policy.

BIN: config "loadcram" as "CRAM utilities": no pre-zero policy, using some (possible) built-in default content.

BIN: config "loadcram" as "CRAM utilities": has no option override, using the previously stated policy.

BIN: config "loadbanner" as "M65 logo": no pre-zero policy, using some (possible) built-in default content.

BIN: config "loadbanner" as "M65 logo": has no option override, using the previously stated policy.

BIN: config "loadc000" as "C000 utilities": pre-zero policy, clearing memory content.

BIN: config "loadc000" as "C000 utilities": has no option override, using the previously stated policy.

BIN: config "kickup" as "M65 kickstart": no pre-zero policy, using some (possible) built-in default content.

BIN: config "kickup" as "M65 kickstart": has no option override, using the previously stated policy.

D81: initial subsystem reset

SDCARD: configuring F011 FDC with have_disk=0, can_write=1

FILE: @mega65.img cannot be open, tried path(s): C:\Users\KPC\AppData\Roaming\xemu-lgb\mega65\mega65.img

ERROR: Cannot open SD-card image C:\Users\KPC\AppData\Roaming\xemu-lgb\mega65\mega65.img, SD-card access won't work! ERROR: No such file or directory

ERROR: Couldn't create: Invalid argument

ERROR: Cannot find SD-card image (which is a must for MEGA65 emulation): @mega65.img

SDCARD: configuring F011 FDC with have_disk=0, can_write=1

ETH: shutting down: handler thread seems hasn't been even running (not enabled?)

Memory state is dumped into D:\CBM\Xemu\xemu-binaries-win64\dump.mem

*** Please review the console content (if you need it) before exiting!

Press SPACE to continue.

Hmm, really no idea ... I don't even use Windows at all, I just ported my Xemu to probably work with Windows as well What I did though, tested with Windows 10 (running as VM on my Linux machine) and I never seen such a problem. If somebody has more windows programming ideas (again: I didn't ever had windows installed - other than a Win10 VM just because of Xemu recently! - on any of my machines being home or workplace office, since windows 3.1). Surely it was just an excuse I'll ask the help of some more Windows capable guys (than me) that then can figure out the reason of this problem.

Btw, just for curiosity if anyone would like to test: https://github.com/lgblgblgb/x…s/tree/binary-windows-dev

Does it make any difference compared to the "stable branch" of xemu?

Also please note, that any test I can even do, is windows 10 based (though the original report from MadZ28 mentioned win10 as well, so maybe that's not the problem here).

Thanks for the reports and test so far, anyway!