| Menu | JAQForum Ver 19.10.27 |
| Menu | JAQForum Ver 19.10.27 |
Forum Index : Microcontroller and PC projects : PicoMite V6.01.00 release candidates
  Page 9 of 9 |
||||||
Bear in mind we're doing something very unusual. That's a default with some distros but please refer to the above. The name has stayed the same for compatibility reasons. Using a group is a way to prevent naughty access to hardware and to allow it in a controlled way to programs/users where that's wanted. A matter of opinion, I'd say. I like screen; you may not (if you used it). It works for plenty of people, some problem at your end with the out of date box I suppose. BTW, Windows has its own set of issues with this stuff and resorting to the likes of Zadig is often needed. It's not even installed by default in my experience! John Edited 2025-10-27 07:03 by JohnS |
||||||
@matherp The published RC8 code does not build with the modified Pico-SDK. There is a definition for gpio_get_out_level_all64(void) in External.h that is identical to what the updated Gpio.c file for the Pico-SDK provides. I suspect this was done so Gpio.c doesn't need to be replaced in the Pico-SDK. But I'm unsure of that. It causes GCC to barf. I just commented out the External.h definition for now. It shouldn't matter where the definition comes from. But there shouldn't be two of them: void ExtSet(int pin, int val); int64_t ExtInp(int pin); /* static inline uint64_t gpio_get_out_level_all64(void) { #if NUM_BANK0_GPIOS <= 32 return sio_hw->gpio_out; #else return sio_hw->gpio_out | (((uint64_t)sio_hw->gpio_hi_out) << 32u); #endif } */ /* ============================================================================ * Function declarations - Pin manipulation * ============================================================================ */ Edited 2025-10-27 10:33 by EDNEDN |
||||||
The problem still exists. I'll code around it. |
||||||
You need to revert gpio.h back to the original supplied with the sdk. Note that I had updated the readme and removed gpio.h from the archive Edited 2025-10-27 18:30 by matherp |
||||||
You just can't trust claude to think things through properly  Try this version for RP2040 VGA PicoMite.zip This now has the same format as load dithered LOAD JPG file$ [, x] [, y] [,mode] [,ximage] [,yimage] x, y: position to start drawing on the screen (defaults to zero) Mode Options: Mode -1: No dithering (processes image as-is, default) Mode 0: Floyd-Steinberg RGB121 Mode 1: Floyd-Steinberg RGB332 Mode 2: Atkinson RGB121 Mode 3: Atkinson RGB332 ximage,yimage: position in the image to use to draw. For example if the image is 480x320 and the display is 320x240 then setting ximage to 80 and yimage to 40 would display the central portion of the image |
||||||
Hi Peter, Claude simply needs your supervision to get to great results....  JPG dithering works fine now. The speed degradation also seems gone (to the same level as RC7). Regards, Volhout P.S. the "LOAD DITHERED" is already compatible with "LOAD IMAGE", so it could be removed as a separate command. Just add the extra parameters to LOAD IMAGE. Edited 2025-10-27 20:26 by Volhout |
||||||
An observation regarding PicoMiteHDMI MMBasic USB RP2350A Edition V6.01.00b5: "Play MP3 FileName$" crashes (requiring a reset) if a function is called simultaneously with playback without appropriate pauses. In my case, it was "inputE$()" from the latest FM. This is not a request for a bug fix; it's just for informational purposes. Inserting a short PAUSE resolves this issue. Regards Michael |
||||||
|
||||||
Hi Peter, Even better than RC7, not yet b20, but close enough. In case this also satisfies the guys with USB problems, freeze it here. For 2040 this is as good as it gets. P.S. I did not test everything yet, but the most critical programs from the past do all work. Volhout |
||||||
Peter, This last version is not 100% robust. I have not found the receipt yet to reproduce, but I have seen 4 occasions now where the unit "locked up" (*). Once when opening the editor, twice when starting a program, and once when MMedit/MMCC finished transferring a file (this was MMedit 533 that does not support AUTOSAVE N yet. Later with MMedit 535 that supports AUTOSAVE N it did not occur (yet). Volhout (*) Both console and PS2 keyboard could not revive the unit. But I know that one of the lockups occurred after I closed the terminal program on the PC while the program was running. And then after few seconds the lockup occurred. I did not unplug the USB, only close the PC terminal program. It sounds like data left in a USB buffer that has not end point anymore, but that does not match with the editor opening a program, and locks up after the first line is printed on screen. That does not use the USB console in that particular moment in time. EDIT: no, it does.. you can also edit in the console.!! . Edited 2025-10-28 00:07 by Volhout |
||||||
Try this version. I've made some more changes and certainly in W11 it survices the terminal being closed when running a tight output loop Do Print "hello",i Inc i Pause 20 Loop PicoMiteRP2040VGAV6.01.00RC9.zip |
||||||
My suggestion is this declaration is removed from the PicoMite archive copy of gpio.c: static inline void gpio_acknowledge_irq(uint gpio, uint32_t event_mask) { check_gpio_param(gpio); io_bank0_hw->intr[gpio / 8] = event_mask << (4 * (gpio % 8)); } It is conflicting with the Pico-SDK's (unaltered) gpio.h file's similar declaration for gpio_acknowledge_irq(). . Edited 2025-10-28 01:03 by EDNEDN |
||||||
The gpio.c version was out-of-date. Now fixed |
||||||
| Page 9 of 9 |
||||||
 |
The Back Shed's forum code is written, and hosted, in Australia. |
