|
Forum Index : Microcontroller and PC projects : PicoMite V6.03.00 Release
| Author | Message | ||||
| EDNEDN Guru Joined: 18/02/2023 Location: United StatesPosts: 306 |
I think I might have stumbled onto a LongString bug in PicoMite V6.03.00 Release. Depending on how 'Option Base' is set, lgetbyte() returns different values. With 'Option Base 0' the position information given by linstr() does not align with the information returned by lgetbyte(). I understand this could be argued either way. But it would seem to me that lgetbyte() should be consistent with the offsets returned by linstr() and used by lgetstr$(). If you flip the 'Option Base' to 1 you get different results than with it at 0. If the answer is this is not a bug, this deviant behavior of lgetbyte() should be documented as dependent on 'Option Base'. And so far I can't find any documentation that it is dependent on 'Option Base'. Below is a program that demonstrates the inconsistency: option base 0 dim integer b(1024) longstring clear b() j$ = chr$(13)+chr$(10)+"--------------some junk text---------------" longstring append b(), j$ longstring append b(), j$ longstring append b(), j$ longstring append b(), j$ longstring append b(), chr$(13)+chr$(10)+"Hello world."+chr$(13)+chr$(10) longstring append b(), j$ longstring append b(), j$ print "b() is currently set to:" longstring print b() p = linstr( b(), "Hello ") print "Hello found at offset ";p for a = p-5 to p+10 t = lgetbyte( b(), a) tt = t if t < 32 then tt = asc("?") print "Offset ";a;" using lgetbyte() has "; chr$(tt); " (";t;") " next a e$ = lgetstr$( b(), p, 12) print "lgetstr$() correctly returning "; e$;" at offset ";p Edited 2026-07-24 00:46 by EDNEDN |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 11753 |
The difference is deliberate. lgetbyte is intended to treat the longstring as a byte array which you would therefore expect to honour Option Base. It's not safe to change this behaviour as this would almost certainly break existing programs I'll add additional clarification to the user manual to make this clear. Edited 2026-07-24 01:10 by matherp |
||||
| toml_12953 Guru Joined: 13/02/2015 Location: United StatesPosts: 701 |
Update: I fixed the following by disabling the PSRAM and reenabling it. When I try to run the program below, I get Not enough PSRAM memory in line 21 (DIM c AS POINT). It doesn't seem like it should take very much, though. ' ' "Center.zen" solves for the center and radius ' of a circle ' ' Sample program for the Zeno Interpreter by: ' ' Stephen R. Schmitt ' 962 Depot Road ' Boxborough, MA 01719 ' OPTION base 1 TYPE POINT x AS float y AS float END TYPE ' program DIM r AS float DIM c AS POINT DIM p(3) AS POINT p(1).x = 7 p(1).y = 7 p(2).x = 0 p(2).y = 8 p(3).x = 0 p(3).y = 0 PRINT "points: "; PRINT "("; p(1).x; ","; p(1).y; "), "; PRINT "("; p(2).x; ","; p(2).y; "), "; PRINT "("; p(3).x; ","; p(3).y; ") " r = circ( c, p() ) IF r > 0 THEN PRINT "Circle: ("; c.x; ","; c.y; "),"; r ELSE PRINT "Not a circle!" END IF END ' ' Calculate center and radius of ' circle given three points ' FUNCTION circ( c AS POINT, p() AS point) AS float LOCAL i AS integer LOCAL float r, m11, m12, m13, m14 LOCAL a(3,3) AS float FOR i = 1 TO 3 ' find minor 11 a(i,1) = p(i).x a(i,2) = p(i).y a(i,3) = 1 NEXT i m11 = DET(a()) FOR i = 1 TO 3 ' find minor 12 a(i,1) = p(i).x^2 + p(i).y^2 a(i,2) = p(i).y a(i,3) = 1 NEXT i m12 = DET(a()) FOR i = 1 TO 3 ' find minor 13 a(i,1) = p(i).x^2 + p(i).y^2 a(i,2) = p(i).x a(i,3) = 1 NEXT i m13 = DET(a()) FOR i = 1 TO 3 ' find minor 14 a(i,1) = p(i).x^2 + p(i).y^2 a(i,2) = p(i).x a(i,3) = p(i).y NEXT i m14 = DET(a()) IF m11 = 0 THEN r = 0 ' not a circle ELSE c.x = 0.5 * m12 / m11 ' center of circle c.y = -0.5 * m13 / m11 r = SQR( c.x^2 + c.y^2 + m14/m11 ) END IF circ = r ' the radius END FUNCTION Option List: PicoMite MMBasic RP2350B V6.03.00 OPTION SERIAL CONSOLE COM1,GP0,GP1,BOTH OPTION LCD SPI GP10,GP11,GP12 OPTION SYSTEM I2C GP6,GP7, SLOW OPTION BAUDRATE 19200 OPTION FLASH SIZE 16777216 OPTION LIBRARY_FLASH_SIZE 4B000 OPTION COLOURCODE ON OPTION CASE UPPER OPTION TAB 8 OPTION DEFAULT COLOURS GREEN, BLACK OPTION KEYBOARD PICOCALC OPTION PICO OFF OPTION CPUSPEED (KHz) 384000 OPTION LCDPANEL CONSOLE ,, FF00 OPTION DISPLAY 26, 40 OPTION LCDPANEL ST7365P, PORTRAIT,GP14,GP15,GP13 OPTION BACKLIGHT LCD 80 OPTION GUI CONTROLS 50 OPTION SDCARD GP17, GP18, GP19, GP16 OPTION AUDIO GP26,GP27', ON PWM CHANNEL 5 OPTION RTC AUTO ENABLE OPTION MODBUFF ENABLE 192 OPTION PLATFORM PicoCalc OPTION PSRAM PIN GP47 Edited 2026-07-25 17:48 by toml_12953 |
||||
| ville56 Guru Joined: 08/06/2022 Location: AustriaPosts: 560 |
Running the prog above on an PicoMite MMBasic RP2350B V6.03.00 with or without PSRAM enabled, I get an error at > run points: ( 7, 7), ( 0, 8), ( 0, 0) [62] m11 = DET(a()) Error : Dimensions but no complaints about DIM c AS POINT .... 73 de OE1HGA, Gerald |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 11753 |
There is no function DET or array DET so like ville56, unable to test further |
||||
| toml_12953 Guru Joined: 13/02/2015 Location: United StatesPosts: 701 |
Oops! I defined DET(n() in the library as FUNCTION DET(n()) DET=MATH(m_determinant n()) END FUNCTION to help writing more standard BASIC code. I just wish MMBasic could have a function return an array. Then I could write even more MAT functions to match standard BASIC. Something like this: a()=INV(b()) ' Like MAT A = INV(B) in standard BASIC c()=TRN(r()) ' Like MAT C = TRN(R) in standard BASIC FUNCTION INV(n()) LOCAL m(BOUND(n(),1), BOUND(n(),2)) MATH M_INVERSE n(), m() INV=m() END FUNCTION FUNCTION TRN(n()) LOCAL m(BOUND(n(),1), BOUND(n(),2)) MATH M_TRANSPOSE n(), m() TRN=m() END FUNCTION Edited 2026-07-25 19:21 by toml_12953 |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 11753 |
> RUN points: ( 7, 7), ( 0, 8), ( 0, 0) Circle: ( 3, 4), 5 > |
||||
| Supertech Regular Member Joined: 13/11/2016 Location: AustraliaPosts: 67 |
I upgraded to V6.03.00 on all my Webmites including OPTION WIFI ssid$, password$, hostname$, ipaddress$, mask$, gateway$, country$ with working stable. Thank you. However, when I type these, I get? > list pins [LIBRARY] If MM.ADDRESS$ Then CLS Error : Expected a number > ? MM.SUPPLY Error : MM.SUPPLY is not declared > Regards. |
||||
| BarryH Regular Member Joined: 05/01/2025 Location: AustraliaPosts: 52 |
MM.SUPPLY is only designed to work for standard Pico/Pico2 boards - ie NOT Wifi, as GP25 (which is not exposed on board pins) is used by the wireless module. BarryH |
||||
| ville56 Guru Joined: 08/06/2022 Location: AustriaPosts: 560 |
LIST PINS works for me ... WebMite MMBasic RP2350A Edition V6.03.00 OPTION SYSTEM SPI GP2,GP3,GP4 OPTION SYSTEM I2C GP8,GP9 OPTION AUTORUN ON OPTION FLASH SIZE 4194304 OPTION COLOURCODE ON OPTION HEARTBEAT OFF OPTION CPUSPEED (KHz) 252000 OPTION DISPLAY 40, 145 OPTION LCDPANEL ST7789_320, PORTRAIT,GP14,GP13,GP15,GP16 OPTION WIFI JN88fg, *********, Nixie, AT OPTION TELNET CONSOLE ON OPTION SDCARD GP17 Clock> list pins Clock> GP0 1 OFF GP1 2 OFF GP2 4 Boot Reserved : SPI SYSTEM CLK GP3 5 Boot Reserved : SPI SYSTEM MOSI GP4 6 Boot Reserved : SPI SYSTEM MISO GP5 7 DOUT GP6 9 DOUT GP7 10 DOUT GP8 11 Boot Reserved : SYSTEM I2C SDA ... maybe you should nuke the Pico first, there seems to be some old data left over. Gerald 73 de OE1HGA, Gerald |
||||
| some_rando Newbie Joined: 25/03/2025 Location: AustraliaPosts: 9 |
I have long been a fan of Geoff Graham's ASCII Video Terminal https://geoffg.net/terminal.html, also published July 2014 in Silicon Chip. Although there were some incompatibilities with the VT100 "standard", I was able to get MMBasic variants starting at about 5.3 through 6.00.03 to talk seamlessly to the AVT with console on GP1/GP0. I also toyed with Fuzix, Micropython, Nuttx, Pi3A+ Linux builds with this architecture. The big advantages of the AVT were that it nominally drew 50mA from the 5V supply, used legacy VGA and PS/2 hardware, and could be turned off to save power, then turned back on - even while inside the MMBasic editor - resuming an editing session. Sadly, I just tried the latest MMBasic 6.03 variant which introduced changes to the editor code, and presumably the VT100 commands sent from the inbuilt editor. I now find that the editor gets to line 20, and then fails to scroll the upper portion of the screen. No doubt 6.03 was tested relentlessly with TerraTerm, and performs flawlessly. But without some serious work the AVT is no longer compatible. I can't even say this is a bug. The fact that the AVT had a common heritage with Micromite, and then Picomite (and others) was serendipity. The world moves on, and regardless, we must have a display in some form : VGA is legacy, and DVI/HDMI is now the standard. Given that the Pico's have two cores, and the newly discovered ability for one core to generate a VGA/HDMI display, it is a natural progression to have "boot-to" style versions of micropython, fuzix et al. (This idea may be shaken a bit when the next versions of the Pico family have four or more cores). My personal opinion is that this could all have gone in a different direction, downwards to the roots of home computing, and followed the earlier evolution towards native-code generating compilers like the Borland Turbo family. Why head in the contemporary direction to self-contained "boot-to" machines which generate a HDMI terminal using overclocking, when there is a market saturated with cheap high end machines which faultlessly run Linux, and every programming language ever invented? Finally, Fuzix has been running on RP2040 since mid 2021. You guys are just rediscovering it now because a core can be handed over to HDMI to create a terminal. Fuzix, Nuttx and the like have interpreters. No native compilers. Geoff Nutt wrote a Pascal compiler, but it compiles to an abstract P-machine. My money is on PShell, which has a RP2040/RP2350 native code compiler, Vi, and LittleFS file system. Last night I swapped-in my last running version from 2023, which still works perfectly. Today I'll look at the latest version. I am hoping there has been some progress. Unfortunately as goes with these things, PShell is held together by a lone author (Lurk101) who values anonymity, and has little time for lesser fools like me. Footnote added 2026-08-01 15:58 by some_rando Wow, I'm about a month late with Pico3, and language developments over there. I eat my hat. Not necessarily the AVT part. :-) |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 9035 |
The incompatibility with AVT surprises me a little. I would have thought that that part of the code was solid by now. VGA and HDMI have always been *additional* to the serial terminal capability AFAIK - you don't need to have either. You can, of course, run a version of the firmware with neither VGA nor HDMI. You should be able to define the serial terminal pins (GP8 and GP9 by default) in this instead of or in addition to using the USB serial port. I suspect that the direction of the evolution of the PicoMite has been at least partially set by the RAM and ROM capabilities of the original Pico. An interpreter is very efficient as a lot of it can remain in ROM, only requiring some workspace in the RAM area. The user program can be tokenized to reduce the RAM required before it is run. A compiler usually needs the source code, then an intermediate code as the linker operates then the final code. That can be quite some RAM footprint in total. It can also, depending on the target, be a very complex process. Remember, you have no disk drives or OS to help out. The RP2350 now has twice the RAM of the RP2040, a lot more flash and some memory management. If you simply want native code then you may as well use an Arduino or some other compiler on a PC, where you can have a nice IDE. Having everything, including keyboard and display handling, in one place is a much neater and more portable solution IMHO. :) Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2026 |