 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/PicoMiteVGA V5.07.05 release candidates
  Page 4 of 9   |
|||||
| Author | Message | ||||
| Bleep Guru  Joined: 09/01/2022 Location: United KingdomPosts: 411 |
Sorry Volhout, :-( This one has the bmp file. The image is very rough, I literally resized it, so the pieces don't look very good, this was another 'to do' if anyone gets it running. Re. your previous post, presumably getting the computer to play both sides will significantly increase memory usage, as I was only seeing just above 50% used? Regards Kevin. TSCPChess.zip Edited 2022-10-01 22:53 by Bleep |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 3845 |
r.e. Chess on the Picomite, assuming its memory allocation works in a similar way to MMBasic for DOS (and thus MMB4L which is what I am familiar with) and assuming I am not talking out of my arse then statistics reported by the MEMORY command are irrelevant. MMBasic has a fixed number of variables slots plus a fixed sized heap (from which the additional memory for strings, arrays and some internal scratch buffers are allocated), if these were being exhausted I would expect an MMBasic error message. What instead I think is happening is that you have too many nested MMBasic SUB/FUNCTION calls. The interpreter implements this by recursion allocating more and more C variables on the Pico stack until it overflows (apparently into the area of RAM that the PicoMite sets aside for program storage). This would be difficult for the firmware to protect against and if possible at all would come with a significant performance penalty. Assuming the correctness of the above then in order to "fix" this you have to reduce the maximum depth of recursion in the program: reduce the depth of its searches, inline functions, use iterative rather than recursive algorithms or move the recursive algorithms into CSUBs where you have explicit control over stack allocation rather than the MMBasic interpreter. Best wishes, Tom Edited 2022-10-02 00:17 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 3532 |
Tom, Do you think it is possible to re-compile the code with a memory map that allows for a larger C stack ? Or is this something the compiler decides on his own ? What is the difference between CMM2 C stack and pico C stack in size ? Regards, Volhout PicomiteVGA PETSCII ROBOTS |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 3845 |
Hi Volhout, I'm pretty sure that is possible, I recall reading that the default can be overridden using a compiler flag for the standard Pico SDK tool-chain. However the additional stack has to come from somewhere and Peter has indicated it would be from the MMBasic heap, that is the memory allocated to MMBasic string and array variables. Note that I would not be in favour of multiple public forks of the Picomite firmware, that way lies madness, c.f. the ESP-01 (at least to my understanding.) When I have the answers to questions like that at my finger-tips I will remove the "NOT A GURU" from my avatar  . You'll need to check the relevant SDK documentation, I wouldn't be suprised if the CMM2 has a stack at least 4x the size of the Picomite; it has so much more RAM to play with.Best wishes, Tom Edited 2022-10-02 23:56 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8583 |
V5.07.05RC5 https://geoffg.net/Downloads/picomite/PicoMite_Beta.zip MM.INFO(HEAP) Returns the amount of MMbasic Heap memory free. MMBasic heap is used for strings, arrays and various other temporary and permanent buffers (e.g. audio) MM.INFO(STACK) Returns the C stack pointer. Complex or recursive Basic code may result in the error "Stack overflow, expression too complex at depth %" This will occur when the stack is below &H 2003f800. Monitoring the stack will allow the programmer to identify simplifications to the Basic code to avoid the error. Various small tuning changes |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 3845 |
Minor bug (IMO), the result of MM.INFO(CPUSPEED) appears to be a string rather than an integer: > ? Mm.Info(CpuSpeed) 252000000 > ? Mm.Info(CpuSpeed) + 1 Error : Incompatible types in expression > ? Val(Mm.Info(CpuSpeed)) + 1 252000001 Best wishes, Tom Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
phil99 Guru Joined: 11/02/2018 Location: AustraliaPosts: 1785 |
" MM.INFO(CPUSPEED) appears to be a string" It is also MM.INFO$() so I had assumed everything produced by MM.INFO() was a string and use Val() to get the number. Edit Manual MM.INFO() MM.INFO$() These two versions can be used interchangeably but good programming practice would require that you use the one corresponding to the returned datatype. MMM.INFO$(CPUSPEED) Returns the CPU speed as a string. Edited 2022-10-03 09:15 by phil99 |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 3532 |
Hi Peter, This is really usefull !!! Implemented it in the chess program to see where things go wrong... Any guide for the heap limits ? It currently gives 6700 (hex). Volhout PicomiteVGA PETSCII ROBOTS |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8583 |
It will give an error message if full. Try Print factorial(100) Function factorial(n%) Local a%(1500) Print n%,Hex$(MM.Info(stack)),MM.Info(heap) If n%=1 Then factorial=1 Else factorial=factorial(n%-1) EndIf End Function |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 3845 |
Hi Phil, As you quote MM.INFO() and MM.INFO$() are interchangeable, and on the PicoMite if you edit a program and use MM.INFO$() and then reopen the same program in the editor you will see it has changed to MM.INFO() without the $. You don't see the same on the CMM2 because the CMM2 editor edits files whilst the PicoMite editor is looking at the program in flash and MM.INFO() and in flash MM.INFO$() use the same token. However the actual type returned by the MMBasic interpreter is independent of the use of $ and is specific to the name of the "thing" requested, e.g. MM.INFO$(DISK SIZE) does not report an error and returns an Integer despite the $. OK, so I rephrase my question: "Why was it decided that the CPU speed should be returned as a string?" Except for diagnostic purposes the only logical uses of this information would require an integer - i.e. changing behaviour or reporting an error if the CPUSPEED isn't greater/less than some specific value. Best wishes, Tom Edited 2022-10-03 23:06 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8583 |
Because that is the bit of code I cut and pasted and as it has always been that way it doesn't make sense to change now as it is consistent with the manual Edited 2022-10-03 23:25 by matherp |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 3845 |
I'm biting my tongue but I nevertheless appreciate you taking the time to respond .EDIT: Did it historically return something like "FAST" or "SLOW" ? Best wishes, Tom Edited 2022-10-03 23:39 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8583 |
V5.07.05RC6 https://geoffg.net/Downloads/picomite/PicoMite_Beta.zip PicoMite Fixed bug in LOAD IMAGE for mono displays (e.g. SSD1306I2C32) Enabled BLIT and LOAD JPG for mono displays BLIT LOAD: now also accept BLIT LOADBMP for compatibility with VGA version PicoMiteVGA Improved LOAD JPG for MODE 1 (mono). There is now a cut-off at &H40 for each of the RGB levels to determine if a pixel is black or white (i.e if any of RGB are >&H40 then the pixel is white) Edited 2022-10-04 19:59 by matherp |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 3532 |
Hi Peter, It is advised to use OPTION DEFAULT NONE OPTION EXPLICIT in programs. But when I do that and stop the program with control-C, or when the program finishes, picomite uses the OPTION settings inside the program also on the commandline. I cannot a=2 I first have to DIM a DIM a: a=2 Is that desired behaviour? The manual says the OPTION DEFAULT and OPTION EXLICIT are tied to the program, and are actually cleared at every new run. PicomiteVGA PETSCII ROBOTS |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8583 |
Same as every version of MMBasic. |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 3845 |
@Volhout, note that "in theory" you are supposed to be able to CONTINUE a BASIC program after Ctrl-C, END or ERROR - see the manual - so when you get dumped to the command-line the state of the interpreter remains as it was in the program until NEW ... at least in theory. In practice Peter/MMBasic has to disable any installed software interrupts, stop PLAY commands (on my request) and perform various other cleanups to keep the command-line usable and these mean that programs making using of these features are not really CONTINUEable and the command is now rather a historical anachronism. YMMV, Tom Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 3532 |
Thank you for the response Tom and Peter, My question was if these options should be cleared at stop, or cleared at restart. It took me far more text, so the question was not as clear as in the line above. And that question is answered... PicomiteVGA PETSCII ROBOTS |
||||
| KenH Newbie  Joined: 06/02/2022 Location: United KingdomPosts: 13 |
Hello Peter I have been trying out PicoMiteV5.07.05RC6. I have had to amend one of my programs due to the removal of the "OC" setpin option. I understand the reason for this change as described in previous posts. However, is it possible to allow the output state of pins to be set before the setpin(x),DOUT command. The following code causes a brief unwanted 0V pulse to be sent. ' Initialise OC output setpin (24),DOUT pin (24) = 0 ' Causes unwanted 0V pulse setpin (24),DIN What I ideally want to do is: ' Initialise OC output pin (24) = 0 setpin (24),DIN .. .. ' Main program setpin (24),DOUT ' Pin only goes low when required Just looked at the manual, it says "You can set an output high or low before it is configured as an output and that setting will be the default output when the SETPIN command takes effect." - which is exactly what I want to do! I can report that the Advanced graphics control handling is much improved over the previous PicoMiteV5.07.05b18 release, but there are still occasional blips. 'Spinner' arrows occasionally stay in the pressed position and the spinner locks and occasionally pressing a 'button' causes a beep but does not cause an interrupt. As I said, these issues are less problematic than previously. MM.INFO$(RESET) is not working. > > print mm.info$(reset) Error : Syntax > Best wishes Ken Edited 2022-10-07 03:03 by KenH |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8583 |
You can Cut and paste from CMM2 manual - now removed - does not exist on PicoMite |
||||
| KenH Newbie Joined: 06/02/2022 Location: United KingdomPosts: 13 |
Sorry, my fault! Trying to set the pin to 0 after setpin(x),DIN rather than before. Now working fine. Thanks again Ken |
||||
| Page 4 of 9 |
|||||
 Print this page |
