Building RISC OS

I’m going to have a crack at building RISC OS.
I have finally got a display on the Beagle (1024×768) but I have no confidence it’ll still work after a reboot.

But…

Wow.

The Beagle xM is slow as treacle at unpacking from one USB device to another. I really ought to see if I can put together something akin to the Pi’s SD card, to see if that runs at a better speed. I’m just worried about the apparent necessity for “MLO” to be the first thing on the disc. Hmmm…

Not a solution so much as a work-around, but have you tried unpacking to a RAM disc first? (I take it you’ve already seen How to build RISC OS in the wiki.)

Lost patience. I’m unpacking it on the Pi. Much quicker.

There seem to be issues with long file names and the tar archive, of the form:

tar: extent #48220 of split file ././@LongLing ignored
**** changed name '<long path>oslib.Hdr.WriteableFiel0000640' (size=107)
**** into '<long path>oslib.Hdr.WriteableFiel'

I’m currently unpacking Desktop.Wimp.Resources.UK and it has happened 74 times so far – most notably in OSLib, VCHIQ.vc04_services.interface, DWCDriver.dwc, AUNMsgs, and toolboxlib.tools.MethodGen.

Do these files need to be tracked down and renamed?

If you are using untarbz2 replace the tar file in it with this. tar.zip to dearchive properly.

Thanks Colin.

I’ll untar the sources again later. Don’t plan waiting forever again today. ;-)

For those wanting to have a crack at building the RPi image – this’ll get you going (TaskObey file called “PatchPaths”). It doesn’t tweak OSLib, and it only works on the Pi sources at this time; just enough so the build will complete.

On a Pi, the full build takes time. I went shopping, came back, and it was still going. I think ~2hrs for a full build on the Pi.

But…

Hey…

8-)

Some observations:

• This one outputs init mod messages – how do I turn that on and off?

• It seems the Big Delay in getting going is at the “Callbacks” stage of the init. Let me guess – this is the USB enumeration part?

• The copyright above probably ought to read as “© 2002-<this_year> Castle Technology Ltd” – it’s odd claiming a 2002 copyright on a 2013 product! ;-)

• What is it that keeps replacing the first byte of my monitor setting file ($.!Boot.Choices.Boot.PreDesk.Configure.Monitor) with ‘|’? The effect is to disable the LoadModeFile line so the following WimpMode line fails.
  I “fixed” this by locking the file, but it’s more a hack than a fix.

But, hey, slow but not overly complicated. :-) :-) :-)

I’m having my obligatory moan here.

I’ve tried to get rool to change untarbz2 for ages. I even wrote a new untar app to fix it. I’ve sent it to them, posted it on these forums but not a peep out of them. Untarbz2 was never up to the job of dearchiving the archives that rool produce themselves it doesn’t support the ustar standard used to create the files. I think it creates a poor image when people who you want to encourage to get involved give up before they start because the supplied tool doesn’t work.

Phew (mops forehead – I feel better now :-))

Anyway regarding compiling on the beagle. Thats a long time I don’t think it takes that long on RPCemu.

Good work!

This one outputs init mod messages – how do I turn that on and off?

This is what all the beta (odd-numbered) RPi builds do. You can tweak Kernel/Hdr/Options – search for the various Debug variables.

It seems the Big Delay in getting going is at the “Callbacks” stage of the init. Let me guess – this is the USB enumeration part?

I’d also like to know what that is. I saw it in 5.20 and it’s not there in 5.18 so it’s one of the 5.19 changes.

The copyright above probably ought to read as “© 2002- Castle Technology Ltd” – it’s odd claiming a 2002 copyright on a 2013 product! ;-)

No, it definitely shouldn’t: that means the Copyright would only apply up to and including 2013. The rule with Copyright is that you state the first year from which the Copyright extends. People who put a date range in there or who change it every year don’t understand how it works (and I’m not saying I’ve not done both of those things in the past!).

I’ve sent it to them, posted it on these forums but not a peep out of them.

Yes, because we’re muppets and we tend to forget about emails… I’ve got – checks – 187 ROOL emails that I still need to do something about. I also have 2,807 forum posts that I’ve not got around to. It’s probably fair to say we’re a bit swamped…

