opcodes and addressing modes – the 6502

Of course our first action needs to be implementing all of the opcodes the 6502 offers. The first thing I noticed was the different addressing modes the 6502 has.

For comfort, I just implemented each addressing mode as a function in the MMU, so whenever we need to address something, no matter if it is for a read or a write, we can just get the desired address by passing the values to our addressing functions.

unsigned char readFromMem(uint16_t adr);
uint16_t getImmediate(uint16_t adr);
uint16_t getZeropage(uint16_t adr);
uint16_t getZeropageXIndex(uint16_t adr, uint8_t X);
uint16_t getZeropageYIndex(uint16_t adr, uint8_t Y);
uint16_t getIndirectXIndex(uint16_t adr, uint8_t X);
uint16_t getIndirectYIndex(uint16_t adr, uint8_t Y);
uint16_t getAbsolute(uint16_t adr);
uint16_t getAbsoluteXIndex(uint16_t adr, uint8_t X);
uint16_t getAbsoluteYIndex(uint16_t adr, uint8_t Y);

With this done, we can now start implementing the opcodes of the 6502, which turn out to be quite a few less than on the Gameboy.

The legal opcodes are linked to the description. The illegal opcodes are grey and not important for the moment. The address mode is in the bottom left, the timing in the bottom right. “+” indicates another cycle on a page boundary breach, “*” indicates another cycle, if the branch is taken. The affected flags are colored red at the bottom.

int stepCPU() {
	switch (readFromMem(PC)) {
		case 0x29: { PC++; return AND(getImmediate(PC), 2); PC++; break; }
		case 0x2d: { PC++; return AND(getAbsolute(PC), 2); PC += 4; break; }
		case 0x39: { PC++; return AND(getAbsoluteYIndex(PC, registers.Y), 4); PC += 2; break; }		//	TODO +1 cyc if page boundary is crossed
		case 0x3d: { PC++; return AND(getAbsoluteXIndex(PC, registers.X), 4); PC += 2; break; }		//	TODO +1 cyc if page boundary is crossed
...

Most of the opcodes are fairly easy to implement, probably only ADC and SBC are the ones, that might give a headache.

ADC adds the value of the memory at the given address to the accumulator, plus the carry bit as well. Where SBC does the same, only subtracting the values from the accumulator. Therefore we can just write the ADC function, and use an inverted value as argument for it, to use it as SBC as well.

uint8_t ADD(uint8_t val, uint8_t cycles) {
	//	TODO handle bcd when decimal flag is set
	uint16_t sum = registers.A + val + status.carry;
	status.setOverflow((~(registers.A ^ val) & (registers.A ^ sum) & 0x80) > 0);
	status.setCarry(sum > 0xff);
	registers.A = sum;
	status.setZero(registers.A == 0);
	status.setNegative(registers.A >> 7);
	return cycles;
}
uint8_t ADC(uint16_t adr, uint8_t cycles) {
	return ADD(readFromMem(adr), cycles);
}
uint8_t SBC(uint16_t adr, uint8_t cycles) {
	return ADD(~readFromMem(adr), cycles);
}

The flags affected are zero, negative, carry and overflow (also decimal is important, but will be later added, when we use this CPU for the C64 emulation, as the NES’s CPU wasn’t capable of using this, probably just by a cut trace on the PCB).

Note: You can never have an overflow flag set, when the two inputs have different signs, as the range does not allow it.

For testing purposes I ran nestest, a testing ROM for almost all CPU behaviors. (Credits go to Kevin Horton, sadly I was unable to find a github or something else to link him to. Make sure to read his README)

Nestest provides a log file, with a proper output, that way, we can compare our output to it, and see how well it matches, and where our CPU might be going wrong.