Following my CPLD version of the 6502, I am planning to making another implementation using simple "TTL" logic. The term "TTL" is in quotes because it doesn't refer to the technology, but rather the simplicity of the logic devices.

My goals are a bit different than other "TTL" projects, such as Drass' recently completed design, to avoid straight duplication of efforts, and hopefully produce another interesting angle. Here's a short list of preliminary requirements and self-imposed rules:

• Only use basic logic devices. This means no ready-made ALUs, no full adders, no programmable devices (including EPROM/Flash). I can use simple gates, (octal) flip-flops, buffers/selectors/muxes/decoders, and similar.
• Make it educational so that anyone interested in CPU design or the 6502 can study the design.
• Focus on simplicity rather than speed. Target is retro speed (~2 MHz), but I'll try to make it as fast as possible within simplicity constraint.
• Lots of blinkenlights. I want to include LEDs to indicate value of all major signals and registers so it's possible to single-step through code and follow along. This makes the design a bit harder, because I can't use registers with built-in tri-state buffers to send data to a common bus. Instead I have to use regular registers, followed by the LEDs, and external mux/tri-state buffers so you can always see contents of X/Y/A/etc register, even if it's not being used.
• Single PCB (for the core), as compact as possible, but try to leave some room for explanatory text in silk screen.
• Fast and modern 3.3V logic families, as much as possible in compact TSSOP-14/16/20 packages
• Clean design and layout. Try to avoid a chaotic maze of gates. This will make it easier to pack things close together without routing problems, and also makes it easier to follow along with the operation.
• Loose compatibility with the NMOS 6502. All instructions implemented, including BCD, IRQ, RDY so you can run most regular software, but not cycle accurate, nor any attempt to support illegal instructions, or unintended quirks/bugs of the original.

If at some point these requirements are too hard to meet, I may relax some of them, or choose to cancel the project.

I have the following steps planned:

1. Create initial design in Verilog. This allows quick simulations to make sure the design works correctly (pass the Klaus Dormann tests for instance). Start with a functionally correct design in high level fashion, but then iteratively map parts to real logic.
2. Make a prototype board where datapath is made with simple logic devices, but keep an FPGA for the control logic to allow easy and flexible debugging and testing.
3. Make a final board where FPGA is replaced by some sort of hard coded PLA design.

I'll follow this with great interest! I guess at 30cm square board.

Made Github project, with initial verilog design file. https://github.com/Arlet/ttl-6502

Passes Klaus' test, but with some missing features. I'm still debating on how to do the BCD correction with minimal resources, but I'm leaning towards an extra cycle where the binary result is fed back into ALU adder to have +6/+10 corrections applied.

Based on CPLD ideas, but again using ALU for address calculations. This should help lower gate count by having only a single full adder in entire design. Requires a few extra dead cycles, but does better than NMOS 6502.

It might be amusing to use the same BCD correction as the 6502 (from the patent perhaps) and maybe on a little daughterboard, or with a box around it, to show the cost.

I was hoping for Eurocard (10x16 cm) size, but too early to tell whether that's feasible.

Advantage of this method is that you don't get performance penalty in binary mode. I think that's most useful, because BCD mode is so little used.

I intend to use ripple carry in ALU, so there's already a performance hit. Adding a second hit in the form of a rarely needed BCD correction doesn't sound appealing. Better to use an extra cycle when needed. Also, extra cycle could be skipped if there's no need for correction, improving performance for simple +1 BCD counters.

Great project Arlet. I’m interested to see what trade offs you end up with. I also like the notion of a PLA design for the control logic.

Might be hard to fit components and blinkenlights on one Eurocard — or are you planning a separate “control panel” pcb?

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

Agreed it will be a challenge. But if I need more room, I'll just make the board bigger rather than adding a second board. I'm planning to add some expansion headers in either case, for external interfaces, such as video or SD card, just to make it easier to experiment later without having to redo the core layout.

Hmm ... blinkenlights ...

What about 2 colors:
Or perhaps 3 colors:

Arne

Thanks for the suggestion, but I think I'll stick with simple single color LEDs in 0603 package, and not too many different colors. I think 0603 is big enough to see what's going on, and hopefully compact enough to not hog the board.

I have a first rough version of the BCD correction working, but I'm not entirely happy with it yet, so I'm going to try to clean it up a bit more. Plan of action:

1. clean up/test BCD
2. move ALU to its own module
3. rewrite ALU in lower level logic
4. create ALU schematic

If you're not aiming for bug/quirk compatibility with NMOS, why not aim for 65C02 compatibility? Perhaps without the bit-ops.

Because I'm trying to keep it as simple as possible. Adding and removing cycles, and picking and choosing what instructions to support helps with that.

I'll start by designing the data path to support the NMOS instructions. If I can add some 65C02 opcodes by extending the PLA, without running out of board space, that's an option for later.

I'm also not aiming for this board to be a drop-in replacement in existing hardware. It's going to be a standalone thing, with it's own I/O, so that removes most requirements for supporting strange corner cases.

Here's the plan for the ALU (shows one bit slice). There's an AI input and a BI input. The AI input can be one of the 4 registers, a 5th register M, or program counter low/high. The BI input always comes from M, but can be optionally cleared or inverted, or both, allowing for add, subtract, increment, or decrement.

An 8:1 mux picks one of the 7 operations: AND/OR/EOR/ROL/AI/ROR/ADD. An eigth input is still free. The AI operation just passes the AI input to the output. Carry goes in from top, and ripples down to next slice.

For BCD operations, the idea is to store the output of the binary addition in A, and at the same time, store the BCD adjustment in M. An extra cycle follows where A+M is calculated and stored in A again.

Each slice uses 4 ICs: the MUX, quad AND, quad OR and quad XOR. There is one XOR, one AND, and two OR gates left over, which I hope to use for Z-flag and decimal carry generation.

And here's preliminary layout check I did earlier. There's still some room left for traces to connect the other gates. As you can see, I like to work on all phases of the project at the same time, rather than work strictly top-down.

:thumbsup:

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502