Possible future directions
Rob Kendrick
I'd like to start this post by saying that opinions contained within it
are not to be taken as the views of either my employer, nor any
projects I am involved with. They are entirely personal views and
ideas. It's also my turn to write an outrageously long-winded and
rambling posting.
I have posted this missive to this group, rather than any other, as it
is mostly technical in nature.
I'm sure the majority of people here have a reason for using RISC OS,
be it because they like the hardware, like the OS, like the GUI, like
the applications available for it, or a combination of an or all of
these reasons. In this post, I hope to outline what my opinions are on
how all this has a future, as for some reason people still seem to
manage to misread my intentions, no matter how bluntly I put them.
Firstly, some assumptions;
* The market is small. So small, that new commercial
enterprises are likely to fail, even if by some
miracle they get venture capital.
* It is too late to rescue this market and make it as great as
it once was. There is no possibility of taking on Microsoft,
Apple, Linux etc. They are too well grounded, and have priced
RISC OS out of the market.
* Most, if not all, of the people remaining using RISC OS do so
because it is a hobby, or have time invested in applications
and either cannot moves to something new or cannot afford or
not want to.
* Hardware is a dead-end. The money required to produce a
hardware platform is large, and it simply doesn't exist
anymore in any meaningful quantity.
Let's deal with hardware first.
The last two pieces of RISC OS hardware were not created for the
express purpose of bringing a piece of native RISC OS hardware to
market. Both are bonuses that have fallen out of other projects by
other people. The cost in developing new hardware to run our current
OS is expensive (recently suggested as high as 100K, although I don't
feel it would be so high).
My feeling is that we should completely abandon native hardware if we
wish to continue using and developing RISC OS and software for it.
There any two big reasons for doing this;
* If we can move to off-the-shelf, commodity hardware, we
suddenly have very cheap and very fast hardware.
* We are detached from a single vendor, with more choice
and upgrade paths. No single "point of failure".
Now, the people who stay with RISC OS because they like the hardware
often cite its reliability and its power efficiency. Firstly, it's
perfectly possible to buy and obtain comodity PC hardware with build
quality that rivals anything we have, and at a significantly lower
price. Secondly, the CPU is not the power hog people claim it to be.
The Iyonix, for example, has many power-hungry components that are
shared with PCs; the south bridge, the hard disc, the graphics card,
the ethernet controller (gigabit is a surprisingly large power-sink.)
Putting an ARM CPU in there doesn't suddenly make all these use less
power. Other than those two reasons, I cannot think of any reason to
stick with it; especially as suitable processors are becoming scarcer
and scarcer, and where they do exist, they are not manufactured for
long enough for such a resource-starved ecosystem to be able to cope
with. (So called 'fashion accessories' - many ARM CPUs these days are
produced for perhaps a couple of months before being discontinued.
Such is the life-cycle of a typical ARM-based product.)
This leaves us with the OS, the GUI, and the applications. Let's deal
with the OS next.
RISC OS, under the bonnet, is at least two decades out of date. In
fact, there are design decisions in it that were boggleworthy even at
the time - bizarre solutions to already solved problems that we are now
stuck with. I don't think any user actually sticks with RISC OS
because of the way it ticks underneath, and this is one of the major
issues preventing the platform moving forward.
The GUI. A lot of people like the GUI, and it has a lot of
novel and unique aspects to it that are nice, and people like. There
is a lot of resistance to the other GUIs in the world just because they
do something differently. I believe that most of this is due to
familiarity, rather than superiority of RISC OS's GUI. However, people
like it, and that's fine. It is certianly something that causes people
to want to stick with RISC OS.
Finally, applications. Only a handful of applications under RISC
OS even shine a light to the equivalents elsewhere, however a
combination of pre-existing data, familiarity, and investment in time is
stuck in them. Some applications are very good, and are certainly
worth continuing to use and hoping to continue to use into the future.
Taking all of the above into account, my belief for the best way
forward for RISC OS users' usage patterns to remain is to throw away
the hardware, and throw away the OS.
This may sound extreme, but let me explain. As I have already
described, native hardware will never again complete with commodity PC
hardware in terms of price or performance. Nor is its power
consumption or reliability serious issues.
As for the OS, I do not believe people stick with RISC OS in the
general case because of it, and it is seriously showing its age and
creaking at the sides. It's holding us back, and it's time we retired
it. It's going to be much easier to build on top of something
pre-existing than make RISC OS work in the future, and in the way we
want.
The GUI can be replicated elsewhere fairly easily; it is not a complex
one and there is much infrastructure out there we can already build on.
Software is less easy to replicate elsewhere, so we're stuck with it.
So, here we go:
* Throw away the hardware and OS.
* Build a set of RISC OS-like libraries on another platform
to easy the porting of RISC OS software there.
* Build a RISC OS-like GUI on top.
* Provide an emulator for running software that hasn't been
ported to map SWIs and other API calls to the new native
set of libraries. This emulator could provide an entire
"RISC OS" virtual machine to each app, thus removing all
the problems involved with multiprocessor systems.
Yes, that's an awful lot of work. But it does let us use the latest
and fastest technology, future-proof us, and massively reduces the
work required to bring RISC OS up to date (working on modern hardware
[the drivers are already written] and giving us a more efficient and
faster base OS). Andy yes, it's not likely to actually happen. But I
*do* believe that it's less work than getting RISC OS and its
applications to run on more modern ARM systems, as well as most
likely cheaper. 100K would pay for three software engineer years. I
think you could get a long way towards completing this scheme with
that, while giving us a good, portable basis from which to move
forward. It makes the RISC OS GUI and the applications (which, again,
I have assumed as being the real reasons people stay) an application,
rather than a hardware and OS platform. That's much easier to move
around and adapt in the future.
Thank you for reading.
B.
druck
[big snip]
I'm afaid I have to agree with everything you said, that's the state
of the union, like it or not.
> * Throw away the hardware and OS.
> * Build a set of RISC OS-like libraries on another platform
> to easy the porting of RISC OS software there.
> * Build a RISC OS-like GUI on top.
> * Provide an emulator for running software that hasn't been
> ported to map SWIs and other API calls to the new native
> set of libraries. This emulator could provide an entire
> "RISC OS" virtual machine to each app, thus removing all
> the problems involved with multiprocessor systems.
> Yes, that's an awful lot of work. But it does let us use the latest
> and fastest technology, future-proof us, and massively reduces the
> work required to bring RISC OS up to date (working on modern hardware
> [the drivers are already written] and giving us a more efficient and
> faster base OS). Andy yes, it's not likely to actually happen.
It's also only worth contemplating if their is a viable ongoing market
in RISC OS applications to run on top of whatever this OS is, which
will be updated to take advantage of any new features offered.
Apart from the sterling efforts of the last few developers continuing
to enhance a few existing products, and some talented hobbists
producing a couple of new small utilities each year, I'd argue that is
not the case.
That leaves the majority of use of RISC OS being to run legacy
applications which are no longer in development. All that is required
to do this is an emulator of existing hardare, freezing RISC OS at
some time in the past, which is effectively where it is, and where
its likely to stay.
> 100K would pay for three software engineer years.
At most two years when taxes are taken in to account, even based on
my industry trailing out-in-the-sticks rate of renumeration.
I would dearly like to be proven wrong, and that there are developers
left with the motivation to see RISC OS taken forward, not just for
technical fulfilment, but to provide a platform relevant to the needs
of users.
> Thank you for reading.
Thanks for writing it, it needed saying.
---druck
--
The ARM Club Free Software - http://www.armclub.org.uk/free/
The 32bit Conversions Page - http://www.quantumsoft.co.uk/druck/
Rob Kendrick
druck <ne...@druck.freeuk.com> wrote:
> [big snip]
>
> I'm afaid I have to agree with everything you said, that's the state
> of the union, like it or not.
I'm glad somebody agrees!
> > Yes, that's an awful lot of work. But it does let us use the latest
> > and fastest technology, future-proof us, and massively reduces the
> > work required to bring RISC OS up to date (working on modern
> > hardware [the drivers are already written] and giving us a more
> > efficient and faster base OS). Andy yes, it's not likely to
> > actually happen.
>
> It's also only worth contemplating if their is a viable ongoing
> market in RISC OS applications to run on top of whatever this OS is,
> which will be updated to take advantage of any new features offered.
My view is that there is no market, and pretending such is
disingenuous. My suggestion aims only at retaining the hobbyists'
interests, and allowing users with an investment to continue without
too larger a change.
> Apart from the sterling efforts of the last few developers continuing
> to enhance a few existing products, and some talented hobbists
> producing a couple of new small utilities each year, I'd argue that
> is not the case.
Yes, indeed. No new (large-scale) applications appear to be being
developed; just a handful of current ones being incrementally improved.
> > 100K would pay for three software engineer years.
>
> At most two years when taxes are taken in to account, even based on
> my industry trailing out-in-the-sticks rate of renumeration.
Ah, yes. I was working on the assumption of 33k salaried developers,
which is pretty average these days for a non-graduate
non-highly-experienced developer.
> I would dearly like to be proven wrong, and that there are developers
> left with the motivation to see RISC OS taken forward, not just for
> technical fulfilment, but to provide a platform relevant to the needs
> of users.
I too would like to be proven wrong, but most of the developers (both
hardware and software) have left. That has to tell the users something
about their platform. I fully understand that some users are unable or
unwilling to move elsewhere, which is why I think the only way they'll
manage to cope is if a scheme as I have outlined, or something similar,
is done.
B.
Michael Gerbracht
> * Throw away the hardware and OS.
> * Build a set of RISC OS-like libraries on another platform
> to easy the porting of RISC OS software there.
> * Build a RISC OS-like GUI on top.
> * Provide an emulator for running software that hasn't been
> ported to map SWIs and other API calls to the new native
> set of libraries. This emulator could provide an entire
> "RISC OS" virtual machine to each app, thus removing all
> the problems involved with multiprocessor systems.
In prinziple I agree with the ideas. Or let's say: If this is happening it
would be a good way forward. I also think that the main reason for
continuing using RISC OS is the way the GUI works and this would need to
be transfered. This does not exclude some new ideas but still it should be
very close to what we have now.
I think what would be necessary also is to be able to run all current
applications. Therefore it seems to be necessary that things like BBC
Basic, the SWIs and the Toolbox are available under the new solution. And
I think that the size of this project stoped attempts to do exactly this
in the past (I think it has been tried after Acorn died ten years ago,
when there were a lot more people around). On the positive side one might
attract programms from outside RISC OS (or former RISC OS users) that are
interested to get a new operating system / GUI, which I guess would be
based on Linux.
I see two alternatives, just shorly because they have been mentioned
elsewhere:
1. Port RISC OS to existing ARM hardware. This requires ROOL to open more
code and people to get it running on new hardware. How much work this is I
do not know.
2. Use VA on a small Linux layer that does not get used as operating
system. Such a machine would boot steight into RISC OS and could feel very
native
I agree that this way we do not solve limitations of the OS itself. But
they are more realistic.
Michael
--
Please replace nospam by m.gerbracht when replying by e-mail
C J Craig
druck <ne...@druck.freeuk.com> wrote:
The charm is the simplicity & immaturity of the programs. The
intuitive integration of them by RISC OS. PC programs have so much
"functionality" you need to study them for 3 years at university!
It might be easier to cut down PC programs & improve their "drag &
drop". The advantage of getting rid of 26meg limit & having ready made
drivers is a huge attraction. Perhaps we just need a MAC? (not that I
have tried one).
Think we should have had a share of those huge fines Europe impossed
on M$oft. Where did that money go?
Chris
--
C J Craig
Ch...@skipton.demon.co.uk
Iyonix ARM XScale computer Risc OS 5.11
Adam
> [snip]
That seems fair.
> So, here we go:
>
> * Throw away the hardware and OS.
> * Build a set of RISC OS-like libraries on another platform
> to easy the porting of RISC OS software there.
> * Build a RISC OS-like GUI on top.
> * Provide an emulator for running software that hasn't been
> ported to map SWIs and other API calls to the new native
> set of libraries. This emulator could provide an entire
> "RISC OS" virtual machine to each app, thus removing all
> the problems involved with multiprocessor systems.
What advantage does this have over the existing emulation solutions? I
guess you'd gain some things like memory protection, co-operative
multitasking etc by running legacy apps in a VM, but I'm not sure
that's worth the large amount of work involved.
> Yes, that's an awful lot of work. But it does let us use the latest
> and fastest technology, future-proof us, and massively reduces the
> work required to bring RISC OS up to date (working on modern hardware
> [the drivers are already written] and giving us a more efficient and
> faster base OS). Andy yes, it's not likely to actually happen.
This is the crux though :( Whether your proposal is sensible or not,
it's just another usenet post blowing in the wind. The only possible
way I can imagine it happening would involve a RISC OS hobbyist, with
a bit of nous and vision, winning the lottery and throwing money
around buying up companies and IP and hiring developers.
Adam
P.S. Who's Andy? ;)
VinceH
Paul Vigay <invali...@invalid-domain.co.uk> wrote:
[...]
> If ROOL release the complete OS (as Peter N has said) though,
> surely it might even be possible to port to native X86 hardware?
That's something I'd like as much, if not more, than I'd like to see
a new ARM-based RISC OS computer (since it would mean RISC OS on
cheap hardware) - but I think it's almost as unlikely, if not more so.
And quite apart from anything else, the shared source licence
specifically restricts this from happening IIRC.
--
VinceH
Mr John FO Evans
suggesting why is the usage licence still being retained?
John
--
_ _________________________________________
/ \._._ |_ _ _ /' Orpheus Internet Services
\_/| |_)| |(/_|_|_> / 'Internet for Everyone'
_______ | ___________./ http://www.orpheusinternet.co.uk
Rob Kendrick
Paul Vigay <invali...@invalid-domain.co.uk> wrote:
> I'm not entirely convinced by the environmental equivalents of RISC OS
> hardware vs PS hardware, as the A9 demonstrates it's still possible to
> build extremely efficient machines.
Remember that efficiency has two sides. Spending 5W but taking an hour
to do something is not more efficient than spending 80W and taking 5
seconds.
> If ROOL release the complete OS (as Peter N has said) though, surely
> it might even be possible to port to native X86 hardware?
Sure. And just as possible to port it to your microwave oven. Part of
my suggestion is to /reimplement/ the API of RISC OS elsewhere,
allowing us to /easily/ port it elsewhere. This would most likely
actually be less effort: you're not having to port the OS parts, just
the bits applications talk to.
B.
Rob Kendrick
Adam <ne...@snowstone.org.uk> wrote:
> What advantage does this have over the existing emulation solutions? I
> guess you'd gain some things like memory protection, co-operative
> multitasking etc by running legacy apps in a VM, but I'm not sure
> that's worth the large amount of work involved.
Performance, and movement. Current emulation systems emulate the OS
too - my idea wouldn't. It provides a platform for software to be
easily ported to that has a good grounding.
> > Yes, that's an awful lot of work. But it does let us use the latest
> > and fastest technology, future-proof us, and massively reduces the
> > work required to bring RISC OS up to date (working on modern
> > hardware [the drivers are already written] and giving us a more
> > efficient and faster base OS). Andy yes, it's not likely to
> > actually happen.
>
> This is the crux though :( Whether your proposal is sensible or not,
> it's just another usenet post blowing in the wind. The only possible
> way I can imagine it happening would involve a RISC OS hobbyist, with
> a bit of nous and vision, winning the lottery and throwing money
> around buying up companies and IP and hiring developers.
Of course - almost all the discussion on these groups is blowing in the
wind.
> P.S. Who's Andy? ;)
B.
Rob Kendrick
Mr John FO Evans <mi...@orpheusmail.co.uk> wrote:
> I have one question to ask. If the market is as bad as everyone is
> suggesting why is the usage licence still being retained?
If you're referring to the RISC OS Open licence, I don't know. It's a
complete show-stopper for any of my involvement in the source code.
(It should be noted that I have offered my help to ROOL in ways other
than working on the sources.)
B.
Rob Kendrick
Michael Gerbracht <nos...@cityweb.de> wrote:
> I see two alternatives, just shorly because they have been mentioned
> elsewhere:
>
> 1. Port RISC OS to existing ARM hardware. This requires ROOL to open
> more code and people to get it running on new hardware. How much work
> this is I do not know.
This will be as difficult or more so for the reasons I outlined. It
also means that when that hardware becomes unavailable, we have to
spend the effort again porting elsewhere. Basing a RISC OS-like system
on top of something else means all the porting work will most likely
already be done for us.
> 2. Use VA on a small Linux layer that does not get used as operating
> system. Such a machine would boot steight into RISC OS and could feel
> very native
But doesn't move the OS anywhere - it stays in exactly the same hole it
is now.
B.
Alan
[snip]
This all seems to make sense to me.
Do you think either the ROLF project or ROX-Filer and
ROX-Session are already steps in the direction you
are suggesting?
Regards,
Alan
David Given
[...]
> I'm not entirely convinced by the environmental equivalents of RISC OS
> hardware vs PS hardware, as the A9 demonstrates it's still possible to
> build extremely efficient machines.
The problem with the A9 is that it's ridiculously expensive; 600 pounds
for such a low-power machine is simply not viable. The same amount of
money applied to PC hardware will get you something that's *at least* a
factor of ten faster and more powerful in all ways.
Even if you're sticking with ARM hardware, there are new platforms out
today that are a quarter the price of the A9 *and still more powerful*.
> If ROOL release the complete OS (as Peter N has said) though, surely it
> might even be possible to port to native X86 hardware?
Not a hope in hell, I'm afraid --- RISC OS in its current form is
intrinsically tied to ARM hardware. Making it work on non-ARM platforms
will be the small, simple job of redesigning all the APIs and rewriting
all the source code and applications...
--
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ───── http://www.cowlark.com ─────
│ "...it's not that well-designed GUI's are rare, it's just that the
│ three-armed users GUI's are designed for are rare." --- Mike Uhl on
│ a.f.c
Dave Higton
Rob Kendrick <nn...@rjek.com> wrote:
> The GUI. A lot of people like the GUI, and it has a lot of
> novel and unique aspects to it that are nice, and people like. There
> is a lot of resistance to the other GUIs in the world just because they
> do something differently. I believe that most of this is due to
> familiarity, rather than superiority of RISC OS's GUI. However, people
> like it, and that's fine. It is certianly something that causes people
> to want to stick with RISC OS.
Let me put it this way: after many years of familiarity with both
RISC OS and Windows, it's the Windows GUI that makes me feel daily
like hurling a brick through the monitor. I have /never/ felt that
when using RISC OS.
> Finally, applications. Only a handful of applications under RISC
> OS even shine a light to the equivalents elsewhere, however a
> combination of pre-existing data, familiarity, and investment in time is
> stuck in them. Some applications are very good, and are certainly
> worth continuing to use and hoping to continue to use into the future.
Zap is one of the reasons I transfer files from my PC to my RISC
PC at work.
Dave
Doug
>
>> 2. Use VA on a small Linux layer that does not get used as operating
>> system. Such a machine would boot steight into RISC OS and could feel
>> very native
>
> But doesn't move the OS anywhere - it stays in exactly the same hole it
> is now.
>
> B.
>
Rob,
I agree with what you say overall as a lot of it makes sense and is
pragmatice but I do think that the Linux one could be used to further
things if it is used as an intermediate stage to in effect provide hooks
in RISC OS to an expanding underlying Linux base to give additional
functionality .
Over time things could move towards your suggestion.
If done right your suggestion could be used to start the move process
and at the same time give something perhaps more immediately available ,
always assuming of course that a version of RISCOS could be sourced and
made available for a Linux distribution.
Well there is always one flaw in a plan :-)
David Given
[...]
> I'd like to start this post by saying that opinions contained within
> it are not to be taken as the views of either my employer, nor any
> projects I am involved with. They are entirely personal views and
> ideas. It's also my turn to write an outrageously long-winded and
> rambling posting.
First off... yes, I agree with pretty much all of this. More on the
politics later, though.
[...]
> RISC OS, under the bonnet, is at least two decades out of date. In
> fact, there are design decisions in it that were boggleworthy even at
> the time - bizarre solutions to already solved problems that we are
> now stuck with.
Definitely. The latest thing I found with my experimentation was a
comment in the OS_Heap code that states that there's special code that
pokes through the stack looking for reentrant calls to the heap
routines... which is vile enough; but the reason for this is to allow
memory allocation from interrupt handlers. Ew ew ew ew! If I'd come up
with that idea as a novice programmer I'd expect my peers to slap me
around the face until I got better. As a seasoned programmer now, if I
started thinking about doing that I'd slap *myself* around the face
until I got better. Memory allocation from an interrupt handler is a
*bad* idea. There's an awful lot of this stuff in the kernel.
[...]
> The GUI. A lot of people like the GUI, and it has a lot of novel and
> unique aspects to it that are nice, and people like.
After nearly a decade, going back to doing stuff with the RISC OS GUI
feels like putting on a worn-in glove --- everything's where I expect it
to be, and everything makes sense, which Ubuntu and Windows certainly don't.
However, there is no place in the world today for a GUI that doesn't
support keyboard navigation.
[...]
> * Provide an emulator for running software that hasn't been ported to
> map SWIs and other API calls to the new native set of libraries.
> This emulator could provide an entire "RISC OS" virtual machine to
> each app, thus removing all the problems involved with multiprocessor
> systems.
Oddly enough, my experimentation is doing exactly this.
What I've got is a fairly simple but working RISC OS module stack
sitting on top of a custom kernel. The kernel exists as a single task in
another operating system; currently OKL4 because it's easy, but I'd
rather use something like Prex instead (Prex is a very elegant
BSD-licensed microkernel OS, not dissimilar to Minix but cleaner;
http://prex.sourceforge.net). The kernel provides SWI dispatch and basic
functionality. Everything else happens in modules.
All SWI handlers run in user mode; I have written *no* code that
requires supervisor mode. Device drivers won't run, of course, but they
wouldn't run anyway. Because it's all in user mode --- including kernel
SWIs, by the way, they're dispatched by the normal SWI dispatch
mechanism --- it would be very easy to lift the entire software stack
and drop it down on top of a different kernel; something based on qemu,
for example, which means you wouldn't be stuck with ARM hardware.
What's interesting here is that I don't have to reimplement huge swathes
of code. I'm mostly running Acorn's original stuff, which is far less
effort. I've done some playing with the ROOL source and have managed to
move some simple bits of functionality --- OS_PrettyPrint, for example
--- into standalone modules.
And yes, there's nothing whatsoever to stop me running multiple VMs
concurrently.
Earlier I promised you politics:
> * It is too late to rescue this market and make it as great as
> it once was. There is no possibility of taking on Microsoft,
> Apple, Linux etc. They are too well grounded, and have priced
> RISC OS out of the market.
The world today is very business oriented, which means that people keep
thinking of things from the business perspective. This is incorrect.
Businesses have to be successful or die, which means they continually
have to struggle to Win, because if they don't, they die. Once you
realise it's not necessary to be a business, you realise that you don't
have to Win.
For example, Windows vs. Linux. That fight is completely one-sided;
Windows is a business, therefore it must crush its opponents. Linux is
*not* a business. This means it's not crushable. It merely has to be
useful; it does not have to Win. Even if Canonical, Red Hat, etc all get
pulled down by the might of Microsoft, Linux can never lose.
As a more extreme example, look at the BSDs --- they're as niche as they
get. And they're useful, extremely so, and are used.
So if RISC OS stops trying to Win, what options are there? Well, not a
lot, to be honest. Even assuming that the unpleasant ROOL license gets
relaxed to a decent one, the code base is ancient and full of cruft. And
yet it does actually work. I, personally, would be interested in a
stripped down RISC OSalike as a boot loader and monitor for ARM-based
development hardware. I can imagine other situations where something
similar could be useful; how about a GUI-based hypervisor console that
lived in four megabytes? Or a high-crypto OS-on-a-USB-stick? All nice
roles, of course, but who cares? It doesn't have to Win; it just has to
be useful.
Rob Kendrick
Alan <alan...@hotmail.com> wrote:
> This all seems to make sense to me.
>
> Do you think either the ROLF project or ROX-Filer and
> ROX-Session are already steps in the direction you
> are suggesting?
ROX I suspect is not the way to go - it's an implementation of a
handful of RISC OS idioms in a very UNIX and X-centric fashion. I
think most die-hard RISC OS users would find it disappointing.
ROLF is certainly closer to the mark, but again it's more about
producing something that looks like RISC OS, rather than something
that's a viable target for porting to. It's certainly made some design
decisions that I wouldn't have made, but then again it's much further
along than anything I'm suggesting.
B.
James Peacock
> On Wed, 1 Oct 2008 04:49:22 -0700 (PDT)
> Alan <alan...@hotmail.com> wrote:
>
>> This all seems to make sense to me.
>>
>> Do you think either the ROLF project or ROX-Filer and
>> ROX-Session are already steps in the direction you
>> are suggesting?
>
> ROX I suspect is not the way to go - it's an implementation of a
> handful of RISC OS idioms in a very UNIX and X-centric fashion. I
> think most die-hard RISC OS users would find it disappointing.
I'd back this up. The problem is that most applications don't really
cooperate on other platforms. You can use the clipboard and
occasionally drag files into X and Windows applications, but that is
as far as it goes. It really feels very primitive compared to directly
dragging between applications, or even using the save box.
James
Rob Kendrick
David Given <d...@cowlark.com> wrote:
> > * Provide an emulator for running software that hasn't been ported
> > to map SWIs and other API calls to the new native set of libraries.
> > This emulator could provide an entire "RISC OS" virtual machine to
> > each app, thus removing all the problems involved with
> > multiprocessor systems.
>
> Oddly enough, my experimentation is doing exactly this.
>
> What I've got is a fairly simple but working RISC OS module stack
> sitting on top of a custom kernel. The kernel exists as a single task
> in another operating system; currently OKL4 because it's easy, but I'd
> rather use something like Prex instead (Prex is a very elegant
> BSD-licensed microkernel OS, not dissimilar to Minix but cleaner;
> http://prex.sourceforge.net). The kernel provides SWI dispatch and
> basic functionality. Everything else happens in modules.
I'm really interested in this project from the fun hack point of view,
but I think it'd still suffer from the same issue of hardware support.
Of course, I doubt writing an L4 API emulation layer on top of another
OS would be difficult (I've done this with QNX in the past), and would
give us a nice elegant API to work to for such things. But my plan
basically left all kernel functionality to somebody else; mainly
because it's already been done better than we can ever hope to.
>
> Earlier I promised you politics:
>
> The world today is very business oriented, which means that people
> keep thinking of things from the business perspective. This is
> incorrect. Businesses have to be successful or die, which means they
> continually have to struggle to Win, because if they don't, they die.
> Once you realise it's not necessary to be a business, you realise
> that you don't have to Win.
>
> For example, Windows vs. Linux. That fight is completely one-sided;
> Windows is a business, therefore it must crush its opponents. Linux is
> *not* a business. This means it's not crushable. It merely has to be
> useful; it does not have to Win. Even if Canonical, Red Hat, etc all
> get pulled down by the might of Microsoft, Linux can never lose.
In the main, I agree. However, if everybody stopped using Linux apart
from a few die-hard users, I'd argue that's the equivalent of dying.
Free Software projects /can/ die - it's just the cause and effect is
very different from that of a business.
B.
Rob Kendrick
Dave Higton <daveh...@dsl.pipex.com> wrote:
> Let me put it this way: after many years of familiarity with both
> RISC OS and Windows, it's the Windows GUI that makes me feel daily
> like hurling a brick through the monitor. I have /never/ felt that
> when using RISC OS.
Certainly Windows routinely irritates me, and I only touch it if I have
to. However, it does have some nice GUI features that would be nice to
have. It's not fair to tar it all with the same brush in that respect,
or automatically shun any feature it has just because of the cruft it
does have.
> > Finally, applications. Only a handful of applications under RISC
> > OS even shine a light to the equivalents elsewhere, however a
> > combination of pre-existing data, familiarity, and investment in
> > time is stuck in them. Some applications are very good, and are
> > certainly worth continuing to use and hoping to continue to use
> > into the future.
>
> Zap is one of the reasons I transfer files from my PC to my RISC
> PC at work.
I certainly used to do this when I moved to Linux. Zap is nice.
In fact, at the moment, I'm writing tools to convert Zap bitmap fonts
for use with a framebuffer port of NetSurf. However, I have learnt the
power of the dark side of the force. I'm expert in both the use of Zap
(at least, 1.35) and Vim, and I get far more done in Vim these days. I
do still pine for certain aspects of Zap, such as its nicely integrated
binary editing modes, and the search function that goes to a buffer
like any other - so you can do subsearches, etc. But none of this
elegance really matters when I can get what I need done in
significantly less time in Vim.
B.
Rob Kendrick
Paul Vigay <invali...@invalid-domain.co.uk> wrote:
> > Even if you're sticking with ARM hardware, there are new platforms
> > out today that are a quarter the price of the A9 *and still more
> > powerful*.
>
> But running from 4 watts of electricity....?
>
> I'm looking for something that will run from solar panels for use when
> electricity runs out and we've had 'Bush's global apocalypse' ;-)
You think you'll be able to see the sun? >:)
I suspect if this happens, you'll have more important things to worry
about than check your email or prepare a newsletter.
I have a solar panel thingy that's quite able to recharge my laptop's
battery reasonably quickly, incidentally.
B.
Rob Kendrick
David Given <d...@cowlark.com> wrote:
> Paul Vigay wrote:
> [...]
> > I'm not entirely convinced by the environmental equivalents of RISC
> > OS hardware vs PS hardware, as the A9 demonstrates it's still
> > possible to build extremely efficient machines.
>
> The problem with the A9 is that it's ridiculously expensive; 600
> pounds for such a low-power machine is simply not viable. The same
> amount of money applied to PC hardware will get you something that's
> *at least* a factor of ten faster and more powerful in all ways.
More importantly, given how much more it costs, it'll take a /long/
time for any electricity saving to pay back the premium.
> > If ROOL release the complete OS (as Peter N has said) though,
> > surely it might even be possible to port to native X86 hardware?
>
> Not a hope in hell, I'm afraid --- RISC OS in its current form is
> intrinsically tied to ARM hardware. Making it work on non-ARM
> platforms will be the small, simple job of redesigning all the APIs
> and rewriting all the source code and applications...
And thus you might as well just reimplement the lot, as it's less work
and yields something better; which is essentially what my suggestion
boils down to.
B.
Rob Kendrick
Doug <doug....@btinternet.com> wrote:
> I agree with what you say overall as a lot of it makes sense and is
> pragmatice but I do think that the Linux one could be used to further
> things if it is used as an intermediate stage to in effect provide
> hooks in RISC OS to an expanding underlying Linux base to give
> additional functionality .
I'm not sure what you're getting at. Linux is just one possibility to
base such a venture on. There are plenty of others. Linux, however,
does have very good hardware support (even excellent ARM support), and
is very very fast and efficient in almost every way RISC OS is not. My
suggestion simply uses it as a kernel; the interface to hardware. Do
not confuse my idea as being RISC OS on top of UNIX.
B.
David Given
[...]
> But running from 4 watts of electricity....?
2 watts, actually.
http://en.wikipedia.org/wiki/Beagle_Board
That doesn't include any hard disk or screen, of course. And it is a bit
shy of memory. You may want to get one of these instead when they become
available:
http://en.wikipedia.org/wiki/Pandora_(console)
More expensive, but it's based around the same CPU (probably the same
reference design, TBH) but in a PDA/games console form factor.
Rob Kendrick
David Given <d...@cowlark.com> wrote:
> Paul Vigay wrote:
> [...]
> > But running from 4 watts of electricity....?
>
> 2 watts, actually.
>
> http://en.wikipedia.org/wiki/Beagle_Board
>
> That doesn't include any hard disk or screen, of course. And it is a
> bit shy of memory.
What's annoying about the Beagle Board is that I'm sure it's being
subsidised by TI. The whole board is cheaper than you can buy just the
CPU!
B.
David Given
[...]
> I'm really interested in this project from the fun hack point of view,
> but I think it'd still suffer from the same issue of hardware support.
> Of course, I doubt writing an L4 API emulation layer on top of another
> OS would be difficult (I've done this with QNX in the past), and would
> give us a nice elegant API to work to for such things. But my plan
> basically left all kernel functionality to somebody else; mainly
> because it's already been done better than we can ever hope to.
It doesn't need L4 at all, TBH. The only reason I used it was because it
makes tinkering with other people's threads very easy (thread A does an
SWI, the kernel blocks it, sends an IPC message to the event loop of
thread B, which changes the registers, replies to the message, and
thread A resumes). Also, it abstracts over all the hideous MMU stuff. L4
is really heavyweight for these purposes, which is why I'm interested in
Prex. It's not as flexible, but provides all the necessary functionality
and is much smaller (and with a nicer license). Alas, nobody's done an
ARM-MMU version of Prex yet. (There's a Game Boy Advance version, but it
doesn't have an MMU, and the memory map's all wrong for RISC OS. Alas.)
But fundamentally, once the memory map is set up, the *only* thing the
dispatch system requires is that when an SWI occurs, the kernel changes
R13user to the system stack, pushes the old R13user and SWI number onto
it, and jumps to the user SWI dispatch routine. Everything else happens
in 'user mode'.
Of course, I'm conveniently forgetting all about IRQs and stuff,
assuming that it's no longer RISC OS's responsibility to touch hardware
at all.
This is all going to get BSD licensed at some point, once I get it to an
interesting point. Currently I'm playing with FileSwitch and wondering
whether it's salvageable. I suspect not.
[...]
> In the main, I agree. However, if everybody stopped using Linux apart
> from a few die-hard users, I'd argue that's the equivalent of dying.
> Free Software projects /can/ die - it's just the cause and effect is
> very different from that of a business.
It's much harder, though. Again, look at the BSDs --- they're so
fragmented they're *only* used by die-hard users. And yet they're still
highly influential and well thought of.
druck
> That's something I'd like as much, if not more, than I'd like to see
> a new ARM-based RISC OS computer (since it would mean RISC OS on
> cheap hardware) - but I think it's almost as unlikely, if not more so.
What cheap hardware is this? Despite the ARM chip itself costing a
mere fraction of that of an x86 processor, ARM based devices, except
for the extreme low end devices or mobile phone heavily subsidised as
part of a contract, isn't cheap.
Compare the price of a PDA (if you can still find one with out mobile
capability) or a Nokia web tablet against that of the vast range of
Small Cheap Computers such as the EEE PC, Asus Aspire, MSI Wind etc.
The SCC's are far more capable than the ARM devices, and due to their
commonality with the economises of scale of the x86 ecosystem, a lot
cheaper than ARM systems.
---druck
--
The ARM Club Free Software - http://www.armclub.org.uk/free/
The 32bit Conversions Page - http://www.quantumsoft.co.uk/druck/
Rob Kendrick
druck <ne...@druck.freeuk.com> wrote:
> On 1 Oct 2008 VinceH <sp...@softrock.co.uk> wrote:
> > That's something I'd like as much, if not more, than I'd like to see
> > a new ARM-based RISC OS computer (since it would mean RISC OS on
> > cheap hardware) - but I think it's almost as unlikely, if not more
> > so.
>
> What cheap hardware is this? Despite the ARM chip itself costing a
> mere fraction of that of an x86 processor, ARM based devices, except
> for the extreme low end devices or mobile phone heavily subsidised as
> part of a contract, isn't cheap.
The scales are different, certainly. However, the CPU used in the
likes of the Neo Freerunner mobile phone, the A9 Home, TomTom
navigation aids, etc, can all be had for less than a tenner each.
B.
druck
> Definitely. The latest thing I found with my experimentation was a
> comment in the OS_Heap code that states that there's special code that
> pokes through the stack looking for reentrant calls to the heap
> routines... which is vile enough; but the reason for this is to allow
> memory allocation from interrupt handlers. Ew ew ew ew! If I'd come up
> with that idea as a novice programmer I'd expect my peers to slap me
> around the face until I got better. As a seasoned programmer now, if I
> started thinking about doing that I'd slap *myself* around the face
> until I got better. Memory allocation from an interrupt handler is a
> *bad* idea. There's an awful lot of this stuff in the kernel.
A very good example. RISC OS is full of such hacks to make interrupt
and callback code hang together. Whilst the user level APIs are
pleasant enough, when you need to get in to the internals, you realise
just how horrible it is, and much tearing out of hair is involved.
It makes me laugh when Paolo WhatsHisFace comes along and says, "we'll
just make it all re-entrant and multi-threaded". He just doesn't know.
> What I've got is a fairly simple but working RISC OS module stack
> sitting on top of a custom kernel.
Very interesting, keep us informed on your progress on this.
David Holden
On 2-Oct-2008, Rob Kendrick <nn...@rjek.com> wrote:
> The scales are different, certainly. However, the CPU used in the
> likes of the Neo Freerunner mobile phone, the A9 Home, TomTom
> navigation aids, etc, can all be had for less than a tenner each.
I think the point druck was trying to make is that although the cost of an
ARM processor is probably a lot less than an x86 chip the cost saved on a
single component is only a small percentage of the overall cost of the
entire populated PCB. In fact, since the necessary support chips for the x86
would probably be cheaper than the equivalents for an ARM processor (due
mainly to them being produced in bigger numbers) overall the cost might even
be higher.
--
David Holden - APDL - <http://www.apdl.co.uk>
Rob Kendrick
Paul Vigay <invali...@invalid-domain.co.uk> wrote:
> You have /got/ to be having a laugh. You're in danger of losing all
> credibility there.
>
> Vim is totally awful, and hardly a step up from vi.
> Compared to !Zap it's like using Edit, or even Windows Notepad.
You clearly have never actually used it. Vim is a superb editor, and
is a mindbogglingly large step up from Vi. It's like going from Edit
to TechWriter. Your posting simply has no base in reality at all.
B.
Rob Kendrick
From the point of view of the A9 Home, the CPU is an SoC. It has all
the complex and expensive support hardware on it already. The things
that make the A9 Home expensive are the cost of RISC OS, and its
manufacture bulk. Not the contents of the box.
B.
VinceH
> > That's something I'd like as much, if not more, than (since it
> > would mean RISC OS on cheap hardware) - but I think it's almost
> > as unlikely, if not more so.
> What cheap hardware is this? Despite the ARM chip itself costing a
> mere fraction of that of an x86 processor, ARM based devices,
> except for the extreme low end devices or mobile phone heavily
> subsidised as part of a contract, isn't cheap.
Well done for reading my comment as exactly the opposite of what I
really meant.
Paul suggested the possibility of porting to x86 - and *that* is what
the cheap hardware was referring to: not the ARM-Based RISC OS
computer. A balls up of the wording in first line didn't help, but I
don't think it was *that* unclear. To rephrase slightly:
[a port to x86] is something I'd like as much as, if not more than
I'd like to see a new ARM-based RISC OS computer (since [a port]
would mean RISC OS on cheap hardware).
But it won't happen because of the work involved and, as I said, IIRC
a licence restriction.
--
VinceH
Rob Kendrick
Paul Vigay <invali...@invalid-domain.co.uk> wrote:
> In a dim and distant universe
> <20081002084...@trite.i.flarn.net.i.flarn.net>,
> Rob Kendrick <nn...@rjek.com> enlightened us thusly:
>
> > You clearly have never actually used it. Vim is a superb editor,
> > and is a mindbogglingly large step up from Vi. It's like going
> > from Edit to TechWriter. Your posting simply has no base in
> > reality at all.
>
> I have used it quite extensively, on my *nix boxes. I think you
> forgot to say "ymmv". :-)
You've clearly made no effort to actually use it past mashing in your
content, and using :wq, then.
To say it's like Edit or Notepad shows an utter disregard for facts.
And you're not one to talk about creditability :)
B.
Theo Markettos
> What's annoying about the Beagle Board is that I'm sure it's being
> subsidised by TI. The whole board is cheaper than you can buy just the
> CPU!
Are you sure that's not just a volume thing? $150 doesn't sound very cheap
for a CPU. Usually it's much, much cheaper (order or two of magnitude,
sometimes) to buy these things at the factory gate in China in batches of
100,000 than it is to buy one-offs from the distributor in the UK.
(That's why everyone here asks for samples, because it just saves a whole
lot of hassle)
Theo
David Given
[...]
> What's annoying about the Beagle Board is that I'm sure it's being
> subsidised by TI. The whole board is cheaper than you can buy just the
> CPU!
Um, the OMAP3530 (which is the package containing the Cortex A8 CPU core
used in the BeagleBoard) is available from TI for $58 per item (in
quantities of 100):
http://focus.ti.com/docs/prod/folders/print/omap3530.html
--
David Given
d...@cowlark.com
Rob Kendrick
Try it.
B.
David Given
[...]
> Try it.
Um, huh?
Those are the prices that TI give. Samples, as well, which means that
they're likely to be inflated compared to the prices in bulk that the
people at Pandora are going to get. What do you mean?
--
David Given
d...@cowlark.com
Rob Kendrick
David Given <d...@cowlark.com> wrote:
> > Try it.
>
> Um, huh?
>
> Those are the prices that TI give. Samples, as well, which means that
> they're likely to be inflated compared to the prices in bulk that the
> people at Pandora are going to get. What do you mean?
They are a complete ballache to obtain at anything like that price.
B.
David Given
[...]
> They are a complete ballache to obtain at anything like that price.
Mmm. Citations?
--
David Given
d...@cowlark.com
Rob Kendrick
David Given <d...@cowlark.com> wrote:
> Rob Kendrick wrote:
> [...]
> > They are a complete ballache to obtain at anything like that price.
>
> Mmm. Citations?
Personal experience of actually trying to obtain them.
B.
David Given
[...]
> Personal experience of actually trying to obtain them.
How many did you try to buy?
--
David Given
d...@cowlark.com
Keith Hopper
Michael Gerbracht <nos...@cityweb.de> wrote:
[snip]
> I see two alternatives, just shorly because they have been mentioned
> elsewhere:
> 1. Port RISC OS to existing ARM hardware. This requires ROOL to open more
> code and people to get it running on new hardware. How much work this is I
> do not know.
> 2. Use VA on a small Linux layer that does not get used as operating
> system. Such a machine would boot steight into RISC OS and could feel very
> native
> I agree that this way we do not solve limitations of the OS itself. But
> they are more realistic.
What, however, about the z_VM approach? I know that this is cuurently
IBM mainframe stuff, but VM itself has been around in various guises for
many years - and IBM do put Linux on top of it. I have no idea about the
status of VM itself - PD SW or strictly proprietary. My gueass is that it
should not be impossible to put RISCOS on top of VM and skip the linux bit
inbetween - unless you run that in another VM partition!!
Ignoring file systems and peripheral drivers it should be possible to
get a VM into less than 100kbytes of memory - including memory management,
exception handling, multi-threading, message management and module/driver
management.
IBMs VM has a basic disc storage and raw peripheral facility too, so
it would seem to offer something worth thinking about - and would
automatically provide pre-emptive multi-tasking.
Thinking outside the square - for once!!
Keith
--
Inspired!
Rob Kendrick
Keith Hopper <asg...@inspire.net.nz> wrote:
> What, however, about the z_VM approach? I know that this is
> cuurently IBM mainframe stuff, but VM itself has been around in
> various guises for many years - and IBM do put Linux on top of it. I
> have no idea about the status of VM itself - PD SW or strictly
> proprietary. My gueass is that it should not be impossible to put
> RISCOS on top of VM and skip the linux bit inbetween - unless you run
> that in another VM partition!!
VM is proprietary and is only available for IBM's very big bits of
kit. Porting an RISC OS to it would be many times more difficult than
even porting it to x86.
> Ignoring file systems and peripheral drivers it should be
> possible to get a VM into less than 100kbytes of memory - including
> memory management, exception handling, multi-threading, message
> management and module/driver management.
I have no idea what you're trying to get at, but you seem to be
describing a hypervisor that would in no way aid us.
B.
Dave Higton
Paul Vigay <invali...@invalid-domain.co.uk> wrote:
> In a dim and distant universe <8a309ae74f...@dsl.pipex.com>,
> Dave Higton <daveh...@dsl.pipex.com> enlightened us thusly:
> [Snippety snip]
>
> > Let me put it this way: after many years of familiarity with both RISC OS
> > and Windows, it's the Windows GUI that makes me feel daily like hurling a
> > brick through the monitor. I have /never/ felt that when using RISC OS.
>
> I couldn't have said it better myself. :-)
Thank you :-)
Today's example: I wanted to compare two DebugView captures. It's
easy to put one window over the other, displaced vertically so you
can compare a few lines. But every time you scroll the rearmost
window, it leaps to the front!
Do the people who write Windows never actually use it?
Dave
druck
As I said the cost of the processor has little bearing on the cost of
any device sophisticated enough to potentially run RISC OS.
druck
> [a port to x86] is something I'd like as much as, if not more than
> I'd like to see a new ARM-based RISC OS computer (since [a port]
> would mean RISC OS on cheap hardware).
A port to x86 is a complete waste of time. You'd expend a huge amount
of effort moving the OS over, and then have at most two or three
recompiled x86 applications to run it. Everthing else would still have
to be run under an emulator. You'd get a small performance benefit
from the native OS code, but undoubtedly lots of compatibility issues.
However, at the end of the day you've done all that work, but have
nothing significantly different from Virtual Risc PC as far as any
user is concerned.
RISC OS already runs on cheap hardware, what it needs is for the
emulator to run over a cheap OS. And that's hell of a lot easier
as its already been done, but Aaron wont let you have it.
Jeremy Nicoll - news posts
> What, however, about the z_VM approach? I know that this is cuurently
> IBM mainframe stuff, but VM itself has been around in various guises for
> many years - and IBM do put Linux on top of it. I have no idea about the
> status of VM itself - PD SW or strictly proprietary.
It'll be proprietary. More to the point though is that (excluding the
Hercules S/360, S/370, S/390 etc emulator) VM will be coded for the
instruction set on those machines (plus I think some very specific OS
'assist' microcode). (The first IBM mainframes I used were 4331s running
VM; later I worked with 3990s etc, which had essentially a pair of 4331s
running embedded inside them as 'processor controllers' doing dedicated
hardware monitoring, tracing etc. If one looked hard at the hardware
control terminals (ie the 'system console') one could see the "DMS"-prefix
messages that showed CMS running some of the code.
IBM also have PR/SM which provides virtualisation of processors, real,
edxtended memory etc and allows multiple 'partitions' each appearing to be a
whole real multi-processor machine to run within one (n-cpu) real machine.
> My gueass is that it should not be impossible to put RISCOS on top of VM
> and skip the linux bit inbetween - unless you run that in another VM
> partition!!
And who exactly is going be able to lay their hands on a spare /390 machine
to do that? They're not cheap, nor are the softeware licences. It's not
going to bring the prospect of a laptop any closer, is it?
--
Jeremy C B Nicoll - my opinions are my own.
VinceH
[Complete effing snip]
Oh, FFS. To reiterate the *fundamental point* of my original post,
which is the very basic point that you have completely failed to get:
* Paul Vigay said something like "couldn't it be ported to x86?"
* My reply was essentially,"(I'd like that but,) *IT AIN'T GONNA
HAPPEN*"
I've specified almost no reasons, but alluded to the fact that I
*know* there are reasons, and know what those reasons are. The two
reasons I *did* give, though, are:
1) The amount of work involved - my mention of which you snipped
(John Cartmell stylee, with no indication[1]) and then pointed out
yourself.
2) The legal aspect (one of the shared-source licence conditions)
There are more reasons. You know that, and went on to explain some. I
know that, and in my original post, where I *only* specifically
mentioned the licence condition, I mentioned it thusly:
In article <4fe75ca...@softrock.co.uk> (the one you originally
misunderstood) I said:
> > > > And quite apart from anything else, the shared source licence
> > > > specifically restricts this from happening IIRC.
The whole point of the phrase "And quite apart from anything else" is
to indicate [that I know] that there are more reasons that the one I
then proceeded to give.
But, like my reference to the work involved, you *also* snipped that
with no indication[1].
You are being John Cartmell in his absence and I claim my five pounds.
[1] I did the same in my reply to you, but while two wrongs don't
make a right I couldn't give TSAAF under the circumstances.
--
VinceH
Mr John FO Evans
> emulator to run over a cheap OS. And that's hell of a lot easier
> as its already been done, but Aaron wont let you have it.
Are we still tangled up with licensing? If so does this slow down attenpts
to find even a limited way forward?
John
--
_ _________________________________________
/ \._._ |_ _ _ /' Orpheus Internet Services
\_/| |_)| |(/_|_|_> / 'Internet for Everyone'
_______ | ___________./ http://www.orpheusinternet.co.uk
VinceH
Mr John FO Evans <mi...@orpheusmail.co.uk> wrote:
> In article <59db2ee8...@druck.freeuk.net>, druck
> <ne...@druck.freeuk.com> wrote:
> > RISC OS already runs on cheap hardware, what it needs is for the
> > emulator to run over a cheap OS. And that's hell of a lot easier
> > as its already been done, but Aaron wont let you have it.
> Are we still tangled up with licensing? If so does this slow down
> attenpts to find even a limited way forward?
What Druck is talking about there is VirtualAcorn, and the
possibility of porting it to/running it on one or more of the various
Linux distros. Aaron has said this isn't going to happen because of
concerns he has regarding support issues, IIRC.
--
VinceH
Rob Kendrick
Paul Vigay <invali...@invalid-domain.co.uk> wrote:
> I can't see that Linux support issues are going to be any worse than
> Windows support issues. And surely he could sub-contract out support
> to a third-party, so it's hardly a show stopper.
There are more issues, certainly. Of course, most of these can be
abandoned by supporting only one Linux distribution/desktop environment.
> I suspect the real reason is more to do with being unable to
> copy-protect a Linux version so easily....
It's just as easy as it is under Windows. ie, pointlessly impossible.
B.
druck
> In article <59db2ee8...@druck.freeuk.net>, druck
> <ne...@druck.freeuk.com> wrote:
>> RISC OS already runs on cheap hardware, what it needs is for the
>> emulator to run over a cheap OS. And that's hell of a lot easier
>> as its already been done, but Aaron wont let you have it.
> Are we still tangled up with licensing? If so does this slow down attenpts
> to find even a limited way forward?
No, Aaron just doesn't want to support Linux. He has his reasons which
I can understand, but I think its a very bad decision, which will
prove very costly.
cfe...@freeremoveuk.com.invalid
druck <ne...@druck.freeuk.com> wrote:
> On 3 Oct 2008 Mr John FO Evans <mi...@orpheusmail.co.uk> wrote:
>
> > In article <59db2ee8...@druck.freeuk.net>, druck
> > <ne...@druck.freeuk.com> wrote:
> >> RISC OS already runs on cheap hardware, what it needs is for the
> >> emulator to run over a cheap OS. And that's hell of a lot easier
> >> as its already been done, but Aaron wont let you have it.
>
> > Are we still tangled up with licensing? If so does this slow down
> > attenpts to find even a limited way forward?
>
> No, Aaron just doesn't want to support Linux. He has his reasons
> which I can understand, but I think its a very bad decision, which
> will prove very costly.
>
Wasn't there a demo Linux version of 'VRPC' at a 'RISC OS' show?
Were there any testers out there?
--
Colin Ferris Cornwall UK
David Holden
On 5-Oct-2008, cfe...@freeRemoveuk.com.invalid wrote:
> Wasn't there a demo Linux version of 'VRPC' at a 'RISC OS' show?
Yes, and the difficulties this produced were what convinced Aaron that it
was not a viable commercial proposition.
--
David Holden - APDL - <http://www.apdl.co.uk>
Rob Kendrick
"David Holden" <Spa...@apdl.co.uk> wrote:
>
> On 5-Oct-2008, cfe...@freeRemoveuk.com.invalid wrote:
>
> > Wasn't there a demo Linux version of 'VRPC' at a 'RISC OS' show?
>
> Yes, and the difficulties this produced were what convinced Aaron
> that it was not a viable commercial proposition.
Perhaps it's time to abandon the commercialness of the emulator, then?
B.
Keith Hopper
Rob Kendrick <nn...@rjek.com> wrote:
> On Thu, 02 Oct 2008 10:20:15 +1300
> Keith Hopper <asg...@inspire.net.nz> wrote:
> > What, however, about the z_VM approach? I know that this is
> > cuurently IBM mainframe stuff, but VM itself has been around in
> > various guises for many years - and IBM do put Linux on top of it. I
> > have no idea about the status of VM itself - PD SW or strictly
> > proprietary. My gueass is that it should not be impossible to put
> > RISCOS on top of VM and skip the linux bit inbetween - unless you run
> > that in another VM partition!!
> VM is proprietary and is only available for IBM's very big bits of
> kit.
Ah! I must admit that I had had that horrible suspicion.
> Porting an RISC OS to it would be many times more difficult than
> even porting it to x86.
If proprietary I would regretfully have to agree with you!
> > Ignoring file systems and peripheral drivers it should be
> > possible to get a VM into less than 100kbytes of memory - including
> > memory management, exception handling, multi-threading, message
> > management and module/driver management.
> I have no idea what you're trying to get at, but you seem to be
> describing a hypervisor that would in no way aid us.
My thinking suggests that the principal problems facing the viability
of a RISC OS solution for the longer term future are the need for the
low-level internals to be "brought up to date" - principally in the tasking
and memory handling area. I dould prefer the ability to 'abstract' memory,
exceptions/interrupts, threads. modules and messaging to a new (real or
virtual) micro-kernel and then interface the rest to this low-level 'heart'
of the system.
Hence my thoughts about VM - which, I acknowledge, does have a bit
more in the way of higher level offerings to handle disc, peripherals, etc.
I have always maintained that much of the ideas at the lower level of
RISC OS were sound - just the implementation which was specific to
particular hardware - and, perhaps, lack of knowledge about some of the
things which we now know a lot more about.
One of the things which I believe makes a lot of work for programmers
- which is entirely orthogonal to program functioning is the need for
garbage collection at the micro-kernel level. Memory chips are now much
cheaper and larger than in the 1980s and garbage collection at the bottom -
even using a hardware MMU - makes so much good sense to me.
My other 'beef' at most OSs (so not RISC OS alone here) is the need to
have a system-wide common concept of all forms of asynchronous change of
control to a thread of execution - be it hardware or program originated.
Providing such a thing would make all forms of debugging - and ordinary
running too - much easier to think about and trap/handle than with the
dichotomous - even trichotomous - state which existing OSs seem to offer -
part OS, part programming language, even part run-time engine.
Just a few more thoughts about my ideal 'way forward'
Keith
--
Inspired!
Rob Kendrick
Keith Hopper <asg...@inspire.net.nz> wrote:
> My thinking suggests that the principal problems facing the
> viability of a RISC OS solution for the longer term future are the
> need for the low-level internals to be "brought up to date" -
> principally in the tasking and memory handling area. I dould prefer
> the ability to 'abstract' memory, exceptions/interrupts, threads.
> modules and messaging to a new (real or virtual) micro-kernel and
> then interface the rest to this low-level 'heart' of the system.
Actually, it all needs a huge overhaul. Memory handling,
multi-tasking, file system access, hardware abstraction, IP stack,
resource handling, IRQ routing, system call implementation, etc etc
etc. Microkernels are cute. But unless you can find one that already
supports all the hardware we want to use, it's going to be a lot of
effort. Which is why I suggested something like Linux or FreeBSD; they
already do.
> I have always maintained that much of the ideas at the lower
> level of RISC OS were sound - just the implementation which was
> specific to particular hardware - and, perhaps, lack of knowledge
> about some of the things which we now know a lot more about.
Buh?
> One of the things which I believe makes a lot of work for
> programmers
> - which is entirely orthogonal to program functioning is the need for
> garbage collection at the micro-kernel level. Memory chips are now
> much cheaper and larger than in the 1980s and garbage collection at
> the bottom - even using a hardware MMU - makes so much good sense to
> me.
Double-buh? Garbage collection is typically a programming language,
and thus userland, thing. Although UNIX does garbage collect its file
system. (ie, you can delete files while programs are using them, and
the space is only freed on the disc when all programs that have it open
close it.)
Although my best guess about what you're on about is replacing the OS
with a very high-level virtual machine that handles memory allocation
in the same fashion as a garbage collected language. Perhaps an OS
implemented in Java? Excuse me while I vomit infectious black bile
from my eyes :)
> My other 'beef' at most OSs (so not RISC OS alone here) is the
> need to have a system-wide common concept of all forms of
> asynchronous change of control to a thread of execution - be it
> hardware or program originated.
Triple-buh?! I have no idea what this means.
B.
druck
[snip]
> Just a few more thoughts about my ideal 'way forward'
Sorry to be disparaging, but talk of sound internals, adding VM and
just popping it on a microkernel suggest very little understanding of
the state of RISC OS.
Like any large software project that was initially knocked up in a
hurry as an a deperate plan B when the orginal OS design didn't work
out, and then developed in a piecemeal fashion through a number of
generations over 20 years, its one huge mess internally.
This can been seen by the massive amount of time and effort required
for even the relatively modest changes both ROL and Pace peformed to
their respective versions, which consisted of porting to 32bit
processors, and adding a degree of hardware abstration. Any more
ambitious rearchitecturing such as you are suggesting would take
several orders of magnetitude more development resources, greater than
Acorn ever employed.
With the exception of a few higher level self contained modules, it
would be easier and quicker to throw away all the legacy RISC OS code
and start again from scratch, no matter whether we are talking about
an ARM based solution, or portable API implementation running on top
of another OS.
Apart from the massive amount of work this would involve on the OS, it
would also break the vast majority of applications which can't cope
with pre-emption or even more memory protection. As say 95% of all
RISC OS applications are no longer developed and wont be altered to
run any new system, you'll have to run them on a compatibility layer
which preserves the existing behaviour.
So is all this worth it for the handful of apps which are still being
developed and _could_ be re-written to take advantage of "new RISC OS"
while everything else runs exactly as before? The answer is no, and
we'd be better off porting those few applications to an OS which has a
future.
David Holden
On 6-Oct-2008, druck <ne...@druck.freeuk.com> wrote:
[snip most of reply]
> So is all this worth it for the handful of apps which are still being
> developed and _could_ be re-written to take advantage of "new RISC OS"
> while everything else runs exactly as before? The answer is no, and
> we'd be better off porting those few applications to an OS which has a
> future.
You've said it, I've said it, in fact _everyone_ who has any real knowledge
of the situation says it, but they still don't get it and think they know
better.
A little bit of history. When ROL first took over the OS from E14 it was
suggested that the best way forward was to use a linux kernel with RISC OS
'on top', rather like Apple did later. This would have to provide 100%
compatibility with regular RISC OS (even then there were too many legacy
apps for it to be otherwise) but work on any ARM hardware that a linux
kernel could use (eg. the CATS board). Although very attractive for the long
term this was just not possible with the resources available at the time and
with the need get RO4 to a marketable state to bring in some money. With the
benefit of hindsight it would have been great if, once the money started
coming in, we could have revisited this idea. It might possibly
_at_that_time_ have been viable, but other things happened and it all went
pear shaped. Now, with a fraction of the potential market we had then and a
fraction of the number of programmers potentially available it's out of the
question in any reasonable time scale.
Richard Walker
On Sep 30, 11:50 pm, Rob Kendrick <n...@rjek.com> wrote:
> * Throw away the hardware and OS.
> * Build a set of RISC OS-like libraries on another platform
> to easy the porting of RISC OS software there.
> * Build a RISC OS-like GUI on top.
> * Provide an emulator for running software that hasn't been
> ported to map SWIs and other API calls to the new native
> set of libraries. This emulator could provide an entire
> "RISC OS" virtual machine to each app, thus removing all
> the problems involved with multiprocessor systems.
I couldn't agree more.
Amazingly, we've been here before:
http://groups.google.com/group/comp.sys.acorn.misc/browse_frm/thread/a8abd24e216c6715/
My recollection was that a small but vocal bunch were desperate to
keep to the 'pure Acorn' way of doing things. Perhaps it was
difficult to imagine the same user environment moving onto a different
architecture? Irritatingly, Microsoft then moved the Windows 95
interface+apps onto the NT kernel, and Apple managed to get die-hard
Mac OS users onto NeXTSTEP! (with some Mac-a-like UI alterations).
I do agree that what made RISC OS nice was the apps: Draw, Zap,
EasiWriter, Impression and Messenger - just to name a few.
Cheers,
Richard.
John Williams (News)
<ffce2df4-ace1-43de...@t41g2000hsc.googlegroups.com>,
Richard Walker <richar...@letterboxes.org> wrote:
> I do agree that what made RISC OS nice
>makes<
We ain't dead yet!
John
--
John Williams, Brittany, Northern France - no attachments to these addresses!
Non-RISC OS posters change user to johnrwilliams or put 'risc' in subject
for reliable contact! Who is John Williams? http://www.picindex.info/author/
Somewhere nice to stay in Brittany? http://petit.four.free.fr/visitors/locate
Richard Walker
wrote:
> In article
> <ffce2df4-ace1-43de-8031-563d34473...@t41g2000hsc.googlegroups.com>,
> Richard Walker <richardwal...@letterboxes.org> wrote:
>
> > I do agree that what made RISC OS nice
>
> >makes<
>
> We ain't dead yet!
Oops. I'm sure I didn't mean that! :)
Cheers,
Richard.
druck
> In article
> <ffce2df4-ace1-43de...@t41g2000hsc.googlegroups.com>,
> Richard Walker <richar...@letterboxes.org> wrote:
>> I do agree that what made RISC OS nice
> >makes<
> We ain't dead yet!
Don't mistake twitching of the corpse for life.
Alan
> On Wed, 1 Oct 2008 04:49:22 -0700 (PDT)
>
> Alan <alan_...@hotmail.com> wrote:
> > This all seems to make sense to me.
>
> > Do you think either the ROLF project or ROX-Filer and
> > ROX-Session are already steps in the direction you
> > are suggesting?
>
> ROX I suspect is not the way to go - it's an implementation of a
> handful of RISC OS idioms in a very UNIX and X-centric fashion. I
> think most die-hard RISC OS users would find it disappointing.
>
> ROLF is certainly closer to the mark, but again it's more about
> producing something that looks like RISC OS, rather than something
> that's a viable target for porting to. It's certainly made some design
> decisions that I wouldn't have made, but then again it's much further
> along than anything I'm suggesting.
>
Have you any technical (more low level ideas) on how you would
approach this?
From other comments on this and similar topics comments my
thoughts are:
- Use X11 for the screen/input.
- Use an attributed file system for types (or add types to an
existing file system).
- Create a library that implements the existing RISC OS
swi calls (or a large proportion of them).
Would the programmic interface be a simple swi function
or something more like OSLib with a swi function to map
swi to library routines?
- I'm not sure how the task manager stuff would work.
- I'm a bit ignorant on the X11 stuff would it need a window
manager written.
To get started it would need.
Filer windows
Icon bar
a minimal set of swis to create windows and manipulate files.
Regards,
Alan
Rob Kendrick
Alan <alan...@hotmail.com> wrote:
> From other comments on this and similar topics comments my
> thoughts are:
>
> - Use X11 for the screen/input.
Absolutely. There are no reasons not to use X.
> - Use an attributed file system for types (or add types to an
> existing file system).
Most modern UNIX file systems support arbitrary attributes (ext2/3, XFS,
JFS, etc). So you can store the 12-bit RISC OS type, along with a MIME
type string, if you wanted.
> - Create a library that implements the existing RISC OS
> swi calls (or a large proportion of them).
Well, certainly provide a library that looks a bit like, say, OSLib.
> Would the programmic interface be a simple swi function
> or something more like OSLib with a swi function to map
> swi to library routines?
OSLib's a lot safer. And I'm not sure we'd want to spend too much
effort making this library easy to use for new software: it only needs
to be easy to /port to/. RISC OS's API is one of the things keeping it
stuck where it is: a new, RISC OS-inspired API without its flaws could
live along the compatibility one.
> - I'm not sure how the task manager stuff would work.
What are you not sure about? Displaying memory usage under UNIX is
tricky and a little bit pointless due to its extensive use of swap and
shared memory. However, it's easy to display a list of tasks and let
the user kill them.
> - I'm a bit ignorant on the X11 stuff would it need a window
> manager written.
Yes, or an existing one adapted. It would have two classes of window;
a RISC OS Window, and a UNIX Window. This allows us to precisely
emulate RISC OS's window furniture, which still combining exact
compatibility with traditional X applications. (ie, under RISC OS, the
window manager handles all the window furniture, including scrollbars,
etc. Traditionally under X, the window manager only provides the title
bar [and associated functionality] and resize handles - scrollbars are
handled by the app.)
> To get started it would need.
> Filer windows
The RISC OS filer is so simplistic, this is most likely a day's work.
New features will take longer.
> Icon bar
Again, should be simple.
> a minimal set of swis to create windows and manipulate files.
The library is by far and away the largest chunk of work.
B.
Steffen Huber
> The RISC OS filer is so simplistic, this is most likely a day's work.
From my own experience: yes for a "works nearly like the filer",
but the devil is in the detail (doing a mouse drag select is
astonishingly sophisticated).
Steffen
--
Steffen Huber
hubersn Software - http://www.hubersn-software.com/
Rob Kendrick
Steffen Huber <sp...@huber-net.de> wrote:
> Rob Kendrick wrote:
> > The RISC OS filer is so simplistic, this is most likely a day's
> > work.
>
> From my own experience: yes for a "works nearly like the filer",
> but the devil is in the detail (doing a mouse drag select is
> astonishingly sophisticated).
This is a complex problem, yes. But pick an X toolkit, and it has most
likely already solved this problem. (Such are the wonders of having
GUI building tools with many widgets, rather than being limited to
"button", "label" and "text entry box".)
B.
Timothy Baldwin
Kendrick <nn...@rjek.com> wrote:
> On Fri, 17 Oct 2008 01:25:34 -0700 (PDT)
> Alan <alan...@hotmail.com> wrote:
>
>> - Use an attributed file system for types (or add types to an
>> existing file system).
>
> Most modern UNIX file systems support arbitrary attributes (ext2/3, XFS,
> JFS, etc). So you can store the 12-bit RISC OS type, along with a MIME
> type string, if you wanted.
Certainely store the MIME type in "user.mime_type", that's a new standard
for UNIX desktops.
I would store the full load and exec address fields, this helps with
compatibility old software - for either RISC OS or the BBC Micro.
I propose an attribute named "user.RISC_OS.load+exec" containing:
Bytes 0-3 Execute address
Bytes 4-7 Load address
Byte 8 Flags
Bytes 9- 2 x Null terminated MIME types.
Where the flags are:
Bit 0 - Use filetype if at least 1 MIME type matches that
in "user.mime_type".
Bit 1 - Use filetype always.
Bit 2 - Use non-filetype part.
Bit 3 - Use non-filetype part if timestamp is same second. This is provide
protection to BBC micro files which are mistaken for RISC OS typed files
and lose the centisecond part of their timestamp.
Bit 4 - File is probably from BBC Micro environment.
Bit 5 - Write filetype to DOS filing system.
A RISC OS filing system will either set bit 0 or bits 1 and 2 as
appropriate.
>> - Create a library that implements the existing RISC OS
>> swi calls (or a large proportion of them).
We don't need to re-implement every interface, a mixture of RISC OS ARM code
(running under an emulator), existing C implementations, and new
implementations would be usable. Also a lot of SWIs need not be
implemented to run most applications.
The RISC OS Open license is however problematic, ironically the mere
existence of a project to implement the RISC OS API on non-ARM systems may
cause the RISC OS Open license to prohibit minor modifications to the C
parts of RISC OS Open.
> Well, certainly provide a library that looks a bit like, say, OSLib.
Better still - use OSLib to define the interface, I have already modified
Defmod to produce header files which implement the OSLib interface by
calling a swi function, for example:
inline int adfsdiscop_verify (bits flags,
filecore_disc_address disc_addr,
int size,
filecore_disc_address *next_disc_addr) {
Registers OSLIB_r;
OSLIB_r.r[1] = 0U | (Register)flags;
OSLIB_r.r[2] = (Register)disc_addr;
OSLIB_r.r[4] = (Register)size;
_call_swi(262720, &OSLIB_r);
*next_disc_addr = (__typeof__(*next_disc_addr))OSLIB_r.r[2];
return (int)OSLIB_r.r[4];
}
>> Would the programmic interface be a simple swi function
>> or something more like OSLib with a swi function to map
>> swi to library routines?
The likes of _swi(), _swix(), and _kernel_swi() should of course also be
provided. However programs using these may include struct definitions which
may not compile in a compatible fashion on 64-bit and big-endian systems;
and if interworking with ARM code or BBC BASIC is to be done the structures
need to be ARM compatible.
> OSLib's a lot safer. And I'm not sure we'd want to spend too much
> effort making this library easy to use for new software: it only needs
> to be easy to /port to/.
C++ programs which use OSLib structures will not have those compatiablity
problems, and C programs are easy to port to C++, especially if one defines
malloc as:
class void_p {
void *data;
public:
void_p(void *d) : data(d) {}
void_p operator = ( void *d) {
data = d;
return *this;
}
template <typename T> operator T * () const {
return reinterpret_cast<T *>(data);
}
};
void_p malloc(size_t count);
>> - I'm a bit ignorant on the X11 stuff would it need a window
>> manager written.
>
> Yes, or an existing one adapted. It would have two classes of window;
> a RISC OS Window, and a UNIX Window. This allows us to precisely
> emulate RISC OS's window furniture, which still combining exact
> compatibility with traditional X applications. (ie, under RISC OS, the
> window manager handles all the window furniture, including scrollbars,
> etc. Traditionally under X, the window manager only provides the title
> bar [and associated functionality] and resize handles - scrollbars are
> handled by the app.)
Therefore the library should handle the the scrollbars (and titlebars on
nested windows) to retain compatibility with standard X window mangers.
Rob Kendrick
Timothy Baldwin <T.E.Ba...@members.leeds.ac.uk> wrote:
> C++ programs which use OSLib structures will not have those
> compatiablity problems, and C programs are easy to port to C++,
> especially if one defines malloc as:
<snip> And one fixes the other dozen or so compatibility issues :)
> Therefore the library should handle the the scrollbars (and titlebars
> on nested windows) to retain compatibility with standard X window
> mangers.
Yes.
B.