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

@rosettif: there is no datassette-port in the C65.
And afaik the 4502 does some 'wait-states' when used in C64-Mode.

To be honest, this alternative ROM project is much more interesting to me than the whole Mega65 project (especially that Ultimate64 and C256 Foenix are now available). A pity it stalled as quickly as it started.

Hi, I'm a programmer interested in computers in so much as I can understand them. So older systems are much more likely to interest me than new ones, which are just really to overblown to get a handle on.

As such I would like to help develop the Free BASIC and Kernal ROMs! For a description of my level of expertise, read on!

I had always wondered how the old 8 bit machines implemented BASIC and have interested in assembly language programming on them as well since the 1980s. But an assembler seemed to be some expensive semi magical piece of technology that was just unaffordable and unapproachable to my younger self. But after studying computer science at university, it's now something that I should be able to do. Theoretically at least.

Once thing I always wanted to implement an assembler on an 8 bit micro back in the day and maybe a high level language. I've studied compiler construction, and did that Nand2Tetris course on Coursera as well

I had been trying to get my dad to dig out ye olde TRS-80 Color Computer II for years without much success, so I started to look into systems that maybe I could buy.

So in the last 6 months or so I started to settle on the Commodore 8 bit micros, looking for a system and typing in a lot of assembler from old books into the VICE emulator running various assemblers I could get my hands on, both in C=64 and C=128 emulation, and also reading and watching all I can to find out how they worked. Including how BASIC was interpreted, tokenised, stored, and ran.

This eventually lead me to actually drop $520AUD on a C=128, 1541 Disc Drive, 1084s monitor and a data set. Which all works great, although the 80 column display doesn't seem to want to sync, though it does display, just the picture keeps rolling and won't lock on, although I'm not sure if that's a problem with the machine or lack of a suitable cable I've tried several stop gap solutions.

However back when it was looking like I might not be able to afford original hardware, I was looking into getting a cheap LatticeXO2 or XO3 FPGA/CPLD board or something like that and developing one bit by bit, no pun intended, starting with say the 6501, then the I/O port to make it a 6510, clocking and PAL, VIC-II, CIAs, SID, etc., etc. until I had something that could run the original ROMs and games. So I poured over all the relevant data sheets and started learning VHDL...

I think I have a pretty reasonable understanding of how the Commodore 64 actually works now, Commodore 128 a bit less.

After I got the Commodore 128, I was still a bit interested in the FPGA stuff, and thought probably the best thing to do was try to create something simple like an REU, then say a SuperCPU, then a C=64, then a C=128.

But then I saw the talk Paul gave about the FPGA phone in Christchurch in January <https://youtu.be/KuNB4ocZDXA> and saw what I wanted to do had essentially be done, and so I want to contribute! It seems a better use of my time that writing yet another assembler for the C=64 or C=128, and I'm fresh out of ideas for games, etc...

The 'cmd_load.s' contains:

;; XXX - C64 BASIC apparently doesn't clear variables after a LOAD in the
;; middle of a program. For safety, we do.
jsr basic_do_clr

This will break some BASIC software, like:

100 DN = 8: REM set device number
110 LOAD "SPRITE DATA 1", DN, 1
120 LOAD "SPRITE DATA 2", DN, 1: REM <- this will try to load from device #0

The 'LICENSE' contains:

This software is Copyright Paul Gardner-Stephen (2019). All rights reserved.
It must not be used or distributed without prior written permission of the author.
NOTE: This is a placeholder statement until a final license is selected.

---

Somehow, I don't feel comfortable trying to use this...

Issue created. How do I clone the whole repository to build the ROMs? 'git clone' worked, 'git submodule init' too, but 'git submodule update' gives me:

git@github.com: Permission denied (publickey).
fatal: Could not read from remote repository.

:: @FeralChild added on 12 Jun ’19 · 18:13

