Changes

v0.2.7 — menus fire on the release

Keith found this one at the exhibit desk, on the build pictured across this site: under v0.2.6, picking a menu item depended on a chain of polled mouse packets — the press that opened the menu had to be seen in one packet, the item press hit-tested from the position riding in another — and nothing at all listened for the release. On the real path, release packets go missing, so his press-drag-release on Demo Program twice fired nothing at all — and once, a click fired the wrong item, because the position had been sampled mid-travel instead of where the gesture ended. v0.2.7 rebuilds menu selection around a single rule: a menu fires where the gesture ends.

• Selection is decided at the release: Prism’s main loop already polls the mouse state every tick — current button, current position, one snapshot. v0.2.7 derives the release edge from that polled state, so no packet arrival is ever trusted: a poll can only be late, never lost — and the fire position is, by construction, the position at the moment of release.
• A browse highlight, new in this build: while a menu is open, the row under the pointer is painted in the accent treatment as you browse, and the previous row is restored as you move on. For the record: v0.2.6 had no browse highlight to preserve — this one is new, and the build log says so.
• Menu behaviour, completed: releasing on the open menu’s own title latches it; releasing on another title switches menus, latched; releasing anywhere else dismisses, firing nothing. A press is never a selection anymore. The desktop-icon and directory double-click path is deliberately unchanged.
• Verification (rig, director-driven, 4 November): one scripted press-drag-release fires Demo Program first try — the fault’s own gesture — with the item highlighted mid-drag; Shell Window, the File and View menus and the dismiss case all pass, and the v0.2.6 regression set re-passes. One honest limit, stated in the build log: the rig’s director synthesizes perfect packets, so it proves the geometry and the absence of regressions — the lost-release fault itself can only be proven fixed at the desk, on the real mouse path.
• Installed in the exhibit 6 November 2026: the exhibit now runs Prism 0.2.7 (build: dist/prism 18,804 bytes, md5 92dc622e…). The screenshots across this site remain the v0.2.6 “Tiles” captures of 6 November — the desktop they picture is unchanged; what changed is how its menus answer the mouse.

One night, four versions — the combined exhibit update

The day’s four builds — v0.2.3, v0.2.4, v0.2.5 and v0.2.6, each verified on the test rig on its own — were installed into the live exhibit as one combined update, so the machine Keith actually uses rebooted once and woke up with all of it: the exhibit now runs Prism 0.2.6 (binary 18,056 bytes). The entries below carry each version’s detail; this one carries the parts that belong to the machine, not to any single version.

• The clock is right at boot: the launcher stamps the host’s date and time into a HOSTTIME file on the /H1 image before MAME starts, and the startup file feeds it to setime. No more “Time?” prompt, no more stray 2014 dates — the guest trails the host by under a minute (the stamp-to-boot latency), which is the accuracy Keith accepted. The mechanism is v0.2.5’s, below.
• The boot console: light blue and 80 columns from the startup file’s first line — and because Prism now starts as prism&, the boot console stays a live shell after the desktop comes up, not a transcript you can only watch.
• New hardware in the exhibit: the launcher now configures a Multi-Pak Interface — the floppy controller in slot 4, the Orchestra-90 in slot 1 — and the Orch-90 demo (orchdemo) is installed in CMDS, ready to run from the Shell Window or by double-clicking it in Prism.
• A correction, per this page’s rule: the v0.2.3 entry below, written while that fix was in verification, names the missing DWSet as the whole cause. The rig’s process table told the deeper story: Prism’s forked shell child died at birth, so no process ever ran on /W5 — and DWSet alone, tried in two builds, was not sufficient. The shipped fix forks shell i=/w5 — the same way EOU’s own startup starts its window shells — so Shell+ opens and defines its own window.
• A second correction (6 November 2026): the Orch-90 demo line above was too confident. orchdemo is indeed installed — but in live testing at the desk its playback failed: the songs ran at the wrong speed and the keys went unanswered. It is on the bench being rebuilt around a tick-clock player, and until a fixed build is verified by ear, the demo stands as installed but not yet working.

v0.2.6 — the “Tiles” beauty pass

Keith set the bar in so many words: Prism must look so modern people won’t believe they’re on a Color Computer 3. The drive icons were the named weakness: nice, but weak-looking. So the evening’s design pass rendered three candidate directions host-side — drawn with Prism’s own primitives, the real SysSmall glyphs and the exact palette bytes — and Keith picked by eye: Direction C, “Tiles.”

