6502.org

Posted: **Mon Jun 14, 2010 8:56 pm**

fachat wrote:

I'm also planning to keep all the current opcodes, but include 2, maybe 3 extra 16-bit registers (U,V,W) with extra opcodes for stuff like

Code: Select all

    LDU $1234
    LDA U,X

using a 16 bit ALU to reduce invalid memory cycles.

Having thought about this a bit more I am more and more thinking about just extending the current registers to 16 bit, with the original opcodes just affecting the lower 8bit. The additional opcodes working on the 16bit values would then look like

Code: Select all

   INYW
   ASLW

This probably helps in reducing the necessary opcode count if I could just reuse

Code: Select all

   LDA ABS,Y

opcodes, when Y is 16 bit. After RESET the high byte of the extended registers would always be zero, and not affected by any "original" 8bit opcode - so the Y- and X-indexed opcodes would be extended in a backward compatible way.

I'd loose extra registers I could reuse for e.g. a blitter though. But on the other hand, adding the originally mentioned U,V,W registers feels like just adding a separate 16bit CPU and not extending the 6502...

I've written up some thoughts on this on my sneak preview page
http://www.6502.org/users/andre/sneak.html#fpga

André

Posted: **Tue Jun 15, 2010 7:51 pm**

Extenders to familiar ones, such as Aw, Xw, Yw?

and PLEASE if you go for it, hit up the branches with a direct addressing mode, 'cause you know my feelings about the 128 bytes either way of a branch test!

Posted: **Tue Jun 15, 2010 8:12 pm**

Quote:

you know my feelings about the 128 bytes either way of a branch

I guess having it relative is good, but was the operand of branch instructions held down to 8 bits just to make programs shorter back when memory was so expensive? Anyone know? Note that JMP abs, although one more byte, is occasionally one clock faster than BEQ, BMI, etc., as the ALU has to get involved with the branches and not the JMP.

Most conditional branches are very short hops; but when you have one that's not within the 128-byte limit, you have to make the oposite condition and follow it with a JMP, and that's not relative. I make them macros (BEQlong, etc.) so they don't take any more space in the source code, but they do take more space and time in the assembled code.

Posted: **Tue Jun 15, 2010 10:09 pm**

I never learned to make macros on the Kowalski assembler, am using jump tables. Do you know how I can do macros on that for a long jump as you mentioned?

Posted: **Tue Jun 15, 2010 11:30 pm**

I am curious too... I never got around to making macros, or a data table... 2 votes! Maybe a different thread to keep this one pure?

Posted: **Wed Jun 16, 2010 12:44 am**

Nightmaretony wrote:

I never learned to make macros on the Kowalski assembler, am using jump tables. Do you know how I can do macros on that for a long jump as you mentioned?

I tried synthesizing the '816's branch long instruction in the Kowalski simulator thusly:

Code: Select all

brl      .macro .op            ;long relative branch
         .if .op 
.bb      =*+3
.os      =.op-.bb
             .if .os > 32767
                 .error "FORWARD BRANCH OUT OF RANGE"
             .endif
             .if .os < -32768
                 .error "BACKWARD BRANCH OUT OF RANGE"
             .endif
             .byte $82,<.os,>.os
         .endif
         .endm

The above would be coded in a program as:

Code: Select all

         brl target

Unfortunately, the macro fails on a forward branch because the .os =.op-.bb expression involves a reference to a yet-to-be-defined location (the macro's operand).

6502.org

memory subsystem for fast 6502