 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : Micromite MMBasic V5.2 Beta 1
  Page 3 of 3 |
|||||
| Author | Message | ||||
| robert.rozee Guru  Joined: 31/12/2012 Location: New ZealandPosts: 2292 |
right, try this: type NEW type EDIT enter 30 lines, each a single character thus: 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 now scroll up to the very top, press f4 to mark, scroll down so that the first 5 lines are highlighted (1...5) and press f4 again. now scroll down to the end and observe cursor sitting at end of the status line. now press f1 to save, then type EDIT to go back into the editor and observe what has been saved. cheers, rob :-) |
||||
panky Guru Joined: 02/10/2012 Location: AustraliaPosts: 1098 |
Geoff, I can confirm issues with EDIT in 5.1 on a MM2 (Circuit Gizmos Microkit) My test with both TerraTerm and MMEdit in chat mode gave the following NEW EDIT enter 12 or more line such as 11 22 33 44 55 66 77 88 99 00 -- == then hit F1 to exit now enter LIST, the following is displayed 11 22 33 44 55 66 77 88 99 1 -- == > Also, as Rob indicated, when you use F4 to cut code, this causes corruption also - in my case the second top line dissappears. Doug. Edit: You may well ask "Why enter non basic code!!!"  ... and you would be right in doing so! When correct basic code is entered, no corruption occurs. Eg. Enter PRINT "a", PRINT "b" etc etc on successive lines and after F1 to save and LIST, all is correct.
However, there does still appear to be an issue when using F4 - in my case the second top line dissappears after the scroll to bottom, scroll to top and F4 F4 then F1 - but only in EDIT. If I subsequently LIST, line 2 is still there. Edit: Hope I haven't wasted any of your time Geoff - the second line issue is only in MMEdit, NOT in TerraTerm so problem is not in MMBasic (I don't think). Doug. ... almost all of the Maximites, the MicromMites, the MM Extremes, the ArmMites, the PicoMite and loving it! |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 5916 |
Starting lines with numbers looks too much like line numbers. I am not sure if the later versions of MMBasic can handle line numbers. By repeating the test using a b c etc, I couldn't see any problem. MMEdit is not a good choice when testing MMBasic Edit mode. I have tried to make it compatible but TeraTerm is the preferred reference to use. Jim VK7JH MMedit MMBasic Help |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3165 |
As the man from Tassy said, the numbers will be interpreted as line numbers (MMBasic will still accept them) and strange things could happen when you load and save a program that has nothing but line numbers. Especially when using the number zero. I suppose I could hunt down the cause of the strange results but why? The editor is intended for editing programs. Rob, I tried your test with 30 digits but I could not get the cursor "sitting at end of the status line". I seem to remember something like this being mentioned a while ago and I could not find it then. Could it be an issue with your terminal emulator? Geoff Geoff Graham - http://geoffg.net |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2292 |
yes, i do remember that problem. have just tried using hyperterm, with VT100 emulation set. although the function nkeys didn't work, i could get the cursor to go to the end of the status line. normally i am running teraterm version 4.89 (svn #6182), built december 1 2015, 07:27:50. try entering the following program exactly: 31 Print "A"
32 33 print "B" ensure there are NO spaces after the 32. the line numbers are important, they must be 31,32,33 as above. when i press f2 to save and run i get: Saved 25 bytes
A [2] 1 :! Then "B" Error: Invalid character: ! > > list 31 Print "A" 1 :! Then "B" > cheers, rob :-) |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2292 |
try this: with 26 lines in the editor, each one containing a single letter of the alphabet, position the cursor over the last letter (not to the right of it, but over the character - with the cursor sitting in the first column of the terminal). now press the up arrow key to run the cursor up to the top of the listing. the cursor will stop over 'a'. now press the down arrow key to scroll down to the end of the listing. on my setup, the cursor ends up at the end of the status line. same on teraterm and hyperterm. 
cheers, rob :-) |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3165 |
These have to take the record for obscure bugs 
The first one from panky and rob (a list of numbers) only caused trouble because zero was one of the numbers. The second from Rob (empty line with a line number of 32) would only cause trouble if the line number was one of a special sequence (32, 306, 562, etc) and the line was otherwise empty. The third (cursor at the end of the status line) would only cause trouble if you started by editing a completely empty program and the resultant number of lines was greater than the screen height and you had gone back to the beginning at some point. Thanks guys for the detailed description, it made it much easier to track them down. How you found them I don't know but they will be fixed in the next release. MMBasic must be in good shape if that is typical of the bugs left 
Geoff Geoff Graham - http://geoffg.net |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2292 |
many places i've worked for have 'asked me to leave' because i kept on find bugs like that! the record (most obscure and longest time to nail down) was a pair of co-dependent bugs that took 9 months to find, but finally explained several million dollars worth of electric motor soft-starters that turned themselves into doorstops. bugs like the 31,32,33 bug are problematic in that if someone saves a syntactically incorrect program during development, they have a small but very real probability of corruption. while the probability of each such event might be extremely low, the more people that use mmbasic, the more often the bug may surface (due to (1-p)^n taking off for large n). i'm hoping we can push n up into the millions! cheers, rob :-) |
||||
| Phil23 Guru Joined: 27/03/2016 Location: AustraliaPosts: 1664 |
Don't know if this is remotely related or correct, but would doing 2 different builds of the MMbasic for the smaller chips work. 1. Standard Build:- As is, all the features present for 99% of users. 2. Core Build:- The majority of special device functions dropped, but provided with the firmware as external cFunctions. Not something I'm ever likely to need, but could fit the needs of the advanced users who are pushing the smaller chips to their limits. Bit like Microsoft has always included in their Server O/S installation. Server Core install has zero GUI, totally command prompt & remotely driven. Don't know anything about there's firmware development tools, but thought I still mention it. Cheers. |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3165 |
This might be a solution to expanding the amount of program memory in the future but it has some serious issues: 1 - What do you remove and what do you leave in? Everyone will have their own opinion on this. 2 - It is not easy to replace something with a CFunction. They are difficult to write and a lot of the special devices (eg, IR receiver) need deep hooks into MMBasic which are not feasible in a CFunction. 3 - It is difficult creating and testing multiple versions of MMBasic. I already have two versions and testing these takes significant time, more versions would just multiple the issue. My current plan is to stick with just two versions and implement the facility to remove some parts (eg, the editor) with a configuration command. I am not certain that it will be feasible but on paper it looks doable. Having a cut down version or a version with removable bits will provide more program memory for the 5% of users who are running out of this memory but it will not help with the amount of RAM which is Justplayin's problem. The only practical answer to this is a chip with more memory like the MX470. Geoff Geoff Graham - http://geoffg.net |
||||
| Page 3 of 3 |
|||||
 Print this page |
