C64, C128 and 1541 firmware provenance record

C64, C128 and 1541 firmware provenance record is a cross-family record of how particular firmware-related artifacts are identified, qualified, and described by the sources that expose them. It is not a ROM catalogue, a download route, or an account of how to use BASIC, a disk drive, or a C128 operating mode. The purpose is narrower: to keep component identity, hardware applicability, artifact access, source lineage, byte-level qualifications, and reuse status together without treating the C64, C128, and 1541 as one firmware lineage.

Reading a provenance record

A component name or part number is an identity clue, not a complete compatibility statement. The C64 archival catalogue separates named BASIC, KERNAL, and combined-ROM records; its revision material also distinguishes several KERNAL labels. The C128 catalogue separately lists BASIC, KERNAL, character, editor, C64-mode, Z80-BIOS, and complete-ROM records. The 1541 catalogue similarly distinguishes DOS images by the drive family and labelled revision. Those directory labels support source-local identification of a described artifact, but they do not prove that all similarly named chips or dumps have identical contents.

A record therefore needs at least two descriptions. The first is the component or package identity: for example, whether a cited entry is a BASIC, KERNAL, character, editor, BIOS, combined-system, or drive-DOS object and which part number or archive label the source supplies. The second is the applicability qualifier: the named machine, board or model, revision, region or national variant, display or keyboard condition, and operating mode where the source actually joins that condition to the object. The C128/C128D parts list is useful for the former because it associates ROM part numbers with positions; it does not turn every listed item into a universal C128 configuration.

The record also separates an artifact access route from a custody claim. A directory path, repository path, named source disk, or archived file label tells a reader where the describing record was observed. It does not by itself establish factory origin, an uninterrupted custody chain, or permission to copy the described material. This distinction matters especially where a catalogue contains both image labels and source or disassembly labels.

Identity and applicability are separate fields

For C64 material, a revision record may pair an archive label with a reported part number, revision, or regional note. Such notes must remain tied to their named entry. In particular, the C64 revision catalogue uses qualified language for early-unit and regional associations; an unqualified filename is not enough to infer a market, keyboard, board, video timing, or production range.

For C128 material, native operation, C64 mode, and CP/M are different contexts rather than interchangeable names for one ROM set. The Commodore 128 Programmer’s Reference Guide identifies the 8502-based C128 and C64 modes, the Z80 CP/M context, the 40- and 80-column facilities, and the full keyboard as distinct machine qualifications. The C128 directory’s component and complete-ROM labels can be recorded alongside those qualifications only to the extent that the relevant source names the connection.

This leaves an important boundary. The mode documentation does not authenticate a complete C128 CP/M system-disk, bootstrap, or support-source chain. An item should not be described as CP/M firmware, original CP/M source, or a complete CP/M provenance record merely because it concerns the C128’s Z80 mode. Any later CP/M entry requires its own named artifact, mode scope, access or custody description, digest or identifier where available, and rights assessment.

For the drive line, the 1540/1541 service manual documents the two DOS-ROM windows and the service-model context, while the firmware directory adds archive-side labels for 1541, 1541C, and 1541-II material. The resulting evidence supports a qualified drive-family record; it does not license treating the original, C, and II lines as one feature-equivalent replacement image.

Binary, source, disassembly, and build labels

The words binary image, source, disassembly, reconstruction, and build output describe different relationships and should not be collapsed. An archived binary is a captured manifestation. A disassembly is a representation derived from binary instructions. A source disk or source collection may contain historical material, transformed material, or both. A reconstruction is a later effort to make a source representation complete or buildable. A build output is the result of a particular toolchain and stated preparation steps. The C64 source archive’s labels distinguish commented source, assembly-source holdings, and disassemblies, but the labels alone do not prove original authorship, completeness, or byte identity.

Michael Steil’s account of a specific C64 KERNAL-source build attaches its discussion to the 901227-01 record and identifies exceptions involving the missing BASIC-overflow range, a checksum, and the RRBY signature. It supports a version-specific source-to-output statement, not the broader assertion that every C64 KERNAL source copy is original or byte-for-byte complete without qualification.

The `cbmsrc` project likewise describes conversion and reconstruction conditions for its C64 source directories, including qualifications for KERNAL revisions. Its repository documentation is evidence for that project’s stated representation and transformations; it is not independent proof that every tree is an untouched Commodore manuscript.

The 1541 record needs the same restraint. Steil’s 1541 DOS account distinguishes preserved material from a buildable reconstruction and discusses the 1540-to-1541-II sequence. The `dos1541` project supplies a repository-specific revision table and says which checksum and signature bytes stand outside its stated exact-ROM result. Those statements are evidence about the named project and revision, not a general warrant to call a reconstructed tree original source.

Checksums, signatures, missing material, and patches

A digest is meaningful only when its algorithm, exact named artifact, and reporting source are retained. The C64 revision record publishes MD5 values for named entries, and the 1541 directory states an archive checksum convention. Neither source establishes a single canonical digest policy for every physical ROM reading, archive copy, regional image, or later mirror. A provenance entry should therefore say whether a value is archive-reported, project-reported, or independently computed, rather than use an unqualified word such as “canonical.”

Likewise, a missing source range, a calculated checksum byte, a signature byte, and a patch difference are not the same kind of fact. The KERNAL build account names its exceptions; `dos1541` names checksum and signature exceptions for its output; and the C64 revision record describes version-specific changes. Each condition belongs with the particular record that reports it, not with an entire platform family.

C128 revision material adds a separate uncertainty. The C128 ROM-revisions note frames part of its account as an understanding of United States revisions and records intermediate 252343 observations that do not fit the announced revision descriptions. That is useful attributed evidence for a qualified row, but it does not supply a complete country-neutral chronology, a universal hash policy, or a settled C128D/DCR equivalence claim.

A 1541C-to-1541-II comparison makes a different type of limitation visible: it identifies track-zero-sensor handling as a meaningful distinction. Together with the project build notes, this prevents a record from equating adjacent part numbers, a named source branch, and all drive-mechanism behavior.

Access and rights boundary

Public visibility is an access fact, not a reuse grant. The cited archival directories and project pages identify locations at which their descriptions were read; they are cited here as evidence and are not presented as a distribution service. The C64 revision record also reports a rights-related removal history, demonstrating why current availability and legal permission must be recorded as separate fields.

The 1540/1541 service manual includes a reproduction restriction, and the KERNAL build account reproduces a historical copy restriction. Neither establishes permission to redistribute firmware, source, a scan, code, a disassembly, or a derivative compilation. This record therefore uses original analytical prose and claim-local citations only; it contains no firmware bytes, source listing, binary, scan, image, screenshot, or copied source table.

Boundaries of the record

This record deliberately does not teach BASIC or KERNAL interfaces, describe 1541 operation, explain C128 architecture or mode selection, prescribe repair work, configure an emulator, or become a general documentation register. It also does not claim complete custody for every C64, C128, or 1541 manifestation. The unresolved C128 CP/M source-and-bootstrap chain, incomplete C128 regional and keyboard matrix, non-universal hash policy, uncertain archive custody, and version-specific 1541C sensor distinction remain visible limitations rather than gaps to be filled by inference.

See also

• Commodore 128 board profiles
• C64 and C128 technical documentation register
• VICE