Closed konimaru closed 4 years ago
Konimaru; please let us know what the new syntax for VPOKE and VPEEK is. Thank you.
So far I only touched VPOKE (and I'm still thinking about VPEEK). It's still VPOKE addr, val
but val
can either be a byte value or a string expression, e.g.
vpoke 50000, string$(100, "X")
I typed the command as you presented it. I see I get two lines on the display at that video location. Is this the intended result or is it to print an X? Please explain the "string$(100, "X")" further.
Not sure why you get two lines (which screen mode?). The idea here was to allow more than a byte to be transferred at a time for speed reasons (from BASIC). I2C uses strings for block data as well so I kept using it. The strings$ creates a bytearray of 100x the byte value 88 (asc("X")). The 88 is just any colour value (blue) which is clearly visible. That said, it doesn't have to be data in the visible screen area.
Upon further testing with my new understanding from your reply I have found that my TV is also producing two scanlines in that color with the built in LINE command. It is doing that with some colors but not others. I have confirmed that your addition to the VPOKE command works. I think it is cool!
OK, let me know when/if anything needs to be done on my side.
And apologies for the extra work.
I have picked up most of these patches one by one because this system here is inscrutable to me. Apart from some minor touch-ups, the patches look good. I have, however, changed all commit titles to conform to the established form ("
I have not picked up "protect i2cr/w against blockmove, i2cr permits zero length", though, because I do not understand its purpose. What does "i2cr permits zero length" mean? Is it supposed to do that, or not supposed to do that? What did it do before the patch, what does it do afterwards? Such things needs to be clarified in the commit message. It also helps not to combine things that are unrelated into a single patch. (The block move guard is independent of the rest.)
Again, thank you for your contribution!
To be honest, I'm sort of glad the i2cr patch didn't make it. I'm currently investigating some i2c related issues and I think it's better to get them sorted first.