[edit] Found a [solution](https://github.com/desktop/des…73#issuecomment-453158514)

Hey, thanks was thinking of starting there anyway, floating point parsing, manipulation and representation, probably working backwards so representation and manipulation followed by parsing.

But I was a bit taken aback by your reply and what I read when I read your more of your blog. I see that you aren't following the same tokeniser scheme that the C=64 did.

Fair enough I guess, would be easier to implement a better symbol table that way. For instance say keeping the identifiers heap sorted so lookup of any symbol is O(log n) where n is the number of symbols.

I guess I'll see when I look at the code. I'm guessing you've got something working anyway, considering you can do LOAD, etc.

But I'm curious as to whether you want to keep the same Microsoft floating point format that the C=64 uses and all the memory addresses in the zero page the same way that the C=64 does as documented in _Mapping the Commodore 64,_ etc. As far as I'm aware doing so would be crucial to getting binary compatibility with existing software that used the KERNAL. I'm guessing the tokeniser format not so much.

How to do the transcendental functions is a bit of a vexed question. There's basically two ways to do it I know of. The first is polynomial evaluation of something close to the Taylor series but with the constants of the polynomial finagled slightly to give more accurate results than using only the first few terms of the Taylor series and ignoring the rest.

Terms which grow increasingly smaller, but increase in order and are infinite in number. And which unfortunately don't settle down to "negligible" for quite some number of terms. So (empirically derived?) correction is added to the first few terms to compensate.

This is how the C=64 did it, and in fact if you are keeping binary compatibility with the BASIC and KERNAL ROMs you actually have to implement this polynomial evaluator because it's exposed and documented so presumably anyone could have used it.

Then you might as well use it to evaluate your transcendentals, but then you are in the position where the table of constants of your polynomials would be the same as the copyrighted Microsoft floating point implementation.

Now I doubt this would be copyright-able, given that to get the same results on the same data (achieve binary compatibility), you are basically stuck with using these constants. So presumably they would be more "facts" than "inventions" or other protectable works, but I'm not a lawyer. And it generally seems against the approach that you want to take.

The other approach would be to use a CORDIC algorithm to do transcendentals. This might even be faster and would not be based on anything Microsoft or CBM did. Unfortunately I don't understand CORDIC yet

__...and would not be based on anything Microsoft or CBM did__

I misspoke. What I should have said is "it would then use a completely different approach to computing transcendental functions than Microsoft used, so there would be no question of copyright infringement".

Ok, I think I have warped my tiny brain enough so CORDIC can fit in At least for computing sine and cosine...

By the way, I cloned the repo, but Paul do you have a link to any documentation about what the work flow is? What assemblers, etc.

Also I think we probably need to start noting down what volatile memory addresses are used and where. Because obviously we can't use locations that are available to the programmer, because then they aren't available to the programmer anymore! Not a huge deal with functions that don't call any other, so long as certain memory addresses are reserved for these leaf functions, but even there we still have to worry about what locations might be trampled by an interrupt handler.

_Mapping the Commodore 64,_ _Mapping the Commodore 128,_ and the _Commodore 64 Programmer's Reference Guide,_ etc., can help but only so much. We can use it to know what locations are used by BASIC and KERNAL but not really to stop one part of the OS rofl stomping another part, written by someone else.

The stack isn't as helpful as it could be 1. because stack relative addressing isn't directly supported on a 6502, although it can be arranged by getting the stack pointer into X with TSX and then using relative addressing eg. LDA

That doesn't help much though because the stack is only 256 bytes! So facilities for recursion would seem to be quite limited, so every bit of data will have to be a global pretty much, and pretty much either located by prior agreement or doled out by central mechanism in the KERNAL..

This could be simple as a free list but even still, it's still a pain because were do you keep that address you receive. Putting a couple of them on the stack isn't likely to be catastrophic, but otherwise you're back to the chicken and egg problem of you have to store it somewhere, and that requires an agreed upon location...

“I'm guessing you've got something working anyway, considering you can do LOAD”

I can't get this to work - it's probably incomplete, as even CIOUT is clearly not implemented. I'm going to take a look into this.

“What assemblers, etc.”

It uses Ophis assembler, it's in the submodule. Under Linux typing 'make' in the 'open-rom' directory did the trick for me (just one REALLY nasty thing: I had to switch Python to version 2 :/)