RC15

Just wondering how far away we are from the next installment of RISC OS for RPI

I’d like to know too. I’m awaiting a proper release that supports the Rpi 3.

There have been various posting saying it is being worked on. I see some of the parts that were being worked on have recently been included in the nightly builds, so it slowly getting there! I suspect one of the problems is trying to see which of the bundled third party apps need updating (There are a lot). They also have to decide if they go for Pi 3 & Pi Zero compatibility. Whilst I think Pi Zero may not need much if any extra work than Pi 2 compatibility, testing it does increase the amount of work required significantly.
Thinking of how people can help speed up a release I think the following would help:
If you have a Pi 2, 3 or Zero and have used any of the third party software in RC12 ¹ and the author hasn’t stated compatibility with Pi 2, 3 or Zero, let the author know of any issues or that no issues exist. That could be very helpful. I say the author rather than ROOL deliberately as the Author is the person who could resolve problems and it should reduce ROOL’s workload and let a full release appear sooner.
¹If you know there are later versions than in RC12 and Pi 2, 3 or zero and appropriate compatibility isn’t noted by the author you could let the author know of any issues or that no issues exist.
I hope the above makes sense, words aren’t my forte!

They also have to decide if they go for Pi 3 & Pi Zero compatibility.

If they don’t go the full way, would the release be able to have a different status for different platforms?

Just wondering how far away we are from the next instalment of RISC OS for RPI

At the London show in October 2016 Steve Revill said that:

A new RISC OS Pico release was imminent, which would include the model 3.
A new RC-xx SD card image was a ‘few weeks away’, would include GPIO 
fixes and was expected ‘this side of Xmas’.

Now we just need a glossary for ‘a few weeks’, ‘imminent’ and ‘this side of Xmas’. Seriously though it does indicate that it should appear soon and include the model 3.

Now we just need a glossary for ‘a few weeks’, ‘imminent’ and ‘this side of Xmas’

There was also a DDE release impending. Perhaps something came up that threw everything off the rails.

Well, expect an imminent announcement of the Pi 4…

It’s only been 10 months and 5 days since the Pi 3.

I actually wouldn’t be surprised to see a Pi 4 in February.

Feb 2015 – Pi 2
Feb 2016 – Pi 3
Feb 2017 – Pi 4?

Obviously the original Pi wasn’t Feb 2014, and two data points don’t make a pattern, but we’ll see…

I can’t remember his exact words but I heard Eben being interviewed a few months ago and I was left with the impression that it would be 2+ years before Pi 4

I seem to remember that PiCompute Module 3 was mooted for Q4 2016, and it has been seen, I believe, so that would probably come first.

I’m just hoping it’s form-factor compatible with the original PiCompute…

I’m just hoping it’s form-factor compatible with the original PiCompute…

I’m sure they’ve said it would be.

I wouldn’t hold your breath waiting for a Pi 4. As andym says they’re still playing catch-up with the compute module. I’ve also seen it mentioned (probably on the Pi forums) that some changes such as increasing the amount of RAM beyond 1GB will require a fair amount of work being done to the SoC (rearranging memory maps, adding extra address lines to the internal & external busses, etc.). If there was a better “low-end” ARM core available then maybe they could upgrade to that, but I suspect that at this point people will be more interested in more RAM, better storage (SATA?) or GPU improvements (speed, screen resolution), all of which are going to be more costly (in terms of development time+money) than “just” swapping out the ARM core. And as we’ve seen with the Pi 2.1, they’re now in the situation where they have to go back and revise older designs to use the newer SoCs in order to maintain their desired price point, so I’d expect future updates to be less frequent in order to minimise the time spent refreshing the older designs.

Back on the topic of RC15 (and Pico, and DDE), I’m not aware of anything specific that’s holding them up. So it’s probably just the usual problem of ROOL not having as much time available as they’d hoped for when they announced that the new releases were coming “soon”.

So it’s probably just the usual problem of ROOL not having as much time available as they’d hoped for when they announced that the new releases were coming “soon”.

When I said: “Perhaps something came up that threw everything off the rails.” I was actually thinking of domestic crises.
Apparently some people have what is known as “a life”

Apparently some people have what is known as “a life”

Really? That’s news to me!

https://www.riscosopen.org/viewer/revisions
New DDE, new ABC both coming.
And so probably new RC too…

