I mean glitches caused by different logic propagation delays. For example, if you have a signal A that goes from 0->1 at the same time that B goes from 1->0, and you combine those signals in an OR gate, the output will stay at '1'. However, if A is slightly delayed, the output will first briefly go to 0. Normally that's not a problem, as long as the signals are all stable before the next clock edge. But if you use that signal for the clock itself, it causes an extra (but very short) transition.

Repeated from the end of this post 5+ years ago:

If the clock frequency is switched while the processor is running, you'll definitely need to take measures to prevent glitches. If switching clock sources results in the φ0 input clock getting a one-time pulse that's less than the minimum width the system will work with (say 25ns or so) the computer will crash. A "runt pulse" would be when the pulse is so short it doesn't even quite have time to fully get to the oposite logic state and back. That would sometimes cause crashes too.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

If you think of a clock as a series of pulses, and you try to use AND to squash one of the pulses, you can see that a slightly delayed control signal might miss the front edge of the pulse, and you'd see a glitch. Which might or might not cause subsequent gates to do something unwelcome.

BTW, on the subject of bidirectional busses: the special thing about the 6502's internal bus structure is the two sets of pass gates which connect the Special Bus to one or other of the other busses. Pass gates are not directional, so these gates act like switches or relays and just connect two busses without regard to which side is driving. Using conventional logic gates you can't really construct this, and this is a stumbling block for people trying to rebuild or simulate the 6502 at that level. This doesn't necessarily affect you, as you have your own bus structure. The reason for it in the 6502 is that wiring costs chip area, unless you can fit all the wiring in the area you necessarily have for the transistors. Cost of production is an exponential function of chip area, and there are steps in the cost function depending on how you fit an array of rectangular die onto a circular wafer. So at some critical sizes, a very small increase in area gives you a step in cost. So, the very small register file of X and Y is served only by the special bus. S gets also to see the ADL, but only for read(?). Fewer busses running along the datapath means a smaller datapath.

Now, I think there might be a 4000 chip which offers quad (or possibly octal) bidirectional connectivity.

(It's moderately likely that one could cook up a pair of control signals which could set the direction of the two bus coupling widgets, and therefore use a bidir transceiver. But that would be something the 6502 doesn't need or use.)

Just to note another resource for decoding the original 6502 implementation: Beregnyei Balazs' giant schematic. It's incomplete and might have one or two errors, but it does illustrate and illuminate some points. It's decoded from a microphotograph.
Also good, Xor posted a colourised block diagram:
viewtopic.php?t=1744

Yes, got it. I think I've seen this and it was a complete surprise. As a former programmer, I've always thought about things in discrete steps. It's hard to remember that that's an illusion and that signals flow more like water around the circuit - taking appreciable, measurable time to get around. I suspect most of my challenges will be in this area.

_________________
C74-6502 Website: https://c74project.com

You've got a good memory Garth. Thanks for digging this up.


Yes, my intention is to have different operating frequencies. It seems a luxury to want to be able to switch on the fly but I know I will want it. I can see why glitches are very likely as a cycle gets cut off at the moment of transition. It seems any partial cycle needs to be suppressed to keep things smooth. I'll remember that when the time comes.

btw, it's kind of ridiculous but in fact I've yet to connect to an actual crystal clock. All my basic experiments have been with a toggle switch. I'm going to order a crystal today and get that working just to make sure that's sorted out. I don't own an oscilloscope so things are likely to get rather exciting for me from here.

Thanks.

_________________
C74-6502 Website: https://c74project.com

I can see these labeled as "PASS MOSFETS" on Hanson's block diagram.



I agree. I'm not subject to any practical cost or space constraints to speak of (at least that I know of - time will tell). It's valuable nevertheless to understand the bi-directional busses. I'm spending some time today working through the trace in more detail so I'm glad you pointed out the pass gates.

_________________
C74-6502 Website: https://c74project.com

I had a bit of a look, and a bit of a think, and I was able to get the second set of pass gates into play by crossing a page boundary:
http://visual6502.org/JSSim/expert.html ... loglevel=1

Ok, I ordered a few oscillators to experiment with. Btw, while looking I found this:

http://www.farnell.com/datasheets/1930165.pdf

The package is unfortunate, but it generates a while host of frequencies and the data sheet claims runt-free operation on startup and while switching frequencies.

_________________
C74-6502 Website: https://c74project.com