If someone else out there fancies running Colin’s new, improved UnTarBZ2 through its paces with a few build archives, they would be very welcome. Assuming the results come out positive, I’ll replace the downloads on our site – I promise!

From the speed of response I’ve obviously touched a nerve – I apologise for that. It is good to know that I’m being ignored rather than not read – no really. There are always good reasons to ignore something but at least I know now that you know about it.

It seems the Big Delay in getting going is at the “Callbacks” stage of the init. Let me guess – this is the USB enumeration part?

I’d also like to know what that is. I saw it in 5.20 and it’s not there in 5.18 so it’s one of the 5.19 changes.

I believe it is the USB enumeration. The reason it’s moved from during the mod init spam to during the Callbacks stage is due to the fix that was made to callbacks firing during the mod init spam (where callbacks would fire after every line of text, which wasn’t intended; according to the original ROM boot sequence the first callbacks that fire should be during the “Callbacks” stage, even though there’s nothing actually coded in the kernel to stop modules triggering callbacks earlier than that)

From the speed of response I’ve obviously touched a nerve – I apologise for that.

Sometimes touching nerves is the best course of action! If you hadn’t, we wouldn’t have known why nothing’s happened yet.

What is it that keeps replacing the first byte of my monitor setting file ($.!Boot.Choices.Boot.PreDesk.Configure.Monitor) with ‘|’? The effect is to disable the LoadModeFile line so the following WimpMode line fails.
I “fixed” this by locking the file, but it’s more a hack than a fix.

This is (IIRC) done somewhere in the boot sequence, when it detects a CMOS RAM reset (because historically, CMOS was used to store the desktop mode, so when things were transitioned over to boot sequences and MDFs I think the decision was made to make sure the mode that’s set in the boot sequence gets reset on a CMOS reset too).

And the reason CMOS has been reset is because it’s embedded in the ROM image on the Pi – so every time you replace your ROM your CMOS is being reset.

And the reason CMOS has been reset is because it’s embedded in the ROM image on the Pi – so every time you replace your ROM your CMOS is being reset.

Since I’ve had the same effect on a beagleboard, the niggling item is not just a Pi ROM image issue.
Reports of the problems people have had with Iyonix 5.20 upgrades rather suggests it is rather wider spread.
I don’t recall the specific 5.19 version but I do recall a discussion I had where Sprow’s suggestion was to work with a clean boot and I found a total blow away and rebuild of the CMOS settings file was required.
That was on RPCEmu – so an IOMD issue too.
Not a problem for people if it’s documented and the system doesn’t go around commenting out lines thus stopping you saving settings.

The copyright above probably ought to read as “© 2002- Castle Technology Ltd” – it’s odd claiming a 2002 copyright on a 2013 product! ;-)

No, it definitely shouldn’t: that means the Copyright would only apply up to and including 2013. The rule with Copyright is that you state the first year from which the Copyright extends. People who put a date range in there or who change it every year don’t understand how it works (and I’m not saying I’ve not done both of those things in the past!).

No Sir, you are not correct! The Copyright, Designs and Patents Act 1988 is extremely clear.

Copyright of the author subsists in a literary work automatically upon “recording” until “70 years from the end of the calendar year in which the author dies”.

In the case of joint authorship, the death of the “author” is considered to be the demise of the last known surviving author. Naturally where a work is created during the course of employment, the employer is the “author”.

Assignment of copyright transfers the right to copy (etc), but does not alter the definition of the “author”, nor the definition of the copyright period.

And there’s nothing you can do to a date in a source file that overrides British Law. So please do use date ranges, they’re very informative.

You can tweak Kernel/Hdr/Options – search for the various Debug variables.

Thanks. It’s a veritable playground. ;-)

No, it definitely shouldn’t: that means the Copyright would only apply up to and including 2013.

Really? I thought copyright extended from the date given for a specific amount of time (something like life+70 years, though I’m not sure how one determines that in an open source project), not copyright within a narrow date range – as the dates given are inclusive of “this product has been ‘ours’ from X to Y”.

Can you cite something to support your claim?

