Talk:RISC OS

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Article milestones
DateProcessResult
January 28, 2011[peer review]Reviewed


Icon bar article merge suggestion[edit]

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
The result was No consensus. --Trevj (talk) 14:19, 21 September 2011 (UTC)[reply]

  • Oppose User:Kvng, what are your reasons for suggesting the merge of the article? Over the years the icon bar article has been neglected somewhat; if you look back to September 2008 you'll see that originally there were several images of the icon bar (one per major OS release), along with descriptions covering any important functional aspects of the bar. This seemed to be in keeping with other bar-related articles (e.g. the Taskbar article). But those images were later deleted by a bot due to not having the correct copyright tags, which then resulted in the associated text being deleted sometime later. So if you suggested that the article should be merged simply because the current version of the article is a bit rubbish, then I think we should at least consider trying to fix it first (Especially since we now have the RISC OS WikiProject to help keep on top of things like this) Phlamethrower (talk) 20:56, 9 February 2011 (UTC)[reply]
  • Oppose merge suggestion. The article will be improved and images again included (e.g. following advice at WP:MSWIN/Licensing). Merging with RISC OS would result in the pruning of information. If and when the RISC OS article becomes too large, it may then require splitting up again (as mentioned above). --trevj (talk) 16:00, 14 February 2011 (UTC)[reply]
User:Kvng, are you seeking further clarification on opposition to the merge proposal? Do you still hold the view that Icon bar should be merged into RISC OS? Although progress on improving this article is slow, it will be improved. As you've made no comment here, the recorded discussions lean towards consensus to keep the article. What do you think, please? Thanks. --trevj (talk) 10:31, 23 March 2011 (UTC)[reply]
The Icon bar is an integral component of the Acorn OS and can be covered in this article. Potential justification for having a separate article is that this article is too long or, as is the case with Taskbar, Icon bar was a topic that wasn't so OS specific. --Kvng (talk) 13:46, 24 March 2011 (UTC)[reply]
The content of Icon bar is currently of comparable length to that for MS Windows within Taskbar, and is longer than the sections on KDE and Gnome in that article. If Icon bar were to be merged with RISC OS, a considered summary of content would require including at Taskbar. Perhaps a longer term solution would actually be to split the content for MS Windows, KDE, Gnome, etc. into separate articles (stubs in some cases). Taskbar could then be a much more generic article, perhaps including a comparision of features between different OS implementations. There would subsequently be little need for OS-specific detail in the text of the article, except perhaps the use of some examples. If this were to be pursued, discussion could be initiated at Talk:Taskbar. --trevj (talk) 14:52, 24 March 2011 (UTC)[reply]
OK, but that's about Taskbar. I still support a merge of Icon bar. WP protocol is that if we can't reach a consensus, things remain as they are. Unless someone new has something new to say, that's probably how it will go down. --Kvng (talk) 19:54, 24 March 2011 (UTC)[reply]
Following the argument that The Icon bar is an integral component of the RISC OS and can be covered in this article, it would also be appropriate to propose:
I don't think that such proposals would meet with consensus approval. --Trevj (talk) 14:54, 8 September 2011 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

BBC BASIC[edit]

BBC BASIC isn't currently within the scope of WP:RISCOS, although it could arguably be included. I'd like to suggest that BBC BASIC link to RISC OS under the relevant section, rather than Acorn Archimedes (discussion at Talk:BBC BASIC). --trevj (talk) 09:56, 29 March 2011 (UTC)[reply]

Converting from list to prose[edit]

The {{Multiple issues}}/{{Prose}} tag means we still need to address a few items. I'm considering the following:

could be moved to List of RISC OS bundled applications (and included in Category:Lists of software)
either rewrite entirely in prose, or move to list(s) as above
revert to prose
could possibly be addressed similarly to 'Features' above?
prose for shorter lists?

--trevj (talk) 10:18, 20 April 2011 (UTC)[reply]

Also worth noting WP:EMBED. --Trevj (talk) 14:57, 17 August 2011 (UTC)[reply]
 Done Features reworded, Bundled applications split out. RISC OS 3 and Work post-Acorn by RISCOS Ltd now at History of RISC OS. --Trevj (talk) 15:36, 26 September 2011 (UTC)[reply]

References[edit]

