 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 V6.01.00D betas
  Page 2 of 4   |
|||||
| Author | Message | ||||
Mixtel90 Guru  Joined: 05/10/2019 Location: United KingdomPosts: 8232 |
I only tested it on Tera Term from the console, of course. The HDMI shouldn't really be having an effect, I don't think. I was attempting to run the latest rc on it. It loaded and I could set the options etc, but I couldn't use the editor. So I tried loading an older version, which was just the same. Hmmmm... thinks I, the only cause has to be something that didn't get cleared out of the flash so I wiped it. The latest rc then loaded and ran perfectly (in so far as I tested it anyway). I noticed that flash slots 1 and 2 were shown as used (before I wiped the flash). I had saved my test program in slot 1 but I don't know about slot 2. There may have been something in it before I started. It's possible that the screen size messes things up, I suppose. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| EDNEDN Senior Member  Joined: 18/02/2023 Location: United StatesPosts: 229 |
I would encourage anybody else loading the 'D' version and switching back to the normal version to post if they are seeing the need to 'Flash-Nuke' the PicoMite to recover. I haven't seen it. But I do sometimes see my loaded program and A: drive files disappear when I don't expect them to. Opinions and thoughts are very welcome here. |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 8232 |
Me too. I'd be very interested to see if it's only me. I didn't nuke the flash before I installed the debugger version so it could possibly be something that carried over from previously. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| EDNEDN Senior Member Joined: 18/02/2023 Location: United StatesPosts: 229 |
@Mixtel90 : Have you had a chance to play with the saved libraries yet? All the comments are stripped out of the code as it is saved in the library slot so that makes it harder to step through library functions and know what they are doing. My guess is people only save a library to the library slot after it has been fully debugged. And usually they won't even want to step through it. Instead they would just Step-Over any given function. But if that isn't true, it would be easy enough to allow the library code to be saved with comments, remarks and line spacing preserved . |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 8232 |
No. I never even considered them. I got onto doing other things then went out for most of the day today (one has to keep one's bus pass lubricated doesn't one?!). I've used the Library before and have learned that you keep your source elsewhere! The thing is, you don't *want* the library routines to have the extra stuff in them, it both slows them down and restricts how much stuff you can fit into the flash slot. It's far better to keep the source program. I realize that it makes stepping through a library routine difficult, but that's just how it is. You couldn't step through a CSUB and a library routine is basically a high level version of one of those. :) You should be able to trust a library routine. If you are distributing libraries then, at the very least, you should document them in some way. Your user then knows what the routine is expecting on entry and what it will return. That's all that's needed really. How it does it doesn't matter - it's beyond the user's control anyway. :) Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| EDNEDN Senior Member Joined: 18/02/2023 Location: United StatesPosts: 229 |
OK! Good points! I agree. There is probably no need to allow the comments and remarks to be kept. I don't agree on keeping the bus pass lubricated. I would much rather just hop in my car. There aren't even busses or taxis where I live so I don't have choice. |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 8232 |
That would make things difficult. lol! However, I don't dive (I never have done apart from a short time when I had a provisional motorcycle licence). I've been dependent on public transport for so long that it's second nature to me. I have free bus transport after 9:30AM on all local (and some not so local) buses within England. I can also go into the rest of the UK but I can't set off from there, so I have to be back in England or pay a normal fare to get back. As buses take ages it's no real loss! Where we are we have very frequent buses into Preston and not quite as frequent to Chorley. Both of those have bus stations that cover a fairly wide area so it's often only one change of bus to get quite some distance. I can buy a discount ticket on the trains too, which gives me 33% off fares. You have to be certain that you are going to be using them enough to make it pay though - and there's no free transport option on there. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
disco4now Guru Joined: 18/12/2014 Location: AustraliaPosts: 1038 |
I just tried the latest Putty from windows and it does respond to the display size escape sequence. (the one that MMBasic send after OPTION DISPLAY is entered.) I seem to remember there use to be a checkbox something like Allow Screen Resizing X in the older verions that needed checking, but can't see the option on the latest, is on by default. P.S. On new version under Terminal/Features/Disable remote-controlled terminal sizing is NOT checked by default. Edited 2025-10-12 08:30 by disco4now F4 H7FotSF4xGT |
||||
| EDNEDN Senior Member Joined: 18/02/2023 Location: United StatesPosts: 229 |
Thank You for running down that information. I just pulled up the code done by 'OPTION DISPLAY' to verify it is using the same VT100 ESC sequence. It is sending ESC [ 8 ; height ; width t void MIPS16 setterminal(int height, int width) { char sp[20] = {0}; strcpy(sp, "\033[8;"); IntToStr(&sp[strlen(sp)], height, 10); strcat(sp, ";"); IntToStr(&sp[strlen(sp)], width + 1, 10); strcat(sp, "t"); SSPrintString(sp); // } That is the exact same Escape sequence that MMDebug is using. I think this problem is resolved!  |
||||
karlelch Senior Member Joined: 30/10/2014 Location: GermanyPosts: 273 |
Hi EDNEDN, I wanted to test your latest version of the debugger (PicoMiteRP2350V6.01.00b20D.uf2, Pico 2). The firmware installs fine but then xmodem transfers are extremely slow (a few bytes per second) and then fail. I use TeraTerm (v5.2) or the Python xmodem library (Windows 11). When using PicoMiteRP2350V6.01.00RC0.uf2, everything works. No special options set; I tried to xmode files right after installing the respective firmware. Best Thomas |
||||
| EDNEDN Senior Member Joined: 18/02/2023 Location: United StatesPosts: 229 |
Usually, I use MMEdit with MMCC. I click on the Transfer button in MMEdit and it kicks off the transfer in MMCC. MMCC is actually using an xmodem transfer to get the work done. Can you give MMCC paired with MMEdit a try? Literally nothing is different in the xmodem code. But I have seen the same xmodem transfer issues on both the PicoMitev6.01.00b?? base firmware and the 'D' version of the firmware. There is something in the xmodem code that needs to be cleaned up to make it more robust. And actually... the problem isn't just in the PicoMitev6.01.00b?? firmware. I've run into issues on the PicoMitev6.00.?? firmware also. I've gone to great lengths to make sure everything is 100% compatible with the base level firmware. And if you search on XMODEM there has been a lot of recent activity resolving XMODEM transfer problems. I'm wondering if there is still something wrong? Please give me a day or two to look through all the xmodem code to see if I can find something that might be causing a problem. And in the mean time, can you try MMCC / MMEdit and see if that works for you on your platform? Edited 2025-10-12 23:53 by EDNEDN |
||||
| ville56 Senior Member Joined: 08/06/2022 Location: AustriaPosts: 262 |
with RP2350 webmite I get the following screen when using "EDIT" ....  for each character I type in, I get an additional line at the bottom. > option list WebMite MMBasic RP2350A Edition V6.01.00b20D OPTION FLASH SIZE 4194304 OPTION COLOURCODE ON OPTION CPUSPEED (KHz) 150000 OPTION DISPLAY 45, 145 OPTION WIFI JN88fg, *********, RP2350-1 Client software is MMCC, latest edition. I did nuke the flash before uploading the debugging firmware ... Is there anything I did not set correctly? I also have crashes (pico reboots) with RP230 (non-webmite) on calling a function but I have to investigate that further and boil it down to something that can be reproduced with short code. 73 de OE1HGA, Gerald |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6338 |
When loading programs from MMEdit, MMCC uses AUTOSAVE, not XMODEM. XMODEM is used when in the file manager. Try setting MMCC display to match the 'mite 145 x 45 I will try and find time to load the firmware and do some testing. Jim VK7JH MMedit |
||||
| TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6338 |
There is a problem with XMODEM and possibly any binary file transfer. XMODEM packets have a packet counter byte and when it gets to the 4th packet, the &h04 is not passed through. I assume that is being dropped when the debugger is activated. This limits XMODEM transfers to 384 bytes. You need to prevent the debugger from watching for it's activation code during XMODEM Some programs send and receive HEX values and that might also cause grief. Jim VK7JH MMedit |
||||
| EDNEDN Senior Member Joined: 18/02/2023 Location: United StatesPosts: 229 |
Thanks for the heads up... I'll do the same thing that is done with Ctrl-C being used as the Break key. During Xmodem transfers the Break key is disabled so the Ctrl-C passes through. And then at the end of the Xmodem transfer, the Break key is restored. I'll regenerate all the binaries and give them a test and then post the update. |
||||
| TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6338 |
You also need to have a way of disabling it similar to OPTION BREAK 0 VK7JH MMedit |
||||
| EDNEDN Senior Member Joined: 18/02/2023 Location: United StatesPosts: 229 |
Yes... That was already in place. There was the ability to switch the Debug key to something else. And 0 was a special case that disabled it. Now Xmodem turns off the Debug key until the transfer is completed. And then restores it. Edited 2025-10-13 12:57 by EDNEDN |
||||
| EDNEDN Senior Member Joined: 18/02/2023 Location: United StatesPosts: 229 |
Xmodem fix... (Thank You karlelch & TassyJim!) PicoMiteV6.01.00b20D_Documentation.zip PicoMiteV6.01.00b20D_Firmware.zip |
||||
| karlelch Senior Member Joined: 30/10/2014 Location: GermanyPosts: 273 |
Thanks EDNEDN! Looking forward to testing it tonight. Cheers Thomas |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 5394 |
Hi EDNEDN, Using b20 for 2040. Looked at the cheat sheet, tried some, but haven't found the clue yet. I have a program that uses SETTICK, and while stepping through the code, I want to skip that particular line, to avoid ending up in the associated SUB every click I make. Is that possible, or should I comment out the line in the editor before running ? I tried "step over", but that executes the SETTICK command anyway. Volhout PicomiteVGA PETSCII ROBOTS |
||||
| Page 2 of 4 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
