Hallo allemaal,

Maybe I already mentioned this subject but a) that was probably years ago and b) me getting old, I don't remember it anymore.

The idea is simple: build a 6502 out of TTL-IC's. I already found out that that is near to impossible so I put some water into the wine: I decided to include EEPROMs/Flash-RAMs as well. In my case I use the Atmel 29F040's for the instruction decoder, the ALU and (what I call) static addresses.
Why did I choose the 29F040? For a very simple reason: I could scrap them for free from obselete HP servers :) (yes, I'm Dutch) The advantage of using the Atmels is that I have so many input pins I can reserve some for future features, To name two:
- it enables me to emulate CPU's with 2- or 3-byte opcodes like the 6809 and Z80 (I know, extra hardware/registers needed)
- even without extra hardware, just by setting one of the input pins. the hardware of the 6502 can be used to emulate a 6800 by selecting an other opcode set.
Regarding using extra hardware, imagine this TTL CPU can be used to emulate a 6502, 65816, 6809 or Z80 just by flipping some switches!
(but I'm already very happy if the 6502 part works)

But now the big question: has anybody else on this forum ideas or experience on building a TTL 6502 and wants to share it here?

Many thanks in advance!

_________________

Someone did it ages ago, with schematics and all.

http://www.6502.org/users/dieter/m02/m02.htm

_________________
"My biggest dream in life? Building black plywood Habitrails"

I have no interest in constructing a TTL 6502, but I do have plans to go back to my discrete CPU projects with a 16-bit or 32-bit stack CPU design. Some year, I'll make it actually happen.

I have also toyed with the idea of a transport-triggered processor architecture as well.

Not too long ago there was something about a home-made 6502 on very nicely done multilayer boards that plug together, with rows of T1 LEDs which I assume were for status and debugging. It was not wire-wrapped. It was very impressive, even though I think the author said he never really did finish it. I can't find it now but maybe this will jog someone's memory for what to put in a search string. If the author can be found, he would probably be happy to give you all the info to give you a head-start so he can see it come to reality.

I have been collecting a few 100 this or that, like 75ABT574, CY7C199-20, CY7C109V33-15, 514256's, 29F400AB-20, 74ABT16374 / 16543, 74ABT843, 74F283, 74F269, etc etc. Assorted 5v and 3.3v stuff, and HC / AC parts. Count me in.

Not that i want a 100mhz 6502, but one with more registers, 16bit data busses, and some other stuff would be nice.

aikatt

With the 6502, essentially the entire zero page is essentially 256 general-purpose processor registers, all accessible in fewer clocks than most 8-bit processors can do anything at all; but with the 65Org32 totally 32-bit 6502 proposed here and in the pages before and after it, the entire 4GigaByte space is in zero page (or more accurately, direct page, since the DP register gives offsets in it).

I'm sorry, but i did mean registers inside the cpu with no external memory cycles, a couple nanosec access times. I did not mean a larger zero page, while i do see the advantage in zeropage addressing, it's not on par with internal registers.

aikatt

Actually, zero-page is on-par with internal registers. The 6502 utterly snows the 8086 and 80286 in a lot of benchmarks despite the heavy use of zero-page addressing. Likewise, the 65816 comes within 80% to 90% the performance of a 68000, despite the 68000's internal 32-bit wide registers.

I think what you mean is, you want a CPU with single-cycle execution. A chip with zero-page cached (since that's all CPU registers actually are -- a software-managed data cache) will give you this.

Are you going to say

inc[mem1]
inc[mem2]
is as fast as
inc[reg1]
inc[reg2]
or...
jmpindirect[mem1]
is as fast as
jmpindirect[reg1]

? If not, then i still want more internal registers. If it is as fast, then would you please tell me how, because i can make 2ns registers, i cannot buy 2ns zero page memory.

aikatt

The 1MHz 6502 outperformed the 4MHz Z80 as well, even though the Z80 had more and bigger registers. Yes, a TAY is only two clocks (125ns @ 16MHz, not 2ns) whereas STA ZP is three clocks, and INY is only two clocks whereas INC ZP is five; but the more complex the instruction decoding becomes (because of things like more internal registers), the lower the maximum speed will be for a given die feature size. I know that one of the design goals for the 6502 was to get really hot interrupt performance, and the 6502 certainly achieved that, certainly beyond any of its early competitors that ran at higher clock speeds, and still beyond many of its more modern competitors.

Since I've never done any processor design, I have to trust that the designers of this one with such hot performance for its simplicity knew the trade-offs. Another one of course is the cost of silicon real estate, which is much, much cheaper today, so maybe the optimum point would indeed allow another pair of index registers, especially if we made the 65Org32, which not only allows over 4 billion op codes (because of the 32-bit byte), but even if we limited the op code table to 256 positions, the fact that ABS and LONG address modes are no longer necessary does open up more spots, perhaps making room for doing the same things we do with X and Y with an X' and Y' as well.

If we were to make the 65Org32, we would need to have the people who do the actual design tell us the trade-offs between different things on the wish list so we can evaluate them. Until I actually see them, my hunch is that for my uses, I would probably prefer to keep the instruction decoding logic simpler so the maximum clock speed can be higher.

Thanks for the URL, lost it some time ago.

But with all respect, this is what I call a simulator, not an emulator. Not having PHI2 (as the site states), I wonder how it can replace a real 6502.
My goal is a CPU that can replace a real CPU using PHI0 as timing.

My design is not using micro-code AFAIK. The AT29C040's I intend to use should mimic the instruction decoder of the real 6502.

But now a for me a bit embarrasing question: how does this micro-code stuff works? I always thought that I had to see it as a mini CPU using only a few basic opcodes needing some cycles to run the actual opcode. But that doesn't explain the few parts Dieter need for his CPU(compared to my design). So if anybody is willing give me more details, I would be very thankfull!

_________________

Microcode is basically defined by the use of a ROM (or RAM), rather than hard wired logic, in order to execute the instructions. Depending on the architecture, some of the bits of the instruction may bypass the microcode and some may be used to select the microprogram which is used to execute the instruction.

Microcoding doesn't necessitate multiple cycle execution; that entirely depends upon the processor. What it does do, however, is make it easier to implement complex instructions.

Microcode tends to set the control bits for various internal components rather than actually executing opcodes as such. For example, a microinstruction on a RISC CPU might look like



Which says "Instruction ADD, Set bus A to register selected by instruction field 1, set bus B to register selected by field 2, set bus C to literal in field 2 sign extended, execute an "add2" operation on the ALU, write register specified by field four, update the zero and carry bits based upon the ALU's output, and then go to the Execute special vector"

Some vectors, like the aforementioned Execute vector, may be special and recognized by the surrounding logic. For example, Execute might be detected and replaced (Before it reaches the microprogram address) with a value based upon the opcode of the instruction.

As microinstructions can get very wide and have lots of fields, microassemblers tend to have lots of defaults which cause the unmentioned functionality to be fed NOPs (or other sane defaults, which may in some cases depend upon other fields: For example, you probably don't want to execute the instruction pointer during the intermediate cycles of a multi cycle instruction, but it should default to being updated when jumping to the execute vector)

Yes, I AM going to say it. Do the math: a register is addressed in the same cycle as the operand-fetch stage of any instruction. Likewise, a cached line of memory is ALSO fetched during this step. Why do you think CPUs have data caches? Even on the x86, they allow single-cycle execution times.

I do not care that you can provide 2ns registers. Caches also are made with the same memory technology as CPU registers. The limiting factor for processor performance is the critical data-path from input to write-back. Usually, this is the ALU itself. You are not going to find a 2ns ALU. That processors have pipelines today is pure evidence of this. Thus, what you need is a memory that is fast enough. Whether 2ns or 20ns is irrelevant as long as the ALU gets its data by the hard real-time constraints it imposes.

The AT&T Hobbit processor had all of four CPU registers -- all C code was compiled to use memory-to-memory (not register-to-register) operations, relying extensively on its cache architecture to provide the gain in performance needed to compete with RISCs. And it did so quite successfully.

What I'm proposing is NOT new.

Thanks for the explanation but.... that is what my design does. In the basic version the EPROM has 14 inputs:
- 4 clock bits
- 8 opcode bits
- 1 bit telling whether a branch should be taken or not
- 1 bit for telling there is a Reset/IRQ/NMI going on
The eight outputs are connected to the clock inputs, Output Enable, latch inputs etc. of the various TTL IC's. So far I need NINE EPROMs for the instruction decoder, not counting two for the ALU and two for some other trick work. Dieter TTL-CPU uses only four and I wonder why so less ???

What made thing more clearer was his ASM file with micro-codes. He used the ALU to increase the Program Counter. As his ALU is only 8 bits wide, he needs several steps for this action. I created a PC based on 74191's, 4-bit pre-loadable up/down counters. To increase the PC I only have to toggle the CLK input of the first 191. So in this case it is speed versus size.

_________________

One could actually say the 6502 is microcoded, as the instruction decoder works as a "microcode". The only "difference" is that in the 6502 the microcode runs at the same speed as the external bus.

André