targets mega65

The Mega65 emulator of Xemu

This is about Mega65, to learn more, visit this site: http://mega65.org/

Mega65 target is a slightly modified Commodore 65 emulation. WARNING: This is NOT a full Mega65 emulation but only the minimal feature sub-set of Mega65 which is enough for some purproses, like Kickstart ROM development and debugging. Do NOT expect that it runs Mega65 specific software in general!

Mega65 mode is only used if the emulator can load KICKUP.M65 (case sensitive name ... at least on UNIX like machines). You should have one, placed into the rom/ directory for example (or the current directory, xemu tries different places, see emu_load_file() function in common/emutools.c about this). Without KICKUP.M65 the machine boots and functions like a C65, even C65GS I/O keying won't be supported (however this mode is not tested too much, for this, please use the c65 target instead of this one).

You must also provide an image file of the SD-card for the Mega65. The file name should be mega65.img with the same rules of placement as with KICKUP.M65 for sure. This is a simple image file, really. On UNIX-like system, you can even try to symlink the device node of a real SD-card reader, but be careful with the access rights, so Xemu can open it at all. Without this image Kickstart won't be able to use the emulated SD-card controller normally, of course.

In theory, there is Makefile support (in directory rom) for creating an SD-card image, but it's better to ignore it for now, and provide a really working one :)

You are recommended to redirect stdout to file (or to /dev/null if you don't need) as the large amount of output may slow down a things a lot, also you may need it (you can check the file then for various information).

NOTES

Mega65 target is basically similar (was forked from) my Commodore 65 emulator, however:

• $D02F keying support for Mega65 mode
• Some Mega65 specific I/O support
• Hypervisor MAP mode, limited load/save machine state (not all stuffs!)
• NOTE: currently, >1MByte MAP/linear access/etc is NOT supported at all (other than the special case of Hypervisor memory mapping $8000-$BFFF and the DMA hack, so Kickstart can use DMA)
• Loading KICKUP.M65 by the emulator (if it does not work, "simple C65 mode" will be used, without any Mega65 feature)
• Super-ugly 16 bit text mode support to be able to see "something", currently only with incrementing video/colour pointers by two, but no extra data is interpreted at all.
• Mega65 SD-card support (still doesn't work) only with the absolute needed features
• F011 FDC is still the same as C65 target's. It will try to access the D81 disk image file, if one is specified, and it has no connection with the SD-card stuff.

HIGH PRIORITY TODO

• debug UART monitor interface support with more commands (still valid, until it reaches the real Mega65)
• debug UART monitor support should be tested with m65dbg better
• SD card controller does not work, kickstart reads sector 0 some times but nothing happens
• There is no write support for SD-card at all
• More VIC-IV features, starting with acceptable 16 bit text support
• True Mega65 favour of MAP opcode support with offsets up to 28 bits, switching to linear addressing of 256Mbyte
• 28 bit load support for ZP Z indexed special opcode
• 28 bit JMP/etc support?
• Backtrace/CPU history support in case of hypervisor out-of-bound code execution?
• F011 FDC implementation should use "emulated" stuff using the SD-card instead of the old C65's implementation for a discrete D81 image

Using Xemu UART-monitor

Still, it's in development phase, but you can try it. First, it needs Xemu compiled for UNIX, as Windows does not have standard socket interface, so it won't work. Xemu Mega65 target by default tries to open a named (UNIX domain) socket in the current directory with the name of uart.sock. You need to connect that socket. You can try that with minicom for example: minicom -D unix#/directory/to/the/socket/uart.sock

I've have a commit for m65dbg which supports the same, it also needs UNIX, and before the compilation you need to enable the UNIX domain socket support with editing serial.c near the beginning of the file (the #define may be commented out by default, thus wouldn't work with this modification). If you have this, you can try then: m65dbg -d unix#/directory/to/the/socket/uart.sock

Please note, that only a ONE client can be connected to the socket, so it won't work, if a process is already connected!

Supported commands and notes:

• I am not sure if my implementation is compatible with Mega65 ...
• r command shows registers, the title is from the VHDL, though not all information is displayed, or some of them are incorrect (ie MAPL/MAPH is handled as a trick in Xemu for hypervisor, and you can't see for real, etc)
• d (dump of memory) command displays 16 bytes from a given hex (parameter) CPU address, that's all
• t (trace) with parameter 0 or 1 disables/enables trace mode. In trace mode, the Xemu window title says "TRACE/PAUSE" instead of "running" (note: for performance reasons the title change may take max of 1 sec to be updated). In trace mode, you can issue t (without parameters) for a step, registers are displayed after the step (I am not sure if it's the same behaviour as with the real thing). An empty command (just hit enter) is the same as t but only, if you are in trace mode already.
• In case of execution code outside of $8000...$BFFF area in hypervisor mode, Xemu switches to TRACE mode by its own after a warning dialog box. So you can examine the situation with the monitor. However, it would badly need the backtrace/CPU history feature implemented, to be really useful ...
• Xemu is a single thread application. UART monitor is implemented with non-blocking I/O called from the main update loop, so sometimes it can be a bit slow. Please note, that SDL2 error/info dialog boxes stops the execution of the main program, so monitor won't respond either till you clicked on the window to acknowledge and close.

It seems even with only the r command, you can use m65dbg to learn where the execution is inside the kickstart with its dis command (if it can load its map files at least, if not, it can be a problem as it then uses the d command to get memory dump and disassemble, which is not well tested with Xemu yet).