Bitmap, stipple, and raster paint editors on CADR and Genera

What the two source generations represent

The later PAINT 7 and older NPAINT 10 expose essentially the same visible program, but they represent their raster regions differently.

NPAINT 10 defines a PAINT-AREA-CLASS whose instances know a source array, origin, dimensions, and optional buffer array. Brush and paint selection copy the chosen patch into a buffer, and BITBLT composes those buffered bits into the screen. The maintained LM-3 file changes old quoted message selectors to the newer form and adds a mode line, but an exact diff shows no redesign of the UI.

PAINT 7 replaces that object protocol with compact structures and specialized halfword operations over the screen buffer. Its PAINT-AREA carries both one-bit and 32-bit views of the same storage, and its inner brush routine aligns pattern words and combines them directly. This is an optimization and data-model rewrite, not evidence for a different visible application.

The later file also declares PAINT-LINE-ITEM, PAINT-PATH, and PAINT-TEXT structures. The active UI does not build a retained object scene from them. Painting and shape commits alter the framebuffer immediately; these declarations should not be misread as an Illustrator-like document model.

DRAW 21 supplies the vector and circle rasterizers used by PAINT. It offers both ordinary and raster-coordinate entry points. The raster variants use the screen convention of an upper-left origin and increasing Y downward, and accept logical raster operations such as IOR, AND-complement, and XOR.

Startup and visible layout

The entry point is PAINT, with an optional input routine and a flag controlling initialization. The default input routine is the mouse. With initialization enabled, PAINT clears the screen and reconstructs the pattern and brush palette.

The program expects the old display representation for which its screen and halfword-array operations were written. The later source explicitly switches to the CPT screen when the current screen has an incompatible plane mask and notes that this version is intended for 32-bit television storage. This is one reason that source presence alone does not establish portability to the maintained System 303 window environment.

The screen is divided functionally rather than into independent windows:

• a strip near the top holds nine paint-pattern swatches followed by eight brush swatches;
• the main framebuffer is the drawing surface, including the regions occupied by the palette and menu;
• the lower-left portion is temporarily made the console stream for prompts;
• a 120-by-12-pixel label at the upper right shows the current mode; and
• the menu is drawn directly into the screen rather than hosted in a separate window pane.

Because the UI is part of the same raster, Restore Pallet (the spelling in the source) is a functional repair command. It redraws palette bits that painting or other screen activity has damaged. It also reruns palette initialization, so it resets the primary paint, alternate paint, and brush to their source defaults.

Mouse-switch protocol

The source names the physical controls top, middle, and bottom; this page retains those names rather than guessing how a particular host mouse maps them.

After entering Select Brush, Select Paint, or Select Alternate Paint, the operator points at the desired swatch and presses a drawing switch. The three handlers do not distinguish middle from bottom, so either dispatches the same selection and returns to Normal mode. Top over the palette remains the direct primary-paint/brush shortcut described above.

The brush cursor is clamped so that half its width and height remain within the screen. It blinks by XOR when idle. PAINT slows the blink while painting, and some modes suppress it because cursor XOR would interfere with rapid drawing.

Complete menu surface

The literal four menus are:

The four unimplemented Area labels are not merely absent from a manual: they are inserted into the live source-defined menu without corresponding dispatch definitions. They are best catalogued as stale or unfinished cells. Whether the old menu package ignored them cleanly or signaled an error is a runtime TODO.

Complete mode behavior

The XOR-mode bottom-switch behavior is easy to miss in a feature summary. XOR does not globally transform both drawing buttons into toggles; it changes only the primary/middle path.

Keyboard input

PAINT does not have a command-key table comparable to Zwei. Its keyboard path is small and modal:

Ordinary typed characters matter visibly only in Text mode. The source interns the whole pending string when the bottom switch is used to choose a font; it accepts the choice only when the resulting symbol is bound to an array. This is a powerful but unsafe historical interface: it selects a live Lisp array by symbol name rather than choosing from a validated font menu.

Text is not retained as editable text. Its XOR preview is committed directly to the screen raster. PAINT does not remember a string, font, or position object that can later be selected and changed.

Pattern and brush palette

The source contains nine paint seeds, each four rows high, and eight brush seeds, each sixteen rows high. Initialization expands them into live UI rasters:

• each paint swatch occupies 40 by 40 pixels; the four-row seed repeats vertically and its short bit sequence repeats horizontally with phase alignment;
• each brush swatch occupies 20 by 20 pixels; its sixteen source rows are shifted into the displayed mask and the remaining area is padding; and
• paint swatches begin 42 pixels apart, while brushes begin 24 pixels apart.

