Talk:RISC OS

The opening sentence now reads "...RISC OS /rɪskˈoʊˈɛs/^[1] (initially named Arthur)^[2]..."

Could this be phrased better? It seems ambiguous to me, as was RiscOS supposed to be Arthur 2, or does the statement mean that the operating system was originally, ie pre-RO2, called Arthur? I'm confused. a_man_alone (talk) 17:09, 3 June 2011 (UTC)

Both, Arthur 2.00 was renamed RISC OS 2.00 before publication. --Egel _Reaction? 17:52, 3 June 2011 (UTC)

It can't be both. In fact, I've thought about it a bit more, and RiscOS was originally called Arthur 2 - pre RiscOS OS systems were called Arthur full stop. I've made a slight change. a_man_alone (talk) 18:06, 3 June 2011 (UTC)

I agree that it now makes more sense than my ambiguous contribution. Thanks. --Trevj (talk) 06:59, 4 June 2011 (UTC)

The way I understand it, the operating system was originally called Arthur, and the subsequent version was to be called Arthur 2, however this was nixed because of the similarity with the name of the film "Arthur 2: On The Rocks" (1988), so the operating system was renamed RISC OS; beginning with RISC OS 2. So in essence, what would have been RISC OS 1 was actually called Arthur, and what would have been Arthur 2 (onwards) was called RISC OS. --HeyRick1973 (talk) 17:43, 8 October 2012 (UTC)

Hi! I think that's what's attributed to the ART factsheet under #History (a summary of History of RISC OS). It'd be better to replace with third party secondary sources, which is something that needs looking at (I have relatively easy access to the relevant '87 mags but will need to refer to later news too, which is less accessible, i.e. not at home). -- Trevj (talk) 07:31, 10 October 2012 (UTC)

From APP118 Archimedes High Performance Computer Systems and APP136 Archimedes 440 the BBC/Acorn MOS version for the Archimedes (300/400) series was named ARTHUR. From the Acorn Newsletters the second (version of the) OS was named RISC OS, the third RISC OS3. --Egel _Reaction? 14:27, 10 October 2012 (UTC)

I am highly amused that my age-old post has prompted such recent activity, especially as we are now talking at a slight tangent to what I was actually asking. What I was querying was the phraseology used in the lede, which originally stated: "RiscOS (initially named Arthur)" My query was that RiscOS was not initially called "Arthur", but was "Arthur II", and even that was not entirely accurate, because it wasn't RiscOS, but RiscOS 2. See how confusing the whole thing was? However, it's always good to talk, and find an excuse to peruse Chris' Acorn stuff. Chaheel Riens (talk) 15:43, 10 October 2012 (UTC)

I've moved the bulk of this content out to A9home, per WP:CFORK. This should make it easier to maintain things. If anyone feels strongly otherwise, please move it back in and/or discuss here. Thanks. --Trevj (talk) 09:54, 13 June 2011 (UTC)

There are some potentially useful references at the bottom of this post. Neil Raine, David Seal, William Stoye and Roger Wilson also presented at the USENIX Computer Graphics Workshop, Monterey, California, 1989 --Trevj (talk) 11:52, 17 June 2011 (UTC)

ROOL's site provides the following commit dates, but AIUI we can't use them within the article because it would count as original research.

Therefore, does anyone know if this kind of information has been previously documented elsewhere, e.g. interviews/articles? --Trevj (talk) 11:25, 29 June 2011 (UTC)

Problem is those dates are a) window manager only (not the OS date) b) the code freeze dates, not the dates they started shipping. So from a public point of view the dates are generally a few months later than that. Anyway, here's some more dates for you ... http://marutan.net/db/modules.php?kModule=12 http://marutan.net/db/modules.php?kModule=1 --Flibble (talk) 13:01, 29 June 2011 (UTC)

Thanks for the other release dates. Yes, it's true that the above ROOL dates are just for the Window Manager and I guess that other parts of the OS required for the respective shipped releases may have been finalised after those dates. (The ROOL MOS dates can also be checked.) Anyway, the reason I've been thinking about dates is because I'm currently reading Andy Hertzfeld's Revolution in the Valley. Therefore, I wondered if it would be interesting from a(n) historical POV to include dates of completed code for functionality included in the major OS releases. Aspects of any large software project presumably have code freezes a considerable time in advance of the product being shipped. In the case of producing ROMs, the fabrication/testing process is probably longer than for magnetic/optical media. But as I said above, it's all WP:NOR AFAIK ATM - unless someone digs something up. Cheers. --Trevj (talk) 09:59, 30 June 2011 (UTC)

