2.1 - General Hardware Specs

Intellivision Master Component (these apply to the clones as well)
------------------------------
CPU:            GI 16 bit microprocessor
Memory:         7K internal ROM, RAM and I/O structures, remaining 64k address 
                space available for external programs.
Controls:       12 button numberic key pad, four action keys, 16 direction disk
Sound:          Sound generator capable of 3 part harmony with programmable 
                ASDR envelopes.
Color:          16
Resolution:     192v x 160h pixels

-----
2.2 - Processor Specs

(Author's note: Most of this information was captured off the net two 
years ago, would the original author please speak up and maybe help me 
clean up this info?? =) )

GI 1600, running at something like 500KHz.  Processor has 16
bit registers, uses 16 bit RAM, and has 10 (yes, 10) bit instructions.
Intellivision cartridges contain ROMs that are 10 bits wide.  Ten
bits are called a decle, and half that is a nickle.  There were 160
bytes of RAM, I think (general purpose RAM -- there is also RAM used
by the graphics chip for character bitmaps and to tell what is where
on the screen).

The CPU was strange.  For example, if you did two ROTATE LEFT instructions,
followed by a ROTATE RIGHT BY 2 (rotates could be by one or two), you did
NOT end up with the original word.  The top two bits were swapped!

Ken Kirkby also has this to add:
"The GI CP1600 was developed as a joint venture in the early seventies 
between GI and Honeywell.  One of the first commercial uses of the CP1600 was 
its incorporation into Honeywell's TDC2000, the first distributed control 
system, prototypes existed in late '74 I think. Honeywells then Test 
Instrument Division also incorporated into a Cardiac Catheterisation system 
called MEDDARS which was released for sale about 1979. The CP1600 was 
definitely a 16 bit chip."

-----
2.3 - Graphics Specs

160x92 pixels, 16 colors, 8 sprites (they were called "moving objects" 
rather than sprites).  I don't recall the sprite size -- I think it was 
16x16.  Sprites could be drawn with oversize pixels (I think they could 
be linearly doubled or quadrupled, but again, memory is hazy).

Graphics is character based.  The screen is twelve rows of twenty
characters.  Characters either come from Graphics ROM (GROM), which
contains the usual alphanumeric symbols and a bunch of other things
meant to be useful in drawing backgrounds (256 characters in all),
or Graphics RAM (GRAM), which the program can use to build pictures
needed that aren't in GROM (like sprite images).  GRAM can hold 64.
The predesigned sprites located in ROM were a big help in speeding up
gameplay.  (Now that I think about it, maybe sprites were 8x16 -- I 
don't recall them taking up 4 pictures in GRAM -- but two seems 
reasonable).

Eight of the colors are designated as the primary colors.  The other
eight are called the pastel colors.

There were two graphics modes: Foreground/Background, and Color Stack.
In F/B mode, you specify the colors for both the on and off pixels of
each card ("card" is the term for a character on the screen).  One of
these (the on pixels, I think) could use any color, but the other could
only use the primary colors.

In CS mode, you can give the chip a circular list of four colors (pastels
and primaries are both allowed).  For each card, you specify the ON bits
color from any of the 16 colors, and the OFF bits color comes from the
next color on the circular list.  You can also tell if the list is to
advance or not.  Thus, in CS mode, you only get four colors for the OFF
bits, and they have to be used in a predetermined order, but you get to
use the pastels.  Most games used CS mode.

I seem to recall that a sprite could be designated as either being in
front of or behind the background, which determined prority when it
overlapped the ON pixels of a background image.

You could tell the graphics chip to black out the top row or the first
column (or both) of cards.  You could also tell it to delay the display
by up to the time of seven scan lines, or to delay the pixels on each
scan line by up to seven pixel times.  Using these two features together
allows for smooth scrolling.

For example, a game that is going to scroll a lot sideways could black
out the first row.  Now, to scroll the background to the right by one
pixel, you just have to delay by one pixel time.  This moves everything
over.  The black part is NOT delayed -- that is always displayed in the
first 8 screen pixel locations.  The net result is that you now see one
pixel that was previously hidden under the black strip, and one pixel on
the other side has fallen of the edge, and everything appears to have
moved over.  Thus, to scroll, you only have to move the screen memory
every eigth time, when things need to be shifted a full card.  There is
no need for a bitblt-type operation.

The hardware detected collisions bewteen sprites and other sprites or
the background.

GRAM and (I think) screen memory could only be manipulated during
vertical retrace.  At the end of vertical retrace, you had to tell
the chip if it should display or not.  If you weren't done, you
could keep manipulating by not telling it to display, but then
you end up with a flicker.  Unacceptable.

-----
2.4 - Operating System Specs

The operating system did several things:

        - It allowed the program to specify a veloc for each sprite.
        The OS would deal with adjusting the sprite position registers 
        for you and cycling through your animation sequence.

        - For each pair of sprites you could specify a routine to be
        called when that pair of sprites collided.  For each sprite,
        you could specify a routine to be called when that sprite
        hit the background or the edge of the screen.

        - It maintained timers, and allowed you to specify routines to
        be called periodically.

        - It dealt with the controls.  You could specify routines to be
        called when the control disc was pressed or released, or when
        buttons were pressed or released.  It provided functions to
        read numbers from the keypad.  The calling sequence for these
        were a bit strange.  When you called these, they saved the return
        address, then did a return.  You had to call them with nothing
        after your return address on the stack, and they return to your
        caller.  When the number is ready, they return to after where
        you called them, but as an interrupt.  In generic assembly, it
        would be like this (I've long since forgotten 1600!):

                jsr     foo
        bar:
                ...
                ...
        foo:    ;do some setup or whatever
                jsr     GetNumberFromKeypad
        spam:   ...

        GetNumberFromKeypad returns to bar immediately.  When the number
        is read, spam will be called from an interrupt handler.  If you
        didn't know that a routine did this, reading code could get
        rather confusing!

--------------------------------------------------------------------------

John Bindel             (jbindel@cs.tamu.edu)
James Carter            (jscarter@aol.com)
Greg Chance             (gchance@ecst.csuchico.edu)
Jeff Coleburn           (vsp@netaxs.com)
Clint Dyer              (apdf35d@prodigy.com)
Allan Hammill           (warspite@ix.netcom.com)
Ed Hornchek             (edh@netcom.com)
Joe Huber               (huber@rock.enet.dec.com)
Jerry Greiner           (jerryg@hevanet.com)
Sean Kelly              (skelly@bbs.xnet.com)
Ken Kirkby              (kirkby@decus.org.au)
Ralph Linne
Matthew Long            (mlong@ccd.harris.com) 
Craig Pell (VGR)        (vgriscep@wam.umd.edu)
Russ Perry Jr.          
Robert Poniatowski      (pony@shakala.com)
David Tipton            (6500dtpt@ucsbuxa.ucsb.edu)
Paul Thurrott           (thurrott@ix.netcom.com)
Steven Roode            (ANA-NG@ix.netcom.com)
Joe Santulli            (digitpress@aol.com)
Laury Scott
Lee K. Seitz            (lkseitz@iquest.com)
Chris Williams          (psu01940@odin.cc.pdx.edu)
Jeremy Wilson           (xeno@io.org)