c64-kb 0.17.0

package/docs/game-design/production-planning.md

@@ -0,0 +1,349 @@
+<!-- doc-type: reference -->
+
+# Production Planning for C64 Games and Demos
+
+How people who shipped C64 software decided what to build first, how much
+memory each part could have, how big the game could be, and what tools they
+wrote. These are design patterns, not techniques: decisions taken before or
+between the techniques, each naming the techniques and recipes here that
+carry it out. Every fact is attributed to a person and a year; a number is
+theirs or is shown as a sum. Nothing on this page was measured in VICE.
+
+---
+
+## build_order — Build the thing everything depends on first
+
+**Kind:** production
+
+**Applies to:** scrolling_platformer, horizontal_shmup, vertical_shmup, single_screen_platformer, top_down_adventure, action_puzzle, beat_em_up, racing
+
+**Realised by:** soft_scroll_h, infinite_scroll_h, tile_map_render, tile_grid_collision, wave_director, object_pool, logic_rate_decoupling, memory_layout_plan, platformer-scaffold, simple-shmup, tile-map-render, soft-scroll-h, memory-layout
+
+**Sources:** John and Steve Rowlands (Commodore Format, 1992 to 1993); Peter Liepa (interview transcript published by BBG Entertainment, 2022); Manfred Trenz (Recollection diskmag interview); Jeff Minter (COMPUTE!'s Gazette, August 1983); Codebase64 wiki guide to programming games (unattributed); Chris Crawford, The Art of Computer Game Design (1984, 1997 electronic edition)
+
+**Checks:**
+
+- Boots and scrolls the level as a runnable PRG before any enemy module is linked in.
+- Runs the same entity positions after a fixed frame count whether the placeholder art or the final art is loaded.
+- Builds each milestone in the plan as its own PRG that reaches a screen in VICE.
+- Keeps a memory map file in the repository before the first full build, and the linker map agrees with it.
+
+**Why.** The order in which parts are built decides how much rework there is.
+The Rowlands brothers wrote in Commodore Format in December 1992 that they
+could not start on player-to-enemy collision because there were no enemies
+yet, and could not write the enemies until the scrolling worked, because the
+enemies are tied to the scrolling level. Their priority list therefore put
+the screen-handling routines first. John Rowlands spent weeks on the scroll
+code before anything sat on top of it.
+
+Peter Liepa's account of Boulder Dash (2022) shows the same rule applied to a
+physics game. The first thing he worked on was making the rocks and the
+digging behave, because the physics had to be interesting before anything
+else mattered. At that stage dirt was drawn as squares, rocks as circles and
+the player as a plus sign. The name came four or five months in.
+
+Manfred Trenz (Recollection interview) said he coded small test programs to
+see whether an approach was the right one before committing to it, and gave
+the large sprite routines in Katakis as the example; the plan should name
+the test program behind each risky routine, a reader's check rather than a
+harness's. Jeff Minter, interviewed in COMPUTE!'s Gazette in August 1983,
+described adding very small pieces one at a time as a disciplined style, and
+said Attack of the Mutant Camels took four or five weeks.
+
+**The shape.** Two written plans exist that an agent can follow. The
+Codebase64 guide names eight stages, paraphrased here: plan and talk the idea
+through; design on paper, including sketched maps and the graphics; code the
+core routines; add sound; add the presentation screens; fix bugs; hand the
+build to testers; compress. Chris Crawford's chapter on the design sequence
+(1984) puts a design phase before any code, made of three structures worked
+out together: the I/O structure (what the player sees and touches), the game
+structure (the causal rules and obstacles) and the program structure, of
+which he says the memory map is one of the most important elements. He then
+asks for an evaluation pass before programming: does the design meet its
+goals, can any value run away without bounds, is there a shortcut to victory,
+and should the project be aborted now rather than later. He says most of his
+own designs were aborted at that stage, and that no more than five or six
+playtesters should ever be used.
+
+A build order that fits both plans and the diaries:
+
+```text
+step  deliverable                          proves
+1     memory map on paper                  the parts fit
+2     scrolling or playfield engine        the dependency root works
+3     player movement on placeholder art   the feel
+4     one enemy, one collision             the core loop
+5     level data from an editor            content can scale
+6     music and effects in their budget    the raster and RAM plan holds
+7     title, get-ready, game-over states   the state machine is complete
+8     tests outside the team, then pack    it ships
+```
+
+**What breaks when it is skipped.** Enemies built before the scroller are
+rewritten when the scroll representation changes; final art drawn before the
+physics is redrawn when the tile size changes; a risky routine never proved
+in a test program is found too slow when everything already depends on it.
+
+**Variations.** A single-screen game's dependency root is the playfield and
+collision grid; a demo's is the loader (`../demo-design/demo-design-philosophy.md`).
+
+Related: `./game-design-patterns.md`, `./c64-game-archetypes.md`,
+`../toolchains/memory-layout-planning.md`.
+
+---
+
+## memory_budget_first — Music and every other part get a byte budget before the code
+
+**Kind:** production
+
+**Applies to:** scrolling_platformer, horizontal_shmup, vertical_shmup, single_screen_platformer, top_down_adventure, puzzle, action_puzzle, beat_em_up, racing, sports, demo_intro, dentro
+
+**Realised by:** memory_layout_plan, sid_play_routine_pattern, sfx_engine_beside_music, exomizer_basics, multi_load_sequencing, memory-layout, sid-music-player, sfx-engine, level-rle-decoder
+
+**Sources:** Chris Butler interviewed by Gary Penn (Zzap!64 issue 17, September 1986); Manfred Trenz (Recollection diskmag interview); Andrew Braybrook, Birth of a Paradroid (Zzap!64, 1985); Dane of Booze Design (Vandalism News issue 65)
+
+**Checks:**
+
+- Lists every part of the program with a byte figure in a budget file, and the figures sum to no more than the RAM the plan claims.
+- Places the music player and tune data inside the region the budget reserves for them, as read from the linker map.
+- Finishes the music play call inside its raster allowance on PAL and on NTSC.
+- Leaves the amount of free RAM the budget promised after the final link, or records the overflow with a date.
+
+**Why.** Music is the part most often squeezed out, because it arrives last
+and needs a fixed block of RAM and a fixed slice of every frame. Chris Butler
+told Zzap!64 in 1986 that Commando was completely finished when Rob Hubbard
+came to add the music, said he needed about 6K, and there was no room; a
+level was cut to make it. Manfred Trenz said he hated playing Turrican
+without in-game music, and that there was no possibility of putting it in.
+Dane of Booze Design said a continuous soundtrack in a C64 demo is tricky
+precisely because the visuals and effects on screen limit the memory and
+raster time left for it.
+
+**The shape.** Andrew Braybrook's Paradroid diary (1985) is the worked
+example. He set out to use the 64K of RAM plus the 4K under the I/O area,
+which he calls a 68K plan (64 + 4 = 68). He allowed about 2K for the game's
+text and found he needed more like 4K; a smaller patrol-route table freed the
+space, and the text went under the I/O devices. Earlier in the same diary the
+transfer sub-game grew to about 2K once its presentation was added, larger
+than he had planned for, and had to be squeezed in; a week later the last
+spare 4K went to deck data. The budget was written first, overflowed in two
+places, and was rebalanced rather than abandoned.
+
+A budget file an agent can keep alongside the source:
+
+```text
+part            reserved  measured  note
+game code       ---       ---
+level data      ---       ---       packed or raw, say which
+charsets        ---       ---       per VIC bank
+sprites         ---       ---       per VIC bank
+music player    ---       ---       player and tune together
+sound effects   ---       ---       tables and code
+text            ---       ---       Braybrook doubled his
+free            ---       ---       the overflow reserve
+```
+
+Fill the reserved column before the first build and the measured column from
+the linker map after each one. For demos, Dane's remark implies a budget per
+part: each part hands the music a memory and raster allowance to write to.
+
+**What breaks when it is skipped.** The game ships without music (Trenz), or
+a level is cut at the end to make room (Butler), or the play call overruns
+the frame on NTSC because it was never given a slice.
+
+**Variations.** A multi-load game can budget per level and reload the music
+with it; a single-load game cannot. Butler's own saving in his next game was
+character graphics in place of sprites in Space Harrier, to save memory.
+
+Related: `../toolchains/memory-layout-planning.md`, `../techniques/memory-banking.md`,
+`../techniques/music-sid.md`, `../music/music-production-reference.md`.
+
+---
+
+## scope_and_region — Decide the load model, the video standard and the schedule margin at the start
+
+**Kind:** production
+
+**Applies to:** scrolling_platformer, horizontal_shmup, vertical_shmup, single_screen_platformer, top_down_adventure, puzzle, action_puzzle, beat_em_up, racing, sports, demo_intro, dentro, party_intro_4k
+
+**Realised by:** pal_ntsc_detection, multi_load_sequencing, exomizer_basics, sprite_multiplex_game, logic_rate_decoupling, pal-ntsc-detect, memory-layout, sprite-multiplex-game
+
+**Sources:** Sarah Jane Avory (development blog, 10 September 2020); Andrew Braybrook, Mental Procreation (Zzap!64, 1987); Chris Butler (Zzap!64 issue 17, 1986); Manfred Trenz (Recollection diskmag interview); psenough, Teach Yourself Demoscene in 14 Days (MIT licensed guide); Kodiak64 (Seawolves sales post, July 2025)
+
+**Checks:**
+
+- Reaches the first level from one file load when the plan says single-load.
+- Runs to the end of a level under `-model ntsc` without the frame counter skipping.
+- Stretches each PAL map section to the NTSC height the plan states, and the section count is the same on both.
+- Takes the same number of seconds to traverse a section on PAL and on NTSC, within one frame.
+- Keeps the on-screen sprite count at or below the limit the plan set for NTSC.
+
+**Why.** Three decisions set the ceiling on everything else: how many loads,
+which video standards, and how much time. Each is cheap on day one and
+expensive on the last day.
+
+**Load model.** Sarah Jane Avory wrote in September 2020 that she made Zeta
+Wing a single load to keep the scope down and to avoid feature creep, and
+that the limits this imposes are the challenge. The core of the game was the
+engine from her earlier game Santron, with updates from Soul Force, so the
+scope decision sat on reused code rather than on a new engine.
+
+**Video standard.** NTSC runs at 60 frames per second to PAL's 50, so a
+raster-synchronised game gets less CPU time per frame. Braybrook's figure in
+the Morpheus diary (1987) is that American machines run about 16 percent
+slower on raster-synchronised games, and his rule was that everything in the
+European version had to leave at least 16 percent spare processor time; he
+later capped the multiplexer at 24 sprites to safeguard the NTSC build. His
+16 percent is a frame-rate figure (50 / 60 = 0.83). Counting cycles from the
+constants in `../hardware/pal-ntsc-reference.md`, a PAL frame is 19,656
+cycles and a 6567R8 NTSC frame is 17,095; 17,095 / 19,656 = 0.87, so about
+13 percent fewer cycles per frame. Not measured here. Avory's answer to the
+same problem is data rather than time: Zeta Wing's PAL map sections are 10
+blocks high and are stretched to 12 for NTSC by copying the first two rows
+again, because there is no RAM for two maps. NTSC then scrolls faster over
+more data and a section takes the same time on both (12 / 10 = 1.2 = 60 /
+50).
+
+**Schedule.** Chris Butler told Zzap!64 he was given about eight weeks to
+write Commando, that it was messy because it was his first time splitting
+sprites, and that there were a lot of bugs, in the gameplay too, because he
+did not have time. Trenz gave 6.5 weeks for the R-Type conversion under
+pressure. psenough's demoscene guide advises reserving buffer time to redo
+or scrap work, typically an extra 20 to 50 percent, and to start small and
+build on what works. The plan should also record a delivery date and a
+non-zero buffer; no build check sees this.
+
+**Sales.** One modern data point, Kodiak64's own figure for Seawolves,
+posted in July 2025: about 110 units over 15 months, 700 to 800 pounds, and the game on
+file-sharing sites within 72 hours of release. Roughly 7 units a month
+(110 / 15 = 7.3); one game, one channel, not a market figure.
+
+**What breaks when it is skipped.** A PAL-only game tears or drops frames
+on NTSC; a game designed as multi-load and then squeezed to a single file
+loses levels late; an eight-week schedule with no buffer ships its bugs.
+
+**Variations.** A game can detect the standard at boot and pick a map set,
+a sprite cap or a logic rate; the Realised-by recipes do the detection. A
+demo's equivalent is trackmo versus parts joined by a key press
+(`../demo-design/demo-design-philosophy.md`).
+
+Related: `../techniques/raster.md`, `../techniques/loaders-packers.md`,
+`../toolchains/release-disk.md`.
+
+---
+
+## tooling_and_editors — Every component gets an editor, and the level editor runs the game's own routines
+
+**Kind:** production
+
+**Applies to:** scrolling_platformer, horizontal_shmup, vertical_shmup, single_screen_platformer, top_down_adventure, puzzle, action_puzzle, beat_em_up, racing
+
+**Realised by:** tile_map_render, tile_grid_collision, charset_animation, table_generation, actor_activation_window, level-rle-decoder, tile-map-render, wave-director, headless-verify
+
+**Sources:** Manfred Trenz (Recollection diskmag interview); John and Steve Rowlands (Commodore Format, 1993); Andrew Braybrook, Birth of a Paradroid (Zzap!64, 1985)
+
+**Checks:**
+
+- Generates every level table in the build from an editor file, with no hand-typed hex in the source.
+- Loads each level file both in the editor and in the game without a conversion step.
+- Changes the matching tile in the VICE screenshot after one map cell is edited and the build is rerun.
+- Flags duplicate and unused characters in a charset with a build-time tool rather than by eye.
+
+**Why.** Manfred Trenz's rule was that every part of a game had to be quick
+to make and quick to alter, which is why each of his games came with its own
+set of editors and small tools. The cost of not having them is in
+Braybrook's Paradroid diary: in one entry he converted the remaining twelve
+decks to hex and keyed them in, about five hours for each of the two steps
+by his figure, so around ten hours (5 + 5 = 10) before the next day's corrections.
+
+**The shape.** John Rowlands wrote in Commodore Format in March 1993 that
+the Mayhem in Monsterland map editor shared the game's own scroll and draw
+code, so that Steve could design a level and then switch straight to the
+game to test it. The editor was the one from Creatures with the Creatures
+scroll code swapped for the Mayhem scroll code, and it carried a small
+graphics editor so any part of a level's appearance could be adjusted in
+place. The workflow he describes is: put the platforms into blocks; load the
+blocks, the character set and the character colours into the editor; design;
+play. Later parts of the diary add utilities that check block designs for
+duplicate and missing characters, and an editor that converts a level's
+happy tileset to its sad one.
+
+The general form is one tool per data table:
+
+```text
+data table          editor or generator         checked by
+tile blocks         block editor                duplicate-char scan
+level map           map editor on game scroller play from the editor
+enemy placements    same map editor, layer 2    activation window test
+charset             char editor                 unused-char scan
+sprite frames       sprite editor               frame count vs table
+music               tracker                     play-call cycle count
+```
+
+On a modern host the editors run on the PC and the game's routines are
+exercised by running the PRG headlessly; the `headless-verify` recipes and
+`../art/asset-pipelines.md` cover the path from editor file to build bytes.
+
+**What breaks when it is skipped.** Hand-keyed data costs hours per level
+and hides transcription errors until play. An editor that renders with its
+own code shows a level the game then draws differently. Steve Rowlands ran
+out of graphic space in the landscape designer in January 1993 and had to
+wait for John to change the editor: the editor's limits are part of the plan.
+
+**Variations.** A puzzle or flip-screen game can use a text-file level format
+and a build-time converter instead; `level-rle-decoder` shows the runtime half.
+
+Related: `../art/asset-pipelines.md`, `../art/art-production-reference.md`,
+`../techniques/scroll.md`, `../techniques/logic.md`.
+
+---
+
+## where_the_documents_are — What survives from the period, and on what terms
+
+**Kind:** production
+
+**Applies to:** scrolling_platformer, horizontal_shmup, vertical_shmup, single_screen_platformer, top_down_adventure, puzzle, action_puzzle, beat_em_up, racing, sports, cracktro, demo_intro, dentro, party_intro_4k
+
+**Realised by:** memory_layout_plan, memory-layout
+
+**Sources:** Video Game History Foundation library announcement (30 January 2025); the diaries and interviews named on this page
+
+**Checks:**
+
+- Ships a sources file in the build's documentation that names an author and a year for every design fact the documentation cites.
+
+The rest is the writer's discipline, not a build property: a person and a
+year for every fact, no unlicensed scan linked, every number the source's or
+arithmetic.
+
+**Why.** An agent asked for a period design document will not find one.
+None of the sources read for this page is an internal 1980s design memo;
+what survives is what developers published at the time and said later.
+
+- Developer diaries in magazines, written while the game was being made:
+  Braybrook's Paradroid and Morpheus diaries in Zzap!64 (1985, 1987) and
+  the Rowlands brothers' Mayhem in Monsterland diary in Commodore Format
+  (1992 to 1993). The text is the publisher's copyright and transcriptions
+  carry no licence of their own: take facts, name the author and the issue.
+- Diskmag interviews, retrospective: Manfred Trenz and Dane of Booze Design
+  in Recollection and Vandalism News. No licence is stated; same rule.
+- Modern developer blogs and posts: Sarah Jane Avory, Kodiak64, and the
+  Codebase64 wiki, which is CC BY-NC-SA and so cannot enter this
+  BSD-licensed repository beyond its facts.
+- Books: Chris Crawford's 1984 text is online in a 1997 electronic edition
+  with his permission, the only period book found with a full design sequence.
+
+The Video Game History Foundation's library, announced on 30 January 2025,
+makes over 1,500 out-of-print magazines full-text searchable, the fastest
+way to find a diary entry by phrase. The foundation states that it does not
+own the intellectual property in the library and cannot give permission to
+reproduce it, and that it operates under US fair-use guidelines; what a
+reader may do with a page is the reader's own question. Museum finding aids
+for arcade-era play-test records exist but were not readable from this
+machine, so nothing about their contents is claimed here.
+
+**What breaks when it is skipped.** A paraphrase of a paraphrase drifts:
+Braybrook's 16 percent becomes a fifth, Butler's 6K a few K. Take the
+number from the sentence the person wrote.
+
+Related: `./game-design-patterns.md`, `../demo-design/demo-design-philosophy.md`.

package/docs/game-design/reference-game-sources.md

@@ -0,0 +1,90 @@
+<!-- doc-type: reference -->
+
+# Reference Game Sources: what an agent may read, and what it may copy
+
+When a mechanism is not in this knowledge base, the next best thing is a
+complete game that does it. This page lists the public C64 game, engine,
+loader and packer sources, what each holds, the licence each states, and
+what this repository may do with it. The repository is BSD-3-Clause
+(`LICENSE`), so a source's licence decides whether its code or text can
+enter a page here.
+
+Every licence below was read at its source on 2026-09-23: the repository's
+`LICENSE` file, the licence section of its README, the file headers, or the
+site footer. "No licence" means none was found in those places. Nothing on
+this page is legal advice; it records what each source says.
+
+---
+
+## The sources
+
+"Adapt" means code may be adapted with attribution and the licence notice
+kept. "Facts only" means read it for mechanisms, formats, table layouts and
+names; write original code and prose.
+
+| Source | URL | What it holds | Licence as stated (where read) | This KB may | Already cited by |
+|---|---|---|---|---|---|
+| c64gameframework (Lasse Öörni, Cadaver) | https://github.com/cadaver/c64gameframework | Multidirectional scrolling game framework: scroll, 24-sprite multiplexer, sprite cache, actors, loader, level and sprite editors. A modified version runs MW ULTRA (repository description). | MIT, full text in the README "License" section, "Copyright (c) 2018-2026 Lasse Öörni". There is no `LICENSE` file, so GitHub's licence field shows none. | Adapt | `techniques/logic.md`, `raster.md`, `scroll.md`, `sprite.md`, `file-io.md`, `loaders-packers.md`, `music-sid.md`; `pitfalls/raster-and-badline.md`; `recipes/kickassembler/easyflash-save.md`, `scroll-panel-split.md`, `sprite-multiplex-game.md` |
+| Hessian (Cadaver) | https://github.com/cadaver/hessian | A complete action adventure game. | README "Code license": program code (`.s` files excluding story and dialogue text), tool code and build scripts are MIT. README "Content license": graphics, levels, music, sound effects and story text are "All rights reserved". | Adapt the code; do not use the content | `techniques/logic.md` |
+| Steel Ranger demo (Cadaver) | https://github.com/cadaver/steelranger-demo | Source of the free demo of Steel Ranger. | README: code, tools and build scripts MIT (2016-2018); graphics, levels, music, sound effects and text "All rights reserved". | Adapt the code; do not use the content | none |
+| Other Covert Bitops sources: Metal Warrior 1 to 4, MW4 Dojo Preview, Escape From New York, BOFH, Advanced Action Movie Simulator, the Amiga and GBA ports | https://cadaver.github.io/games.html | Zipped game sources. Steel Ranger 2 and MW ULTRA have no source link there. | No licence. `games.html` states none; `mw4src.zip` (V1.2) holds no licence file, and its `readme.txt` and `doc/manual.txt` state none. | Facts only | none |
+| Cadaver's articles ("rants") | https://cadaver.github.io/rants/ | Articles on multiplexing, scrolling, interpolation, sprite caches, loaders. | No licence (issue #21 records none). | Facts only | `techniques/logic.md`, `scroll.md`, `sprite.md`, `loaders-packers.md`, `text-mode-render.md`; `recipes/kickassembler/sprite-multiplex-game.md`, `recipes/oscar64/iffl-kernal-skip.md` |
+| Bitfire (Tobias Bindhammer, Bitbreaker) | https://github.com/bboxy/bitfire | Demo loader and framework with a built-in decompressor. | BSD-3-Clause, `LICENSE` file, "Copyright (c) 2021, Tobias Bindhammer". | Adapt | `pitfalls/loader.md`, `techniques/loaders-packers.md` |
+| Sparkle (Sparta/OMG) | https://github.com/spartaomg/SparkleCPP | IRQ loader and disk linker. | BSD-3-Clause, `LICENSE` file, "Copyright (c) 2019-2026, Sparta/OMG". | Adapt | `pitfalls/loader.md`; `techniques/loaders-packers.md`, `memory-banking.md`; `recipes/kickassembler/irq-owns-port.md` |
+| Krill's Loader (Gunnar Ruthenberg) | `loader-v194.zip` from CSDb ("Repository Version 194"); there is no public git repository (`techniques/loaders-packers.md`) | IRQ loader, drive code, decompressors, bundled tools. | README "License" section in the v194 zip: BSD-3-Clause wording, "Copyright 2022 Gunnar Ruthenberg", with a credit request ("Loader by Krill") and a binary clause that wants that credit in the production or in documentation inside the release archive; a website credit alone does not count. Third-party tools and decompressors in the zip keep their own licences. | Adapt, with the credit in the release | `techniques/loaders-packers.md`, `input.md`; `pitfalls/loader.md`, `cia.md`; `formats/iec-disk-reference.md`, `c64-file-formats.md`; `hardware/cia-reference.md`; `toolchains/cc65-reference.md`; `c64-failure-patterns.md`; the game and demo design pages |
+| TSCrunch (Antonio Savona) | https://github.com/tonysavon/TSCrunch | Byte-aligned LZ+RLE cruncher and three 6502 decrunchers. | Apache-2.0, `LICENSE` file. | Adapt, with the notice | `techniques/loaders-packers.md` |
+| Exomizer (Magnus Lind) | https://bitbucket.org/magli143/exomizer | Cruncher (C) and decrunchers for several assemblers. | Current master: zlib-style headers, "for any purpose, including commercial applications" (read in `src/exo_main.c`, `src/search.c`, `exodecrs/exodecrunch.s`, `exodecrs/kick/exodecrunch.asm`). Older copies differ: the Exomizer 3.1 inside Krill's v194 zip has cruncher C files that say "non-commercial, non-profit", while its decrunchers say "any purpose". The GitHub mirror `bitshifters/exomizer` has no licence file. | Adapt a current decruncher, keeping the notice and marking changes | `techniques/loaders-packers.md`; `pitfalls/loader.md`; `art/asset-pipelines.md`; the game and demo design pages |
+| Oscar64 (drmortalwombat) | https://github.com/drmortalwombat/oscar64 | The C compiler, its runtime library and headers, samples. | GPL-3.0, `LICENSE` file. No runtime-library exception was found in `LICENSE` or the README, and the installed `include/` files carry no notice. | Use as a tool; facts only from its source. Whether a PRG that links its runtime library is affected is not settled here. | `toolchains/oscar64-reference.md`, `oscar64-headers-reference.md`; `recipes/oscar64/attract-replay.md`, `pal-ntsc-detect.md` |
+| drmortalwombat's Oscar64 games: Corescape, Plekthora, MetalMayhem, zombies, ballnchain, minotrace, bunkerdigger, shalldom; OscarTutorials | https://github.com/drmortalwombat | Complete games written in Oscar64 C. | GPL-3.0: `LICENSE` file read for Corescape; GitHub's licence field says GPL-3.0 for every one listed. | Facts only | Corescape: `techniques/logic.md`, `raster.md`, `sprite.md` |
+| mwenge's disassemblies: Uridium (Braybrook), Iridis Alpha and Gridrunner (Minter) | https://github.com/mwenge/uridium, https://github.com/mwenge/iridisalpha, https://github.com/mwenge/gridrunner | Commented, buildable reverse-engineered source of commercial games (64tass). | No licence. No `LICENSE` file and no licence wording in any of the three READMEs. The READMEs make no claim over the games. | Facts only | Iridis Alpha: `techniques/logic.md` |
+| Mark Moxon's annotated C64 Elite | https://github.com/markmoxon/elite-source-code-commodore-64 and https://elite.bbcelite.com | The 1985 Bell and Braben source, reformatted and annotated. | README, "A note on licences, copyright etc.": no licence, "intentionally no `LICENSE` file"; readers may "read and fork this repository... but that's it". Game copyright D. Braben and I. Bell 1985; commentary copyright Mark Moxon. | Facts only | `techniques/effects-vector-3d.md`, `maths.md`; `recipes/kickassembler/wireframe-ships.md` |
+| Lode Runner reverse engineering (XekriRedmane) | https://github.com/XekriRedmane/lode_runner_reveng | Literate source of the Apple II Lode Runner (1983) that assembles to the original. | README "License": CC BY-SA 4.0. The README says nothing about the game's own rights; the game is Doug Smith's and Broderbund's. | Facts only | `techniques/logic.md` |
+| a2-lode-runner (fschuhi) | https://github.com/fschuhi/a2-lode-runner | Research notes and a browsable site built on the repository above. | README "License and attribution": its own scripts and tests MIT (`LICENSE`); the research material and documentation CC BY-SA 4.0 (`LICENSE-CC-BY-SA-4.0.md`); "Rights in the original game ... remain with their holders." | Facts only | `techniques/logic.md` |
+| Ultima IV Remastered (Per Olofsson, MagerValp) | https://github.com/MagerValp/u4remastered | The C64 Ultima IV rebuilt with new loaders; builds with cc65 from the original disk images, which the repository does not include. | README "License and Copyright": code Apache 2.0, "© 2006-2015 Per Olofsson"; new graphics and intro music are their artists' copyright; the original game "© 1985 Origin Systems". | Adapt Olofsson's code, with the notice; the game data is not his | none |
+| Codebase64 wiki | https://codebase.c64.org/ | Routines and articles, including a game sources section. | Footer: "CC Attribution-Noncommercial-Share Alike 4.0 International", "Except where otherwise noted". | Facts only (non-commercial and share-alike terms do not fit a BSD repository; `game-design/production-planning.md` says the same) | `hardware/` references; `techniques/scroll.md`, `sprite.md`, `logic.md`, `memory-banking.md`, `cpu-cycle-tricks.md`, `text-mode-render.md`; `recipes/kickassembler/reu-dma.md`; the game design pages |
+| C64-Wiki | https://www.c64-wiki.com/ | Reference articles on the machine, games and people. | Footer: "Content is available under GFDL unless otherwise noted." The version is not stated on the copyrights page. | Facts only | `hardware/` references; `pitfalls/cia.md`, `kernal-and-io.md`, `sid.md`; `techniques/scroll.md` |
+| Microchess (Peter Jennings), on 6502.org | https://6502.org/source/games/uchess/uchess.htm | 6502 chess program, adapted for a serial terminal by Daryl Rictor. | Page: "MicroChess (c) 1996-2002 Peter Jennings"; the poster was "given permission to distribute this program"; "Please get his permission if you wish to re-distribute a modified copy". | Facts only | `techniques/logic.md` |
+
+---
+
+## Rules for this KB
+
+- **The KB ships original code.** Every listing here is written for the page
+  and built by `npm run check:listings`. MIT, BSD, Apache and zlib code may
+  be adapted with attribution and its notice kept, but no page has done so
+  yet; keep writing original listings unless the maintainer decides
+  otherwise.
+- **Prose is always original.** Do not paste a source's text, even from an
+  MIT repository.
+- **Facts only** for GPL sources, sources with no licence, CC BY-NC-SA and
+  GFDL wikis, and disassemblies of commercial games. A disassembly's stated licence
+  describes the repository; the READMEs here make no claim over the games
+  themselves.
+- **Game content is not code.** Hessian's and Steel Ranger's graphics,
+  levels, music and text are all rights reserved, even though their code is
+  MIT.
+- **Cite by URL** in the page's Sources section, with the licence in
+  brackets and the file you read, as `techniques/logic.md` does:
+  `https://github.com/cadaver/c64gameframework (MIT): actor.s`. Say "facts
+  only" beside a source that is not open for copying.
+- **Check the licence again before adapting.** Licences change: Exomizer's
+  cruncher moved from non-commercial terms to zlib-style ones between the
+  copy in Krill's v194 zip and the current master.
+
+---
+
+## Sources
+
+- Licence texts read with `gh api repos/<owner>/<repo>` (licence field),
+  `gh api repos/<owner>/<repo>/contents/LICENSE` and
+  `gh api repos/<owner>/<repo>/readme`, for every GitHub repository in the
+  table, 2026-09-23.
+- https://cadaver.github.io/games.html and
+  https://cadaver.github.io/games/mw4src.zip (files listed and read).
+- https://bitbucket.org/magli143/exomizer, raw file headers on `master`.
+- `loader-v194.zip` (Krill's Loader, Repository Version 194): `loader/README`
+  "License", and `loader/tools/exomizer-3.1/src/*.c` and `exodecrs/`
+  headers.
+- https://codebase.c64.org/doku.php?id=start (footer).
+- https://www.c64-wiki.com/wiki/C64-Wiki:Copyrights (footer).
+- https://6502.org/source/games/uchess/uchess.htm.