Important software compatibility notice

Is it possible to add an option to the dev build to enable/disable Zero Page relocation at boot?

I’m seeing so many issues on the latest builds that I’m not certain if they’re down to Zero Page relocation or other changes in the OS.

I’d like to soak test two Pi’s side-by-side on the same OS build, one with Zero Page relocation, one without, and see if they break at the same point to help track down the root causes.

Soak testing RC14 side-by-side with the 15-10-15 build has proved these are new issues to 5.23, so it’s now a case of trying to prove if it’s the app or the OS at fault.

Can you build your own? I suspect that a lot of zero page stuff is initialised before the point where RISC OS is able to look at whether zero page ought to be high or low.

If you can build your own ROM then it’s easy to enable/disable zero page relocation. For the Pi, change the Kernel & FPEmulator lines in the components file to the following:

Kernel -at 0xFC010000 -options ASFLAGS="-PD \"HiProcVecs SETL {FALSE}\""
FPEmulator -options FPE_APCS=3/32bit FPEANCHOR=Low

(You can do similar changes for the other ROMs, just make sure the Kernel start address is correct)

Changing the OS to allow dynamic selection at boot time would be a significant amount of work, so it isn’t something that we have planned.

Building RISCOS is sadly beyond my current capabilities.

Building RISCOS is sadly beyond my current capabilities.

This help?
http://www.heyrick.co.uk/blog/index.php?diary=20131105

You’ll need a spare Pi and expect it to take forever to unpack the sources and make the initial build.
I found it actually surprisingly simple to build. Just set !Builder going and then leave it to do its thing. Read the blog stuff, see what you think…

You’ll need a spare Pi and expect it to take forever to unpack the sources and make the initial build.

Shamelessly for speed I build on VRPC OS4.39 on an iMac, the whole job is a bit under 20mins. However with the coming of the 512MB RAMdisc on the RPi2 builds on that now go at about the same rate. Unpacking is quite spritely!

The build is easy, and I have built a low vector ROM as an exercise in finding out how to. Comparing the iMx6 and BCM2835 components files was the key.

expect it to take forever to unpack the sources

Using a Pi 2 with a 500Mbyte RAM disc it takes 1m23s to unpack the sources and 12m45s to create the rom. As you say, quite spritely, a bit under 15min!

I now recall trying to go down this route a few years back and gave up due to it not being a reliable test.

The issue with the “go built it yourself” route is that you need the same DDE version as the live system, otherwise you’re also testing DDE differences that could affect C. Many of the issues I’m seeing at the minute are C Module related.

Can ROOL auto-build and make both versions available, so we know the only difference is Page Zero relocation?

I said that a while back. It won’t cost much out of a modern system to stick 32KiB of junk space in to the address range &0 – &7FFF.

I’ve finally got around to trying to “patch” my copy of PhotoFiler (I don’t want to use a low vector ROM indefinitely!) but I’m not quite sure how to do it. From the first page of this thread:

Thanks everybody. I have updated Photofiler and now it runs without zeropains. The changes are: [code]

and

you need to replace the MOV r0, r2 with LDR r0, [r2]

With these changes made, PhotoFiler doesn’t appear to function at all; presumably it’s not detecting the Filer correctly. I’m not familiar with assembler or the patch notation (eg. does “line 24, 32” mean “insert this block of code at line 24 and again at line 32”, or something else?) so I’ve probably done something wrong.

Can someone please supply either the complete code to the “filer_active” function, or upload a ready-assembled copy of the PhotoFiler module? I’d really appreciate it :)

32KiB of junk space

Junk space indeed!

32kb = 32,000 bits
32kB = 32,000 bytes
32Kb = 32,768 bits
32KB = 32,768 bytes
32KiB = 32,768i bytes?

I didn’t think even quantum computers used imaginary bytes!

Or is this a cunning, albeit mildly illogical, way of saying it’s virtual memory?

I’ve finally got around to trying to “patch” my copy of PhotoFiler

As this is from last year obviously I have mostly forgotten all about it. As I recall the PhotoFiler modifications were very good at stopping the pain but the slight downside was that no thumbnails were produced either. The conclusion I came to at the time was that R14 needs to be stacked over the XOS_ReadSysInfo call. These solutions work here. HTH.

