Hi everyone,

I'm just trying to figure out the pinout for the 6502's ALU. I found that picture that everyone uses to reference how the 6502 works inside (http://homepage.mac.com/jorgechamorro/a2things/6502.jpg) but I only see 5 instruction inputs for the ALU: SUMS, ANDS, EORS, ORS, and SRS. It seems to me that more inputs than this would be needed; for example, the SRS input is labeled "shift right," yet the 6502 can also shift left, so what input would be used for that instruction? I really can't make any sense of how the ALU uses its control inputs at all; can someone please shed some light on this?

A shift left is easily achieved by merely adding the accumulator to itself. Thus, ASL A == CLC; ADC A (if ADC A were available as an instruction on the 65xx architecture).

For the rest of the inputs, I haven't a clue.

I haven't concerned myself much with what goes on inside the processor, but if you look at the op code table, you'll definitely see patterns. For example

• the conditional branches are all in odd-numbered rows of column 0
• the "Load" op codes are all in rows A and B
• the "Store" op codes are all in rows 8 and 9
• the "subtract" op codes are all in rows E and F, etc..
• All the op codes in column 0 are 2-byte
• all the ones in columns 8, A, and B are 1-byte
• all the ones in columns D and E are 3-byte, and
• all the ones in column 4 are 4-byte. (I'm looking at the '816 table at the moment, but it mostly has the same things the '02 does, just more.)
• In column 3, all the odd-numbered rows take 4 clocks, and all the even-numbered ones take 7.
• You have a similar situation in column 5 with alternate rows taking 3 and 4 clocks.
• All of column 1 uses the accumulator, and the addressing mode alternates between (d,x) and (d),y (or in the case of 6502, (zp,x) and (zp),y) in even- and odd-numbered rows.
• The addressing mode of every odd-numbered row in column 2 is (d) (or (zp) in the case of the 6502).
• Column 3's addressing modes alternate between d,s and (d,s),y.

There are lots more of these patterns. I think you could derive some kind of formula (for lack of a better word) showing how various bits pick the source and destination registers, number of clocks (or should I say the cycle sequence), number of bytes in an instruction, the indirection, indexing, etc.. A few will require more logic to fit them in, but they're the exceptions.

That's a good analysis from the point of view of a programmer, but does not address the original poster's quest to understand how the ALU itself works inside the CPU. No relationship between opcode and ALU inputs are guaranteed, since none of the opcode bits directly drive the ALU inputs. The instruction decoder is responsible for providing this mapping.

That diagram actually shows very well how subtraction works: The processor just inverts the bits, and then does an add with carry on them (thus why carry must be set before performing a subtraction)

The ALU works in conjunction with several other components of the diagram under direction from control signals generated from the random control logic.

The signals SUMS, ANDS, ORS, EORS and SRS select the required operation to be applied to the operand values supplied by the A input register and B input register. The DAA input is used to tell the ALU if its working in decimal mode or binary so that it can change its look ahead carry logic to correctly predict the output carry. The carry input can be loaded from the C bit of status register or a constant 0.

During most instructions the A input register is loaded with the contents of the accumulator or address bytes from the instruction or zero page during indexed and indirect address calculations.

The B input register is normally loaded with immediate data bytes, values read from memory or constant values (e.g. 0, 1, 2) created by the open drain MOSFETs. When an immediate or memory data byte is loaded it can be read directly or inverted to support subtract. The constant values are primarily used when the ALU is calculating target memory addresses during instruction execution.

As kc5tja says the ALU uses its addition function (SUMS) to perform left shifts (by loading AI and BI with the same value) and subtractions (by loading an inverted value into BI) as well as normal addition.

Normally a SUMS calculates AI + BI + C to determine a result value and carry out. Inverting the bits in a signed binary number is equivalent to calculating -1 - BI. Substitutung this into an addition gives:

AI + (-1 - BI) + C which rearranges into the subtraction AI - BI + C - 1 (e.g. the SBC operation)

Note that this expression also shows why the carry bit must be set to subtract two values with no borrow (e.g. AI - BI - (1 - 1) = AI - BI) and clear in to cause a borrow (e.g. AI - BI - (0 - 1) = AI - BI - 1).

The ALU has an asynchronous design, its outputs change whenever its inputs change - it is not synchronised to a clock signal so its output is captured by a latch register than can be controlled synchronously and can also be fed back into the ALU A input (for address calculations).

The other outputs from the ALU are an output carry, an overflow and a half carry. The half carry is used to correct the result of the binary addition performed by the ALU into a proper BCD result.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

I'm not sure if you're responding to me, but that "diagram" shows very well that what I said is quite true. The 65816 has opcodes placed which don't always fit the rules established by the 6502.

It only re-inforces what I said earlier: the ALU inputs are driven by the instruction decoder, and any correlation between opcode bits cannot be guaranteed.

In no way, shape, or form, did I not insinuate that opcodes couldn't direct-drive the ALU stages -- there are plenty of CPUs that do this (most RISC and TTA CPUs, for example), and it's pretty clear that the 6502 usually does this. But, I cannot guarantee that this property holds true at all times, and I know it doesn't always hold for the 65816.

hmm....that came out entirely more heated than I intended. I must have been angry about something at the time, but I can't remember what. Either that, or I was suffering from a headache. At any rate, I'll just apologize in advance for that.

Oops - not quite. I printed out and taped together the giant circuit diagram by Balazs Beregnyei, found those open drain FETs on page 10, and tried to figure out what they do. In fact, they conditionally pull down the low 3 bits of the address bus, to fetch the right vectors from high memory.

I don't think there are any constants used by the ALU. It can add zero, with an optional carry. Is that enough?

Ed

See Dia's translations of some of Balazs' work, including 6502 Integration.pdf which covers the ALU. Pagetable has an excellent article with links to other good information.

Edit: better link: single pdf of the 6502 circuit diagram

On reflection I think you're right. Its been a while since I've looked at this in detail.

Evaluating indirect addresses (e.g. JMP ($1234) or LDX ($01,X)) requires an increment during effective address calculation which needs AI loaded with zero and carry in to forced 1.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

I wasn't

Thank you, everyone, for your excellent input; I didn't realize that you could do a shift-left by simply adding a number to itself, although of course it seems obvious now that I think about it. I was aware of that huge PostScript file containing a schematic of all the FETs in the 6502, but hadn't seen the translated explanation before, which turns out to be incredibly helpful for a non-Hungarian speaker like myself.

By the way, as some of you might have guessed, I am building a homebrew 6502 from scratch, so you may see occasional weird questions about the internal structure of the 6502 popping up from me here; I appreciate all the assistance, and hopefully when I'm done I'll be able to release something interesting and useful to the world. =)

How? 74 logic? Programmable logic? Something else?

Mostly 74 logic. I expect to use a ROM microcode, but I'm hoping everything else can be 7400-series chips. Because the intent of this project is really to open up the 6502 as much as possible so that everything is accessible to oscilloscope, logic analyzer, or what have you, I want to avoid using FPGAs or any other kind of PLD.