What happened to Pico?

Hello,

I found this site (phenomenal work, by the way) as we’re having a bit of a retro computing challenge at work, and I wanted to bring to life some old BBC Basic code I wrote many decades ago. My plan was to create a “mini BBC” machine from an old Raspberry Pi in a BBC Micro style 3D printed case, running RiscOS Pico, with my old code running on this.

However… as much as I look around the site and the Internet, I can’t find a working download link. Have you withdrawn this project??? If so, is there any way I can still get a copy of Pico, or am I out of luck now?

Many thanks
Gary Delooze

I haven’t seen any official statements around it, but I know it has issues with newer Pis so I’m not entirely surprised that it’s gone. It’s still available through the Wayback Machine though.

Pico was a one off intended to celebrate the anniversary of BASIC. However you can get any Pi running RISC OS behaving like Pico with something like the following:

*Unplug BootFX
*Configure Language 13
*Configure Mode 7
*Opt 4 0

(Language should be the module number of BASIC; I think it’s 13 but check this…)

That way, it will boot directly into BASIC with the old teletext style display.

Thank you both – very much appreciated, I will try both of those over the weekend

hello all,

how do i get the pi to boot into basic as rick explains? is there some config file i need to edit?

is there some config file i need to edit?

Press F12 to get to a * prompt, then issue the commands:

*Unplug BootFX
*Configure Language 19
*Configure Mode 7
*Configure NoBoot

Finally, reboot (i.e. press Ctrl-Break). This should boot into BASIC.

I still think that something along the lines of Pico should be kept up. Not for BASIC (as it does not have WIMP needed by most BASIC programs), though for close to metal programs (single tasking RISC OS programs) that can run without much overhead from the OS.

Sounds to me like you’re describing RO without the disc based components, or a stripped down disc based boot section

I still think that something along the lines of Pico should be kept up. Not for BASIC (as it does not have WIMP needed by most BASIC programs), though for close to metal programs (single tasking RISC OS programs) that can run without much overhead from the OS.

It’s pretty much what has been discussed multiple times as an “IoT-like” configuration. Suitable for IoT, some form of embedded applications and retrocomputing/retrocoding.

Still supporting the boot process, no desktop, no desktop apps in ROM. Possibly with the newer Network Stack (when available), headless support and eventually (future) a multi-task module to multi-task CLI apps.

However before one embarks in such a challenge remember that (at this time) when RISC OS is in CLI mode it starts spinning the CPU, so the Pico like configuration is not ideal for low power applications. Ironically Linux in CLI-only (or headless) it’s a better option at this moment if one wants to pursue IoT/Embedded low power apps.

Still supporting the boot process, no desktop, no desktop apps in ROM.

Why bother? Regular RISC OS can do that – just tell it to boot into the command line.

Supporting the Boot process is a bit harder as it is spilt between pre-Desktop setup, and post-Desktop components, and I wouldn’t imagine there’s much appetite to mess with any of that.

Though, it shouldn’t be too hard to replace it with a simple custom !Boot script that will load and set up the required things and then call the embedded application that is wanted.

I wouldn’t worry about the apps in ROM. They’ll just take some space in the ROM image (a mere fraction of the contents of an SD card) and they won’t ordinarily be available.
But, if you ever need to fix anything, you might appreciate having the ability get to a desktop with a functional editor that isn’t going to poop itself because it can’t find fonts, settings, menus, and whatever else…

RISC OS is in CLI mode it starts spinning the CPU

Yup, the speed management is part of the Wimp. Outside of that, you have to do it yourself. It might suffice to probe to see if there’s a slow option, and to step back prior to handing control to the application? A little bit of BASIC to call a few Portable module SWIs should do the trick…

Why bother?

Agreed, sorry I forgot to add to my previous post that most of it is achievable just via config. Reading/Posting on here while cooking dinner! :D

But, if you ever need to fix anything, you might appreciate having the ability get to a desktop with a functional editor that isn’t going to poop itself because it can’t find fonts, settings, menus, and whatever else…

True. BTW that reminds me in the past I made a Screen Editor for the CLI, need to find the sources back in one of my Pi SD or my old RiscPC HD…

Also, just to add to my previous post the headless configuration is available in the PiTools so it’s probably possible to extract just that code (respecting licenses of course!) and use it on a Pico like configuration.

It might suffice to probe to see if there’s a slow option, and to step back prior to handing control to the application? A little bit of BASIC to call a few Portable module SWIs should do the trick…

Good point, I’ll have a look at that one of these weekends, it could be interesting to have an initial (single-task) model and go from there.

The reason I am mentioning this is because there are so many projects being done for the RPi Zero (no need for WiFi) where the Pi Zero is being used to emulate a 68K or to produce a scan-doubler for old RGB systems and it may be an opportunity for RISC OS to expand a bit on this type of projects (they are all headless, CLI only).

I can’t see any IOT developer sacrificing all the development tools, drivers, libraries and automated updates freely available on Linux. Unless using BBC BASIC is the main priority.

I can’t see any IOT developer sacrificing all the development tools, drivers, libraries and automated updates freely available on Linux. Unless using BBC BASIC is the main priority.

I agree on this to some extent. However, let’s not forget that plenty of IoT is also done completely OS-less. Libraries can be ported, and I am sure you are aware that the GCCSDK offers a gdbserver tool to debug code on RISC OS via GDB. It is also possible to use JTAG of course.

With that said I do not wish to start now an argument, I know you have strong feelings about this, but the automated updates can be added to RISC OS, I added it to the list of things for the Desktop Modernisation Project, so (unless someone else comes up with a tool before me) it will be available at some point.

I already started to work on a JSON based protocol and with the module to quickly query RESTFul APIs (I demoed it on my youtube) I can pull down a JSON with the info from a github repository (so I do not even need to host it on my servers). The JSON get parsed by cJSON lib which I also made it available to everyone from RISC OS github Community (I just need to formalise the release, had not much time for RISC OS lately).

The JSON file contains all the pointers to where to fetch the latest RISC OS image (for an IoT the kernel.img is more than enough) and other files (if required). The code will then create a RAM disk (if there isn’t one created already) download the img and whatever else is required and place all the files in the RAM disk. Files can also be verified (right now using MD5 only).

It then backup the current img in the FAT32 partition and replaces it from the RAM disk on the FAT32 and the final step will be reboot the system. Yes most of linux file systems have inodes and so it’s safer on Linux to do such a process, but so far experimenting with the RAM disk seems to be safe enough.

Right now I need to complete this process. For the “automation” it’s possible to call the process from a running application (this until a multi-tasking module will be available).

The “trick” is to use a module for all of the above, so that it can run without replacing the running application (given that for now RISC OS without Desktop is single task). But I need to test if it’s safe enough to just have a module or if it’s best (for the last bit) to use a utility.