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!

BASIC 10 Reference

Today we have a guest post from Edilbert, one of our great volunteers in the MEGA65 team, who has been working on documentation for BASIC 10. As you will discover, this was no small task.  But I'll stop here, and hand over to Edilbert...

I followed the MEGA-65 for some years and wondered how long it would take until I could buy this fascinating machine. Then I read Paul's post in the Forum64, where he asked for support. So I thought, it would be nice to join the team and contribute. 

Initially I thought, I could do some assembly programming for the operating system or the BASIC interprenter, but they needed writers for the user's guide. So I proposed to write the chapter: BASIC-10 command summary. I really underestimated the work, that would be needed. First, I had to write the stuff new with my own words - no copy and paste from existing sources. Preliminary versions of the Commodore C65 exist, but they cannot be used for copyright reasons. 

Then I got access to the repository with the stuff, that was created already. It was a bunch of LaTeX files with some text, some program generated tables and templates for all planned chapters. Well, I thought to be an expert in LaTeX, because I wrote all my scientific papers with that program, but then I always got layout templates from the journal editors and had to insert text, figures and citations. This one was a completely different beast. It was a snake pit. First I had to install some extra packages, that were unknown to me. After the first successfull LaTeX run I got a pdf (hurrah) but also a log file with more than 6000 lines of errors and warnings. I thinks, this was due to the effect, that different contributors used packages, that were sometimes incompatible. So I decided, that I should first read through the log file and eliminate as much errors and warnings as I could. This was not easy, but I managed to find solutions and workarounds in most cases. 

The next problem was the screen font, that was used to illustrate example programs. The used font was for 40 column screens and not free of copyrights. So I created my own true type font for this purpose for a 40 column and a 80 column screen. 

Now I started to fill in the contents for the BASIC-10 chapter. I took the syntax from existing sources but wrote a new text for the description and tried to find a compromise between mathematical correct and user friendly formulation, which is sometimes difficult. I wrote 190 pages of text, thought about example code, tested this code on a Commodore 128, where possible and tried to make it readable.  

The result is a page like this for every BASIC 10 keyword, with the nice screen font for showing how examples would be typed:

The LaTeX source for a page like this would be:

Now after 6 months and more than 150 work hours the chapter is written. We need probably some revision, to improve the English, make some text clearer and insert better code snippets, but the first version is done. 

Now I'll focus on the screen font (add graphic symbols) and layout. But working with the MEGA-65 team is a great pleasure and motivation. I'll continue and am looking forward to get in some future my own MEGA-65 hardware.