P.S.. The original PhotoFiler 2.08 crashes catastrophically on attempting to open a directory of ArkWorks files, the fixes below do not fix that.

filer_active
        ; Purpose: Is the currently active task the Filer?
        ; Exit:    EQ if it is; NE otherwise

        STR	r14, [r13, #-4]!	; STMFD	r13!, {r14}

        ; Get lower 16 bits of current task handle and compare it to the
        ; domain ID. (v. hacky)
        ;
        LDR     r14, [r12, #Filer_TaskHandle]
;        MOV     r0, #&F00
;        LDR     r0, [r0, #&F8]

        STMFD   r13!, {r1-r2,r14}
        MOV     r0, #6
        MOV     r1, #0
        MOV     r2, #70
        SWI     &20058;    XOS_ReadSysInfo
        LDR     r0, [r2]
        LDMFD   r13!, {r1-r2,r14}

        MOV     r14, r14, LSL #16       ; clear top sixteen bits
        MOV     r14, r14, LSR #16
        TEQ     r0, r14

        LDR	pc, [r13], #4		; LDMFD	r13!, {pc}


        END

or even :-

filer_active
        ; Purpose: Is the currently active task the Filer?
        ; Exit:    EQ if it is; NE otherwise

        STR	r14, [r13, #-4]!	; STMFD	r13!, {r14}

        ; Get lower 16 bits of current task handle and compare it to the
        ; domain ID. (v. hacky)
        ;
;        LDR     r14, [r12, #Filer_TaskHandle]
;        MOV     r0, #&F00
;        LDR     r0, [r0, #&F8]

        STMFD   r13!, {r1-r2}
        MOV     r0, #6
        MOV     r1, #0
        MOV     r2, #70
        SWI     &20058;    XOS_ReadSysInfo
        LDR     r0, [r2]

        LDMFD   r13!, {r1-r2}
        LDR     r14, [r12, #Filer_TaskHandle]

        MOV     r14, r14, LSL #16       ; clear top sixteen bits
        MOV     r14, r14, LSR #16
        TEQ     r0, r14

        LDR	pc, [r13], #4		; LDMFD	r13!, {pc}


        END

Thanks for that. I’ve implemented the second option (it looks a little “cleaner” to my untrained eyes) and it’s working with my low vector ROM. I trust that it’ll work with the high vector one too :)

Thanks again!

Edit: For the benefit of any PhotoFiler users that don’t have ObjAsm, you can download the patched module. Just drop it into the !PhotoFilr app directory, replacing the existing module (you should of course back up the old one first, just in case!)

You can tell whether you’re running the old or new one by typing *Help Modules; the new one is still version 2.08 but has today’s date instead of 2008.

I didn’t think even quantum computers used imaginary bytes!
Or is this a cunning, albeit mildly illogical, way of saying it’s virtual memory?

Some boring people with their heads up their asses decided to redefine the “kilobyte” that world+kitten had been happily using through the eighties and nineties as a power of 2. Look at RISC OS itself, your computer starts with so many K. Switcher shows values in K. Harddiscs are shown in M, or maybe G.

It’s not supposed to be Kilobyte these days, it is supposed to be Kibibyte. Unless you’re talking harddiscs, in which case you really do have an 80GB drive, which is why it formats to be around 74GiB… :-/

Some boring people with their heads up their asses decided to redefine the “kilobyte” that world+kitten had been happily using through the eighties and nineties as a power of 2.

Yup – but I thought that was the distinction between kB and KB? I’ve not seen Ki before – is that really a thing?

[Edit] Blimey. Yes it is. Looked it up. Heads up asses indeed. I thought hard disc manufacturers were right out of order in the first place, quoting disc sizes in power-of-10 units instead of power-of-2.

Blimey. Yes it is. Looked it up. Heads up asses indeed. I thought hard disc manufacturers were right out of order in the first place, quoting disc sizes in power-of-10 units instead of power-of-2

Sometimes you just need someone to take a sidelong view to burst their bubble.

To quote from the NIST site:
“In December 1998 the International Electrotechnical Commission (IEC), the leading international organization for worldwide standardization in electrotechnology, approved as an IEC International Standard names and symbols for prefixes for binary multiples for use in the fields of data processing and data transmission”

and around about the same time everyone else collectively said “who gives a ….” and went on to routinely use pretty much any combination of letters that vaguely convey the range of numbers they want without any implied accuracy.

The regular use is K, M, or G as Rick mentioned, thereby, hopefully, preventing either the KB or KiB adherents from making any comment.

How did I miss that xkcd? I’m a regular consumer!

I reckon (you know, as in “wot I reckon”) the SI ought to have adopted the bit and the byte as SI units, with a defined variation of the definitions of all the 10^3n prefixes as meaning 2^10n for bits and bytes. And told the drive manufacturers “them’s the rules.”

Chris

I have tried your patch on a Pandabaord Es running 5.23 High Vector 21st May 16 ROM and it works until you hit a directory full of Artworks files then it aborts with a filer error at address &203F0218 but no Zeropain output is given.

I managed to crash the ARMX6 on R-Comp’s stand (several times!) at the south west show by opening a directory of ArtWorks files while PhotoFiler was running, so this may not be a high vector thing.

I just tried the unmodified 2.08 on a low vector ROM and it crashed there too (although in my case it froze the entire machine instead of aborting). It therefore doesn’t appear to be related to the changes and I disavow all responsibility :)

If anyone else has a fix for the issue then I’m happy to run it through ObjAsm and host the output, but unfortunately I don’t have the assembler knowledge to maintain PhotoFiler myself.

The unmodified PhotoFiler 2.08 does open a directory of ArtWorks files here on the 26bit OS4.39 VRPC and the 32bit OS4.42 A9home but crashes catastrophically with OS 5.23 on all three Raspberry Pi’s, the Titanium and even the Iyonix, including OS5.22. I assume that PhotoFiler from version 2.06 did work on the Iyonix at the time.

Have tried PhotoFiler 2.08 with Redsq – works ok with RO4.02 but Redsq freezes with RO5.19 when a directory is opened containing Artwork files.
But does seem to manage ok with only one file in the directory.

Have tried PhotoFiler 2.08 with Redsq – works ok with RO4.02 but Redsq freezes with RO5.19 when a directory is opened containing Artwork files.

Same here with RPCEmu on a Mac, OS4.02 good, OS5.19 bad. OTOH on OS 5.17 RPCEmu the ArtWorks files thumbnailed perfectly.

I’m getting the same behaviour on my ARMX6 (5.23 18th March).
Nice program though, it handles large images suprisingly quickly.
Shame about the Artworks files though.

Okay, this is rather horrible.

I know nothing about how the ArtWorks render module works, nor do I have any documentation on it. So going blind and playing around, and plenty of reboots later, I find that I can get it sort-of working as follows:

Towards the end of the s.Thumbnails code, you’ll see a call to XAWRender_RenderAddress, followed by setting up some data blocks into registers, then:

        MOV    r14, pc
        MOV    pc, r10

Modify as follows:

        MOV    r14, pc
        MOV    pc, r10

        MOV    r0, r0
        MOV    r0, r0

Now the machine won’t stiff the moment you see an ArtWorks file. Instead one or two may be rendered and then the Filer will crash horribly (and take the machine down with it, yay!).

That’s one step forwards, one step back.

For what it’s worth, the reason for the stiffing is because ArtWorks appears to return after the instruction following the BL, which meant that the LDMFD was missed, which left five words on the stack and, well, you can guess what happens if the stack gets out of whack. Especially when it’s the SVC stack ‘cos we’re a module. ;-)

So for now, the simplest option is to simply nobble ArtWorks support. To do this, set the flag in Hdr.Options to 0. It’ll be obvious which one. ;-)
However, in order to get it to build, you’ll need to bodge the data block to be a size that can be used in an immediate MOV, so open up Hdr.Workspace and look for this line:

sizeof_workspace                * @

Add the right amount of junk prior so the MOVs will work, as follows:

  [ ARTWORKS = 0
BodgeSizeofWorkspaceToFit       # 136
  ]
sizeof_workspace                * @

Then rebuild, and just accept that – for now – something is very VERY wrong with ArtWorks support, and since it isn’t a publicly documented API…….