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)