Retrocomputing Stack Exchange is a question and answer site for vintage-computer hobbyists interested in restoring, preserving, and using the classic computer and gaming systems of yesteryear. It only takes a minute to sign up.
Sign up to join this community
I was wondering if the original NMOS 6502 has any timing limitations on changing the clock rate during operation?
I ask, because the CSG 8502 version could "run at double the clock rate of the C64", which sounds like a normal 6502B. But it did change it on the fly.
Was there more to it than that? Were there timing constraints like those with the Atari HALT pin or similar?
As long as any clock properties from the datasheet are kept, like the cycle time, pulse widths for '0' and '1' parts of clock and rise and fall times, the clock rate might be changed in any imaginable way. The CPU simply has no ways to know whether its clock is changed.
I was wondering if the original NMOS 6502 has any timing limitations on changing the clock rate during operation?
Well, like any CPU it has to stay within the defined minima; specifically those on page 18 of the 1976 MCS6500 Microcomputer Manual:
and described on p.17 of the same manual
I ask, because the CSG 8502 version could "run at double the clock rate of the C64", which sounds like a normal 6502B. But it did change it on the fly.
Why should it? Switching is not done by the CPU with some secret circuit (other than magic smoke that is), but is solely a function of the clock source.
As long as the minima for that CPU are kept, that is not being clocked faster than defined, all will work fine. After all, the trick is not 'double clocking' it but rather 'half clocking'. That is, instead of the clock the CPU is intended for (like here 2 MHz) have it run at 1 MHz.
If that clock source provides a variable frequency signal with all components within the minimum requirements, then the CPU will run quite fine at whatever speed it is feed at a given time.
Was there more to it than that? Were there timing constraints like those with the Atari HALT pin or similar?
No. Just never undercut the basic timing constrains of the CPU (*1).
Bottom line: There is nothing magic about changing duration of clock phases as long as all timing parameters are still within what the datasheet says. For a basic first Generation 1 MHz NMOS 6502 this means no phase should be shorter than 470 ns and no full cycle should exceed 10 µs. You're free to switch between any frequency and symmetry you want as long as these two parameters are kept valid.
In practical terms such a 1/2 MHz switching would be based on an external clock generator providing a 2 MHz clock (maybe divided down from a higher clock). This clock is divided by two providing a synchronous 1 MHz clock. Since they switch in phase, every rising edge (*2) of the 1 MHz clock is also a rising edge of the 2 MHz. Thus any switch between both sources can happen at any point during during the following high phase. It's best done of course with the rising edge of the slower clock.
(Made with Wavedrom)
This diagram shows quite nicely how switching looks and that there is no influence to the CPU, as it only acts on the resulting clock. No help needed and no detectable influence exerted - except speed increase of course :))
The needed logic is rather simple - one Flip-Flop (*3) to hold the state and two gates to synchronize. It's easy to put it into a PLA creating the general timing. Of course this should be made in glitch-free logic :))
And yes, classic 4.77/9.54 MHz switching for XT class PCs worked exactly the same way. After all, this is nothing CPU-specific but part of the clock circuit.
For the C128 all clock switching is done by the 8564 VIC-IIe. It is feed by an ~8 MHz clock (called Dot-Clock) and provides 3 clock signals:
The 1 MHz output is running continuously and used for all system timing, as with a C64. The 4 MHz clock only runs during the second half of the 1 MHz clock, so effectively at 2 MHz. It lets the Z80 run, when enabled, with the same timing as the 8502.
The 2 MHz clock output delivers the 1 MHz system clock when in SLOW mode, letting the CPU access memory during the second memory slot, while doing video access during the first. When in FAST Mode, VIC-IIe video access is disabled and both memory access slots are given to the 8502. Unless it's an I/O access (signalled from I/O decoding via a dedicated input). In that case the cycle gets stretched covering at least one 1 MHz cycle to synchronize I/O access with the system clock - effectively slowing it down to 1 MHz for 1 cycle.
The added complexity is not related to the basic clock switching, as seen by the CPU, but to make sure all I/O timing requirements are satisfied.
Having asymmetric and/or changing clocks isn't anything unusual. A prominent example might be the Apple II. Here all timing is derived from a 14.31818 MHz clock source. For the basic timing this is divided by 14 giving a base clock of 1.023 MHz (a cycle time of 978 ns). But every 65th cycle the CPU clock is stretched (slowed) by two 14 MHz cycles (139 ns) to 1117 ns (0.895 MHz), resulting in an effective clock of 1.020 MHz (*4). All of this is done on the fly and invisible to the CPU.
The BBC micro (*5) is by default running at 2 MHz, but a range of peripherals is clocked at 1 MHz. Any access to these addresses will stretch the 2 MHz clock, turining it into a 1 MHz cycle. As explained in an application note:
1MHz peripherals are clocked by a 1MHz 50% duty cycle square wave (chosen to allow chips such as the 6522 to use their timing elements reliably). The BBC Microcomputer's cpu normally operates with a 2MHz clock, but with a slow-down circuit which has the effect of stretching the "clock high" period immediately following the detection of a valid 1MHz peripheral address.
(Acorn Application Note #003, 1MHz Bus Application Note, Section 5 on Page 5)
The following graphic shows nicely how the stretch will look to the CPU. Note, due the need of synchronisation the example shows an effective slowing down to 0.833 MHz.
(Same manual p.9, only relevant parts)
Another example is the Oric-1 timing. Its asynchronous clock is based on a 12 MHz clock, divided by three to allow three memory cycles, of which the ULA gets two and the CPU one. From the CPU's point of view this looks like a clock with PHI1 high for 666 ns (Eight 12 MHz cycles) and low for 333 ns (four 12 MHz cycles) as show here:
It's all about giving the CPU a clock signal that looks fine within the defined limits (*6).
Last but not least, many years ago (late 1990s), yours truly did a design using a 65C02 running at 6 MHz, but using 100 ns SRAM. With default timing only ca. 5 MHz would have been possible with this RAM. To crank it up, the first half of a clock cycle was shortened to 50 ns while the second, where the 6502 does its memory access, got the rest. 16% faster processing out of the same components by playing with the clock. :))
Now, if that question is less about clock switching but more about CSG's numbering scheme, as it seems from a comment (*7), then the answer is rather simple: Commodore numbering is random.
Having said that, a bit of logic can be found when looking at some CSG CPU variants:
Looking at this it can be deduced that
the first digit is modified according to the chip process with
6 = NMOS, 7 = HMOS, 8 = HMOS-II and 4/5 = CMOS (*8)
the second stays a '5'.
the last two are simply using a free designation starting from 00.
Of course this wouldn't be Commodore if they hadn't violated the scheme right away with
In the end, a 8502 is, not as assumed, a 6502, but a 6510 (with 7-bit port) in HMOS-II for 2 MHz.
As seen in other places, chip 'names' are in no way always systematic or based on the same structure. Some mark technical differences, some are marketing related (like Intel's decision to call the CPUs 4004 and 8008 within their group), but overall they are a logistics item. Nowadays marketing and chip numbers are different issues anyway.
*1 - Of course it's also a good idea to keep within the constraints of RAM and other system components, but unless that is a very specific setup it should be fine right away, as all timing in a 6500 system is related to the CPU clock.
*2 - Works the same for falling, so it's sufficient to look at one case.
*3 - Usually with an additional FF holding the switch request issued from the software. For luxury maybe made readable as well, so software could check what clock it is running at.
*4 - In case you're wondering why these odd numbers, work your trusty calculator and see if 14.31818 / (14 * 65) yields any interesting result :))
*5 - A case Kaz reminded in a comment.
*6 - Had Commodore done the same with the C64, no-one would have had to worry about bad lines.
*7 - Maybe this should have been made into a separate question in the first place.
*8 - This is a guess based on the chip numbers used with the C65, as the switch to CMOS happened at a time when Commodore was in decline.
I'm pretty sure based on this image
That the Saturn II accelerator does this with a NMOS part.
Apart from avoiding glitches in the clock changing it isn't a huge task.
