XEMU and chargen

Zitat von FeralChild

When calling XEMU using the following command:

Code

1. ../xemu/build/bin/xmega65.native -dmarev 2 -forcerom -loadrom (my custom-built ROM)

it always uses original Commodore chargen for the display, even though my custom-built ROM contains alternative chargen. Is it possible to force it to use font from the supplied ROM?

Currently not so much But you can try to put CHARROM.ROM on the SD-card image with your custom ROM. Ideally this shouldn't be a problem, as the used ROM (the 128K one) has the character data embedded, which can be then used, but Xemu is not yet up to date with recent Hyppo's used by mega65-core which MAY can do that automatically. Till that, that, I can suggest the ugly workaround I mentioned with CHARROM.ROM.

Other workaround is the brand new (you need to use very fresh Xemu for that, it's in the master branch only since a hour or so ...) Xemu with its "virtual SD card" mode. What it does, that you can have a normal directory (ie, windows/linux/mac directory on your file system, whatever system you use to run Xemu) and Xemu can create on-the-fly an in-memory SD-card virtual image from the content of a directory and use that. But this mode is more intended for mega65-core developers (also any changes you made inside the emulation will be lost on exit). If you may want to use that, you can do that, by specifying the -virtsd command line parameter, and overriding -sdimg with the name of the directory you want to use. However, then you need to have the character rom still as a separated file, also MEGA65.ROM, and all the needed files then yourself (maybe even things like BANNER.M65, though system should work fine without that too).

In the second thought ... Stay tuned, I have an idea how to solve this before introducing newer Hyppo for Xemu which is not ready for that yet. Though, till that things I've described above still applies as kind of crude workarounds.

OK, here is my first try to solve this. It needs fresh xemu from the 'dev' branch. Simply use the -fontrefresh CLI switch as well with the all already used one (ie -forcerom and -loadrom). Also this new commit in the dev branch touches some other parts of Xemu/MEGA65, like 8K size of chr-WOM (WOM=WriteOnlyMemory ... from point of view of CPU, not VIC, of course), its memory mapping and initialization, even if the commit diff is small. So hopefully it works and does not break anything other either ... Btw, the 'alternate charset' VIC-III setting cannot be applied still, that's another question. But connected to this change, at least now there is WOM space to refer.

Ah. You should NOT have spaces and/or non-US-ASCII characters in directory/file names ever - main rule of using computers OK besides the trolling attempt of mine which is more meant as a joke .... but seriously: unfortunately since Xemu should work and compile on at least four very different beasts (mac, unix, windows, html/emscripten) there are some problems would affect one but not the other etc, which leads to the problem to find some general limitations as the least common divisor for all This is an example of paths and scripts etc used by the build system. You can clearly see this: cc: error: 8-bit/GIT/xemu: No such file or directory indicating that path if broken down two peaces because of the space in the component Commodore 8-bit. And yes, I know it worked before but the new build system is much more complicated and needs configuration step, and passing directory names as arguments etc etc, where it fails ... Probably this can be fixed by me in several places, but it never be perfect since the nature that space means argument separator in general ...

in nutshell: please try this in a directory, where the path components does not contain special characters.

But anyway, thanks for the report, I will try later to fix at least the most sensitive parts of this problem, but I've said I cannot even expect it will be perfect for all cases/systems/targets/shell versions/etc. Btw, similar problem of xemu using non-US-ASCII characters, even in run-time (not the compilation part) especially on Windows where there is totally different API for WCHAR based file operations and "normal" ones, grrrr

Also, I've just made a few changes in the dev branch, that _probably_ it should work even in the case of having a directory component with space in its name of the directory path. But in general, best bet: try to avoid special names, in my personal opinion.

Anyway, I tried to lighten the situation so maybe now it can compile even in that case, however there can be "hidden traps"