65ORG16.b Core

ElEctric_EyE · Post by **ElEctric_EyE** » Mon May 23, 2011 12:21 am

Intro...
Ideas
More ideas
And some more ideas...

BigEd has successfully modified Arlet's verilog Core of the original NMOS 6502, for 16-bit functionality by multiplying the data bus width by 2 (to 16-bits), and the address bus width by 2 (to 32-bits) for direct access to 4.3GB of memory. All original NMOS6502 instructions are intact, meaning their original 8-bit values are now the LSB of the 16-bit opcode***. The NMI/RESET/IRQ vectors are now at $FFFF_FFFA, $FFFF_FFFC, $FFFF_FFFE, respectively.

Features of the .b core:
-- 90+MHz operation in a Spartan 6 environment.
-- 16 Accumulators
-- Another index register called 'W', that functions like the Y-index register. All associated addressing modes, Pushes, Pulls and Transfers are there.
--Transfers are allowed amongst all Accumulators, and from the 3 indexes to/from any accumulator.
-- Some 65C02 opcode additions like PHX, PHY, etc., and INC A, DEC A have the same value for current 65Org16 Assembler*** compatibility, although INC/DEC also apply to the other accumulators.
-- Shifting, Rotating can be done on any 1 of the 1st 4 accumulators (i.e A..D) and the result stored in another of the 1st 4 accumulators (i.e. A..D) utilizing a barrel shifter* for a maximum of 15 <shifts,rotates> instantaneously. Shifting, Rotating the contents of memory can be done in this same manner, for all other addressing modes.
-- 2 zeropage and stackpage relocation pointers have been added, allowing the 64K zeropage and 64K stackpage to be placed anywhere within the 4GB addressable memory space.
-- Logic (AND, ORA, EOR) or Math (ADC, SBC) functions can be done to any accumulator and the result stored in another accumulator**, for all addressing modes.
-- 32 opcodes are present to transfer any accumulator value to the stackpage pointer or the zeropage pointer.
-- 32 opcodes are present to transfer zeropage pointer or stackpage pointer to any accumulator.

Here are the macro definitions for some of the new opcodes.

First .b 65O16 core spec is here in zipped RTF format.
Updated spec v2 is here, including the opcode matrix.

* Thanks to BigEd's Verilog code for the barrel shifter on his GitHub page.
**Thanks to Arlet for his idea which I call 'Transposing Stores' on the accumulators.
***Many thanks as well to TT & Bitwise for their HXA and As65 65Org16 compatible Assemblers.
Also, a great many thanks to Bruce, who has contributed his C'mon which is also 65Org16 compatible.

It all started here:

Arlet wrote:

To add another accumulator, or other registers really isn't all that difficult. Suppose you want to add a register 'B', which can be used the same way as 'A':

- You'll need to widen the [1:0] regsel path, e.g. to [2:0] regsel. This allows 4 more registers. Widen src_reg and dst_reg the same way.

- Change SEL_A .. SEL_Y to 3'd0 .. 3'd3, and add SEL_B 3'd4.

To use the register B, all you need is extra decoding. The data path is already there. And the only decoding you need to use the B register instead of the A register, is to add a line for 'dst_reg <= SEL_B' and 'src_reg <=SEL_B ', when the IR matches your new instruction pattern. All the instructions that work for A (EOR, ADC, ROL, STA,...) then work automatically the same way for B.

The same thing applies to reg-reg transfers. To add a 'TBX' instruction, you'll need: load_reg <= 1, dst_reg <= SEL_X, src_reg <= SEL_B, and state <= REG when IR==TBX and state == DECODE.

EDIT(2/20/2012): Changed title, clarified some details.
EDIT(3/28/2012): Clarified more details.
EDIT(4/24/2012): Finishing the .b core spec's.
EDIT(5/14/2012): Added some links for reference, and link for new Macros.
EDIT(2/13/2013): Added link for "it all started here" comment

