Docs / User Guide / Live Monitor

Live Monitor#

See what’s happening → understand it in plain language → inspect the technical evidence.

Open MONITOR in Controls while the C64 is on. The Monitor fills the browser window and follows your theme. Live shows the running machine. Component sections pause on a shared moment for inspection.

Start exploring#

1. Open Monitor. It always starts on Live, showing the machine's parts working together.
2. Choose a component card or section to capture and pause. Click the small C64 display to open Video.
3. Compare sections using the same moment. Choose the play icon to watch activity, or Back to C64 to resume normal playback.

Monitor records a complete detailed frame about once per second while the machine runs. Pause keeps the most recent completed recording for Code, Video and the captured evidence in Memory, Sound and Storage. Other sections hold that recording until another capture replaces it. Paused views reuse their snapshot, with a fresh read when input or configuration changes. Its picture can be older than the paused live display, and its recorded values are separate from the current live snapshot.

Opening Monitor while paused advances up to two PAL frames (about 40 ms of emulated time) to record one complete frame, then stays paused. Sections share that recording without advancing again. Closing releases it.

If you pause inside Monitor before its first recording finishes, resume briefly to record one. Replay never advances the machine. Resetting or restoring allows automatic recording to continue while it runs.

Choose a section#

Every section uses the same open workspace. Subtle surfaces group components, while simple dividers separate observations from their explanations and evidence.

On phones, scroll within a section to reach its details. Video stacks the picture above its inspector. Sound uses stacked voice cards, with SID 1 and SID 2 buttons to switch chips. Compact tablets also show one SID at a time.

Opening a component captures and pauses on one shared moment. Switching components keeps it. Use Resume to watch activity in a component. Returning to Live resumes a pause made by navigation, while an explicit manual pause stays held. The playback button shows Running or Paused. Closing Monitor resumes playback, including a pause you made manually.

Live: the living machine#

Every card places its component label and title at the top, with Inspect and About at the bottom. The visualization fills the right third.

Six softly outlined cards sit directly on the open workspace, with visualizations on their right. They connect current observations to a plain explanation. Click a card or its Inspect action to open the corresponding readings. Voice buttons and storage badges open their specific targets. Storage device badges fill two rows at the top of its visual area. About opens the hardware story without changing your current section or capturing a frame.

• One shared snapshot refreshes RAM, chip settings, controls and storage at the selected rate. Click the sampling button beside The living machine to cycle through 1 → 10 → 25 → 50 samples/s. The default is 10.
• Live descriptions summarize two-second observation windows. Histories retain every sample, while the main interface refreshes at most ten times per second. Code patterns count sampled instructions, not CPU time.
• Above 10 samples/s, Code keeps the PC without changing instruction labels, and Sound keeps simple voice labels above each channel graph. Pause restores the exact settings.
• Live trails retain up to eight seconds at every sampling rate. The Code trail plots sampled CPU positions from $0000 to $FFFF, oldest to newest. Clusters suggest repetition, not a proven loop or percentage of CPU time.
• IRQ request shows the sampled line. IRQ allowed means the CPU I flag is clear, not that an interrupt handler ran. Brief requests can occur between samples.
• The Code card shows the current PC separately from the sampled instruction address. PC can already point into an operand.
• Frame cycle budgets and detailed chip actions remain in Code and Video, tied to their captured frame.
• RAM counts show addresses whose values differ from the previous snapshot.
• Pitch settings are not audio-level meters. CPU positions are not CPU-usage measurements.
• Video fills its visual third with a proportioned screen diagram, eight sprite-enable slots, X/Y fine scroll and colour swatches. Textures illustrate character or bitmap mode, not actual program artwork.
• Sprite enable bits do not prove visible pixels. Border openings and bad-line activity belong to captured Video analysis.
• Solid lines show C64 connections. The dashed line shows external storage connections.
• The desktop overview fits one screen. Smaller windows can scroll the cards.

