Pi 3 bugs

I can’t see any part of the forum devoted to bugs in software running on the Raspberry-Pi 3. So here are 2 for starters.

Pinging the router in a task window (I tried StrongEd and Edit), gave one line of (successful) packet transmission and then the error message from TaskWindow, “TaskWindow may have gone wrong …..”.
I couldn’t get out of this without shutting down.
However pinging from a command line in the ShellCLI, didn’t produce any errors.

Clicking on Help in Reporter’s menu, produced a StrongHelp error message. Clicking “continue” allowed continued working, but not reporter’s StrongHelp manual.

All Reporter menu → Help does is issue a command Filer_Run <Reporter$Dir>.!Help
What is the SH error message?

Which versions of StrongED and StrongHelp are in use?

StrongED 4.69f9 (30-Jun-2016) should be okay on RPi 3.

There is a problem on the Raspberry Pi 3 that does not show up on the Titanium with Reporter’s StrongHelp.

Simply double clicking on !Reporter.HelpData.Reporter errors below.

StrongHelp   2.88a2 (05-Dec-2015)
Error from StrongHelp: Internal error: undefined instruction at &0000A22C

StrongHelp   2.87 (03-Sep-2012)
Error from StrongHelp: Internal error: undefined instruction at &0000AB20

Double clicking on the !Pre Utility within the StrongHelp crashes. No great surprise the Utility is dated 05Oct97. There is something familiar about this, the obsolete Utility and what is it for anyway.

Removing the Utility clears the fault as does finding a later version, as does purloining a later version, e.g. 08Sept12 found in InetSocket StrongHelp.

The duff !Pre is 26 bit!! We have definitely been here before, I just don’t recall the context.

05Oct97

