ViewXLS

I have published a new version of “ViewXLS” http://home.allgaeu.org/areiser/riscos/software/viewxls/index.html

It’s a development version, but you may find it useful.
New features:

• May open XLSX files.
• Multi document view.
• Shows some drawing objects.
• Unicode (if Cyberbits is found).

Thanks very much Anton.
Just tried this on two multisheet xlsx files that are sent to me each month. They both render satisfactorily and export successfully to CSV for use in FireWorz.
Until now I have had to jump through hoops to get at the data. Ie transfer to linux, open in LibrOffice, export to csv, transfer back to RISC OS etc.

Thanks very much Anton.

Seconded! ViewXLS is extremely useful. However when I run the latest version on my Pi3 (5.24) I get:
“Trap while in trap handler: internal error: undefined instruction at &0009A20C, pc=00090154: registers at 000A0450”. Switching CPU from ARMv7 strict to fast mode makes no difference.

I get the same result as George with version 0.21 beta, whereas the old 0.11 beta loads fine. This is on a Raspberry Pi 3B+.

@ Pi3
Maybe the ‘unzip’ Absolute in ViewXLS.Resources is a bit outdated. Its needed to load XLSX files.

Maybe the ‘unzip’ Absolute in ViewXLS.Resources is a bit outdated. Its needed to load XLSX files.

I don’t think unzip is the problem, Anton. The symptoms are identical if I rename unzip so as not to be recognised. And I checked the ViewXLS* environment variables to be sure that it couldn’t be pointing at unzip somewhere else. I even got hold of a newer version of unzip; both your distribution and the newer one run if double-clicked, issuing a help message because there were no command line args.

For info – I am using an ARMX6 running RO 5.25

PatchSWP on Pi3B+ gives a lot of error messages like “Not-yet-patchable by me:SWP 3,7,⁹ at offset &87C18”.
On Ti it works without problems.

Dave, Raik, thanks for the info. I will investigate.

!ViewXLS 0.21β (25.02.2020) starts up normally on the RPi1 in both ARMv5 and ARMv7 modes. SWPs may be the problem, there are eight. I think the source is assembler, I think. My diagnostic, on the RPi4 and RPi3B+, went a bit awry.

*showregs
Register dump (stored at &2001BE50) is:
R0  = 70000180 R1  = 00000183 R2  = 00000000 R3  = 00000000
R4  = 000AEB48 R5  = 00000060 R6  = 0008B8CC R7  = 0008B8CC
R8  = 0009FC4C R9  = 000A03D8 R10 = 000ADE88 R11 = 000A0450
R12 = 000AEAC4 R13 = FA208000 R14 = 60000110 R15 = 0009A20C
Mode SVC32 flags set: nZCVqjggggeAIft        PSR = 70100193
*memoryi PC-20 +40
0009A1EC : Ô.;È : E93B01EF : LDMDB   R11!,{R0-R3,R5-R8}
0009A1F0 : Ô.,È : E92C01EF : STMDB   R12!,{R0-R3,R5-R8}
0009A1F4 : ...· : E10F0000 : MRS     R0,CPSR
0009A1F8 : Ä.Ä„ : E3800080 : ORR     R0,R0,#&80         ; ="Ä"
0009A1FC : ..Ä„ : E3800201 : ORR     R0,R0,#&10000000
0009A200 : ..¿„ : E3C0001F : BIC     R0,R0,#&1F         ; =31
0009A204 : .)· : E129F000 : MSR     CPSR_cf,R0
0009A208 : ..†· : E1A00000 : MOV     R0,R0
0009A20C < .–†· : E1A0D00C : MOV     R13,R12
0009A210 : .††· : E1A0A00A : MOV     R10,R10
0009A214 : .∞†· : E1A0B004 : MOV     R11,R4
0009A218 : ...o : 6F020013 : SWIVS   XOS_IntOn
0009A21C :  AôÂ : E5994120 : LDR     R4,[R9,#288]
0009A220 : ..†· : E1A0000D : MOV     R0,R13
0009A224 : .P†„ : E3A05018 : MOV     R5,#&18            ; =24
0009A228 : T..Î : EB000054 : BL      &0009A380
*memoryi R14-20 +40
600000F0 : Internal error: abort on data transfer at &FC1DEFB0
*where
Address &FC1DEFB8 is at offset &000008B8 in module 'Debugger'
*fx0
RISC OS 5.27 (04 Mar 2020)
*help Debugger
==> Help on keyword Debugger
Module is: Debugger        2.07 (05 Feb 2020)

David, thanks for your diagnostics.
In my source there is no assembler involved.
The RunImage in ViewXLS 0.21ß is created with DDE27.
Meanwhile I have DDE29. Compiled with this I get only one not-yet-patchable SWP from PatchSWP. My suspect is the RISC_OSLib (I know ;-), but some part of my source is twenty years old).

Help appreciated.

My diagnostic, on the RPi4 and RPi3B+, went a bit awry.

That’s because you used R14 instead of R15. ;-)

It’s worth remembering that Debugger also accepts PC as a synonym for R15.

That’s because you used R14 instead of R15. ;-)

https://www.riscosopen.org/wiki/documentation/show/Reporting%20bugs

I use RISCOS_Lib myself, Anton, albeit in a somewhat tweaked/modded form over the years.

My main copy doesn’t seem to have any SWP instructions in it, but a ROOL-downloaded copy from 2015-ish seems to use one to test if SWP is available/functional, then uses it later if available – RISC_OSLib.Kernel.s.k_body
Rather oddly, my “normal” RISC_OSlib doesn’t have any corresponding files. Also, and perhaps more significantly, there are no SWP references in RISC_OSLib.rlib which I think is the actual RISC_OSlib that applications use (it is the closest match to my own version).