I'm undoing this edit. The tag was dated Sept 2006 (persumably originating with this tag), and many references have recently been added + some dubious claims removed IIRC. However, the article still lacks some refs, as noted around just one week ago. When we've managed to address these issues, I think the tag could legitimately be removed once more. In the mean time, I'm sure that any reviewing editor from elsewhere would share the view that the tag remain. I hope that makes sense. --Trevj (talk) 06:56, 22 May 2011 (UTC)[reply]

Ambiguous use of the term "Arthur"[edit]

The opening sentence now reads "...RISC OS /rɪskˈˈɛ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)[reply]

Both, Arthur 2.00 was renamed RISC OS 2.00 before publication. --Egel Reaction? 17:52, 3 June 2011 (UTC)[reply]
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)[reply]
I agree that it now makes more sense than my ambiguous contribution. Thanks. --Trevj (talk) 06:59, 4 June 2011 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

Origin of name ?[edit]

Any possibility that "Arthur" was a reference to the Cambridge University Computer Science / Computer Algebra lecturer Dr. Arthur C. Norman ? He IIRC wrote the floating-point and LISP packages for the BBC Micro ... — Preceding unsigned comment added by 88.211.22.194 (talk) 14:07, 6 July 2015 (UTC)[reply]

Early history?[edit]

The history section begins "RISC OS was originally released in 1987 as Arthur 1.20. The next version, Arthur 2, became RISC OS 2 and was made available in April 1989." This is not correct as Arthur 1.20 was the third incarnation of Arthur (arguably the one that mostly worked). The History of RISC OS document itself contradicts the above by saying "was originally released in 1987 as Arthur 0.20, soon followed by Arthur 0.30, and Arthur 1.20. The next version, Arthur 2, became RISC OS 2 and was completed and made available in April 1989.". The thing is, I'm not sure how best to phrase this without it getting ridiculous. Perhaps it should only make brief mention of Arthur and be something like "RISC OS, originally developed from an earlier system called Arthur (1987), was made available in April 1989 as RISC OS 2"? HeyRick, but not logged in 86.214.250.191 (talk) 22:58, 11 August 2017 (UTC)[reply]

References

  1. ^ RISC OS Open - About us: RISC OS Open Limited FAQ

A9home[edit]

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)[reply]

Font Manager[edit]

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)[reply]

Release version commit dates[edit]

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]

Arthur written in BASIC?[edit]

 – Article move after start of discussion. -- Trevj (talk) 08:11, 26 April 2012 (UTC)[reply]

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

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

RISC OS Kernel Type[edit]

RISC OS not a microkernel?[edit]

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[1] 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)[reply]

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)[reply]

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)[reply]

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)[reply]
And how is this even remotely relevant to microkernels? Guy Harris (talk) 20:22, 12 January 2016 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]

NCOS merge suggestion[edit]

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

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)[reply]

  • 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)[reply]
Independently notable, per WP:PRODUCT. -- Trevj (talk) 14:14, 15 March 2012 (UTC)[reply]

NO WEB BROWSER INFORMATION?![edit]

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

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)[reply]
List of RISC OS bundled applications--Egel Reaction? 14:16, 25 August 2018 (UTC)[reply]

RISC OS Emulators[edit]

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)[reply]

RISC OS capable hardware emulators
Emulator Machines Emulated Host Platforms Supported Latest Release
!A310Emu Archimedes RISC OS
Archie Archimedes Windows, DOS 0.9 10th February 2001
Arcem Archimedes Windows, Linux, Mac OS 1.50 16th December 2012
Arculator Archimedes Windows, Linux

0.99 15th August 2009

Virtual A5000 Archimedes Windows 1.4
Red Squirrel Archimedes, Risc PC, A7000 Windows 0.6 28th October 2002
RPCEmu Risc PC, A7000 Windows, Linux, Mac OS, Open BSD 0.8.9 1st January 2012
VirtualRPC Risc PC Windows, Mac OS Update Patch 22nd January 2009
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[2] - is that the deliberate mistake? Cheers. -- Trevj (talk) 14:18, 15 February 2013 (UTC)[reply]

Compatibility between versions?[edit]

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)[reply]

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)[reply]

Latest versions[edit]

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)[reply]

External links modified[edit]

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:

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: 18 January 2022).

  • 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 IITalk to my owner:Online 07:24, 30 August 2015 (UTC)[reply]

External links modified[edit]

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:

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

checkY 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)[reply]

First with outline fonts? (and with video?)[edit]

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)[reply]

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)[reply]
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)[reply]

Is there a 256 MB limitation is some OS version?[edit]

"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)[reply]

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)[reply]