registers $030c-$030e

[aitsch]

hi folks,

i 've read in the programmer's reference guide that the registers
$030c-$030e are the satorage areas for .A, .X, .Y registers.

my first understanding was that i have direct access to the a,x,y registers but
a ldx #$01 does not store the value 1 in $030d.
the same (not) for lda and ldy

what are these registers for?

greetings
aitsch

[srowe]

They're not really registers. They are storage used by BASIC to allow you to pass values for registers into and out of a SYS call. So you can POKE values in and that is what will be in the registers when you enter machine code and the values the registers had when you RTS will be stored back there.

Here's how they are used

https://eden.mose.org.uk/gitweb/?p=rom- ... HEAD#l8494

[aitsch]

ahhh thx.

so that means, it is not possible to have "direct access" to the X/Y registers

[chysn]

so that means, it is not possible to have "direct access" to the X/Y registers

The thing is, the registers are constantly changing as BASIC does things and the IRQ plugs away. So having "direct access" to the registers from BASIC isn't that meaningful a concept. These locations are pretty good for setting and getting registers in BASIC in the most relevant way possible.

When you perform SYS, BASIC grabs the values at these locations and loads them into the appropriate registers before jumping to the SYS vector at $14. But before it does that, it puts a return address on the stack to go to the end-half of SYS. This "tail" routine STORES the registers in those locations after the routine returns.

The idea here being that you can set registers for a machine language call, and then get the register values after the machine language call.

Obviously, if you're writing machine language code, you already have direct access to the registers.

[Mike]

The 6502 itself does not keep the A, X and Y register values in external memory, they're internal to the CPU.

If you read carefully, what's written in the PRG reads: "Storage for 6502 .A (.X/.Y/.P) register" and not "6502 .A (.X/.Y/.P) register".

srowe's hot-link into the relevant code section doesn't work for me - here's what SYS does:

Code: Select all

.E127  20 8A CD  JSR $CD8A    ; read numeric argument
.E12A  20 F7 D7  JSR $D7F7    ; convert to integer in $14/$15
.E12D  A9 E1     LDA #$E1     \
.E12F  48        PHA           \ push $E144 - 1 on stack as return
.E130  A9 43     LDA #$43      / address for machine code routine.
.E132  48        PHA          /
.E133  AD 0F 03  LDA $030F    \
.E136  48        PHA           \
.E137  AD 0C 03  LDA $030C      \ prepare A, X, Y and P registers
.E13A  AE 0D 03  LDX $030D      / from addresses $030C..$030F
.E13D  AC 0E 03  LDY $030E     /
.E140  28        PLP          /
.E141  6C 14 00  JMP ($0014)  ; call machine code routine (RTS returns to $E144)
.E144  08        PHP          \
.E145  8D 0C 03  STA $030C     \
.E148  8E 0D 03  STX $030D      \ update $030C..$030F from
.E14B  8C 0E 03  STY $030E      / A, X, Y and P registers
.E14E  68        PLA           /
.E14F  8D 0F 03  STA $030F    /
.E152  60        RTS          ; return to BASIC interpreter loop

Greetings,

Michael

P.S. to my knowledge, there's only one contemporary CPU that actually kept (most of) its registers in external memory, and that was the TMS9900.

[groepaz]

8051?

[Mike]

8051?

That's a well placed attempt at a cornering case: the RAM containing the registers is internal to the microcontroller, so my assertion above still holds. Yet one is able, in principle, to take their address - so that would disqualify them as registers, at least in C sense. More like a memory-memory architecture (possibly even the 'register' operand instructions use only aliases of memory operands).

You could add the several stack based CPUs to this list, of course.

And the 65xx could also be regarded as having 256 8-bit or 128 16-bit memory mapped registers (with A, X and Y just acting as scratchpads...)