• Tiles: each drive is now a modern app-icon badge — a 48×28 paper tile with an ink keyline and stepped 3-2-1 stair corners. Hard disks carry a platter glyph with an amber tone-arm; /D0 carries the classic floppy glyph — ink body, paper shutter and label, an amber label rule. /DD and /H1 share the platter; the labels differentiate, as before. Art box 44×26 → 48×28, icon pitch 54 → 56.
• The whole family, one language: the directory glyphs were restyled to match — a paper plaque with an ink frame, an amber folder with an ink tab tick, a file page with three ink rules (v0.2.4’s amber header band retired), and the program page keeping its bold amber play-triangle. The v0.2.4 grid contract is untouched, so icon and name still cannot drift apart.
• The trash can, second try: the design sheet’s first transfer — a lid bar over a solid block — read as the letter T, and the sheet said so. The shipped can is an actual can inside the framed plaque: a handle nub, a lid that overhangs the body, ribbed walls. It was prototyped in the simulator before any C was written.
• Both themes survive: under Classic Mono the tiles, labels and selection render in the mono registers with every shape unchanged; the amber selection backing still fills the cell, and the tile’s clipped corners show as ground notches against it — exactly as mocked, and kept.
• Verification (rig, four boots): the desktop in SysSmall with the tiles up; /DD opened with every folder glyph square on its name; the Mono round-trip and back; the Shell Window CLEAR cycle; a prism& boot with a live console; and the Demo Program’s screen itself captured this time, returning cleanly. Build: dist/prism 18,056 bytes, md5 bae9df1e…

One harness lesson, logged because it cost a boot: the test director’s scheduler is not a scheduler — a stage re-runs every frame with whatever values that frame carries, so click targets read from files silently reverted to their defaults mid-sequence. The fix (director-v026.lua) reads the target once and holds it. The guest was never at fault.

v0.2.5 — the clock tells the truth; the classifier learns

Keith’s request was simple: this emulated machine has no real-time clock, so Prism’s menu-bar clock faithfully displayed whatever date the boot prompt had been fed — April 2014, some days. Have EOU check the desktop’s clock as it boots; minute accuracy is fine. It shipped together with the fix for a classifier bug that had been mislabelling programs since v0.2.

• Boot clock sync: before MAME starts, the launcher writes the host’s date and time into a file named HOSTTIME on the /H1 image (Toolshed, host-side); the startup file then runs setime</H1/HOSTTIME in place of the old interactive setime. The file format — one line, yyyy/mm/dd hh:mm:ss, CR-terminated, no LF — was discovered in-guest: setime prints that format as its own prompt header and reads exactly one line in it, so fed from a file it needs no interaction and no helper utility. The guest trails the host by roughly 45–55 seconds, which is the stamp-to-boot latency. Proven on two consecutive boots: date -t answered “November 03, 2026 19:02:05” with the host inside the same minute, and Prism’s own clock read 18:48 at host 18:48.
• The classifier — the root cause was deeper than the bug: since v0.2, everything in /DD/CMDS wore a folder icon, and double-clicking a program tried to open it as a directory. The first fix — read the file descriptor’s attribute byte via SS_FD, the documented route — failed in the rig: directories showed as files. A purpose-built probe (fdprobe) found out why: on this system, RBF’s SS_FD handler never fills the caller’s buffer. It returns with the buffer untouched, for files and directories alike — so any classification built on it reads garbage.
• The test that actually works (the same probe, 9 paths out of 9): a path is a directory if and only if opening it with mode 0x81 succeeds; regular files refuse that open and open with mode 1 instead. The shipped classifier does exactly that, then reads a non-directory’s first two bytes and marks it a program only if they are the OS-9 module sync bytes $87 $CD. No SS_FD call remains in read_dir.
• Verified end to end: the real directories in /DD (APPS, AWK_SAMPLE, BBS, BOOTS, CAL, CMDS, DATA) wear folder icons; data files wear the file icon and answer “That file is not a program” when double-clicked; copies of a CMDS program wear the program icon, and double-clicking one launched it on /W4 — Prism reported “Program finished”. One known cosmetic: OS9Boot starts with the sync bytes (it is a module container), so it wears the program icon although its descriptor carries no execute bits. Noted, accepted.
• Regression gate: the Shell Window CLEAR cycle, the Demo Program, the v0.2.4 alignment geometry and the prism& live-console boot all re-pass on the final binary. Build: dist/prism 17,497 bytes, md5 efcbc1d7… — rig only at this point; the exhibit install is the combined update at the top of this page.