Inside the C64 collects the component guides in one place. Its chapters include history, connections, specification tables, things to try, primary references and links to this emulator's architecture documents. Close an About dialog with × or Escape to return to the same section.

The selected rate is saved in this browser and restored after reloads. If browser storage is unavailable, the rate lasts until the page is reloaded. Higher rates refresh the live observations more often. Detailed frame recording keeps its separate schedule, and Pause still holds the captured frame. The button sets a target rate, so a busy browser can deliver fewer samples. Monitor does not collect samples while closed or hidden. Detailed frame capture is heavier than a live snapshot and can cause a brief hitch on slower devices. Selecting a lower sample rate reduces snapshot work, but does not change the frame-recording interval.

The top-right C64 display remains live. Detailed Video and Code recordings keep their own frame identity and replay controls. They are separate from the shared state snapshot, which does not record everything that happened between samples.

A lit sprite-slot marker means enabled at some point in the latest captured frame, not necessarily moving or visible throughout it. Before a frame is available, the markers show the current sample's enable bits.

Controls: inputs and timing#

Open Controls in the header or Inspect Controls on Live.

These readings share the selected live sampling rate. Brief presses can fall between samples. Reading this page does not acknowledge interrupts or advance timers.

Memory: find out what the bytes do#

• Start with the pictures above the map: Screen cells, Character shapes or Bitmap pixels, and the eight sprite slots. Click one to find its source and decode it on the right.
• Screen cells opens a 40 × 25 grid of hexadecimal bytes. Click a cell or use arrow keys to see its address, value and character source or bitmap colour nibbles.
• Static picture optionally reconstructs the sampled settings. Raster changes can make it look scrambled. Follow the Video link to inspect the finished frame.
• Current pointers updates all eight sprite shapes on every shared sample, including disabled slots. A dashed outline and dim slot number mark disabled slots. A checkerboard makes transparent areas and black sprites easier to distinguish.
• Sprite previews default to Captured frame, showing what was visible in the shared recording. Click a captured sprite to show its recorded shape and line-end settings in the right pane. Click that preview or its link to inspect a visible pixel in Video. Choose Current pointers or Inspect current pointer bytes to inspect sampled data instead. Captured appearances update with the shared frame, not each live sample.
• Character patterns, bitmap bits and current-pointer previews decode VIC-visible memory, including character ROM. Bitmap previews show raw bits even in invalid graphics modes.
• Each square in the 64 KB RAM map represents 256 bytes. S, C, B and ● identify configured graphics regions. The selected source range is highlighted. Arrow keys move between pages.
• Bright fills show sampled RAM changes, separate from graphics-source markers.
• Unidentified pages explain what is known and suggest a graphics source to explore. They are not presented as pictures.
• Choose a manual interpretation in View, or open Hexadecimal bytes for technical inspection. Zero page, Stack and CPU location remain available.
• Switch from Live memory to Captured memory to inspect RAM at a recorded cycle. Follow its last recorded change, instruction origin and later graphics reads. Evidence lists have Previous and Next pages.

The map shows underlying RAM, including RAM beneath ROM and I/O. It does not show chip registers or colour RAM. Current-source links open VIC-visible bytes directly. Selecting a RAM page beneath ROM explains the distinction and offers a link to the VIC source. Map letters use the shared snapshot and describe its configuration. Video records actual matrix reads, without claiming that every read produced a visible pixel. Missing or partial read evidence is labelled explicitly. Graphics reconstructions omit raster changes, scrolling and compositing. Invalid graphics-mode combinations produce black only in the optional static picture. Byte maps and raw bitmap bits remain readable. Use Video's captured frame for changing settings and the final picture.

Code: understand the program's actions#

Code uses the shared recording, which refreshes while running and stays fixed while paused. Explain actions translates recorded VIC-II and SID writes and RAM changes into plain-language actions.

Cycles without a matching recorded action show an explicit empty state. This does not mean the CPU is idle. See in Video preserves the exact frame and cursor, including cycles without an action.

