GEOS documentation, reconstructed source and binary record

GEOS documentation, reconstructed source and binary record is a documentary guide to two published GEOS references and to a later, separately maintained reconstruction of parts of GEOS 2.0. It distinguishes the documentary identity of the manuals from the status of the reconstruction project's source tree, reference binaries and build outputs. It does not attempt to restate the desktop, application, or general product history covered by GEOS on the Commodore 64 and 128.

The surviving records identify related but non-equivalent materials. An archival transcription of the GEOS 2.0 User's Manual names Berkeley Softworks and the Commodore 64, 64C and 128 computers. The Official GEOS Programmer's Reference Guide has a different stated scope: its front matter identifies it as a guide for the C64, 64C and 128 covering versions 1.0 through 1.2, credits Michael Farr, associates the work with Berkeley Softworks and Bantam Books, and gives January 1987 as its Bantam Book date. A modern project describes itself instead as reverse-engineered source for the English GEOS 2.0 KERNAL and disk and input drivers. Its statements are evidence about that project's reconstruction and build process, not evidence that Berkeley Softworks released this source tree.

Published documentation

The user manual and programmer's guide should be catalogued separately. The user-manual transcription supplies a title and platform line for a Version 2.0 manual, but an archive host and OCR transcription do not by themselves establish every detail of a physical copy's printing history or chain of custody. The programmer's guide supplies its own bibliographic facts: its stated title uses the word “Official”, its coverage is versions 1.0–1.2, and its front matter names Michael Farr, Berkeley Softworks and Bantam Books. The word in the programmer guide's title does not automatically make every other GEOS document an edition of that guide, nor does it settle the precise edition history of a scan.

The two documents also serve different purposes. The user manual is oriented toward operation and work disks. Its errata discuss the relationship between the DESKTOP 2.0 and CONFIGURE 2.0 files and, in a stated disk-drive circumstance, place an application and its documents on the same work disk. The programmer's guide is developer-facing material: it discusses KERNAL routines, program organization and file structures, including VLIR use. A later source-tree layout should therefore not be mistaken for a map of the source arrangement used by the original developers merely because the period guide documents an interface or file concept.

C64 and C128 qualifications

The platform labels do not describe a single undifferentiated runtime. In the user manual's tutorial, the supplied C128 boot procedure is described as booting the computer in C64 mode. The programmer's guide's C128 notes separately describe C64 GEOS software operating in the C128 environment in 40 columns and document compatibility choices for 40-column, dual-mode and 80-column software. These are documentary statements about the covered versions and procedures; they should not be generalized to every GEOS edition, application or later enhancement.

The reconstruction project uses a related but distinct vocabulary for its own build variants. It lists a `bsw128` variant as GEOS 128 2.0 with 128 KB RAM and VDC 640-pixel-width support, but also says that this variant needs further work to boot. It further documents a C128 option for a native 1571 burst driver. The manual and project records can be read together to identify a C64/C128 distinction, but each is authoritative only for what it describes: the printed manuals for their instructions and documented compatibility conventions, and the project for its reconstructed build configurations.

Reconstruction provenance and scope

The pinned project README identifies the reconstruction as covering the English GEOS 2.0 KERNAL plus disk and input drivers for the C64 and C128. It describes the source as reverse engineered, heavily reorganized and modularized. The same account attributes an earlier 1999–2002 reverse-engineering effort to Maciej Witkowiak and a 2015–2016 cc65 port, reconstruction and modularization effort to Michael Steil. This provenance distinguishes the repository from a period publisher's source release. It also limits what the repository can demonstrate: a project description can substantiate its own stated method, files and goals without proving the contents or authenticity of every historical distribution.

The project explicitly says that its source-file division need not match the layout of the original binaries. It gives the filesystem and application/accessory loading code as an example: code that was not separated in the original KERNAL binary is divided into `filesys.s` and `load.s` in the reconstruction. That statement is important when using the tree as a technical record. A readable modular source arrangement can be valuable for analysis, but it is not a claim that the original commercial source was organized in the same files.

