c64-kb 0.17.0

package/docs/demo-design/demo-composition.md

@@ -0,0 +1,349 @@
+<!-- doc-type: reference -->
+
+# Demo Composition
+
+How a multi-part C64 demo is put together: what one part owes the next, how a
+part ends, how long anything is allowed to run, how the music survives the
+joins, and in what order the work gets done. These are design patterns, not
+techniques. Each one names the techniques and recipes that realise it; the
+mechanics live on those pages. `./demo-design-philosophy.md` covers why demos
+exist and the lifecycle of a release; this page starts where a group has parts
+on disk and has to make a demo out of them.
+
+No archetype covers a full multi-part demo; the nearest are `demo_intro` and
+`dentro`, and `party_intro_4k` inherits the same rules at a smaller scale.
+Sources are named in prose. Nothing here was measured on this machine unless a
+sentence says which repo page did.
+
+---
+
+## part_lifecycle — What one part owes the next
+
+**Kind:** structure
+**Applies to:** demo_intro, dentro, party_intro_4k
+**Realised by:** irq_chain_table, stable_raster_irq, multi_load_sequencing, sparkle_irq_loader, krill_loader_integration, vic_bank_select, memory_layout_plan, sid_play_routine_pattern, irq-chain, memory-layout, sid-music-player
+**Sources:** Linus Åkesson, Spindle v2 documentation (2015); Raistlin, Stopping Music Popping (2023)
+
+**Checks:**
+- Every part writes $D011, $D012, $D015, $D016, $D018 and $DD02 before its first frame is shown.
+- No part writes $DD00 when it runs under a loader that owns that register.
+- After a part's clean-up returns, the IRQ vector points at a handler the next part installed, not at a handler in memory the next part has loaded over.
+- The music play routine is entered exactly once per frame during a part's preparation and fade-out.
+- No load in the disk image overlaps a page range the next part declares inherited.
+
+**Why.** A part written on its own assumes a clean machine. A part in a demo
+follows another part, and inherits whatever that part left in the VIC, the
+SID, the interrupt vector and RAM. Åkesson's Spindle documentation makes the
+contract explicit because the loader runs between parts and needs to know what
+each one touches. The same contract holds with any loader, or with none.
+
+**The shape.** Åkesson divides a part into six routines that the framework
+calls in order. In this page's words:
+
+```
+stage      runs with IRQs   job
+prepare    enabled          build tables and speedcode, copy data; no VIC writes
+set up     disabled         write the VIC registers and colour RAM; fast
+interrupt  (is the IRQ)     the effect's per-frame work; vector at $FFFE
+main       enabled          framebuffer effects that do not reach full frame rate
+fade out   enabled          raise a flag the effect reads; return "done" when the fade has finished
+clean up   enabled          tear down: stop interrupts, wait for a chosen raster line
+```
+
+Preparation of the next part overlaps the current part's run, which is why
+prepare may not write VIC registers: the screen still belongs to the part on
+display. The next part's remaining data finishes loading after fade out
+reports done and before clean up is called (Åkesson).
+
+What a part hands back is what it owned: the interrupt vector, the six VIC
+registers in the first check, the sprite enable bits, the SID registers its
+effects wrote, and any memory it did not declare as inherited. Åkesson lists
+the registers to re-initialise because the previous part may leave unexpected
+values in them; that is the pattern.
+
+**Memory inheritance.** Two adjacent parts may not overlap in RAM unless the
+second declares that it inherits a page range from the first. Åkesson's linker
+inserts a filler part when two neighbours collide: a black screen with no
+badlines and an interrupt handler that only calls the music player. A
+deliberate filler is the seam a transition is built in. The loader keeps a
+fixed region ($0C00 to $0DFF in Spindle v2) and may write a further page and
+four zero-page bytes while loading, so a part's memory plan starts by
+subtracting those.
+
+**Music across the boundary.** One player is active at a time, and each part's
+handler carries a three-byte placeholder the linker turns into the call to the
+installed player (Åkesson). The handler has to be entered every frame through
+preparation, fade out and clean up, or the tune skips; see
+`music_continuity_across_parts` below.
+
+**What breaks when it is skipped.** A part that trusts $D018 from its
+standalone build shows the wrong charset for a frame after a part that moved
+it. A part that leaves $D015 set hands the next part its sprites. A part that
+disables interrupts and never re-enables them before the switch kills the
+music at the join. A part that uses $0E00 while the next one loads is
+overwritten from under itself.
+
+**Variations.** A megademo (see `pacing_and_length`) resets between parts, so
+the contract shrinks to leaving the disk readable. A one-file intro has no
+contract, and the six stages are still the order to write it in.
+
+Related: `../techniques/loaders-packers.md` (`multi_load_sequencing`),
+`../techniques/raster.md` (`irq_chain_table`),
+`../techniques/memory-banking.md` (`memory_layout_plan`).
+
+---
+
+## transition_conditions — Three ways a part ends
+
+**Kind:** behaviour
+**Applies to:** demo_intro, dentro, party_intro_4k
+**Realised by:** screen_wipe, colour_fade, colour_cycling, keyboard_matrix_scan, sid_play_routine_pattern, screen-wipe, colour-fade, colour-cycling
+**Sources:** Linus Åkesson, Spindle v2 documentation; Dane, interviewed by Magic in Vandalism News 65
+
+**Checks:**
+- A part whose end condition is the space bar advances on that key and on no other.
+- A part whose end condition is drop-through advances only after the next part's scheduled load has completed.
+- A part whose end condition is an address reaching a value advances on the frame the player writes that value, and does not advance if the tune is stopped.
+- The fade-out stage reports done before the clean-up stage runs.
+- No frame between two parts shows the first part's screen with the second part's colours.
+
+**Why.** A part has to know when it is over. Åkesson's script format has three
+answers. **The shape:** each part carries one condition.
+
+```
+condition          meaning                                  used for
+key (space)        wait for the viewer                      early builds; megademo parts
+drop-through       end as soon as the next part is loaded   parts that exist to cover a load
+address = value    wait until RAM holds a value             music sync: the player's song position
+```
+
+The third is how a demo runs to its soundtrack. Åkesson's example reads the
+player's song position from a zero-page byte, so a part ends on a pattern
+boundary rather than a frame count. The condition is met, the fade-out stage
+runs until it reports done, then the switch happens; a part that fades over
+two seconds has to be told to end two seconds early.
+
+**The judgement.** Dane, on the soundtrack of Edge of Disgrace, describes the
+job as solving the memory and raster-time limits without letting the viewer
+see where either ran out. Applied to a join, that is the test: a transition
+reads as forced when the viewer can see the limit that caused it. A cut to
+black because two parts collide in memory, a pause because the disk had not
+finished, a fade keyed to a raster count instead of the tune. The fix is not a
+faster effect over the seam; it is moving the condition so the seam falls
+where the music already has one.
+
+**What breaks when it is skipped.** A part timed by a frame counter drifts
+against the tune by one frame per missed play call. A part ended by the loader
+alone ends at a different moment on a 1541, on an SD2IEC and in VICE. A part
+that waits for space in the final build stops the demo on the big screen.
+
+**Variations.** A demo mixes the three: space everywhere during development
+(Åkesson's advice), address-equals-value once the tune is in, drop-through for
+filler parts. A 4K intro with no loader has the first and third.
+
+Related: `../techniques/transitions.md`,
+`./demo-design-philosophy.md` section 5 (transitions as an aesthetic
+site), `music_continuity_across_parts` below.
+
+---
+
+## pacing_and_length — How long anything may run
+
+**Kind:** composition
+**Applies to:** demo_intro, dentro, party_intro_4k
+**Realised by:** multi_load_sequencing, big_font_2x2, dycp_scroller, big-font-scroller, dycp-scroller, sine-scroller
+**Sources:** Raistlin, X 2023 Demo Compo: A Look Back (2023); Goto80, The First Megademos (2021); Cascade release notes (1998)
+
+**Checks:**
+- No single effect stays on screen for more than about twenty seconds without a visible change of state.
+- The part that runs across the disk flip loops until the flip is detected and shows a scroller.
+- Every part in the final build advances without a key press unless the design names it a megademo.
+- No effect in the final build runs below the frame rate its design states.
+- The final build's running time, measured start to end, is within ten percent of the figure in the part list.
+
+**Why.** The audience at a party sees the demo once, projected, in a row of
+other demos. Length and dwell are the two numbers they feel directly.
+
+**Two structural families.** Goto80's history of the megademo separates the
+forms. A megademo is a run of discrete parts; the viewer presses a key to
+reach the next, tolerates a break for a loader or a menu, and needs no common
+theme, so the next part can be anything. A trackmo drops the loading part and
+streams the next part from disk with no visible break, and then the name
+megademo stops fitting. The C64 megademos he lists all date from 1987; 6581
+Crew and Finland Cracking Service are among the six groups named. A megademo
+part is a complete short programme with its own ending; a trackmo part is a
+paragraph in a longer piece.
+
+**The numbers.** Raistlin's look back at X 2023 states the rules Genesis
+Project set for No Bounds: do not dwell on an effect for more than twenty
+seconds however long it took to write, and a total running time close to ten
+minutes. He gives the field's running times as Mojo and Wonderland XIV about
+sixteen and a half minutes, Multiverse about eighteen, Next Level about
+twenty-one, and calls fifteen minutes and more the new norm for the bigger
+demos. He takes the blame for his own demo running short and leaning on code
+while the others carried far more art and flipped sides quickly. The dwell
+rule held up; the ten-minute total did not. Both figures are his, from one
+competition.
+
+**The disk flip.** Raistlin describes No Bounds' turn-disk part as a greetings
+scroller long enough to cover the flip and then some, kept because it looked
+good. The scroller at the flip is the standard placement: a part that can run
+indefinitely while the viewer changes sides, and that has to be there anyway
+(the boast tradition, `./demo-design-philosophy.md` section 5).
+
+**What reads as unfinished.** Raistlin's note on another entry's fight
+sequence is that it wanted more animation and a higher frame rate: the
+audience cannot see the code but can see a slideshow. Cascade's note on Trip
+to Nepa(l) (1998) says trouble linking the parts left the whole demo slow
+paced, the other visible form: parts each fine, a whole that drags.
+
+**What breaks when it is skipped.** Without a dwell rule the hardest effect
+stays up for a minute because it was hard, and the room's attention leaves
+after twenty seconds. Without a length figure against the part list the demo
+is short against the field or padded.
+
+**Variations.** A 4K intro keeps the dwell rule and runs the length of its
+tune. A single-file demo has no flip and puts the scroller at the end.
+
+Related: `./demo-design-philosophy.md` sections 2 and 5,
+`transition_conditions` above, `composition_workflow` below.
+
+---
+
+## music_continuity_across_parts — One play call per frame, always
+
+**Kind:** behaviour
+**Applies to:** demo_intro, dentro, party_intro_4k, cracktro
+**Realised by:** sid_play_routine_pattern, irq_chain_table, stable_raster_irq, frame_sync_loop, pal_ntsc_detection, sid-music-player, irq-chain, pal-ntsc-detect
+**Sources:** Raistlin, Stopping Music Popping (2023); Linus Åkesson, Spindle v2 documentation; Dane, Vandalism News 65
+
+**Checks:**
+- Consecutive entries to the play routine are 19,656 cycles apart on PAL, within the tolerance the design states, on every frame of a run that crosses every part boundary.
+- Consecutive entries to the play routine are 17,095 cycles apart on NTSC under the same rule.
+- No frame between the first play call and the end of the demo has zero play calls or two.
+- The play call is the first thing the interrupt handler does, or it has an interrupt of its own.
+- When the play call moves to a different raster line between two parts, it moves by steps and not in one frame.
+
+**Why.** A SID tune is a sequence of register writes that assume one call per
+frame. Raistlin's article names the moments a demo breaks that assumption:
+initialising a new part, the transition into it, and the final switch when the
+IRQ vector changes. Each can drop a call or make two, and the result is an
+audible pop or a lurch in the tempo.
+
+**The figure.** A PAL frame is 312 raster lines of 63 cycles: 312 × 63 =
+19,656 cycles. An NTSC frame on the 6567R8 is 263 lines of 65 cycles: 263 × 65
+= 17,095 cycles. Both are arithmetic from the line counts on
+`../hardware/pal-ntsc-reference.md`; the PAL sum is also the figure Raistlin
+states, and that page measured it in VICE x64sc with a CIA timer latch. The
+NTSC figure stands on arithmetic and that page's table.
+
+**The shape.** The play call sits at a fixed point in the frame. Raistlin's
+two fixes are ordering and sliding. Ordering: make the play call the first
+thing the handler does, or give it its own interrupt, so variable-time code
+cannot move it. Sliding: when the new part wants its call on a different
+raster line, move it over several frames; his example walks the call from line
+255 to line 50 in steps of about twenty lines over eleven frames. He allows
+about five to ten percent variance during a transition and expects the exact
+figure in steady state.
+
+Dane's remark on Edge of Disgrace is the design-side half: the music is
+written to each part's memory and raster budget, and a continuous soundtrack
+is hard for that reason. The composer knows which parts have raster time for a
+heavy player and which do not, and the player's cost is a line in the part's
+budget from the start, not a surprise at linking.
+
+**Detection.** Raistlin traces execution of the play routine's address in the
+VICE monitor, logs each hit with its clock to a file, and differences
+consecutive clocks; any gap that is not the figure is a fault. The same
+monitor commands (`trace`, `logname`, `log on`) are documented for another
+purpose on `../runtime/vice-reference.md`; a trace of a play routine across a
+part boundary is not measured here. A trace on stores to $D400 to $D418 asks
+the same question from the register side.
+
+**What breaks when it is skipped.** One dropped call is a click. A doubled
+call is a note that lands early. A call that moves from line 255 to line 50 in
+one frame gives one short gap of 312 − 255 + 50 = 107 lines, 107 × 63 = 6,741
+cycles, about a third of a frame (Raistlin calls it about half), and the tempo
+stumbles once. In a trace, a missed call shows as a gap near 39,312 cycles and
+a doubled call as one near zero. On NTSC a tune written for PAL runs faster by
+19,656 ÷ 17,095, which is a separate fault with a separate page
+(`../pitfalls/region-timing.md`).
+
+**Variations.** A demo that changes tune between parts has the same problem at
+the join: the old player's last call and the new one's first want the same
+spacing. A cracktro with one part has only the initialisation case.
+
+Related: `../techniques/music-sid.md` (`sid_play_routine_pattern`),
+`../pitfalls/region-timing.md`, `../hardware/pal-ntsc-reference.md`,
+`part_lifecycle` above.
+
+---
+
+## composition_workflow — The order the work goes in
+
+**Kind:** production
+**Applies to:** demo_intro, dentro, party_intro_4k
+**Realised by:** multi_load_sequencing, memory_layout_plan, exomizer_basics, memory-layout
+**Sources:** Dane, Vandalism News 65; Linus Åkesson, Spindle v2 documentation; psenough, Teach Yourself Demoscene in 14 Days; Phoenix, NVScene 2014 report in Hugi 38 (2014)
+
+**Checks:**
+- The first linked build runs every part in order with a key press between them and no transitions.
+- The second linked build runs to the tune with every part ended by a song position.
+- Transitions are added only after a build exists that runs end to end on the tune.
+
+**Why.** The whole is assembled last and under a fixed deadline. The order in
+which the pieces are made decides how much of the deadline goes to polish and
+how much to firefighting.
+
+**The shape, from two shipped accounts.** Dane, on Booze Design's process: for
+Uncensored the theme was decided at a gathering in the summer of 2014 and the
+linking order came naturally from it; nothing is decided early. For Edge of
+Disgrace, HCL stacked up previews of effects, the group worked toward
+coherency, and when HCL stopped making effects they linked the demo in
+chronological order over about six months, HCL linking one more effect or
+transition and Dane adjusting or composing to it; the soundtrack changed
+almost daily. Most of the work on Uncensored was done in the three months, and
+the forty-eight hours, before the deadline. Read as an order: theme, then
+linking order, then effects fitted to both, with the last quarter of the
+calendar carrying most of the load.
+
+Åkesson, from the tool side, gives four steps. Put the parts in a script in
+order of increasing interest with every transition set to the space bar. Add
+the tune and switch every transition to a song position so the music drives
+the demo; this is the rough cut. Build the transitions, biggest first, such as
+an intermediate part that brings in a background picture ahead of the effect
+that uses it. Then polish the switchovers that glitch, with clean-up routines
+that stop interrupts and wait for a chosen raster line. Åkesson's reason for
+leaving transitions until the order is fixed is that once it is, inherit tags
+and transitions can rely on it. Two practices sit alongside the steps and have
+no observable on the binary: write the part order, the total time and the
+owner of each join down before the last quarter of the calendar, and show each
+art-heavy part to someone other than its coder before the deadline.
+
+**Who owns what.** psenough's guide puts the demo's overall design, from
+concept through the arrangement of scenes to the joins, with the graphician
+more often than not: the coder produces effects, the composer a tune to each
+part's budget, and someone holds the order and the joins. The guide also
+advises a schedule buffer of twenty to fifty percent over the honest estimate,
+and starting small.
+
+**Paintovers.** Phoenix's report on NVScene 2014 records Pixtur introducing
+paintovers to get feedback on colour and tone before a release. The method, as
+the name says, is to let others paint over a work-in-progress frame; that
+description is this page's, not the report's. On a sixteen-colour machine this
+is cheap and the alternative is finding out at the projector.
+
+**What breaks when it is skipped.** Transitions built before the order is
+fixed are rebuilt when it moves. A tune commissioned before the part budgets
+are known is too heavy for the part that needs raster time or too thin for the
+part that had it. A demo linked in the last week ships the pacing fault
+Cascade described. An unwritten part order means the group learns the running
+time at the party.
+
+**Variations.** A one-coder 4K intro collapses the roles into one person and
+keeps the four steps. A megademo skips the transition steps and spends them on
+each part's own ending.
+
+Related: `./demo-design-philosophy.md` section 4 (the release lifecycle,
+which this pattern refines), `pacing_and_length` above,
+`../techniques/loaders-packers.md`.

package/docs/demo-design/demo-design-philosophy.md

@@ -0,0 +1,320 @@
+<!-- doc-type: reference -->
+
+# Demo Design Philosophy
+
+This document covers the aesthetic, cultural, and structural conventions of the C64 demo scene.
+It is the *why* behind technique choices — the social context that gives those techniques meaning.
+For the technical implementation of individual effects, see `../techniques/effects-vector-3d.md`,
+`../techniques/loaders-packers.md`, and the other files in `../techniques/`. For the cracktro
+subset and intro conventions, see `./intro-cracktro-patterns.md`.
+
+---
+
+## 1. The Demo as Performance
+
+A C64 demo is not a program that happens to run. It is a released artifact — something that exists
+publicly, has been voted on, has been reviewed, and carries its group's name into the permanent
+record. That distinction matters because it shapes every creative and technical decision a demo
+coder makes.
+
+The primary venue for a demo is a party. Demoparties assemble sceners in one place — historically
+in Scandinavia but now distributed globally — project demos on a large screen in front of an
+audience, and run a live vote. The vote result is published immediately. A production that places
+first in a 64K intro compo at a well-regarded party earns a kind of public certificate that "this
+is good by peer consensus." That certificate is permanent: it lives in the CSDb record.
+
+**CSDb (csdb.dk)** is the modern release archive and community review board for C64 scene
+productions. Every serious release is catalogued there with a release date, party affiliation,
+download links, and user ratings. CSDb ratings aggregate scene opinion over years, so a demo
+released in 2008 still accretes votes in 2024 as new people discover it. This long tail of
+evaluation makes the scene's collective aesthetic judgment unusually robust compared to ephemeral
+web hype.
+
+**Compo demo vs uploaded release:** A compo demo is submitted to a party competition, shown live,
+and voted on in real time. An uploaded release is self-published to CSDb (or formerly to ftp
+sites) without competitive context. Compo demos carry more prestige because the deadline is hard,
+the audience is expert, and the vote is honest. Uploaded releases still matter — many important
+productions circulate that way — but the community understands the difference. A release that
+"was never in a compo" is not lesser by definition, but it lacks the proof-of-pressure that compo
+placement provides.
+
+The phrase "released" in scene culture means more than "exists." It means: polished to the point
+where the group was willing to put their name on it in public, under deadline, in front of peers.
+An internal build that leaks is not released. A demo shown at a party but never uploaded is
+technically released but imperfectly archived. The full release cycle closes when a clean binary
+appears on CSDb with accurate credits.
+
+---
+
+## 2. Compo Categories and Constraints
+
+Parties divide productions into categories with strict size or content rules. The C64 scene has
+developed its own conventions for each category.
+
+### 256-Byte Intro
+
+The entire binary — code and data — must fit in 256 bytes. This is a severe constraint on a
+machine where a single sprite definition occupies 63 bytes. The art form is almost entirely about
+what you can procedurally generate: mathematical patterns, Lissajous curves, sine-wave effects,
+simple rasterized geometry. Assembly is mandatory; no compiler overhead survives at this scale.
+
+The technical-versus-art balance tilts almost entirely to technical: the aesthetic is the
+algorithm itself. A 256-byte entry that produces something visually unexpected wins because the
+audience understands how little room existed. Scroller text is usually absent or reduced to a
+single static message printed at cost. Tune is either borrowed from ROM or generated by a minimal
+wavetable that fits in the remaining bytes.
+
+### 1K Intro
+
+At 1024 bytes, 1K intros can contain a short SID tune and one or two distinct visual effects.
+The design challenge is sequencing: the demo needs to feel like it goes somewhere — intro,
+effect, outro — within extreme constraint. Crunching (compression with a decompressor header)
+is standard but the decompressor itself costs bytes, so packing efficiency is critical.
+
+The aesthetic expectation shifts slightly toward polish. A 1K intro that shows a clean plasma
+effect with a synchronized tune beat is judged differently than one that shows the same plasma
+untimed. The beat synchronization requires reserving bytes for a timing table or computing beat
+from the SID frame counter — small costs that pay outsized aesthetic dividends.
+
+### 4K Intro
+
+Four kilobytes allows a short but coherent demo. Typical content: a one-minute SID tune, two to
+four effects in sequence, group logo or rasterized scroller, and at least one transition. The
+4K category is highly competitive because it is achievable by a small team — a coder and a
+musician — without the production overhead of a full demo.
+
+Groups like Genesis Project have produced landmark 4K work that demonstrates the category's
+ceiling: procedural geometry, smooth palette cycling, and tight tune synchronization within a
+tiny binary. The 4K format rewards coders who have deeply internalized the hardware: every byte
+saved is a byte available for one more effect frame or one more palette entry.
+
+### 64K Intro ("Mini-Demo")
+
+At 64 kilobytes, the intro is large enough to contain multiple SID tunes, complex loading
+sequences (if the 64K includes a loader), and richer visual sequences. Some parties call this
+a "mini-demo" to distinguish it from the uncapped full-demo category. The boundary is cultural
+more than technical — a 64K intro might run longer than a conventional demo from 1988.
+
+The production challenge at 64K is organizational: the team needs a coder, musician, graphician,
+and sometimes a separate "design lead" to make sure the parts hang together aesthetically. Size
+management is still real — 64K is not infinite — but asset quality is the dominant constraint.
+A 64K intro with mediocre SID work will lose to one with an outstanding tune even if the visuals
+are comparable.
+
+### Demo (Full, No Strict Size Cap)
+
+The full demo category has no mandated size ceiling, though practical limits apply: a disk-based
+C64 demo must fit on one or two sides of a 1541 disk (approximately 165K or 330K usable). Most
+full demos run four to eight minutes, contain three to six distinct parts separated by loaders,
+and feature coordinated work from a coder, musician, and graphician.
+
+Full demos are where the scene's most ambitious aesthetic experiments appear. Multi-part
+construction with per-part loaders (see `../techniques/loaders-packers.md`) allows each part to
+own the full 64K address space. A group can write one part in Oscar64 targeting a plasma effect
+and another part in hand-tuned assembly targeting a sprite-multiplexed 3D rotation, with the
+loader transition between them handling decompression and relocation. The full demo format is
+the main competitive prize at major parties.
+
+### Wild Compo
+
+Wild compo accepts anything the party organizers will permit: hardware expansions, mixed-media
+productions, demos running from unusual storage, real-time performances with external peripherals.
+C64 entries in wild categories have included productions that modify the hardware in real time,
+demos that display output on oscilloscopes driven by the SID, and entries that use the cassette
+port in unintended ways. Wild compos reward lateral thinking over optimization; the judging
+criterion is audience reaction.
+
+---
+
+## 3. Scene Tiers
+
+The C64 scene is not a single aesthetic community. It contains at least three recognizable
+sensibilities that have evolved over four decades.
+
+### Newschool
+
+The newschool aesthetic emerged from the competitive intro categories in the 2000s and 2010s.
+It prioritizes mathematical rigor and visual density: procedural geometry, voxel-style terrain,
+mode 7 perspective, 3D vector objects (see `../techniques/effects-vector-3d.md`), and tunnel
+effects running at maximum frame rate. The visual language often echoes demoscene productions
+on platforms with more CPU headroom — treating the C64 constraint as proof of craft rather than
+as a source of aesthetic vocabulary.
+
+Newschool productions in the 256-byte and 4K categories frequently achieve things that appear
+impossible on a 1 MHz 6510, which is precisely the point. The audience reaction is calibrated
+to technical astonishment. Tune choices tend toward chip-music styles that complement the
+geometric visuals rather than emulating older SID styles.
+
+### Oldschool
+
+The oldschool aesthetic draws on the visual vocabulary of C64 demos from roughly 1986 to 1992:
+raster bars, hardware sprite multiplexing, FLD-style scrollers, charset animation, and SID
+tunes in the three-voice synth tradition. Oldschool is not nostalgia by default — it is a
+deliberate aesthetic position that treats the platform's native visual grammar as valid art.
+
+The most celebrated modern oldschool productions include **Edge of Disgrace** by Booze Design
+(released 2008, widely regarded as one of the finest C64 full demos) and **Comaland** by Censor
+Design (released 2014, similarly acclaimed). Both productions are extensively documented on CSDb
+and have been analyzed in technical write-ups by their authors. They demonstrate that the
+oldschool format supports creative ambition at the same level as any contemporary platform.
+Groups like Triad, Resource, and Fairlight have maintained continuous oldschool output across
+decades, and their aesthetic consistency is part of what makes their releases identifiable.
+
+### Wild
+
+The wild tier is not a competitive category but a mode of production. Wild-tier thinking asks:
+what can the hardware do if we ignore the expected use? Demos that drive external hardware,
+that treat audio output as primary and visual output as secondary, that run from storage media
+the machine was not designed for — these are wild in sensibility regardless of which compo they
+enter. Some groups produce both competitive oldschool demos and wild-tier experiments in the same
+year.
+
+---
+
+## 4. The Released-Demo Lifecycle
+
+Understanding how demos get made illuminates why they look the way they do.
+
+**Concept.** A demo begins as an idea for a sequence or a theme — often loose. "We want a
+tunnel leading into a 3D rotation with a SID tune that builds from ambient to loud." The concept
+rarely survives first contact with hardware constraints unchanged, but having a concept before
+writing code is the mark of a production-mode group rather than a tech-demo group.
+
+**Tune commissioned.** For groups that collaborate across physical locations, the musician
+typically works first. A SID tune has a fixed length and structure — the musician delivers a
+file, usually a .sid or a raw binary, and the coder builds timing tables around it. Commissioning
+the tune before or during early effect prototyping means the visual sequence can be choreographed
+to the music's actual beat grid rather than retrofitted later.
+
+**Effect prototyping.** Individual effects are developed independently, often by separate coders.
+An effect prototype in Oscar64 or KickAssembler runs as a standalone binary — it is not
+integrated into the demo shell yet. This is the longest phase and the one most subject to scope
+creep. A plasma effect that runs at 25 FPS on PAL gets profiled and optimized; if it cannot hit
+the target, the design adapts.
+
+**Asset production.** Graphicians produce sprites, charset tiles, Koala-format bitmap screens,
+and logo art in parallel with effect prototyping. C64 graphic formats are extremely constrained
+(see the file formats reference), so graphicians working at production quality understand the
+hardware palette, multicolor restrictions, and sprite overlay techniques. A graphician who does
+not know that FLI (Flexible Line Interpretation) requires cycle-exact timing is a liability in
+a competitive demo.
+
+**Integration.** The demo shell is assembled: loader, parts, inter-part transitions, tune player,
+memory banking. This phase often reveals conflicts — two effects that independently work cleanly
+cannot both live in the same part because they need overlapping zero-page addresses or conflict
+on a CIA timer. Integration is where `c64_check_compatibility` queries (in the KB) find their
+real-world equivalent: the coder manually auditing what each part uses and resolving collisions.
+
+**Final-party-pressure crunch.** Most demos are still not feature-complete two weeks before the
+party. The deadline is fixed and public — the party will happen whether or not the demo is ready.
+This creates a forcing function that compels decisions: cut the fourth part, fix the scroller
+text typo, accept the one scanline flicker in the transition, release. The crunch is not
+dysfunction; it is the design mechanism that prevents infinite scope creep. Productions that miss
+parties and get uploaded later often feel slightly overlong precisely because they lacked the
+forcing function.
+
+**Why "released" means polished.** The party vote is brutal. Audience members vote on what they
+see projected, in real time, having watched the preceding entries. A demo that crashes does not
+recover gracefully — the audience watches a frozen screen until the organizer resets the machine.
+A demo that runs to completion but has a visually weak ending loses to one that has a strong last
+thirty seconds. This pressure produces a very specific kind of polish: demos are end-to-end
+correct, not just technically impressive in isolation.
+
+---
+
+## 5. Aesthetic Tropes
+
+Certain conventions are so embedded in C64 demo culture that their presence or absence is itself
+a statement.
+
+**Amazing transitions.** The transition between parts or effects is a primary aesthetic site.
+Palette splits, screen-clearing raster sweeps, charset swap flickers, and DRAM-fade techniques
+all serve the same function: marking the boundary between visual ideas without cutting to black
+abruptly. A well-designed transition makes the demo feel like a continuous performance rather
+than a playlist. Groups that are known for their visual sophistication — Crest, Genesis Project,
+Onslaught — treat transitions as first-class effects requiring their own development time.
+
+**Tune sync.** An effect that responds visually to the music's beat grid reads as deliberately
+designed rather than accidentally happening at the same time as the music. Tune sync can be
+implemented via hardcoded timing tables derived from the musician's tempo, via CIA timer
+comparisons, or via live SID voice-amplitude sampling. The simplest version — synchronized raster
+bar expansion on the beat — is immediately legible to any scene audience. Complex tune sync, where
+multiple visual parameters modulate independently to different frequency bands, is a marker of
+production-quality ambition.
+
+**The boast tradition.** Demo culture derives in part from cracking culture, where inserting your
+group's name into a commercial release was the primary form of attribution. The demo form
+inherited the tradition: every demo carries a visible group signature, a scroller with greetings
+to allied groups, and a credits sequence. The greetings scroller is simultaneously social bonding
+(publicly acknowledging relationships within the scene) and territorial marking (your group name
+is on this production, permanently). Groups like F4CG, Hokuto Force, and Resource have
+maintained distinctive greeting styles across decades of releases.
+
+**Why scrollers exist.** The hardware scroller emerged from the CIA-timer-driven hardware scroll
+registers as a way to display more text than fit on screen without flicker. A smooth one-pixel-
+per-frame left-scroll of a character row is nearly free on the 6510 if implemented in hardware
+scroll mode (via VIC-II's fine scroll register, with software column shifting once per full
+character width). This made scrollers the natural medium for group messaging: unlimited text,
+smooth motion, zero per-character cost. What began as a technical affordance became a social
+institution. A demo without a scroller in the oldschool tradition reads as deliberately minimalist.
+The scroller's content — the actual text — is the demo group's primary direct communication with
+the viewer, often more personal and candid than any other medium available to the coders at the
+time.
+
+---
+
+## 6. Modern Revival
+
+The C64 demo scene did not end when the Amiga arrived or when the PC became dominant. It
+contracted, reorganized, and continued. From roughly 2005 onward, the scene entered a sustained
+revival driven by several forces: emulator accuracy (VICE reaching cycle-exact fidelity),
+hardware preservation (SD2IEC, Ultimate II+ making physical machines more accessible), and
+the emergence of younger sceners encountering the platform via its cultural legacy rather than
+childhood ownership.
+
+**Edge of Disgrace** (Booze Design, 2008) is the most frequently cited landmark of the modern
+revival. It demonstrated that a full oldschool-style C64 demo released in the 2000s could be
+not merely competent but genuinely surprising — technically and aesthetically. Its documentation
+at CSDb includes author notes that make it useful as a reference for production methodology, not
+just a thing to watch.
+
+**Comaland** (Censor Design, 2014) continued the revival's trajectory, demonstrating that the
+platform's ceiling had not been reached and that groups with deep institutional knowledge could
+continue pushing it. Both productions are well-documented at CSDb and have been discussed in
+technical detail by their authors, making them safe references.
+
+The post-2010 scene has also seen growth in the competitive intro categories. The 4K and 256-byte
+categories attract technically focused coders for whom the constraint itself is the creative
+medium. These productions often participate in cross-platform parties where C64 entries compete
+alongside Amiga, PC, and console productions in platform-specific categories. Cross-platform
+party exposure has drawn sceners from other platforms who then specialize in C64, refreshing the
+scene's technical approach.
+
+The question of "firsts" — first C64 demo to achieve X — is a live area of scene discourse.
+The C64 demo scene tracks technical firsts carefully, but attributing any specific first to a
+specific production without checking CSDb risks propagating error. Agents retrieving this chunk
+should use `c64_search` with specific technical terms and cross-reference against CSDb records
+rather than relying on any static claim here.
+
+---
+
+## 7. Cross-References
+
+- `./intro-cracktro-patterns.md` — The cracktro subset: intro conventions derived from cracking
+  culture, boast formatting, loader integration, and the specific aesthetic of the release-group
+  intro. This document is being written in parallel (Phase 6, Task 7).
+
+- `../techniques/effects-vector-3d.md` — Technical implementation of the effects that appear
+  in newschool and oldschool demos: plasma, tunnel, voxel, mode 7 perspective, 3D vector
+  rotation. The philosophy sections above describe why these effects are used and what audience
+  reaction they are calibrated for; this reference covers how they are implemented.
+
+- `../techniques/loaders-packers.md` — Multi-part demo workflow, Krill/Exomizer/Sparkle
+  loader integration, and the GCR-level disk tricks that enable fast loading. Full demos depend
+  on this infrastructure; the lifecycle section above describes how loaders fit into the
+  integration phase of production.
+
+- `./demo-composition.md`: the design patterns for a multi-part demo, one level below the
+  lifecycle in section 4: what a part hands to the next, the three ways a part ends, dwell and
+  length norms, keeping the music play call one frame apart across every join, and the order
+  the linking work goes in.