I collated a set of useful refs for arthur to 3.7 by combing through Chris's Acorns, the highlights are here User:Flibble/Acorn_Stuff#Refs_per_version, give some dates for some versions.--Flibble (talk) 19:06, 1 July 2011 (UTC)

Nice one. Will see what can be done with that when I get some uninterrupted time to wade through it all. --Trevj (talk) 20:44, 1 July 2011 (UTC)

Now done (first stab). --Trevj (talk) 14:56, 1 July 2011 (UTC)

Added it to the security section.--Flibble (talk) 16:05, 8 July 2011 (UTC)

The edit got discussed on my talk page though it should belong here, so I am clearing up my talk by moving it here.

Hi, since I reverted you and you reverted me back, and I may have been wrong I'll just answer here. Guy Harris is my go too guy for operating systems (and more related stuff) history, and I'm not sure he (or you) owned an Acorn Archimedes like I did, but I'm sure he's more familiar with Mach microkernel than I am. I looked into your edits and see that you are familiar with at least that (and also other things where you was actually reverted (I do not know [Gosling] [Emacs] history to say, but its somewhat interesting..)).

About your RISC OS revert, I have only my memory (WP:OR, I may have thrown out my Programmers Reference Manual or at least not sure where I put it, but I'm fairly confident Acorn didn't use the term "microkernel" there or elsewhere and microkernel/Mach predates RISC OS by a few years) while you have a source kind of (I'm not sure everything2 must be a reliable source or the text good enough: "Almost all components of the operating system were implemented as modules, including the filesystems, the editor, windowing system, etc. [..] In this sense it was a true microkernel OS."). I would just like us all to agree. Mach may not have a monopoly on the microkernel term, it's an umbrella-term, but should we only use it for similar things?

Kernel type may have had less significance in the Acorn brand's documentation. And I am all for getting stronger citation even if it could, as unlikely as that seems, contradict any weaker one already found. A kernel is too well defined in the academic subject of systems programming to lack a type, & RISC OS kernel is not as vague as vaporware to lack a type(aside: makes me wander, do monitor programs of hardware develoment kits boards have types). I tried stereotyping it as monolithic similar to Linux, but to confirm my suspicion kept searching till encountering the citation I've placed, that not only contradicted my opinion, but is logically sound from as much I understand Operating Systems upto this day.--V. S. Chawathe (talk) 20:05, 12 January 2016 (UTC)

Are you all familiar with SWI instruction (now has a new name/or replaced?) to call the OS and that only your user programs where is userspace, at hex 8000. I may not know this all fully, but was only aware of memory protection between user programs at that address, and not OS services located at that address with protection (e.g. I assume then not in userspace).

Yes. So below 0x8000 there was firmware. There's an open sourced RISC OS fork and I was considering contributing to it. By fully you surely mean nobody memorised interrupt service vectors. OS services (Windows lingo analogous to DOS TSR programs and *nix daemons) might be running with root privileges, and being a daemon does not imply always being one of the (protected or otherwise) kernel's constituents.--V. S. Chawathe (talk) 20:05, 12 January 2016 (UTC)

I'm not sure I get your text fully in your edit summary, but anyway autoloading vs. manual loading (that Linux supports both) is not the defining issue(?) of a microkernel. comp.arch (talk) 10:21, 12 January 2016 (UTC)

RISC OS required action originating from user space, whereas Linux kernel running from kernel space can do autoloading. That Linux supports manual matters for "kernel module" developers, rather than being the way of mandatory usage. So the modules from citation are uncomparable to the "kernel modules" from Linux as you had in the good faith comment of edit.--V. S. Chawathe (talk) 20:05, 12 January 2016 (UTC)

And how is this even remotely relevant to microkernels? Guy Harris (talk) 20:22, 12 January 2016 (UTC)

The cause for reversion contrasted Linux kernel modules with RISC OS modules. I was just helplessly going deeper.--V. S. Chawathe (talk) 20:35, 12 January 2016 (UTC)

Well, I'm a Yank, and the Archimedes wasn't a big thing here. My familiarity with Mach comes largely from having been a kernel-level developer for 9 years at a Unix-box company in Cupertino that used a Mach-based kernel :-), although anybody who'd call XNU a microkernel is stretching the definition of a microkernel rather a lot:

