Pinephone

First off, I know RiscOS is not a mobile OS, but considering how well RiscOS runs on something like the original Pi, if RiscOS did have a mobile version it could run great on something like the Pinephone. I imagine a lot faster/more efficient than anything else being designed for the phone. Opinions? Thoughts? Would it ever happen?

As a phone OS – too many functions with no support under RO.

Of course if you’re in the Pinebook market then just look at the ARMBook¹ from R-Comp.

¹ I made a throw away comment about the “ARMBook” when the project was unnamed and it may be coincidence but that was the assigned name. It has a variant with only one “o” due to a typo I believe.

The only thing on the RISC OS “pro” side is its tiny footprint. All other things are severe disadvantages, including but not limited to

1. no security
2. no WLAN
3. no bluetooth
4. no GPS
5. no drivers for mobile 3G/4G/5G data/speech modem chips
6. no sensible idea how to be usable on a touchscreen, no even a screen keyboard
7. no apps
8. no capable browser
9. no efficient decoders for video (usage of hardware acceleration)

No GPS:
what about SatNav which sends messages giving current location. RiscOSM receives the messages and provides a moving map display.

Not to forget ComCentre… ;-)

Look at PiGeek …

what about SatNav

We’re talking about an internal GPS unit as is found in many phones.

including but not limited to

1. No concept of processes so anything designed to run “in the background” is likely to need to be a module running with kernel level privilege.
2. A cooperative desktop which could be a problem if something hangs up on a mobile device using a soft keyboard.
3. Practically zero memory protection. The OS was designed in a time when it wasn’t a terrible thing to grab a copy of another application’s workspace, or for user tasks to write to system workspace.
4. No security model whatsoever. One SWI can elevate you to SVC mode which means you can basically do whatever you like with the entire system.

This degree of flexibility does have some benefits, however using the system as a mobile OS really isn’t one of them!

My guess it it would take a lot of effort to get it even a basic phone that will also do texting to work.

However, having done that perhaps you could play Lander on it? ;)

a lot of effort

Not sure. The Pinephone is basically a Pine64 inside a phone. And the port already exists for the Pinebook. The communication work (calls, SMS, MMS, 3G/4G) is done by an independent modem, drived only by AT commands (even for voice calls). The documentation of this modem is public.

See there: https://www.riscosopen.org/forum/forums/1/topics/15156

@David, heck even if it could be a self powered portable RiscOS desktop for people who travel a lot. You could theoretically plug it into a TV and if Bluetooth ever worked add a Bluetooth keyboard and mouse and could work. However, I still have this mental idea of what the OS could be like as a mobile OS, maybe I could draw up some ideas. Not a programmer though by any means so a lot of what was said prior is beyond my expertise.

1. no security
2. no WLAN
3. no bluetooth
4. no GPS
5. no drivers for mobile 3G/4G/5G data/speech modem chips
6. no sensible idea how to be usable on a touchscreen, no even a screen keyboard
7. no apps
8. no capable browser
9. no efficient decoders for video (usage of hardware acceleration)

As RISC OS only uses a single core, there is plenty of scope to run second pared down OS to do the heavy lifting on WiFi and Bluetooth stacks, and GPS and modem drivers. That would leave the RISC OS font end to provide the UI to set them up.

On onscreen keyboard shouldn’t be a problem, but obvious 1 and 7, 8 & 9 are still an issue which don’t have any shortcuts for RISC OS.

I’m hoping the Iris web browser should clear up issue 8. That’s not to say RiscOS wouldn’t work as a mobile OS in the future with the improvements the community is implementing already.

We’re talking about an internal GPS unit as is found in many phones.

So, nothing to do with RISC OS, then – you are talking about hardware.

I’m hoping the Iris web browser should clear up issue 8.

I am sure that Iris will be more powerful than existing browsers, but if it is good enough to compete with e.g. Chrome remains to be seen. It will also likely suffer from other RISC OS deficiencies like the suboptimal performance of the network stack (there was a recent discussion here on this forum about transfer speeds).

