 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 : PicoMite Firmware Release Version 6.01.00
  Page 5 of 6   |
|||||
| Author | Message | ||||
| Volhout Guru  Joined: 05/03/2018 Location: NetherlandsPosts: 5648 |
Peter, Is 6.01.00 tagged on github, so I could fork it and build it myself, and make the bug fixes? Not that I have the capabilities, but I might find someone who does. I do have a strong desire to get the 2040 release fixed, since I plan to stick with it. And now, I can ask you what the fixes are for the RX interrupt, and the other bug. But 4 weeks from now you won’t remember (no Blaim). Volhout PicomiteVGA PETSCII ROBOTS |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10923 |
A typo and a missing line of code - trivial stuff |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 5648 |
Peter, What would you ask for fixing these 2 issues in 6.01.00 ? 100 gbp per hour? I would pay a reasonable around to get it fixed. I do understand this is against your principle. But I do want to close the 2040 chapter for myself, and would be willing to donate to get it final. And it would buy you some memory modules for you new pc. Volhout Edited 2026-01-05 05:32 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
| Amnesie Guru Joined: 30/06/2020 Location: GermanyPosts: 746 |
 ... and so do I (but more with the RP2350). I think we have more than enough to play with, now even STRUCTs  but a strong final version would be great, of course it isn't possible to find all bugs, but when introducing new features, something else is always broken (mp3 playback, PIO etc.) so I also would appreciate when the picoMite finally comes to an end.  Greetings Daniel |