ElEctric_EyE · Post by **ElEctric_EyE** » Mon May 23, 2011 12:36 am

MY POC will consist of:
1) a Spartan 6 144-pin QFP consisting of:
8K internal ROM (top-end of 64K)($FFFF_E000-$FFFF_FFFF),
8K internal stack (top-end of 64K)($0001_E000-$0001_FFFF), and
8K zero page (bottom-end of 64K) ($0000_0000-$0000_1FFF), to start with.
2) FPGA config PROM
3) a 16-bit ADC input device.
4) a MUX'd 16-bit DAC for stereo audio out. Audio is cheaper than video for testing purposes...

With the Spartan-6, anticipated speeds should be close to 100MHz initially. We will have to see how the addition of the first accumulator slows things down. But first I'll make a simple CPU/ROM/RAM/STACK Addr decode in schematic form with the original 65ORG16 CPU and perform an ISE speed test.
The next test will be the B accumulator hard coded to do a transfer to the orginal A accumulator. I will have to prove it in ISim, with some very simple code...

Arlet · Post by **Arlet** » Mon May 23, 2011 8:26 am

The 65Org16 only supports 16 bit accesses, which may be a problem in some cases where you want to access bytes. Do you want to add support for byte access ?

Also, with so many registers, you'd probably want to be able to perform ALU operations on two registers. It seems a bit silly to have all these registers, and then have to write data to memory before you can do anything with it.

GARTHWILSON · Post by **GARTHWILSON** » Mon May 23, 2011 9:20 am

Quote:

The 65Org16 only supports 16 bit accesses, which may be a problem in some cases where you want to access bytes. Do you want to add support for byte access ?

This is a lower version of the 32-bit version where we discussed the same thing. I've worked with a 4-bit Saronix RTC58321 (real-time clock) IC with the 6502 which is 8-bit, and it was no problem at all. I've also delt with 2-bit inputs, and again, it was no problem. You don't need a processor that has 2- or 4-bit fetches and stores to deal with them.

In the case of text, each character can take a 16-bit byte. Memory is so cheap and dense compared to 25 years ago, so that's not a problem. You could pack two characters in each byte, but I think the program overhead would make me decide against it. Especially something like doing a search would be a pain.

The I/O ICs like the 6522 are 8-bit, and the only potential problem I see is when you want bits 6 and 7 to affect the V and N flags in the BIT instruction. The easiest solution might be to have extra flags that get affected by bits 6 and 7 and can be branched on just like the V and N flags.

The '816 has the XBA (eXchange accumulators B and A) instruction which is useful for swapping 8-bit bytes in the 16-bit accumulator C also, and the 65Org16 ought to have it. Especially when you get to 32 bits, but to a lesser extent 16, a barrel shifter becomes awfully useful.

BigEd · Post by **BigEd** » Mon May 23, 2011 9:49 am

I was thinking an 8-bit shift might be handy - but a byte swap is very similar. And then I thought that 8 single-bit shifts probably isn't too big a cost if I'm dealing with slow peripherals anyway.

