 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.00.03
  Page 8 of 9   |
|||||
| Author | Message | ||||
Mixtel90 Guru  Joined: 05/10/2019 Location: United KingdomPosts: 7939 |
Ah, I see now. They are RAM disks with a slightly different name and have to be de-initialised or they'll get walked on during a RESET. :) As I don't currently have anything with PSRAM to experiment with I'm a bit stuck with further investigation. My PGA2350 doesn't appear to be working now. :( . Edited 2025-07-21 19:17 by Mixtel90 Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| dddns Guru Joined: 20/09/2024 Location: GermanyPosts: 544 |
2350HDMIUSB: With resolution 640 and switching to MODE3 and FRAMEBUFFER CREATE, edit file file$ causes an heap error. Without PSRAM it takes a while and leaves a 240Kb .vars on a: With PSRAM the error occurs immediately. With RESOLUTION 1280 it errors with/without PSRAM in MODE 1 with FRAMEBUFFER CREATE With RESOLUTION 848 or 800 it works fine with PSRAM enabled. With another program I've tested I don't use EDIT FILE but an heap error occurs, when I define about 100 variables and then call a subroutine. It directly errors in the subroutine calling line. Now I've tested really _all_ HDMI modes and it only occurs with RESOLUTION 640 in MODE 3 and 4 I found the same for 2350VGA Edited 2025-07-21 19:56 by dddns |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10316 |
Creating a framebuffer in 640x480 mode 3 uses 150K of heap out of 184K so you are running out when you try and do other things requiring heap |
||||
| dddns Guru Joined: 20/09/2024 Location: GermanyPosts: 544 |
PSRAM won't help and of cause this has run on previous versions, at least with PSRAM. Another hint might be, that loading a big sized program might lead to a heap error. I thought PSRAM would help, but it errors the same way. please see here Edited 2025-07-21 20:25 by dddns |
||||
| dddns Guru Joined: 20/09/2024 Location: GermanyPosts: 544 |
I've debugged with MEMORY and see, that free memory reported is still (based on) 232k after changing to MODE 3 and having variables defined before. |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10316 |
correct but only 184K of that is heap and creating a framebuffer uses 150K of it. This disappears when you are back at the command prompt after an error |
||||
| dddns Guru Joined: 20/09/2024 Location: GermanyPosts: 544 |
To make it clear: it runs in 848 or 800 and and all other but not in 640 resolution |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10316 |
Options? Version? program? |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7939 |
*weld* *weld* *weld* I now have a very basic PGA2350 board apparently working! The module wasn't dead. :) Well, it's fired up over the console anyway. PSRAM is recognised on GP0. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7939 |
Minor manual copy/past error: Page 149 RAM FILE LOAD n If I use RAM LIST n at the command line the system hangs and a reset is needed. No program is loaded into the slot so that is the problem. If I load it with "'this is a test program" then it lists correctly. Can I suggest implementing something like MM.INFO(EXISTS RAM n) as a means of detecting whether a RAM slot has a program loaded? I'm confused. After a power up RAM SAVE 1 gives a "Error: Already programmed", but it's a cold start. I've not even got any capacitors added to this board so the supply has gone. I have to save the current program using RAM OVERWRITE 1, which works fine. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10316 |
After power up the contents of the PSRAM are indeterminate - they are not zero. You need to use RAM ERASE to clear one or more slots before attempting the list one or save to one. As I said above, this is deliberate so that slots survive a reset. |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 7939 |
Ah, thanks, that makes sense. Could something like a recommendation to use RAM ERASE ALL after first powering up (if the RAM slots are to be used) be added to the manual please? It might help other confused people. :) Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3292 |
Will do. Geoff Graham - http://geoffg.net |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2944 |
Terminal bug: Using the latest available ‘PicoMite RP2040 v6.00.03’ on a genuine RPi 2040 Pico. Accessing it via USB in TeraTerm. TeraTerm terminal set to 80x30. OPTION DISPLAY 30,80 is set. All works as expected until I enter the EDITor. TeraTerm then switches to 81x30. This then leads to the issue I am seeing. If I edit the program code in any way, and then press ESC, the whole screen jumps one character to the left (I.e, I effectively loose the first column from the screen -but it is not lost forever from the code). If I acknowledge the ‘Exit and discard all changes (Y/N):’ with N, then the screen redraws correctly (ie the first column reappears). I believe the two issues above are linked. Not tried on any other versions. I have three other OPTIONs also set, possibly the first one ‘interfering’: SERIAL CONSOLE COM1, GP0,GP1,BOTH COLOURCODE ON CPUSPEED 150000 Be interested if anyone else can replicate this…. |
||||
| EDNEDN Senior Member  Joined: 18/02/2023 Location: United StatesPosts: 155 |
@WhiteWizzard I have a simple alternative to what you are doing and seeing. Go into the editor with a large program that fills up much of the screen and is several pages long. Ideally, use TeraTerm because that allows faster keyboard key pressed repeats. If you hold down the various arrow keys to move around fast, I'm seeing lock ups. It takes a while, but after 30 or 45 seconds of moving around fast things often times lock up. |
||||
disco4now Guru Joined: 18/12/2014 Location: AustraliaPosts: 1003 |
@WhiteWizzard It appears only to happen if the Term size=Win size option in Teraterm is not checked. I only unchecked this trying to replicate the issue so normally checked for me. Unchecked.  Checked.  Edited 2025-07-22 11:20 by disco4now Latest F4 Latest H7 FotS |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2944 |
Useful feedback (especially that info from disco4now). Will try later when back home to see if it ‘fixes’ things for now. Only thing is I am looking to replace TeraTerm with a dedicated ‘Termite’, but am using TT as a reference. Thanks again! |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10316 |
MMbasic always tells the terminal to be 1 character wider than the setting of OPTION DISPLAY. It does this so that auto linewrap in the terminal can't cause problems. Every version of MMbasic I've done does this. |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2442 |
strictly speaking, instead of setting 81 columns, you should be sending the escape sequence to turn OFF the DECAWM setting when you enter the editor: DECAWM – Autowrap Mode (DEC Private) This is a private parameter applicable to set mode (SM) and reset mode (RM) control sequences. The reset state causes any displayable characters received when the cursor is at the right margin to replace any previous characters there. The set state causes these characters to advance to the start of the next line, doing a scroll up if required and permitted. (from: https://vt100.net/docs/vt100-ug/chapter3.html) ... then turn it back ON when returning to the command prompt. the default setting is ON. it is possible that TeraTerm has, in recent releases, started honoring this setting; as i recall, in the past TeraTerm allowed 'virtual parking' of the cursor briefly to the right of the rightmost screen column provided an escape sequence (or control code) to move the cursor elsewhere is the next thing received. GFXterm handles this scenario in a similar way - the cursor's X location is set to 81, but the cursor is left sitting in column 80. only when the next printable character arrives is the cursor (if needsbe) moved to the start of the next line and the scrollable area of the screen scrolled up. the end result is you can print on the bottom right of the screen without triggering a scroll, but autowrap and autoscroll still work correctly - albeit their action fractionally delayed. this is why GFXterm should not require setting the screen width to n+1. cheers, rob :-) addendum: according to https://vt100.net/docs/vt510-rm/DECAWM.html it looks like the default for DECAWM is OFF. but this does not match my past experience, will need to think a little more about this. does anyone out there have a real hardware VT102 to test this against? see also: https://github.com/mattiase/wraptest for a summary of background and some of the ongoing issues. Edited 2025-07-23 01:20 by robert.rozee |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2944 |
Fully appreciate your explanation but I am confused by what I am seeing. With OPTION set to 80x30, and TeraTerm (TT) set to same, then TT will be 80x30 when at the command prompt, and when program-code is running, and when initially entering the Editor. If I use the cursor keys to move TT’s cursor up/down/left/right then the screen is ‘drawn’ correctly and TT remains at 80x30. If I use F3,F4,F5 the screen remains correctly drawn (and TT at 80x30). If I edit code it remains all good. ONLY when I press ESCape, AND having made at least one change to the program code (ie making the prompt appear at the bottom of the screen to effectively ask if you want to save the changes), does TT change to 81x30 and ‘shift’ the whole screen one space to the left. Surely there is a small issue with the screen rendering when the prompt appears otherwise would it not always be an issue with rendering in the editor? So, while I understand the quote above, it raises a question as to why it only does it for the ‘confirm prompt’. Note too that pressing N (ie to continue editing), the screen is once again drawn correctly (ie, it effectively jumps back one column to the right (and the first column reappears). Hope this makes sense - and that maybe somewhere in the code it may be drawing the above screen starting incorrectly in column 0 as opposed to column 1. |
||||
| Page 8 of 9 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
