Project Logs

Collapse

• What Is Real Today, and What Is Still a Concept?

  John Chirillo • 2 hours ago • 0 comments

  I want to be very clear about one part of RetroBridge because the enclosure concept images are polished enough to look like finished hardware.

  The core RetroBridge appliance is real and working.

  The custom beige retro enclosure is still a design concept.

  Validated today

  The current RetroBridge V1.1 appliance has been physically built and tested with:

  • Raspberry Pi 5
  • 3.5-inch 480×320 touchscreen
  • touch input
  • custom RetroBridge Time Machine frontend
  • Apple-1
  • TRS-80 Model I
  • Apple II
  • IBM PC
  • Commodore 64
  • clean Debian 13 Trixie build
  • boot-to-RetroBridge behavior
  • maintenance mode
  • recovery testing

  The real project photographs in this page show that working appliance.

  Still a concept

  The period-inspired beige enclosure is the direction I want the physical design to take next.

  The concept includes:

  • angled CRT-style profile
  • front bezel
  • ventilation
  • rear I/O access
  • Raspberry Pi 5 active cooling
  • separate shell sections
  • standard fastener concept

  But I have not yet published STL or STEP files.

  I do not want to call an enclosure printable until the following have been physically validated:

  • display opening dimensions
  • Raspberry Pi mounting-hole locations
  • USB/Ethernet/USB-C alignment
  • active-cooler clearance
  • cable routing
  • airflow
  • screw lengths
  • wall thickness
  • print tolerances
  • assembly order

  So the current status is simple:

  The RetroBridge appliance is real.

  The custom retro enclosure is the next mechanical-design phase.

  Once the enclosure has been modeled, printed, assembled, and tested on the actual hardware, I plan to publish those files as a separate validated part of the project.

• The Other Test: Can the Whole Appliance Be Recovered?

  John Chirillo • 2 hours ago • 0 comments

  Reproducibility answers one question:

  Can RetroBridge be rebuilt from scratch?

  Recovery answers another:

  Can the exact working appliance be restored quickly if the microSD card fails?

  I tested that separately.

  I created a full image of the known-good RetroBridge V1.1 microSD card.

  The raw image was:

  • created from the entire physical card
  • SHA-256 hashed
  • compressed with gzip
  • gzip integrity-tested
  • SHA-256 hashed again after compression

  I then restored that image onto a second microSD card and booted the Raspberry Pi from the restored copy.

  The recovered card successfully reproduced the working RetroBridge appliance.

  I tested:

  • the RetroBridge frontend
  • Apple-1
  • TRS-80 Model I
  • Apple II
  • IBM PC
  • Commodore 64
  • appliance startup behavior

  The recovery test passed.

  The private full-card image is not published in the public repository.

  That is intentional.

  A complete operating-system image can contain machine-specific state such as:

  • local user information
  • SSH state
  • network configuration
  • logs
  • host-specific settings
  • other material that does not belong in a public project archive

  Instead, RetroBridge publishes:

  1. a documented clean-build process, and
  2. instructions for builders to create and verify their own recovery image.

  So the project now has both:

  reproducibility — rebuild it from public instructions recovery — restore your own exact appliance image

  That gives the project a much more practical long-term maintenance path.

• Can RetroBridge Be Rebuilt From Scratch?

  John Chirillo • 2 hours ago • 0 comments

  A working development card is useful.

  A project that can be reproduced from scratch is much more valuable.

  To test that, I started with a separate 32 GB microSD card and a fresh Raspberry Pi OS / Debian 13 Trixie installation.

  I intentionally did not clone the original RetroBridge system image onto this card.

  Instead, I rebuilt the environment from the public project documentation and third-party dependencies obtained from their upstream sources.

  The clean build included:

  • Raspberry Pi OS / Debian 13 Trixie
  • MHS35-compatible 480×320 touchscreen support
  • ADS7846 touch input
  • Python/Tkinter
  • DOSBox
  • VICE
  • Debian open-roms
  • trs80basic
  • Rust
  • SDL3
  • EWM
  • RetroBridge EWM 1× display patches
  • RetroBridge launcher scripts
  • Trixie-specific boot/autostart integration

  Then I tested the complete appliance.

  Clean-build validation results:

  480×320 display — PASS Touch input — PASS Apple-1 — PASS TRS-80 Model I — PASS Apple II — PASS IBM PC — PASS Commodore 64 — PASS Boot-to-RetroBridge — PASS

  That was one of the most important milestones in the project.

  It showed that RetroBridge was not dependent on one carefully preserved development card or on undocumented configuration that had accumulated over time.

  The public build path could reproduce the appliance from a clean operating-system installation.

  For me, that is the difference between a working prototype and a reproducible project.