On behalf of my date range idea – I cite this:
“In case of a dispute of ownership of a work, the date plays an important part. If your work was developed and published before any potential opponents then you can usually expect to win any case which challenges your rights.
In the case of work which is continually updated, (for example a web site), the year of publication may be shown as a period from first publication until the most recent update, (i.e. 2000-2004)” [source: http://www.copyrightservice.co.uk/copyright/p03_copyright_notices ]

Interestingly, it appears as if the “accepted” international standard for copyrighting work is to put the date prior to the name, with the notable exception of the old-fashioned parts of the United Kingdom that insist on doing it the other way around [source: http://www.ipo.gov.uk/types/copy/c-about/c-about-faq/c-about-faq-protect.htm ]; though thankfully the UK does not require works to be registered to benefit from copyright protection, in accordance with the Berne Convention (unlike the US that seem to cherry-pick which parts of international law to follow and thus often “recommend” people to register (for a fee) their work).

From the speed of response I’ve obviously touched a nerve

Not at all – you just happened to get in when I was about to reply to the questions before your post, so I thought I’d answer both at once. :)

Not a problem for people if it’s documented and the system doesn’t go around commenting out lines thus stopping you saving settings.

The OS should never ever patch parts of the system configuration without plastering a big message on-screen saying “What” and “Why”.

Or, perhaps more specifically, if I wanted an operating system that thinks it knows better than me and thus arbitrarily modify my configuration settings “for my safety” … then I’d buy a Mac.

The OS should never ever patch parts of the system configuration without plastering a big message on-screen saying “What” and “Why”.

Imagine if a Noob upgrades their Pi ROM; they find they’re back in a generic mode; they reconfigure the machine using !Configure and it still chucks them back to the generic mode (yes, I locked the file because using Configure didn’t stop this happening). What would they think then?

The OS should never ever patch parts of the system configuration without plastering a big message on-screen saying “What” and “Why”.

In case I’ve not made it clear:
The OS should never ever patch parts of the system configuration without plastering a big message on-screen saying “What” and “Why”.

yes, I locked the file because using Configure didn’t stop this happening

Strangely, you aren’t the only one. You, me and a collection of others I’ve seen relating the same story.
Much better if the OS wasn’t chuffing about with the settings really.

The OS should never ever patch parts of the system configuration without plastering a big message on-screen saying “What” and “Why”.

“please may I change this setting? this is why. If I don’t and things break it’s your fault…”

From this: http://www.copyrightservice.co.uk/copyright/p02_protecting_copyright we have “The year. Normally when first published, but for unpublished work, use the year it was written.”

and from this: http://www.copyrightservice.co.uk/copyright/p03_copyright_notices we have “In the case of work which is continually updated, (for example a web site), the year of publication may be shown as a period from first publication until the most recent update”.

So the important thing is the first date, the other one is optional (and an admin headache to have to keep updating). I was probably wrong about the optional year being interpreted as the end date – but I’m sure that’s what I was told in the past(!).

This page http://en.wikipedia.org/wiki/Copyright says the US used to mandate the use of the year of first publication also (but notes that copyright applies irrespective of the presence of a notice nowadays in all parties to the Berne convention)

“In the case of work which is continually updated, (for example a web site), the year of publication may be shown as a period from first publication until the most recent update”.

So the important thing is the first date, the other one is optional

Is it not considered that RISC OS, with its daily builds, is “continually updated”?

(and an admin headache to have to keep updating).

Surely it’s a simple matter of running a five line BASIC program (or some sort of script) to create a value or snippet of assembler or whatever that holds the copyright message, in the form “© 2002-<this year> Castle etc etc”?
Same with a website, a simple bit of script can provide the date range. This can be swapped out for a constant if necessary.

It would certainly look better than last night’s build carrying a copyright date eleven years out of time!

the US used to mandate the use of the year of first publication also (but notes that copyright applies irrespective of the presence of a notice nowadays in all parties to the Berne convention)

Which is about as useful as a bicycle to a fish – quote “No. In general, registration is voluntary. Copyright exists from the moment the work is created. You will have to register, however, if you wish to bring a lawsuit for infringement of a U.S. work.” [source: http://www.copyright.gov/help/faq/faq-general.html#register ]
What is the point of a copyright if you cannot hope to enforce it? At least, without a “voluntary” registration at $65 a time ($35 online).

It is also worth noting the following bearing in mind the supposed “country of origin” of a work: "In the internet age, publication online may be considered publication in every sufficiently internet-connected jurisdiction in the world. It is not clear what this may mean for determining “country of origin”. In Kernel v. Mosley, a U.S. court “concluded that a work created outside of the United States, uploaded in Australia and owned by a company registered in Finland was nonetheless a U.S. work by virtue of its being published online”. However other U.S. courts in similar situations have reached different conclusions." [source: http://en.wikipedia.org/wiki/Berne_Convention_for_the_Protection_of_Literary_and_Artistic_Works]

Like I said, the American legal system has “interesting” interpretations of everybody else’s laws.

But this is getting away from the point. I still reckon a “2002-2013” style date range is much better looking.

“© 2002-<this_year> Castle Technology Ltd”

A few spanners to add to the works:

1. Why doesn’t it also say (above Castle) “© 1987–2000 Acorn Computers Ltd”?¹²³
   • General awareness of ARM originating from Acorn is an important part of RISC OS’s heritage, and may already be better understood as a result of the mentioning in recent media reports, e.g. recognition of Sophie Wilson’s work.
2. If ROL were to permit their changes to be included/adapted for the CTL/ROOL fork, this could also be included in a similar fashion, leaving their legacy within the 32-bit version.⁴
3. And for good measure, shouldn’t ROOL (and its contributors) also be listed, seeing as the changes are managed/published by ROOL (rather than CTL)?
4. And what about Pace too?

¹ The date range is clearly stated as being optional, through the use of “may”, however convention may be to state a range.

² Note the en dash (and no spaces) for a range of values.

³ Or whatever dates are appropriate.

⁴ Better late than never?

I still reckon a “2002-2013” style date range is much better looking.

Seems meaningless to me. Any dispute to do with the date would be a prior claim of copyright. So a range of dates is meaningless it just adds confusion. You can see why the rules say it /may/ be added.

But I’m no lawyer and certainly wouldn’t change things based on a forum discussion.

Why doesn’t it also say (above Castle) “© 1987–2000 Acorn Computers Ltd”

Presumably because its a notice of castle’s copyright ownership.

See the confusion the range causes. It’s a range of from dates not a start to end date

Naturally where a work is created during the course of employment, the employer is the “author”.

I’m not sure it is as simple as that. Isn’t it 50 years after publication for Crown copyright? But I seem to recall that a company-inspired project will usually list some young programmers to extend the copyright life of a product.

70 years from the end of the calendar year in which the author dies

This does not apply to companies which can (in theory) go on for ever.

Trevor asked:

Why doesn’t it also say (above Castle) “© 1987–2000 Acorn Computers Ltd”

Because the copyright on the work is not owned by Acorn Computers Ltd. It may once have been, but that’s irrelevant now. The copyright was acquired outright.

If ROL were to permit their changes to be included/adapted for the CTL/ROOL fork, this could also be included in a similar fashion

Whoever owns the copyright on those novel works might assign it to ROOL, or licence its use. In the latter case they would retain copyright and that would have to be documented… but in that case I’m pretty sure their submissions would not be accepted.

Copyright is not a credits roll. It’s a legal declaration of who has the right to copy it. That right can be transferred, which means those who once had it may no longer have it. Acknowledging contributors is unrelated to declaring the copyright owner.

shouldn’t ROOL (and its contributors) also be listed

Copyright owner != contributors.

Colin asserted:

Any dispute to do with the date would be a prior claim of copyright. So a range of dates is meaningless it just adds confusion.

A prior claim is one kind of dispute, which only the earliest date has much influence upon. However, there are other disputes such as whether the copyright on a work has now lapsed. For works that are updated, the copyright on new contributions will have a different copyright period to the original content, and that needs to be indicated by the date range.

Chris asked:

Isn’t it 50 years after publication for Crown copyright?

The Crown is the special case. I didn’t mention it because it isn’t relevant to this discussion – AIUI it is not the Crown that owns the copyright on any RO related software! For the record, Crown copyright on literary works extends for 125 years if unpublished, and 50 years from publishing if published within 75 years of being created.

70 years from the end of the calendar year in which the author dies

This does not apply to companies which can (in theory) go on for ever.

In that case it is 70 years from the end of the calendar year in which the work was created.