Commander X16

I posted this on Discord, but thought it could be useful for future consideration. (and anyone not on discord)

1. It would not effect any current software
2. I know FPGA space is limited, and I think this would require minimal space...it's just exposing values already tracked



WHAT:
Using a new DCSEL mode, 6 is currently unused
Have VERA_ADDRL,VERA_ADDRM,VERA_ADDRH for both ports available for direct access

WHY:
Since VRAM can't be banked for direct CPU access, this mode could allow "easier random" access to VRAM
*I'll leave it for other smarter people to improve, like VERA FX

EXAMPLES:

1. Compression routines often require offsetting from data already decompressed, which requires reading back from the current "pointer"
Having to switch selected port just to access the current L/M/H slows things down, increases code size etc.
also this could eliminate the need to use a CPU pointer (zero page?) since all the inc/dec would be handled by VERA

2. Config both ports at once. Say you want to do a palette fade again FPGA space is limited, but maybe someday this could be squeezed into it

working with an 8-bit system, every cycle counts

It's a neat idea, but the "DCSEL" area is only 4 registers, and to fully configure ADDR0 or ADDR1, you need three registers each, so both won't fit in one DCSEL.

If you're worried about code size, you can switch to ADDR0 in one instruction: STZ $9F25 (3 bytes, 4 cycles).
Then, if ADDRSEL is known to be 0 already, you can use INC $9F25 to switch it to 1 (3 bytes, 6 cycles).
For reference, LDA #$nn STA $9F25 is 5 bytes, 6 cycles, so that STZ trick is the biggest gain.

If you need to switch without changing DCSEL, then you can use INC/DEC again, as long as you know what the state of ADDRSEL would be at that point in your code.

Yes but could this not be true for DCSEL 6 or w/e...

$9F20 - $9F22 - Data0 LMH
$9F29 - $9F2B - Data1 LMH
$9F2C still free for some wizard to help define for better VRAM access

again, I do understand and this is just a convenience add.
but I have found so many cases this could be useful and faster.

hey, maybe in this mode would NOT have a latched value and really reads what the LMH points to...I can dream

Oh! I hadn't thought of that; DCSEL exposing one ADDR and you set ADDRSEL to the other one, and now both are exposed.

I'm not sure how much this would simplify code, but I'd be fine with this feature.

badmai wrote: ↑Wed Jan 29, 2025 3:05 am lda #1
sta VERA_ADDRH0
sta VERA_ADDRH1
lda #$FA
sta VERA_ADDRM0
sta VERA_ADDRM1
lda #$00
sta VERA_ADDRL0
sta VERA_ADDRL1

I doubt there would be such a change at this point. Maybe VERA2? Anyway in the timebeing you can do this which isn't too many more cycles that the 'ideal' solution above.

Compression routines often require offsetting from data already decompressed, which requires reading back from the current "pointer"

Oh, and be careful with this, the value in DATA0/1 is set on an address change, not on a read. So if you set DATA0 to point to 0x00000, then change it using DATA1, DATA0 will still point to the original value.

Yes, that is what I was talking about when I said "latched value"...i've ran into that in the past