Page 15 of 24
Posted: Mon Apr 09, 2012 10:41 pm
by ElEctric_EyE
Ok, adding the opcode decoding for the W register has forced me to clean up the opcode table I was using from WDC6C02. What a mess that is/was! Anyway, I have changed just a few values of some opcodes previously added. Like INC [A..Q] and DEC [A..Q] now match the WDC65C02 for the A Accumulator at $xx1A and $xx3A and a couple other new ones were moved to make decoding the W reg easy and only a column or 2 off from the Y reg. Yes, the W reg is like the Y reg.
Take a look, here is the bottom layer (i.e. upper 8 bits of opcodes = $00)of the
FINAL 65ORG16.b core!!!!
I have to finish re-editing the macro's I presently have, then I can start testing. The verilog is already done. Not too difficult at all to modify the machine. The difficulty is keeping all the opcode encodings from getting tangled!
I have a little bit more editing to do on the above table... The only opcodes I have left to add are TXW, TYW, TWX, TWY.
This will be it for the 65Org16.b!

Posted: Tue Apr 10, 2012 10:55 pm
by ElEctric_EyE
I've "de-optimized" Arlet's opcode state machine in order to make sure I have every single bit perfect
as it needs to be to obey the opcode table above, or the Sim will crash as it has been doing all day, at least on my fast machine, with ISE13.2, it is crashing. On my slow laptop, with ISE13.4, the Sim appears to be correct... I'm not blaming ISE at this point. I find errors in my opcode decoding frequently. It's not pretty, but progress will be made!
Code: Select all
/*
* Microcode state machine */...
casex ( IR[15:0] )
16'b0000_0000_0000_0000: state <= BRK0;
16'b0000_0000_0010_0000: state <= JSR0;
16'b0000_0000_0100_0000: state <= RTI0; //
16'b0000_0000_0100_1100: state <= JMP0;
16'b0000_0000_0110_0000: state <= RTS0;
16'b0000_0000_0110_1100: state <= JMPI0;
16'bxxxx_xxxx_xxx0_01xx: state <= ZP0; // even rows, columns 4,5,6,7
16'b0000_0000_xxx1_0000: state <= BRA0; // odd rows, column 0
16'bxxxx_xxxx_xxx0_0001: state <= INDX0; // even rows, column 1 --(zp,x)
16'bxxxx_xxxx_xxx1_0001: state <= INDY0; // odd rows, column 1 --(zp),y
16'bxxxx_xxxx_xxx1_0010: state <= INDY0; // odd rows, column 2 --(zp),w
16'bxxxx_xxxx_0xx1_0101: state <= ZPX0; // row 1,3,5,7, column 5
16'bxxxx_xxxx_0xx1_0110: state <= ZPX0; // row 1,3,5,7, column 6
16'bxx00_xx00_10x1_010x: state <= ZPX0; // row 9,B, column 4,5
16'b0000_0000_0111_0100: state <= ZPX0; // STW zpx
16'bxxxx_xxxx_11x1_01xx: state <= ZPX0; // row D,F, column 4,5,6,7
16'bxxxx_xxxx_0010_1100: state <= ABS0; // BIT abs
16'bxxxx_xxxx_0xx0_1101: state <= ABS0; // row 0,2,4,6 even D column
16'bxxxx_xxxx_0xx0_1110: state <= ABS0; // row 0,2,4,6 even E column
16'b0000_0000_1xx0_11xx: state <= ABS0; // row 8,A,C,E, column C,D,E,F --X/Y/W abs
16'bxxxx_xxxx_xxx1_1xx1: state <= ABSX0; // odd rows, column 9,B,D,F
16'bxxxx_xxxx_xxx1_1110: state <= ABSX0; // odds rows, column E
16'bxx00_xx00_0x00_1000: state <= PUSH0; // PH[A..Q], PHP
16'b0000_0000_x101_1010: state <= PUSH0; // PHX, PHY
16'b0000_0000_0100_1011: state <= PUSH0; // PHW
16'b00xx_00xx_0x10_1000: state <= PULL0; // PL[A..Q], PLP
16'b0000_0000_x111_1010: state <= PULL0; // PLY, PLX
16'b0000_0000_0110_1011: state <= PULL0; // PLW
16'b0000_0000_1xx0_00x0: state <= FETCH; // IMM, row 8,A,C,E, column 0,2
16'bxxxx_xxxx_xxx0_1001: state <= FETCH; // IMM, even rows, column 9
16'b0000_0000_0xx1_1000: state <= REG; // CLC, SEC, CLI, SEI
16'bxxxx_xxxx_1xxx_1000: state <= REG; // DEY, TY[A..Q], T[A..Q]Y, INY, INX, INW, DEW
16'bxxxx_xxxx_xxx0_1010: state <= REG; // <shift/rotate> [A..Q], TX[A..Q], NOP
16'bxxxx_xxxx_00x1_1010: state <= REG; // INC/DEC [A..Q]
16'bxxxx_xxxx_10x1_1010: state <= REG; // TSX, TXS
16'bxxxx_xxxx_1xx0_1011: state <= REG; // T[A..Q][A..Q],TYX,TXY
16'bxxxx_xxxx_1111_00x0: state <= REG; // TW[A..Q], T[A..Q]W
endcase
Re: 65ORG16.b Core
Posted: Wed Apr 11, 2012 6:09 pm
by ElEctric_EyE
Maybe I am misunderstanding something?. But as I understand it, the register select logic chooses the X or Y index registers here and only here (which I have modified):
Code: Select all
/*
* register select logic. This determines which of the A thru Q, W, X, Y or
* S registers will be accessed.
*/
always @*
case( state )
INDY1,
INDX0,
ZPX0,
ABSX0 : regsel = index_y ? SEL_Y : index_w ? SEL_W : SEL_X;
....
It appears to be under the absolute,x (ABSX0) but I assume the register select logic works for all addressing modes where the core has to select Y or X indexing?
Re: 65ORG16.b Core
Posted: Wed Apr 11, 2012 6:13 pm
by Arlet
Maybe I am misunderstanding something?. But as I understand it, the register select logic chooses the X or Y index registers here and only here (which I have modified):
Code: Select all
always @*
case( state )
INDY1,
INDX0,
ZPX0,
ABSX0 : regsel = index_y ? SEL_Y : index_w ? SEL_W : SEL_X;
....
It appears to be under the absolute,x (ABSX0) but I assume the register select logic works for all addressing modes where the core has to select Y or X indexing?
It's for all the states separated by the commas: INDY1, INDX0, ZPX0, and ABSX0. But yes, this is the only place.
Re: 65ORG16.b Core
Posted: Wed Apr 11, 2012 6:49 pm
by ElEctric_EyE
The comma, yes I should've recognized everything preceding a semicolon or colon is included in the argument. Thanks, learning continues...
So my MUX, is it good?
Code: Select all
regsel = index_y ? SEL_Y : index_w ? SEL_W : SEL_X;
I see BigEd deleted his post

