Animated 6502 Block Diagram

[Jefffrey]

https://jeffayle.github.io/6502blocks/
git repository

Animated 6502 Block Diagram runs a transistor-level simulation of the MOS Technology 6502 and shows the internal state on Donald Hanson's Block Diagram.

This is the visualization tool I wish I had had since the amazing reverse engineering work of visual6502 and I hope it can be useful to others.

If you want to see it run ehbasic, press the run button and switch to the I/O tab. Type "c4000" into the text box, press enter, and then unfocus the texbox. This will send the input needed to get you to READY. Give it some time, it is slow. Type your program into the textbox then unfocus the textbox to start sending input. You will see the input being consumed character by character from the textbox.

If you want to see how an instruction executes, switch to the RAM tab, select "empty (4k)". Start entering instructions into memory starting at address 0. To do this, double click on a cell in the table then enter a new hexadecimal value. Unfocus the textbox to save the value. Switch back to the processor tab and use the step and back button to explore execution in half-cycle increments. Enter new opcodes into memory and press the reset button to look at the next instruction of interest.

There are some rough edges. I/O is janky, editing memory is janky. My goal is to create a tool that can be easily picked up and understood by someone who has experience programming a 6502 but no prior understanding of the internal machinery. It's not at that state yet, and I would appreciate any feedback on how to get there.

[BigEd]

Really nice - well done!

[piorkov]

Very cool project - I use it to debug my emulator.
However, one thing bothers me - in your project you used a modified block diagram, which causes some differences compared to what viusal6502 shows.

One of the differences I noticed is TXS - the modified diagram forces an update of the S register to take place only for T1 half 2

But from perspective viusal6502 S register is set in T1 half 1

http://visual6502.org/JSSim/expert.html ... te,Execute

What is the reason for this? So does this pre-S register make sense?

[BigEd]

You can trace both halves of the master-slave sides of the stackpointer with an URL like this:
http://visual6502.org/JSSim/expert.html ... BS,s,-nots

The stack pointer is special, in the sense that it can be read and written in the same cycle, so it has a slightly more complex structure than X and Y.

[Mr SQL]

BigEd wrote:

You can trace both halves of the master-slave sides of the stackpointer with an URL like this:
http://visual6502.org/JSSim/expert.html ... BS,s,-nots

The stack pointer is special, in the sense that it can be read and written in the same cycle, so it has a slightly more complex structure than X and Y.

This is very interesting. I wonder if more silicon could similarly have speed up the X and Y regs.

No doubt having modeled on a breadboard they were already pushing space limitations.

[BigEd]

(Is there any time where it would be helpful to read and write X or Y in the same cycle? I would guess not.)

[Mr SQL]

BigEd wrote:

(Is there any time where it would be helpful to read and write X or Y in the same cycle? I would guess not.)

hmmm... good question.

We save cycles with zero page indexed addressing so a possible scenario that comes to mind would be to read and increment (write) the index register.

[Jefffrey]

piorkov wrote:

Very cool project - I use it to debug my emulator.
However, one thing bothers me - in your project you used a modified block diagram, which causes some differences compared to what viusal6502 shows.

One of the differences I noticed is TXS - the modified diagram forces an update of the S register to take place only for T1 half 2
But from perspective viusal6502 S register is set in T1 half 1

Screenshot From 2025-02-26 22-10-29.png

http://visual6502.org/JSSim/expert.html ... te,Execute

What is the reason for this? So does this pre-S register make sense?

The pre-s register that I forced into the diagram is what visual6502 calls the stack register, so when you see visual6502 load the stack register, that's the pre-s register on my modified diagram. Which one of these is the "true" value of the stack register pointer is arbitrary. Instead of drawing pre-s & s like I did, I could have done s & post-s. In fact, I wanted to do that so that I would show the same stack pointer as visual6502, but I just wasn't able to make it work visually. I added it to the diagram because it's in the hardware and if only one is shown, the diagram will either show the register being loaded, but the value doesn't change until the next half-cycle, or else the diagram will show the wrong value being read from the register when it is being written to at the same time.

