Hi gnawzie, and welcome!
If you really want to understand the internals of the 6502, see first Donald Hanson's
block diagram, and then Michael Stiel's presentation on 6502, informed by the visual6502 work:
Reverse Engineering the MOS 6502 CPU [27C3]We've put various resources and links into the visual6502 wiki, so explore that too.
Building a CPU using a very wide microcode implemented with ROMs is certainly feasible, and you'll learn a lot from it. But an exact copy of the 6502 isn't necessarily best, because you copy some complex and incidental decisions made by the original MOS design team.
It's probably worth looking at the design or implementation of other minimal or simple CPUs. Some resources:
- Bruce Jacob's RiSC-16:
http://www.eng.umd.edu/~blj/RiSC/ - Steve Chamberlin's Tiny CPU:
http://www.bigmessowires.com/cpu-in-a-cpld/ - Dieter Mueller's no6502:
http://www.6502.org/users/dieter/m02/m02.htm - Ruud Baltissen's ttl6502:
http://www.baltissen.org/newhtm/ttl6502.htm(My point here is not "this has all been done before" but more "here are some ways this kind of project can be tackled")
Arlet has a point: many implementations these days are inside programmable logic chips, so learning to read (and eventually write) Verilog will open up more possibilities. But I do think a detailed block diagram is also an asset: it's the way my brain works, at least. If you can do a paper design, there are then several ways to implement it.
A big advantage of Verilog (or VHDL) is that you can write it and then simulate it - you don't need to build hardware to see whether your ideas are heading the right direction. In a simulation you can trace any signal and even print out values, to debug your ideas. All the tools are free, or no-cost.
But it's also true that you can tie yourself in knots in Verilog (probably you can do the same on a breadboard!) so having clear diagrams is always going to help. In Verilog you must stick to a small set of idioms to get reliable results: it's not a chip design language but a general purpose simulator-building language, and you don't want or need that generality.
Cheers
Ed