Available cycles do not mean useful work: wait loops count too. Dispatch intervals include stalls and interrupt entry. Writes do not describe every calculation or input operation.

Instruction links from captured evidence show recorded opcode and operand bytes. Missing bytes stay unknown. Following a target keeps the same recording in Memory. The ordinary assembly address field and Follow PC use current CPU-visible memory. Follow PC samples the current program counter, possibly partway through an instruction. Enter a known code address when you want decoding to start there.

Video: explore one captured frame#

Hover over the captured picture for an 8× pixel lens centred on your pointer. A single crosshair marks the centre pixel a click explains, including near the edges. The normal pointer is hidden inside the lens. The lens uses the recording and does not capture another frame. Move outside the picture to dismiss it.

Video keeps the picture, timeline and explanation together. It uses the shared recording, which refreshes automatically while the C64 runs. Pause to hold it.

Start with TL;DR#

Selecting Video always opens TL;DR. Direct evidence links still open the relevant detail. The buttons at the top switch between it and Frame story, with the selected view highlighted.

• TL;DR holds the shared frame and gives a short explanation with picture grabs.
• Three enlarged cards introduce different mechanisms below the smaller picture. More findings, above the cards, cycles through additional evidence without adding a longer page.
• Click a picture grab or See the evidence below it to open its explanation, then follow it into the frame story or pixel inspector. Headings remain plain text.
• The text comes from recorded facts and fixed rules, with no AI or demo recognition.
• Resume returns to Frame story, where recordings can refresh again.

Control changes describe what was written, not proof that a particular shape moved or changed colour. Missing or conflicting pixel evidence stays unresolved.

Follow the frame story#

Start with the numbered stops below the picture. Scroll the strip or use Previous change / Next change to follow the whole recording, including later setting changes, sprite sources and the bottom border. Writes on the same raster line share a stop, and consecutive lines with the same setting sequence form a range. Each recorded write remains available. This frame groups observations by topic.

• Select a stop to pause the C64 and hold the shared recording.
• Selected change connects recorded evidence, VIC rules and a strip of the picture.
• For changed settings, compare the before/written values and choose another occurrence.
• Follow the recorded instruction into Code, a source into Memory, or the relevant rules.
• The border story separates top, bottom, left and right, with uncovered positions and recorded sprite output. Select an edge to explain a pixel there.
• Previous change / Next change move between observations. The slider still selects any cycle.
• Play replay advances the selected story stop as it passes each change. Next change continues from that point.

The story is computed from this recording, with no program recognition or AI. A write alone does not prove a visible change. Picture strips show final output, not simulated before/after images. Missing evidence stays unresolved.

Click the picture#

• Click a pixel to open Why this pixel? in the right-hand inspector.
• Focus the picture and use arrow keys, then Enter, for keyboard inspection.
• Choose Sprite appearances in the inspector to highlight any of the eight slots.
• Expand Technical evidence inline for the recorded bytes and source limits.
• Follow Inspect captured source in Memory to keep the frame, cycle and address.

The pixel explanation enlarges the selected picture area, highlights the source bit or pair and shows which colour source it selects. Multicolour pairs paint two neighbouring pixels. Recorded output-stage controls follow colour changes within the line. Missing or conflicting source evidence stays unresolved.

Control the recording#

Selecting a topic, sprite, pixel or cycle keeps that selection when the next recording arrives. It does not pause the C64. Use Pause or Play replay or select a frame-story stop to hold one frame. Leaving sprite details clears its selection and outline.

Choose what to inspect#

The five timing rows have their labels on the left. Click a row label to open its explanation, or click the timing chart to inspect a cycle. Rules and picture use this same cursor, with no separate playback toolbar. Expanding a rule does not change the selected cycle.

Try it with Nine#

Open Monitor during the effect you want to understand. Linus Åkesson’s Nine explanation describes how timed colours, idle graphics and sprite layers work together. Compare those mechanisms with the current recording:

