Issue with reading VRAM with auto-increment (via ASM)

All aspects of programming on the Commander X16.
Post Reply
SolarSurfer
Posts: 30
Joined: Sun Nov 26, 2023 2:18 am

Issue with reading VRAM with auto-increment (via ASM)

Post by SolarSurfer »

I'm new to assembly and am having a hard time understanding why my code to read VRAM is behaving the way it does. I'm using x16emu r45 and cc65 to assemble.

I followed along with Matt Heffernan's "Hello VERA" tutorial ... https://www.youtube.com/watch?v=Wn8-unoaWSc ... (the slide at around 8:48)

I tried writing my own code to read 5 bytes of VRAM at address $1B000 (the tutorial is based on an old emulator, so it uses $00000)

Code: Select all

    stz VERA_ctrl ; ADDRSEL=0
    lda #($10 | ^VRAM_ADDR) ; Stride 0001xxxx
    sta VERA_addr_bank
    lda #>VRAM_ADDR
    sta VERA_addr_high
    lda #<VRAM_ADDR
    sta VERA_addr_low

    ldx #5
@read_loop:
    lda VERA_data0   ; read from VRAM
    jsr print_hex ; Matt's subroutine to print .A as a hex string
    dex
    bne @read_loop
(variable names above are based on Matt's tutorial's naming conventions). The first read works perfectly. But every subsequent read (i.e. LDA $9F23) just returns $20. That's not what's in memory (I checked via x16emu's debugger)

By my understanding, the "stride" should auto-increment behind the scenes, such that my next LDA gets the next VRAM addr's value. It seems to work perfectly for writes (STA) but not for reads (LDA).

If I change my code to just make 5 distinct reads, incrementing the addr myself (and setting stride zero) then it works fine. But that's horribly inefficient. I can't for the life of me figure out what I'm doing wrong with the stride/loop approach. Any advice is appreciated.
Stefan
Posts: 454
Joined: Thu Aug 20, 2020 8:59 am

Re: Issue with reading VRAM with auto-increment (via ASM)

Post by Stefan »

Could it be that the print hex function changes the VERA address, for instance by printing something?
User avatar
ahenry3068
Posts: 1131
Joined: Tue Apr 04, 2023 9:57 pm

Re: Issue with reading VRAM with auto-increment (via ASM)

Post by ahenry3068 »

Stefan wrote: Sun Nov 26, 2023 6:27 am Could it be that the print hex function changes the VERA address, for instance by printing something?
This.
SolarSurfer
Posts: 30
Joined: Sun Nov 26, 2023 2:18 am

Re: Issue with reading VRAM with auto-increment (via ASM)

Post by SolarSurfer »

Wow, that's quite a surprise to me, but indeed that's exactly what's causing the problem. After the lines of code that establish VERA control and VRAM addr, I changed my logic to loop-and-store-to-RAM, then loop over RAM and print.

Code: Select all

    ldx #5
@read_loop:
    lda $9f23
    sta ZP_DATA,x
    dex
    bne @read_loop

    ldx #5
@print_loop:
    lda ZP_DATA,x
    jsr print_hex
    dex
    bne @print_loop
... and, it works perfectly! It prints out on screen the hex representation of the 5 bytes at the VRAM addr.

Thank you Stefan and ahenry3068 :)
Last edited by SolarSurfer on Sun Nov 26, 2023 2:21 pm, edited 1 time in total.
SolarSurfer
Posts: 30
Joined: Sun Nov 26, 2023 2:18 am

Re: Issue with reading VRAM with auto-increment (via ASM)

Post by SolarSurfer »

A follow-up question ...

How could I have known that writing to one area of VRAM (indirectly via the print_hex subroutine's "jsr $FFD2") would cause VRAM reads (directly via "lda $9F23") to fail in another area of VRAM? Though I'm greatly appreciative of your help in the forum, I'd like to know-how-to-know these things myself, too. Hopefully soon I can contribute to the forum too, instead of only asking questions.

I didn't see any caveats in https://github.com/X16Community/x16-doc ... ram-access ... is it a quirk of the emulator? Or established behavior of the real VERA hardware?

FWIW, you can see the print_hex impl here: https://github.com/SlithyMatt/x16-assem ... ck.asm#L74
Last edited by SolarSurfer on Sun Nov 26, 2023 3:14 pm, edited 2 times in total.
Stefan
Posts: 454
Joined: Thu Aug 20, 2020 8:59 am

Re: Issue with reading VRAM with auto-increment (via ASM)

Post by Stefan »

The only way to read or write VRAM is to first set the address at 9F20-9F22. Printing with FFD2 is writing to VRAM.

So any function reafing or writing VRAM is bound to touch the address bytes.

A function could preserve the VRAM address, but in most cases that is not done. You need to test tovreally know
Guybrush
Posts: 63
Joined: Fri Jul 10, 2020 10:38 pm

Re: Issue with reading VRAM with auto-increment (via ASM)

Post by Guybrush »

SolarSurfer wrote: Sun Nov 26, 2023 2:19 pm Wow, that's quite a surprise to me, but indeed that's exactly what's causing the problem. After the lines of code that establish VERA control and VRAM addr, I changed my logic to loop-and-store-to-RAM, then loop over RAM and print.
You could have also used the other VERA data port (VERA_data1) for reading, which the print_hex subroutine doesn't use.
Stefan
Posts: 454
Joined: Thu Aug 20, 2020 8:59 am

Re: Issue with reading VRAM with auto-increment (via ASM)

Post by Stefan »

Both ports use 9F20-22.
SolarSurfer
Posts: 30
Joined: Sun Nov 26, 2023 2:18 am

Re: Issue with reading VRAM with auto-increment (via ASM)

Post by SolarSurfer »

Thanks, Stefan. Now I understand: The $9Fxx range of I/O registers are the ONLY way for the CPU to talk to VERA. Whether it's my own code or a Kernal subroutine in ROM, they all share those registers.

This is very cool, I'm starting to understand the whole system much better :)
User avatar
ahenry3068
Posts: 1131
Joined: Tue Apr 04, 2023 9:57 pm

Re: Issue with reading VRAM with auto-increment (via ASM)

Post by ahenry3068 »

KUDO's. You dove right into a tricky subject. I've been at this about 7 months now and I didn't start tackling VERA stuff until about 4 months in.
Post Reply