6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Fri Mar 29, 2024 10:56 am

All times are UTC




Post new topic Reply to topic  [ 353 posts ]  Go to page Previous  1 ... 12, 13, 14, 15, 16, 17, 18 ... 24  Next
Author Message
 Post subject:
PostPosted: Mon Apr 09, 2012 10:41 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
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


Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: Tue Apr 10, 2012 10:55 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
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


Top
 Profile  
Reply with quote  
 Post subject: Re: 65ORG16.b Core
PostPosted: Wed Apr 11, 2012 6:09 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
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?

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
 Post subject: Re: 65ORG16.b Core
PostPosted: Wed Apr 11, 2012 6:13 pm 
Offline
User avatar

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands
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.


Top
 Profile  
Reply with quote  
 Post subject: Re: 65ORG16.b Core
PostPosted: Wed Apr 11, 2012 6:49 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
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.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
 Post subject: Re: 65ORG16.b Core
PostPosted: Wed Apr 11, 2012 7:03 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10760
Location: England
(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!)


Top
 Profile  
Reply with quote  
 Post subject: Re: 65ORG16.b Core
PostPosted: Wed Apr 11, 2012 7:10 pm 
Offline
User avatar

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands
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.


Top
 Profile  
Reply with quote  
 Post subject: Re: 65ORG16.b Core
PostPosted: Wed Apr 11, 2012 8:06 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
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?

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
 Post subject: Re: 65ORG16.b Core
PostPosted: Sat Apr 14, 2012 8:01 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
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.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
 Post subject: Re: 65ORG16.b Core
PostPosted: Sat Apr 14, 2012 8:52 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
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.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
 Post subject: Re: 65ORG16.b Core
PostPosted: Sat Apr 14, 2012 11:46 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
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...

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
 Post subject: Re: 65ORG16.b Core
PostPosted: Sun Apr 15, 2012 6:03 am 
Offline
User avatar

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands
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.


Top
 Profile  
Reply with quote  
 Post subject: Re: 65ORG16.b Core
PostPosted: Sun Apr 15, 2012 6:34 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10760
Location: England
Yes, it's much more work to catch the undefined opcodes - not a good plan.


Top
 Profile  
Reply with quote  
 Post subject: Re: 65ORG16.b Core
PostPosted: Sun Apr 15, 2012 1:51 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
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.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
 Post subject: Re: 65ORG16.b Core
PostPosted: Sun Apr 15, 2012 6:31 pm 
Offline

Joined: Mon Mar 02, 2009 7:27 pm
Posts: 3258
Location: NC, USA
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.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 353 posts ]  Go to page Previous  1 ... 12, 13, 14, 15, 16, 17, 18 ... 24  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: