6502.org
http://forum.6502.org/

65ORG16.b Core
http://forum.6502.org/viewtopic.php?f=10&t=1842
Page 15 of 24

Author:  ElEctric_EyE [ Mon Apr 09, 2012 10:41 pm ]
Post subject: 

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!!!!
Image

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! :D

Author:  ElEctric_EyE [ Tue Apr 10, 2012 10:55 pm ]
Post subject: 

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:
/*
 * 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

Author:  ElEctric_EyE [ Wed Apr 11, 2012 6:09 pm ]
Post subject:  Re: 65ORG16.b Core

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:
/*
 * 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?

Author:  Arlet [ Wed Apr 11, 2012 6:13 pm ]
Post subject:  Re: 65ORG16.b Core

ElEctric_EyE wrote:
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:
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.

Author:  ElEctric_EyE [ Wed Apr 11, 2012 6:49 pm ]
Post subject:  Re: 65ORG16.b Core

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:
regsel = index_y ? SEL_Y : index_w ? SEL_W : SEL_X;


I see BigEd deleted his post :wink: 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.

Author:  BigEd [ Wed Apr 11, 2012 7:03 pm ]
Post subject:  Re: 65ORG16.b Core

(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!)

Author:  Arlet [ Wed Apr 11, 2012 7:10 pm ]
Post subject:  Re: 65ORG16.b Core

ElEctric_EyE wrote:
So my MUX, is it good?
Code:
regsel = index_y ? SEL_Y : index_w ? SEL_W : SEL_X;

Yes, it'll work.

For clarity I would prefer an extra line:
Code:
regsel = index_y ? SEL_Y :
         index_w ? SEL_W : SEL_X;

Or, as I suggested earlier:
Code:
regsel = index_reg;

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.

Author:  ElEctric_EyE [ Wed Apr 11, 2012 8:06 pm ]
Post subject:  Re: 65ORG16.b Core

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?

Author:  ElEctric_EyE [ Sat Apr 14, 2012 8:01 pm ]
Post subject:  Re: 65ORG16.b Core

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.

Author:  ElEctric_EyE [ Sat Apr 14, 2012 8:52 pm ]
Post subject:  Re: 65ORG16.b Core

ElEctric_EyE wrote:
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.

Author:  ElEctric_EyE [ Sat Apr 14, 2012 11:46 pm ]
Post subject:  Re: 65ORG16.b Core

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...

Author:  Arlet [ Sun Apr 15, 2012 6:03 am ]
Post subject:  Re: 65ORG16.b Core

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.

Author:  BigEd [ Sun Apr 15, 2012 6:34 am ]
Post subject:  Re: 65ORG16.b Core

Yes, it's much more work to catch the undefined opcodes - not a good plan.

Author:  ElEctric_EyE [ Sun Apr 15, 2012 1:51 pm ]
Post subject:  Re: 65ORG16.b Core

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.

Author:  ElEctric_EyE [ Sun Apr 15, 2012 6:31 pm ]
Post subject:  Re: 65ORG16.b Core

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.

Page 15 of 24 All times are UTC
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/