Intellivision Master Component Hardware

Figures

Slightly Simplified Block Diagram

Intellivision I Schematic (from Sylvania Service Manual)

Note: This image is courtesy of Frank Palazzolo's 2bits website

Component Overview

System Architecture

The Intellivision Master Component is built around two main data busses, the CPU Address/Data bus and the STIC Address/Data bus. Both busses are time-multiplexed between address and data, and both have a number of specialized control signals associated with them.

System Architecture :: The CPU Bus

The CPU Address/Data bus has 16 Address/Data Lines named DB0 through DB15, and three control lines named BDIR, BC2, and BC1. (Additionally, the active low signals ~BUSRQ and ~BUSAK are available for Direct Memory Access requests. These are discussed later.)

The CPU Bus originates at the CP-1600 CPU, and is directly connected to the 16-bit System RAM, 8-bit Scratchpad RAM, the PSG, the STIC, and the various program ROMs in the system. It does not connect directly to the GRAM or GROM, as these are controlled via the STIC. (Communication between the STIC bus and the CPU bus is described later.)

Because the CPU Bus is time-multiplexed between Address and Data values, it relies on external devices to latch addresses during one bus phase before performing the access in a later bus phase. The value on the BDIR/BC2/BC1 control lines designates the current phase for the CPU bus. As there are 3 control lines, there are 8 bus phases defined. These are described in the following table:

While the table is well and good as a reference, it would be useful to illustrate how these phases are used. Also, the CPU state-flow diagram is very useful for understanding how these bus phases work.

The CP-1600's bus transactions typically last between 4 and 7 CPU cycles. Half of these cycles are NACT cycles, inserted as spacing cycles between the activity cycles. As a general rule, there is a NACT cycle inserted after every cycle EXCEPT in two specific cases. The first is between DW and DWS, which always occur back-to-back. The second is during an indirect access after an SDBD instruction, where the CPU omits NACT states after both DTBs.

The tables below illustrate the various bus transations, complete with a cycle-by-cycle description of the transaction.

System Architecture :: The STIC Bus

The STIC bus is somewhat simpler than the CPU bus. The STIC bus originates at the STIC and extends to the 16-bit System RAM, the 8-bit Graphics ROM, and the 8-bit Graphics RAM. The bus itself is a 14-bit bus which multiplexes address and data in a manner similar to the CP-1600. What's interesting about the STIC bus is that it's used directly by the STIC during active display and indirectly by the CPU during vertical retrace. This will be covered in greater detail in the next section.

The STIC's bus protocol is an extreme subset of the CP-1600's. Rather than provide a 3-wire set of encoded bus controls, the STIC provides 3 decoded bus phase lines, BAR', DTB', and DWS'. Only one of these three lines is asserted at a time, to designate which bus phase the STIC is executing. (The NACT bus state exists when all three lines are de-asserted.) In addition to the bus control lines, the STIC provides three timing lines, SR1, SR2 and SR3 which are used to synchronize various events with respect to display time.

Transactions by the STIC are initiated by cycling the BAR', DTB' and DWS' lines in approximately the same way that the CPU would do so. This is largely due to the fact that the STIC actually can act as intermediary for the CPU in some cases (as covered in the next section.) Nonetheless, there are some important differences:

• There aren't as many NACT cycles introduced by the STIC as there are by the CPU. Rather, DTB' is asserted as soon as BAR' is deasserted.

• During a write cycle, DTB' is momentarily asserted after BAR' until the STIC figures out that it's performing a write cycle. DTB' is deasserted and the STIC goes back to the NACT state before finally asserting DWS for a write.

The STIC bus itself is largely boring. During active display, the STIC is grabbing bits of display data from the System RAM, GRAM and GROM. During vertical retrace, the STIC bus serves as an extension of the CPU bus. This leads us to the next section.

System Architecture :: Bridging the CPU and STIC busses

The System RAM is the key component which glues the STIC and CPU worlds together. Both the STIC and the CPU are bandwidth hogs, requiring unfettered access to large amounts of data. Yet they also need to communicate a great deal. The System RAM makes this possible by acting both as a bridge and as an isolator for the two busses.

The System RAM itself has two busses -- a 16-bit data/address bus on the CPU side and a 14-bit data/address bus on the STIC side. The CPU side bus speaks normal GI bus protocol, using BC1, BC2 and BDIR control signals. The STIC side is much less flexible, serving alternately as a passthrough for the CPU bus in CPU-controlled mode, and as a state-machine-driven character output in STIC-controlled mode.

Outside of active display time, the STIC and System RAM work together to open the STIC bus up to CPU accesses. Upon seeing an INTAK bus cycle, the System RAM enters the so-called CPU controlled mode. In this mode, the System RAM acts as a bidirectional buffer, copying the lower 14 bits of the CPU bus over to the STIC bus in most cases, or from the STIC bus back to the CPU bus during a read. This bridges the two data/address buses. It does not handle the control signals, however.

During the CPU-controlled mode, the STIC performs bus decoding on behalf of the CPU bus, converting the 3-wire GI bus protocol into the decoded signals BAR', DTB' and DWS' mentioned previously. These signals are fed on behalf of the CPU to the GRAM and GROM, thereby allowing the CPU access during this time to all of the peripherals that are on the STIC bus, namely the GRAMs, the GROM, and the STIC itself.

At the start of active display, the STIC issues a ~BUSRQ to the CPU, requesting access to the bus. (~BUSRQ is tied to the SR2 timing signal on the STIC.) The CPU responds after the first interruptible instruction by bringing ~BUSAK low. The System RAM switches to STIC-controlled mode upon seeing the first ~BUSAK high-to-low transition, thereby ending the bus-copying behavior of CPU-controlled mode.

