Work is underway to make open-source replacement ROMs for the C64

@mega65 I have just noticed a warning added in the manual

Quote

Compound instructions cannot be safely used at 1MHz or 2MHz operating modes. This is because in those operating modes it is possible for an interrupt to occur following one of the single-byte prefix instructions, but before the compound instruction executes. This will cause the processor to forget to apply the effects of the prefix to the instruction, resulting in incorrect behaviour.

Since I'm using compound instructions in the 80x50 screen editor, I have disabled SLOW/FAST commands in MEGA65 native mode. But what about 1MHz mode enforced by IEC activity? I hope the compound instructions can be still safely used in such case, otherwise I'll need to implement a workaround to make IEC routines safe in native mode.

Quote from FeralChild

@mega65 I have just noticed a warning added in the manual

Quote

Compound instructions cannot be safely used at 1MHz or 2MHz operating modes. This is because in those operating modes it is possible for an interrupt to occur following one of the single-byte prefix instructions, but before the compound instruction executes. This will cause the processor to forget to apply the effects of the prefix to the instruction, resulting in incorrect behaviour.

Since I'm using compound instructions in the 80x50 screen editor, I have disabled SLOW/FAST commands in MEGA65 native mode. But what about 1MHz mode enforced by IEC activity? I hope the compound instructions can be still safely used in such case, otherwise I'll need to implement a workaround to make IEC routines safe in native mode.

As far as I can see, the only concern if you have IRQ or NMI received, since it can interrupt in the "middle" of a compound instruction in 1/2MHz mode (since from 3.5MHz mode no NMOS timing applies and there cannot be interrupt after a one cycle opcode, including the ones used as "prefixes" ... however at 1/2MHz, the NMOS timing applies where these "prefixes" are no longer single cycle opcodes). If you can make sure interrupt cannot happen, IMHO, there is no danger.

Well, I'm not sure I can easily guarantee this. MEGA65 native mode screen editor currently needs the compound instructions. Some day BASIC will use them too - there is a plan to move variables (in the MEGA65 native mode) to area somewhere above $10000. And now imagine someone is reading file byte by byte using GET#...

Added a note in the current bug report.

OK, the $D054 seems to switch to 48 MHz, contrary to $0000 - so it is probably a good idea to use $D054 register in the native mode and adapt the IEC routines accordingly.

It seems to me that either $D054 register is not fully documented, or the XEMU implementation is wrong/outdated - I have created a separate issue https://github.com/MEGA65/mega65-user-guide/issues/125.

Does the latest Open-ROM (26.01.2021) (from filehoster) run with xmega65? I can start it with this OpenROM but no keypress is possible.

AFAIK not anymore. It uses registers $D607 and $D608 for scanning the keyboard (these registers are much more convenient to use than CIA), which are not emulated.

Quote from FeralChild

AFAIK not anymore. It uses registers $D607 and $D608 for scanning the keyboard (these registers are much more convenient to use than CIA), which are not emulated.

I'm not sure what it means. AFAIK D607 and D608 are only used to access extra C65 keys over the usual C64 matrix. At this point iomap.txt is totally crazy about these registers I cannot figure out how it should work, as it's already used on C65 for the mentioned purpose, now on MEGA65 it can use for any keys? :-O Hmmm.

These registers can be used to access the whole keyboard matrix, but in a more convenient way:

- no joystick interference; for C64 mode I have written a dedicated code to suppress joystick events; original implementation does not have such a protection

- you do not have to set bits in 2 separate registers to access the given matrix row like in original C65/C128 designs; just put the row number (0-8, if I remember correctly) into $D614 and read the bitfield from $D613; additionally, you have a dedicated register for bucky keys (SHIFT, ALT, etc.), $D611 - this made my keyboard scanning routine much smaller and more simple - see https://github.com/MEGA65/open…board_m65/mega65_scnkey.s

I’m definitely not going back to the C65 way of scanning the keyboard (CIA + $D607 / $D608 to access additional kb matrix row). I never managed to get it working nevertheless - and when I got the DevKit, I already new about $D613 / $D614, so I dropped the old code.

Quote from FeralChild

These registers can be used to access the whole keyboard matrix, but in a more convenient way:

- no joystick interference; for C64 mode I have written a dedicated code to suppress joystick events; original implementation does not have such a protection

- you do not have to set bits in 2 separate registers to access the given matrix row like in original C65/C128 designs; just put the row number (0-8, if I remember correctly) into $D614 and read the bitfield from $D613; additionally, you have a dedicated register for bucky keys (SHIFT, ALT, etc.), $D611 - this made my keyboard scanning routine much smaller and more simple - see https://github.com/MEGA65/open…board_m65/mega65_scnkey.s

I’m definitely not going back to the C65 way of scanning the keyboard (CIA + $D607 / $D608 to access additional kb matrix row). I never managed to get it working nevertheless - and when I got the DevKit, I already new about $D613 / $D614, so I dropped the old code.

Display More

