Primary material
Manuals, data sheets, service manuals, original source releases, contemporary developer notes, and scans of period magazines or books.
Sources & standards
How we know what we claim.
Code Like It's 198x is part curriculum, part reference shelf, and part public workshop. That only works if the site is clear about evidence: what was run, what was read, what was inferred, and what still needs checking.
The source ladder
stronger evidence firstVerified output
A lesson program that builds from the repository, runs in the named emulator or on hardware, and produces the screenshot or behaviour shown on the page.
Measured hardware
Photos, capture cards, logic analyser traces, disk or tape flux captures, and other evidence taken from real machines when a claim needs that bar.
Trusted secondary work
Modern retrospectives, interviews, emulator documentation, preservation projects, and community research used with attribution and checked against stronger evidence where possible.
What each section owes you
site contractLessons
The code must build, run, and show the thing the prose says it shows. If a ROM is needed, the page says so without redistributing it.
Pattern Library
A pattern is reusable only after it exists as working code, with the system, language, and limits named clearly.
The Vault
Historical claims need a source trail. Primary sources win; oral history and modern writing are useful, but they are labelled for what they are.
Screenshots and video
Images should be generated from our builds, our emulator captures, real hardware captures, or software we have actually booted. Captions should say enough to understand the origin.
What counts as valid
source rulesGood enough on its own
- Original manuals, data sheets, service manuals, schematics, source releases, ROM listings, and official developer documentation.
- A reproducible build and run from this repository, with the command, target, emulator or hardware route, and observed result named.
- A capture from real hardware when the claim is specifically about electrical behaviour, analogue output, timing edge cases, or physical media.
Useful with attribution
- Period magazines, books, adverts, interviews, reviews, and type-in listings, especially when scanned or quoted from the original publication.
- Modern emulator documentation, preservation notes, community research, reverse-engineering write-ups, and long-lived reference sites.
- Oral history and retrospective interviews, clearly treated as recollection unless supported by contemporary material.
Not enough by itself
- AI output, unsourced summaries, forum hearsay, copied wiki text without a trail, or a screenshot whose origin cannot be explained.
- A passing emulator run as proof of exact hardware timing, unless the page only claims emulator behaviour.
- A memory, anecdote, or common belief when the page is making a specific historical or technical claim.
Evidence labels
plain English markersThe source was built from the repository.
The program was run in the named emulator or on named hardware.
The screenshot, image, audio, or video came from that run.
The factual claim has a source trail.
The prose is drawing a conclusion from sources or observed behaviour, not quoting a source directly.
The page is honest that the claim is not fully verified yet.
AI is not a source
Drafting help does not make a claim true.
AI can help rough out prose and code, but it cannot stand in for a manual, a trace, a build log, a screenshot, or someone who was there. If an AI draft introduces a fact, that fact still needs an ordinary source before it belongs on the site.
Code builds from the repo
Screenshots come from real runs
Historical claims cite sources
Unsettled claims stay labelled
Screenshots, copyright and ROMs
Show the result, do not ship what is not ours.
The site can show screenshots and short clips from software that has been booted for testing, review, or documentation. It does not distribute commercial ROMs, disks, tapes, Kickstarts, kernels, or copyrighted assets as downloadable course material.
Emulator versus hardware
Use the right level of proof for the claim.
Emulator evidence is valid for lessons, screenshots, normal program output, and the behaviour learners are expected to reproduce. Hardware evidence matters when a page claims exact timing, analogue display behaviour, physical media behaviour, or anything where the emulator itself is part of the question.
Lesson works in the supported run path
Caption names the capture source
Hardware-only claims need hardware evidence