I agree that it has all gotten rather out of hand.
I am no longer even trying to keep MMBasic for Linux up to date with what Peter is doing and in addition because I’ve refactored or rewritten a number of fundamental pieces of the code it isn’t possible for me to automatically merge in his work so I have to pick and choose … not necessarily a bad thing.
Time for me to go to bed,
Tom
Have you tried thwill’s short test program on your RC21 with line continuation off ?
I haven’t, but I did just build the latest RC22, and it appears Peter’s code changes broke the i2c keyboard functionality on the PicoCalc. I had already prepped a release since the new code changes seemed realitvely minor, but when I went to test the build, the old “keyboard disconnect” i2c error appears immediately on boot. I know he was fixing something around the Wiimote for some other PicoMite platform(s), and I’m guessing that must be using i2c stuff and broke it.
After rolling back to RC21, I got the same error.
I misspoke earlier – the line-ending fix wasn’t from Peter’s updates, it was submitted separately, via email, from @Toml_12953. There’s probably a core Picoite problem that needs to be fixed instead though. Specifically, it was this change:
I think at this point we’re just spinning our wheels. It seems nonsensical to try to keep up to date with the latest RCs when they break as much as they fix. And trying to make fixes or changes for the PicoCalc when the core code is changing so much just means having to revisit and redo those changes as well. There also often doesn’t seem to be an actual need to chase these code changes beyond “ooh, look I can run the latest version”. Sometimes more interesting things come along like the display update code, which actually cleaned up the code and improved performance. But so many of these updates have been focused on features only relevant to other platforms, and experimental new features that create (or expose) as many bugs as they do new features.
Sorry for the off topic ramblings… One other thing I wanted to ask about though – @thwill, I signed up for an account on TheBackShed a few days ago, but I never got any kind of confirmation email. There’s no rush, but I just wondered if that’s usually how things go, or if I needed to do something else? Only reason I wanted access was to be able to post a thank you to Peter and and also be able to more easily follow the thread on there. But I can also just continue to lurk and observe as an outsider. I wasn’t really planning to post about issues like the i2c breaking in RC22, as I imagine by the time I did, it would be fixed and something else would be broken in another RC! 
How about your RC22 build, does this fix the line end bug or are we waiting for matherp to include in the next build ?
I2c timeout 500, guess this value determines how long to wait for a response from the keyboard ?
The input new line bug that was fixed/changed, now causes the bug thwill described, but I’m not sure Peter and TheBackShed folks are even aware of it. Currently we could have one or the other issue. I’m also not sure if it’s an issue only on the PicoCalc, of if other devices running the new builds would experience it too. But there seems like a way to test, so I’ll see about putting RC22 (non-PicoCalc) on a Pico and testing the behavior on the serial console. For this particular problem I think that would be a way to figure out if it’s just a PicoCalc thing or a universal thing (which maybe no one else is aware of yet). Unless it’s another bizarre keyboard issue (which it might be!), I’m guessing it might be a general problem with RC22 (and older builds going back to when it first appeared). The keyboard still has that issue with modifer keys that isn’t fixed as well, but that’s not something I know how to fix. (It’s that thing where, for example, reading input will show garbage for shifted keys like a “:” etc.) The regular PicoMite builds support some kind of solderboard (I think that was the name?) keyboard mechnism, and it’s clear the PicoCalc keyboard doesn’t work the same way, but how to address the problems that arise from those differences is still an open issue.
Yeah, I don’t know much about i2c stuff, and even less about the timing issues on it, but the PicoCalc keyboard seems especially sensitive to the timing settings. This might be due to the quality of the firmware running on it, and I know others have made changes and improved it, as well as adding features like being able to query the battery info, etc. There might be additional improvements in time from those efforts. Like someone mentioned working on adding RTC functionality since we have big charged batteries on the device that are unlikely to completely drain, and the keyboard STM32 could keep the time alive across power cycles and draw very little power to do so.
On a Pico, running Peter’s PicoMiteRP2040V6.00.02RC22.uf2, I get the result shown above. This was the buggy behavior @Toml_12953 reported and supplied the fix for. But this is on a Pico with no additional hardware connected via USB.
So it’s not just a PicoCalc issue. This is the same bug we saw here:
And the change made on the PicoCalc side to “fix” it, caused the bug @thwill described above.
I’ll roll back the changes for that fix, so then the PicoCalc version will match the bahavior of the upstream Picomite version. Then the INPUT bug will be the same for both versions. Someone should probably mention the issue on TheBackShed. I’ll refrain from doing so, since I already made one post that was ignored, and I prefer to be silent on there anyway. (Not even sure it was wise to join, but figured it was worth a shot.) 
@adcockm I’m not sure how your line-input / line-ending change could be responsible for this new bug, but also I wasn’t able to reproduce it using Peter’s standard PicoMite builds.
Though I do think your line-input / line-ending fix is “wrong”. I believe that the correct fix for both this and the issue with the modifier keys is to edit I2C.c#CheckI2CKeyboard() so that:
ConsoleRxBuf instead of putting in the keycode received.
\r or is it just \n ?Best wishes,
Tom
You weren’t able to produce the line-input bug on a standard RC22 PicoMite build? I’m not sure what I did wrong or how it happened in the screenshot above then, because that was on a freshly flashed RC22 PicoMite build and it didn’t produce a newline as expected. Is there possibly something wrong with my settings in the Maximite Control Centre? I almost never use the serial connection, so it might not be configured properly. I purposely used MMEdit because I thought it was what PicoMite folks were using. (Usually I just use PuTTY.) I suppose I could try TeraTerm since that also seems popular.
I got no confirmation email either. But I was admitted. Try to log in, maybe you are already admitted?
I think that’s because you are transmitting/receiving LF as line-ending, you should be sending carriage returns CR, or possibly CRLF.
Tom
Looking at the original code (and accepting I may not be thinking straight yet this morning) In PicoMite.c#MMgetline a line read from the console is expected to end \r whilst one read from a file is expected to end \n or \r\n.
I suspect that the PicoCalc’s I2C keyboard is “Unix oriented” so it sends the code for \n when “Enter” is pressed. If I am correct you need to capture this in I2C.c#CheckI2CKeyboard() and instead write the code for \r to ConsoleRxBuf.
Best wishes,
Tom
Thanks! Changing the line-ending to CR worked as expected.
Thanks for the pointers above too. I just need to figure out what codes the keyboard is actually sending (for enter, shift, alt). I was tempted to go looking in the code for the keyboard firmware, but then I realized I could probably try the BASIC that was mentioned in this thread:
I suspect the “Enter” key sends some kind of keycode as well, and may not be either \r or \n.
I suppose while I’m at it I can try out all the keys to make sure they aren’t doing weird stuff, and filter/translate as needed. The only one that is specifically handled (and is presumably correct) is the “Ctrl” key, which is also handled separately in the regular PicoMite code.
All good. I’m on there now.
And thanks to a night’s sleep I can see why your original fix broke Z-MIM.
Prior to your fix reading a \n from a file (filenbr != 0) would end the line (break) … and after your fix it didn’t (continue)
if(c == '\n') { // what to do with a newline
#ifdef PICOCALC
if(filenbr == 0 && EchoOption) {
MMPrintString("\r\n");
break; // on the console this means the end of the line - stop collecting
} else
continue ; // for files loop around looking for the following newline
#else
break; // a newline terminates a line (for a file)
#endif
}
You were 100% correct on all counts. For “Enter”, the PicoCalc sends 10 (\n) instead of 13 (\r). As for the modifier keys, “left shift”, “alt” (there’s only one on PicoCalc), and “right shift” all have unique keycodes that do get sent before the actual character code (which is properly changed, like with lowercase to uppercase codes). So detecting and throwing away those extra key codes are the way to go. “Ctrl” also sends a code which I think I should probably strip out as well – it’s being detected separately (and properly) to modify the key it goes with, but the initial code is probably still getting passed through as a character.
I also just realzied there’s a “CapsLK” key on the PicoCalc in a truly bizarre location. (It’s far away from the “shift” keys, on the second row of keys on the device from the top, between “Tab” and “Del”. I guess that’s why I never noticed it there. Ha!
Thanks so much for looking into this and your excellent suggestions and code pointers!
So PicoMite_PICORP2350_V6.00.02RC22a.uf2 is on the way with a coffee too ? 
(asking for a friend)
Sorry for the delay. (Got a little bit of sleep, since it’s around 6am here now.)
The delay meant Peter’s latest changes also made their way into this build.
And now it’s probably time we all stopped hijacking the Z-MIM thread, though it ended up being a productive sidetrack.
Coffee sent . Any plans for updates ?, will try removing all comments to see if it speeds things up a little 
UPDATE…
Removing all comments certainly speeds things up !. Spinning cursor and hence instructions calculated much faster
Thank you for the coffee .
I assume this means Z-MIM is now working again with the latest PicoCalc/PicoMite firmware ?
I have a number of irons in the fire so I’m not going to commit to updates (other than bug fixes) so you will just have to wait and see.
That’s good to know - I knew there would be an effect but I hadn’t expected it to be especially significant - I can strip comments automatically for the “bin/” versions of the files in the next release. Note that comments between functions/subroutines shouldn’t matter, only those within - not that my comment stripping tooling distinguishes.
Best wishes,
Tom
Yes adcockm’s…
All comments removed to minimise size too. Note variables used in critical loops can be speeded up by declaring at the beginning of the program (MMBasic can find them faster when referenced).
Moving forward a status bar should be an easy addition. Yet to add atmosphere to the game I’d love to see atmospheric sounds added to locations such as water noises by a stream, creaking etc within houses, rustling leaves and wind in forests…