Was The CP16xx Series Processor 8 Or 16 Bit. The Data Sheet Says 16-Bit, But I Thought The Intellivision Was 8-Bit. This Probably Will Not Get Too Many Replies Seeming As Its A Less Known Processor

Check out the CP1600 datasheets on bitsavers.org. The Intellivision wiki indicates that the processor was a 16-bit processor with some relation to the PDP-11 16-bit minicomputers from DEC. The linked datasheet supports that claim. (The schematics for a design based on the CP1600 is also provided.)

The reference material linked also refer (interestingly) to the Programmable Interface Controllers which are the ancestors of the Microchip PIC16xx processors.

Wikipedia has a short article on the CP1600 at http://en.wikipedia.org/wiki/General_Instrument_CP1600 . I have an old General Instrument data book that has the 1610 and it's clear it has a 16-bit data bus.

Where is the address bus on this thing ? It seems hard to do address decoding

My book just has a few pages on it, not a really complete datasheet; but what I get from a quick look is that D0-D15 is not just for data but also outputs the address. The BDIR, BC1, and BC2 pins tell what the bus is doing at the moment. The address is put on the bus, latched and sent to address-decoding circuitry and memory, and then D0-D15 turn back into a data bus.

Does anyone have a datasheet for the CP1600. I have searched, and this is all I can find: http://bitsavers.trailing-edge.com/pdf/ ... _May75.pdf I need something smaller that just goes over the most important processor things.

Try http://spatula-city.org/~im14u2c/intv/i ... cp1600.txt
There are also docs in this SDK http://sdk-1600.spatula-city.org/
(But if you have a document with more than you need, that seems like a nice problem to have.)

Hi, James. I had a look at the pdf you linked to, and found it less than lucid. But the CPU itself certainly has some wrinkles that caught my interest! Its registers and its multiplexed address/data bus are 16 bit, but its instruction opcodes are only 10 bit! (The other 6 bits are unused and Reserved.) Furthermore, there's a software mechanism that allows limited 16-bit functionality using 8-bit memory! And the ALU is 8-bit, presumably breaking down each 16-bit operation into two internal 8-bit operations.

From the pdf I'm posting the CPU block diagram. See pg 43 of the pdf for the Instruction Description. I'm also including an excerpt from the first of the two documents Ed linked to.

cheers,
Jeff

From what I have seen, Spatula City is more or less targeting the Intellivision

My only two problems now are as follows: 1) Is this too complex of a processor for me to work with
2)What is the chance of me finding one of these chips and a substantial amount of peripherals for it

Howdy!

I found this thread while Googling about for CP1600 / CP1610 information. I am indeed the owner of Spatula City, and yes, I am largely focused on the Intellivision by default. However, my day job is as an embedded CPU / SoC architect, and as a hobby I'm a bit of an amateur computer architecture historian. After nearly 20 years in this business, I'm convinced there's very little that's truly new, and plenty to learn studying the old.

If anyone here does find information about other GI peripherals related to the GIMINI family, I'd love to hear about it. This certainly is a fascinating processor.

The CP1610 isn't a difficult CPU to program. Interfacing might be a shade tricky owing to its multiplexed bus, and the fact it needs several voltages coming to it. Indeed, what brought me here this evening was idle curiosity about the clock-driver circuit in the Intellivision schematic. ( Schematic here: http://spatula-city.org/~im14u2c/intv/tech/images/schematic.png The relevant portion is the cluster of diodes, the pair of 2N3906s and the 7407 feeding into the phi1/phi2 inputs, all in the upper left portion of the schematic. )

I've made several circuits that interface to its bus. It's not terribly difficult to demux the bus and treat it like other processors that have a demux'd bus. The so-called "Osborne Book" has a good chapter on the CP1600 and even offers a circuit for demuxing the bus on page 26. This directory offers a page-by-page scan of the relevant chapter: http://spatula-city.org/~im14u2c/chips/cp1600_osborne/

