ViewXLS
Anton Reiser (471) 63 posts |
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.
|
John Rickman (71) 645 posts |
Thanks very much Anton. |
George T. Greenfield (154) 748 posts |
Seconded! ViewXLS is extremely useful. However when I run the latest version on my Pi3 (5.24) I get: |
Dave Higton (1515) 3497 posts |
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+. |
Anton Reiser (471) 63 posts |
@ Pi3 |
Dave Higton (1515) 3497 posts |
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. |
John Rickman (71) 645 posts |
For info – I am using an ARMX6 running RO 5.25 |
Raik (463) 2059 posts |
PatchSWP on Pi3B+ gives a lot of error messages like “Not-yet-patchable by me:SWP 3,7,9 at offset &87C18”. |
Anton Reiser (471) 63 posts |
Dave, Raik, thanks for the info. I will investigate. |
David Pitt (3386) 1248 posts |
!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) |
Anton Reiser (471) 63 posts |
David, thanks for your diagnostics. Help appreciated. |
Rick Murray (539) 13806 posts |
That’s because you used R14 instead of R15. ;-) It’s worth remembering that Debugger also accepts PC as a synonym for R15. |
David Pitt (3386) 1248 posts |
https://www.riscosopen.org/wiki/documentation/show/Reporting%20bugs |
Andrew Rawnsley (492) 1443 posts |
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 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? |
Rick Murray (539) 13806 posts |
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… |
Jeffrey Lee (213) 6048 posts |
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. |
Stuart Swales (1481) 351 posts |
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. |
Anton Reiser (471) 63 posts |
Stuart, you are right. Thanks for your support. |
Rick Murray (539) 13806 posts |
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”.
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? |
Norman Lawrence (3005) 172 posts |
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. |
Andrew Rawnsley (492) 1443 posts |
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. |
Steve Fryatt (216) 2103 posts |
Does StubsG support C99 and all that which the current Stubs do? |
David Pitt (3386) 1248 posts |
&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 |
Stuart Swales (1481) 351 posts |
Anton has published new versions of !ViewXLS and !sch2xls this morning |
David Pitt (3386) 1248 posts |
!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. |