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 : CMM2: V5.05.06RC19: Scotty more power
Page 4 of 4 | |||||
Author | Message | ||||
LeoNicolas Guru Joined: 07/10/2020 Location: CanadaPosts: 444 |
I realized that my Octahedron code runs 20 ms slower on the RC20 compared to the RC19. Is this difference expected? Edited 2020-11-17 16:02 by LeoNicolas |
||||
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8578 |
V5.05.06RC21 posted: http://geoffg.net/Downloads/Maximite/CMM2_Beta.zip This includes a more aggressive crunch on load making the stored program even smaller and very slightly faster. In addition mm.info(modified fname$) will return a valid datetime if fname$ is a directory (new) or a blank string if nothing is found (as in RC19 and before) I had to improve the handling of co-linear coordinates in the triangle draw routine as one combination could yield incorrect results. I've also tightened up the stack overflow handling. NB: I'm about to redo a big part of the graphics engine. If it works the result will be V5.06.0 and V5.05.06 won't ever happen |
||||
JoOngle Regular Member Joined: 25/07/2020 Location: SwedenPosts: 82 |
We're not worthy, we're not worthy (Wayne's world). Thanks Peter, to follow your development is nothing short of mind-blowing. |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 3839 |
Good morning, Here is today's offering: Colour Maximite 2 MMBasic Version 5.05.06RC21 Copyright 2011-2020 Geoff Graham Copyright 2016-2020 Peter Mather > list "bug.bas" ' Copyright (c) 2020 Thomas Hugo Williams Option Explicit On Option Default None #Include "bug2.inc" foo() End > list "bug2.inc" Sub foo() Local j% j% = 0 Print j% Inc j% Print j% End Sub > run "bug.bas" 0 6 The output should of course be: 0 1 Note that the #Include matters, if I flatten the example then it produces the correct output EDIT: If you explicitly set the increment you don't see this issue: Inc j%, 1 Best wishes, Tom Edited 2020-11-17 20:49 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8578 |
Will fix Edited 2020-11-17 20:58 by matherp |
||||
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8578 |
Fixed and re-uploaded - no version change |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 3839 |
Thanks Peter. I'm in the process of enhancing my unit-test framework so it is possible to run all the tests in a directory hierarchy with a single command. Once I've done that then perhaps you'd consider running that command as part of your release process since it seems that my code "reaches the parts that other beers cannot reach." Best wishes, Tom Edited 2020-11-17 21:04 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
LeoNicolas Guru Joined: 07/10/2020 Location: CanadaPosts: 444 |
Wow, the RC21 is running my octahedron 8 ms faster than the RC19 and 28 ms faster than the RC20. Amazing job Peter. Thank you |
||||
LeoNicolas Guru Joined: 07/10/2020 Location: CanadaPosts: 444 |
I found a bug with the INC command. If I put more than one INC command in the same line with the increment equals to zero, all INC commands except the last one in the row will increment the variables by one. dim i,x,y,z for i=1 to 10 inc x,0:inc y,0:inc z,0 print str$(x)+", "+str$(y)+", "+str$(z) next The result will be: 1, 1, 0 2, 2, 0 3, 3, 0 4, 4, 0 .... EDIT: The first two INC commands are always incrementing by one, even if I change the increment value for a value greater than 1. Edited 2020-11-18 15:13 by LeoNicolas |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 5901 |
The problem is bigger than it first looks. Any multi-statement line with any INCrement reverts to INC of 1 The INCrement can be a literal or variable. Both will fail. dim i,x,y,z, f f = -1 for i=1 to 10 inc x,f : ' test inc y,f inc z,0 print str$(x)+", "+str$(y)+", "+str$(z) next 1, -1, 0 2, -2, 0 3, -3, 0 4, -4, 0 5, -5, 0 6, -6, 0 7, -7, 0 8, -8, 0 9, -9, 0 10, -10, 0 Pushing the limits was always going to be a bumpy ride! Jim Edited 2020-11-18 16:08 by TassyJim VK7JH MMedit  MMBasic Help |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 5901 |
A strange problem with READ OPTION EXPLICIT OPTION DEFAULT NONE DIM INTEGER n, s DIM p1$, p2$ READ p1$, P2$ PRINT P1$+">> "+P2$ READ p1$, P2$ PRINT P1$+">> "+P2$ END DATA "I2C ","I2C parameter" DATA "I2C CLOSE ","I2C CLOSE" gives: I2C 1 >> I2C 1 parameter I2C 1 CLOSE >> I2C 1 CLOSE It gets even crazier with I2C2 in the DATA lines. With 650 data statements I estimate that 90% went through OK but that still leaves a lot of oddities. Jim VK7JH MMedit  MMBasic Help |
||||
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8578 |
Jim I've noted and fixed your two bugs but the code is in bits at the moment as I'm re-writing a big part of the graphics engine so no updates for the moment - sorry |
||||
William Leue Guru Joined: 03/07/2020 Location: United StatesPosts: 382 |
Speaking of bugs, I had a weird thing happen to me yesterday. While editing and testing a short MMBasic program, I decided to change a line at the top of the program that set the graphics mode. Initially it said mode 1,8 But I didn't like the very limited gray-scale colors that are available in this mode, so I changed that single line to mode 1,16 and then ran the program. To my surprise, the program, instead of running and showing some graphics, did nothing for several seconds and then terminated. But that is not the weird part. Going back into edit, I discovered to my horror that several lines of the program source had been corrupted! And even worse, after I fixed them and re-ran the program, the same lines of the source were corrupted again. Power-cycling the computer did not stop the problem from happening yet more times. If I changed the mode back to 1,8, everything ran correctly. It sounds as if the firmware on 5.05.06RC15 has a bug that causes the editor to go wonky when the graphics mode is changed to 16-bit. I realize this is going to be tough to debug since it is so complicated. Hopefully a more recent release candidate fixes the issue. -Bill |
||||
jirsoft Guru Joined: 18/09/2020 Location: Czech RepublicPosts: 532 |
Hi Bill, I have similar problem, but didn't realised the connection to 16 bit mode. Since change back to RC10 (or so) and later to RC21, the problem was not there... Jiri Napoleon Commander and SimplEd for CMM2 (GitHub), Â CMM2.fun |
||||
William Leue Guru Joined: 03/07/2020 Location: United StatesPosts: 382 |
Thanks, Jiri! I will update to a new release candidate soon. In the mean time I am keeping away from 16-bit graphics. -Bill |
||||
markboston36 Regular Member Joined: 27/10/2020 Location: United StatesPosts: 76 |
when will 5.05.06 be released? i see we already have 5.06 beta's |
||||
panky Guru Joined: 02/10/2012 Location: AustraliaPosts: 1094 |
http://geoffg.net/Downloads/Maximite/CMM2_Beta.zip This includes a more aggressive crunch on load making the stored program even smaller and very slightly faster. In addition mm.info(modified fname$) will return a valid datetime if fname$ is a directory (new) or a blank string if nothing is found (as in RC19 and before) I had to improve the handling of co-linear coordinates in the triangle draw routine as one combination could yield incorrect results. I've also tightened up the stack overflow handling. NB: I'm about to redo a big part of the graphics engine. If it works the result will be V5.06.0 and V5.05.06 won't ever happen ... almost all of the Maximites, the MicromMites, the MM Extremes, the ArmMites, the PicoMite and loving it! |
||||
Page 4 of 4 |
Print this page |