v0.2.4 — the polish bundle: SysSmall, straight rows, a blue console

Five fixes that had been queuing behind the Shell Window, shipped as one polish build. The first is the verdict trailed at the end of the v0.2.3 entry: Keith judged the font comparison sheet — four candidates rendered from the real glyph data — and picked SysSmall.

• SysSmall is the default font (EOU’s 200/39, from SYS/smallfont.27). A probe found the buffer is resident after boot — the startup file’s font-merge line loads it — so Prism’s own load-if-needed path is belt and braces. The View menu offers SysSmall, Prism Sans and Narrow, switching live. The wider 8-px cell forced a layout audit: desktop icon labels are now pixel-centred (they were hardcoded to text column 99 — off-screen at 80 columns), the clock bar widened, and status text is capped at 62 characters.
• Directory alignment, rebuilt after a live rejection: the first design went to the rig while Keith watched, and he rejected it on sight — he was right. The true root cause: text is placed on the 8-px character grid while icons are placed in pixels, so at the old row height the name-to-icon offset drifted by up to a full cell, differently on every row. The rebuild makes the row 16 px — a multiple of 8 — so the name’s cell and the icon art share one centre line on every row, and a snap on drag-release keeps the window locked to that grid for good. The file icon was redrawn for contrast in the same pass (the white page had washed out on the white window): an amber header band and ink rules; the program icon is a bold amber play-triangle. Verified row by row in /DD and /DD/CMDS: every icon squarely paired with its name.
• prism&: the startup now forks Prism with EOU’s trailing ampersand, so the boot console (/term) stays a live shell after the desktop appears — date answered at its prompt. (A leading-ampersand form was tried first; under the boot shell it silently does nothing.)
• The boot console turns light blue: the startup file’s first line sets palette register 1 to light azure (0x1D). The change is retroactive — once the line runs, the entire /term console is blue, including the kernel lines printed before it. The NitrOS-9 splash box and the brief green phase before the startup file runs can never be blue, and /W1 and /W2 keep their green: the change is /term-scoped.
• WIDTH 80 before DOS in the launcher’s autoboot string; the 80-column boot is screenshot-proven. Honest footnote: several apparent boot “hangs” during this session were the test harness, not the guest — the rig’s Lua director ignores its gate files for roughly its first two minutes after launch, so boot commands typed inside that window collapsed and DOS was never issued.
• Regression gate: the Shell Window (live /W5, a command answered, the full CLEAR cycle) and the Demo Program (“Program finished”) re-pass on the final binary. Build: dist/prism 17,477 bytes, md5 73dc8dca… — installed in the test rig only; the exhibit install is the single combined step at the top of this page.

v0.2.3 — the Shell Window gets a real window

Found the honest way — at Keith’s desk, using the exhibit like a user. Special → Shell Window reported “Shell window open on /W5”, and the shell really had started… but pressing CLEAR to cycle to it never arrived. The shell was running on a window that, as far as the display was concerned, did not exist.

Root cause: Prism opened /W5 and forked the shell onto it, but never defined the window — no DWSet. EOU only cycles the display among defined windows, and the boot defines just /W1 and /W2. Worse, the spare window descriptors’ own stored definitions are invalid: a bare wcreate /w5 answers Error #195 — Illegal window definition, so any program that trusts the descriptor defaults hits the same wall. The programs that work — pdemo, Prism’s own screen — define their windows explicitly, parameters and all.

• Shell Window fix: on opening /W5, Prism now writes the full DWSet definition first — screen type 7, origin 0,0, 80×25, foreground 2, background 1, border 2 (the same parameters pdemo uses) — and only then forks the shell.
• Launch window, same treatment: the program-launch window /W4 is now defined at open too, so a launched program’s output — or its error message — can never again run invisibly on an undefined window.
• Plainer words: the status line now reads “Shell window open on /W5 — press CLEAR (Home) to visit it.”
• Status, stated plainly: rig-verified the same day — the full CLEAR cycle lands on a live /W5 shell and date answered, with the Demo Program regression passing — and installed into the live exhibit on the night of 3 November 2026 as part of the combined update at the top of this page. One detail of the root-cause account above did not survive verification; the correction is in that combined entry, where this page’s rules put it.

