c64ref gathers every Commodore 64 disassembly into machine readable text

A collection first, a website second

The stated purpose of the project is narrow and honest: an effort to collect C64 reference documentation in machine readable form and maintain scripts to present it to the web. That ordering matters. The artefacts of value are the text files, and the website is a presentation layer over them.

The collection has three parts. The ROM Disassembly section holds disassemblies of the KERNAL and of BASIC, and it lists them by which one covers what and who produced it. The Memory Map section gathers memory maps. The KERNAL API section collects listings of the KERNAL entry points.

The source directories reflect that structure, with a directory per topic, and each reference file has a short machine friendly name:

[Disassembly KERNAL]: src/c64disasm/c64disasm_cbm.txt
[Memory Original]: src/c64mem/c64mem_src.txt
[API Guide]: src/kernal/kernal_prg.txt

The point of collecting from many authors is that no single disassembly is complete or correct for every purpose. The collection includes a KERNAL-only disassembly from Commodore and a BASIC-only one from Microsoft, plus a version that covers both from Lee Davison, a BASIC-only version from Bob Sander-Cederlof, a German-language pair from the Commodore-64-intern-Buch, a KERNAL-only version from Magnus Nyman, and a pair from Marko Mäkelä.

For a developer, having all of them in one searchable place is the difference between trusting a single commentator and being able to check where they disagree.

Nine memory maps, each with a different bias

The memory map section is where the collection is most immediately useful, and it is the widest set. The titles named are Mapping the Commodore 64 by Sheldon Leemon, Memory Map mit Wandervorschlägen by Dr. H. Hauck, the Commodore-64-intern-Buch credited to Commodore, a Reference by Joe Forster and STA, the Comments in the original source credited to Microsoft and Commodore, the C64 Programmer's Reference Guide, 64map, and a Reference by Jim Butterfield.

The languages are mixed, with two German entries among the English ones, and that is part of the point. The German sources are not a translation of the English, it is a different treatment, and the Wandervorschläge title translates roughly as a memory map with suggestions, which hints at commentary the plain address list does not carry.

The Credits section names Michael Steil as the person who did the original work of collecting, converting, formatting and editing the collected files. That sentence is the honest description of the effort involved. These documents exist in books, magazines and handwritten notes, and turning them into consistent machine readable text is a manual job that a scraper cannot do.

The result is that a lookup question, which address holds that variable, has multiple well-known answers of different quality, and this repository lets you see them at once rather than trusting the first one you find.

The KERNAL API section spans nine decades of Commodore documentation

The third section lists the KERNAL entry points, and the titles span a wider period of Commodore publishing than the other sections. The Commodore 64 Programmer's Reference Guide from Commodore is there, as is COMPUTE!'s VIC-20 and Commodore 64 Tool Kit: Kernal by Dan Heeb, Machine Language Routines for the Commodore 64 and 128 by Todd D Heimarck and Patrick Parrish, Mapping the Commodore 64, Commodore 128 intern by Jörg Schieb, Frank Thrun and Heinz Wrobel, The almost completely commented C64 ROM disassembly by Lee Davison, Cracking The Kernal by Peter Marcotty, Kernal 64 / 128 by Craig Taylor, Commodore 64 standard KERNAL functions by Joe Forster and STA, a C64 KERNAL jump table by Frank Kontros, and Das neue Commodore-64-intern-Buch credited to a group of German contributors.

That list is the clearest statement of the project's value, because these are the sources that disagree with each other. A KERNAL jump table gives you addresses. A commented disassembly gives you what the code does. A tool kit gives you worked routines. A programmers reference guide gives you the officially documented behaviour.

None of them is sufficient alone, which is why the collection keeps them side by side rather than merging them into one canonical answer. When the official documentation and a disassembly disagree about an entry point, the disagreement is the interesting part, and the repository preserves both.

One caveat applies throughout: the collection preserves the sources as they were, which means the opinions and the accuracy of each author are preserved with them.

The pipeline is a Python script and a single dependency

The repository is small in terms of machinery. The top level holds a generate.py, a requirements.txt, a validate_html.sh, an .editorconfig, a .gitignore, a LICENSE, the README, a docs directory and the src directory holding the reference text.

The dependency list is short enough to state in full. requirements.txt pins a single package:

Markdown==3.8.1

So the generation step renders the collected text as Markdown, and a shell script validates the generated HTML. The documentation directory holds a Build.md, which is the build instructions the project links to from the README with a Building button.

There is no build system beyond that. No framework, no plugin loader, no theme engine. The scale of the project matches its purpose, which is to publish text files in a readable way on the web, and a heavier toolchain would add risk without adding anything.

The homepage is pagetable.com/c64ref, and the repository description calls the project the Ultimate Commodore 64 Reference with the sub-line ROM Disassembly, Memory Map and more. The language of the repository is Python, the licence is BSD-2-Clause, and the repository publishes no GitHub releases, so the site and the master branch are the only versions of the truth.

Corrections and translations are the contribution path

The Contributions section is short and specific: extensions, translations and corrections of typos and content are welcome. Three kinds of contribution are named, and they are not equally easy.

Corrections of typos are the cheap and obvious case, since the reference text is meant to be verbatim and a typo in a transcription is a defect rather than a disagreement. Extensions mean adding sources that are not yet in the collection, for example another disassembly or another memory map from a source nobody has transcribed yet. Translations mean doing the same work for the German documents, which is the most substantial of the three and the one that would most change the collection, since a large part of the best German Commodore documentation is not available in English at all.

The credit for the original collecting, converting, formatting and editing belongs to Michael Steil, and the documentation makes the point that the effort of the collection came first and the tooling came second. The scripts exist to serve the collection, not to replace the human work of reading a book and typing out a memory map.

That is also the honest limit of the project. It is a curated transcription, so its accuracy is bounded by the volunteers who read each source, and it will never be as consistent as a single official manual. It is better than that, though, because it lets you see the disagreements.

A quiet maintenance record, and a licence that keeps the door open

The last push to the repository was on 2026-04-05, and there are no GitHub releases. A project like this does not need versioned releases, since the content is reference documentation that is corrected in place, and the absence of tags is a reasonable design rather than a sign of neglect. The repository is not archived.

The licence is BSD-2-Clause, with the LICENSE file at the top of the repository. That choice matters more here than it would for most projects, because the reference documentation itself comes from books and magazines whose copyright sits with their authors and publishers, and a permissive repository licence cannot grant rights it does not have. BSD-2-Clause makes the code and the transcription workflow reusable, and the content it covers remains what its original owners made it.

The repository topics describe the collection accurately: 6502, c64, commodore, disassembly, kernal, memory-map, rom and collection. The 6502 tag is the hint about the real subject, since almost everything in this repository is ultimately a description of what a 6502 program sees when it reads a particular address on a particular machine.

Editorial conclusion

Adopt c64ref if you are writing Commodore 64 or Commodore 128 code and want the original disassemblies and memory maps in a form you can grep, diff and script against instead of scanning scanned PDFs. Do not adopt it as a learning resource for newcomers, since it assumes you already know what a KERNAL entry point is. Before you rely on it, check two things: which of the several competing disassemblies you intend to treat as authoritative, since the collection deliberately includes a BASIC-only and a KERNAL-only version from different authors, and whether the machine readable text has been kept in step with the corrections people contribute, since the maintainers welcome extensions, translations and corrections as contributions.

Frequently asked questions

Official sources

1. Issues
2. License: BSD-2-Clause
3. mist64/c64ref on GitHub
4. Project website
5. README