This corrects two tempting but wrong readings of the source constants: the paint swatches are not 32 by 32, and the brush swatches are not merely the 16-by-16 seed arrays. The user selects the expanded screen regions.

The initial alternate paint is the first, all-zero pattern. The initial primary paint is the fifth pattern in source order, and the initial brush is the fourth mask. Visual names such as “spray”, “brick”, or “circle” are not assigned here: the source provides bit rows but no authoritative semantic names, and a runtime palette has not yet been reached.

The older NPAINT buffers a selected pattern or brush, insulating its active semantics from later damage to the visible swatch. The optimized PAINT source instead reads from the live screen location during its halfword composition. That architectural difference makes Restore Pallet especially consequential, but a complete behavioral comparison after overwriting a selected PAINT-7 swatch remains a runtime TODO.

Save and restore are volatile screen snapshots

Save Screen allocates an ART-16B array if necessary and copies the complete framebuffer halfword array into it. Restore Screen copies that array back; if no saved array is bound, it does nothing.

There is no pathname, image header, archive member, or file-format selector in this workflow. The saved object is a Lisp-memory copy of the whole screen, including the editor UI, not a durable painting document. It is closer to a single volatile framebuffer checkpoint than to either an image archive or a VM snapshot: it contains screen words only, not the Lisp process, menus, globals, or machine state needed to resume PAINT.

The loader reinforces this narrow boundary. LOAD.PAINT loads compiled Mouse, Menu, and Paint components; it does not install an image codec or persistent painting format.

Maintained LM-3 status and fresh runtime probe

The LM-3 Fossil tree retains NPAINT as l/sys/demo/npaint.lisp, with the draw primitives in l/sys/io1/draw.lisp. The active HACKS system lists ABACUS, ALARM, BEEPS, CROCK, DOCTOR, MUNCH, QIX, and other demos, but not NPAINT. The file is therefore retained source, not a declared default HACKS component.

A fresh isolated System 303-0 run on 18 July 2026 established:

