This project is being undertaken to control a wired Gottlieb 1979 Solar Ride playfield
via electronics under PC control. Game logic (rules and actions) will be controlled
by code running on a Windows PC.
The PC will communicate with one or more micro controllers (PICs) via a
PC serial port.
Ideally the cost of the PICs and other electronics will be kept as low as possible,
with as many off-the-shelf parts used as possible. This represents a trade-off
(cost/ease of construction).
The end result of the project will be to then apply knowledge and techniques
obtained for building arbitrary home games (with new playfield designs).
The PIC code will hopefully only require minor modifications when migrating
from one game to another, with most of the emphasis being on developing the
game rules on a PC using familiar/traditional programming languages and
A reusable PC programming API will be created to make this task easier.
The design of the hardware and interaction between controllers and the
PC will be such that the relatively poor real-time environment provided by
the PC operating system will not greatly impact the overall real time performance
of the game.
In other words we strive for real-time performance from a non
Java Control Code
The game will be controlled via a Java "operating system" running
on Windows. In theory it should be fairly easy to run this on Solaris or Linux also.
All Java packages for the project exist under the root of
The display used for outputting the score and information will be a standard
Windows window on the PC-attached monitor. Java Swing will be used for this
display. At time of writing the essence of the display code is written.
A JFrame-based window of size 760 by 570 (e.g. for an 800 x 600 resolution)
will be used [Not finalized - may just go full screen.].
There will be 4 fixed areas of the display:
- Title area – at the top, sized 760 x 100. Just shows the game name.
- Message area – at middle left, sized 500 x 400, displays any messages required during
- Image area – at middle right, sized 260 x 400, shows a bitmapped image, such as
the Solar Ride playfield or backglass. Can be dynamically updated with useful
hints overlaid on the playfield image.
- Score area – at bottom, sized 760 x 70. Shows the player number (or name), score and ball in play (or game over).
Rudimentary text features such as text blinking and scrolling can occur in the
message area. The message area and score area together are akin to the DMD
display in modern pins.
All serial port communications code resides in the comm package. We use the
Sun serial port driver code. We will send messages at 2400 baud (8N2) to the
master micro controller (Basic Stamp 2 or BS2).
Testing has revealed that this is the best communication rate we will
get from the BS2. With a BS2sx module, we can probably communicate at 4800 or 9600.
[2400 was reliable with the BS2 but no higher. Eventually switched to a faster
BS2p24 stamp and it works reliably at 4800. I can't recall if there was a problem
Additionally, an RS232 line driver chip, the MAX232 (actual chip used
is the Sipex232ACP) is being used to provide reliable voltages to the serial
port. It also allows us to use independent hookups to the port for development
time downloading and run time communications.
A simple compact protocol of commands and responses has been created. All
commands implement the Command interface and all responses implement the
Response interface. There is one concrete class for each controller
type (master, lamp, switch, relay). Each controller type will have different bit assignments and addresses for their commands. Otherwise the format of all commands and responses is common.
We will have 3 modes of command/response:
- Send, with definite synchronous response.
- Send with no response.
- Asynchronous unsolicited responses.
The definite response type will be used in non real time situations, such as
when the version level of a micro controller is requested at program initialization.
Response timeout values can be used.
Sending with no response will be done for real time commands in which there
is no data expected back. For example, firing a coil does not generate any
inherent response data. Of course, the micro controller may have a problem
and generate a response with a return code indicating the problem.
[Used by the majority of commands.]
Asynchronous unsolicited responses will mostly come from the switch
controller, which will send back the switch matrix state when switch
open/close events occur.
A response queue is implemented in the control program via class
ResponseQueue. If the Java code for some reason is slow or delayed in
processing responses from the switch controller (for example) then they
will be queued and processed. This will hopefully prevent switch events
from being lost, while at the same time not burdening the micro controller
with having to buffer data in its limited RAM space.
The response queue code implements a FIFO queue, with a priority provision
so that high priority switch matrix messages can be handled first.
End of the original document. Many details missing based on the experience of
implementing the project. Hope to add this later.
Last updated: September 26, 2008