Different parts of Nine produce different findings. The analyzer does not infer nine objects, author intent, multiplexing or a crunch trigger from appearance alone.

Find a timing rule#

In Timing & rules, search by name, rule ID or Bauer section. Filter the catalogue to checked rules, mismatches or missing evidence in this frame. Expected half-cycles explains the PAL bus schedule, beam X comparisons and logical display state from captured controls. These are reference predictions, kept separate from measured matches.

Each expanded rule shows its required inputs and frame totals. Transition rules also show the recorded values at the selected cycle. Use Show next mismatch to jump directly to the failing evidence.

Help and evidence limits#

How to use Video and Evidence & limits open small dialogs. Close with × or Escape to return to the workspace. Use Memory for current screen, character and sprite sources. Video's inspector stays tied to the captured frame.

Click graphics before and after a raster effect to compare their recorded sources. An empty graphics shifter is explained separately from a fetched byte. These explanations use the captured frame, never current RAM as a replacement.

Sprite coverage can include pixels hidden behind foreground graphics. Related writes and line-end samples do not prove which write caused every visible effect. The timing chart covers all 312 PAL lines, including margins outside the picture.

Ghost bytes#

When the graphics sequencer is idle, it can repeat one byte instead of fetching normal character or bitmap data. Video checks the recorded bank, ECM setting, sequencer state and bus reads. The source is bank + $3FFF, or bank + $39FF with ECM.

• Observed confirms matching idle graphics reads.
• Candidate means nonzero text-mode data coincides with open border gates.
• Neither label proves which final pixels appeared or the programmer's intent.
• Ordinary discarded idle bus reads are excluded. Missing or conflicting evidence is identified explicitly.

Sound: inspect the SID voices#

Sound supports one or two SID chips, with each chip's model and address shown. On desktop, all voices are visible and SID 1 keeps the same width with one or two chips. When SID 2 is off, faded cards preview its three extra voices and filter. Recent activity also keeps a faded SID 2 column, with empty plots until enabled. Enable it with SID2 in Options → Sound. Each voice explains its settings beside its readings. Numeric text refreshes more slowly than the meters, so it stays readable. Pause for exact held settings. Follow each voice through its envelope, filter or bypass path, and output.

These are settings and shadow readbacks, not measured audio levels. Envelope shapes are illustrations, not timed audio traces. Gate off can still sound during release, while gate on does not prove an audible output. Captured writes show how settings change, without reconstructing the sound waveform. Moving the captured slider pauses updates and holds that recording. Frame start shows the initial settings. Highlighted voices received a write at the selected moment. Upper traces show pitch settings, lower bars show gate on. Incomplete recordings show the available writes without inventing later voice settings. Recent history starts when Monitor opens. Reset, restore, SID routing changes or leaving Monitor start a fresh history. A full buffer is labelled explicitly.

Storage: follow the connected devices#

Storage opens on an active device, or an attached device when idle. Your selection then stays fixed while you inspect it. The rate readout shows kB/s, with separate read and write values. The Live card shows the same rate below its device buttons. One kB means 1,000 bytes. Rates use up to one second of wall time and fall to zero when traffic stops, including while paused.

These streams measure different work. Disk and tape rates are not decoded program-loading speeds. Counters run only while the Monitor is open and visible.

The observation strip retains up to eight seconds at every sampling rate and shows its actual observed span. Drive activity does not prove a particular file was loaded. Tape position is not program-loading progress. Cartridge mapping is not a count of ROM reads, and a REU read alone does not prove a completed copy.

Completed LOAD links open current memory, which may have changed since loading. I/O and special mappings are labelled separately from confirmed RAM writes. Hardware loader traffic does not establish a RAM destination by itself.

Shared snapshots and recorded frames#

Recording has a temporary host CPU cost. Evidence labels and explanations do not change emulated timing or how the C64 picture is generated. Missing or conflicting evidence is reported rather than guessed.