Also on the bench today: Keith judged that Prism Sans’ characters still don’t sit in proportion to each other, so a font comparison sheet was rendered from the real glyph data of four candidates — Prism Sans, EOU Narrow, EOU Standard / CocoGIME (8×8), and SysSmall — for a pick-by-eye verdict; the winner becomes the default in the polish update. And the directory-window icon alignment complaint was traced in the drawing code: rows are 11 px tall but the folder and file icons are drawn 14–16 px, on three different vertical anchors (folder at the row top, file 2 px above it, text 1 px below), so icons overflow their rows and drift against the names. The fix — icons redrawn to fit the row, one shared centre line — is queued in the same polish update.

v0.2.2 — one-action Shut Down, and a portable bundle

• Shut Down (the headline): a new third item in the Prism menu (and in the launcher menu; Quit Prism stays the plain exit-to-shell). Shut Down writes one timestamped line — PRISM-SAFE-SHUTDOWN HH:MM:SS — to /H1/SHUTDOWN.SIG and exits exactly like Quit. A watcher script on the host (a MAME -autoboot_script) fingerprints every marker in the drive image at start-up — so a stale marker from a previous session is baselined and can never fire — then rescans in small per-frame slices; a new or changed marker must survive two consecutive complete scans before the emulator closes itself. No timers, no guesses; the worst case of any failure is that the emulator stays open. Proven end-to-end three times on the test rig, and across eight rig boots the watcher never fired without a fresh marker. Build: dist/prism 17,185 bytes.
• Boot-to-Prism: the hard drive’s startup brings Prism up directly, and after Prism exits it prints “Prism closed. It is now safe to close the emulator. Type PRISM to run it again, or GSHELL for the EOU GUI.” — the fallback if the watcher is ever absent.
• Exhibit fix: the long-standing MAME ROM-audit warning on boot was traced to a bogus bios b11e11 line in coco.ini and removed. It mattered more than it looked: the warning parks the machine before the shutdown watcher’s script ever runs. The exhibit now boots warning-free.
• Portable bundle (Windows-first): the official MAME 0.275 Windows binary, unmodified; drive images with boot-to-Prism and Shut Down baked in; the exhibit’s own machine config; every path relative, so nothing touches a user’s existing MAME setup. It ships with zero ROM bytes: the launcher checks for the two ROM files by SHA-1 and, if they’re missing, offers exactly one button — “Get the CoCo 3 ROMs” — which downloads them from the Color Computer Archive and verifies before enabling Start (manual copy is the fallback). Verified live: coco3.rom 32,768 B, SHA-1 e0d82953…; disk11.rom 8,192 B, SHA-1 10bdc5aa… — byte-for-byte what the coco3h driver demands. Distribution zip: 151,499,915 bytes.
• Testing notes, honestly: under Wine 9.0 the shipped mame.exe starts but cannot open the bundle’s disk images — a Wine file-layer quirk, not a bundle defect (the same images boot under Linux MAME) — so the decisive end-to-end test will run in a Windows 11 VirtualBox VM. Public distribution containing EOU still awaits Curtis Boyle’s permission, asked on 2 November.

The design rule: use the whole machine — the v0.3 “Full RAM” direction

Keith set a standing design rule: Prism must use the whole 2 MB in everyday operations, through the GIME’s memory management — 8K pages, 256 of them in a maxed machine, swapped into the CPU’s 64K window on demand. Directory caches, icon caches, font caches and per-window backing stores will live in paged RAM and be mapped in as needed, so the desktop works from memory instead of re-reading disks.

Sequencing, as designed: the page manager lands in os9sys first (block allocation, map-in/map-out, a small LRU, and yielding blocks under system pressure so Prism never starves its neighbours), Prism adopts it second, and the planned CoCo RTS is designed against it third. That ordering is the v0.3 “Full RAM” milestone; the System Monitor and Orch-90 demo adopt the layer on their next revisions. A design entry, not a shipped feature — it is recorded here because the rule now governs every build after it.

v0.2.1 — Prism Sans, a typeface of its own

Keith’s verdict on the v0.2 interface font (EOU resident 200/2 “Narrow”): still ugly — “maybe smaller yet?” A fonts-only session followed. First, a survey of everything EOU loads at boot, each rendered in Prism and judged on screenshots:

