Visual6502wiki/6507 Decode ROM
The Decode ROMTemplate:Ref is a 130x21 bits ROM in the 6502 that is used to decode the instruction and to control various units of the CPU.
Some basic (maybe partially incorrect) information: http://www.pagetable.com/?p=39
This is a verified correct transcription of the ROM, taken from the Atari 6507 diagram sheets (this ROM differs from the one in the NMOS 6502, as simulated by the [visual6502 simulator]):
100XX1XX 3 X STY XXX100XX 1 3 T3INDYA XXX110XX 1 2 T2ABSY 1100XXXX 3 0 T0CPYINY 100110XX 3 0 T0TYAA 1X0010XX 3 0 T0DEYINY 000000XX 3 5 T5INT 10XXXXXX 2 X LDXSDX XXX1X1XX X 2 T2ANYX XXX000XX 1 2 T2XIND 100010XX 2 0 T0TXAA 110010XX 2 0 T0DEX 1110XXXX 3 0 T0CPXINX 100110XX 2 0 T0TXS 100XXXXX 2 X SDX 101XXXXX 2 0 T0TALDTSX 110010XX 2 1 T1DEX 111010XX 3 1 T1INX 101110XX 2 0 T0TSX 1X0010XX 3 1 T1DEYINY 101XX1XX 3 0 T0LDY1 1010XXXX 3 0 T0LDY2TAY 0XX0X0XX 3 2 CCC 001000XX 3 0 T0JSR 0X0010XX 3 0 T0PSHASHP 011000XX 3 4 T4RTS 0X1010XX 3 3 T3PLAPLPA 010000XX 3 5 T5RTI 011XXXXX 2 X RORRORA 001000XX 3 2 T2JSR 01X011XX 3 X JMPA XXXXXXXX X 2 T2 XXX011XX X 2 T2EXT 01X000XX 3 X RTIRTS XXX000XX 1 4 T4XIND XXXXXXXX X 0 T0A XXXX0XXX X 2 T2NANYABS 010000XX 3 4 T4RTIA 00X000XX 3 4 T4JSRINT 0XX0XXXX 3 3 NAME1:T3_RTI_RTS_JSR_JMP_INT_PULA_PUPL XXX100XX 1 3 T3INDYB XXX000XX 1 3 T3XIND XXX100XX 1 4 T4INDYA XXX100XX 1 2 T2INDY XXX11XXX X 3 T3ABSXYA 0X1010XX 3 X PULAPULP 111XXXXX 2 X INC 010XXXXX 1 0 T0EOR 110XXXXX 1 0 T0CMP 11X0XXXX 3 0 NAME2:T0_CPX_CPY_INX_INY X11XXXXX 1 0 T0ADCSBC 111XXXXX 1 0 T0SBC 001XXXXX 2 X ROLROLA 01X011XX 3 3 T3JMP 000XXXXX 1 0 T0ORA 00XXXXXX 2 X NAME8:ROL_ROLA_ASL_ASLA 100110XX 3 0 T0TYAB 100010XX 2 0 T0TXAB X11XXXXX 1 1 T1ADCSBCA 0XXXXXXX 1 1 NAME7:T1_AND_EOR_OR_ADC 0XX010XX 2 1 NAME4:T1_ASLA_ROLA_LSRA 011010XX 3 0 T0PULA XXX11XXX X 4 T4ABSXYA XXX100XX 1 5 T5INDY 101XXXXX 1 0 T0LDA XXXXXXXX 1 0 T0G1 001XXXXX 1 0 T0AND 0010X1XX 3 0 T0BITA 0XX010XX 2 0 NAME6:T0_ASLA_ROLA_LSRA 101010XX 2 0 T0TAX 101010XX 3 0 T0TAY 01X010XX 2 0 T0LSRA 01XXXXXX 2 X LSRLSRA 001000XX 3 5 T5JSRA XXX100XX 3 2 T2BR 000000XX 3 2 T2INT 001000XX 3 3 T3JSR XXXX01XX X 2 T2ANYZP XXXX00XX 1 2 T2ANYIND XXXXXXXX X 4 T4 XXXXXXXX X 3 T3 0X0000XX 3 0 T0RTIINT 01X011XX 3 0 T0JMP 0XX0X0XX 3 2 NAME3:T2_RTI_RTS_JSR_INT_PULA_PUPLP_PSHA_PSHP 011000XX 3 5 T5RTS XXXX1XXX X 2 T2ANYABS 100XXXXX 1 X STA 010010XX 3 2 T2PSHA XXX100XX 3 0 T0BR 0XX010XX 3 X PSHPULA XXX000XX 1 5 T5XIND XXXX1XXX X 3 T3ANYABS XXX100XX 1 4 T4INDYB XXX11XXX X 3 T3ABSXYB 0X0000XX 3 X RTIINT 001000XX 3 X JSR 01X011XX 3 X JMPB 11X00XXX 3 1 T1CPX2CY2 00X010XX 2 1 T1ASLARLA 11X011XX 3 1 T1CPX1CY1 110XXXXX 1 1 T1CMP X11XXXXX 1 1 T1ADCSBCB 00XXXXXX 2 X NAME5:ROL_ROLA_ASL_ASLA X1XXXXXX 2 X LSRRADCIC 0010X1XX 3 1 T1BIT 000010XX 3 2 T2PSHP 000000XX 3 4 T4INT 100XXXXX X X STASTYSTX XXX11XXX X 4 T4ABSXYB XXXX00XX 1 5 T5ANYIND XXX001XX X 2 T2ZP XXX011XX X 3 T3ABS XXX101XX X 3 T3ZPX 0X0010XX 3 2 T2PSHASHP 01X000XX 3 5 T5RTIRTS 001000XX 3 5 T5JSRB 01X011XX 3 5 T4JMP 010011XX 3 2 T2JMPABS 0X1010XX 3 3 T3PLAPLPB XXX100XX 3 3 T3BR 0010X1XX 3 0 T0BITB 010000XX 3 4 T4RTIB 001010XX 3 0 T0PULP 0XX010XX 3 X PSHPULB 101110XX 3 X CLV 00X110XX 3 0 T0CLCSEC 01X110XX 3 0 T0CLISEI 11X110XX 3 0 T0CLDSED 0XXXXXXX X X NI7P X0XXXXXX X X NI6P
The format is:
76543210 G T NAME
- The first column represents the 8 bits of the IR. 1 means the bit has to be 1 for the line to fire, 0 means the bit has to be 0, X is a don't care. Note that the lower two bits are always XX - the decode ROM doesn't actually check these, but check a cooked version of these bits instead.
- The second column is the "G" input, it must match 1, 2, 3 or it's a don't care. G is derived from the lower two bits of the IR:
G1 = IR0 G2 = IR1 G3 = !IR0 & !IR1
- The third column is "T", which is the clock cycle in which the line fires (0..5).
Some observations:
1. There are 15 duplicates in the decode ROM:
$ for i in `sort pla.txt | cut -c -12 | uniq -c | sort -n | grep "^ 2" | cut -c 6-17 | sed -e "s/ /./g"`; do grep $i pla.txt; done
We assume this has been done because they had no way of routing the output of some line where they wanted, so they put the same line at a different location again.
2. As an example, ADC # is 2 cycles, but there are lines that match T=[2..4]. In practice, these will never fire; they are meant for other instructions that have a similar encoding and do have T>2.
3. About G, and how it explains many illegal opcodes: Orlando and I reverse engineered this by dumping operation lists with decode.rb and filtering which Gs made sense. The funny thing here is that this leads to the table:
00 -> G3 01 -> G1 10 -> G2 11 -> G1/2
11 is the don't care case, there are no opcodes XXXXXX11 that are documented. So in order to simplify the G encoding, 11 has both G1 and G2 turned on, so all G=1 and G=2 lines fire. And this explains A LOT of things, like how LDA (0xAD, G=1) and LDX (0xAE, G=2) become LAX (0xAF, G=1 and G=2):
LDA T=0 XXXXXXXX X 0 T0A 101XXXXX 1 0 T0LDA XXXXXXXX 1 0 T0G1 X0XXXXXX X X NI6P LDX T=0 10XXXXXX 2 X LDXSDX 101XXXXX 2 0 T0TALDTSX XXXXXXXX X 0 T0A X0XXXXXX X X NI6P LAX T0 10XXXXXX 2 X LDXSDX 101XXXXX 2 0 T0TALDTSX XXXXXXXX X 0 T0A 101XXXXX 1 0 T0LDA XXXXXXXX 1 0 T0G1 X0XXXXXX X X NI6P
...which is pretty much LDA and LDX joined!
If you look at http://www.oxyron.de/html/opcodes02.html , you can see that columns 3, 7, B and F are illegal; this is the G=1+G=3 case. These columns basically execute all operations of the two preceding columns at the same time. Note that (as far as I checked) the cycle count (number in the table) is always the MAX() of the two opcodes it consists of.
This was known:
http://www.viceteam.org/plain/64doc.txt
Other undocumented instructions usually cause two preceding opcodes being executed.
But now we have more of a clue what's happening there...
Column 2 is KIL, column 3 has mostly *8* cycle instructions, which is weird. There are no regular 8 cycles ones. Not sure this is accurate in the docs. I see a correlation between the KIL and the 8 cycles. My theory is that KIL overflows the cycle counter. Not sure why column 3 doesn't inherit that feature.
The MAX() property and the KIL/Column 3 thing might explain how the cycle counter gets reset to 0... what triggers that. Orlando is also looking into this, comparing neighbor opcodes that terminate differently.
Here is the ruby program that accepts an opcode at the command line and prints the sequence of clocks:
#! /usr/bin/env ruby
if ($*.length < 1)
print "usage: #{$0} <value>\n"
exit
end
opc = eval($*[0])
b0 = (opc & 1) != 0
b1 = (opc & 2) != 0
gmatch = Array.new
gmatch[1] = b0
gmatch[2] = b1
gmatch[3] = !b0 && !b1
bin = ("%08b" % opc)
input = Array.new
File.open('pla.txt').each_line do |s|
next if s =~ /^#.*/ # skip lines starting with '#'
input += [ s.chop.split(/ /) ]
end
6.times do |time|
print "T=#{time}\n"
input.each do |ni, g, t, name|
print "#{ni} #{g} #{t} #{name}\n" if (bin.match(ni.gsub(/X/, ".")) && (t == "X" || time == t.to_i) && (g == "X" || gmatch[g.to_i]))
end
print "\n"
end
It also needs to read a file 'pla.txt' which has a tabulation as found here.
Notes
- Template:EndnoteThe "Decode ROM" is named as a ROM in Hanson's block diagram, although it has wordline inputs and no address decoder. It is sometimes described as a PLA although it also lacks an AND plane. It is a structured layout of NOR gates with many common inputs, as compared to the unstructured gates found in the central decode logic, sometimes known as the random logic (meaning not structured).
