On this page you can read about the design and development environment of the StarShip.
Here is a short description of what you can find when you click a link at the top of this page.
I intend to fill these pages little by little, so check from time to time!

• hardware overview
  Description of the major components of the StarShip.

• processor subsystems
  The processor systems of the StarShip.
  Inside the StarShip are 2 small computer systems: one with a Motorola M6802 CPU, the other with an M6809 CPU.
  The M6802 system handles the 2 console keyboards, the trackball and the control of the LCD at the left side.
  The M6809 system is dedicated to the main screen graphics.
  Outside the StarShip is the main computer system. It is a VME-based rack with a Motorola M68020 CPU.
  This VME rack controls all the digital I/O and the 2 small video screens at the left and right side.

• I/O implementation
  With the main control computer outside the StarShip it is almost impossible to run wires for every switch, light, and every segment of a display directly between the StarShip and the main computer system.
  Here is a description of the interface between all components.

• development platform
  A historical tale of the grow path from the early beginnings of this never-ending project to the development methods I am using now.

• software design
  Such a big software project needs some thinking before you start, allthough I must admit that I just plunged into it and learned (or should I say: reviewed my design) as I went along.

• Operating System
  When the things you want to do in software start to get complex or you find that the software looks like a bunch of things (tasks) which do not have a direct relation with each other, it is time for some control mechanism to make life easier.

• start-up control
  When the software is downloaded in the target computer (that is the memory of the main computer of my StarShip), you have a simple option: just run the code. It is called the "big bang" approach. You cross your fingers and hope that the software does what it is supposed to do. The worst condition is a crash of the software, for example a "BUS ERROR".
  An examination of the processor registers gives a good indication where the problems start.
  A more subtle error cause problems later on ... So, you need some scheme to start only a specific part of the software.
  That is where the integrated diagnosys system comes in.

• integrated diagnosys
  I have implemented a separate debugging task with an interface to the Operating System.
  It has its own display (CRT) and keyboard outside the StarShip. You could call it the Simulation Control Console.
  The top area of the display is used to show events like tasks that start or stop. Below that is the biggest area used to show information. Then comes a sort of status line and then comes the area (at the bottom of the screen) to enter commands to the Simulation Control task. The commands can be entered manually or through a softkey interface.

• low-level debugging
  The main computer has a small monitor program in EPROMs that allows several "quick and dirty" tricks.
  Enter breakpoints, examine/change memory locations, trace/step the code and 1-line assembly/disassembly.

• start page
  This links takes you back to the page you are now reading ...