00000000 : E92D401E : ^@-È : STMDB   R13!,{R1-R4,R14}
00000004 : E5D02000 : @ –Â : LDRB    R2,[R0,#0]
00000008 : E3520058 : X@R„ : CMP     R2,#&58            ; ="X"
0000000C : 02800001 : A@ÄB : ADDEQ   R0,R0,#1
00000010 : 08FD801E : ^ĽH : LDMEQIA R13!,{R1-R4,PC}^
00000014 : E5D02000 : @ –Â : LDRB    R2,[R0,#0]
00000018 : E3520021 : !@R„ : CMP     R2,#&21            ; ="!"
0000001C : 05D02001 : A –E : LDREQB  R2,[R0,#1]
00000020 : 03520078 : x@RC : CMPEQ   R2,#&78            ; ="x"
00000024 : 05D02002 : B –E : LDREQB  R2,[R0,#2]
00000028 : 03520032 : 2@RC : CMPEQ   R2,#&32            ; ="2"
0000002C : 05D02003 : C –E : LDREQB  R2,[R0,#3]
00000030 : 03520036 : 6@RC : CMPEQ   R2,#&36            ; ="6"
00000034 : 18FD801E : ^ĽX : LDMNEIA R13!,{R1-R4,PC}^
00000038 : E1A03000 : @0†· : MOV     R3,R0
0000003C : E1A04001 : A@†· : MOV     R4,R1
00000040 : E2801004 : DPÄ‚ : ADD     R1,R0,#4
00000044 : E3A00010 : P@†„ : MOV     R0,#&10            ; =16
00000048 : EF020021 : !@BÔ : SWI     XOS_ReadUnsigned
0000004C : 61A00003 : C@†a : MOVVS   R0,R3
00000050 : 68FD801E : ^Ľh : LDMVSIA R13!,{R1-R4,PC}^
00000054 : E1A00002 : B@†· : MOV     R0,R2
00000058 : E3C00802 : BH¿„ : BIC     R0,R0,#&00020000
0000005C : E1A01004 : DP†· : MOV     R1,R4
00000060 : E3A02040 : @ †„ : MOV     R2,#&40            ; ="@"
00000064 : EF020038 : 8@BÔ : SWI     XOS_SWINumberToString
00000068 : 61A00003 : C@†a : MOVVS   R0,R3
0000006C : 71A00001 : A@†q : MOVVC   R0,R1
00000070 : E8FD801E : ^Ä˝Ë : LDMIA   R13!,{R1-R4,PC}^
00000074 : 36327821 : !x26 : LDRCCT  R7,[R2],-R1,LSR #16
00000078 : 00000000 : @@@@ : ANDEQ   R0,R0,R0

08Sep12

00000000 : E92D401E : ^@-È : STMDB   R13!,{R1-R4,R14}
00000004 : E5D02000 : @ –Â : LDRB    R2,[R0,#0]
00000008 : E3520058 : X@R„ : CMP     R2,#&58            ; ="X"
0000000C : 02800001 : A@ÄB : ADDEQ   R0,R0,#1
00000010 : 08BD801E : ^ÄΩH : LDMEQIA R13!,{R1-R4,PC}
00000014 : E5D02000 : @ –Â : LDRB    R2,[R0,#0]
00000018 : E3520021 : !@R„ : CMP     R2,#&21            ; ="!"
0000001C : 05D02001 : A –E : LDREQB  R2,[R0,#1]
00000020 : 03520078 : x@RC : CMPEQ   R2,#&78            ; ="x"
00000024 : 05D02002 : B –E : LDREQB  R2,[R0,#2]
00000028 : 03520032 : 2@RC : CMPEQ   R2,#&32            ; ="2"
0000002C : 05D02003 : C –E : LDREQB  R2,[R0,#3]
00000030 : 03520036 : 6@RC : CMPEQ   R2,#&36            ; ="6"
00000034 : 18BD801E : ^ÄΩX : LDMNEIA R13!,{R1-R4,PC}
00000038 : E1A03000 : @0†· : MOV     R3,R0
0000003C : E1A04001 : A@†· : MOV     R4,R1
00000040 : E2801004 : DPÄ‚ : ADD     R1,R0,#4
00000044 : E3A00010 : P@†„ : MOV     R0,#&10            ; =16
00000048 : EF020021 : !@BÔ : SWI     XOS_ReadUnsigned
0000004C : 6A000005 : E@@j : BVS     &00000068
00000050 : E1A00002 : B@†· : MOV     R0,R2
00000054 : E3C00802 : BH¿„ : BIC     R0,R0,#&00020000
00000058 : E1A01004 : DP†· : MOV     R1,R4
0000005C : E3A02040 : @ †„ : MOV     R2,#&40            ; ="@"
00000060 : EF020038 : 8@BÔ : SWI     XOS_SWINumberToString
00000064 : 71A00001 : A@†q : MOVVC   R0,R1
00000068 : 62930000 : @@ìb : ADDVSS  R0,R3,#0
0000006C : E8BD801E : ^ÄΩË : LDMIA   R13!,{R1-R4,PC}

P.S. Found it. StrongED mailing list “StrongHelp crashes on launch” 12Dec15 and it was Reporter.

StrongHelp 2.87 (03-Sep-2012)
undefined instruction at &0000AB20
Two words back.
str r14,[r13,#4]
Is this now flaged as a undefined instruction in the Pi3?
A small util could be made to test this.

There are still a number of manuals out there that have Guttorm Vik’s original, 26-bit, !Pre utility in them. The purpose of the utility is to remove a leading ‘X’ from SWI names to allow them to be looked up.

An extended version is also around that tries to convert hex numbers to SWI names so you can look up those too (26-bit and 32-bit versions exist).

Finally there is an unreleased version here that should run on any ARM, it accepts 0x as another hex prefix (for Lua) as well as decimal SWI numbers.

Edit:

Having now re-read the thread that David pointed to and checked the code. This is what happens:

If StrongHelp is started by Filer_Running a manual (as Reporter does) then it will perform a look-up for a specified page, if not page name is given !Root will be used. If there is a 26-bit !Pre in the manual an abort can occur on modern hardware.

This has been fixed in StrongHelp 2.88a2, if the page name is missing then no look-up is performed (it’s now treated the same as a double-click on the manual), so the 26-bit !Pre isn’t being run.

Of course, a look-up from StrongED or Zap will still trigger an abort, for that the !Pre utility needs to be replaced. I’ve put an updated version here

str r14,[r13,#4]
Is this now flaged as a undefined instruction in the Pi3?

It shouldn’t be, it’s just storing R14 at SP+4; though are you sure that is right¹? Given that R13 is the base, I would have expected…

STMFD R13!, {R14} → STR R14, [R13, #-4]! (stack descends, SP write back expected)

and later on…

LDMFD R13!, {PC} → LDR PC, [R13], #4 (reverse of above)

It was common in the older days to use load/store multiples for stacking single registers; however on newer ARMs the single word loads and stores are more efficient than using multiples for just one word. STR is better, though it’s more of a mouthful.

Of course, this is where macros can be useful, you just specify the register(s) and let the assembler pick the most appropriate instruction. ;-)

¹ Just looked at &AB20 on my StrongHelp and it is an ANDEQ instruction (data words). Doing a search, there is a bit of messing around with STR xx,[R13,#4] to build blocks for GetIconState, but there isn’t one single instance of writing R14 to R13,#4 that I can see. StrongHelp v2.87 2012/09/03.

it’s just storing R14 at SP+4; though are you sure that is right?

Yes, it’s correct. R13 is pointing to a block claimed off the stack and R14 is used as a work register here.

StrongHelp is a Module and those Aborts are in Appspace, are you sure it’s StrongHelp generating the error?

It does have a WimpTask, which is more likely the culprit. AB20 in the Wimp task is an undefined instruction.

I’d say there’s an LDM ^ somewhere in the WimpTask that’s becoming a NOP and corrupting the stack.

EDIT: StrongHelp 2.87 !RunImage: +C2C8 E8FDC000 LDMFD R13!,{R14,PC}^

There’s a TEQ PC,PC just above that bypasses it, so it’s probably not the culprit.

The versions of StrongHelp and StrongED being used on my Raspberry-Pi 3 are 2.87 (3/9/2012) and 4.69f9 (30/6/2016), respectively. I can’t see any version 2.88a2, as mentioned by Fred, on the StrongHelp website.
There is no !Pre file or utility in this version of StrongED or any file with a name like SwiFilter.

@ Jon

StrongHelp is a Module and those Aborts are in Appspace, are you sure it’s StrongHelp generating the error?

I interpreted it as the abort being at offset &AB20 inside the StrongHelp module. This means the aborting instruction is at &AB18 which is indeed STR r14,[r13,#4].

The abort can’t be from StrongHelp’s wimpslot as there is no code there, the Wimp task in is the module too. :-)

@ David

I can’t see any version 2.88a2, as mentioned by Fred, on the StrongHelp website.

StrongHelp 2.88a2 is still an alpha version and therefore not visible on the website, zip available here

There is no !Pre file or utility in this version of StrongED or any file with a name like SwiFilter.

The !Pre files are inside StrongHelp manuals such as the Reporter manual. Shift double-click to open and you’ll see it.

Replacing the !Pre file solves both bugs mentioned in my original post, thanks. However, the reason I couldn’t find !Pre in the Reporter StrongHelp manual before is that I thought the manual was a single file, not a directory. I still don’t understand what type of object these manuals are, as when I do a count from the filer menu on the directory !Manuals.Root in !Boot.Resources, for example, it tells me it contains 10 files which equals the number of StrongHelp manuals inside and when you repeat this on any one manual it tells you it is a directory with 1 file inside; but when you shift double-click on any manual it shows many files inside. In other words each manual behaves like a zip file. If I have got this right, how will others, perhaps new to RISC OS, know?

Oh, it gets worse!
I have quit StrongHelp and shift-double clicked on a manual and the filer tells me “Error when reading ….. !Manuals.Root.Astrobase is a file”.
On one occasion the ‘file’ opened in an editor, Edit, I think.
Help, get me out of here! Is the filer lying?

Is the filer lying?

No. As you quit the application, you quit the filing system too. So manuals become legacy files for the OS.

I have quit StrongHelp and shift-double clicked on a manual and the filer tells me “Error when reading ….. !Manuals.Root.Astrobase is a file”.

As you quit the application, you quit the filing system too.

Indeed, the image filing system is not there any more, the image file cannot be ‘imaged’ it is just a file again. The same happens to a zip file if SparkFS is fully quit.

The vanilla default behaviour is for shift double click on files is to open them in Edit. So why does StrongHelp not fully tidy up after itself on quitting and restore the default behaviour?

I have quit StrongHelp and shift-double clicked on a manual

As others have already explained you need to have StrongHelp running to open a manual as a directory. To the OS it’s just a file, it’s StrongHelp’s image filing system that makes it accessible as a directory.

So why does StrongHelp not fully tidy up after itself on quitting and restore the default behaviour?

It’s because the Filer caches directory info. If the directory with the manual is opened with StrongHelp running the Filer sees the manual as a directory.

Quit StrongHelp and the manual becomes a file again, the Filer however still has the manual marked down as a directory.

To overcome the problem simply close the directory and open it again. What would be useful here is a command/SWI to force the Filer to refresh all open directory viewers.

To overcome the problem simply close the directory and open it again.

Many thanks for the explanation and answer.

Could try issuing something harmless like Rename foo foo which would cause the Filer to see this on upcall and refresh.

But a Filer_RefreshDir command would be welcome.

But a Filer_RefreshDir command would be welcome.

I have got as far as discovering that OS5’s ‘Refresh’ Filer Menu entry does the job. Google found that in the OS6 documentation. OS4.39 also supports refresh.

A bit more digging might find out what the Menu item commands.

P.S.

ROOL.BCM2835Dev.castle.RiscOS.Sources.Desktop.Filer.s.DecodeMenu

DecodeMenu_Refresh
        MOV     r14, #&FF
        STRB    r14, [r4, #d_unsure]    ; mark this dirviewer as dirty
        LDR     r14, poll_word
        ORR     r14, r14, #poll_word_upcall_waiting
        STR     r14, poll_word          ; Poke the foreground application
        EXIT

P.P.S. Always wondered what ‘Refresh’ was for, so forgot all about it.

What was the reason for using an image filing system when creating the StrongHelp manuals application? As I understood it, the main idea was presenting help manuals in a mark up language, but an image filing system wouldn’t be necessary for that?

What was the reason for using an image filing system when creating the StrongHelp manuals application? As I understood it, the main idea was presenting help manuals in a mark up language, but an image filing system wouldn’t be necessary for that?

It makes it very simple to create the manual structure in a text editor, with one text or data file for each page that it contains.

For large manuals on older machines, I’d guess that it also had performance benefits as the files could all be human-readable whist also ensuring that StrongHelp could locate the individual pages very quickly without the need to parse a large text file containing markup.

Steve has already given a couple of reasons for using an image filing system. Another reason was probably to overcome the limitations of older filing systems (10 char leafname, 77 files per directory, etc). StrongHelp 2.00, which introduced the image filing system, was written in 1994/1995 when these limitations still applied.

Thanks for replies.

Has anyone had managed to load Otter on a Pi 3?

Trying to load there is a long pause and then the desktop starts responding again. i.e. no error message or anything on screen.

Using Otter as downloaded from PackMan today and Chris Hall’s non ZPP 5.23 23.8.2016 build

Has anyone had managed to load Otter on a Pi 3?

PackMan doesn’t yet have the version of UnixLib that works on the Pi 3. See here.

The latest Otter is here.