$ size /System/Library/Kernels/kernel 
__TEXT  __DATA  __OBJC  others  dec     hex
8388608 1138688 0       1334080 10861376        a5bb40

and that counts only the core kernel, not any loadable kernel modules. File systems and network protocols all run in kernel space. Yes, there are some APIs that might be thought of as "system calls" that involve user-mode helpers, but not many of them, and other UN*Xes have some as well.

So I'm not sure what makes something a "microkernel". The original intent for Mach was to allow a lot of functions performed in kernel-mode code in traditional UNIXes to be moved to user-mode server processes; see, for example, section 8 of the 1986 Mach paper from USENIX. Section 9 of that paper, however, describes a kernel more like XNU, with file systems, etc. living in kernel space. That paper, BTW, doesn't use the term "microkernel"; I'm not sure where the term first occurred.

"The OS is made up of a number of modules. These can be added to and replaced, including soft-loading of modules not present in ROM at run time and on-the-fly replacement." does not indicate a microkernel; plenty of non-microkernel operating systems allow modules to be loaded, either automatically or manually, into the kernel. The author of that Everything2 piece is confused - but, well, as the Wikipedia page on Everything2 says, "Everything2 (styled Everything2), or E2 for short, is a collaborative Web-based community consisting of a database of interlinked user-submitted written material. E2 is moderated for quality, but has no formal policy on subject matter.", so it's pretty much a moderated Wikipedia, and Wikipedia articles are 'NOT' valid sources for Wikipedia. I wouldn't consider it a reliable source.

