Commander X16

Thank you Stefan — I didn’t know that.

I had the ADC in mind, if I stored 1 in A, then I’d be incrementing with carry.  Then I’d have to BCS or whatever that’s called, which is still messy I suppose.

Found hints of this on the infowebs...

But I may be very wrong.

 

clc

Lda #01

adc >my-address

adc <my-address

 

Its probably really slow, right?  4 clocks each for the ADC $$$$.  Or there’s a fundamental flaw in my logic.

This makes me think about SWEET16

I guess you could use ADC, but it would be more code and slower.

Assuming you are using r0 as zero page vector, this might work (not tested):

 

On 12/25/2021 at 8:40 AM, rje said:

Found hints of this on the infowebs...



But I may be very wrong.



 



clc



Lda #01



adc >my-address



adc <my-address



 



Its probably really slow, right?  4 clocks each for the ADC $$$$.  Or there’s a fundamental flaw in my logic.

You're just looking to increment a 16 bit index spread across two bytes.  The INC and INX and INY operations set the Z flag if the result is zero and sets the N flag if the most significant bit of the result is 1.

So, if your 16 bit value is stored in say zero page addresses 7E (low byte) and 7F (high byte) then

INC 7E

BNE# 02

INC 7F

And @ZeroByte is correct, the easiest way to save something from VRAM to file is to copy it to low RAM and save it from there.  Or if it is a big file, copy it to consecutive banks of banked RAM and save it from there.

On 12/23/2021 at 9:53 PM, Greg King said:

That's BASIC's way of doing it.  In Assembly, SETLFS doesn't take anything in the accumulator for LOAD/SAVE calls.  And, the "VRAM bank + 2" is put into the accumulator of the LOAD call (i.e., the 17-bit VRAM address is given directly to the LOAD call).

I knew better than that - it's the .A value of LOAD, not SETLFS. Whoops. (fixed my post)

Thanks for pointing it out.