INTV clock

[decle]

Morning,

 

Everyone knows that the NTSC INTV is clocked at 3.58MHz which is divided by 4 to give a machine cycle of 894KHz + change.

 

Except of course it isn't. The 7.16MHz crystal clocks the AY-3-8915 which divides it by 2 to clock the STIC at 3.58MHz. The STIC then generates the main system clocks 01 and 02. So the STIC divides the 3.58MHz NTSC clock by 4 generating 894KHz?

 

The CP1610 data sheets seem to suggest that machine cycles (or ucycles) are 2 clocks 01 / 02 periods in length (http://www.avoidspikes.com/dsplib/chips/cp1610.pdf top of page 9-27). I believe that Joe and others have established through cycle counting that the machine cycle is 894KHz. So does this mean that the CP1610 and the rest of the INTV is clocked at 1.788MHz which is then divided by 2 internally? The minimal STIC datasheets don't seem to describe the clock generation behaviour. And while we are at it, what is the little cluster of discrete components at the top left of the schematic (http://spatula-city.org/~im14u2c/intv/tech/images/schematic.png) doing to the clock inputs to the CP1610?

 

Just askin'

 

 

decle

 

 

[intvnut]

There's a cryptic footnote in the GI docs: "1 microcycle = 2 clock cycles." The clock cycle they're referring to there is the ϕ1 / ϕ2 that drive the CPU. The microcycle, OTOH, is what us programmers here have generally referred to as a "clock cycle", as that's what the instructions are counted in.

 

So:

• 7.16MHz crystal drives AY-3-8915. It divides by 2 for the STIC.
• 3.58MHz at the STIC, divides by two, giving 1.79MHz ϕ1 and ϕ2 signals for the CPU. These are non-overlapping clocks that are 180° out-of-phase.
• 1.79MHz at the CPU cycles the processor through four phases, TS1 through TS4, that form one microcycle.
  • This is highlighted in the diagram at the top of page 9-27, with the arrows showing "1μ CYCLE."
  • TS1 and TS3 happen while ϕ1 is high; TS2 and TS4 happen while ϕ2 is high.
  • So, two periods of ϕ1 (or ϕ2) form a full microcycle.
• The resulting microcycle rate is 895kHz.

You could argue, then, that the CP-1610 is actually a 1.8MHz (or 2MHz on PAL), rather than 895kHz/1MHz, but then you'd also have to double all the cycle counts in the cycle count chart. The cycle count chart is in terms of microcycles.

 

But, the last time I think I ever heard anyone say "microcycle" out loud was in this movie:

 

Edited May 25, 2016 by intvnut

[intvnut]

As for what those circuits are doing: They're sending in the clocks at a whopping 11V or so... Those clocks are driving a lot of circuits, so I imagine the high voltage is to charge that capacitance quickly.

 

The 7407s are open collector drivers, which mean they can pull down, but not drive upward. (The TI data sheet I have for the 7407 suggests they can pull down something like 30mA - 40mA.) The transistor part of the circuit pulls the voltage up to around 11V when the 7407 isn't pulling down to ~0.4V. (The schematic says 5.6V, but I believe that's the average voltage. The data sheet says the ϕ1 / ϕ2 voltage must be in the range 10V to V_DD, and V_DD is 12V.)

 

I don't fully understand the principle of operation of the transistor part of the circuit; but I understand what the goal is.

Edited May 25, 2016 by intvnut

[decle]

Cheers Joe, totally clear.

 

It is interesting that the 3.58MHz & 895KHz numbers have come to dominate the descriptions of the INTV, rather than any of the others. I guess this is a effect of the system description of the BSR page.

 

1.79MHz is a number which is equivalent to the 1MHz, 2MHz or 4MHz normally quoted for the 6502 or Z80. It is also the equivalent to the number quoted on GI datasheets.

 

