From: tzs@carson.u.washington.edu (Tim Smith)
Subject: Re: Intellivision questions
Organization: University of Washington School of Law, Class of '95
Date: Thu, 17 Dec 1992 23:52:13 GMT

gkomatsu@uhunix.uhcc.Hawaii.Edu (Galen Tatsuo Komatsu) writes:
>	What are the specs of the Intellivision consoles?

[It's been nearly ten years since I worked with these, so the
 following is all subject to large uncertainty]

CPU
===

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! 

GRAPHICS
========

160x92, I seem to recall.  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.
(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.

SOUND
=====

I don't remember.

OS
==

The operating system did several things:

	It allowed the program to specify a velocity and animation
	sequence 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!

--Tim Smith