This circuit may also be useful if you want to switch clocks on the fly:
http://www.eetimes.com/document.asp?doc_id=1202359

Fantastic! I can see SBADH in cycle 12/13.
I've spent some time with these traces. Definitely heavy going but I'm beginning to see the light. The intermediate registers (e.g. A INPUT, B INPUT, ADD, ABL, ABH, PCLS, PCHS) are entirely absent in my design and this makes for a totally different mindset. Somehow I end up with the same number of cycles for most things (which is frankly very surprising looking at these traces) but the internals could not be more different. I'll be very glad If it turns out to be just two different approaches and not some fundamental misunderstanding. I'll soldier on for now and see where it goes.

A quick questions: I assume the OPEN DRAIN MOSFETS 0/ADH0, 0/ADH(1-7) set ADH to a constant when asserted - in the trace it is 0ADH17 in Cycle 2 and it looks to be the high byte of the stack address for the PHA write. Correct? Similarly, 0/ADL0, 0/ADL1 and 0/ADL2 set constants as well for ADL?

Cheers.

_________________
C74-6502 Website: https://c74project.com

Thanks Arlet. I'll give this a try when the oscillators get here.

_________________
C74-6502 Website: https://c74project.com

Ok, I think I may understand what's happening here.

My design is simpler but relies on having to do more in each cycle and therefore incurs a greater propagation delay for each step. The 6502 on the other hand, cleverly executes several threads in parallel, using additional registers as intermediary stages, and gets it all done in as many steps (with each step being faster).

INX provides a good illustration. It takes two cycles on each architecture. My microcode is as follows:

Step 1) IR := *PC; PC +=1 - fetch opcode, Increment PC
Step 2) X := X + 1 - Roundtrip through the ALU, Incrementing X and storing the result back in X

The 6502 on the other hand performs several things in parallel:

Step 1) XSB, SBADD - move X to the ALU; PCLADL, PCHADH - move PC to address bus, ADLPCL, ADHPCH - move PC to inc circuit
Step 2) ADDSB, SBX - store X+1 back into X; PCLADL, PCHADH; Setup the next read; IPC - Increment PC; Fetch opcode from address setup in step 1

The tradeoff, I think, is that the 6502 will manage a faster clock rate (since it is doing less for each thread in a given cycle) at the expense of more registers (which it requires as intermediary stages). By comparison, my design seems slow and simplistic, forcing signals to travel through much more circuitry on every cycle. And it actually requires quite a few registers itself (12 vs. the 6502's 17) and also quite a few bus buffers to boot.

At least this is what I think is going on ... I'm not actually sure if the signals in the 6502 are doing what I think they are doing. Perhaps someone can comment here.

Either way, I can safely say I am more impressed than ever with the 6502. When I get a chance, I will take a look at the second trace BigEd provided as I'm very curious on the sequencing of the indirect/indexed addressing mode. In the meantime, I will press on with my simpler design.

Maybe I can gain some speed just through a faster TTL logic family

_________________
C74-6502 Website: https://c74project.com

If you know verilog, you could also take a look at my 6502 verilog core, which gets to the exact same amount of cycles, but in a different way (there are no internal buses for instance)

https://github.com/Arlet/verilog-6502

Quite right about the open drain MOSFETS Drass - they are the conditional pulldowns which operate on a precharged bus to construct constants such as 0, 1, fe and so on.

One trick in the 6502 is the use in some places of phi2/phi1 cycles instead of phi1/phi2 cycles: you'll see for example many datapath control signals are valid over phi2/phi1, which means they can safely control the datapath activities which occur over phi1/phi2. I think...

You mention A INPUT, B INPUT as registers, Drass, and I see that Hanson labels them as such (these are the busses named as alua and alub in visual6502, the byte-wide collections of signals which form the inputs to the ALU)... but I'm not sure whether or not to think of them that way. I think I must, although there's no recirculation so they are latches rather than flops. They are clocked by datapath control signals - a case of gated clocks - not by the chip-wide clocks. Looking closer, I see the ALU output is also a latch, this time clocked unconditionally. Whereas the accumulator does recirculate, but is loaded conditionally by SBAC used as a clock. The merging of a clock and a multiplexor is one of the efficiencies in 6502 which keeps the transistor count so low.

I'm sure you're right though that splitting ALU action over two cycles - operate and then writeback - helped keep down the path length and bus complexity in the 6502.

(I'll second Arlet's recommendation to study his core!)