![]() |
Forum Index : Microcontroller and PC projects : PicoMiteVGA V5.07.07b19 - Major enhancement - 640x480 edit in colour
![]() ![]() ![]() ![]() |
|||||
Author | Message | ||||
homa![]() Guru ![]() Joined: 05/11/2021 Location: GermanyPosts: 451 |
small error: When entering e.g. >files the screen will be dark/black/blank for a short time until the output appears. (But not always!??) The same with e.g. >edit whereby this does not really disturb, since also another screen structure comes. |
||||
Mark Regular Member ![]() Joined: 26/11/2022 Location: United StatesPosts: 85 |
I’ve noticed the same thing (blanking) on one monitor, but not on another. Also, when playing a .wav file on the monitor that blanks, the screen goes black while the file plays. On the other monitor, the text wiggles slightly. It clears up when the file stops playing. |
||||
matherp Guru ![]() Joined: 11/12/2012 Location: United KingdomPosts: 10008 |
V5.07.07b21 PicoMiteVGAV5.07.07b21.zip Please let me know if this solves the audio and screen blanking issues Unfortunately this means I have had to put the SDcard routines back into RAM so we have lost 4k of program space - now 92K I could see the issues on one monitor and this change seems to have solved them - please let me know This release will delete options and the flash disk |
||||
Mixtel90![]() Guru ![]() Joined: 05/10/2019 Location: United KingdomPosts: 7471 |
That program space is shrinking.... :( Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
robert.rozee Guru ![]() Joined: 31/12/2012 Location: New ZealandPosts: 2396 |
as far as i am aware, individual program size is limited by the amount of RAM available to the editor in order to edit it. however, while the editor is running there are a number of routines present in RAM, that while needed by the interpreter, are not used by the editor. therefore, i wonder if there is some way to 'bump' routines declared as "__not_in_flash_func" out or RAM while the editor is running, then reload them upon exiting the editor so that they are again available to the interpreter. to this end, i've posted a question on the pico forums: https://forums.raspberrypi.com/viewtopic.php?t=347663 i'm picking it would probably be necessary for the set of 'bumped' routines to reside in RAM contiguous with the block of RAM the editor uses for its buffer, but how to achieve this is another question. cheers, rob :-) |
||||
Mixtel90![]() Guru ![]() Joined: 05/10/2019 Location: United KingdomPosts: 7471 |
I won't panic until it gets to 32k - that's the "old school" limit. :) Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
Amnesie Guru ![]() Joined: 30/06/2020 Location: GermanyPosts: 523 |
I could live with less program space too. But that's just me :) -Daniel |
||||
Volhout Guru ![]() Joined: 05/03/2018 Location: NetherlandsPosts: 4821 |
Classic basic uses 32 bit variables , so 32k is a lot. Mmbasic uses a lot more per variabele. I feel, Cannot prove it, picomite Needs this ram. Logic analyzer uses 60k already. It is not even a game with multiple levels. Please dont shrink any further, or remove funtionality. Volhout Edited 2023-02-19 22:57 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
thwill![]() Guru ![]() Joined: 16/09/2019 Location: United KingdomPosts: 4245 |
I forget, is this the variable/heap RAM we are taking about ? My recollection is that the program itself runs from flash and the interpreter/firmware is split between RAM and flash ... presumably with the RAM part being loaded from the flash when the Pico starts? Best wishes, Tom MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
robert.rozee Guru ![]() Joined: 31/12/2012 Location: New ZealandPosts: 2396 |
of course, i'm forgetting there is FLASH CHAIN n, so one can just spread a large program over multiple flash slots. there are 5(?) slots, each 92k, giving a total program size of 460k when all chained together. speaking of which, perhaps it is time to drop the concept of flash slots completely. instead have .BAS and .BIN files in the onboard file system, where .BAS is a BASIC human-readable text file, and .BIN is a tokenized BASIC program (each .BIN files would need to exist as a single contiguous block). the editor could load either type, and save either type, but CHAIN could only call a .BIN file. the only 'complexity' would be that you would need to load a .BAS file into the editor, then save it as a .BIN file before it could be run or chained. and there would need to be a bit of shuffling around to ensure that .BIN files written by the editor were always contiguous. oh, and RUN and CHAIN would now always require a string parameter. a positive outcome would that the FLASH... group of commands would become completely redundant. and OPTION AUTORUN could be depreciated in favour of simply always running any AUTOEXEC.BIN file that exists on the onboard file system. cheers, rob :-) Edited 2023-02-19 23:20 by robert.rozee |
||||
matherp Guru ![]() Joined: 11/12/2012 Location: United KingdomPosts: 10008 |
Rob I'm sure its great you are taking an interest but your freeing up random bits of non-contiguous memory is of no use. There are other ways of increasing program space but as Volhout says it is variable RAM memory that is more precious so not a priority |
||||
robert.rozee Guru ![]() Joined: 31/12/2012 Location: New ZealandPosts: 2396 |
quite true, contiguous memory is the requirement. however, using FLASH CHAIN n largely mitigates the program size complaint, as a BASIC program can span 400k or more without issue. with a fixed number of routines that the INTERPRETER needs to reside in RAM, there is no simple solution to lack of BASIC variable space. well, you could allocate the TILE memory from the interpreter's pool only when required, but that is just another 12k(?), minus the code required to manage it. switching from flash slots to instead having .bas/.bin files is unrelated to freeing up RAM, but may be a pleasant simplification for picomite users. as i recall, the idea of using fixed flash slots was only necessary because at the time there was no path to having a file system in the onboard flash. that has now changed. cheers, rob :-) Edited 2023-02-20 00:02 by robert.rozee |
||||
homa![]() Guru ![]() Joined: 05/11/2021 Location: GermanyPosts: 451 |
YES the problem is solved for me. Works perfectly now, good job. ![]() |
||||
Mark Regular Member ![]() Joined: 26/11/2022 Location: United StatesPosts: 85 |
The blanking is solved when loading a file or entering edit mode, but it still blanks while playing a .WAV file from SD card. The screen does not blank when playing a .wav file from flash. The audio sounds fine while playing regardless of SD or flash. Mark |
||||
dgrissom Newbie ![]() Joined: 19/05/2022 Location: United StatesPosts: 3 |
Note certain if this has been reported? On my system using "b21" the editor is not properly showing marked blocks for Cut/Paste, etc. ![]() |
||||
matherp Guru ![]() Joined: 11/12/2012 Location: United KingdomPosts: 10008 |
Fix one problem and create another ![]() PicoMiteVGAV5.07.07b21.zip No version change - just a 1 line fix |
||||
JohnS Guru ![]() Joined: 18/11/2011 Location: United KingdomPosts: 3989 |
I'm finding the colour doesn't work properly in CLS rgb(...) e.g. MODE 1 CLS RGB(red) Pause 1000 CLS RGB(green) Pause 1000 CLS RGB(blue) Pause 1000 I think I'm getting WHITE in each case. CLS RGB(black) works. option list is just OPTION KEYBOARD US Makes no difference having OPTION CPUSPEED 252000 Tried with b20 & b21. Using PRINT @ or TEXT with colours (and obeying TILE sizes) seems fine - I do get coloured text. John Edited 2023-02-20 20:29 by JohnS |
||||
Volhout Guru ![]() Joined: 05/03/2018 Location: NetherlandsPosts: 4821 |
@Peter, Feature request: when "colourcode ON" and in "mode 1", please automatically select "tile small". Bug report: V50707b21 running picochess3 program (attached). This works fine on V50707b18. [109] For j=0 To offsets(piece(i))-1 Error : Stack overflow, expression too complex at depth 9 I monitor C-stack, and it was not 0, but that is based on earlier provided thresholds (you posted). Maybe this is (in the end) a stack error with current memory map. If you run picochess3, put it in the same folder as the sprite file Small_Col.bmp. Picochess will play against itself, so nothing needed. Just press F2 (run). picochess3.zip I hope this one is simple to fix... Volhout Edited 2023-02-20 20:57 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
matherp Guru ![]() Joined: 11/12/2012 Location: United KingdomPosts: 10008 |
This is correct. To get colour you need to use the TILE command. CLS is the equivalent of BOX 0,0,mm.hres,mm.vres,0,0,rgb(red) and any colour in mono mode is white. They both use the DRAWRECTANGLE primitive. I played with interpreting the coordinates in DRAWRECTANGLE to see if the matched tile boundaries and then setting the tile colours accordingly but it has far too many unforeseen consequences that would completely bemuse the user to be a realistic option |
||||
Volhout Guru ![]() Joined: 05/03/2018 Location: NetherlandsPosts: 4821 |
@Peter, I have one more program that refuses to work with the new memory map. Not enough memory to load sprites. This change (b21) is really killing existing programs. Many of the larger programs will need a complete rewrite and memory optimize. I know I asked for color in mode 1 in the editor, regret it now I see the result. Regards, Volhout PicomiteVGA PETSCII ROBOTS |
||||
![]() ![]() ![]() ![]() |
![]() |
![]() |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |