More opcodes for the NMOS 6502: Applicable to the 65Org16.x

ElEctric_EyE · Post by **ElEctric_EyE** » Sat Sep 03, 2011 12:37 am

What is the 65Org16?

Do a search on Google for 65Org16 Site: 6502.Org to catch up if you desire more detail.

Simply stated, as many times before, it is a 16-bit equivalent of the original NMOS 6502 8-bit core originally created by Arlet Ottens in Verilog, but modified into 16-bit data, 32-bit address by BigEd. i.e BigEd has modified Arlet's 8-bit 6502 core into a 16-bit data bus 4GB addressable CPU with all NMOS 6502 commands intact!

I would like to further modify BigEd's 65Org16 Core. More will be explained later, but I would like to attempt adding a WDC65C02 PHX opcode first. Arlet has already shown us how to here.

If you are interested how we got to this stage, I would recommend at least skimming through the 6502.org threads below, feel free to add links if you know I've missed any...

They show a beginning desire to mold a bigger, better, faster 6502 type CPU. One that can be designed into a very capable FPGA, maybe approaching 1/2 ASIC speed, using a Spartan 6 QFP style package Xilinx FPGA.

Chapter 1.
Chapter 2.
Chapter 3.

NOTICE: I reserve the right to heavily edit this page in the future, as I have had a long day of work! Thank You

... Thanks Admin!

GARTHWILSON · Post by **GARTHWILSON** » Sat Sep 03, 2011 12:48 am

Quote:

Do a search on Google for 65Org16 Site: 6502.Org

or other search engine. I use ixquick.com because they don't keep a record of what you search for like Google does. The way our loss of freedoms is going, pretty soon they'll be carting you off as "domestic terrorists" because you looked up "water balloons" for your child's birthday party. ixquick.com works the same way as Google, but without keeping records for the nosey feds to look into.

ElEctric_EyE · Post by **ElEctric_EyE** » Sat Sep 03, 2011 1:05 am

Garth, don't make me go there!
I am posting here to lose myself in digital electronics! I did receive my Digilent USB JTAG Cable today, but I am tiring...

ElEctric_EyE · Post by **ElEctric_EyE** » Mon Sep 05, 2011 2:53 pm