But the way I see the code is: Verilog will look at index_w first to see if it's a 1 or 0. Then it will look at index_y and regsel will be SEL_Y if index_y is 1, or SEL_W or SEL_X depending on the value of index_w.
If this is the case, I have all opcodes in place for indirect W addressing mode. There's just an error somewhere because after an INY in my test assembly code, it DECODEs a break $00, even though this is not in the assembly.
Re: 65ORG16.b Core
Posted: Wed Apr 11, 2012 7:03 pm
by BigEd
(I don't think I've ever deleted a post before... In this case I'd managed to say the same as Arlet, but got in just after he did, and was terse to the point of danger. So it had to go!)
Re: 65ORG16.b Core
Posted: Wed Apr 11, 2012 7:10 pm
by Arlet
So my MUX, is it good?
Code: Select all
regsel = index_y ? SEL_Y : index_w ? SEL_W : SEL_X;
Yes, it'll work.
For clarity I would prefer an extra line:
Code: Select all
regsel = index_y ? SEL_Y :
index_w ? SEL_W : SEL_X;
Or, as I suggested earlier:
Where 'index_reg' is set up during DECODE, like src_reg, and dst_reg. This will improve clarity and timing when you add more registers.
Re: 65ORG16.b Core
Posted: Wed Apr 11, 2012 8:06 pm
by ElEctric_EyE
Excellent, thank you Arlet. At this point I would like to add just 1 more index register as I am using only a 16x16 opcode matrix to be compatible with all (except SED, CLD) NMOS6502 opcodes and a few more WDC65C02. I am very quickly running out of room on the 16x16 grid, so this will be the end of the .b core.
Something strange is going on, because on my laptop the core is functional. On my desktop speed machine, the core is crashing ISim. I will have to experiment further and figure it out...
I'm unsure if I should post what I have to Github?
Re: 65ORG16.b Core
Posted: Sat Apr 14, 2012 8:01 pm
by ElEctric_EyE
While looking for opcode decoding errors for load_reg in the .b core and comparing against Arlet's original posted on Github I noticed column 6 was not accounted for on Arlet's core. I think it should be, or am I mistaken?
I have a second 'W' register and indirect indexed store has tested ok, finally! Spent many days pouring over 1' and 0's, today finally found my issue as I expected in the decoding...
Will do some more testing, then see what top speed is. If all is ok, in a few days I'll post to Github.
Re: 65ORG16.b Core
Posted: Sat Apr 14, 2012 8:52 pm
by ElEctric_EyE
While looking for opcode decoding errors for load_reg in the .b core and comparing against Arlet's original posted on Github I noticed column 6 was not accounted for on Arlet's core. I think it should be, or am I mistaken?...
Ah, I think I understand why. All bitpatterns not matching go to the default SEL_A. This is where it
was a bit of a challenge for me as there is no default accumulator in the .b core. Everything must be accounted for, at least as far as a good looking simulation is concerned.
Re: 65ORG16.b Core
Posted: Sat Apr 14, 2012 11:46 pm
by ElEctric_EyE
I was working on the core for most of the day, and posted the progress previously mentioned. And now I am "chilling"..
Now I was thinking, if the default register 'catches' opcodes that are not defined previously, this could be an illegal opcode register on both the src_reg and the dst_reg side. Maybe set a D flag, D for detention! Then what to do after that? Maybe send a NOP, a BRK...
This is just a thought, no time to pursue it just yet...
Re: 65ORG16.b Core
Posted: Sun Apr 15, 2012 6:03 am
by Arlet
The reason I use defaults is to help the synthesis tools to minimize logic. If you want everything accounted for, you'll need more decoding logic.
Re: 65ORG16.b Core
Posted: Sun Apr 15, 2012 6:34 am
by BigEd
Yes, it's much more work to catch the undefined opcodes - not a good plan.
Re: 65ORG16.b Core
Posted: Sun Apr 15, 2012 1:51 pm
by ElEctric_EyE
Since I have multiple Accumulators, I do have to define each one and I don't see any one being a default. Instead of leaving it open ended, I think it would be better for decoding to add a default which would naturally define all the opcodes not presently decoded and set a flag in the status register.
Re: 65ORG16.b Core
Posted: Sun Apr 15, 2012 6:31 pm
by ElEctric_EyE
Well, I left everything open ended, no defaults. Everything seems to be working ok on the laptop, still getting undefined red X's on the desktop for some of the Accumulators. Max speed right now, without using smartexplorer, is 91MHz.
Here's a link to the core on
Github for anyone interested. The prior post of the
opcode matrix is up to date. A growing list of macro's can be found in the README txt file on github.