Commander X16

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)
(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.

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

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.

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

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

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

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.

Both ports use 9F20-22.

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

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.