| Menu | JAQForum Ver 19.10.27 |
| Menu | JAQForum Ver 19.10.27 |
Forum Index : Microcontroller and PC projects : PicoMite V6.02.01 betas
  Page 7 of 8   |
||||||
V6.02.01b PicoMiteV6.02.01b7.zip All versions Various internal tidying and coding improvements New command ONESHOT |
||||||
A question: has the use of LOCAL within executable code in SUBs and FUNCTIONs been quietly made acceptable in some cases? Peter had noted that he had not been able to teach his AI not to put LOCAL in places where MMBasic would throw a syntax error, and I have found the same with Gemini--that is its most frequently repeated syntax error. But I'm finding now that while Gemini keeps inserting LOCALs within code, it's usually not objected to unless there is some other issue with the syntax. This has certainly reduced my frustration with Gemini. So has a change been made? |
||||||
LOCAL can appear anywhere within a subroutine - this has always been the case. The error the AIs make is to put it inside a looping structure which will cause an error when it is executed the second time. |
||||||
The AI "thinks" LOCAL has block-scope like local variables do in most (?) languages, but in MMBasic LOCAL has function/subroutine scope. Tom |
||||||
Ah, ok, thanks. Tom--yes, the errors I had been seeing were when it was in DO or FOR loops. I had not yet noticed that it was accepted when not within re-executed code in a SUB or FUNCTION. |
||||||
Here is my sad result trying to use the framebuffer with Peter's Pico2 HDMI board with firmware: HDMIUSB: Mode 3. Will PSRAM help with this? Anything else I can do to gain the needed memory? All string arrays have LENGTHs, and I think I've trimmed as much else as is feasible. EDIT: Just tried with Mode 2, and that works (but will take some resizing of things). ~ Edited 2026-03-02 02:47 by lizby |
||||||
Yes, framebuffer works in all resolutions. Also good for variables, blit slots, ram slots etc, no need for option modbuff Just what comes to my mind right now, I'm sure that there are some more benefits |
||||||
strange behavior when using WEB CONNECT "ssid", "password" in a program on a Pico-W-2, I get the error Error : Invalid in a program WEB CONNECT without parameters does not throw an error, even if no OPTION WIFI was specified before. <but it seems to do nothing... has this always been so? At least the manual does not state that this is only allowed on the commandline. Is there no way to specify the network I want to connet to in a program? |
||||||
Hi Lizby, Why are you defining a Framebuffer? they take a large chunk of memory and are only really used when you are doing stuff fast on the screen, like fast moving graphics or games. |
||||||
How did you ultimately achieve that? In MMBasic itself (specifically in the FileSystem adapter layer) or did you patch LittleFs in a few places? Regards |
||||||
AFAIK yes, use WEB CONNECT to define it once and then a restart of the cpu is required. Once defined, it will reconnect to the network after a reboot or power cycle. As for a change of the parameters a reboot is required, it only works from console. |
||||||
Vibe Virtual Model Railroading (TM ;-} ). So, yes, there is a lot happening on the screen. It works at HDMI 640x480 mode 3 without framebuffers, but you can see some of the workings of the screen writing. With mode 2 320x240 it's clunkier in appearance, but smoother in action. I'd like to run it at 640x480 with a framebuffer, and am hoping that will be possible with PSRAM. |
||||||
@lizby Resolution 1024 or 1280 in Mode 3 look very nice and could work with framebuffer without PSRAM..maybe have a look ;) |
||||||
How would I be able to have a framebuffer at 1024 or 1280 when there's not enough memory for one at 640x480 with 4-bit color? This is a 1700+ line program with a 2700+ line library and lots of fairly big arrays. Edited 2026-03-02 07:18 by lizby |
||||||
Because of the lower resolution: OPTION RESOLUTION 1024x768 MODE 1 1024x768x2-colours with RGB332tiles, optional layer buffer MODE 2 256x192x16colours and colour mapping to RGB332 palette, optional layer buffer MODE 3 512x384x16 colours and colour mapping to RGB332 palette, optional layer buffer MODE 5 256x192x256 colours, optional layer buffer OPTION RESOLUTION 1280x720 MODE 1 1280x720x2-colours with RGB332, optional layer buffer MODE 2 320x180x16colours and colour mapping to RGB332 palette, optional layer buffer MODE 3 640x360x16 colours and colour mapping to RGB332 palette, optional layer buffer MODE 5 320x180x256 colours, optional layer buffer Man page 73 |
||||||
Some of the changes I’d like to see in a future version: OPTION PRINTZONES ON|OFF Allows print zones in PRINT statements. Default: OFF and OPTION ZONEWIDTH n Sets the width of print zones to n columns. Default: 10 What this will do is to allow the comma in a PRINT statement to act like other BASICs and move the cursor to the next print zone rather than just print a single space. I know it’s not as useful for a 40-column display but still it would make converting old BASIC programs a lot easier. The default is OFF for compatibility with other PicoMite BASIC programs. If you don’t want to use it, then do nothing and your programs will work as they always have. |
||||||
Something is not right here... the comma should advance the output to the next tab stop (default 8 char). Geoff |
||||||
Thanks, but: I tried OPTION RESOLUTION 1024x768 Mode 3 512x384x16 : Not enough Heap memory. And OPTION RESOLUTION 800x600 Mode 2 400x300: Not enough Heap memory. So for now, I'm back to 640x480 Mode 2 |
||||||
comma = tab works for me > print"fred",,"barney" fred barney > OPTION LIST WebMite MMBasic RP2350A Edition V6.02.00RC5 same as always Jim |
||||||
You're right about the comma outputting tabs. My bad. The default is 2. I'd like to decouple it from the tab key, though so I could have print zones wider than 8 characters. Maybe allowing a larger range for the tab key would be OK. |
||||||
| Page 7 of 8 |
||||||
 |
The Back Shed's forum code is written, and hosted, in Australia. |