[Note that it is certainly possible that the CPU will not see this ~BUSRQ phase if it is executing too many non-interruptible instructions in a row. In that scenario, the System RAM will remain in bus-copy mode, although the STIC has stopped decoding the bus-control signals for the CPU. The result is that the CPU still cannot access the STIC bus. If the CPU continues to ignore ~BUSRQ during active display, the System RAM will remain in bus-copy mode and CPU will fight with the STIC over the bus. This is bad, as the System RAM and the STIC will both attempt to drive the STIC bus, leading to hardware fights and potential physical hardware failure. Not to mention that the display will be totally garbaged up.]

In STIC controlled mode, the STIC bus side of the System RAM becomes a timing driven entity that is controlled through the SR2 and SR3 timing signals. While in STIC-controlled mode, the System RAM nearly completely isolates the CPU bus from the STIC bus, except when the STIC needs to access the System RAM. This is where ~BUSRQ and ~BUSAK come in to play. It only makes sense, then that the ~BUSAK high-to-low transition (which is essentially a slightly time-delayed SR2 transition) is what causes the System RAM to exit CPU-controlled mode and enter "buffer fill mode" for the STIC.

While ~BUSRQ is active, the SR3 signal is pulsed 20 times to trigger 20 reads to the display memory to read the next row of cards. (The STIC asserts ~BUSRQ for this, because the System RAM is single-ported and can only be read by one device at a time.) This row's worth of values are read onto the STIC bus and into a separate 20 word buffer. Once the row is read into these buffer registers, ~BUSRQ is released and the CPU is allowed to resume calculation. The row buffer is then subsequently read up to 15 more times (again, by pulsing SR3) for each of the scan-lines of the display in order to generate the row of cards on the screen, without disrupting the CPU's progress at all.

It's important to note: ~BUSRQ does steal cycles from the CPU during active display. Some measurements place this penalty at almost 10% during active display. Altogether, there are between 13 and 14 ~BUSRQ's per frame (depending on the setting of the vertical delay register), with each lasting for approximately 110 CPU cycles. A minimum of 60 CPU cycles are required to read the 20 cards from System RAM, based on experimental evidence, which means that a correct program should have no more than about 40 cycles of non-interruptible instructions in a row. The figure below illustrates what a typical frame time looks like.

Timing Diagram Showing SR1 (~INTRM) and ~BUSRQ Timing

Using some simple timing that consist mostly of non-interruptible code, I've measured the following cycle counts for an NTSC Intellivision:

Additionally, I've worked out (with Kyle Davis' help) the following formulas for describing when various events (eg. ~BUSRQ asserted) occur relative to the start of frame. All of these quantities are expressed in raw CPU cycles.

Interfacing

The Master Component interfaces to a variety of external devices, primarily through two sets of external links: the cartridge port and the hand controller ports. Game cartridges and most peripherals connect via the cartridge port, whereas the two hand controllers connect via the hand controller ports.

Interfacing :: The Cartridge Port

The Master Component's cartridge port consists of a single 44-pin 0.1" spacing edge-card connector. A number of essential bus signals are brought out on this connector. The following figures illustrate which of these signals corresponds to each of the various cartridge pins. The table afterwards lists what each signal does.

Pin Mapping On Intellivision Cartridges

The following meanings are assigned to the cartridge port signals:

• Vcc -- +5v Power
  
  
• GND -- Ground
  
  
• RESET -- System Reset
  

  Pulling this line low will send a short reset pulse to the STIC. This will result in ~MSYNC being brought low by the STIC, thereby resetting the machine.

• ~MSYNC -- Master Sync
  

  This signal goes low for at least 10ms during Reset. It is generated by the STIC as soon as the STIC recognizes a low pulse on its RESET line.

• MCLK -- Master Clock
  

  This pin provides the 3.579545MHz master clock signal that drives the Master Component.

• BC1, BC2, BDIR -- Bus Control
  

  These are the bus control signals as described in the CPU sections above. The outputs on pins 38, 40, and 42 come directly from the INTAK remapping circuitry. Cartridges generally loop these signals back on pins 36, 34, and 32. The outputs on pins 37, 39, and 41 are also directly connected to the INTAK remapping circuitry, and are the signals that most Mattel cartridges use for determining the bus phaase.

• DB0 thru DB15 -- Address/Data Bus
  

  This is the 16-bit multiplexed address/data bus.

• ~BUSAK -- BUS AcKnowledge
  

  This signal goes low when the CPU has relinquished the bus during a DMA access by the STIC. It appears possible that external devices can access the PSG, EXEC, and 8-bit RAM during the time ~BUSAK is low, but it's unclear whether this is the case. In all likelihood, it is not the case.

• SR1 -- STIC Timing Signal
  

  This signal is tied to the CPU's ~INTRM input, triggering an interrupt when the STIC goes into the vertical refresh phase.

• CBLNK -- "Character BLaNK" / Horizontal Retrace
  

  Used for genlocking the Keyboard Component's TMS9927 to the Master Component's AY8900 STIC.

• EXT AUDIO -- External Audio Input
  

  The Intellivoice and ECS's second Programmable Sound Generator provide audio input via this pin. I'd imagine if the Keyboard Component can generate Audio, it also provides it on this pin.

• EXT VIDEO -- External Video Input
  

  This was originally designed to accept the genlocked video from the Keyboard Component. The Intellivision II changed the circuit external video output slightly to accept the non-genlocked video from the System Changer. It also moved this to a different pin.

• ??? -- Intellivision special purpose
  

  These pins are tied to ground on non-Intellivoice cartridges, and left open on Intellivoice-aware cartridges.