search

uli / basicengine-firmware

BASIC Engine Firmware
78 stars 16 forks source link

fixes for issues #16/#17/#18 #20

Closed konimaru closed 4 years ago

konimaru commented 4 years ago
bitartrate commented 4 years ago

Konimaru; please let us know what the new syntax for VPOKE and VPEEK is. Thank you.

konimaru commented 4 years ago

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")
bitartrate commented 4 years ago

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.

konimaru commented 4 years ago

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.

bitartrate commented 4 years ago

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!

konimaru commented 4 years ago

OK, let me know when/if anything needs to be done on my side.

And apologies for the extra work.

uli commented 4 years ago

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 (": <command|function>: ").

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!

konimaru commented 4 years ago

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.