(Of course, if you're dealing with fast peripherals it might more sense to add some well-chosen opcodes. Remember, though, that the CPU is at 50MHz or more.)

I completely agree that packing two characters to a byte would be a net loss.

Remember that every opcode needs to be

dreamt up
carefully described in words (as in, specified)
described in verilog
tested
written into the assembler

and ideally, useful! (To people and perhaps to high level languages.) So each new opcode should earn its keep. In these discussions generally most ideas only get to the 'dreamt up' stage.

I'd suggest a step-by-step approach: pick the smallest increment which gives a meaningful gain and get that working first.

Good luck!

Arlet · Post by **Arlet** » Mon May 23, 2011 10:15 am

Whether packing two characters in a word is worth it depends on the memory. If you're trying to avoid external memory, the block RAM size can be quite limiting. Of course, there are still ways around that. If you have a lot of byte-wide strings, you could hook up some 8-bit wide block RAM to the bottom 8 bits of the data bus, and leave the top bits unused.

I agree with the process of picking new opcodes. Also, keep in mind that the more you add, the slower the CPU will run, especially if you're going to add extra muxes in the data path, or extra operations in the ALU. A barrel shifter sounds nice, but if it cuts your max speed in half, it is probably not going to result in a net gain in processing power.

ElEctric_EyE · Post by **ElEctric_EyE** » Mon May 23, 2011 11:29 am

I too agree with opcode selection. First, I plan to lay out on paper a 16 x 16 grid, put the original 6502 opcodes in the lower 8 x 8, add in WDC65C02 and WDC65C816 opcode in different colors, analyze similarities and follow suit with the additional commands as best I can. I will be posting that info here for consideration before any kind of github post.

As far as dealing with 8 bit devices, say a keyboard interface, I think just ANDing off the upper 8-bit in software would be fine. For reading strings to be display, "stacking" the 16 bit data bus with 2 bytes makes sense, but this is all software anyway...

BigEd · Post by **BigEd** » Mon May 23, 2011 11:36 am

ElEctric_EyE wrote:

a 16 x 16 grid

Hmm, it's much bigger than that: think 256x256. Probably a better bet is to draw up a picture of how to use the bitfields within the opcodes. At 16x16 you've only used 2 extra bits: you have 8 extra bits.

(But, you only have 8 extra bits. So adding too many extra registers is going to demand too many of those bits. 8 registers needs 3 bits, for those opcodes which can act on any register. Some opcodes use two registers, so that's 6 bits. A regular encoding will probably help keep the clock speed up. Anyhow, perhaps start with a B accumulator, or a W and Z index register, see how that works out.)

Arlet · Post by **Arlet** » Mon May 23, 2011 12:10 pm

A simple strategy could be to start with just a B accumulator, and have an extra bit that basically says: "use B instead of A". This is very easy to implement, and then you can write some programs to see if it looks useful. You can even skip the TAB and TBA instructions at first.

Similarly, you could have a bit that changes X to W, and Y to Z.

ElEctric_EyE · Post by **ElEctric_EyE** » Mon May 23, 2011 8:57 pm

BigEd wrote:

ElEctric_EyE wrote:

a 16 x 16 grid

Hmm, it's much bigger than that: think 256x256...

Oops, oversight on my part, 16 x 16 is the 8 bit cpu. You're right 256 x 256 is too big to draw out.

Not sure what you guys mean by the opcode bits yet, but it may become clearer to me soon, when I get into the guts. But I do plan to keep it simple on the first stage and focus first on adding 1 accumulator. But before I do that...

I've got the schematic with the cpu, address decoding, 2 rams done. Now I have to work on a simple program to code into a ROM and I can do the first implementation and check the top speed. I was thinking of doing a test pattern program using indirect indexed. This is still using the original 65ORG16. No modifications yet. No external testing of RAM, just an observation of signals in ISim.
I may have incorrect values in the remarks, but the program is functionally sound and won't write data into zeropage, stack or attempt overwrite itself in ROM.

Code: Select all

          LDA #$0000
          STA $0000
          LDA #$1000
          STA $0001           ;start @ indirect address $1000000
          LDX #$D000         ;
          LDY #$FFFF
A        LDA #$AA55        ;$AA55 = 1010101001010101
          STA ($0000),Y      ;store in start @ $10000000
          DEY
          BNE A
          INC $0001
          DEX                    ;repeat until address $EFFFFFFF
          BNE A
B        JMP B

fachat · Post by **fachat** » Mon May 23, 2011 10:04 pm

ElEctric_EyE wrote:

Not sure what you guys mean by the opcode bits yet, but it may become clearer to me soon, when I get into the guts. But I do plan to keep it simple on the first stage and focus first on adding 1 accumulator. But before I do that...

Think of the instruction not as a "2 byte" or "1 word" value, but as "16 bits". The lower 8 bits are the original set, and the upper 8 bits are "extension" bits.

For those opcodes that use the AC, 3 extension bits would be needed to replace the single AC with one of eight AC registers. Similary for the index registers. Because there are opcodes that use AC _and_ and index register, for some you need 6 extension bits.

Keep in mind that "000" means the "original" register to keep at least some compatibility if you want it. I.e. for the index registers, on some opcodes this means X, on others it means Y. If you define "001" to be the exchanged register, you'd get the additional benefit of addressing modes "(zp),X" ot "(zp,Y)".

BTW, as a side remark, using my prefix bytes (with variable length opcodes) I've already defined 9 prefix bits (as I call my extension bits), and 2 bits left. If you need some ideas what you want can do with it, you can have a look at my 65k project ;-)

André

ElEctric_EyE · Post by **ElEctric_EyE** » Tue May 24, 2011 12:14 am

fachat wrote:

...For those opcodes that use the AC, 3 extension bits would be needed to replace the single AC with one of eight AC registers. Similary for the index registers. Because there are opcodes that use AC _and_ and index register, for some you need 6 extension bits...
André

Ah, now I begin to understand!...
Andre, you agree with 8 accumulators too and think they may be useful?

IMO Accumulators and index registers are like free memory to me. You load a value into them and the value is there without external memory. And even better if you can do math on the them (accumulators). I also like index registers. I do like the stack too, but am in favor of more registers/accumulators than stack use.

Been thinking on my ride home from work, the next post I will make (hopefully tonight) will be the hex representation of the program I posted last.
The next logical step, after the observation of the top speed recommended by ISE is to observe the program in ISim. If everything works OK, then the next step will be to widen the IR[7:0] to IR[15:0] within Arlet/BigEd's cpu module. This will be the first "mod". Then I'll rewrite the hex representation of that same code to accomodate the 16-bit IR. Sounds easy, but you never know...

ElEctric_EyE · Post by **ElEctric_EyE** » Tue May 24, 2011 1:58 am

Ok, I'm gonna start from MK's assembler to make a test program so I know exactly what memory locations are filled...

Here's the code the I've successfully simulated and tested in MK's assembler for the original 6502. After running it and observing the virtual 64K 6502 memory, it stores #$A5 from address $1000 to $DFFF.
The .bin image (8-bit hex) of this program (for an original 6502/C02) that starts @ $F000 is:
A9,00,85,00,A9,10,85,01,A2,D0,A0,00,A9,A5,91,00,C8,D0,F9,E6,01,CA,D0,F4,4C,18,F0

Code: Select all

  *= $E000          ;start

 	LDA #$00
 	STA $00
 	LDA #$10
 	STA $01              ;set up indirect indexed registers
 	LDX #$D0
 	LDY #$00
A	LDA #$A5           ;store pattern 10100101
	 STA ($00),Y       ;from $1000
	 INY
	 BNE A
	 INC $01
	 DEX                  ;to $DFFF
	 BNE A
B   JMP B         ;end without setting interrupt

This is the correct representation (I think) of an equivalent code necessary to implement the same idea upscaled to a 65O16 if the assembler were to exist. And so with the original 65ORG16 the binary image should look like this (still in 8-bit hex):
A9,00,00,85,00,00,A9,10,00,85,00,01,A2,FF,FE,A9,AA,55,91,00,00,C8,D0,00,F9,E6,00,01,D0,00,F4,4C,18,F0,FF,FF. I think this is right... Will test in ISim.

Code: Select all

  *= $FFFFE000       ;start

 	LDA #$0000
 	STA $0000
 	LDA #$1000
 	STA $0001              ;set up indirect indexed registers
 	LDX #$FFFE
 	LDY #$0000
A	LDA #$AA55           ;store pattern 1010101001010101
	 STA ($0000),Y       ;from $10000000
	 INY
	 BNE A
	 INC $0001
	 DEX                  ;to $FFFEFFFF (still below start @$FFFFE000)
	 BNE A
B   JMP B         ;end without setting interrupt

EDIT: Fixed 6502 assembler program

SysHacker · Post by **SysHacker** » Tue May 24, 2011 12:29 pm

Hello everybody,

Here's my proposal for a 16-bit 6502

Hilights:
8 data registers
4 index registers - not including FP and BP
Orthogonal instruction set - most addressing modes with most instructions
however, you still can't XOR the Frame Pointer with A1
3 new other registers - a DIRECT PAGE register, a STACK PAGE register, & a FRAME POINTER.

Draft 1 can be found here and is preserved for reference.

NEW DRAFT 07/06/11+1048 UTC:

Code: Select all

65ORG02B INSTRUCTION BEHAVIOR:

NOTE: `byte' and `word' are used here interchangeably to describe an 16-bit quantity.

    In general, most instructions behave the same as on the standard 6502, as found [url=http://www.llx.com/~nparker/a2/opcodes.html]here[/url], except with 16-bit bytes.

Clarifications:
    Most instructions have 2 operands - DESTINATION and SOURCE. In most instructions on the original MOS 6502, the DESTINATION is implied, as either the A, X, or Y registers. Some instructions do not have a DESTINATION - like the in-place operations, which change the SOURCE.

THE ADDRESSING MODE BYTE:
   An instruction's SOURCE is selected by the addressing mode byte, the most significant byte of the opcode word [i](Or is it the least - the one the opcode isn't stored in)[/i].

Some instructions, detailed in the INSTRUCTIONS section, use the addressing mode byte for a different purpose. 

The addressing mode byte consists of 3 fields: the 2-bit IR field, the 3-bit MOD field, and the 3-bit SELECT.

The MOD field selects the addressing mode to be used:
    000 - INDEXED INDIRECT - Adds the contents of the word immediate that follows to the Frame Pointer and the Index Register selected by IR, adds the dword value at that address (on the Direct Page) to the zero-extended SELECT field, and uses the result to address memory. TIME: 6 + 1 on page crossing.

    001 - INDIRECT - Adds the contents of the word immediate that follows to the Frame Pointer, adds the address (on the Direct Page) to the zero-extended SELECT field, and uses the result to address memory. TIME: 5 + 1 on page crossing.
    NOTE: added here because, well, it's not like losing an index register is good for performance. DIRECT mode got rolled in with Absolute.

    010 - IMMEDIATE/INDEX REGISTER - If the most significant bit of the SELECT field is set, uses the IR field as an Index Register to use as the source. Otherwise, uses a word operand as the source. TIME: 1 on both cases.
        NOTE: Index Register mode was added mostly to the 01-series instructions (I HATE having to load something into A to shift it left).

    011 - ABSOLUTE/DIRECT - If the most significant bit of the SELECT field is set, uses the word operand + the Frame Pointer alongside the Direct Page to address memory. Otherwise, uses the dword operand to do the same. TIME: 2 on both cases.
        NOTE: Direct mode added here because it makes the most sense.

    100 - INDIRECT INDEXED - Adds the contents of the word immediate that follows to the Frame Pointer, adds the address (on the Direct Page) to the zero-extended SELECT field and the Index Register selected by the IR field, and uses the result to address memory. TIME: 5 + 1 if SELECT is nonzero + 1 on page crossing.

    101 - INDEXED DIRECT - Adds the contents of the word immediate that follows to the Frame Pointer and the Index Register selected by IR, and uses it to address memory alongside the Direct Page register. TIME: 3

    110 - ACCUMULATOR - Uses the SELECT field to select an Accumulator Register and uses it as the source. TIME: 1.

    111 - ABSOLUTE INDEXED: Adds the content of the dword immediate that follows to the Index Register selected by IR, and uses it to address memory.

New Opcodes/Changes:
    The addressing mode field in the cc=01 instructions is used to select an accumulator register, and the one on LDX, STX, and CPX is now used to select an index register.

   LDY, STY and CPY are now illegal.

Opcode Table, Mark 1:

  |   x0   |   x1   |   x2   |   x4   |   x5   |   x6   |   x8   |   x9   |   xA   |   xC   |   xD   |   xE   |
--+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+
0x| BRK nm | ORa A0 |BNC far |        | ORa A1 |  LSR   |        | ORa A2 |        |        | ORa A3 |????????|
--+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+
1x|JSR rel | ORa A4 |BNS far |        | ORa A5 |  ASR   |        | ORa A6 |        |        | ORa A7 |  ASL   |
--+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+
2x|  ENT   | AND A0 |BGT far |        | AND A1 |  ROR   |        | AND A2 |        |        | AND A3 |  ROL   |
--+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+
3x|  LVE   | AND A4 |BLE far |        | AND A5 |  DEC   |        | AND A6 |        |        | AND A7 |  INC   |
--+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+
4x|  PSH   | XOR A0 |BVC far |        | XOR A1 |  JSR   |        | XOR A2 |        |        | XOR A3 |  JMP   |
--+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+
5x|  POP   | XOR A4 |BVS far |        | XOR A5 |????????|        | XOR A6 |        |        | XOR A7 |????????|
--+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+
6x|  PHP   | ADC A0 |BGE far |        | ADC A1 | BIT A0 |        | ADC A2 |        |        | ADC A3 | BIT A2 |
--+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+
7x|  PLP   | ADC A4 |BLT far |        | ADC A5 | BIT A4 |        | ADC A6 |        |        | ADC A7 | BIT A6 |
--+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+
8x|  ANP   | STa A0 |BCC far |        | STa A1 | STi W  |        | STa A2 |        |        | STa A3 | STi X  |
--+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+
9x|  ORP   | STa A4 |BCS far |        | STa A5 | STi Z  |        | STa A6 |        |        | STa A7 | STi Y  |
--+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+
Ax|  ADS   | LDa A0 |BAV far |        | LDa A1 | LDi W  |        | LDa A2 |        |        | LDa A3 | LDi X  |
--+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+
Bx|????????| LDa A4 |BBE far |        | LDa A5 | LDI Z  |        | LDa A6 |        |        | LDa A7 | LDi Y  |
--+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+
Cx|  LDS   | CMP A0 |BZC far |        | CMP A1 | CMP W  |        | CMP A2 |        |        | CMP A3 | CMP X  |
--+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+
Dx|  LDF   | CMP A4 |BZS far |        | CMP A5 | CMP Z  |        | CMP A6 |        |        | CMP A7 | CMP Y  |
--+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+
Ex|  STS   | SBC A0 |  DNOP  |        | SBC A1 | BIT A1 |        | SBC A2 |        |        | SBC A3 | BIT A3 |
--+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+
Fx|  STF   | SBC A4 |JMP rel |        | SBC A5 | BIT A5 |        | SBC A6 |        |        | SBC A7 | BIT A7 |
--+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+

Code: Select all

UPDATED 07/06/11 UTC+1048: added opcode table

ElEctric_EyE · Post by **ElEctric_EyE** » Tue May 24, 2011 3:51 pm

Hi SysHacker, Welcome and thanks for the suggestion. You're abit ahead of me right now though I will definately come back to your suggestion!

Right now having abit of trouble and I think I know why. And it involves modifying Arlet's bin2coe program once again, but this time for 16-bit wide data.
I think I've successfully modified all the necessary code in cpu.v to increase the IR to a full 16 bits in order to avoid the confusion of an 8 bit instruction followed by a 16 bit data, which is what I was wrestling with before in my previous post.
All upper bits for all instructions have been set to 16b'0000_0000_xxxx_xxxx. I also adjusted my hex editor for 2 byte wide data and made the ROM.bin file successfully. Looking at it in ISim I can tell it is getting the incorrect vector because I think the .coe file is incorrect because it's set for 8 bit wide data.