memory subsystem for fast 6502

[fachat]

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é

[Nightmaretony]

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!

[GARTHWILSON]

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.

[Nightmaretony]

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?

[ElEctric_EyE]

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?

[BigDumbDinosaur]

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