I just found this logisim (free) electronics tool, and a couple of nice CPU examples, one "hard coded", the other microcoded.

The cpus are not "6502" (nor anything else "real", but are good examples for basic cpu principles (at least they seem to be ... me not being any expert, but Professor Toomey, seems to know what he's doing )

Mike

=====================
http://ozark.hendrix.edu/~burch/logisim/

Logisim is an educational tool for designing and simulating digital logic circuits. With its simple toolbar interface and simulation of circuits as you build them, it is simple enough to facilitate learning the most basic concepts related to logic circuits. With the capacity to build larger circuits from smaller subcircuits, and to draw bundles of wires with a single mouse drag, Logisim can be used (and is used) to design and simulate entire CPUs for educational purposes.

---------------------
http://minnie.tuhs.org/Programs/UcodeCPU/index.html

"Warren's Microcoded CPU

Introduction

I wanted to design a microcoded CPU which had a reasonable number of instructions and RAM, but was still reasonably clean and elegant. I've used the microcode logic structure that Mythsim uses, but I've designed the CPU from scratch and implemented it using Logisim.
Download

Here is a Zip file which contains the microcoded CPU as a Logisim circuit, a microassembler and an assembler written in Perl, a text file containing a minimal set of microinstructions, and a sample assembly language file:
microcode_cpu.zip, version 1.1

CPU Overview

The CPU has a 16-bit address bus and a 16-bit data bus. With Logisim, you can only address the 16-bit words as words not bytes. This also means that you only need to add 1 to the PC to move to the next whole-word instruction, not 2. There are 8 general purpose 16-bit registers, an ALU which can do 16 different operations, an instruction register and an immediate register to hold immediate (literal) values.
Each simple instruction is 1-word (16 bits) long with these fields:
7-bit opcode (MSBs)
3-bit t-register (usually the 2nd operand to the ALU)
3-bit s-register (the 1st operand to the ALU)
3-bit d-register (LSBs, usually the destination of the ALU operation)"

======================
http://minnie.tuhs.org/CompArch/Tutes/week03.html

1 Introduction

In this week's tutorial we are going to look at a simple hardwired CPU, to demonstrate that the control logic in a CPU can be built using some simple gates and multiplexors.


The ALU is the same one that we designed last week. It performs the four operations AND, OR, ADD and SUB on two 8-bit values, and supports signed ADDs and SUBs.
The CPU is a load/store architecture: data has to be brought into registers for manipulation, as the ALU only reads from and writes back to the registers.
The ALU operations have two operands: one register is a source register, and the second register is both source and destination register, i.e. destination register = destination register OP source register.
All the jump operations perform absolute jumps; there are no PC-relative branches. There are conditional jumps based on the zeroness or negativity of the destination register, as well as a "jump always" instruction.
The following diagram shows the datapaths in the CPU:

Such tremendous response and interest !

Anyway .... is there any similarity between the control / decision rom / control logic in the above micro coded cpu and the 6502 ?

Looking through the visual6502 simulator code, I see there is a "cycle" variable and the function halfStep() seems to be about the lowest level of code in the simulator.

But I still haven't been able to figure out how the 6502 "sequences" through the deocde PLA.

I'm especially interested in how the instruction fetch cycle works in detail

Any tips / hints, info, greatly appreciated

Mike

Hi Mike
my quick answer is that a general educational presentation on a CPU design will be a lot simpler and easier to understand than the actual (NMOS) 6502. There are a couple of reasons for that:
- NMOS allows for very cheap transparent latches
- the middle of the chip is packed with unstructured ('random') logic gates

so, the 6502 has some 100(*) or more bits of control pipeline state which record the state of the current instruction in progress, scattered throughout the central section. An educational presentation or TTL rebuild is not likely to re-do that. An FPGA redesign could do. The actual meaning of those bits is very difficult to discern.

From a distance, the ROM or PLA and the datapath give the impression of a very ordered and understandable design: and those parts are. But in between them is something very special.

Also note, the 6502 is pipelined, and I would expect most introductory explanations of a CPU would not be.

Cheers
Ed

(*) figure off the top of my head from familiarity with visual6502

Edit: I had linked to a wiki page I've been working on which discusses some findings from original 6502 schematics. But I realise that it doesn't provide full-scale images - Balazs' schematics are still best for a circuit-level understanding, in combination with visual6502.

Hi Ed,


If the "meaning of those bits is very difficult to discern", how is the Visual6502 code running (presumably accurately), the correct connections ?

Hmm, I guess ?? ...everything can be treated as a "black box" ? ... as long as the input / output pins have been identified.

I'll have to take another look at the javascript.

Thanks for the links.

The above tutorial / example I posted is actually fairly simple, even for me , and I'm going to try to iimplement it in a couple of different tools. I've been playing with Minecraft and a great addon called RedStoneChips, and have just found out about another game / simulation envirionment called Garry's Mod / Wiremod, which also supports electronic simulations.

It's too bad, in one respect, that the 6502 is still being manufactured, in that, I assume, that's one of, if not the main reason, why the internal operations of this ~40 year old technology has never been documented.

(Is the current 6502, in fact using the same internal structure of the Nmos6502 ? ) (Has it ever been "disassembled" like the nmos version?)

Btw, is your day job in electronics, / electrical engineering ?

Me ... just a hobbyist

Mike

Hi!

If you are willing to make a Minecraft cpu, i made plans for a super simple 4 bit risc(register register architecture) cpu with 4 registers(it is also supposed to be fast), i actually opened a topic, it was supposed to be based on the 6502, but after lots of thought i figured out that the mos elegant design with the lowest gate count is a super simple risc cpu...
I actually never finished the designs, but if you want i can make the documentation with the specifications... (I was planning to finish it, but other stuff made me put aside this project for now).

I was also planning to implement it in a cpld, one day i hope i will...

Edit: In my Minecraft server, I've made room and built 128 words of ram, and all the basic building blocks, i was planning to make it the hard way, but i am having trouble even turning off lights in a warehouse(some redstone nodes get sucked hi when they are far from the event that changed the state), thanks for mentioning the chip plugin!

Hi Dajgoro,

The RedstoneChips plugin runs on a bukkit server, not the vanilla minecraft server.

Where is your server ? ... I wouldn't mind taking a look.

What is your minecraft i.d ? .... I can whitelist you for my server which is running bukkit and the redstone chips plugin.

You can send it to me at mikestramba@gmail.com

I have built 99% of the cpu in RedstoneChips, currently using wireless connections to make it a bit easier. I may eventually use "wires", and ideally animated wires to indicate the signal paths.

I'd love to see anything you have on your CPU design.

You can send it to me at mikestramba@gmail.com ... and we can continue to converse via email if you wish.

Mike

Elsewere i use the nickname D101h as D Dajgoro and 101h as 101 in hexadecimal, that means that the number is 257 in decimal.
I've seen the number 257 appears around me countless times, also the number 101 is intriguing...
So you may find my nick as D101h in Minecraft, as for the server, its old ip is: 89.201.175.35:25574 , while the new one is: 193.192.59.151:25571. Currently we are in a sort of transit state.
The server has not been officially opened yet, so if someone wishes to play(or try something), pm or email me your nickname and i will white list you(enable your nickname to connect).
As for toes of you who would try to play this game in a quiet and relatively safe place, you may also join to my server.

As for the map, it is a continent, with a city. The logic circuits are located in a huge brick warehouse, and behind that is the cpu project.

Hi Mike
indeed, visual6502's simulation is very black-box: it just simulates each transistor as a switch. Many of the signal names attempt to ascribe some meaning to the wires or the storage elements, some of which are easy and obvious and others of which are not. The parts which are programmer-visible or well-documented in Hanson's block diagram are the ones which make most sense.

(Yes, my work life has been in the chip industry: I did a Master's degree in VLSI and spent some years as a design engineer. I'm not sure I should count myself as an EE though.)

The Minecraft mods sound like a good way to get a hands-on experimentation with logic simulations, and to share expertise with like-minded people.

(The visual6502 people have not taken a CMOS 6502 apart, and don't have any plans to. As you say, it being in current production is one good reason. Also we can only deal with relatively old technologies. And we have a huge backlog! I think the overall structure is quite similar, judging from the die shots and patents, and also knowing that Bill Mensch has proceeded almost single-handed.)

Cheers
Ed

Hi Ed,

Ok, I'm going to ask a naive question about the reverse engineering of the chip.

Not to forget, what a fabulous effort and results it already is !

Please correct any of my assumptions :

1) I ASSume... that since the simulator is apparently able to run 6502 code correctly, that you are satisfied that all the connections have been identifed, and "virtually" wired up correctly ?

If so, and since apparently all? of the major datapaths / registers etc have been identified, and the behavior of the chip is documented, then what is the difficulty in identifying the "non standard" logic "gates" that are in the "middle" of the chip ?

Please don't mis-understand me, I'm not saying that it should be easily done ... or do-able at all, I'm just trying to learn, what the difficulties are.

Is it because the non standard layouts are not easily identfiable in their function?

Btw, I did read Hanson's paper, (a lot of which flew over my head) and he mentions difficulty with "parallel and bidirectional pass transistors", when reverse engineering. Is that part of the problem, when identifying the circuit function ?

Heh, not that I really even know what a pass transistor is ... had to "wikipedia" it:)

Mike

Hi Mike
the trick of the visual6502 is that it doesn't have to understand anything in order to work correctly! All of the signal names are there purely for our (human) convenience. They could be wrong or misleading and the simulation would still work - so long as we correctly labelled the pins, and the X and Y and A registers, all would be well. Even if we mislabelled X and Y, that would only cause confusion in the user interface, it wouldn't stop any programs from working. Node 1653 will always be the top bit of the accumulator, even if we didn't label it at all.

But as Donald Hanson points out, pass transistors do make life complicated for simulators and designers - they also make for a very efficient chip when you get things right. The thing is, they act bidirectionally, whereas most of the chip's transistors can be proved to act unidirectionally. Visual6502 sometimes has to iterate 20-30 times for each phase of the clock until the state of the chip settles down, because of the sloshing around when the pass gates open up. (Sort of.) The pass gates are also responsible for the indeterminate behaviour of some of the undefined opcodes: with pass gates in the design, it's no longer a pure logic design with one direction of cause and effect.

(Yes, we're satisfied that all the connections are wired up correctly. There still could be something missing, because exhaustive test is near impossible: RDY especially makes it much harder. We know that booting C64 Basic only uses 70% of the transistors!)

Cheers
Ed

Just started playing with Logisim, excellent tool for learning.