(And kernel modules in Linux - and OS X, and Solaris, and Windows NT, and so on - can be loaded by user commands; they're not just autoloaded.)

I've reverted the reversion. Vipul, if you want to call it a microkernel, find a real source, not some random post on E2. Guy Harris (talk) 19:52, 12 January 2016 (UTC)

You've reverted it before replying on my reply to comp.arch and I am afraid it seems rather hasty reversion, as if, if anything other than Mach seemed to be microkernel, then you feel your glory being stolen. I am not rereverting as I've tried to clarify my reasoning here, the rest is for the Wikipedeans to rationalize. My part stops.--V. S. Chawathe (talk) 20:28, 12 January 2016 (UTC)

Stale

 – No other discussion participants since July 2011. -- Trevj (talk) 13:33, 31 October 2012 (UTC)

Given, the shared kernel, most of the modules, developers and hardware. I suggest moving the NCOS page into a section on the RISC OS page. With a redirect setup on NCOS.--Flibble (talk) 16:15, 8 July 2011 (UTC)

• CommentOppose I'm not so sure that this would be helpful to readers following the (admittedly small number of) links from articles outside the Acorn/RISC OS subject area. They would then end up at a subsection of RISC OS when following a link to NCOS. Although the kernel, modules, developers and (internal) hardware are very much shared - isn't the OS itself distinct, as it was developed with a different purpose to RISC OS? The merge of Arthur (Operating System) seemed more logical, as it was a previous version of RISC OS, used for the same purposes i.e. desktop computers. NCOS is notable as a standalone article (there are additional references to it, but ISTR that some of these are behind paywalls). Merging the content into RISC OS would probably mean rewording the lead to avoid duplication of stuff like 'It was adapted by Acorn Computers from its own RISC OS, which was originally developed for their range of Archimedes desktop computers.' This would result in the context being less obvious to readers following links to NCOS. Conversely, if this information were to be retained, it would be unnecessary for readers of the main RISC OS article. Additionally, it should be noted that NCOS has been listed elsewhere as a 'Missing encyclopedic article'. --Trevj (talk) 09:24, 11 July 2011 (UTC)

Independently notable, per WP:PRODUCT. -- Trevj (talk) 14:14, 15 March 2012 (UTC)

What?! No Web Browser Information?! Please add web browser information. In-Correct (talk) 04:57, 14 February 2013 (UTC)

Browsers are application software, not part of the Operating System. Is there a more appropriate page dedicated to RISC OS software, where these could be listed? REH11 (talk) 21:20, 24 August 2018 (UTC)

List of RISC OS bundled applications--Egel _Reaction? 14:16, 25 August 2018 (UTC)

This is a list of the emulators that are capable of running RISC OS, I think I've got all of them. I've decided not to commit this directly to the RISC OS article as due to being involved with two of them it is a conflict of interest. However if someone thinks that they're NPOV enough please add them to the page. If there is not a wiki page yet for an emulator it links to the emulators homepage. Also note that the emulators listed at http://en.wikipedia.org/wiki/List_of_computer_system_emulators#Acorn_Archimedes has many issues, not least that many listed are not system emulators.--Flibble (talk) 11:43, 15 February 2013 (UTC)

Are you thinking of this being included within #Supported hardware, where the current emulation info is? Or elsewhere? I don't see a major problem with you adding this yourself (best to clearly declare the COI in the edit summary, as I'm sure you would) but me or someone else will surely be happy to do it otherwise. Just one thing about the external links: they shouldn't really be included within the table, per WP:ELPOINTS. However, there's no reason they can't still be referred to as references in each case. I'm personally convinced that some of these are notable, and have been intending to write at least a stub for RPCEmu for a while now. Sorry about the delay. Finally, ArcEm can be run under RISC OS too - is that the deliberate mistake? Cheers. -- Trevj (talk) 14:18, 15 February 2013 (UTC)

I think that the sentence "Limited software portability exists with subsequent versions of the OS and hardware." Is being unduly harsh towards RISC OS for compatibility issues arising from fundamental changes in the hardware (for instance the combined PC+PSR being split into two things, or the change of behaviour related to unaligned loads). Neither of these are directly the fault of RISC OS; it isn't the same as an OS induced incompatibility (example: Linux when it changed SWI behaviour, or Linux again when it changed to hard float). Indeed, the comment on BBC BASIC programs (which are interpreted so would be (mostly) immune to changes in how the processor operates) demonstrates that RISC OS maintains a reasonably good level of compatibility. Multitasking programs I have written for RISC OS 2 run on RISC OS 5. Single tasking programs from the BBC Micro era run on RISC OS 5! There are, certainly, issues of compatibility with older software (what system doesn't have these sorts of issues?). Could this section be reworded to make it look a little less like RISC OS is arbitrarily incompatible with itself? HeyRick1973 (talk) 11:07, 27 October 2013 (UTC)

You're probably right - I'll have a closer look soon. (I'm currently recovering from the minor shock of finally transitioning User:Trevj/Impression (software) (edit | talk | history | links | watch | logs) - which I'd forgotten about - to Impression (software)! I'll add some further info and refs at some point in the future... but at least that's a starting point which should be robust enough to demonstrate notability.) Cheers. -- Trevj (talk) 18:00, 27 October 2013 (UTC)

