Hello. Perhaps a dead boring topic already but wanted to write few words as a build log. I made Apple I style computer few years ago using FPGA and now started to build TTL based 6502. Not sure where this path is leading in general but now I'm targeting to have 6502 compliant processor. I try to stay on std gate level but I slipped at least on alu adder (LS283). This project may end on breadboard but Hopefully I have motivation left after working prototype and I will draw a PCB.
The design is not based on other similar projects and surely not based on the original structure. I haven't paid much attention to study documentation of the original design anyway. However my design has inflected by couple of hw projects. At least I need to name bmow as one of them.
Attached image shows a rough design on paper. Basically I design as I go so I don't care to have detailed specs on paper.
My next milestone is to have a working prototype which is able to run a Hello world in Basic.

On breadboard I have perhaps 20% progress today. That includes part of Alu, some registers, phase logic, clock etc.

Axel

Welcome Axel, should be an interesting journey. Surely there's a milestone when you can run one instruction - or two! And it should go up and up.

Sure there are many, many steps to gain the targeted milestone.
BTW: I didn't think that timing design would be such a challenging task. If IR latch&PC++ does not have a phase of its own, timings must be done exactly (within half a cycle). Is there an extra phase for that in the original 6502?

Axel.

The original 6502 does make full use of its two-phase non-overlapping clock, which is not quite like having a double-speed clock, but is a little bit like that. To match the 6502's timings is possible in a modern synchronous design - Arlet's core manages it - but it might well take some head-scratching.

Welcome Axel. I'll be following your project with interest!

If I understand your question correctly, the "latch IR&PC++" puzzle has to do with the 6502's simple pipelining scheme. Many 6502 instructions do double duty in the final cycle, capturing the result of an ALU operation and performing the Opcode fetch/PC++ at the same time. Similarly, you might also find instances where the ALU is used to add an offset to the low-byte of an address at the same time as the processor is fetching the high-byte. Yet another optimization involves fetching the first operand byte even as the Opcode is still being decoded. (If it turns out that the instruction does not take an operand, like say DEX, then the fetched byte is simply discarded and PC++ is inhibited. The same byte will then be fetched again as an opcode in the following cycle).

All this overlapping, of course, makes for more complexity in the datapath and control logic. You end up with a much simpler design by allowing for additional cycles to complete a given instruction. Making the processor cycle-accurate might then be a subsequent milestone.

Hope that helps.

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

Hello and thanks Drass and BigEd. I think I ended up very similar idea in my design what comes to IR fetch/PC++. Proving that idea in practise... well there are a lot of wirings to do... but few elements are already waiting for action.

Axel.

Nice photo! I have breadboard envy.

The first hw setup is now wired. That means a minimal setup which I plan to use for testing the design in practice before drawing PCB. Breadboard has two ALU registers, AR and PC registers, ALU with add/sub/x2/, IR register, phase logic, main databus, mem databus, RAM manual data input logic, variable speed clock and manual clock stepping.

Dry tests (manually controlling logic signals) are passed.
As a next step I'm starting to implement microcodes into control logic eeproms. I'm eager to see if everything works together after I have implemented few instructions.
Actually the beadboard is currently missing flag register. I need to design and test that too before I move on to draw the schematic.

Well, I also have too many control signals to drive. The current control logic needs to beredesigned before I can continue microcode implementation much further.

Now the fun part begins

Axel.

3 x 128KB Flash chips for Microcodes. In detail: 5 flags, 8bit opcode and 4bit phase signals. Now working on Microcode generator which _should_ generate bin-files with less errors. I can concentrate on phase designing and optimization (=Debugging). Maybe I can execute few commands in the coming days/weeks.

Design parameters are still pretty much open. I think I will stick on NMOS 6502 opcodes and nothing more.
Flags register design still open.

Two phase clock works as much as I can test before having signal control Flashes in place. There are four triggering points. That means one clock cycle is one machine cycle.
Edge0: PC_OUT (put Instruction ready for IR in Phase 0)
Edge1: Instruction latch and PC counter ++ (necessary outputs to enable state and required latches ready for next rising edge)
Edge2: Main latching point. Register latches etc.
Edge3: Next phase or Phase reset

WE signal for RAM still under investigation. Current design probably does not respect general requirement that address lines should be stable before or at the same time when WE goes down. Due to control logic WE probably goes low slightly before address is set.

Axel.

Nibble to 7 segment drivers are more or less obsolete today. That is shame because there were handy for many applications. It takes much more wires to build two digit nibble display using eprom etc. (Yes I'm aware of plds )

I'm waiting for eproms to finish microcode control. Still don't know whether this is just a pile of wires or can we call it a computer...

Axel

While waiting for parts I drew the first draft of schematic. It might contain errors and it surely is a big mess, but I'll publish it anyway. Topology overview follows.
I modeled few commands and here is what microcode looks like in the AComputer (or at least in theory looks like that...):

--------------------------
Opcode: $02 / Processor HALT (NMOS phases 0)
*: Phase reset

Opcode: $69 / Add M to A with Carry Immediate (NMOS phases 2)
*: PC++; T <- MEM(PC);
C=0: PC++; A <- T + A; Latch_ALL; Phase reset
C=1: PC++; A <- T + A + 1; Latch_ALL; Phase reset

Opcode: $8D / Store A in M Absolute (NMOS phases 4)
*: PC++; ARLO <- MEM(PC);
*: PC++; ARHI <- MEM(PC);
*: PC++; //should also work if the next phase is combined in this phase
*: MEM(AR) <- $FF + A + 1; Phase reset

Opcode: $A9 / Load A with M Immediate (NMOS phases 2)
*: PC++; A <- MEM(PC);
*: PC++; Latch_NZ; Phase reset

Opcode: $E6 / Increment M by One Zeropage (NMOS phases 5)
*: PC++; ARLO <- MEM(PC);
*: ARHI <- 0 + 0;
*: T <- MEM(AR);
*: MEM(AR) <- T + 0 + 1; Latch_NZ; Phase reset

Opcode: $EA / No Operation (NMOS phases 2)
*: PC++; Phase reset

Flag operations still missing. I have no ideas at the moment how to implement status register and flag operations...

Axel.

Block diagram:

Fun project!

What sort of chips do you plan to use? You mentioned the '283 adder. (So, no '181 ALU chips, I guess.) Will you be using a '574 for each register? And 257's (or similar) for the multiplexers?

cheers
Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Hello,

The first draft of the schematic is attached two messages above. Yes, 283s for adder, 173s for registers. There aren't much comments in the schematic but signal names and block diagram probably clarify everything.

Timing diagram of different clock signals.