On Picomites
OPTION RESET will erase the Library.
This is done because the indicator for the library OPTION.FLASHSIZE is reset to its default value and there is not a way of knowing if the flash slot contains a valid library.(It could be used just as a normal flash slot)
On the ARMmites we have
LIBRARY RESTORE that will test for the existence of a library and restore the OPTION.FLASHSIZE pointer if a library exists.

  Quote  

On Picomites
OPTION RESET will erase the Library.

Yes it does on the PicoMite too. However, I think what electricat may be doing is then loading options from disk that have the library configured. Hence he can't then load the library again. I'm not pursuing this further because the library is working for everyone else other than the COLOR issue which you have solved

  matherp said  

  Quote  

With connected PS/2 Mouse on GP27,GP28 it is impossible to use GP26, since it ALWAYS shows 3,3V (in reality the pin is @ 3,7V measured with multimeter).

Sounds like a H/W fault at your end. Definitely not the case with a bare Pico2 running PicoMiteVGA V6.00.02RC5

I guess you tested this with a level shifter? Even on breadboard I have the same issue! Only way to solve this is with a level shifter (2N7000) between clk & data.
But since the Pico 2 is 5V tolerant I leave out the level shifter for the PS/2 mouse and got this problem. With level shifter it works. But is this normal?

My theory: The Pico 2 ADC isn't 5V tolerant, since GP27 & GP28 belong to the ADC, if voltage >= 3,3 then it overloads the GP26,too.

Greetings
Daniel
Edited 2025-03-19 21:04 by Amnesie

Hi Daniel,

That is important. And new to me.
You could very well be onto something. But that would also influence GP29 (measuring Vbus).
Anyway, I would add a level shifter never the less...

Volhout
Edited 2025-03-19 21:21 by Volhout

@Peter, disco4now

Now I see whats going on!
Thank You both, for excelent explanation. Knowing that, I will be carefull with this.
Updated manual (with some carefull hope   ) would protect against such questions from other users, next time.

I did not want start new thread for this minor question.

I did not get in, how mm.info$(PATH) might be usefull/used?

If I command prompt -> ? mm.info$(PATH)
it returns NONE

if inside editor I would type in ? mm.info$(PATH) after run it would be changed to ? mm.info(PATH) (and sure, returns NONE) while it seems to me string thingie...

To my understanding it should return path, but I failed to use it properly maybe

for examle


I see path changed from command prompt, but after RUN returns NONE and modified to


Edited 2025-03-19 22:23 by electricat

  Volhout said  

Hi Daniel,

That is important. And new to me.
You could very well be onto something. But that would also influence GP29 (measuring Vbus).
Anyway, I would add a level shifter never the less...

Volhout

Hello Volhout,

I can confirm my theory.

As soon as I connect a Voltage > 3,3V to GP27 OR GP28, it results in compromising GP26, too (it is constantly at 3,3V).

So Peter, is this a general fault in the Pico ADC? Of course I can solve this via level shifter (and I will!) but I think this is an important thing to notice, since it no langer has to do with a PS/2 mouse, but with any voltage > 3,3V on other ADC pins. I always read that the Pico 2 supports 5V ?!

Greetings
Daniel
Edited 2025-03-19 22:32 by Amnesie

Certainly on the RP2040 the ADC pins are different to the others. They all have ESD protection diodes up to IOVDD (linked to 3V3 on the Pico), which none of the others do. Attempting to put more than about 3V3+10% on one will attempt to power the whole chip at the input voltage. This also applies to the ADC inputs of the RP2350.

You shouldn't attempt to use more than 3V3 on *any* ADC pin on either chip, even if used in digital mode because the diodes are formed on the substrate and are not actually on the other side of the ADC multiplexer. (There is actually only one ADC on the die which is multiplexed to a number of pins.)

  Quote  

I did not get in, how mm.info$(PATH) might be usefull/used?

It returns the location that the current program was loaded from - if from disk
use CWD$ to get the current working directory

  Quote  

Certainly on the RP2040 the ADC pins are different to the others. They all have ESD protection diodes up to IOVDD (linked to 3V3 on the Pico), which none of the others do. Attempting to put more than about 3V3+10% on one will attempt to power the whole chip at the input voltage. This also applies to the ADC inputs of the RP2350.

You shouldn't attempt to use more than 3V3 on *any* ADC pin on either chip, even if used in digital mode because the diodes are formed on the substrate and are not actually on the other side of the ADC multiplexer. (There is actually only one ADC on the die which is multiplexed to a number of pins.)

Correct ADC pins are not 5V tolerant

OK

I never read about that, only that the PICO 2 is 5V tolerant. Good to know, I will redesign my PCBs :)

Thank you!
Daniel

Harm and others using PIO

I want to make a big change to PIO initialisation to allow all pins on the RP2350B to be used from MMBasic. For various reasons this simply can't be done with the current Basic interface routines.