While the announcement of RISC OS 5.20 is 24th July 2013 (https://www.riscosopen.org/news/articles/2013/07/24/risc-os-5-20-stable-is-now-available), the downloads page for the builds (say, OMAP3) gives a date for the ROM image almost a year later [Beagle/OMAP3 https://www.riscosopen.org/content/downloads/beagleboard 2014/04/24; Iyonix https://www.riscosopen.org/content/downloads/iyonix 2014/04/24; RiscPC https://www.riscosopen.org/content/downloads/riscpc 2014/04/24; there doesn't appear to be a stable for the RPi or the Panda/OMAP4]. Which would be the best date to use, the announcement (as now) or the date of the actual software (2014/04/24)?

Additionally, the "Latest preview" needs to be changed, though I'm not sure how to do this. The ROOL site runs an autobuilder each night, so the most recent "beta" version of RISC OS available is always "last night". It is disingenuous to suggest it was 19 months ago, when 19 hours is more realistic.

I have also added "loadable ROM image" to the update method, since this is how RISC OS is now most commonly used (on OMAP, Pi...).

HeyRick1973 (talk) 21:58, 12 January 2015 (UTC)

Hello fellow Wikipedians,

I have just added archive links to 2 external links on RISC OS. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

• Added archive https://web.archive.org/20120405190435/http://www.raspberrypi.org/?page_id=43&mingleforumaction=viewtopic&t=919.0 to http://www.raspberrypi.org/?page_id=43&mingleforumaction=viewtopic&t=919.0
• Attempted to fix sourcing for http://www.geocities.com/chris-o/

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers. —^{cyberbot II}_{Talk to my owner:Online} 07:24, 30 August 2015 (UTC)

Hello fellow Wikipedians,

I have just modified 3 external links on RISC OS. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20101110111706/http://www.iyonix.com/iyonix/features/osfeatures.shtml to http://www.iyonix.com/iyonix/features/osfeatures.shtml
• Added archive https://archive.is/20121208135752/http://select.riscos.com/RISCOS6/faq.html to http://select.riscos.com/RISCOS6/faq.html
• Added archive https://archive.is/20130104150342/http://acorn.riscos.com/riscos3/37/37DiscImage/Manuals/AppNote to http://acorn.riscos.com/riscos3/37/37DiscImage/Manuals/AppNote

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

Y An editor has reviewed this edit and fixed any errors that were found.

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 21:52, 2 September 2017 (UTC)

a) About "the first": "The outline font manager provides spatial anti-aliasing of fonts". Change wording to "The outline font manager, first.. provides spatial anti-aliasing of fonts". I.e was anyone before with outline on screen at least (Adobe/PostScript fonts before? But not Display PostScript), just Acorn first with anti-aliasing? drop "spatial", not like temporal applies here..

b) I believe Acorn was first with video ("moving lines", yes, possibly not the best compression..), i.e. before QuickTime, but not bundled with the OS if I recall. Still say something on it (here or on other (Arch] page)? comp.arch (talk) 13:17, 7 November 2017 (UTC)

I thought it referred to anti-aliased fonts in system usage, (such as menus, headings, messages, etc) rather than the use within applications such as !Impression, !Draw or !Poster, for example.

'Course - I may be completely wrong there. Chaheel Riens (talk) 11:35, 8 November 2017 (UTC)

Yes, I'm also talking about as part of the OS (while I do not recall, titles may have been bitmapped..). I'm referring to outline fonts, was someone else first with them non-anti-aliazed (you could also use bitmap e.g. outside of WIMP/windows, i.e. for games). Original MacOS was of course earlier with windows, but it had only bitmapped fonts back then (in screen). The OS could do small outline from the start with anti-aliasing, correct (but didn't use if fonts huge). Some desktop publishing software added rotation of fonts or on a curve. comp.arch (talk) 18:07, 8 November 2017 (UTC)

"ARMv3 first to support 32-bit memory address space (previously 26-bit)." RPCEm is limited to 256 MB, as RiscPC didn't support more. 26-bit meant 64 MB max, but going to 32-bit and high bits not used, it seems 256 only had to be a address bus hardware limitation of the ARM chip and/or RiscPC. Any idea why RPCEm follows that limitation, as e.g. Raspberry Pi has more memory and I assume/d all usable for RISC OS. comp.arch (talk) 10:04, 8 November 2017 (UTC)

Being aware that by answering this I'm breaking the WP:FORUM guidelines. You are confusing two separate things, virtual memory size (26bit, 32bit) with physical memory size. Ask yourself, "why if 26bit addressing supports 64MB of space, did the biggest machine only have 16MB RAM in?". The virtual memory space is divided into sections that map to RAM, ROM, IO space, podule space, VRAM etc, the total amount of all this combined cannot exceed the size of the virtual memory space. This mapping is called a 'memory map' and varies considerably between different hardware. Support for these different memory maps requires specific code in RISC OSs kernel. RPCEmu emulates the memory map of the Risc PC, as such it can use Operating Systems built to run on the Risc PC, but not those versions of RISC OS built for other hardware, with different maps. The Risc PC memory map has a 256MB (2 128MB SIMMS) section in it for RAM, but no more, RISC OS probes how much physical RAM you actually have by writing to memory addresses and checking to see if there are duplicate values at wrapping points in the map (e.g 64MB RAM in one of the two SIMM slots will have the same data at 64MB and 128MB). So in answer to your primary question, there's not a 256MB limit in the OS, but there is in some of the hardware (including emulation of that hardware) that the OS runs on.Flibble (talk) 03:25, 2 September 2018 (UTC)