1. (FBOUNDP 'PAINT) returned NIL in the booted load band.
2. Loading SYS: DEMO; NPAINT requested a login to the configured AMS-BRIDGE-1 file host and failed because that host was unavailable.
3. A bounded attempt to use the harness's local bridge reached its special lispm login, but host-keyboard pathname punctuation was translated into an incorrect guest pathname before source evaluation.
4. The session was stopped cleanly without modifying its private disk or source copies.

This run proves only that PAINT is not preloaded and that the retained source is not presently loadable through the default preserved file-service path. It does not prove that NPAINT is incompatible with System 303. No PAINT UI appeared, so the run supplies no confirmation for menu rendering, palette appearance, or the four stale Area cells.

The ignored capture 0004-fboundp-paint.png has PNG SHA-256 a170e293a11855520e7c92c2163b09333a533310aecc6d614187744a003f2552 and pixel SHA-256 58033154753f9e1c4f572c6077f6708e1028ec2bcb11ced70e288bb0c9c6a190. It was not curated into the museum: a screenshot of a false FBOUNDP result does not materially illustrate PAINT's visible behavior. Publication should wait for a successfully reached application state and the per-image review in the screenshot rights policy.

Raster-plane data model

A raster plane records:

• an optional underlying raster array;
• an external X and Y origin;
• logical width and height;
• array element type; and
• a default element, zero for integer element types.

The external coordinate space is unbounded in principle. Reading outside the allocated logical rectangle returns the default. The first write lazily creates at least a 32-by-32 backing raster. A write before the current origin reallocates and shifts the previous contents; growth to the right or bottom rounds backing storage upward in blocks of 256 pixels horizontally and 100 rows vertically. Negative editing coordinates are therefore legitimate, not an error or merely a viewport trick.

An image-raster-plane adds a color map. The library can find the nonzero filled area, draw or clear planes, copy with a Boolean or fill ALU, swap complete planes or rectangular subplanes, shift origins, reflect about four axes, rotate by 90, -90, or 180 degrees, duplicate or remove rows and columns, draw filled rectangles and lines, render arbitrary graphics through a temporary bitmap stream, flood a connected region, and manufacture the changed subplane needed for undo.

Clearing a plane fills its allocated storage with the default and then resets logical width and height to zero. It does not necessarily release the backing array. Moving a plane normally changes its origin instead of copying pixels.

Editor state and coordinate systems

The base editor owns:

• a black plane, the image being edited and saved;
• a gray plane, a 25-percent-gray reference and merge layer;
• cached display rasters and presentations for the grid and sample;
• display offsets, initially ten cells in each direction;
• scale, initially ten display pixels per raster cell;
• a dynamically sized array of registers;
• a movable bounding box;
• current drawing mode and foreground/background fill ALUs; and
• an edited flag.

Editing coordinate (0, 0) is the upper-left corner of the editing box, with Y increasing downward. Black, gray, and register planes use those editing coordinates and may extend into negatives. The displayed copy instead uses scaled, scrolled window coordinates.

The distinction matters when moving the bounding box. After a box move, the implementation shifts the origins of black, gray, and register planes by the opposite amount while updating the display offset. The magnified grid therefore appears unchanged, but the one-to-one sample moves. This command changes the image's coordinate interpretation, not just a decorative crop outline.

Redisplay, presentations, and undo

The grid is a Dynamic Windows presentation surface. Incremental redisplay updates both visible pixels and the remembered image in presentation history. The latter is necessary so that dismissing a typeout overlay restores current bits rather than an old copy. Grid lines are displayed only at scale four or greater. The gray plane is drawn through a 25-percent stipple, and the sample is shown at actual size.

Point strokes record the old value of each modified cell. Larger operations save the affected subplane or an invertible operation. Undo, Redo, Skip, and Clear Undo History come from the inherited Undo Program; Help and Command Help come from the Help Program where that program is inherited. This is a genuine action history, not a second saved framebuffer.

Entry and pane layout

The selectable program's pretty name is Bitmap editor, and its Select key is }. Code can also call EDIT-IMAGE or EDIT-BITMAP, choosing writable, fixed-size, or read-only behavior and optionally waiting for the activity to finish.

The standard frame contains:

• a one-line title;
• an actual-size sample at the upper left;
• a dynamically tiled register pane at the upper right;
• a large magnified grid;
• Help and Undo/Redo/Skip menus;
• a central drawing-command menu;
• current drawing-mode and gray-plane menus; and
• a four-line scrolling command interactor.

The main application defaults to a 64-by-64 bounding box when no image is selected. Create Image accepts width and height of at least one, depths 1, 2, 4, 8, or 24 bits per pixel, and optionally supplies standard color maps for four- or eight-bit images.

Direct drawing gestures

The implementation recomputes Control and Meta state during a drag, not only on the initial press. A user can therefore switch a single gesture between setting, clearing, and passing over cells without releasing the mouse.

One-bit images expose Draw, Erase, and Flip. When the selected image has a non-bit element type, the editor automatically switches to Foreground and Background fill modes. Set Pixel changes either fill value, can sample a value from a grid point, and can use the color chooser when a color map exists.

No application-specific character key table occurs in the source. Command names are entered through the command interactor, while the menus and presentations provide mouse accelerators. The } Select key is the only literal application-selection character defined locally. Ordinary Dynamic Windows Help, completion, editing, and command-processor controls remain inherited and are not duplicated as if they were Bitmap Editor commands.

Complete shared command inventory

The following table covers every source-defined command in the base Bitmap Editor table, grouped by purpose.

The Bitmap Editor program adds:

It also inherits Help, Command Help, Undo, Redo, Undo Skip, and Clear Undo History. The installed Bitmap Editor Help command dictionary is older: it describes a dedicated Read MacPaint File command and omits the source-defined Set Pixel and generic Write Image File. The implementation, not that older topic list, establishes the current local command table.

Menu and presentation accelerators

Register retrieval is not replacement. The implementation copies the register into the destination with Boolean IOR, so existing set bits remain set. Storing does replace the register, carries the image color map, and upgrades the register's element type when the edited image depth changes. Every register operation is undoable.

Shape semantics and a flood discrepancy

Lines and rectangles use direct raster-plane primitives; rectangles are filled. Polygon and spline drawing render through a temporary bitmap stream and then copy the result through the current ALU. Polygon and spline require at least three points. Shape commands save the affected subplane for undo.

For Draw/Erase/Flip mode, Flood Region deliberately uses XOR, so it complements the four-connected region whose pixels match the seed. In Foreground/Background mode it fills with the selected pixel value.

The active flood implementation always returns a raster plane, but the command still tests for a false result and reports that the region is not closed. That error path belonged to the commented-out previous algorithm, which returned false when it could not find enclosing boundaries. It is unreachable through the active definition inspected here.

There is a second source-visible edge case. The active algorithm defines its maximum coordinate as origin plus width or height and tests it inclusively. For a default-zero region connected to the raster edge, reads at that one-past edge also return zero, so the result can include a one-cell apron outside the logical plane. Runtime confirmation and a determination of whether later patches mask this effect remain TODO.

Scale and bounding-box edge cases