The top of this source file contains a list of what node numbers everything corresponds to in visual6502. You can cross check these with the names that visual6502 uses. It is also the case that what visual6502 calls the program counter registers are named program counter select on Hanson's block diagram.

I called the pre-s register "S select" because it has the same structure as the program counter + program counter select registers, except for the added increment logic. All of the registers in the 6502 are a piece of hardware called a latch,. Latches are level triggered, this means that they load a new value as long as the write signal is high. Putting two latches together in this way makes a piece of hardware called a flip-flop. Flip-flops make a kind of register that loads a new value when the write signal changes from low to high (or high to low). Normally you would show a flip-flop as a single register on a diagram like this, but it's relevant here because the stack pointer register and the program counter registers behave differently from the other registers.

[Jefffrey]

Mr SQL wrote:

This is very interesting. I wonder if more silicon could similarly have speed up the X and Y regs.

No doubt having modeled on a breadboard they were already pushing space limitations.

You would need more adders as well, inx/iny use the ALU, and you're already using the ALU to do indexed addressing in this scenario.

The 6502 could have been made out of flip-flops instead of latches across the board. I think that might be what the 6800 is.

[barnacle]

But don't flip-flops take more real estate than latches?

(as an aside, when I've designed 74xx series discrete processors, my favourite part is the '574 flip-flop...)

Neil

[BigEd]

I'm fairly sure the 6800 uses mostly dynamic latches in much the same way the 6502 does - there's a visual version so it's easy to check! http://www.visual6502.org/JSSim/expert-6800.html

The give-away would be whether a chip has a minimum frequency: you can't stop the clock if you have dynamic storage.

BTW, we might well have chosen pre-S because it isn't logically inverted, so it's straightforward to display. A little later in development we realised we also need to be able to display logically inverted values.

[Mr SQL]

Jefffrey wrote:

Mr SQL wrote:

This is very interesting. I wonder if more silicon could similarly have speed up the X and Y regs.

No doubt having modeled on a breadboard they were already pushing space limitations.

You would need more adders as well, inx/iny use the ALU, and you're already using the ALU to do indexed addressing in this scenario.

The 6502 could have been made out of flip-flops instead of latches across the board. I think that might be what the 6800 is.

Thank you for the explanation. I'm curious how do illegal opcodes manage to add extra functions without extra hardware.

[Dr Jefyll]

BigEd wrote:

I'm fairly sure the 6800 uses mostly dynamic latches in much the same way the 6502 does

May I clarify on your behalf, Ed? I believe you're emphasizing that it uses dynamic latches rather than static latches. (In light of Neil's remark, a reader might wonder if you mean it uses dynamic latches rather than dynamic flipflops.)

PS- welcome, Jefffrey! Great to see this educational project!

-- Jeff

[barnacle]

Yes - I tend to forget that dynamic circuitry was used anywhere outside memory (ok, ok, registers are very small memories!).

I was commenting more on the difference between a latch - which changes its output when the input changes - and a flip-flop, which is in effect two latches with the second latching the first only on a clock.

(for a home-grown computer, the main use of the flip-flop is that many of them come with tristate outputs which allows a distributed wide multiplexer.)

Neil

[BigEd]

Indeed, I could have been clearer.

The typical dynamic latch in NMOS is just one transistor: it feeds into a gate or two, but sometimes that gate would be there anyway. Sometimes there's very obvious just an inverter following the transistor, in which case we might count the latch as costing three transistors.

Commonly we see flip-flop designs which are made of two cross-coupled NOR gates, which can also be drawn as a pair of recirculating NOR gates. Such things are static - they have no minimum frequency. The cost would be six transistors, or eight if there's an associated inverter.

But in the world of NMOS, a flip-flop is often just a pair of dynamic latches, with an inverter between, so that's 4 transistors minimum.

In passing, one thing the 6502 does very effectively is to use the two clock phases productively. A design made with flip-flops, like the typical FPGA design, can't be implemented quite the same way: a clock cycle is in that case an indivisible thing. (Unless you have some flops on one clock edge, others on the other, but that's pretty unusual.)