Table of Contents

Supporting "Smarter" Terminals

William Schaub, Dale Sinder and Steve Zoppi 2025/05/09

Overview

Abstract

On CERL 1) NovaNET, support was added in the late 1980's for a “Smarter” PLATO 2) terminal that exceeded the capabilities of its predecessors 3).

With the advent of robust personal computers, the need to have special-purpose hardware was no longer necessary. Though prior generations of personal computer-based terminal emulators had been attempted, the limitations of the terminal platforms, displays and CPU characteristics limited what could be done in until displays could equal or surpass the capabilities of the PLATO terminal's 512×512 pixel density.

The ability to support other forms of rich graphics, native fonts, and more, led to the development of a significantly enhanced terminal software called PlatoAccess.

PlatoAccess was constructed to build upon the existing Level Zero ASCII Protocol and implemented the Level One ASCII Protocol .


As we continue to recover older lessons of historical import, we have come across lessons which use these features of PlatoAccess. Because CYBIS does not inherently (in Release 1), support these more advanced display capabilities. The Retro1 project has chosen to enhance CYBIS in Release 2, to implement these capabilities.

Accomplishing this is an on-going project. Enhancements build upon other accomplishments so this work must be conducted in phases. Each phase is documented here in the order in which they must be done. This work is conserved in the form of a TUTORIAL for the aspiring hobbyist.

Prioritization of Work

Work is prioritized as described above; by the natural programming need, with each feature providing a stepping stone to the next feature. Prioritization will then shift to doing the most likely to be encountered feature that is also very difficult to do without.

Prerequisites

Overview of Activities

As noted above, this procedure assumes that you are using a CYBIS Release 2 system with no additional modifications applied to the following files:

Failing to have a proper backup may lead to undesirable outcomes:

  1. You may accidentally overwrite work in progress on lessons nplato and nmem.
  2. The replacement code file plmods will completely overwrite any modifications which may have been locally applied.

When completed, this procedure adds many new files and edits or replaces the contents of these key existing files:

  • ns0notes ⇐ (New Copy)
  • s0notes ⇐ System Library
  • os0notes ⇐ (Old Copy)
  • ns0terms ⇐ (New Copy)
  • s0terms ⇐ System Library
  • os0terms ⇐ (Old Copy)
  • maintsub ⇐ Utility Jobs
  • maintp ⇐ Build Procedures
  • nmem ⇐ (New Copy)
  • mem ⇐ System Memory Viewer
  • omem ⇐ (Old Copy)
  • nplato ⇐ (New Copy)
  • plato ⇐ System Lesson PLATO
  • oplato ⇐ (Old Copy)
  • nuser ⇐ (New Copy)
  • user ⇐ System Lesson USER
  • ouser ⇐ (Old Copy)

These procedures will also create a set of modifications which, when applied correctly, will implement features of the Level One PLATO Protocol.


It is highly recommended that you backup the entire system using the cdc.io backup subcommand.

The system lesson operator is used to promote the following files to “production” using the system standard procedure:

You must successfully complete all steps in each phase before proceeding to the next.

Tutorial Phases

Tip

The tutorial phases are arranged in a prescribed order, wherein each phase builds upon the previous. Performing these activities out of order will leave the installation in an inconsistent, or perhaps inoperable state.

1)
The Computer-based Education Research Laboratory at the University of Illinois at Urbana/Champaign
2)
Programmed Learning and Teaching Operation