||||
| Bleep Guru Joined: 09/01/2022 Location: United KingdomPosts: 723 |
@Amnesie I would not agree with that, I think the 2350 has plenty of legs left in it, or future updates to the Pico family. But I do think cramming everything on the 2350 onto the 2040 will reduced it's usefulness. Just my opinion. Regards Kevin. |
||||
| bfwolf Senior Member  Joined: 03/01/2025 Location: GermanyPosts: 153 |
I'm not sure if Peter made the Structs extension toggleable via "config macros"?  In my job, I really like doing that with software, even though my colleagues beat me for it because they don't like features that can be disabled with a #if statement. But I can resist the beats.  Besides, in projects using the Zephyr RTOS, for example, pretty much everything is configurable this way.And I get the impression that most of the bugs Peter has fixed recently weren't related to the Structs extension? Therefore, "purists" who want this and need a version without Structs could perhaps compile their own version 6.01.01 with all the fixes? |
||||
| toml_12953 Guru Joined: 13/02/2015 Location: United StatesPosts: 541 |
We're eagerly awaiting his source code so we can find out things like this. Of course we're only at 6.02.00RC0 so there may be many more RCs before general release. |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 5648 |
Hi toml_12953, Question is if there is a tag for 6.01.00 as released on Geoff's site. Main reason for me to stay with 6.01.00 for RP2040, is that I have a legacy with pico that becomes increasingly more difficult to keep working with every increment. I want to put a stick in the ground, do one final validation, and start working on finalizing these projects. Last 2 years I have spend more time on testing incremental releases, than I spend on writing new code. And I think it is time. 6.01.00 is stable enough, just fix the obvious bugs (things that do not work at all) and freeze it. What is wrong with 6.02.00rcxx ... nothing, except that the new functionality is eating flash, and with Peters pace with help of AI, it will become unusable soon for legacy platforms as Game*Mite where A: drive size is key. So 6.02.00 is not suited for my legacy projects anymore. I understand Peter want's to go on. And he should. With AI helping him the innovation pace increases dramatically. And he has a good team of people around him testing the new functionality with structures, methods, etc.... Volhout PicomiteVGA PETSCII ROBOTS |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 8486 |
Some of my stuff is still running 5.07.03 or thereabouts. It won't get upgraded because it works fine. It also has the advantage of having all the original flash slots. ;) I don't usually build a project and use a beta or RC version in it, no matter what the bells and whistles are. I usually wait until a new full release has been out for a week or two before I'll consider using it. After that it won't usually get updated because I'm happier designing new hardware than programming. :) Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10923 |
Volhout, I'll make you a deal. Upgrade to V6.02.00 and I will commit to keeping this stable for the RP2040 irrespective of any future developments for the RP2350. I'm not intending to make any further changes to V6.02.00RC0 unless bugs are found and Geoff is already working on the changes to the manual. I will never accept any sort of remuneration for the code I make available |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 8486 |
That sounds like an excellent offer to me. :) V6.02.00 is fixing some stuff that might be very important on the RP2040 as well as adding structs. I don't know about such things, but I suspect that adding structs hasn't impacted flash all that much as they seem to be a specialised form of arrays, for which the code already exists. Having them included on the RP2040 helps immensely with keeping programs compatible the RP2350. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4221 |
Does it come down to how much larger V6.02.00 is (or, will be) than V6.01.00 on the RP2040? John Edited 2026-01-05 22:54 by JohnS |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 5648 |
@Peter, Deal ! @John, I will look into it, but the EXP7 I tested used 32kbyte more than 6.01.00. This is after 6.01.00rcxx had taken 16kbyte, and Peter gained me 48kbyte. So EXP7 should be able to run Game*Mite (32+16-48=0). But I have not tested yet, since I have in total some 45 picomite projects that need testing on several platforms. I.e. Petscii Robots, Rocks, PicoFrog, Logic Analyzer, Thermal Camera, Frequency Counter, Capacitance meter, etc..etc.. Volhout PicomiteVGA PETSCII ROBOTS |
||||
karlelch Guru Joined: 30/10/2014 Location: GermanyPosts: 314 |
Hi, this is probably a stupid idea, still I am thinking about this for some time. One cool aspect of MMBasic is that there are so many features already built in. Seeing how productive Peter is, I expect this to be continuing. However, this also means that the firmware will probably grow. A solution here may be to adapt some system of libraries - not MMBasic libraries, but real chunks of compiled code that can be imported when needed. Candidates for this may be the recent astronomy functions or the turtle graphics. Currently, the different firmware versions reflect this kind of system, depending on the firmware, there is different functionality beyond a common core. Yet, maintaining more different firmware versions is challenging, as one could have seen from the ramifications recent new functionality additions had across firmware versions and the debugging and testing that was needed. I have little idea how complicated such a library system would be, but maybe it's worth discussing? Best Thomas |
||||
| bfwolf Senior Member Joined: 03/01/2025 Location: GermanyPosts: 153 |
I've also considered something like "DLLs." But that wouldn't help with such "fundamental" things as structs, since they need to be "deeply embedded in the interpreter core." It would be a viable approach for supporting additional peripherals or libraries for processing JSON files or mathematical functions, etc. The question is how to make such "DLLs" accessible from the BASIC side and where to store them so that their code is executable but they require as little RAM as possible. Perhaps stored linearly in a "flash partition"? For connecting to BASIC, the Amiga had a simple and interesting concept in AmigaBasic (otherwise one of the worst programs ever on the Amiga, full of bugs—written by Microsoft,  of course). There were '.fd' ASCII files that listed the function names and offsets of the procedures and functions in the DLL jump table, as well as all function parameters and their types.The function was declared as follows: DECLARE FUNCTION Name [(ParameterList)] LIBRARY The contents of the ParameterList are only for formality and declarative purposes—the actual information is retrieved from the '.fd' ASCII file. Example-FD-file: "dos_lib.fd" dos_lib.fd.zip Notes: The offset in the jump table is determined by the line order. The beginning can be specified with a line '##bias nn'. This allows you to skip sections and specify a new offset for the following lines with one or more '##bias nn'. All offsets are relative to the base address, which is specified with '##base _DOSBase' (for example). A line for a function might look like this: Open(name,accessMode)(d1/d2) The values in the second set of parentheses are the registers where the parameters must be passed, since on AmigaOS all parameters to DLLs are passed to M68K registers. The return value is always in D0, as far as I remember. Long ago.. Then you had to specify which DLL was needed: LIBRARY "filename" And when no DLL was needed (closing all DLLs): LIBRARY CLOSE But I think that's all in the future... Edited 2026-01-06 06:12 by bfwolf |
||||
phil99 Guru Joined: 11/02/2018 Location: AustraliaPosts: 2963 |
As this firmware is now frozen this is just for information. OPTION LCDPANEL VIRTUAL_C appears to have a bug on the basic RP2040. Note its OPTION LIST entry. GP16 & 18 can still be used as normal. CLS RGB(any colour) results in a black background. Saving a large box image uses too much memory. > option list PicoMite MMBasic RP2040 V6.01.00 OPTION FLASH SIZE 16777216 OPTION COLOURCODE ON OPTION CPUSPEED (KHz) 378000 OPTION DISPLAY 52, 150 OPTION LCDPANEL VIRTUAL_C,GP16,GP18 OPTION AUDIO GP18,GP19', ON PWM CHANNEL 1 > cls rgb(green) '<---results in a black background when saved > box 0,0,320,240,1,rgb(green),rgb(green) > box 99,99,111,111,33,rgb(red),rgb(blue) > save image "Virtual_C test.bmp" Error : Not enough Heap memory Error : Not enough Heap memory Error : Not enough Heap memory Error : Not enough Heap memory Error : Not enough Heap memory Error : Not enough Heap memory Error : Not enough Heap memory Error : Not enough Heap memory Error : Not enough Heap memory Error : Not enough Heap memory Error : Not enough Heap memory Error : Not enough Heap memory Error : Not enough Heap memory Error : Not enough Heap memory Error : Not enough Heap memory Error : Not enough Heap memory Error : Not enough Heap memory > |
||||
| karlelch Guru Joined: 30/10/2014 Location: GermanyPosts: 314 |
Yes, the core functionality should be included - I was mainly thinking of features that could be nicely wrapped into a package (e.g. Astronomy). But I agree, the technical implementation would probably be difficult - also, one could argue that the result would deviate from Basic even more. I enjoy that with MMBasic, there is only the firmware to choose and one does not have to think where to get additional packages from (as w/ MicroPython), and having to choose between different flavours (e.g. CircuitPython, Pimoroni Python, MicroPython, all w/ not necessarily interchangeable libraries). And MMBasic is powerful enough to write hardware drivers in Basic (see here for an example). Anyway, I wanted to bring up the idea, knowing that it'll likely remain an idea ;-) Best Thomas |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10923 |
phil99 I've just repeated with V6.02.00RC0 and it all seems to work fine, including cls rgb(green) and save giving a green image. Please could you retest and confirm on that version - thanks  Edited 2026-01-06 18:41 by matherp |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 8486 |
No no no!!!! Do NOT even consider the likes of DLLs unless you personally are writing everything from scratch! Have you learned nothing from Microsoft? ;) Are you willing to support them all through future changes to MMBasic? Microsoft failed spectacularly. :) There is no underlying OS for a start and no safe, guaranteed storage area for DLLs to occupy. The RP2350 isn't exactly short of flash area for MMBasic to expand into. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| bfwolf Senior Member Joined: 03/01/2025 Location: GermanyPosts: 153 |
The principle behind DLLs isn't bad in itself, even if their implementation on Windows wasn't exactly brilliant. Other operating systems have had them for a long time and implemented them much better (Unix/Linux/AmigaOS). And the fact that DLL functions can be accessed from BASIC isn't really unusual. I just did a Google search: VBA actually still has a "fairly similar" syntax for 'Declare' as it did back in AmigaBasic. The fact that AmigaBasic was so bad back then had less to do with its interpreter core or even the AmigaOS DLL concept. AmigaBasic simply crashed very quickly if, for example, you pressed the wrong key in certain places in the editor. Furthermore, apparently quite a few things weren't programmed in a system-compatible way, so it didn't work on newer AmigaOS versions or only worked with patches. And it was incredibly slow! In principle, one could "think about" something like this for future versions... After all, this would allow the "basic version" of MMBasic to remain relatively compact, while still making its functionality extensible for specific applications. |
||||
| Page 5 of 6 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2026 |
