Pine A64

Just been notified of this via Facebook:

Pine A64

Of course it is 64 Bit so…

Looks interesting. It’s a pity that they have a number of inaccuracies in the comparison with the PI: Number of GPU cores, SD card maximum capacity. Maybe more!

I just got wind of this from a friend – it does look very interesting, doesn’t it! Even if (as seems likely) any port of RISC OS to it only uses one of its cores and 32 bit data, the extra RAM and ability to drive a 4K screen (I’ve recently acquired a 43" 4K for my Mac, and it’s wonderful) would make a huge difference.

Is it realistic to hope for RISC OS for it, do you think?

Is the 32bit compatibility mode of the v8arch cpu’s, mean that the kernel has to be 64bit and the apps can still be 32bit or can we start with an entirely 32bit port then gradually add 64bit parts with fully 32bit apps running in there own 32bit address spaces(one per app), with 32bit and 64bit modules?

Whilst this is definately intriguing given the price, my fear is that the challenges involved in 64bit and software compatibility makes this more of accademic interest than practical. To answer Clive Semmens’ point, I’d comment that we already have 4k resolution, extra RAM, and SATA disc support in i.MX6, which is fully compatible with existing software. Granted it is rather more expensive, but from a RISC OS enthusiast perspeective, it is already here, and has been for a year.

Of course, with that said, it is important that we keep an eye on “the next big thing” to follow Pi, as RISC OS has benefited from the exposure that brought. I just worry that 64bit represents a huge change, at a time when we still struggle with existing software :(

Could be an interesting side project for somebody; but I don’t think the existence of 64 bit ARM means the end of 32 bit. There is still going to be a need for that, for devices where 16 bit microcontrollers are insufficient but 64 bit would be overkill and/or too expensive in design terms. Think of the majority of cheaper phones, tablets, domestic routers, etc etc.

Is it realistic to hope for RISC OS for it, do you think?

Only if you feel like porting it yourself – with 8 platforms to support, 4 of which are yet to reach stable, I think the OS developers already have enough on their plate (I know I do!). It would be nice to have the time to improve support for what we’ve currently got, rather than constantly rushing towards the latest new thing.

Plus, although there is a public manual for the SoC, it’s little more than a list of register fields, which means it’s basically useless when it comes to using it as a reference for writing drivers from scratch. It would be much better to wait for a chip with decent documentation (perhaps one of the ones from http://www.96boards.org – I haven’t really checked what their docs are like, see above re: too many platforms).

Is the 32bit compatibility mode of the v8arch cpu’s, mean that the kernel has to be 64bit and the apps can still be 32bit or can we start with an entirely 32bit port then gradually add 64bit parts with fully 32bit apps running in there own 32bit address spaces(one per app), with 32bit and 64bit modules?

I believe the 32bit compatibility mode will allow the kernel + OS to be 32bit. There might have to be a small amount of 64bit code (e.g. startup code in the HAL), but once you get into a 32bit execution mode it should be pretty similar to an ARMv7 CPU.

There’s an introduction on porting code to ARM 64-bit here.

I think porting the OS to a new platform is beyond my capabilities, sadly. I’m very grateful to those who’ve given me RISCOS on my Pi!

I’ve been out of this loop for a while – didn’t know about the i.MX6. How much more expensive? Which board(s) are known to work with RiscOS (I see some of them are reasonably affordable), and how easy is it to get RISC OS up and running?

Which board(s) are known to work with RiscOS

As far as I know, it works with the Wandboard Quad and adds the advantage of fast SATA support, which is only available on the Wandboard Quad iMX6 board. The version of RISC OS that runs on it is not currently openly available from ROOL, but is available from R-Comp, usually with a kit of parts to build up a computer. I seem to recollect that it will be made freely available in the future, but I have no idea when that’s scheduled. Andrew at R-Comp will be able to tell you more about it.

Wandboard Quads occasionally pop up on eBay for about £60, and are about £100 new. But not much use without access to the RISC OS port from R-Comp.

Wandboard Quad iMX6 board. The version of RISC OS that runs on it is not currently openly available from ROOL, but is available from R-Comp, usually with a kit of parts to build up a computer. I seem to recollect that it will be made freely available in the future, but I have no idea when that’s scheduled.

Two years has been quoted for that – 2nd para.

I’ve been out of this loop for a while – didn’t know about the i.MX6

In that case I feel obliged to point out that there’s also CJE’s IGEPv5-based ‘RapidO Ig’, and the home-grown Titanium. Like the ARMX6 they both have 2GB of RAM, SATA, and plenty of CPU horsepower. Unfortunately I think hardware limitations mean that the ARMX6 is the only one that can do 4K resolutions properly. But if you look at the hardware features which we aren’t yet using then you’ll see that there’s the possibility of 4GB of RAM support on the IGEPv5 (which would also help with any future ports to ARMv8 devices), dual monitor support on Titanium (+ back-ports to other machines like the Pandaboard and Iyonix, or multi-monitor “for everyone” via USB DisplayLink devices), better media playback via use of hardware overlays (benefits everything except IOMD and Iyonix), and of course the holy grail of multi-core support (over 50% of the platforms the OS supports have multiple cores!)

So, as I said, plenty of room for improvement with the existing platforms before we start looking for new hardware to sink a few thousand man-hours into developing a port for.

Fair enough. Sadly, £498 is way beyond my budget (£299 for the 4K telly for the Mac nearly cleaned me out) – but it’s the 4K support I’d really appreciate anyway. Faster processor and more RAM would be nice, but not so important to me. I’ll stick with my original Pi for the moment!

It would also be fairer if advocates for the non-religious and for secularism got to appoint equivalent numbers of their nominees. Afterall, roughly have the nation is non-religious.

To that end, I had a customer (a non-technical user) at work the other day say to me that they wished “the developers” (whoever ‘they’ might be) would stop porting the OS to more and more different platforms and instead concentrate on getting more useful software running on the platforms we already have. I can certainly see some merit in his argument – “it’s no point having RISC OS running on 10 different boards if you still have to switch to Windows to do something such as edit a photo or do your online banking”

they wished “the developers” (whoever ‘they’ might be) would stop porting the OS to more and more different platforms and instead concentrate on getting more useful software running on the platforms we already have.

#DUCKS DOWN#

I concur. My increasing use of QupZilla/Otter is still outweighed by the amount of times I RDP into a Windows or Linux machine to do something I can’t do on RISC OS (especially cloud storage – I’d love a GUI DropBox client for RISC OS, but for now have to LanMan into Windows). And I also think (as a non-developer/non-coder but merely a consumer of RISC OS) that we should all stop pandering to those insistent on running twenty year old machines, of which I have several, by expending efforts making software and OS developments compatible with RiscPCs, A7000s and earlier. I’d rather, as Andrew and Jeffrey said, we improved the platform for more modern hardware, including the unfortunate need to reinvent some of Justin Fletcher’s developments of a decade or so ago.

It’s not like some of the newer hardware is breaking many banks, is it?

#REMAINS DUCKED DOWN#

It’s not like some of the newer hardware is breaking many banks, is it?

Indeed. I love my Pi, but I don’t really care that it doesn’t run everything I can run on the Mac. It runs things I don’t have for the Mac, and it runs my own little apps that I can write easily that would be a right pain to write for the Mac (impossible for me, in fact).

I’d love to be able to use the 4K screen I have for the Mac with RISC OS as well (at more than 1920×1200), but it ain’t worth breaking the bank to achieve it.

Jeffrey:

4 of which are yet to reach stable

How do you define “stable”? Toolbox has bugs, USB has bugs, GraphicsV is evolving… there are always going to be things that will be “broken” or “in course of…”, so how does one define “stable”?

Andrew:

they wished “the developers” (whoever ‘they’ might be) would stop porting the OS to more and more different platforms and instead concentrate on getting more useful software running on the platforms we already have

You might like to point out that the “developers” that are maintaining / porting the OS are not the same as those who create software.
You might also like to point out that creating a big impressive product takes a lot of time for a remarkably small market. This means it is likely to carry a price tag if it isn’t being done for altruism or as a labour of love.
And finally, point out that RISC OS’ architecture is nothing like Linux, so quick and easy ports of the popular things (Thunderbird, The Gimp, etc) are not quite as “easy” as downloading the sources and "make"ing the application. Perhaps in time as a side effect of the WebKit browser work, we may have an “alien” UI library (Qt or somesuch) that can aid in porting work, but for now, it’s more difficult.

“it’s no point having RISC OS running on 10 different boards if you still have to switch to Windows to do something such as edit a photo or do your online banking”

Fair point – but for a lot of my needs I pick the platform that is most applicable for getting what I want done, done. AudioGrabber on the PC for ripping that old MeatLoaf CD (direct rip to MP3 with ID3 tags, quick and simple). Checking my mail? The tablet can deal with that. Downloading HaruChika? That needs IRC with XDCC support – often I use AndroIRC and leave it running while the phone charges…

RISC OS is pretty far behind the curve in some respects, so that while it is nice to hope, it is more practical to use something else for the things RISC OS can’t do.

As for online banking…hehe…don’t get me started.

andym:

that we should all stop pandering to those insistent on running twenty year old machines,

;-) When I write software, if I need to use a feature that is present and easy in RISC OS 5, or convoluted and painful in earlier versions, I’ll use the RISC OS 5 method. If this makes my software incompatible with a near-20-year-old OS, then, you know, tough.

I think we should support the older machines when it is practicable to do so, but now when it impedes future development. After all, there is a version of RISC OS 5 for RiscPC class machines…

including the unfortunate need to reinvent some of Justin Fletcher’s developments of a decade or so ago.

Indeed. But enough time has passed and hardware has evolved enough that when it comes to doing the work (whatever it may be from instance to instance) that when it comes to developing an API, we should design one that suits our use cases, and not “copying what ROLtd did”.
I can hear the backbenchers shouting about incompatibilities. Well, gee, let’s see… Anything that touches GraphicsV? Pretty much the entire USB stack?
It’s about time we accept that there is this other branch of RISC OS that did wonderful things and then died. Write a nice eulogy. And then move on.
This is the version that is being developed. None of the other versions of RISC OS matter. What matters is right here. Some people will not accept that, just like some people are absolutely refusing to accept systemd. Fair enough, it’s their choice. But everything else marches on regardless. So should RISC OS 5.

It’s not like some of the newer hardware is breaking many banks, is it?

Some of the hardware is extremely cheap. And some is not. At least we have a spread of price brackets, so there ought to be a machine for everybody.

As for the 64 bit hardware – the obvious question is “what does this bring us?”. It can address more than 4GiB? Fair enough, but there was a Large Address Thingummy that allows 32 bit ARM to do the same thing. Pretty much the only benefit that I can determine is that a lot of the instruction set has been streamlined (again) so we might get a small performance boost from using a 64 bit processor in 32 bit mode – but whether it is worth the effort or not, I don’t know.
The biggest issue, 32 bit processors have 15 general purpose registers that are 32 bits wide (R0-R14), the 64 bit incarnation offers 31 general purpose registers that are 64 bits wide. Which will have exactly zero relevance to huge swathes of RISC OS’s internals that were written with the 32 bit architecture in mind and wouldn’t touch those extra registers even if they existed. In fact, if PC is no longer R15 and LR is no longer R14 and SP is no longer R13; expect most of RISC OS to break (unless it is run in 32 bit mode).
With this in mind, while it is great to say “oooh, shiny!” at the 64 bit hardware, I do have to question if it actually brings any benefit.

Wow. Quite a lot of this doesn’t even look like ARM code…

https://community.arm.com/docs/DOC-8453

Consider this:

func smc_handler64
	mov	x30, #BL1_SMC_RUN_IMAGE
	cmp	x30, x0
	b.ne	smc_handler

	mrs	x30, scr_el3
	tst	x30, #SCR_NS_BIT
	b.ne	unexpected_sync_exception

	ldr	x30, [sp, #CTX_EL3STATE_OFFSET + CTX_RUNTIME_SP]
	msr	spsel, #0
	mov	sp, x30

	mov	x20, x1

	mov	x0, x20
	bl	bl1_print_bl31_ep_info

	ldp	x0, x1, [x20, #ENTRY_POINT_INFO_PC_OFFSET]
	msr	elr_el3, x0
	msr	spsr_el3, x1
	ubfx	x0, x1, #MODE_EL_SHIFT, #2
	cmp	x0, #MODE_EL3
	b.ne	unexpected_sync_exception

	bl	disable_mmu_icache_el3
	tlbi	alle3

	mov	x0, x20
	bl	bl1_plat_prepare_exit

	ldp	x6, x7, [x20, #(ENTRY_POINT_INFO_ARGS_OFFSET + 0x30)]
	ldp	x4, x5, [x20, #(ENTRY_POINT_INFO_ARGS_OFFSET + 0x20)]
	ldp	x2, x3, [x20, #(ENTRY_POINT_INFO_ARGS_OFFSET + 0x10)]
	ldp	x0, x1, [x20, #(ENTRY_POINT_INFO_ARGS_OFFSET + 0x0)]
	eret
endfunc smc_handler64

[taken from https://github.com/ARM-software/arm-trusted-firmware/blob/master/bl1/aarch64/bl1_exceptions.S with comments removed for size]

Yep, 64bit seems to be the place to be. But, IMHO, it’s not for RISC OS.

Coolness could be on the embedded side, with a possible port on some microcontroller, or a true Open Hardware computer with an Amber Core on Mist and some IOMD/VIDC20 like hardware (a kind of RPC+).

Both would be great :)

Jeffrey:

4 of which are yet to reach stable

How do you define “stable”? Toolbox has bugs, USB has bugs, GraphicsV is evolving… there are always going to be things that will be “broken” or “in course of…”, so how does one define “stable”?

An even-numbered ROM available from ROOL’s downloads page (or I guess from R-Comp/CJE).

https://www.riscosopen.org/news/articles/2010/01/23/new-iyonix-rom-release-version-5-16

OK, that page doesn’t exactly mention that the ROMs are going to be stable, just that they’re “official” and “tested” – but “stable” is what we want them to be. A stable (non-changing) system for application developers to target (unlike development builds which can have APIs modified and then reverted the day after without any warning), and a stable OS for users to be using. Plus a certain expectation that there the core hardware drivers (audio, video, storage, USB, networking, CPU, etc.) are all present and provide a reasonable level of functionality.

To that end, I had a customer (a non-technical user) at work the other day say to me that they wished “the developers” (whoever ‘they’ might be) would stop porting the OS to more and more different platforms and instead concentrate on getting more useful software running on the platforms we already have. I can certainly see some merit in his argument – “it’s no point having RISC OS running on 10 different boards if you still have to switch to Windows to do something such as edit a photo or do your online banking”

I assume that you explained to your customer that “the developers” are by and large¹ volunteers, who are doing what they are doing for fun?

If someone finds porting the OS to new platforms fun, then that’s what they’re going to spend their time doing. Telling them that we’re short of a decent photo editing package isn’t necessarily going to make developing one fun in their eyes, and if it doesn’t, then forcing them to work on such a project isn’t going to suddenly make them spend time working on it. In fact, they will probably spend less time on RISC OS as a result.

Bounties are one possible option, but speaking personally adding money to the equation is a disincentive to work on RISC OS stuff in a ‘fun’ context. I’m fairly sure that I’m not alone in that.

I concur. My increasing use of QupZilla/Otter is still outweighed by the amount of times I RDP into a Windows or Linux machine to do something I can’t do on RISC OS (especially cloud storage – I’d love a GUI DropBox client for RISC OS, but for now have to LanMan into Windows).

I think you’re going to come back to the ‘fun’ aspect. Again personally, what I do for RISC OS is down to what interests me at the time when I’m doing it. At present, that’s fixing stuff that I bodged ten or twenty years ago when I didn’t know any better – isn’t bringing you new features to any of my software (yet), but it might make it easier to add things in the future. You might also get some developer tutorial stuff falling out of it, too – time permitting.

I get the impression from shows that a lot of users ‘wish’ that I was still working on NetSurf. That ceased to be ‘fun’ when I realised that I had not had time to touch any of my own code for around eighteen months – while all of the other active RISC OS developers capable of working on the browser had presumably given a big sigh of relief when I’d stepped forward, and were still working on their own ‘fun’ things².

Since then, we’ve had a number of people say that they would like to help, only to walk away after I’ve spent time guiding them through the RISC OS code. I’ll admit that the situation does seem to have changed in the past few months, and I’ve not ruled out getting back involved once I’m sure that I won’t be the only RISC OS developer who’s ignoring my own projects to work on our platform’s front-end.

…as a non-developer/non-coder but merely a consumer of RISC OS…

I think there could be another problem here. RISC OS is no longer really a commercial platform, and the reality is that everyone needs to contribute with their time if we’re going to get anywhere. “But I’m not a programmer”, you say (that’s “you” in the general sense – not specifically andym)? Well, no, but that’s not an excuse: there are plenty of other things that users can do.

Again, I’ve not really done any software development for over a year: I can remember talking to Jim Nagel in the bar of the Webbington Hotel last February and saying that I’d been working on non-development things for a few months, and it hasn’t really changed since then. In fact I can’t release the ZeroPain fixed versions of CashBook and Locate that I have here because work that I started on my shared library code last spring still hasn’t been finished and as a result neither application will load files properly. I could port the ZeroPain fixes back to a 2014 vintage of the code, but that would take as much time as just finishing the library³ – and it’s time that I don’t seem to have.

It’s true that I’m fairly busy with things that don’t involve computers, but a lot of my “RISC OS time” is actually spent writing copy for the Wakefield Club’s monthly⁴ newsletter. Over the past twelve months we’ve published 116 A5 pages of material, but from a Club of 70 or so RISC OS users, that material represented only nine authors. Worse still, 94% of the content was written by just four people, and I wrote (or ghost wrote) around two thirds of the total. Yet people ask why I’ve not had any new software to demonstrate at shows since the end of 2014!

Given that I’d actually like to update my software, this situation seems crazy.

If you’re a non-developer, there’s still plenty of stuff that you can do to help out. Test software, write or critique⁵ documentation, or just write material for your favourite RISC OS magazine, newsletter or news website. You don’t have to be technical to do any of this stuff, and in fact it’s often an advantage if you’re not. Wearing my WROCC Editor’s hat, it’s often easier to correct an article written by someone else for technical accuracy than it is to write the same thing from scratch, and I’d imagine that’s true of most editors, manual writers and the like.

If all of that still sounds too technical, then there are yet more things that need volunteers. Everyone wants the platform’s shows to continue, yet the people doing the organising work to make them happen are often the same people who should be developing hardware and software to bring to those same shows. We’re often trying to juggle the administration around our day jobs and other hobbies, too.

That’s turned into rather more of a rant than I’d intended it to be, but the bottom line is that the RISC OS market isn’t really the same now as it was in Acorn’s day. You can’t just pass money to CJE or R-Comp⁶ and expect everything to be hunky-dory. You need to be offering your time as well: if not for hardware or software development, then for doing the more mundane things that people like myself are doing for you so that we can then get on with doing that development.

Either that, or we need to accept that the platform isn’t going to go anywhere at all.

¹ I’m not sure of the status of the likes of John B and the ARMX6, but whatever it is, I can’t imagine that the RISC OS market can afford to pay industry rates.

² The other problem with NetSurf has been the changes to version control and the build system that have occurred since I was last actively working on it. Git’s a steep learning curve, and the switch from using the same version of the GCCSDK that I have installed for my own development work to a clone of the one on the NetSurf team’s build server is going to need a fair bit of time to get my head around. At present I can’t even build the browser from source on my own machine – let alone fix simple bugs and test the results.

³ The big problem with CashBook is that what time I have had to work on it has been spent making some very big structural changes to its innards to modularise the code into the way that it should have been written all along. As a result, the code that has been ZeroPain-fixed bears little or no resemblance to that which was in the last stable release.

⁴ Ahem.

⁵ The latter is actually just as important as the former, and still a massive time-saver for developers.

⁶ Other companies are available⁷.

⁷ Probably.

a lot of my “RISC OS time” is actually spent writing copy for the Wakefield Club’s monthly4 newsletter. Over the past twelve months we’ve published 116 A5 pages of material, but from a Club of 70 or so RISC OS users, that material represented only nine authors. Worse still, 94% of the content was written by just four people, and I wrote (or ghost wrote) around two thirds of the total.

Join any voluntary organisation and get actively involved and you soon notice that you’re one of a very low percentage that actually do anything much.
I used to edit the local CAMRA newsletter, as well as providing 90% of the content. I was always grateful for the contributions of those other few.
As ever, those that do something get tagged to do more, and more, and more and…

The big thing is it has to be fun, whatever your personal definition of fun is.

Join any voluntary organisation and get actively involved and you soon notice that you’re one of a very low percentage that actually do anything much.

Oh, yes – I’m well aware of that! It will be no surprise to know that it’s also true of the amateur theatre world, at least away from the brightly-lit bits…

The big thing is it has to be fun, whatever your personal definition of fun is.

Indeed. I’m not really expecting anything to change (although one can always hope).

However, I think that’s it’s important for those complaining that the developers aren’t working on the right things to understand the situation. People are then free to choose to continue to not get involved, but I don’t think they can complain (as Andrew’s “customer” was up thread) about the direction that developments take.

However, I think that’s it’s important for those complaining that the developers aren’t working on the right things to understand the situation. People are then free to choose to continue to not get involved, but I don’t think they can complain (as Andrew’s “customer” was up thread) about the direction that developments take.

Indeed, I regularly have to explain this to our customers (note, no quotes around customer necessary, these are real individuals who’s names I’m not prepared to post on here for obvious reasons). They are always pointed towards the ROOL forums and/or the various software mailing lists/bug trackers depending on the nature of their comment. However, if R-Comp or CJE were to make “getting involved” a pre-condition of selling a system to a customer, then I suspect that they would both go out of business before the end of the year!

In my personal and private opinion (which is independent of that of my employer) then if we as developers (since I too write software in my spare time) aren’t at least prepared to listen to what users want or have to say, we’ll end up with no-one left to develop for!

Steve Fryatt wrote:

I get the impression from shows that a lot of users ‘wish’ that I was still working on NetSurf. That ceased to be ‘fun’ when I realised that I had not had time to touch any of my own code for around eighteen months – while all of the other active RISC OS developers capable of working on the browser had presumably given a big sigh of relief when I’d stepped forward, and were still working on their own ‘fun’ things.

For my part, I’m really grateful for the work you managed to do on the RISC OS bits of NetSurf. Especially when you sorted out the RISC OS code to handle the core treeviews change; that was nearly the end of the RISC OS front end.

Since then, we’ve had a number of people say that they would like to help, only to walk away after I’ve spent time guiding them through the RISC OS code. I’ll admit that the situation does seem to have changed in the past few months, and I’ve not ruled out getting back involved once I’m sure that I won’t be the only RISC OS developer who’s ignoring my own projects to work on our platform’s front-end.

The core developers are still plodding along, improving things for all platforms. :)

The other problem with NetSurf has been the changes to version control and the build system that have occurred since I was last actively working on it.

That’s a shame if we’ve thwarted you! It was unintentional. :)

Git’s a steep learning curve

Yes it is. You’re welcome to get in touch directly or via the mailing lists if you need any help.

and the switch from using the same version of the GCCSDK that I have installed for my own development work to a clone of the one on the NetSurf team’s build server is going to need a fair bit of time to get my head around.

We recently upgraded to the GCCSDK 4.7.4v2 release. That was because the previous version had a UnixLib bug that caused it to close the wrong file descriptors in some circumstances.

At present I can’t even build the browser from source on my own machine – let alone fix simple bugs and test the results.

Please get in touch if you need help. It shouldn’t be too hard for us to get it working again.