Interested in an ARM-based laptop?

Aren’t tax laws fun?

In NZ there’s a $400 limit before you need to pay GST, and a further $1000 limit that requires import documentation. I once bought something that came to $999.19 on the day of import and I was worried that the official Customs exchange rate would knock it over the $1000 and cause a bunch of hassle.

Nope… and they didn’t even charge the GST on it. Go figure.

As for Andrew’s comments, fair enough. I was just muttering aloud really :)

According to the Pine64 website quoted by David Boddie, the Pinebook CPU is a 64-bit Quad-Core ARM Cortex A53. So does Andrew Rawnsley have a 64-bit version of RISC OS or am I missing something? Is there a Pine32 and is that what he is using?

The Cortex-A53 can be implemented in two execution states: AArch32 and AArch64. The AArch64 state gives the Cortex-A53 its ability to execute 64-bit applications, while the AArch32 state allows the processor to execute existing Armv7-A applications.

Plus, more importantly, the A53 can execute AArch32 code in EL0 and EL1, which to my understanding are equal to “our” user and supervisor mode.

According to the Pine64 website quoted by David Boddie, the Pinebook CPU is a 64-bit Quad-Core ARM Cortex A53. So does Andrew Rawnsley have a 64-bit version of RISC OS or am I missing something?

As Holger already explained: all(?) current 64bit ARM variants (with the possible exception of Apple’s homebrew stuff) still support the good old 32bit modes we know and need for RISC OS. Raspberry Pi 3(+) also uses Cortex-A53 and as we all know RISC OS runs just fine on it.

A small correction to Patric’s post: AArch32 is ARMv8 in these cases (no more SWP).

I think the Cortex-A76 is due to be ARM’s first (64bit) CPU that starts to drop support for 32bit modes.

https://www.riscosopen.org/forum/forums/12/topics/10172?page=2#posts-79444

But as Steffen says, I wouldn’t be surprised if Apple have been a bit more aggressive with their roadmap (IIRC they were a pretty early mainstream adopter of AArch64).

Is there any time scale on the dropping of 32bit?

With ref to the dropping of SWP -

What about a module to catch SWP,s – like shown for another ARM instruction on Adrian of Aemulor Web site?

There’s an existing utility called PatchSWP that stops apps from generating SWP instructions in the first place. While there are undoubtedly a few apps that it doesn’t work for, I think most of these have been manually patched and so I’m not sure whether we need another solution for it.

Thanks for answers, folks.

Is there any time scale on the dropping of 32bit?

Whilst I’d expect having a 32bit mode to be less likely to be included in most future 64bit CPUs. 32bit ARM CPUs will still be around long after I’m dead and probably after my children have also died.

I read recently that the number of 8bit CPUs sold last year was umpteen Billion (10 IIRC) and that sales volumes are increasing! 32bit CPUs will always draw less power and be cheaper than 64bit so they aren’t going away.

32bit CPUs will always draw less power and be cheaper than 64bit so they aren’t going away.

I dunno – 32 bit is that awkward one between the requirements of microcontrollers (8 bit will suffice in many cases) and the 64 bit requirements of modern operating systems.

I dunno – 32 bit is that awkward one between the requirements of microcontrollers (8 bit will suffice in many cases) and the 64 bit requirements of modern operating systems.

And so one day, RISC OS will work on a cheap microcontroller :) Perhaps it could already be the case.

And so one day, RISC OS will work on a cheap microcontroller :)

Doubt it. I can’t imagine there’d be much call for a microcontroller with MMU and video – such devices go inside toasters, bread makers, washing machines…

There could, of course, be a potential case for a “RISC OS like” microkernel written for Cortex-Mx class hardware. It would look a little like RISC OS (via serial port) but not be RISC OS, just sort of familiar.

Perhaps it could already be the case.

Well, the Pi Zero costs the same as a Happy Meal, so…….

There could, of course, be a potential case for a “RISC OS like” microkernel written for Cortex-Mx class hardware.

Funny you should mention that. The BBC micro:bit uses the 32-bit ARM Cortex-M0+ microcontroller. One could start with an Assembler (like Sprow has done under RISC OS for 8-bit PIC microcontrollers).

Doubt it. I can’t imagine there’d be much call for a microcontroller with MMU and video – such devices go inside toasters, bread makers, washing machines…

Not only. Basically, some SOC are equal to microcontrollers.
And anyway, perhaps that MMU could be optionally forgotten for RISC OS. Then all becomes possible.

Basically, some SOC are equal to microcontrollers.

RISC OS is really ‘best’ with some sort of video output – it doesn’t natively support stty like Unix. I can’t think of many microcontrollers with video support. Remember, it isn’t just the actual video signal generation, it’s a frame buffer to hold the video data. For something that’ll be familiar to you, think of the Minitel terminal. Based around a simple microcontroller, it provided a video output by having a video output chip write to its memory chip (8K XRAM). That RAM wasn’t connected to the main processor, and the main processor only had a tiny amount of memory onboard (256 bytes). Why? Because for the sorts of applications microcontrollers typically inhabit, there’s no need for such complications. Like I said, think of washing machines and breadmakers…

And anyway, perhaps that MMU could be optionally forgotten for RISC OS.

Then it wouldn’t be RISC OS.

Every processor has a defined “start” address. Many modern processors start execution at address zero. Some old school ones (like the 6502) read the start address from a specific location at the end of addressable memory. This places constraints on where things can be. The operating system on any 6502 based device must be at the end so it can pick up an address from &FFFC-&FFFD (and NMI from the two bytes prior, IRQ from the two bytes following), plus some sort of RAM must be at the start as &00xx addresses have special zero page instructions, and &01xx is the stack.

