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

[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]

Could it be that the print hex function changes the VERA address, for instance by printing something?

[ahenry3068]

Could it be that the print hex function changes the VERA address, for instance by printing something?

This.

[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

[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

[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]

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]

Both ports use 9F20-22.

[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

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