• 200/2 Narrow (6×8) — the v0.2 default: thin, spindly, uneven spacing.
• 200/50 MacNarow (6×8) — a heavy bold blob; worse for a light interface.
• 200/39 SysSmall (8×8 cell, ~5 px glyphs) — the cleanest stock face, but the 8-wide cell widens all text: the launcher-button label overflows and the icon-label column math breaks. Not a drop-in.
• 200/34 Small — lowercase renders as small caps; chunky, gamey. 200/49 MacStd and 200/21 IBM were judged from the contact sheet only (bold/heavy; serif typewriter — wrong identity).

The winner was drawn, not found: Prism Sans — hand-drawn 5-px glyphs, 7 rows tall inside the standard 6×8 cell (so not one layout constant moved), full printable ASCII, a dotted zero to separate it from the letter O. It is generated by fonttest/makefont.py into src/prismfont.h, embedded in the binary, GPLoaded at start-up into group 200 buffer 52 — the first buffer above EOU’s own 1–51 — and FontSet as the default. The View menu gained Prism Font and Narrow Font, switching live.

• Lesson, written down: WindInt’s text grid is locked to 8-px rows. A font header declaring 7 rows wrapped the status line onto the menu row and double-spaced the directory — the font declares y=8 with its seventh row simply blank.
• Lesson two: font buffers are not all equal. The identical font in buffer 200/96 broke CurXY positioning at high columns (clock and icon labels streamed across the menu row); buffer 52 positions perfectly. 52 is proven, 96 is poisoned.
• Build: dist/prism 16,610 bytes; installed into the exhibit with byte-identical read-back and screenshot-verified in an isolated instance (the running exhibit was never touched by the test).

v0.2 — identity, double-click, launching

• Screen: 640×200 — screen type 7 at 80×25, the documented EOU maximum, verified on screen before adoption (DWSet requests for 106×25 and 80×28 fail silently). Font 200/2 “Narrow” (6×8) throughout; text laid out in pixels.
• Double-click — the session’s #1 bug, fixed for real. The chain, each link proven before the next fix: v0.1.1 trusted the driver’s release-edge click count — which reads 3 after a double-click, not 2. A click-count rescue was then tried and rejected in full: after a slow descent into a new directory, a second click’s release carried a stale count whose position hit-tested to the same row in the new window, and Prism spuriously launched the “Answer” program. The shipped mechanism trusts only what Prism can observe itself — its own press edges on the same target within 42 ticks — with selection painting deferred 48 ticks, until the double-click window has fully closed, so a repaint (~0.1–0.3 s for four row paints) can never span and swallow the second press. The packet holds current state, not a queue; that was the whole trap. Accepted cost, by design: a single click’s highlight lands ~0.8 s after the press; a double-click opens immediately.
• Program launching: File → Open, or a double-click on an executable, forks it through a shell on /W4 (modal; Prism F$Waits, then reports “Program finished”). Programs that open their own windows work inside the flow — the bundled pdemo DWSets and selects its own /W3, draws, and waits for its own key. Special → Shell Window forks a genuine interactive shell on /W5, left running and visited with CLEAR.
• Chrome and identity: paper menu bar with an HH:MM clock at the right end (redraws only when the minute changes — the entire cost is one 40×16 rect per minute); a 4-segment spectrum band under the bar (ink | amber | paper | ground); amber title bars with the title centred in ink; dot-pattern drop shadows (the system 50% pattern, group 204 buffer 1 — A/B-tested against solid and kept); procedural hardware icons (hard drive, floppy, folder, file, executable, trash) drawn from palette-register primitives, so both themes remap them for free; a draggable directory window (title-bar drag with an outline ghost, clamped on screen) with close box and page arrows; 64-entry listings, 10 rows per page, “..” no longer listed; the Prism launcher button bottom-left with its 9-item pop-up menu; an About dialog; and a clean Quit — “Prism 0.2 exited.”
• Platform findings (verified on screen or in logs): the CoCo mouse in MAME is a relative device — the packet integrates host deltas, so absolute pointer warps leave it frozen at (330,104) while buttons register; that one fact ended a day of “pointer freeze” misdiagnoses (a physical mouse emits deltas and always worked). ESC $30 resets the palette — it is not a border call, and v0.2 never uses it. PutBlk does not render in any tried form on this WindInt, which is why the icons are drawn primitives. Directory classification costs real time: an SS_FD per entry runs ~3–4 s for 38 entries and ~10–15 s for 64.
• Build: dist/prism 15,448 bytes. Verified across ten Spectacle screenshots: both themes, a fast double-click opening /DD, descent into /DD/CMDS without the rejected rescue’s false launch, pdemo launched from the menu, the launcher menu, About, the /W5 shell executing date, a title-bar drag, and a clean quit.
• Shortfalls, on the record: the standalone release disk is still a data disk, not self-booting; the Shell Window’s shell is reaped only when Prism exits; large-directory classification is slow and listings cap at 64; single-click highlight lags ~0.8 s by design (above).