Why am I talking about the 6502? Because that is what it is like without an MMU. Things live in fixed positions, and while you can have some trickery (sideways ROMS), stuff generally is at a place and that’s that.

Now to RISC OS. The ARM will begin execution at &0 which is where one would expect the ROM to be located. Well, that’s cool if you can get the OS into less than 32K and map the RAM directly afterwards. Otherwise, how will one have applications begin at &8000 like all of them assume? How will be have a module area at &20000000 which can auto-extend as necessary? Or the whole concept of WimpSlot? Dynamic Areas?

The truth is, every address you think you know under RISC OS is fakery. The MMU slices up the available RAM, ROM, and hardware into little chunks that can be rearranged as desired in order to make things “just work” for RISC OS.

From a TaskWindow:

*BASIC
>DIM m% 11
>m%!0 = 0
>m%!4 = &8000
>m%!8 = 0
>SYS "OS_Memory", ((1<<9) + (1<<13)), m%, 1
>PRINT ~m%!8
   628D000
>

Try it in a different TaskWindow, it’ll say something else, like 78F4000. What this is doing is taking the &8000 that the application thinks it is running at, and requesting the OS to say where this actually is in physical memory.

Then all becomes possible.

RISC OS needs an MMU. It had memory management right from the outset (MEMC1), and was written with this being a core part of how it operates. With no MMU, with a flat memory map, it won’t be RISC OS.

Having said all this, it is worth pointing out that a breaking change “RISC OS-like” micro OS for Cortex Mx devices is not that big a deal – we can tolerate a breaking change here as the M-family instruction set is some variation of Thumb (most likely Thumb v1 and some degree of Thumb-2), so it isn’t actually binary compatible with existing RISC OS. It is worth noting that if you go to ARM’s infocenter, you can get a document describing the available instructions in a Cortex-M core and their cycle counts – yup, in microcontroller world we’re back to the fun of counting cycles like we did in the old days. ;-)

Microcontroller != Microprocessor.
Microcontroller != SOC (usually, though quite a few have Cortex-M series secondary cores in addition to 32 or 64 bit primary cores)

The BBC micro:bit uses the 32-bit ARM Cortex-M0+ microcontroller.

Uh… just looked at that on Amazon. I know practically nothing about the micro:bit. How does one actually talk to it? It looks like it supports Bluetooth and…? Does it contain some sort of interpreter onboard (like Lua or something)? I can see references to buttons, ADCs, and a bunch of LEDs. I can’t imagine they’re teaching kids to program this thing in assembler!

Edit: Ah, it looks like it fakes being some sort of storage device. I guess that’s how one gets programs on to it. Weird online editor generates a hex file. I wonder what the hex file actually is? It looks… complicated. There’s an C runtime, an mbed SDK, a Nordic SDK, and MicroPython, and it looks like most hex files are Python scripts. Can you even push raw assembler to it? With all that stuff onboard, how much Flash is available to the user?

Edit2: Whoa, now that’s amusing. The heart of the device is a 16MHz Cortex-M0. The thingy that provides the USB interface is a 48MHz Cortex-M0+ device. ;-) So the glue is considerably more powerful than the primary processing unit. Sweet… ;-)

Edit3: All this said, the micro:bit is ~€20 on Amazon. Six € more will get me a Pi Zero starter kit. I know which is likely to be more useful in the long run. (or a mite less than 2×micro:bit for a Pi3)

I think the main thing about the micro:bit was/is that they conned the government/BBC into giving them to a bunch of school kids. Why on earth they didn’t use pi-zeros or something is anyone’s guess, because even a cursory glance would tell you which is likely to be more productive/practical. Ah well.

Then it wouldn’t be RISC OS.
Every processor has a defined “start” address.

Sorry I mean memory protection. Memory translation, etc. is probably possible on some µc today. I will need to check. Anyway, a cut down version of RISC OS ‘à la BBC MOS’, with only Basic and ARM ASM, could be fun to have.

Anyway, a cut down version of RISC OS ‘à la BBC MOS’, with only Basic and ARM ASM, could be fun to have.

Right, some sort of micro-sized OS. Or maybe even smaller. Pico-sized, perhaps…

PS, one thing which maybe wasn’t clear – you don’t have to put down deposits if you’re not comfortable with dealing with us like that. Just expressing interest at the appropriate price points is enough. I’ll try and get the PDF of the show flyer up online tomorrow.

Please forgive my ignorance (and/or enthusiasm!), but I scanned this whole thread again and again and I just couldn’t find where to do that.
Is there an actual URL where one can express interest or even pre-order? Because, a RISC OS laptop is exactly what I need :)

It seems to be the usual RISC OS way. The businesses who want to trade with RISC OS have a serious aversion to putting information online. It seems preferable to tell less than 100 people in a room, rather than the whole planet. I don’t understand it either.

It seems to be the usual RISC OS way. The businesses who want to trade with RISC OS have a serious aversion to putting information online. It seems preferable to tell less than 100 people in a room, rather than the whole planet. I don’t understand it either.

It certainly seems that way to me, too.

But then again, it’s kinda been like this since the first Archimedes came out (at least, if you’re not living in the UK). And maybe it’s just really brilliant marketing. Like maybe if I told no one where to buy our new album, people would queue up to get their hands on it…

Hey, I should try that! ;-)

That seems a bit unfair. I’m sure Andrew would be more than happy to answer any questions you might have via mail.

If he received twenty emails asking for the information surely answering them would take much longer than putting the info on the armini site?