Project Orrery - Real-Time VGA Planetary Orbit Simulator.

OVERVIEW

For my 6.115 final project, I designed and built a real-time planetary orbit simulation running on a PSoC microcontroller. The system renders animated planets to a VGA monitor while calculating their motion from simplified orbital-mechanics equations.

A matrix keypad accepts custom dates and times; a rotary encoder changes simulation speed; toggle switches control orbit rendering and select between an inner-system and full-system view. Fourteen external seven-segment digits show the current simulation date and time.

SYSTEM ARCHITECTURE

The PSoC coordinates VGA graphics generation, planetary simulation, user input, and external display hardware. DMA continuously streams pixel data to the monitor while the CPU updates orbital positions, polls controls, renders the next frame, and refreshes the date/time displays.

The orbital model stores each planet's angular velocity, eccentricity, initial mean anomaly, and perihelion orientation. Those values are used to compute a position relative to the Sun for the selected simulation date.

VGA OUTPUT

Stable VGA required precise horizontal sync, vertical sync, and pixel timing. The output follows 640 x 480 at 60 Hz timing, but blanks early horizontally to form a square display area for the circular orbit system. Horizontal timing covers 800 pixel periods per line with 640 visible pixels; vertical timing covers 525 lines with 480 visible lines. Hardware counters generate these intervals while DMA streams pixels to the VGA output register independently of CPU rendering.

The DMA path naturally produces one pixel output every eight master-clock cycles, so the pixel-clock relationship is f_pixel = f_master / 8. A 240 x 240 render target at the desired scaling would have demanded roughly a 100 MHz master clock, beyond what the platform could reliably sustain. The final design uses two 120 x 120 SRAM buffers and a roughly 6.3 MHz pixel clock, then scales the image for the VGA display.

FRAMEBUFFER

The renderer draws the next scene into buf while vbuf remains the actively displayed video buffer. The VGA ISR tracks the scanline and permits the transfer only during vertical blanking. DMA is disabled for the copy, then immediately re-enabled afterwards, so the monitor never scans a partially updated frame.

Pixels use an 8-bit RGB332 representation: three red bits, three green bits, and two blue bits, so each pixel occupies one byte in SRAM. The blue least-significant bit is also connected to the blue most-significant bit to retain useful grays and saturated blues. Rendering includes pixel drawing, sprite drawing, midpoint-circle orbit paths, and buffer clearing.

RENDERING

Planets are rendered as sprites directly into the framebuffer. I wrote a Python conversion script that turns indexed PNG artwork into C arrays containing RGB332 values, and also produces preview images from those arrays to check the embedded palette before compiling it into firmware. A pixel value of zero is treated as transparent.

The project has two display modes. The inner-system view uses larger planets and orbit radii; the full-system view uses reduced sprites and compressed radii so the outer planets also fit inside the 120 x 120 render area. Orbit paths can be enabled or disabled in real time.

ORBITAL MODEL

The simulation uses a first-order Keplerian approximation intended for visualization rather than scientific precision. Each planet stores angular velocity w, eccentricity e, initial mean anomaly M0, perihelion angle varpi, and its current screen position.

For elapsed simulation time t in days, mean anomaly advances as M = M0 + wt. The implementation then applies the first-order eccentricity correction nu approximately equals M + 2e sin(M), rotates it by perihelion orientation phi = nu + varpi, and computes screen coordinates x = r cos(phi), y = r sin(phi). The rendered orbit paths remain circular, but the Keplerian correction makes the planets move at visibly non-constant speed along them, especially Mercury.

TIME AND SPEED

Internally, the simulator represents time as elapsed days from the J2000 reference epoch. Entered calendar time is converted by accumulating full years since 2000, the days in preceding months, the day within the current month, and a fractional day from hour, minute, and second. The routine handles leap years, varying month lengths, and rollover before the resulting value reaches the orbital model.

The encoder is read through the PSoC quadrature-decoder peripheral. Its clamped position x controls the multiplier as speed = e^(0.5x), giving both near-real-time motion and fast time acceleration without a long linear control range. At high speeds the simulator steps in minutes, hours, or full days; pressing the encoder resets it to 1x.

INTERFACE

A scanned 4 x 4 matrix keypad provides date/time entry: firmware drives one row low at a time, reads the four columns, and maps the detected key. Numeric entry, deletion, and confirmation are supported, with entered values clamped to valid calendar ranges before updating simulation state.

Two toggle switches control orbit visibility and system scale. Two daisy-chained MAX7219 drivers receive SPI data and operate fourteen seven-segment digits in BCD decode mode, showing YYYYMMDDHHMMSS. The driver code formats values, extracts decimal digits, and addresses the appropriate display in the SPI chain.

RESULTS

The final system renders animated planetary motion in real time with stable VGA output and responsive controls. Display updates are smooth without visible tearing, and the orbital calculations remain stable over a wide range of simulation speeds.

The completed system supports orbit visualization, inner and full solar-system views, date/time entry, and dynamic speed adjustment. The largest design change was the framebuffer resolution reduction; it traded detail for a timing budget that the hardware could reliably meet.

FUTURE WORK

Live external time data was planned but not completed within the project timeline. Other next steps would be higher-resolution VGA output, planet labels, zoom and panning, a starfield background, moon simulation, and true page-flipped double buffering if additional SRAM were available.