Set Scale accepts only a positive integer. Zoom/Expand enforces a minimum scale of one. Zoom by Factor, however, accepts any number and passes the rounded product to the same internal setter without validating the result. A factor of zero, a negative factor, or a small factor that rounds to zero can therefore install a scale that other redisplay code does not expect. This is a source-visible validation gap, not yet a reproduced runtime failure.

Refit Bounding Box examines nonzero black pixels only; gray reference pixels do not enlarge the result. Saving crops to the editing edges derived from the box. In read-only mode, saving back is rejected. In fixed-size mode, the box is kept at the image's size and copied only within the original dimensions.

Named images, files, and formats

The persistence path has three distinct layers:

1. edits alter the Bitmap Editor's black raster plane;
2. Save Image copies the bounding-box region into a live Genera named-image object; and
3. Write Image File serializes a chosen named image through a currently registered image-file-format handler.

Stopping after step 2 does not necessarily write a host or Lisp-machine file. Conversely, Read Image File can read several explicit or wildcard pathnames, optionally rotate or trim each result, attach its source pathname and format, assign a unique name when necessary, and register the resulting images. The user then chooses one with Edit Image.

The file-format registry is dynamic. The base Image Substrate always defines Symbolics BIN; distributed source modules additionally define handlers for XBM, PBM, PPM, CBM, XIM, XWD, Utah RLE, TIFF, PCX, IMG, GIF, and Truevision, while separate Color and PostScript systems define their own image and PostScript handlers. Which names appear in a running Bitmap Editor depends on which systems and patches are loaded.

BIN is a Symbolics binary form-dump containing image objects and can be loaded to reconstitute those objects. It is serialized application data, not a disk archive and not a VM snapshot. The other listed formats are image interchanges with different read/write capabilities; source presence should not be promoted to a claim that every handler is active or fully interoperable in the cold museum world.

The generic reader still contains special options for PICT and MacPaint, including optional Macintosh file headers and rotation guidance. No PICT or MacPaint DEFINE-IMAGE-FILE-FORMAT registration was found in the inspected distributed source tree, while the older installed Help exposes a dedicated MacPaint command. This is release/help drift or a missing separately loaded component, not evidence that MacPaint is available in the audited runtime.

Deep-raster support is real but qualified

The implementation creates and displays 2-, 4-, 8-, and 24-bit rasters, carries color maps through black, gray, and register planes, draws menu swatches for foreground/background values, and replaces Boolean Draw/Erase/Flip with fill modes for non-bit images. Those are concrete deep-raster facilities.

The same source labels its color adapter as a collection of “kludges” and contains an old save-path comment saying an adjustment is temporary until the editor supports deep rasters, even though the code preserves the current plane's element type. The defensible conclusion is partial and historically layered color support, not “one-bit only” and not “fully verified 24-bit paint program.” Actual editing, color-map selection, and round-trip results for every supported depth remain runtime TODOs.

Purpose and layout

The Stipple Editor designs the repeating one-bit fill patterns used by the Graphic Editor and graphics substrate. It is a selectable program named Stipple editor with Select key |, and the Graphic Editor can also open it as a modal designer that returns a new stipple object.

Its fixed 500-by-500 frame contains, in order:

• a one-line title;
• a sample occupying roughly the top quarter of the remaining space;
• the magnified editing grid;
• a two-line accepting-values pane for Name and optional Gray level from zero through one;
• the drawing-mode menu;
• the draw-command menu; and
• a three-line command interactor.

There is no register pane, no separate gray-command menu, and no standalone image sample/register split. The black and gray planes and base command table still exist through inheritance.

Tile and sample representation

A new editor starts with an 8-by-8 bounding box. Editing an existing stipple uses its declared repeat width and height and fits the grid with an extra factor of four. The sample first copies the bounding-box cell horizontally into a raster whose width is the least common multiple of the cell width and 32, then tiles that raster across the pane. Any cell or box change therefore invalidates the complete sample.

The least-common-multiple padding is a storage and BITBLT alignment detail, not an enlargement of the logical repeat. On save, the resulting stipple array records the original cell width as its X phase and retains the chosen name and gray-level metadata.

Controls and complete local command surface

Stipple drawing uses the same grid gestures, one-bit Draw/Erase/Flip modes, Control/Meta temporary modes, shapes, transforms, black/gray planes, view, bounding box, Help, and undo commands listed for the base Bitmap Editor.

Its complete installed/source command set is therefore:

