If the PicoCalc has PSRAM, what pin is it using? I need to know so I can activate it with the
OPTION PSRAM PIN n
command. V 06.00.02 allows 5 RAM program slots (similar to flash slots) when PSRAM is active. The difference is that RAM slots will be erased after a power cycle whereas flash slots retain their data.
Well, I figured I try different pins and see if any work. GP0 is out since that’s part of COM1. GP 19 is already in use. GP47 is illegal except for the Pimoroni chip. That only leaves GP8 as a possibility. I tried that pin and the system accepted it and put it in my OPTION LIST.
When I tried the RAM (RAM LIST, RAM SAVE, etc.) commands, though, they weren’t recognized. I then tried to disable the PSRAM option using
OPTION PSRAM DISABLE
I get Error : Invalid Option so I can’t disable it.
Think I read somewhere that Picomite/MMBasic wouldnt allow you to chose the pins used in the PicoCalc so I didnt bother investigating further. I also overclock and that apparently isn’t good for the slow PSram either, some have found PSram timings CAN be adjusted for use at higher clocks but still of no use on the PicoCalc. Yes it has been mentioned ‘why did Clockwork put PSram on the main board then load it with PicoMite ??’. You might have luck via MicroPython and the sorts tho…
Answer to the question is NO. Not in a usable way. The RP2350 supports a second device on the QMI bus (quad spi) using one of GP0, GP8, GP19 and GP47 as the chip select. When a chip is connected in this way it is automatically memory mapped to 0x11000000 and be treated as normal RAM albeit somewhat slower. The PicoCalc has a PSRAM chip connected to normal GPIO pins so can only be used by copying data into and out of RAM not the same thing. MMBasic supports the QMI connect but not GPIO connected PSRAM
I wonder how hard it would be to modify the customized version of PicoMite to allow using GP20 as a valid pin number. Is it just a question of changing the test for a valid entry or is there other code that has to be changed?
I am pretty sure it is more complicated than that. As @picouser said, MMBasic supports the QMI connect but not GPIO connected PSRAM. So I am pretty sure some new code will have to be written. This question should be addressed to @adcockm, he is likely to know better than anyone outside of Peter, but Peter has shown no interest in supporting the PicoCalc.
Unfortunately I don’t understand the Pico hardware and PicoMite code enough to try to implement PSRAM support via GPIO. If there was already support for it via GPIO in PicoMite it would be easy to adjust the pins used in the code. From the discussions I’ve seen, it sounds like even if it was implemented, the slow speed of access over GPIO would mean that it couldn’t just be used to increase total RAM without slowing everything down, so you’d be trading more RAM for a noticable and maybe massive performance hit. Perhaps it could be implemented in a sort of “paging” way where special commands could be used to access it and store/retrieve data, but then you’d have to write special BASIC code just to use it, and it would probably only be useful in special circumstances. I don’t know how access speeds compare, but I’m assuming it would be faster than loading from a file on the SD, so you could do something like pre-load lots of data from the SD into GPIO connected PSRAM and then access it faster from your program. The tradeoff would be the wait time to load it, but then you could access it faster. Similarly, if you had a lot of writes to do it would probably be faster to do them in PSRAM and then dump a large chunk of it back to the SD for storage. Again, I’m not even sure that would be useful in many situations?
Overall it seems like a lot of custom work (which I don’t really understand well enough to attempt), for very little gain, at least when it comes to PicoMite.
I’m pretty sure I’ve read that people have gotten it working using MicroPython, but I’m not sure what they’re using it for, if anything?
The general consensus seems to be that Clockwork added a pretty useless bit of PSRAM to the PicoCalc. Pretty sure that has been mentioned on both TheBackShed and here by folks who understand hardware design. I’m not sure if it was just a poor design choice, a marketing tactic, or a bit of both.
The Pimoroni Plus 2 has its own issues with PicoMite.
The non-wireless version should work with PicoMite. I don’t own one myself, but PicoMite supposedly supports it, including the PSRAM on it. The documentation is very light on support for this module, but I’ve seen mention of it on both TheBackShed and this forum, and people have reported it works. However, it cannot be overclocked much (only to 252Mhz), so you won’t get the kind of CPU performance in PicoMite that you can get with the Pico2. Apparently there is a voltage issue on the Pimoroni board that prevents stable overclocking and Peter is of the opinion that Pimoroni implemented their PSRAM wrong, so while he (begrudgingly?) supported it in PicoMite (because of outcry from users on there), it doesn’t work very well. One, probably frustrated user, managed to get their Pimoroni Pico 2 overclocking well by removing the PSRAM completely. There are other user stories on TheBackShed that I’ll leave as an exercise for the reader to find, but the gist is that the Pimoroni module is not a good option for PicoMite either, unless you NEED the PSRAM and don’t care about the speed you’re running at. If you want something fast and overclocked, then you’re not going to be able to use that extra PSRAM anyway.
The wireless version, the Pimoroni Plus 2W does NOT WORK with MMBasic at all. It’s explicitly not supported by WebMite, and given the general feeling about WebMite on TheBackShed I expect you’d have a long time to wait if you expect it to ever be supported. Peter has stated he will not update anything related to the wireless functions on WebMite. Given how fragile that code is, and how little I understand the stuff Peter has done with it, I’m not comfortable trying to modify that code much either, at least in terms of adding real functionality and actually making use of full wireless capability of the WiFi and Bluetooth. I’d love to see that functionality added though, but only Peter understands this code well enough to do it, and he has no desire to (and seems to hate the idea of it).
So as far as the Pimoroni modules go, you should only consider the Pimoroni Plus 2 (WITHOUT wireless), and while you’ll be able to use PSRAM, you’ll only be able to use PicoMite (not WebMite) and run it at 252Mhz. If you want to run faster, then you should use a Pico2(W) module.
For sheer performance and access to more RAM in MMBasic, the Luckfox Lyra may be a better choice, but the only MMBasic that could run on it is MMBasic for Linux. People have tried it and it does work on the Lyra, but MMBasic for Linux does not have any wireless functionality at all, and it doesn’t sound like there is any plan to support it. It is also based on an older version of PicoMite, so it doesn’t support the newer commands and bugfixes that have been added in more recent versions. I’m not sure how well it supports graphics and the display, but it’s probabaly comparable to PicoMite/Webmite on the Pico modules. And of course it has the problem with proper sound support which requires a hardware mod, putting up with static in the sound, or just not using sound at all.
It’s certainly not “useless”, you have to keep in mind that PSRAM is not simply “more SRAM” and is not expected to be either transparent to access or equally performant.
It can’t be used in a normal memory-mapped fashion, but copying blocks to/from normal RAM is pretty straightforward and is still great for some applications.
As for the Pimoroni board, I have no idea what Peter’s issue is, since the schematic shows it’s wired up exactly the way the RP2350 datasheet says it should be (sharing the QMI SPI bus pins, and a separate QMI CS pin). And of course he doesn’t elaborate.
@adcockm, Hypothetically speaking, if I were to design a board that would plug into the side of the PicoCalc, wired something like the table below. Would it be possible to modify PicoMite Basic for the PicoCalc to use the PSRAM?
It’s theoretically possible that PicoMite could be modified to use PSRAM connected to GPIO, but I don’t think I have the ability or time to research and try to understand all the inner workings of PicoMite to try to add that kind of PSRAM support. If Peter could be talked into doing it, there’d be a better chance it would work and not break or destabilize things. So I’m not sure the board you described would be useful for anything unless you wanted to use MicroPython instead (or something else) since it would probably be easier to implement with that, even if no one has already done it yet. (Maybe someone already has – I’m not sure?)
I looked at the code a bit, and it’s not something that looks like it would work if only the pin definition was changed. There are probably lots of other things that would need to be adjusted as well. I also realized that the current implementation in PicoMite for PSRAM only supports PicoMite builds and isn’t active for WebMite builds. So if you want to use WiFi with PicoMite then you’re not going to be able to use PSRAM at all. I guess that’s why the Pimoroni Pico 2W is explicitly not supported at all?
I figured that was the case. I was pretty sure it would not work as a direct RAM expansion. However, I think it could still be used via Basic code like any other SPI device and it could be used as buffered I/O or external scratch storage, but I don’t think that would be terribly useful. I think there are better choices for external UART, i2c or SPI devices that could be put on a PCB and plugged into the side of the PicoCalc, like an RTC, temperature sensor or GPS.
