 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 RP2040: V6.00.00 betas
  Page 3 of 4   |
|||||
| Author | Message | ||||
stanleyella Guru  Joined: 25/06/2022 Location: United KingdomPosts: 2112 |
rocks 13 on pico2 hdmi mode 1 flickers bad. mode 2 ok mode 3 [105] Play modfile "b:\sfx-bg.mod" '"RISsound.mod" Error : Not enough memory mode 4 [105] Play modfile "b:\sfx-bg.mod" '"RISsound.mod" Error : Not enough memory mode 5 ok |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9100 |
This fixes the mode 2 issue (forgot a parameter when I compiled). Still don't see an issue with flashing on the logic analyser code PicoMiteV6.00.00b6.zip Wrong thread - this is for the RP2040. However the error is correct - mode 3 uses a lot of memory and you can't have a framebuffer and mod file playback Edited 2024-09-18 07:01 by matherp |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4222 |
Closing in on the issues - MODE2 works again - rocks works (atm cannot test 315MHz CPU since this monitor won't sync at 75Hz). - Screen flicker: see attached zip. In both clips you can see some flicker (camera/monitor aliasing), but the 50900 does not show the "build up from top to bottom" of the signals. The beta 6 you see this. And this is weird, becausee the writing of these signals happens in between two "framebuffer copy f,n" commands. clips Just for clarity: this is the zip I last shared, called LA_24_1.bas. Not LA-24.bas. In LA_24_1 the screen write routine is faster because it clears the whole signal window, and then writes the signals. The older LA_24 is slower in that it erases section for section, just before writing. And LA_24 does not use framebuffer. EDIT: or is it simply that the framebuffer copy in beta 6 is much slower ? Volhout Edited 2024-09-18 17:10 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4222 |
@Pete, In Beta 6, when choosing 315MHz, the VGA output is 150Hz (not 75Hz) measured at the VSYNC signal. Volhout PicomiteVGA PETSCII ROBOTS |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9100 |
Harm OK, I've found the problem but not the cause. Something is resetting the FRAMEBUFFER WRITE address mm.info(writebuff) returns the address of where MMbasic is writing. If you print this before and after the FRAMEBUFFER WRITE F you will see it change. But somewhere in the loop is reverts back. Now I just need to find out what is doing it. If you have time you could help by putting in prints of mm.info(writebuff) to see where it changes Edited 2024-09-18 18:04 by matherp |
||||
Martin H. Guru Joined: 04/06/2022 Location: GermanyPosts: 1113 |
Quick test, some Issues with 6.00.00b6 Picomite VGA (252 Mhz) With some programs the screen freeses after pressing ctrl/C and remains dark when you want to switch back from mode 2 to 1. Sometimes when playing MOD files, the Pico is no longer accessible (it plays the mod but no longer responds) I can't tell exactly when this happens, as it only occurs sporadically. Edited 2024-09-18 18:06 by Martin H. 'no comment |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9100 |
Harm I've found the problem. In your code you create the framebuffer and then set to write to it. Sometime later in set_screen you call MODE 1 In the new release changing mode resets the framebuffers and layer buffers because the contents are meaningless after a mode change. If you remove the framebuffer create and framebuffer write from the top of the program and include them in set_screen after the call to MODE then everything will work as before. This is not a change I intend to undo as it should have been in previously. I could special case where the MODE command is to the same as before but this could hide bugs where the program was run from a different mode. Martin Could this also be the cause of your issue? |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4222 |
Thanks, What you say makes sense. I will make the changes you propose. What about 150Hz VGA at 315MHz ? Volhout PicomiteVGA PETSCII ROBOTS |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9100 |
That's fixed PicoMiteV6.00.00b6.zip Edited 2024-09-18 20:35 by matherp |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4222 |
Hi Peter, So far I think all is dandy on the 2040 VGA version. Tomorrow night I will run some more programs, but the ones that caused problems now all run. In the OPTION RESET VGA DESIGN 2 you could add CPUSPEED 252000. Since I understand all platforms run this speed, and typically VGA needs it anyway. Thanks for the effort making everything work again. I am going through my archives, and look at the games that use map() or map$() arrays. Most can be corrected by a global replace, so they run on 6.0.0. Regards, Volhout P.S. I have not checked programs that use frambuffers in combination with LCD. That could be another issue, especially if coded by me. (first asign framebuffer, then change mode...stupid.). Edited 2024-09-18 22:09 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
| Martin H. Guru Joined: 04/06/2022 Location: GermanyPosts: 1113 |
Hi Peter,, Just installed the version from your latest upload: For example, when I press ctrl & C in Petsciirobots. The screen stays on N, but no cursor appears. From the terminal I can continue working so that cls and for example "box 10,10,10,10,255,255" work. Only the text output is not displayed on the VGA screen. Print, list, edit etc does not work, but text 200,200,"12345" does strange  Cheers Martin Edited 2024-09-19 00:30 by Martin H. 'no comment |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9100 |
After ctrl-c please type "framebuffer close" does that normalise things? This is one of those no-win ones. If I close framebuffers after a crtl-c you lose context for any debugging. If I leave them you get strange effects like you describe |
||||
| Martin H. Guru Joined: 04/06/2022 Location: GermanyPosts: 1113 |
Hi Peter, I tested this, "framebuffer close" or even Mode change does sadly not normalise thing. thank you for your efforts Cheers Martin 'no comment |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4036 |
Peter, Just a comment from "the cheap seats", but for diagnostic purposes MMB4L v0.7 will have a GRAPHICS LIST command that will list every extant graphics surface (window/page/frame/blit/buffer/sprite), it's type, size (and ultimately probably other properties) and an indicator as to which one is the current write destination. Perhaps the PicoMite would benefit from something similar ? Best wishes, Tom Edited 2024-09-19 02:02 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| Malibu Senior Member  Joined: 07/07/2018 Location: AustraliaPosts: 228 |
Peter, I think there's one more niggling problem with the WebMite and Watchdogs... It's been pretty stable, but occasionaly I've had some random resets - so I had another play with your code to see what I could learn. IF I hit reload/stop/reload/stop, etc etc reasonably fast in the browser, effectively I create multiple HTML requests for the webmite, but before it can answer, the client disappears, so there's no client to send a web page to (As I suspect is what's happening with some of the 'bot' traffic I've seen) Eventually, I get a "No free connections" error because all the connection slots are used, and soon enough the watchdog fires. So, I changed some of the MMtcpServer.c code //if(pcb==MaxPcb)error("No free connections"); if(pcb==MaxPcb)printf("Warning: No free connections\r\n"); just to see what happens... The resulting error lines in MMCC The no connections error is still present, but it doesn't fire the watchdog and eventually recovers. Is it possible to have the WM ignore any new requests once the connection max has been reached (or until it has time to clean up the already open connections)? My way of thinking is to keep the server running no matter what, and if the client loses connection or doesn't get answered, it's not the servers problem. Any thoughts on that one?  (This is still using the 5.09.00RC5 version of the source code) John |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4222 |
Peter, Framebuffer Clear restores the screen in my case. I understand your reasoning, but I would suggest erasing the framebuffer is used when entering the editor. At the moment stopping a game that writes data to framebuffers, after stopping, and pressing F4 (edit) shows a blank screen. Regards, Volhout P.S. In earlier versions pressing ctrl-c brings the prompt on screen. Maybe you force a framebuffer write N ?. Anyway, what is the use of debugging when you don't see a thing ?I have not seen this in a long time. Edited 2024-09-23 01:41 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
| carlschneider Senior Member Joined: 04/08/2023 Location: South AfricaPosts: 158 |
Hi there Maybe I’ve missed some updates along the way. Goeff’s site is still serving 5.09.RC5 but I saw a reference to 5.09RC9 but couldn’t find a link on the forum. I see 6.00b6 as a link on this forum. What is the state of the art for the Webmite currently? Is it currently? Stable 5.08 Release candidate 5.09 RC5, no formal final stable release? 5.09 stable release abandoned in favour of 6.00 for RP2350 inclusion? Or am I just looking in the wrong places? Does 6.00 use a different SDk version with updated LWIP version or is the 5.08 and 5.09 WiFi instability still baked in? Sorry, more questions than answers… Cheers Carl Retirement is tough on Hobbies without a day job |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9100 |
V6.00.00 uses the latest sdk and LWIP. The sdk includes an update to the wifi driver. For me 6.00.00 is proving the most stable for web use of any release. 5.09.00 has been abandoned in order to include RP2350 support |
||||
| carlschneider Senior Member Joined: 04/08/2023 Location: South AfricaPosts: 158 |
Thanks Peter, much appreciated. Cheers Carl Retirement is tough on Hobbies without a day job |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4222 |
Hi Peter, Something strange.... Below code checks for a change in MM.INFO(PS2) to detect if a key is pressed. 'check if a PS2 key is pressed Print "press any key" Do a=MM.Info(ps2) Pause 10 b=MM.Info(ps2) If a<>b Then Print a,b Loop Until a<>b Print "PS2 found" If you run this code (F2) from the commandline it immediatly finds a PS2 keyboard. It must "remember" the F2 key you pressed on the PS2 keyboard to run the program. Similar with RUN+<enter>. If you enter the editor (F4) and run the program from the editor (F2) the same happens. But.... If you enter the editor, and make a change to the program (i.e. add a comment, space, whatever) and press F2 to run the program, it works as expected. It waits for you to press a key. I cannot explain the difference. I would (of coarse) want the program to work like this. Show that a new key is pressed, not act on a key that might have been pressed before. I tried reading MM.INFO(PS2) multiple times, as a dummy, to clear any buffers, prior to the loop, but that does not solve it. This is 6.0.0 beta 6 on a RP2040 VGA platform. Any idea ? Volhout EDIT: I found something . It is timing related. If you poll mm.info(ps2) too frequent you do not get usefull feedback. A 50ms delay between polling, and a "clear" of the buffer (reading mm.info(ps2) several times) prior to running the loop gives decent results. Edited 2024-09-24 21:38 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
| Page 3 of 4 |
|||||
 Print this page |