• Center View, Clear All, Clear Gray, Clear Undo History, Command Help, Draw Line, Draw Point, Draw Polygon, Draw Rectangle, Draw Spline, Flood Region, Help, Merge Gray, Move Black, Move Bounding Box, Move Gray, Move View, Refresh, all three named Reflection commands, Rotate, Set Drawing Mode, Set Pixel, Set Scale, Snap Bounding Box, both Stretch commands, Swap Gray, Swap Region, Undo, Redo, Undo Skip, Zoom by Factor, and Zoom/Expand;
• Save, which constructs the current live stipple object; and
• Done/Exit Stipple Editor, which returns the object to a modal caller or buries the standalone activity.

The inherited register command names also occur in the installed Stipple Editor dictionary: clear, retrieve into black/gray, and store black/gray. This conflicts with the implementation layout. There is no register pane to present a register argument, and store/undo code requests that pane when redrawing. The commands are inherited at the command-table level, but usable register interaction in Stipple Editor is not established. Treat it as a source/help inconsistency until a live run determines whether the command processor hides, rejects, or errors on those operations.

Gray-plane commands are similarly absent from a visible gray menu but have ordinary command arguments and remain inherited by name. Their usability should also be confirmed in the running activity rather than inferred from menu absence.

Like the Bitmap Editor, the Stipple Editor defines no local character-command table beyond its | Select key. Name and Gray level are edited in the accepting-values pane; commands are invoked through menus, presentations, or the command interactor.

Save, Done, and persistence

Save constructs a GRAPHICS:STIPPLE-ARRAY, copies the bounding-box cell across the aligned width, and stores it as the object currently being edited. Done returns that object when the editor was opened modally or clears it and buries the ordinary selectable activity.

For a newly designed pattern, the reliable implementation-level workflow is therefore edit, Save, then Done. Done alone does not reconstruct the array from unsaved grid changes.

The installed Graphic Editor book says that a new stipple remains embedded in drawings that use it but is not retained in the sample-pattern menu across a reboot. Its statement that stipples cannot be saved refers to this absence of a persistent interactive Save-to-file workflow, not to an inability to create a live stipple object.

The source contains a separate WRITE-DEFSTIPPLE-FORM utility. It writes a Lisp definition form containing the repeat dimensions, name, and bit rows. No Stipple Editor command calls it. It is a valuable preservation/export path, but using it requires explicit Lisp evaluation or a museum script and should not be described as a visible menu feature.

CADR

The public source is sufficient to reconstruct PAINT's algorithms, menus, palette seeds, and controls without extracting a proprietary load band. A faithful runnable reconstruction still needs an old-screen compatibility layer or a port of the framebuffer assumptions. The maintained LM-3 NPAINT is useful as a cross-check, but its presence in the Fossil repository does not make it an active System 303 application.

A future runtime recovery should:

1. make the pinned demo/npaint.lisp available through the harness's local file service without changing its bytes;
2. record whether legacy DEFCLASS and direct screen operations load in System 303;
3. capture the initial palette and all four menus;
4. test every mouse-switch path, especially the four handlerless Area labels;
5. demonstrate Normal, XOR, direct, line, circle, and text modes on disposable pixels; and
6. retain the session and only curate the smallest screenshot needed for the resulting historical claim.

Genera

The licensed source and installed Help remain local, ignored research inputs. This article paraphrases behavior and records checksums; it does not reproduce source or Help payloads. A future live audit should use the isolated Genera harness and separately exercise:

• a one-bit named image and a deep image;
• all five drawing modes and mid-stroke modifiers;
• black/gray merging and register OR retrieval;
• crop-box movement versus view movement;
• the flood and zoom edge cases;
• generic format availability in the actual loaded world;
• Stipple Save-then-Done and Done-without-Save; and
• inherited register and gray commands in the pane-reduced Stipple frame.

No Genera screenshot is included because no Bitmap or Stipple frame was reached in this audit. Source-derived pane descriptions are labeled as such and must not be silently promoted to runtime observations. When a frame is reached, review a specific, minimal screenshot under the publication policy and place only the reviewed image in docs/assets/genera-screenshots/.

Related museum material includes the public CADR visual-assets inventory, CADR color inks and raster patterns, and the Genera image/world recovery boundary.

Public CADR and LM-3 files

The System 46 snapshot is pinned at Git commit 8e978d7d1704096a63edd4386a3b8326a2e584af. The maintained LM-3 source is pinned at Fossil check-in 4df393c68d7f083ce42d5c377039d26043cc18a9031ace28258dc97f4137eb91. They were verified locally on 18 July 2026.

Licensed Genera research inputs

The source and decoded Help remain ignored local inputs. The table is evidence-only metadata and does not convey a redistribution claim.

System 303 runtime record

The execution-time usim hash comes from run.json, not from a screenshot sidecar. Raw session files and all unreviewed captures remain under ignored build/cadr-computer-use/ storage.