We have all kind of workaround solutions for RISC OS to cater for all kinds of deficiencies. Use RDP or VNC to browse. Use UniPrint/UniScan to make up for the lack of current printer/scanner drivers. Use Surfsticks like USB-serial modems to connect to mobile internet. Use a WiFi Ethernet bridge to access WLAN. Use a dedicated proxy machine to access cloud storage. Use a NAS box to access exFAT, NTFS and ext2/3/4 formatted media.

Some say that technique started with the Risc PC’s PC card. Some say it already started with the BBC Micro emulators. If you have one specific use case where you desperately need a solution for RISC OS, it might be OK to employ such workarounds. But try to convince a new user that the onboard WIFI is sadly not usable and that an additional piece of hardware needs to be bought. Will be an ex-user soon.

what was said prior is beyond my expertise.

Mine too :)

I am sure that Iris

I hope OWB will be updated too. It’s (a bit) less capable, but (very) very fast.

It will also likely suffer from other RISC OS

Correct. Anyway, on Pi4, it’ll do the job.
I’m waiting for the version with JIT JS.

My recent hack with running NetBSD on one core and RISC OS onthe other , can be reversed. That is let NetBSD handle most hardware and RISC OS in a window.

So in theory , could be fun to try on a pinephone… not sure if the gain is much , bit FUN!

Oh no , I need a pinephone.

Oh no , I need a pinephone.

Get one while you can, they don’t stay in stock long and buying them secondhand on eBay turns out to be more expensive. The price of shipping though, at least to the US is a little ouch…

My recent hack with running NetBSD on one core and RISC OS onthe other , can be reversed. That is let NetBSD handle most hardware and RISC OS in a window.

I’d wondered about that when I saw your announcement and discussion some months ago. I think both approaches have value in different ways, but, as you say, having access to the hardware supported by NetBSD would be wonderful.

If RISCOS is the “primary OS” it facilitates anything where low level control of hardware is beneficial – IoT, realtime applications etc.
If NetBSD is the “primary OS” we’d get to leverage not only its hardware support, but the stability and server functionality of BSD with the excellent RISCOS desktop – it seems like a natural synergy.

I wonder, could devices supported by NetBSD be presented to RISCOS via a common abstraction such that applications could use a “standard” API irrespective of whether the low level hardware was supported natively or via NetBSD?

I have a PinebookPro, currently happily running Manjaro i3, but have been thinking about putting one of the BSDs on it. If this is an activity that’d benefit from more people getting involved then I’d be delighted if I could help at all.

f RISCOS is the “primary OS” it facilitates anything where low level control of hardware is beneficial – IoT, realtime applications etc.
If NetBSD is the “primary OS” we’d get to leverage not only its hardware support, but the stability and server functionality of BSD with the excellent RISCOS desktop – it seems like a natural synergy.

The thing is that even if RISC OS is the “primary” OS , it only means that it handles gfx and user input. Probably also som kind of disc access. NetBSD have full access to the hardware, and RISC OS has it too. Remember , neither of them are emulated, they run as full systems.

Sorry, yes, I understand – it’s quite a different way of looking at things compared with the usual world of hypervisors etc. so it’s easy to fall back into thinking of it in those terms!

So if communication between the two parts is more like client/server and we’re interested in making use of NetBSD’s hardware support it makes me think of Plan9’s approach to devices… IIUC you used a block of memory accessed by both OSs? I wonder whether 9P would be useful in any way with such a shared area, even though it’s not a file as such and has different semantics?

Or more likely I’ve done the usual thing of contemplating a generalised solution to a small problem that simply makes a bigger problem :-)

To return to topic.

I think that runnning Linux port as an app is better than running full os.

Are/is there any new info/updates on the Pine phone running Linux RO?

Powering a mobile phone with RISC OS is like converting a camper van into a submarine¹, in that it’s technically possible, but isn’t really a sensible place to start.

¹ More specifically, a submarine that remains dry on the inside, and has “up” as an available direction.

Powering a mobile phone with RISC OS is like converting a camper van into a submarine

and expecting to get a signal while underwater.