The reason I asked is that the CP1600 page on wikipedia (https://en.wikipedia.org/wiki/General_Instrument_CP1600) rather misleadingly suggests that the CP1610 is a "detuned" CP1600 running at 894KHz. Whereas the frequencies quoted for the CP1600 are 3.3MHz and 5MHz. In reality for these numbers to be comparable I believe that the 1.79MHz (or 2MHz for the PAL Intellivision) should be quoted. So whilst the CP1610 may be detuned it is not as significant as the page currently implies.

 

I also find it interesting that it is not the clock rate that knocks the throughput of the CP16x0 processors, but rather the effective divide by 16 that you get from the clock rate to average instruction rate.

 

decle

 

[intvnut]

One last detail on that clock driver circuit. The data sheet says that the clock capacitance is as much as 30pF, and the rise/fall times are 15ns. That works out to an average current of 20mA during the swing. The peak current would be higher, naturally. That's a pretty significant switching current though.

 

And this is insanely cool: I was able to ask Google that, with units, and it worked it out for me...

[intvnut]

Cheers Joe, totally clear.

 

It is interesting that the 3.58MHz & 895KHz numbers have come to dominate the descriptions of the INTV, rather than any of the others. I guess this is a effect of the system description of the BSR page.

 

1.79MHz is a number which is equivalent to the 1MHz, 2MHz or 4MHz normally quoted for the 6502 or Z80. It is also the equivalent to the number quoted on GI datasheets.

 

The reason I asked is that the CP1600 page on wikipedia (https://en.wikipedia.org/wiki/General_Instrument_CP1600) rather misleadingly suggests that the CP1610 is a "detuned" CP1600 running at 894KHz. Whereas the frequencies quoted for the CP1600 are 3.3MHz and 5MHz. In reality for these numbers to be comparable I believe that the 1.79MHz (or 2MHz for the PAL Intellivision) should be quoted. So whilst the CP1610 may be detuned it is not as significant as the page currently implies.

 

I also find it interesting that it is not the clock rate that knocks the throughput of the CP16x0 processors, but rather the effective divide by 16 that you get from the clock rate to average instruction rate.

 

decle

 

 

You're right that it should probably be quoted as 1.79MHz / 2MHz rather than 895kHz / 1MHz, as that's more in line with what the data sheets say.

 

The TS1/TS2/TS3/TS4 are somewhat analogous to T cycles on a Z80, and a CP-1610 microcycle is roughly analogous to an M cycle on Z80. One difference is that the Z80 has a variable number of T cycles per M cycle, while on the CP-1610, there's always four TS states per microcycle. Also, the states TS1/TS2/TS3/TS4 correspond to the peaks of ϕ1 and ϕ2 (so you get all four TS states in just 2 clock cycles) while each of the T cycles on the Z80 is a full clock period.

 

In contrast, a 6502 really just has 2 states, ϕ1 and ϕ2. It moves through some number of T states for each instruction; as few as 2, and as many as 7. But, I'd argue it lacks the two-level structure to its timing that the CP-1610 and Z80 have. All of the 6502 cycle counts are in terms of ϕ1's clock rate.

 

So, in terms of how fast you proceed through machine cycles, a 3.3MHz Z80, 2MHz CP-1610 and a 1MHz 6502 all move through machine cycles at about the same rate. (I say 3.3MHz for Z80, as most M cycles are 3 T cycles, but some are 4.)

 

And then there's strange birds like the TMS9900, with four-phase clocking... (ϕ1, ϕ2, ϕ3, and ϕ4!)

[intvnut]

Two things really kill the CP-1610 performance, FWIW:

• Double-pumped 8-bit data path. Nearly every cycle is followed by a NACT cycle, and I suspect it's the double-pumped nature.
• Multiplexed address/data bus. Every access to the outside world is two bus cycles (each with a NACT).

Those two together give a factor of 4 slowdown on nearly everything. The only bus cycles that aren't followed by a NACT are during SDBD reads.

 

(Although, fun fact: The Z80 is a double-pumped 4-bit data path...)

Edited May 25, 2016 by intvnut

[carlsson]

Speaking of the TMS9900, a while ago there was thread in that subsection of the forum, linking to a site trying to calculate MIPS for various processors. Now we can agree that MIPS says very little about computational strength, and the guy handling the website hasn't even come to calculate or benchmark the CP16x0 yet.

 

http://drolez.com/retro/

http://atariage.com/forums/topic/250055-mips/

[+DZ-Jay]

 

One last detail on that clock driver circuit. The data sheet says that the clock capacitance is as much as 30pF, and the rise/fall times are 15ns. That works out to an average current of 20mA during the swing. The peak current would be higher, naturally. That's a pretty significant switching current though.

 

And this is insanely cool: I was able to ask Google that, with units, and it worked it out for me...

google_calc.png

 

 

LOL! You think that's impressive? I've been using Wolfram Alpha for years to do things like that.

 

[intvnut]

Ah... I could spend way too much time in that thread. I won't, though. The TMS9900 runs reasonably well if given 0WS 16-bit RAM, and falls off quickly if it isn't. The TMS9995 really cleaned up the performance.

 

In the end, MIPS isn't a great measure, but rather μsec required per task. That's the benchmark TI itself used, because comparing cycle counts just never cut it.

 

Here's a fun document comparing TMS9900, TMS9995, TMS99000 (also called "Alpha" in the docs), 8086, Z8000 and 68000, from the TMS99000 architect Karl Guttag.... http://spatula-city.org/~im14u2c/vdp-99xx/e1/99000_(Alpha)_Misc_Documents.pdf

Edited May 25, 2016 by intvnut

[intvnut]

 

LOL! You think that's impressive? I've been using Wolfram Alpha for years to do things like that.

 

volts.png

 

I suppose I shouldn't be impressed. I could do that 25 years ago on an HP-48SX, and even then it was old hat.

 

 

...not to mention https://en.wikipedia.org/wiki/Antikythera_mechanism

Edited May 25, 2016 by intvnut

[+DZ-Jay]

 

I suppose I shouldn't be impressed. I could do that 25 years ago on an HP-48SX, and even then it was old hat.

 

Cleveland-Institute-515-T-Slide-Rule-1.jpg

 

...not to mention https://en.wikipedia.org/wiki/Antikythera_mechanism

 

I was just saying it because people have a tendency to attribute to Google some clever technologies that are common in other software platforms, just because Google is all they use and that's all they've seen. But, OK, your dick is bigger than mine, I guess.

 

I do like that Wolfram Alpha breaks it down and gives you a bunch of additional useful information besides the answer, such as context domain, comparable quantities in other common units, corresponding measurements, etc.

 

-dZ.

[+DZ-Jay]

I do have one topical question: when you are talking about the effective clock speed of the CP-1610 and microcycles and all that, aren't those specific to its application in the Intellivision?

 

I mean, if you remove the STIC and the need to break the cycle into phases to drive the shared bus arbitration, wouldn't the CP-1610 run faster? Or are those aspects intrinsic to the CPU functionality?

 

-dZ.

[decle]

I do have one topical question: when you are talking about the effective clock speed of the CP-1610 and microcycles and all that, aren't those specific to its application in the Intellivision?

 

I mean, if you remove the STIC and the need to break the cycle into phases to drive the shared bus arbitration, wouldn't the CP-1610 run faster? Or are those aspects intrinsic to the CPU functionality?

 

-dZ.

 

As with all good questions I think the answer is yes and no. The choice of 1MHz and 894KHz as the machine cycle rate on the PAL and NTSC Intellivision respectively is driven by the timing of the respective TV standards. According to the CP1610 data sheet (http://www.avoidspikes.com/dsplib/chips/cp1610.pdf page 9-26) the clock period can be selected from 0.5 to 2 microsecs. Using the information Joe provides above (divide by 2 to get machine cycles), this implies machine cycle rates of between 250KHz and 1MHz. So the PAL INTV is the upper end of the specification of the silicon.

 

However, the CP1610 is one of several versions in the CP16x0 range. There are datasheets of the generic part the CP1600, for example

 

https://archive.org/details/bitsavers_giCP1600CPsersManualMay75_9917417(section 2.4)

http://spatula-city.org/~im14u2c/chips/GICP1600.pdf(page 1)

 

which suggest that some versions can be clocked as fast as 5MHz, which would imply machine cycle rates as high as 2.5MHz. This would probably bring the CP1600 into the same ballpark as the 6502 and Z80 in terms of real world performance. I still don't think it would match these CPUs on instruction throughput, but the greater flexibility of its architecture stands a chance of making up the difference.

 

Would such a part be usable within an INTV framework? Well as you suggest you would need to disconnect the STIC as the clock source for the CP1600 and other ancillaries such as the System RAM and ROMs. I think the problem would probably be the System RAM, which bridges the CPU and STIC buses. The STIC would still be bound by the TV signal timing and merrily ticking at a machine cycle frequency of 895KHz. I suspect the bridge in the System RAM would not take kindly to one side running faster than the other, but Joe would be better placed to comment.

 

If you wanted to use a faster CPU within the INTV I suspect it would be easier to replace the CP1610 with a daughterboard with a CPU, cache RAM and glue, much like the Amiga and Mac accelerators did. That way the rest of the system could clock along at the normal pace, but interactions between the TurboCPU and the cached RAM could be much faster. Obviously the CPU would need to wait if a cache miss occurred; and the cache would need to be set up to not store volatile addresses like STIC or other support chip registers.

 

These days, rather than using a real CP1600 (which I imagine are rarer than rocking horse do-do), it should be possible to build such a daughterboard using a single microcontroller or FPGA, with appropriate level switching logic. Of course then you could also change other things, like the number of registers, make the ALU 16bit rather than 8bit, add the annoyingly missing instructions, like OR, reduce the number of NACT cycles on the bus... Along a similar line it is also probably possible to create a SuperSTIC. Make use of those 2bits at the top of every BACKTAB card to display all the colours in FB mode. Or do any number of other funky things. Definitely scores high on the interesting if pointless scale.

 

decle

[decle]

Two things really kill the CP-1610 performance, FWIW:

• Double-pumped 8-bit data path. Nearly every cycle is followed by a NACT cycle, and I suspect it's the double-pumped nature.
• Multiplexed address/data bus. Every access to the outside world is two bus cycles (each with a NACT).

Those two together give a factor of 4 slowdown on nearly everything. The only bus cycles that aren't followed by a NACT are during SDBD reads.

 

(Although, fun fact: The Z80 is a double-pumped 4-bit data path...)

 

Hilarious, I had assumed the 8bit ALU was an error on the datasheet. And I did not know that the Z80 had a 4 bit ALU, learn something new every day.

 

decle

[decle]

 

Hilarious, I had assumed the 8bit ALU was an error on the datasheet. And I did not know that the Z80 had a 4 bit ALU, learn something new every day.

 

decle

 

Even better, chatting with a colleague about this little Z80 factoid, he said he had always wondered how they did the half carry. Now it makes perfect sense.

[+DZ-Jay]

 

As with all good questions I think the answer is yes and no. The choice of 1MHz and 894KHz as the machine cycle rate on the PAL and NTSC Intellivision respectively is driven by the timing of the respective TV standards. According to the CP1610 data sheet (http://www.avoidspikes.com/dsplib/chips/cp1610.pdf page 9-26) the clock period can be selected from 0.5 to 2 microsecs. Using the information Joe provides above (divide by 2 to get machine cycles), this implies machine cycle rates of between 250KHz and 1MHz. So the PAL INTV is the upper end of the specification of the silicon.

 

However, the CP1610 is one of several versions in the CP16x0 range. There are datasheets of the generic part the CP1600, for example

 

https://archive.org/details/bitsavers_giCP1600CPsersManualMay75_9917417(section 2.4)

http://spatula-city.org/~im14u2c/chips/GICP1600.pdf(page 1)

 

which suggest that some versions can be clocked as fast as 5MHz, which would imply machine cycle rates as high as 2.5MHz. This would probably bring the CP1600 into the same ballpark as the 6502 and Z80 in terms of real world performance. I still don't think it would match these CPUs on instruction throughput, but the greater flexibility of its architecture stands a chance of making up the difference.

 

Would such a part be usable within an INTV framework? Well as you suggest you would need to disconnect the STIC as the clock source for the CP1600 and other ancillaries such as the System RAM and ROMs. I think the problem would probably be the System RAM, which bridges the CPU and STIC buses. The STIC would still be bound by the TV signal timing and merrily ticking at a machine cycle frequency of 895KHz. I suspect the bridge in the System RAM would not take kindly to one side running faster than the other, but Joe would be better placed to comment.

 

If you wanted to use a faster CPU within the INTV I suspect it would be easier to replace the CP1610 with a daughterboard with a CPU, cache RAM and glue, much like the Amiga and Mac accelerators did. That way the rest of the system could clock along at the normal pace, but interactions between the TurboCPU and the cached RAM could be much faster. Obviously the CPU would need to wait if a cache miss occurred; and the cache would need to be set up to not store volatile addresses like STIC or other support chip registers.

 

These days, rather than using a real CP1600 (which I imagine are rarer than rocking horse do-do), it should be possible to build such a daughterboard using a single microcontroller or FPGA, with appropriate level switching logic. Of course then you could also change other things, like the number of registers, make the ALU 16bit rather than 8bit, add the annoyingly missing instructions, like OR, reduce the number of NACT cycles on the bus... Along a similar line it is also probably possible to create a SuperSTIC. Make use of those 2bits at the top of every BACKTAB card to display all the colours in FB mode. Or do any number of other funky things. Definitely scores high on the interesting if pointless scale.

 

decle

I see that you misunderstood my question. You have confirmed that this entire conversation is focused on the capabilities of the Intellivision and predicated on having to connect the CP-1610 to a TV-capable device.

 

I don't think this is necessarily intrinsic to the CPU. Or are you suggesting that the CP-1610 is only usable in such an application domain?

 

-dZ.

[decle]

I see that you misunderstood my question. You have confirmed that this entire conversation is focused on the capabilities of the Intellivision and predicated on having to connect the CP-1610 to a TV-capable device.

 

I don't think this is necessarily intrinsic to the CPU. Or are you suggesting that the CP-1610 is only usable in such an application domain?

 

-dZ.

 

Ahh, sorry. As you say I misunderstood. The CP1610 is a general purpose CPU and could be used anywhere. There are some features which make it more difficult, and therefore expensive, to use with general memory and peripherals. Notably the multiplexed bus and the need to have an external device initialise the program counter on reset and interrupts. But it is all totally doable. At which point you would have complete freedom to choose the clock frequency within the constraints of the silicon. So up to 2MHz clock (1MHz machine cycle) for the CP1610 and 5MHz (2.5MHz machine cycle) for the CP1600. However, the 2:1 ratio between the 01/02 clock frequency and the machine cycle rate is fixed and intrinsic to the silicon.

 

Have I understood the question this time?

 

decle

Edited May 25, 2016 by decle

[+DZ-Jay]

 

Ahh, sorry. As you say I misunderstood. The CP1610 is a general purpose CPU and could be used anywhere. There are some features which make it more difficult, and therefore expensive, to use with general memory and peripherals. Notably the multiplexed bus and the need to have an external device initialise the program counter on reset and interrupts. But it is all totally doable. At which point you would have complete freedom to choose the clock frequency within the constraints of the silicon. So up to 2MHz clock (1MHz machine cycle) for the CP1610 and 5MHz (2.5MHz machine cycle) for the CP1600. However, the 2:1 ratio between the 01/02 clock frequency and the machine cycle rate is fixed and intrinsic to the silicon.

 

Have I understood the question this time?

 

decle

Thanks! Very useful.

[decle]

Two things really kill the CP-1610 performance, FWIW:

• Double-pumped 8-bit data path. Nearly every cycle is followed by a NACT cycle, and I suspect it's the double-pumped nature.
• Multiplexed address/data bus. Every access to the outside world is two bus cycles (each with a NACT).

Those two together give a factor of 4 slowdown on nearly everything. The only bus cycles that aren't followed by a NACT are during SDBD reads.

 

(Although, fun fact: The Z80 is a double-pumped 4-bit data path...)

 

OK, follow up question. Parking for a moment the potential problems with R6 and R7, do you think the CP1610 would have been a better CPU (whatever that means) if GI had gone for 8 bit registers and and an 8 bit ALU? So just considering smaller registers vs faster machine cycle rate.

[intvnut]

 

Would such a part be usable within an INTV framework? Well as you suggest you would need to disconnect the STIC as the clock source for the CP1600 and other ancillaries such as the System RAM and ROMs. I think the problem would probably be the System RAM, which bridges the CPU and STIC buses. The STIC would still be bound by the TV signal timing and merrily ticking at a machine cycle frequency of 895KHz. I suspect the bridge in the System RAM would not take kindly to one side running faster than the other, but Joe would be better placed to comment.

 

In the case of the RA-3-9600 system RAM, I doubt the relative rates matter so much as the absolute rate. It's limited to a 500ns data access time t_da, which is measured from the rising edge of BAR to the data first being on the bus. The CPU samples the bus in TS3, which starts 500ns after DTB on a 2MHz CP-1610. The CPU has a 0ns setup time relative to TS3 and 10ns hold time relative to the fall of TS3, so the RA-3-9600 just meets timing in a PAL system.

 

I don't know whether the RA-3-9600 uses the ϕ2 signal coming to it for bus phases at all, or just for internal refresh reasons.

 

The GIC1600 Microcomputer Users Manual has a bunch of additional interesting information about the CP-1600. It goes into much more detail about the CP1600 microarchitecture, and by extension, the CP1610.

 

 

 

Hilarious, I had assumed the 8bit ALU was an error on the datasheet. And I did not know that the Z80 had a 4 bit ALU, learn something new every day.

...

Even better, chatting with a colleague about this little Z80 factoid, he said he had always wondered how they did the half carry. Now it makes perfect sense.

 

 

Ken Shirriff's blog has a lot of information on the Z80 and the 8085 (and other CPUs!) The half-carry, in particular, doesn't require a 4-bit ALU. The 8085 has an 8-bit ALU, for example, but also provides the Aux Carry bit.

 

Some fun links there: (I highly encourage browsing the rest of his site!)

• http://www.righto.com/2013/09/the-z-80-has-4-bit-alu-heres-how-it.html
• http://www.righto.com/2014/10/how-z80s-registers-are-implemented-down.html
• http://www.righto.com/2013/01/inside-alu-of-8085-microprocessor.html
• http://www.righto.com/2013/02/looking-at-silicon-to-understanding.html
• http://www.righto.com/2013/03/register-file-8085.html

 

It's interesting to compare the Z80 to the 8085, since they both implement the 8080 instruction set as a common subset. The 8080 and Z80 share a few designers, including Federico Faggin. If you do a web-search for him, you can find some oral histories where they talk more about it.

Edited May 25, 2016 by intvnut

[intvnut]

 

OK, follow up question. Parking for a moment the potential problems with R6 and R7, do you think the CP1610 would have been a better CPU (whatever that means) if GI had gone for 8 bit registers and and an 8 bit ALU? So just considering smaller registers vs faster machine cycle rate.

 

I think instruction bandwidth may become a problem for that processor, if they don't also go to a non-multiplexed bus. The 6502 would have been dead with a multiplexed bus.

 

I think you end up with ripple effects up and down the microarchitecture if you take the double-pump assumption out. What you end up with depends on how you account for those ripples...

[intvnut]

First, another link: CP-1600 Microprocessor User's Manual. This is what I meant to link earlier, actually. It includes some fun diagrams...

 

 

 

OK, follow up question. Parking for a moment the potential problems with R6 and R7, do you think the CP1610 would have been a better CPU (whatever that means) if GI had gone for 8 bit registers and and an 8 bit ALU? So just considering smaller registers vs faster machine cycle rate.

 

Thinking about this a little more...

 

If you think of the current 16-bit register file as a collection of 8-bit registers, you actually have 16 8-bit registers. Now, two of them combine to form PC, but other than that, the other 14 registers are interchangeable if you ignore the encoding restrictions that prevent you from using some registers for various purposes.

 

To keep the orthogonal instruction set that makes CP-1600 so expressive, you'd need a larger opcode than 8 bits. So, you probably need to keep the 10 bit (or larger) opcode size, and thus a 16-bit data bus, otherwise you run into instruction bandwidth problems. Either that, or you end up with variable length instructions that give some registers higher status than others. For example, you could make R0 the "accumulator" (or R0_lo and R0_hi), and make most operations use it as an implicit operand, similar to 6502.

 

But let's assume you keep a 16-bit data bus, large opcodes, and the interleaved bus. Going back to 8 bit operations I think may allow eliminating a TS state most of the time, getting you closer to the Z80 T-state count. Have a look at the CP1600 pipeline:

 

 

I suspect the "Read Registers" phase just reads the low halves of the register. You can probably pull "Start Processing Next Data Bytes" one cycle earlier, or maybe two. One seems doable.

 

Let's assume you can get down to 3 TS states from 4, though. That's a 33% speedup on 8-bit arithmetic. Unless you keep 16-bit arithmetic as an option, I think you slow down on a lot of interesting workloads.

 

What I'm saying is that the machine is fairly balanced as it is. If you could get 8-bit instructions in addition to the 16-bit instructions, with the 8 bit instructions going 1 TS state faster, that would give a nice speedup on 8-bit values, but nothing dramatic.

[decle]

As always, excellent insight Joe. Very informative. Thanks

[Walter Ives]

On 5/24/2016 at 10:29 PM, decle said:

Everyone knows that the NTSC INTV is clocked at 3.58MHz which is divided by 4 to give a machine cycle of 894KHz + change.

 

Except of course it isn't.

        You (decle) and intvnut seem to have hashed this out correctly. Here's a synopsis for others perusing this forum:

        The system master clock is generated by a 7.16 MHz (well, 7.159090909... MHz) crystal oscillator at the color chip. The color chip uses both edges of that clock to synthesize the video signal, which can transition at 70 ns intervals, which is four samples per cycle of the NTSC 3.58 MHz color carrier.

        The graphics subsystem (STIC) is clocked at 3.58 MHz. The STIC outputs one color pixel every 280 ns clock period, the 4-bit value of which it sends to the color chip. Yup, that's one pixel per color carrier cycle. A concurrent fifth bit is used to provide sync.

        The CP1600 is clocked with a two-phase non-overlapping 1.79 MHz clock.

        Each pair of CPU clocks make up one microcode cycle (what GI terms a microcycle). Instruction timings are given in microcycles.

        Although the CPU is a 16-bit processor, internally it uses an 8-bit wide arithmetic logic unit to perform all arithmetic and logical operations, included addressing arithmetic.

        No engineer would say that the CP1600 is clocked at 895 kHz. That number isn't particularly useful and sources that quote it as the clock rate just confuse the issue. But what is extremely useful, especially to programmers trying to figure out how long a piece of code to execute, is the inverse of that number, the length of a microcycle. On NTSC systems that is 1.12 us per microcycle (well, 1.17460317460…us). That's the time by which you multiply the number of microcycles in the table in order to get the instruction time.

 

    WJI