Make the evidence
possible to check.

Choose evidence that answers the question

Original software, source code, manuals, datasheets, schematics and contemporary accounts help us understand what people built and how it worked. Measurements and reproducible experiments can test a specific explanation.

No source is automatically conclusive. A manual may contain a mistake or describe another hardware revision. A magazine review records one experience. An interview may preserve a valuable recollection without settling an exact date.

Prefer evidence close to the subject, compare independent sources where useful, and investigate disagreements. Modern research and emulator implementations can help explain a problem; their conclusions still need evidence appropriate to the claim.

A citation should identify the author or organisation, publication, edition or date, and a page, section or other useful locator. Link to the original document when available. A link to another Code198x explanation helps a reader explore; it does not replace the underlying source.

Say what has actually been checked

These words describe different kinds of evidence. They are not interchangeable stamps of approval, and pages need only use the distinctions relevant to their claims.

Proposed

An explanation, design or approach to investigate. It has not yet been established by a source or a test.

Source-checked

A claim has been compared with identified sources. The citation should let a reader find the relevant passage.

Built

The source produced an output with specified tools. This does not establish that the program behaves correctly.

Run

The program was executed on a named machine or emulator. Say what was observed and under which configuration.

Captured

An image, recording or trace came from an identified run or measurement. A single capture cannot demonstrate every behaviour.

Inferred

A conclusion drawn from evidence. Explain the reasoning and what would change it.

For an execution check, identify the source revision, build tools, target model, emulator version or hardware configuration, inputs and observed result. Record limitations: a successful run in one emulator does not establish identical behaviour on every machine.

Make examples reproducible

A runnable lesson should provide the source and steps needed to reach its result. Explain supplied files before relying on them. Check normal play as well as relevant boundaries, failure and retry behaviour; a screenshot alone does not show that a game works.

Pseudocode, diagrams and hand-worked traces have a different role. They explain a model rather than execute on a particular machine. Label that distinction and check that their examples are internally consistent.

A reusable pattern should name its problem, implementation, assumptions and costs. A finished game should fulfil its agreed scope. A small BASIC game can be complete without matching the scale or polish of a commercial release.

Treat the machine and the emulator as things to investigate

When a result surprises us, possible explanations include our program, an emulator limitation, a hardware variant or a documentation error. Compare evidence before deciding which explanation fits.

Claims about electrical signals, analogue output or precise timing need evidence suited to those questions. Name stock, expanded and successor configurations, and separate the host tools used to build a program from the hardware needed to run it.

Modern comparisons need limits too. Smaller code is not necessarily faster, and fewer instructions do not automatically mean less energy. Explain what a change enables and how its effect was established.

Write history accurately and proportionately

Distinguish documented facts, recollections, allegations, disputed accounts and interpretation. Do not invent motives, dialogue or convenient stories, or award an unqualified “first” where the evidence is more complicated.

Technical achievement does not excuse harmful conduct. Relevant, documented wrongdoing belongs in an accurate account, with attribution and age-appropriate language. Avoid sensationalism and unsupported claims about people. The Vault provides room for fuller context when a lesson needs only a short explanation.

Review AI-assisted work by the same standards

AI can assist drafting, programming and investigation. Its output is not evidence that a fact is true or a program works. Check claims against sources and test code appropriately; retain uncertainty where the evidence does not settle a question.

Reuse our writing under CC BY 4.0

Unless a work carries a different notice, original Code198x prose is licensed under Creative Commons Attribution 4.0 International (CC BY 4.0). This covers our lessons, reference writing, documentation, editorial articles, captions and page copy, including explanatory pseudocode.

You may share and adapt that writing, including commercially. Credit Code198x and any named authors, retain the supplied notices, link to the licence and indicate changes. Do not imply endorsement or restrict the rights granted by the licence.

For example: “Adapted from A Program Is Instructions, Code198x, CC BY 4.0. Examples shortened for a worksheet.” Link the title to the original page and the licence name to its terms, and retain any additional attribution supplied there.

The prose licence does not cover software, executable examples, images, diagrams, recordings, fonts, game assets, ROMs, names or logos unless separately stated. Third-party and inherited material retain their own terms. The maintained code samples use MIT. See the repository licence notice for the scope and the full legal terms for the licence conditions. Contributors retain copyright in their original work.

Explain where images and assets come from

Captures should identify the software and relevant configuration. Illustrations should be recognisable as illustrations; do not present a mock-up as executed output. Record provenance and permissions for assets, and credit artists, authors and photographers where they can be established.

Games, artwork, photographs, logos and trademarks belong to their respective owners. Identify third-party material and any licence attached to it separately from our own work. Reproduction does not imply endorsement or affiliation. Keep excerpts and images proportionate to their explanatory purpose.

Do not include third-party ROMs, games or assets in downloads without permission to distribute them. The ROM guide explains setup needs; our name and logo guidance covers the project’s marks.

Rights-holders can request removal through the contact routes below. We will remove the material on request.

Help us put things right

If something is wrong or unclear, include the page URL, the passage or behaviour, and what led you to question it. For a program fault, include the steps and machine or emulator configuration. Sources and suggested corrections are welcome; you do not need to know the answer before reporting a problem.

Report a problem on GitHub or contact us through Discord. Avoid posting personal information in public reports. The contribution guide also lists ways to help check the material.

We assess corrections against the evidence and update the explanation. When sources remain in conflict, the page should say what is uncertain rather than manufacture certainty.