v0.1 — first light

• The platform first: EOU was maximised with SwapBoot — of the five complete boot sets it found, the EMUSOFTCLOCK set was chosen (this emulated machine has no RTC; boots pause at a “Time?” prompt and ENTER accepts) — and the monitor type set to RGB. GShell came up at a true 640-wide desktop in correct greys, in place of the 320-wide composite rendition it had been showing.
• The mouse fix that was itself the bug: SS_Mouse returned a frozen, railed position (X=0, Y=198) while buttons worked. The cause was a setting applied during the first fix attempt: MAME’s Machine Configuration “Hi-Res Joystick Interfaces” must be NONE for this setup — EOU reads a plain joystick-ADC mouse on the right port (PTRRES=0), and the hi-res routing means the two never meet. The MAME UI would not persist the change, so coco3h.cfg was hand-edited (hires_intf value 1 → 0). After that, the diagnostic mtest swept X 330→634 and Y 104→195 with clicks registering, and the arrow tracked in both GShell and Prism. Right Controller Port = P1 = joystick_rx/ry; the launcher passes -mouse so the host mouse feeds MAME at all.
• Toolchain, all user-space, no sudo: CMOC 0.1.86, LWTools 4.21, Toolshed 2.6.1, plus byacc, GNU m4 and flex to satisfy the builds (CMOC needs a yacc; bison was absent). Smoke test passed: hello.c → a 1,687-byte OS-9 module, listed by Toolshed on a scratch disk.
• The shell itself: Prism opens its own device window with DWSet and selects it; on exit it DWEnds and the user’s shell screen returns. Session 1’s canvas was screen type 7 at 640×192 with four palette registers in fixed roles — ground deep teal-blue $19, paper white $3F, ink black $00, accent warm amber $34 — with Classic Mono (light grey $38, dark grey accent $07) switchable live from the View menu. Menu bar (Prism / File / View / Special), drive icons for /DD, /H1, /D0 down the right side, directory windows listing a drive’s real contents, and the pointer read only through SS_Mouse ($89), polled on an F$Sleep-paced loop at ~30 Hz.
• v0.1.1 (same day): double-click detection moved onto the release edge of the driver’s click count — on a press packet the count reads 0 or 1; it only reaches 2 on the release packet of the second click, then decays. (The mechanism was proven at the packet level; v0.2 later replaced it wholesale — see that entry.)
• Gotchas, recorded so nobody repeats them: WindInt pattern fills paint only the pattern buffer’s value-1 pixels — a textured ground needs an opaque solid base pass first, or closed menus leave permanent ghosts (found on screen, fixed in v0.1’s final draw). And os9 copy lands files without execute bits: os9 attr -pe is the incantation that yields the standard --e-rewr; plain -e leaves the shell answering Error #216.
• Build: dist/prism 7,451 bytes, installed in the EOU hard drive’s CMDS. Verified on screen: desktop up, /DD directory window matching a host-side os9 dir exactly, Classic Mono applied live, clean exit to a live Shell+ prompt.
• Honest shortfalls at v0.1: program launching stubbed (the F$Fork wrapper was built and linked; window ownership/hand-back was v0.2 work); icons were line drawings, not bitmaps; listings showed the first 15 entries with no scrolling; no self-booting standalone disk yet — session 1 shipped the bare binary plus a data disk that runs on any booted NitrOS-9/EOU system.

The project begins

Keith Clark of Rodney, Ontario commissions a Finder-style graphical shell for the TRS-80 Color Computer 3 — written from scratch, in the open, as a free gift to the CoCo community, after admiring the polished graphical desktops of the CoCo’s era and deciding its hardware could wear one just as well. The direction: Muse has total development control; Keith approves the overall look and shine. The finish test for every screen, set on day one of the polish work: “Would this look at home next to the GS/OS Finder?”

The project is called Prism. Its source is published under the MIT licence, and this site is its home.