So, without spending more time trying to figure out what each bit of the RISC_OSlib folder heirarchy does, and if it is necessary, there may be one SWP used, but in all likelihood probably not. It would certainly seem very odd for someone to introduce SWP commands between 1995-ish (my copy stems from that era) and 2015.

If you’d like me to compile code against my RISC_OSlib to see if it makes a difference, let me know.

Are there any other libraries being used?

Oops, sorry, wasn’t paying enough attention.

Clearly R14 isn’t a return pointer here, I wonder what’s making use of it? Even stranger, if the faulting instruction is two before the > marker, that implies it’s the MSR that is failing. Off the top of my head, it looks like the code is setting V, inhibiting interrupts, and clearing the bottom five bits (USR mode). Not terribly multi core friendly, mind you…

Off the top of my head, it looks like the code is setting V, inhibiting interrupts, and clearing the bottom five bits (USR mode)

Yes. However it’s selecting USR26, which means it could fail badly on old machines (e.g. RiscPC running RISC OS 5), and new machines (ARMv8 – processor mode 0 is now a 64bit mode, and it’s illegal to use MSR to switch between 32 & 64bit modes). Machines in the middle (i.e. ARMv5 to ARMv7) are likely to work fine because they’ve got bit 4 of the PSR hardwired to 1 (-:

Solution: Don’t modify bit 4 of the PSR.

If it helps, I just dumped the current RISC_OSLib library shipped with DDE29 and that contains no MSR or SWP

Edit: DDE29 o.ansilib contains the wonky MSR code from David’s dump. Could you try just linking with o.Stubs to use the SharedCLibrary?

Edit: The wonky MSR code is in AbortFindHandler in kernel.s.k_body, in a wonderful mish-mash of conditional assembly.

Stuart, you are right.
Linking with o.Stubs and PatchSWP says: No SWP instructions found.
Don’t know, how o.ansilib found his way into the makefile.
So the RISC_OSLib was a false suspect, but it was a library ;-)

Thanks for your support.

Yes. However it’s selecting USR26

I did remember that (and thought it was odd to be clearing down to USR26), and checked by looking at something on ARM’s wonderfully chaotic site. It described the CPSR in much detail, and noted that bit 4 was “reserved”.
So I didn’t mention anything as that would be wrong on RiscPCs and emulators that have a 26 bit mode to switch to, but wouldn’t be relevant to the Pi 4… only you then mention:

processor mode 0 is now a 64bit mode

Oh boy… So there lies the problem, no? :-)

My tablet is running on steam tonight (no idea why it’s treacle slower than usual, maybe something is updating itself?) so I would look this up – but would I be right in thinking that bit four nominally set is the range of processor des we’re used to, while that bit clear is the same set of modes (maybe an extra for hypervisor behaviour), only in a 64 bit incarnation?

Anton many thanks for continuing to develop ViewXLS and it looks like you may be able to get it working on the Pi3. I use sch2xls and xls2sch quite a lot and both work on a Pi Zero but only xls2sch works on the Pi3. Perhaps the fix for ViewXLS may also work for sch2xls. Thank you for your support.

Whilst we’re checking compatibility, I tried the latest version on VirtualRPC (RISC OS 4.02) last night and 0.21b gave crashed with an Abort during load. I didn’t write down the address, I’m sorry. It may be some of the new OS5 stuff, I don’t know, or might benefit from linking to StubsG rather than Stubs. Happy to help with testing.

might benefit from linking to StubsG rather than Stubs

Does StubsG support C99 and all that which the current Stubs do?

I didn’t write down the address

&807C OS4.02

*memoryi PC-20 +40
0000805C : 4¿ú. : 159CC034 : LDRNE   R12,[R12,#52]
00008060 : .¿å. : 008CC000 : ADDEQ   R12,R12,R0
00008064 : .¿å‡ : E08CC001 : ADD     R12,R12,R1
00008068 : ..†„ : E3A00000 : MOV     R0,#0
0000806C : ..S„ : E3530000 : CMP     R3,#0
00008070 : .†— : D1A0F00E : MOVLE   PC,R14
00008074 : ..å‰ : E48C0004 : STR     R0,[R12],#4
00008078 : .0S‚ : E2533004 : SUBS    R3,R3,#4
0000807C < ˚ˇˇÍ : EAFFFFFB : B       &00008070
00008080 : 0.21 : 31322E30 : Undefined instruction
00008084 : fl (2 : 322820DF : EORCC   R2,R8,#&DF         ; ="fl"
00008088 : 5.02 : 32302E35 : EORCCS  R2,R0,#&0350       ; =848
0000808C : .202 : 3230322E : EORCCS  R3,R0,#&E0000002
00008090 : 0).. : 00002930 : ANDEQ   R2,R0,R0,LSR R9
00008094 : ..ü : E59F000C : LDR     R0,&000080A8
00008098 : ..ü : E59F100C : LDR     R1,&000080AC

Anton has published new versions of !ViewXLS and !sch2xls this morning

Anton has published new versions of !ViewXLS and !sch2xls this morning

!ViewXLS 0.22ß does start up on the RPi4 and on OS4.02, and render an xls.

It does go rather wrong if a text file is dropped onto iconbar icon, some of the desktop is there but on a grey background. I, accidentally, discovered this on RPCEmu where, obviously, the xls test file had lost its filetype and was at the default text filetype. F12 reclaims the full Desktop, and filetyping the test file as MSExcel worked properly. This crash can be replicated on the Titanium.