The project also identifies boundaries beyond the reconstructed KERNAL and drivers. Its default build documentation lists KERNAL components, disk and input drivers, combined and compressed program images, and a `geos.d64` disk image. The README says that the disk image can use a `GEOS64.D64` template if one is present, with specified files replaced; otherwise it is newly made, with an optional desktop file under the stated condition. This makes an application disk, a source-tree build artifact and a period distribution medium different records even where their filenames or functions are related.

Binary terminology and comparison record

Careful terminology prevents the phrase “binary record” from implying a complete official archive. The following labels describe the project documentation rather than a universal authentication of all GEOS media.

Term	Meaning in this record	Boundary
Original distribution binary	A historical compiled GEOS 64 or GEOS 128 2.0 distribution form to which the project compares a standard build.	The README's comparison statement does not identify every regional, patched or later distribution.
Project reference binary	A file in the repository's `reference/` directory, which the README describes as an original binary from a cbmfiles.com version.	This is a project-stated reference source, not an independently completed provenance census for all original media.
Rebuilt output	A file generated by the project's build process. The README represents a standard compile as producing binaries identical to the specified GEOS 64 and 128 2.0 distribution binaries.	The statement is attributed to the pinned project state and is not a claim about every configuration, compiler environment or derivative.
Patched or custom variant	A build option such as `gateway`, `wheels`, `bsw128` or `custom`, with changes or configuration choices described by the project.	The README says that the listed Wheels and `bsw128` variants need more work to run or boot; they must not be represented as completed original releases.

The project says that `regress.sh` compares output with reference binaries and gives `make regress` as a command that builds selected variants and performs that comparison. In the same README, the default C64 build is described as including named 1541, 1571 and 1581 drive-driver files and several input-driver files, while configuration selects which supported drive and input driver are included in the KERNAL image. These facts document the project's build design. They do not establish that every listed driver is present on every period disk, that every project output is a preserved distribution binary, or that the repository reconstructs all GEOS applications.

The project records a historical account of three copy-protection measures involving the loader, a serial-number relationship with major applications, and KERNAL traps. It also notes ways in which its version differs from the original loader arrangement. For documentary purposes, that is a description of historical technical context and of the reconstruction's stated boundary. It is not a reason to reproduce protected software, provide bypass instructions, or treat the record as a distribution channel.

Dates, manifestations and uncertainty

The date evidence concerns more than one event or artifact. The Centre for Computing History's collection record describes GEOS as a C64 release in 1986 and gives its Version 2.0 item a “Date Published” value of 1986. By contrast, Bo Zimmerman's maintained FAQ says that GEOS 1.0 was released in 1985 and characterizes the final worldwide Berkeley Softworks GEOS 2.0 as occurring around 1987. The programmer-guide front matter gives January 1987, while the user-manual archive item is labelled 1988-07.

These dates should remain attributed rather than averaged into one release year. They may refer respectively to a museum catalogue's collection item, a software-version chronology, a book publication, and an archived manual manifestation. The available sources do not establish a single date that can safely be assigned to every GEOS version and document. This article consequently treats the disagreement as a record-management issue, not as a choice between sources.

Citation and reuse boundary

The published programmer's guide carries an all-rights-reserved notice and a reproduction restriction in its front matter. The reconstruction README asks readers to respect the underlying GEOS licence while describing only intellectual property added by reverse engineering and later improvements as public domain. Neither statement is a complete chain of title or a general licence for the manuals, original software, reference binaries, reconstructed outputs or other associated material.

Accordingly, this article cites and summarizes records in new prose. It does not reproduce scans, OCR text, source code, disk images, binaries, screenshots or other source media. C64 Wiki's source policy likewise distinguishes a citation from authorization to copy and treats restricted material as citation-only unless a separate licence or permission record supports reuse. Names are used here solely to identify the documented products, publications and project records.

See also

• Commodore 128
• Commodore 1541