Nice to see some work on ABC, but there’s still more to do!

Off the top of my head (with no specific changes in functionality¹):

• GCOL [a,]r.g.b (also COLOUR r,g,b ?)
• COLOUR OF r,g,b [ON r,g,b]
• &dead is the same as &DEAD

¹ By that, I mean updating existing behaviour to match modern facilities; as opposed to new stuff like “use VFP instead of FPE²” or “LOCAL variables like BASIC”…

² Although this really needs done as well, as IIRC all ‘real’ variables use FP ops, and with FPE it’s going to hurt.

BASIC weirdness?

I was looking up the syntax to COLOUR OF … ON … to make sure I wrote it down correctly, and I could only see “COLOR” listed. Then I looked back and saw it before CALL. And looking forward, CIRCLE is between COUNT and CRUNCH and COLOR follows CRUNCH. Glancing around, I see WAIT following WHEN, too. RAD after RUN but before RESTORE…

What’s the logic here? Isn’t this list supposed to be alphabetic?

Isn’t this list supposed to be alphabetic?

The order is as in the keyword table within the BASIC module at &EF20 in BBC BASIC V 1.62 (28 May 2016).

In castle.RiscOS.Sources.Programmer.BASIC.s.Lexical at line 584, see “lexical tokens and name table”, and at line 596, “;this table MUST be alphabetic in first char”

When RC15 does appear, I think one really useful utility will be to update a disc image that is based on the RC14 SD card image to the latest RC15 image (similar to the Update packages to update the ROM and firmware, stable builds in all but name).

It will need to change those files that have changed, make a backup copy of !Boot, only update SparkFS if the user still has the read-only version etc etc. One way would be to copy !Boot to !BootOld, delete !Bootold.Loader, make a new !Boot excluding !Boot.Loader, then merge !BootOld onto the new !Boot and copy the new firmware into !Boot.Loader.

In castle.RiscOS.Sources.Programmer.BASIC.s.Lexical at line 584, see “lexical tokens and name table”, and at line 596, “;this table MUST be alphabetic in first char”

No specific exclusion of further alphabetic sorting for 2nd or 3rd character though.
Would it be a good idea to do a lower level sort?

No specific exclusion of further alphabetic sorting for 2nd or 3rd character though.
Would it be a good idea to do a lower level sort?

Only if the code can be changed to make use of it! Currently it is only indexed on the first character (see INDEXTAB) – after that is scans sequentially. So there may be more sense in ordering it within the first letter with most used first. But the abbreviations available also seem implicated in the search, so I suspect that also affects the order. Any changes to the tokenisation could be very dangerous!!

I am sure the ordering was deliberate so that frquently used keywords would have simpler shortcuts (like P. = PRINT) and be found more quickly.

An idea for RCxx distribution:
To use your RPi for anything realistic an SD card >2Gb is unavoidable. The current method involves unpacking a 2Gb image, which takes a lot of time, writing 2 Gb to SD-card – even more time – formatting a second, big, SD-card, using !Systemdisc, and copying the image contents to the formatted SD card.
To try out if this idea worked, I formatted only a small part of an 8 Gb SD-card and applied !Systemdisc. Then wrote !Boot inc. Loader, and Utilities – only Hform and !Systemdisc, read-only SparkFS and harddisc4-zip on it. Started up Pi with this new SD. Created a RAMdisc 120 Mb, transferred everything there, clicked RAM::System and !Scrap. Started up Hform from RAM::Utilites, formatted sd-card to maximum size, ran !Systemdisc, unpacked harddisc4 to freshly formatted card, copied Loadeer contents and reset. It worked.
The idea is to distribute a small Riscos image, 120 Mb is enough, with minimal !Boot, RCxxcontents/zip, SparkFS, and modified/crippled Hform with Systemdisc capabilities. Hform creates the RAM disc, copies everything, sets System and Scrap paths, formats sd-card and creates !Boot.Loader directory + partition, unpacks RCxxcontents/zip to sdcard. Then resets.
Advantage: Burning the sd-card is a lot faster because the image is minute and you only need the target SD-card. It might be a charged download as !Systemdisc isn’t freeware, but extra needed SD cards are not free either.

An idea for RCxx distribution:
…

I see where you are coming from, but !SystemDisc is commercial software. AIUI the income from which enables the author to do other unpaid RISC OS work. Like supporting each new variant of Pi (three last year).