Project Goals

High Level

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 development environments.

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 real-time environment.

Details

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 com.pinnovations.pinctrl.

Display

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 the game.
• 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.

Comm

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 at 9600.]

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