RISC OS on Raspberry 3

Hello :)
I’ll get a raspberry pi 3 but I wonder how RISC Works on the new PI 3.

RISC works 100% in raspberry pi 3 and will get Wifi support?

It’s not 100% yet. You’ll need to set up your SD card manually (separate firmware, ROM and HD4 image) and then may run into compatibility issues (for example, some apps built with GCC will crash). There should be an official release at some point that simplifies everything, but it’s not yet available.

There is currently no Wi-Fi support.

ok, thank you :)
I will get a PI 3 now and waiting for new version of the risc ok.

Remember that RISC OS can’t (yet) use the extra cores of a Pi2 or 3 and is so compact it doesn’t really benefit from the increased memory either, so if you have an original Pi1 lying around put RISC OS on that! It is also slightly more compatible with old software.

I’ve manually set up my microSD card and got RISC OS 5.23 (18-Apr-2016) working on my Raspberry Pi 3, but when I press Ctrl/F12 to open the Taskwindow it crashes with the error:

Internal error: Undefined instruction at &000080C4

*where (at the F12 prompt) gives:
Address &000080C4 is at offset &000000C4 in application memory.

!RiscOSM mapping certainly displays nice and quickly anyway.

Are you using StrongEd? If so do you have the taskwindow mode installed. I recently tried the latest test stronged with a new !StrED_cfg and that gave an error when opening a taskwindow – can’t remember if it was the same error as yours. Installing the taskwindow mode apparently fixes it.

when I press Ctrl/F12 to open the Taskwindow it crashes with the error:

Did you have a TaskWindow server (Edit, SrcEdit, StrongED or Zap) running?

If not, what’s the output of *Show TaskWindow$Server ?

can’t remember if it was the same error as yours.

A missing TaskWindow mode in StrongED causes a branch-through-zero so that’s not the same as the reported error which is in application space.

I use Zap 1.48 (12 Jul 2015) tnk-11
*Show TaskWindow$Server gives:
TaskWindow$Server : SDFS::RISCOSpi.$.Apps.!Zap

Internal error: Undefined instruction at &000080C4

*where (at the F12 prompt) gives:
Address &000080C4 is at offset &000000C4 in application memory.

I can confirm the above bug on a Raspberry Pi Mk 3 running the same version of Zap. It is a first time around thing, once Zap is on the iconbar CTRL-F12 seems good.

I haven’t tried an RPi2 but there is no such problem on the Titanium.

When using the same microSD card in a Raspberry Pi 2, I don’t get the Ctrl/F12 Zap problem. It only goes wrong on a Raspberry Pi 3.

It is a first time around thing, once Zap is on the iconbar CTRL-F12 seems good.

This suggests that the error is in the ZapTW mode, specifically the TaskWindow absolute which is tied to Alias$TaskWindow. A quick look suggests that it hasn’t been 32-bitted, there’s still MOVS PC,LR and LDMFD {}^ inside it.

Begs the question why it hasn’t caused problems earlier.

On the RPi3 Zap will not open an Obey file :-

*where
Address &203E256A is at offset &00000256 in module 'ZapObey'
*

Plus there is no shortage of Pain.

StrongED, the editor of choice here, seems OK on the RPi3.

Begs the question why it hasn’t caused problems earlier.

I think these instructions the way they’re being used falls into “undefined behaviour” category. Some processors will deal with them better than others.
Does it not fail on the OMAP as well?

I think these instructions the way they’re being used falls into “undefined behaviour” category. Some processors will deal with them better than others.

Correct, but as there are a number of different SOCs in use these days one would have expected at least one of them to fail. It seems though that the ARMv7 ones are okay, but that ARMv8 is not.

Does it not fail on the OMAP as well?

I’ll try that later on, at the moment I’m working a solution for the StrongED TaskWindow problem that Colin reported.

I think these instructions the way they’re being used falls into “undefined behaviour” category

Starting with ARMv7 “undefined behaviour” instructions started being reported as “undefined instruction”. I suspect MOVS PC, R14 issued in USER mode on ARMv8 may trigger this behaviour.

LDR R0, [R0], #0 is a good example of an “undefined instruction” from ARMv7 onward.

LDR R0, [R0], #0 is a good example of an “undefined instruction” from ARMv7 onward.

Is LDR R0, [R0], #0 any different to LDR R0, [R0, #0]?
I know it is specifying a writeback, but it is zero, so aren’t the results the same?
Or does the processor treat it differently regardless because of the implied writeback? I guess if it actually does try to write back…umm…?

Is LDR R0, [R0], #0 any different to LDR R0, [R0, #0]?

Prior to ARMv7 they were interchangeable, the implied writeback is now frowned upon. Essentially any instruction that has the possibility of unpredictability will now (implementation defined of course) trigger an “undefined instruction”.

According to the very carefully written pseudocode (written by the inimitable David Seal) in the last version of the ARM ARM that I was involved with (DDI 0406B, issued April 2008, a few months after I retired), LDR R0, [R0], #0 should never have been unpredictable – the writeback should occur before the loaded data is put into R0, which then overwrites the written-back address. Whether implementations actually did that is another question, of course – it is after all a completely pointless instruction (which could therefore theoretically be available for future shoehorned-in extra instructions…but what a tortuous sliver of extra instruction set space it is!)

LDR R0, [R0], #0 should never have been unpredictable – the writeback should occur before the loaded data is put into R0, which then overwrites the written-back address.

Indeed, and LDR R0, [R0, #0]! performs the writeback after the load from Rn+< immed >

It’s not supposed to:

if ConditionPassed() then
EncodingSpecificOperations();
    offset_addr = if add then (R[n] + imm32) else (R[n] - imm32); 
    address = if index then offset_addr else R[n];
    data = MemU[address,4];
    if wback then R[n] = offset_addr;
    if t == 15 then
        if address<1:0> == '00' then LoadWritePC(data); else UNPREDICTABLE; 
    elsif UnalignedSupport() || address<1:0> == '00' then
        R[t] = data;
    else // Can only apply before ARMv7
        R[t] = ROR(data, 8*UInt(address<1:0>));

Of course with post-indexing the address used is what’s in the register initially, not the updated value – but the updated value is still written to the register before the loaded data is stored to the register, overwriting the written-back value if it’s the same register. Theoretically…very possibly not in real implementations (although that’s actually wrong according to the spec), but it’s not a useful instruction anyway so it really doesn’t matter.

Just use ’bc. ’ at the beginning of the first line instead of ’bq. ’

Thanks Colin!

Should have explained it better. It modifies Rn after the load has been performed from Rn + < immed >, where the post versions modifies Rn before the load is performed.

I figured this out whilst getting the protection in one of the Eterna games working, it was reliant on the behavioural difference between the two versions.

I can’t imagine why you’d use writeback if you’re using the same register for the data and the address, and the order of writing to the registers is unimportant if they’re different registers.

Obviously it’s important whether the indexing is done before or after the address goes onto the bus! That’s the whole point of pre- or post-indexing.