The proposal will be to eliminate the PIO helper functions and have one big INIT call to replace them and replace PIO SET BASE

PIO INIT MACHINE pio, sm, clock, startaddress,
sidesetbase, sidesetno, sidesetout, setbase, setno, setout, outbase, outno, outout, inbase,
jmppin, wraptarget, wrap, sideenable,
pushthreshold, pullthreshold, autopush, autopull, inshiftdir, outshiftdir, joinrcfifo, jointxfifo, joinrxfifoget, joinrxfifoput

In this approach you will use the actual GP numbers even when they are above GP31. The system will automatically check that you are using GPs in the range 0-31 or 16-47 and give an error if they are not. It will automatically set the GP base for you.
It is important to note that the pin base (GP0 or GP16) applies at the PIO level and not at the state machine level.

As always I want to have a single code base so would much prefer this to be a change which applies to all variants.

It would mean a change (simple) to all programs using PIO but would be future proof in a way the current approach isn't.

Thoughts?
Edited 2025-03-20 20:34 by matherp

I have a question for Matherp. Since there are several boards (like the Pimoroni Pico plus 2) that don’t work under overclock and therefore can’t be used in the HDMI version, I was wondering if it would be possible to use the technique described here:

https://github.com/Panda381/DispHSTX/blob/main/_doc/DispHSTX.pdf

The DispHSTX driver is controlled by the system clock by default. This requires that the system clock is set to 5 or 10 times the pixel clock by the driver.
There is another alternative yet - by turning the DISPHSTX_USEPLL switch to 1, another variant is used. Specifying the DispHstxClockReinit() function at the beginning of the program redefines the clock control in the processor so that all peripherals and the system clock are controlled from the common PLL generator PLLUSB, while the PLLSYS generator is used only for controlling the HSTX driver. The clock generated by the PLLUSB generator should preferably have a frequency equal to the integer multiple of the USB clock, that is 48 MHz. This allows the HSTX driver timing to be controlled independently of the system clock. It is even possible to overclock the HSTX clock a little more than would be possible when driving from the system clock. If the HSTX driver malfunctions due to overclocking, there is no risk of the entire system crashing, the system can even check the correct function of the driver and adjust its clock if necessary. However, it is important to remember that the processor must be fast enough to generate the display signal in this mode, so it is recommended that only experienced users use this mode.

IIRC the issue with overclocking isn't that it is needed to output HDMI, it's to give enough time to be able to use layers. These have to be copied into the framebuffer between video frames. The higher the resolution the more data there is to copy in the same time. You can get HDMI at much lower CPU speeds but with reduced resolution and without layers.

No doubt I'll get corrected if I've misunderstood this.  :)

@Peter,

About PIO: Is this something that can be postponed for 6.00.03 ? Un tp now we have managed to have 6.00.02 compatible with virtually all legacy PIO programs (actually, virtuall all MMBasic programs).
With this change all PIO programs will need a re-write of the MACHINE INIT, in which the order of items is also changed.

I do understand why this is handy, but please delay to 6.00.03.

A second thing to wory about is the number of characters that are in this new INIT (the line length). Even in case some values can be empty (default) or a 0 or a 1, there are some that are longer (i.e. PIO(WRAP_TARGET) ), so the line will become unreadable/not editable in the internal editor.

Again, nice suggestion for 6.00.03. Please release 6.00.02rc5, with only the LIBRARY fix. Then continue with MMBasic command changes like these in a new release. Pico is not finished yet, you will continue to find optimizations and new idea's for many more months/years. 6.00.02 is not the end, but let it be a milestone.

Those a re my 5 cents.

Volhout
Edited 2025-03-20 22:54 by Volhout

  Volhout said  

@Peter,

Pico is not finished yet, you will continue to find optimizations and new idea's for many more months/years. 6.00.02 is not the end, but let it be a milestone.

Volhout

I share those thoughts. But in general the idea is great!

Greetings
Daniel

V6.00.02RC6 is available on

https://geoffg.net/Downloads/picomite/PicoMite_Beta.zip

Fixes bug in library when COLOR command is used and spaces appear before it in the line
Fixes bug in VGA versions when changing to a smaller font at the command prompt

LINE x1,y1,x2,y2,w,c now supports the width parameter for diagonal lines

RP2350B only
OPTION VGA PINS and OPTION AUDIO I2S both now support pins in the range GP32-GP47

Note: in all cases pins specified must all be in either the range 0-31 or 16-47
In the case of VGA/VGAUSB with AUDIO I2S this applies to all pins for both functions

Oops...
When I unpack the update V6.00.02RC6 it still says V6.00.02RC5

Greetings,

Jan.

  JanVolk said  

Oops...
When I unpack the update V6.00.02RC6 it still says V6.00.02RC5

Greetings,

Jan.

Same here.

Tom L
Edited 2025-03-21 07:58 by toml_12953

The upload doesn't seem to have worked - try again