OK-ok, I am not against this of course, quite opposite, I'd like to understand it to be able to emulate! That's the only reason of my posts here. A bit confusing for me, as you talked about only $D607 and $D608 before, but now $D613 and $D614 ... Also $D613 and $D614 according to iomap.txt are "DEBUG" only registers.

As you wrote: "It uses registers $D607 and $D608 for scanning the keyboard (these registers are much more convenient to use than CIA), which are not emulated."

So that's why I am wonder now how these $D613/$D614 comes here then. Sorry that I still can't understand now the whole picture here

Also, $D611 is more attached to $D610 in my mind, which is the hardware accelerated keyboard scanner (but that uses ASCII values not matrix positions, though indeed, for just $D611, it's nothing to do with that and only shows the state of the "modifier keys"). Btw, $D610 and $D611 is already emulated.

Sorry, this was clearly my mistake. The $D613 / $D614 are documented in the user guide, pages 418 / 419, https://github.com/MEGA65/mega…-20210115/mega65-book.pdf - it’s strange that they are marked as debug registers

Quote from FeralChild

Sorry, this was clearly my mistake. The $D613 / $D614 are documented in the user guide, pages 418 / 419, https://github.com/MEGA65/mega…-20210115/mega65-book.pdf - it’s strange that they are marked as debug registers

Ah, OK. I'm about to dig into this and emulate things, by testing with open-rom meanwhile.

Great, thank you!

Quote from FeralChild

Great, thank you!

OK, done. It seems to work. The only problem, that in "baseline" Xemu, VIC-IV things are not so great, so you can see only the upper half of the screen, and using precise video address causes strange effects from time to time. Yes, indeed, it's the fault Xemu (at least the lack of VIC-IV merge still ...). So I've decided to break my own rules, and merge this into the "hmw" branch for now (that is, the mirror of Hernan's branch). Testing with that, the result is much more nature experience, at least at the first sight, and for me. It's currently building (MacOS version is already on the download page, Windows is always slower, not because it's Windows, but there is a huge queue of Linux VMs waiting for boot at Travis-CI nowadays ...), but it will be there sooner or later. Check out the page https://github.lgb.hu/xemu/ and look for the VIC-IV experimental build for now. And sure, it also means, this "hmw" branch though having many VIC-IV things, lack 99% of the Xemu development I did meanwhile (1% being this feature for now, hehe).

Great! I've checked the hmw branch, works for me too! Just a question - is it possible to put additional custom file into a virtual SD card (is it emulated at all)?

I want back to my Z80 simulator - I'm trying to get the Z80 Instruction Set Exerciser Working (implemented a small CP/M simulation, with crude support of the only system call it needs), for now I am experiencing problems with loading the binary from the DevKit SD Card.

Quote from FeralChild

Great! I've checked the hmw branch, works for me too! Just a question - is it possible to put additional custom file into a virtual SD card (is it emulated at all)?

I want back to my Z80 simulator - I'm trying to get the Z80 Instruction Set Exerciser Working (implemented a small CP/M simulation, with crude support of the only system call it needs), for now I am experiencing problems with loading the binary from the DevKit SD Card.

Well, it's an SD-card image file. If you see the output of Xemu (if started from a terminal emulator, not by some GUI ...) it will print where is that file exactly. You need to treat that file as a real SD-card image, it's even have MBR, partitions etc. So in theory, you can use any tools which can deal with image files. Unfortunately there is no true way yet in Xemu to add custom files, Xemu itself can do it, to help people starting (ie it can write the ROM and some other files there, so users do not need to deal with this problem!), but that's a very well fixed scenario only.

So, you can do that "manually" manipulating the image file (preferably when Xemu does not run ....). Other, not so well tested method is the "virtual in-memory SD-card" feature of Xemu. In this mode, you need to specify command line options:

-sdimg path_and_filename normally selects the SD-card image you use, however in this mode, it should specify a DIRECTORY on your host OS ("host OS" => the OS runs xemu) AND the -virtsd option (it does not take any parameter, unlike -sdimg) to signal Xemu that you want use virtual SD-card mode. In this mode it creates and keeps the SD-card image in-memory only on-the-fly, by keeping only the already written blocks (thus Xemu in this mode won't allocate 4Gbytes of memory) according to a block-directory object in memory. Also, in this mode, Xemu automatically "formats" and "fdisk" the virtual SD-card, and, given the directory input from -sdimg in this mode, writes those files onto the in-memory disk image. This is intended for developers, so for sure, any modification on the "sd-card" won't be persistent, since the sd-card itself lives in the memory only. However this makes it possible to drop things you need into a directory on your OS, and tell Xemu to use that directory as a source of a "temporary and virtual" SD-card on start-up. But again, I'm not sure how usable that is currently or it works at all Anyway just give a feedback if it does not work, and I'll try to have a look, if you need this feature seriously.

Yes, I know block is 254 bytes (not 256 bytes), I'll fix it

And a short video to demonstrate game loading: