VERA vram -> vram copies on overlapping addresses not working?

[RickDangerous]

I have stumbled upon an issue with copying VERA memory, and I'm wondering if this is a hardware issue or an emulator issue.

Here's the scenario:

I fill the first 10 bytes of the VRAM with this pattern: 

$BB, $AA, $AA, $AA, $AA, $AA, $AA, $AA, $AA,  $AA

Then I point the D0 address to 0, and the D1 address to 1 - so just one byte apart. Both are set to autoincrement 1:

now I want to read from d0, and write to d1

lda $9f23

sta $9f24

this updates the VRAM to

$BB, $BB, $AA, $AA, $AA, $AA, $AA, $AA, $AA,  $AA

as one would expect!

the d0 address is updated to 1

the d1 address is updated to 2

but the memory the processor "sees" at 9f23 for do is still $AA - not $BB as it actually is in VRAM - as if the memory was read before the store:

the original lda $9f23 read from address 0 ($BB) incremented the address to 1 (still $AA at that point) and probably reads the memory only at that time?

then the sta $9f24 writes to address 1, changing it to $BB, but the contents of the $9f23 register does not change at this point.

so my question is: is this "intended" behavior in the sense that this is how VERA handles this situation? Or is this some kind of bug?

Thanks,

Erik

[kaos]

Can you provide a complete code sample that shows this behavior plz?

(Use the forum quote-function to get it somewhat pretty)

[Yazwho]

On 11/20/2022 at 8:11 PM, RickDangerous said:

so my question is: is this "intended" behavior in the sense that this is how VERA handles this situation? Or is this some kind of bug?

It is, I asked the same thing a while back as it caught me out as well.

The DATA registers are set when the address changes, not on the actual read. When you read, the address changes and thus the register updates. Before the next read if the data at the register changes the register will not reflect the new value.

I worked around it like this.

[RickDangerous]

On 11/20/2022 at 10:07 PM, kaos said:

Can you provide a complete code sample that shows this behavior plz?



(Use the forum quote-function to get it somewhat pretty)

Kaos, are you still interested in the source, even though Yazwho confirmed the behavior?

[RickDangerous]

On 11/21/2022 at 4:51 PM, Yazwho said:

It is, I asked the same thing a while back as it caught me out as well.



The DATA registers are set when the address changes, not on the actual read. When you read, the address changes and thus the register updates. Before the next read if the data at the register changes the register will not reflect the new value.



I worked around it like this.

Thanks for the workaround, yes - I also figured that out and did it very similar..

[RickDangerous]

On 11/21/2022 at 5:34 PM, RickDangerous said:

Thanks for the workaround, yes - I also figured that out and did it very similar..

A different workaround - if you have a register to spare:

lda $9f20

sta $9f20

Thats a few cycles faster than the inc/dec method, but it touches a register

another one, if you happen to know that you won't leave vera bank while copying, the direction doesnt change, etc.

lda #??  ; the value of the vera high / bank register, e.g. #$10

sta $9f22

Again, a little faster, a little smaller, a little less flexible.

 

[kakemoms]

Can you post the code? I like to look into this once I get my HW up and running.

I suspect it could be caused by line 136 in top.v of the VERA verilog code:

Code: Select all

    always @* case (extbus_a)

Which looks for address bus changes for triggering data reads.