Overview

Credit Management

• The presence of a credit is indicated as long as the relay switch is closed. It will become closed initially, as soon as the coin switch gets triggered, and held closed as long as Q13 receives a high signal on it's base. As soon as the base signal goes to low, the power supply for the relay coil collapses, allowing the relay-switch to open up again.

• As long as the relay switch is closed, the signal line that is directed to UE3:B (NOT-gate) gets pulled to ground, so that the signal coming out of the NOT-gate is high. And of course the other way around.

• That means, that the signal that comes out of UE3:B pin 4 is high, if a credit is present, and low, if no credit is present. That signal on low (no credit) is getting into UG3:B and UG3:A to their (active low) reset pin, holding both states to low, while no credit is present.

• UG3:B is used as a 1-bit memory cell, that momorizes if the machine draws a normal image (1s-level) or an inverted image (extended play/ "Hyperspace")

• UG3:A is used as a 1-bit memory cell, that memorizes if the machine is either in game mode (Q on pin 5 on high) or in attract mode (Qbar on pin 6 on high).

• The signal that comes out of UG3:A pin 6 is used to trigger a credit consumption (whenever the machine state falls back from play mode to attract mode). This signal is going up to the trigger of UH3 (a 74121 monostable multivibrator).

• UH3 is used as a 1-bit memory cell to memorize/indicate if the first credit is already consumed (consumed if Q is going to high)

• UD2:A (7474 flip-flop) is used as a 1-bit memory cell to memorize/indicate if the second credit is already consumed (consumed if its Q is going to high)

• The consumption of UD2:A's credit is either permanently present, depending on, if the 2PlayPerCoinSW is closed or not. The second trigger is Qbar of UH3, which works similar like a counter chain.

• Both Q's (UH3 and UD2:A) are going in the NAND-gate UG2:D, so that if both credits are consumed, the output of UG2:D on pin 11 is pulled low, which will end up on the base of Q13 and interrupt the current flow for the relais coil, allowing its switch to open up again and set the credit-indicator line on low again).

The endurance of the Q signal of UH3 depends on the configuration of the 74121. In this particular case, it is C9 with a default capacitance of 200nF. This configuration results in a Q-signal of approx. 250µs. The relay must have a release-time within this timespan to work properly.

Options for relays:

