Open C64 ROMs Guest post update

And today we have another guest post, this time from our very-productive contributor to the C64 Open ROM project that we started, so that we can have copyright-problem free ROMs for inclusion with the MEGA65, and also for emulators and other projects to use for the same purpose.  But enough from me ...

Hi all! My name is Roman, I'm from Poland, and I work on the Open ROMs (https://github.com/mega65/open-roms). For those of you who missed previous posts - it's a MEGA65 side project to create free and open-source ROM set for Commodore 64 and every compatible machine. We will, of course, never reach 100% compatibility - but a reasonable degree should be achievable. My personal goal is to create not just a poor-man replacement - I want a ROM which is simply better!

Currently both KERNAL and BASIC needs a lot of work, for now I decided to focus on the first one.

I started my work with improving the IEC (read: floppy) support. That took me quite some time and a lot of debugging with specially modified VICE emulator, showing the details of serial communication. As a result LOAD should work now on real hardware too - not only with VICE KERNAL hacks. Although IEC functionality is mostly complete now (SAVE being the big missing, somehow I always find more urgent things to do), it will probably still need quite some work to fix incompatibilities with various utilities.

But not only LOAD works - we've got a built-in DOS Wedge too!

Another big task was migration from Ophis to Kick Assembler. I needed conditional compilation, Paul wanted to unify the tool-chain across various MEGA65 sub-projects, so Kick Assembler was a natural choice. Boring job, but had to be done. The most important advantage is, that we can now easily configure builds - enable and disable various features (sometimes mutually exclusive, or potentially incompatible with certain existing software) at will.

Kick Assembler has some nice features - it can export labels to VICE monitor, same with breakpoints (.break directive). And this is fully utilized by our make system - just type 'make test' (or try other test targets), enter VICE monitor, and see by yourself. I also started adding pseudo-commands for common snippets of code, which might be written in a more efficient way on 65C02 and higher CPUs - again, still a lot to do here.

I have rewritten our utility to place floating routines in memory (floating = not having predetermined addresses). Previous one used a very simple method: take the biggest hole (block of free ROM memory) and fill it in starting from the biggest routine. A new approach is to start from the smallest hole and try to fill it in as efficiently as possible, using a slightly modified knapsack solving algorithm - it prefers solutions using larger routines. The tool can still be improved, to fill in more than one hole in a single step - for now this is not needed, in practice the current solution leaves no unnecessary gaps.

One of the problems with improving compatibility is how to identify which unofficial routines we need to provide. We don't have a good solution for this yet, but I've extended the warm start routine - if caused by BRK (for now it's a quite likely outcome of failed attempt to call unofficial routine), it prints the actual BRK address. Try it - launch VICE with Open ROMs and do 'SYS 49152'.

Yet another large task was to rewrite the keyboard scanning. Till recently a TWW/CTR routine was used (https://codebase64.org/doku.ph…orrect_and_non_kernal_way), adapted to be a part of our Kernal. But although this code is really advanced, way better than the Commodore one, from our point of view it has a very serious disadvantage: compatibility problems. The algorithm used requires more memory than the original, it has to use some bytes that are normally free for use by the application/game. On the C64 we don't have memory allocation as in modern operating systems, everyone uses what he believes is free; game can put the final boss behaviour implementation in a place used by extended keyboard scanning, and we won't even notice it. The new routine isn't as sophisticated as TWW/CTR one - but it still prevents ghost characters from appearing (press A+S+D at the same time on a C64, with original ROMs you'll get letter F written). Additionally, it can decode extended C128 keys - currently released build still has some problems with them, fix is on the way.

In general, a lot is happening 'under the hood', to achieve better compatibility, sometimes using really dirty hacks. FileBrowser64 is now working (other browsers don't work yet), some game cartridges work too (don't bother with utility cartridges, as of yet most of them just crash).

Starting from recently, all the released builds are versioned. Release string DEV.191025.FC.1 means that this is a development snapshot done 25.10.2019 by FeralChild (my nick on C64 forums and on the GitHub), and this is the first snapshot released that day. If you create a bug report, please always include both the release string, and the build - for now one of: generic, MEGA65, Ultimate64, testing. Right now all ROM builds can be used on any platform, there is no hard dependency yet - but, for example, MEGA65 build won't even try to read C128 extra keys or initialize SIDs at $D5xx. Please also note, that 'testing' contains features that will hurt compatibility, in case of problems it is always a good idea to retest with 'generic'. BTW, don't mix the builds - it will be detected and you'll see a nice KERNAL panic screen.

For the near future, I'll definitely focus on KERNAL improvements - rather on compatibility, than on the features. Some official routines are incomplete, several unofficial entry points needs to be provided. Once you get involved with a project like this, there is no way to be bored!