Some caveats on the Osborne book: The circuit offered doesn't correctly comprehend the ADAR bus phase. But, it really isn't complicated. The GI protocol is simple for most memory accesses:

• Each peripheral or bus demuxer has an Address Register
• The BAR and ADAR bus phases put the value on the bus into everyone's Address Register at the end of the bus phase
• The DTB and ADAR bus phases instruct the currently addressed peripheral to put its data on the bus at the start of the bus phase, holding it until the end of the bus phase.
• The DW/DWS bus phases indicate a write. The write data is stable just before the end of DW until near the end of DWS. In a modern circuit, just snapshot data on the DW/DWS transition.
• The CPU sprinkles NACT (no action) bus phases liberally. In particular, you'll reliably have a NACT after BAR, ADAR, and DWS. (Not so for DTB.)

Notice that ADAR shows up in two places: It acts like DTB at the start of the cycle, but like BAR at the end. The ADAR bus phase supports direct-mode addressing, and saves a round-trip through the CPU. For example, if someone writes:


This assembles to the two words: 0280 1234. Suppose that instruction is at locations $A000 - $A001 in the following example.

The actual bus phases the CPU goes through to execute the instruction above are as follows:

• Cycle 1: CPU issues BAR. CPU puts address of MVI opcode ($A000) on bus by the end of the bus phase.
• Cycle 2: CPU issues NACT.
• Cycle 3: CPU issues DTB. The addressed memory (eg. a ROM or a RAM somewhere) responds with the opcode of MVI. CPU samples opcode near the end of the bus phase.
• Cycle 4: CPU issues NACT.
• Cycle 5: CPU issues BAR. CPU puts address of the MVI direct address argument ($A001) on the bus by the end of the bus phase.
• Cycle 6: CPU issues NACT.
• Cycle 7: CPU issues ADAR. The addressed memory (eg. ROM/RAM somewhere) responds with $1234. The key piece: All peripherals sample $1234 into their Address Registers at the end of the bus phase.
• Cycle 8: CPU issues NACT.
• Cycle 9: CPU issues DTB. The newly addressed memory (whatever is at $1234) responds with its data. The CPU samples this data near the end of the bus phase to move it to R0.
• Cycle 10: CPU issues NACT.

So that's the ADAR bus phase. Not really complicated, but also not explained well at all in the docs.

The observant will notice I've left out two bus phases: INTAK and IAB. INTAK acknowledges an interrupt, but otherwise acts as a BAR. In fact, the Intellivision remaps INTAK to BAR. (See the computation of BC1_OUT, BC2_OUT, BDIR_OUT in the top-center of the schematic linked above.)

IAB, though, requires direct support from your circuitry, if you plan to use interrupts. The CPU doesn't have a fixed interrupt or reset vector. Rather, it issues an IAB bus phase, and expects some peripheral on the bus to respond with an address. The first address after reset should be the reset vector. After that, it should be the interrupt vector. In the Intellivision, the EXEC ROM actually responded to IAB, providing the reset vector (0x1000) and interrupt vector (0x1004).

Anyway, if you do pursue something with the GI CP1600 / CP1610, I'd love to hear about it, even just to be a fly on the wall. In terms of acquiring one: If you get an Intellivision 1, the CPU is socketed in most of them. So, you could pop it out, do whatever you like, and then pop it back in later if you tire of it.

I looked into the CP1610 when the subject was originally raised. It is certainly an interesting implementation. The "transfer" of addresses from the the data bus to the address register/bus is an interesting solution. It would not be possible without the use of a multiplexed bus. In our current headlong race for more speed, some of the advantages of a multiplexed bus, namely the reduction of the number of I/O pins required, are lost. Your description of this action by the CP1610 highlights a particular benefit of a multiplexed bus.

I too agree that there is virtually nothing new in computer architecture today. I scrounge around on bitsavers.org, and find some real architectural gems that have been forgotten but which are still applicable today.

Thanks for your post.