• SPST Relay, Compac 2187 P/N 150-5, 5V DC Coil (or replacement with similar properties)
• Alternative Relay, SPST, 5V DC Coil, release-time >250µs with increased capacitance on C9 (e.g. 3.5µF for release-time of 3ms)
• Optocoupler replacement
• Bypassing Credit Management by pulling UE3:B pin 3 to ground (bodge wire on UE3:B from pin 3 to pin 7 (gnd), results on an all time present credit). In this case the components UH3, C9, C8, D19, Q13, D15 and the relay are not required and can remain unpopulated (note: as the IC's UD2 and UG2 are hosting additional gates that are used in other context, they are still needed).

Start Conditions

The start conditions are handled by UG2:C and UF2:A

The start is triggered by the StartSwitch and additional conditions are retrieved from UE3:B pin 4 (HI if credit is present) and UG3:A pin 6 (HI if in attract mode).

This means, a new game is initiated when...

• StartSwitch is pressed and released,
• A credit is present and
• Machine is in attract mode

12.6 VAC to 12 VDC Bridge rectifier

The sync-board is just hosting the 12 V rectifier, but has no need for 12 V for its remaining circuitry. 12 VDC are necessary for

• Sound creation on the memory/sound board and
• powering the coin counter

In case a modern switching power supply or a standard PC PSU is used that already provides 12VDC, the whole section is unnecessary and could remain unpopulated.

In that case the external 12 VDC has to be provided to

• Motion/sound board edge connector J3-21
• The coin counter has to be connected to 12 VDC and the sync board edge connector J5-19 (CoinCounter2)

Note: On the sync board, edge connector J5-16 (CoinCounter1) would normaly provide 12VDC (comming from the rectifier) and would not be used in this specific case.

Score/Timer Digits

16x16 Area Check

An array of logic gates uses the horizontal and vertical sync counters as input, to check, if the actual raster position is at a spot, where either a score or a timer digit has to be displayed. It also determines which counters value should be visualized and provides that information as select lines A and B to the multiplexers at UG1 and UF1.

Counter Selection

The two multiplexers at UG1 and UF1 are receiving the 4 bit values of all 4 counters for saucer score, rocket score and timer (units and tenth). It selects the 4 bits of just one counter, depending on the select lines that where provided by the 16x16 area check and forwards the 4 bits of the selected counter to the 7-segment logic section.

7-Segment Logic

The 16x16 area check already determined, that the actual raster position is in the area of a score/timer digit and which counter has to be displayed. The logic gates in the 7-Segment logic group are now determining if the raster position is within that 16x16 area at a pixel location, where a segment of the digit has to be displayed. At it's core, it is the 7448 at UD5 who translates the 4 bit counter value into signals for each segment of the 7-segment display. As a 7-segment display is only capable to properly process values from 0 to 9, values beyond 9 will result in unrecognizable output.

As a result of the circuit design, the digits have a size of 8 (width) by 16 (height) "pixels", with a line width of 2 pixels and are asymmetric along the vertical axis. For the same reasons, there is a space of 8 pixels between the tenth and the units of the timer display.

Test Pattern Generator

A simple XOR-Gate at UA4:D is taking care of creating the test pattern. It derives it's input from the 4th bit of the horizontal and vertical sync counter. As those bits are alternating every 8 counts, this results in an 8 x 8 "pixel" sized pattern.

Side note: The video signal mixer section has two distinct areas, one for normal (non-inverted) display and another one for "Hyperspace" (inverted) display. The test pattern is only provided to and mixed into the non-inverted mixer, so don't expect a test pattern in Hyperspace.

Starfield Generator

The challenge with generating a starfield background is that it should appear random, but not be truly random. With true randomness, there would be no consistent stars between each frame, resulting in very rapid, barely noticeable flickering. It would appear more like faint white noise in the background than a constant background. Side note: If you carefully examine the various gameplay recordings and screenshots available online, it becomes clear that the pattern is identical on every machine and in every game.

This challenge was solved by using constant counting logic between each star for each frame. This is achieved using a counter chain consisting of ED6 and UE6 (both 74161). The trick is that the counting start is initialized by randomly selected bits of the horizontal and vertical synchronization counters (where the bit selection is fixed and determined by the circuit). The random order of these input bits results in different counts/distances between individual stars, depending on the horizontal and vertical synchronization count at the time the starfield generator counter reaches its maximum and is reinitialized. Since the synchronization count starts from the same starting point with each frame, the resulting starfield count repeats in the same way, creating the same pattern for each frame.

Collision Detection

Let's clarify the name convention in the schematics first:

• RocketEnable: the sprite of the rocket is present at the actual location of the raster beam/ sync-counter. The signal is derived from the 4 most significant bits of the rockets horizontal and vertical counter on the motion board and represents an area of 16 x 16 pixels.
• SaucerEnable: one of both saucer sprites is present at the actual location of the raster beam/ sync-counter. The signal is derived from the 4 most significant bits of the saucers horizontal counter and from bits 4, 5, 6 and 7 of the saucers vertical counter on the motion board. Due to the saucers duplication logic, it represents of 16 pixels width and 8 pixels height.
• RocketVideo: at the actual location of the raster beam/ sync-counter a pixel of the rocket sprite is present and has to be displayed
• SaucerVideo: at the actual location of the raster beam/ sync-counter a pixel of one of both saucer sprites is present and has to be displayed.
• RocketMissileVideo: as the missiles have just a dimension of 1 x 1 pixels, this indicate the presence of the rocket missile and is also used to signal the drawing of the missiles pixel.
• SaucerMissileVideo: same as with RocketMissileVideo, just applies for the saucer missile.

Some simple AND gates are used, to check if the shapes (whole sprite area, regardless of an actual pixel) are overlapping at the actual raster position and trigger a collision

• UE2:C pin 10 -> Rocket hit by SaucerMissile
• UE2:D pin 13 -> Saucer hit by RocketMissile
• UE2:A pin 1 -> Rocket with Saucer collision

Collision Execution

Because the conditions that led to a collision detection might be already gone with the next frame, the events have to be memorized for further execution of follow-up activities in some 7474 flip-flops.

• UD2:B -> memorizes Rocket with Saucer collision
• UD3:A -> memorizes Saucer hit by RocketMissile
• UD3:B -> memorizes Rocket hit by SaucerMissile

Follow-up activities triggered by the collision detections are

• Spinning of rocket shape
• Flickering screen (rapid change between normal and inverted image)
• Explosion sound at the memory/sound-board
• Adhancing score counters

The area indicated as Collision Execution consists also of an oscilator circuitry for timing of previos mentioned activities.