• The Fresh Trixie Build Changed the X11 Startup Path

  John Chirillo • 2 hours ago • 0 comments

  One of the most useful things I did with RetroBridge was rebuild it on a completely fresh microSD card.

  The original development appliance had evolved over time, so I wanted to know which assumptions were real project requirements and which were simply artifacts of the original system.

  That clean build exposed an important difference in Debian 13 Trixie.

  On the earlier setup, the RetroBridge frontend could be launched into the desktop using the normal LightDM-era X11 assumptions and the user's .Xauthority file.

  On the clean Trixie build with the MHS35-style touchscreen driver, that was no longer true.

  The display driver created a dedicated service:

  spi-display.service

  That service starts the graphical environment itself:

  startx → Xorg :0 → LXDE

  and the X session is owned by root rather than the normal RetroBridge user.

  That meant my old launch method failed because the expected user-owned X authorization file was no longer the right authorization path.

  I first proved the frontend itself still worked by locating the temporary X authorization file created for the active Xorg process and launching RetroBridge manually into display :0.

  Once that worked, I replaced the manual workaround with a proper startup wrapper.

  The final wrapper:

  • runs inside the already active LXDE session
  • grants the normal RetroBridge user access to the X display
  • launches the Python frontend as that normal user
  • respects the RetroBridge maintenance-mode file

  The validated startup chain became:

  Power on → SPI framebuffer → spi-display.service → Xorg :0 → LXDE → RetroBridge

  After adding that wrapper to the LXDE autostart path, the fresh Trixie card booted directly into the RetroBridge Time Machine interface.

  This was a good example of why rebuilding from scratch matters. The RetroBridge code itself was fine — the surrounding graphical-session model had changed underneath it.

• Five Computers, One Tiny 480×320 Screen

  John Chirillo • 2 hours ago • 0 comments

  One of the most useful constraints in RetroBridge turned out to be the screen itself.

  The project uses a 3.5-inch touchscreen with a 480×320 display. That is tiny compared with what most modern Linux applications and emulators expect.

  I did not want RetroBridge to feel like a normal desktop where emulator windows happened to be running. The goal was for every historical environment to fit the appliance cleanly and feel intentional.

  That meant solving the display problem differently for each system.

  TRS-80 Model I

  The TRS-80 environment runs inside a deliberately sized terminal so the 64-column experience fits comfortably on the small screen.

  IBM PC

  DOSBox uses appliance-specific settings:

  fullscreen=true fullresolution=desktop output=openglnb aspect=true scaler=none

  Those settings produced a usable full-screen DOS environment on the 480×320 panel.

  Commodore 64

  VICE runs with doubled rendering disabled so the display stays within the physical screen.

  Apple-1 and Apple II

  These were the interesting ones.

  EWM creates the Apple-1 and Apple II SDL windows at approximately 3× logical scale by default. On a 480×320 display, that is much too large.

  Rather than maintaining a modified fork of EWM, RetroBridge supplies two very small patch files that change only the relevant window and logical dimensions from 3× to 1×.

  After rebuilding EWM, both Apple environments fit the RetroBridge display correctly.

  That approach also keeps the public project clean:

  • RetroBridge distributes the patch
  • EWM remains an independent upstream project
  • no third-party emulator source tree or binary is redistributed

  The small screen forced RetroBridge to become more than a launcher. Every environment had to be adapted to the same physical appliance.

  In the end, the limitation helped define the project.

• Why Build a Computing Time Machine?

  John Chirillo • 2 hours ago • 0 comments

  RetroBridge started with a simple question: could one small Raspberry Pi system provide a meaningful hands-on tour through the first few years of personal computing?

  I was less interested in collecting emulator icons than in preserving the differences between the machines themselves.

  The Apple-1 begins close to the hardware with Woz Monitor and Integer BASIC. The TRS-80 puts BASIC at the center of the experience. The Apple II represents the transition toward a more complete consumer personal computer. The IBM PC introduces the DOS environment that would shape an enormous part of the industry. The Commodore 64 represents the explosion of home computing into programming, graphics, sound, and games.

  That became the core RetroBridge timeline:

  1976 — Apple-1 1977 — TRS-80 Model I 1977 — Apple II 1981 — IBM PC 1982 — Commodore 64

  Instead of presenting those systems as separate applications, RetroBridge wraps them in one chronological touchscreen interface.

  The result is a small physical computing-history exhibit that you can actually use.

  One of my goals with this project is to make the history feel tangible. You do not just read that these machines existed — you select a year, enter the system, type commands, run BASIC, and experience how personal computing changed over a very short six-year period.

  That is why I describe RetroBridge as:

  Five Computers. Six Years. One Computing Time Machine.

View all 6 project logs