I don't know how to make it. I just don't. I only know that it uses a PLA, I don't know the bit layout, nor the parameters, nor anything else. Help me please.

>Help me please.

As there's learning involved you'll need to do most of the work yourself. First be sure you're clear on what the PLA does.

With 65xx family every instruction consumes multiple cycles. On the first cycle the opcode is fetched and saved internally, and in later cycles this determines the various corresponding actions which need to happen -- for example selecting an ALU function, or cueing an internal register to update itself from one of the internal buses. The PLA coordinates this. It inputs the opcode and the counter that says which cycle is presently happening. Then the outputs of the PLA trigger whatever actions need to happen in that particular cycle for that particular instruction.

You may also want to read up on microcode, which is an alternative approach (and probably easier if you want to build something yourself). It does the same job, though. Microcode is stored in a dedicated memory which is used as a lookup table to say what needs to happen in any particular cycle of any particular instruction.

-- Jeff

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

I'd recommend, I think, tackling a simple CPU first. The 6502 is clever and featureful.

But on the 6502 front, if you're interested in the implementation of the real thing, I'd recommend having a look around the visual6502 wiki and playing with the visual6502 simulation.

The simplest re-implementation I know of is Arlet's 6502 core - that's worth having a look at too. As Jeff says, you will have to put in some effort to understand what's going on in the 6502! And also as he says, there are many possible ways of implementing a 6502, which needn't be especially close to the original implementation.

What kind of implementation are you planning?

BigEd, I'm planning to make a Minecraft MOS 6502. I'm only 13 and I know nothing about electricity thingies, I don't have the materials either. .

ah, minecraft - an interesting choice of substrate! But that's fine, logic is logic - electricity barely comes into it.

Have you got the idea about the distinction between combinatorial logic and sequential logic? For example, have you built a counter? A counter might be a good thing to start with, then a clock. It's a journey well worth undertaking, but is it quite a journey and a 6502 is not right at the start of it.

(There's also a book and a free course which might interest you: nand2tetris. Bearing in mind that different people have different learning styles, and one of the things to do in life is to figure out what works for you.)

Oh, I've been building Hack CPUs for a full year now, I even wrote the assembler! But I'm lazy to continue with the software hierarchy. I'm not a complete newbie in computer engineering, I've built some CPUs in Logisim and Minecraft and I even know advanced topics like pipelining. I just didn't know too much about the 6502's IS and I was lazy to think. Thanks for the help

Ah, OK, that's a much better starting point! There's a page on the 6502 PLA here:
http://visual6502.org/wiki/index.php?ti ... Decode_ROM

(It's not really a PLA, or a ROM. It's just a compact and regular way to implement a large number of NOR gates, with inputs taken from the same set of signals. In this case, 21 signals, which represent the IR outputs and the timing state, and (may of?) their inverses, and one (or more) other helpful signals.)

BigEd, correct me if I'm wrong but: the 6502's IS is just 8 bit, and it's the function. Where are the arguments? Which pins are the arguments?

Yes, the IR is 8 bits, for the opcode. The operands don't need to go to the control logic, as they don't affect the setup of the datapath or the sequencing of operations. The operand(s) come in through the databus, and are steered fairly directly to their destination in the datapath - or in a few cases, like the last byte of a JMP, steered directly to the latches behind the address pins.

Do you have Donald Hanson's block diagram in front of you? It could be a useful constant reference.
http://visual6502.org/wiki/index.php?ti ... ck_Diagram

BigEd, how does the 6502 deal with it's arguments? The opcode section is easy, just make a PLA or some microcode, but I'm struggling so hard with the arguments! I don't know how to deal with arguments, help is appreciated.

As a very simple example, take
LDA #0
or for better visibility
LDA #$ED

In the first cycle, the LDA byte is read, comes in over the databus, and is steered to the IR. The PC is incremented.

In the second cycle, the control logic digests this byte, and sets things up. Also, the second byte comes in over the databus - this always happens, with no influence from what the opcode was. This operand is headed for the IDB, the internal databus.

In the third cycle, which overlaps with the fetch of the next instruction, the operand byte is now on the IDB, and is routed over the special bus SB through the decimal adjust logic to the accumulator A.

Have a good long look at this tabulation, in combination with Donald's block diagram:
http://visual6502.org/JSSim/expert.html ... loglevel=8

The thing to understand is that the datapath is controlled by the datapath control signals, and they are derived from the outputs of the PLA. It's in the datapath that all the arithmetic, logic, and data movement happen.

It might help to draw out the sequence on several copies of the block diagram. With coloured pencils. Don't underestimate the power of pen and ink - it's enormously easier to think with pen and paper than with keyboard and screen. At least, it is for me.

Not that, I mean how does it actually implement the arguments. People told me to use MUXs and decoders but I don't know how, I'm talking about hardware.

Do you know about registers and busses and multiplexors? I think that would a good basis.

But two things trouble me: "implement" and "decoders" - those words seem out of place and might indicate some misunderstanding or mistaken assumption.

Yes, by implement I'm referring to the CU. For example: to implement the opcode, you can just have a PLA. But what about the arguments? How does the CPU where do redirect that byte? Because in one instruction they might be register address (it's an example, I know nothing about the actual IS from the 6502) but on another instruction, those same bits might be branch target or something. I'm talking about arguments that do different things depending on the instruction.

It's the job of the control unit to direct the datapath! The incoming operand bytes must be steered to the appropriate place, for example:
- one of the registers
- the ALU, as an operand of a do-something opcode
- the ALU, with a register value, as the operand of an indexing action
- the ALU, with the PC low byte, as a relative branch
- the address bus, as the operand of an opcode with zero page addressing mode
- the PC, as the operand of a jump