RRB sprite number count limited because of colour ram wrap-around.

[MirageBD]

Setting chrcount to something bigger than $0100 will cause colour ram reads to wrap around at the $0200 mark, causing vic4 not to read intended gotox command any more just start drawing from the start of the row again.

Repro source and prg/d81 here: https://github.com/MirageBD/RRBBug

[MirageBD]

Trying to explain what my repro example is showing: When the charcount reaches $0100 colour ram will wrap around from $0200 to $0000 and start reading from there. It won't find a gotox character and will instead draw the goto-x position (320) as a regular char (reading from memory 320*64). I've mapped the char 320 to an up-arrow character to show that the chargen is not reading the gotox characters any more but is instead thinking that it should draw a regular char with char-index 320.

[drex69]

So, after having a conversation with MirageBD, I have created a repro, to show my problem.

I am not sure, if this is the same problem or not, or its just my dodgy coding ;)

This example is using FCM, but I cannot set CHRCOUNT > $80.

Have a look, and see what you think, if its nothing to do with Mirage's problem, let me know, and I will remove it.

Repro source and prg here: https://github.com/drex69/MEGA65/tree/main/RRB_BUG

[gardners]

There is nothing in the way that the colourram addresses are calculated that would cause the wrap directly. It is the is_fetch_start flag triggers the resetting of the offset to the colourram and screen ram addresses. That line is set once per raster line, or once on every even raster line if double-RRB is enabled.

Problem was actually screen RAM line (bad line) buffer being limited to 512 bytes. Increased to 1024 bytes.

[gardners]

Believed fixed. Once @MirageBD confirms it works for him, we can close it.

[MirageBD]

Seen fixed. Thank you very much @gardners :)

[MirageBD]

Closing as seen fixed by multiple people.