I have been working the past few days getting refamiliarized with the testbench I have used for the POC:65O16.b. Slightly modified (I'll post schematic soon), it's using BRAMs in the Spartan 6 containing a 4K Zero page RAM ($00000000-$00000FFF), an 4K Stack RAM ($0001F000-$0001FFFF) and a 4K "ROM" ($FFFFF000-$FFFFFFFF). The bugs have been worked out of it thanks to Arlet's help with some RAM timing signals, and making the .coe converter that is needed to convert an 8/16-bit .bin file into a .coe file for the Block Memory Generator.

Speaking of .bin files, the assembler Bitwise has written for us already seems to be 65C02 compatible. Thanks Bitwise! Quickly coding for PHX, PLX and STZ produced the expected results in the .bin file.

Tomorrow I'd like to get into modifying the 65Org16.b core, using Arlet's core as the reference, and testing it with ISim...

Work also progresses on the V1.1 DevBoard.

EDIT: added "16-bit" link.
EDIT: added "testbench" link, corrected memory sizes

ElEctric_EyE · Post by **ElEctric_EyE** » Tue Sep 06, 2011 4:24 pm

I've done coding PHX, PHY, PLX and PLY. Line #'s are referenced to Arlet's NMOS core. Whether they work or not I am about to find out, but they did pass synthesis.

To define the PHX($00DA), PHY($005A), and PLX($00FA),PLY($007A) in the Mircocode state machine I added the following after line 893 :

Code: Select all

// extra 65C02 opcodes
		16'b0000_0000_x101_1010:	state <= PUSH0; // PHX,PHY
		16'b0000_0000_x111_1010:	state <= PULL0; // PLX,PLY

To define the behavior of PHX I added the following after line 1016:

Code: Select all

16'b0000_0000_1101_1010:	// PHX
				dst_reg <= SEL_X;

For PHY I added the following after line 1022:

Code: Select all

16'b0000_0000_0101_1010:	// PHY
				dst_reg <= SEL_Y;

I'm pretty sure the previous will work. I'm not so sure about the following because I could not find PLA(0110_1000) in the code. I did find the mask for it on line 979 which is why I proceded this way:

To define the behavior of PLX & PLY I added the following after line 981:

Code: Select all

16'b0000_0000_x111_1010:	// PLX,PLY

Now off to testing in ISim...

Arlet · Post by **Arlet** » Tue Sep 06, 2011 6:49 pm

For the pull instructions, you need to set 'dst_reg', and for the 'push' instructions, you'll need to set 'src_reg'.

In a PLX for instance, the X is the destination. So, during PLX decode you'll need to set 'dst_reg', and the actual write to register X will be done during the next DECODE cycle (of the next instruction) (line 545)

For 'push' instructions, the data is fetched from the register file at line 650/651, during PUSH0. The data then goes into the ALU, where it comes back out one cycle later, during the PUSH1 cycle. In the PUSH1 cycle, the ALU output goes to DO bus in line 431, where it is written to the stack.

ElEctric_EyE · Post by **ElEctric_EyE** » Tue Sep 06, 2011 7:39 pm

I was following the behavior of PLA($68,0110_1000) on your code on line 979 where you have a mask for xxxx_10x0. Is this the only place for the PLA opcode behavior definition? or am I missing something? Thanks! I will come back to your previous post, just need this answered.

Arlet · Post by **Arlet** » Tue Sep 06, 2011 8:40 pm

ElEctric_EyE wrote:

I was following the behavior of PLA($68,0110_1000) on your code on line 979 where you have a mask for xxxx_10x0. Is this the only place for the PLA opcode behavior definition? or am I missing something? Thanks! I will come back to your previous post, just need this answered.

Yes, line 979, but also line 1004.

ElEctric_EyE · Post by **ElEctric_EyE** » Wed Sep 07, 2011 3:27 pm

Ok, I can't say I'm learning yet. I thought doing PHX, PHY, PLX, and PLY would have been easier, but I am still digesting the flow of it. At the same time I had to make adjustments to my testbench to accomodate the 4Kx16 .bin file that Bitwise's assembler makes. I was using address decoding for 8Kx16, for my earlier experiments using a hex editor. I really need to look at the HDL equivalent of the address decoding and study it. So many wires in schematic entry is a pain, especially when working with 32-bit addresses!

I'm happy to say a simple program I've made below appears to be running in ISim.

Code: Select all

RESHandler:	LDX #$FFFF
		        PHX
		        LDX #$7FFF
		        PHX
		        LDY #$1000
		        PHY
		        LDY #$4000
		        PHY
		        PLX
		        PLX
		        PLY
		        PLY
		        BRK

I need to head out for abit, but when I return I can run a Sim and post it. Which signals should we be focusing on? I know we will want to look at PC[31:0], IR[15:0], statename [47:0], X[15:0] and Y[15:0].

I have posted my changes to my version of the core on Github.

If these opcodes work I have 2 more instructions I/(we?) would like to tackle next. TXY and TYX...

Arlet · Post by **Arlet** » Wed Sep 07, 2011 3:44 pm

ElEctric_EyE wrote:

Which signals should we be focusing on? I know we will want to look at PC[31:0], IR[15:0], statename [47:0], X[15:0] and Y[15:0].

and also A, S, AI, BI, ADD, DI, DO, src_reg, dst_reg. That should cover most of the data path between stack and registers.

ElEctric_EyE · Post by **ElEctric_EyE** » Wed Sep 07, 2011 5:41 pm

I was able to fit the entire loop of the program I previously posted, into the pic. I thought the src_reg and dst_reg were 16 bits looking at the code, after all they are transferring data between the A,X,Y, and Stack registers. I wish I could tell if it was working.

Arlet · Post by **Arlet** » Wed Sep 07, 2011 5:46 pm

ElEctric_EyE wrote:

I thought the src_reg and dst_reg were 16 bits looking at the code

They are 2 bit wide, and only contain the index of the register. See lines 75-82. So, whenever src_reg is equal to 2, that means that X is the source.

By the way, your code isn't working. The PHX instruction should cause a state = PUSH0, but it's going to REG instead.

This is because the $00da opcode is covered by line 893:

Code: Select all

8'bxxxx_1010:	state <= REG;   // <shift> A, TXA, ...  NOP

You'll need to change that pattern so it doesn't cover the new opcode(s)

ElEctric_EyE · Post by **ElEctric_EyE** » Wed Sep 07, 2011 9:13 pm

Arlet wrote:

...By the way, your code isn't working. The PHX instruction should cause a state = PUSH0, but it's going to REG instead.

This is because the $00da opcode is covered by line 893:

Code: Select all

8'bxxxx_1010:	state <= REG;   // <shift> A, TXA, ...  NOP

You'll need to change that pattern so it doesn't cover the new opcode(s)

I know this was your warning at the outset, I thought I had it covered. I need a few more days to re-check this out.

ElEctric_EyE · Post by **ElEctric_EyE** » Thu Sep 08, 2011 4:48 pm

I'm at work so I'm on and off looking at your code....

Arlet wrote:

...By the way, your code isn't working. The PHX instruction should cause a state = PUSH0, but it's going to REG instead.

This is because the $00da opcode is covered by line 893:

Code: Select all

8'bxxxx_1010:	state <= REG;   // <shift> A, TXA, ...  NOP

You'll need to change that pattern so it doesn't cover the new opcode(s)

I'm thinking for line 893:

Code: Select all

16'b0000_0000_x0x0_1010:	state <= REG;   // <shift> A, TXA, ...  NOP

will work, since the extra opcodes shown below bits 5 & 7 are both 1.

Code: Select all

// extra 65C02 opcodes
		16'b0000_0000_x101_1010:	state <= PUSH0; // PHX,PHY
		16'b0000_0000_x111_1010:	state <= PULL0; // PLX,PLY

__________________________________________________________________________________________________________________________
No, I can see that's not going to work either. Still thinking...

I think defining just about each one will have to be done like this:

Code: Select all

		16'b0000_0000_00xx_1010:	state <= REG;   // ASL,INC, ROL, DEC
		16'b0000_0000_0100_1010:	state <= REG;	 // LSR
		16'b0000_0000_0110_1010:	state <= REG;	 // ROR
		16'b0000_0000_10xx_1010:	state <= REG;	 // TXA, TSX, TAX, TXS
		16'b0000_0000_1100_1010:	state <= REG;	 // DEX
		16'b0000_0000_1110_1010:	state <= REG;	 // NOP

Also, I'm going to have to worry about line 979 too aren't I?