A way to get RISC OS on a Psion NetBook
Tarquin Mills
RON project, also we have seen the rise of the emulator. Why not merge
the two problems to give you the solution, a RISC OS emulator on
the NetBook that uses the ARM directly and calls EPOC to access the other
hard.
--
Tarquin Mills
RUNG (RISC OS Users, Norfolk Group)
http://www.speccyverse.me.uk/rung/ (running on RISC OS)
New domain name coming one day http://rung.aaug.riscos/
Peter Naulls
Tarquin Mills <specc...@ntlworld.com> wrote:
> Several RISC OS owners have Psion NetBooks thanks to the proposed
> RON project, also we have seen the rise of the emulator.
"The emulator"? Do you mean VirtulRPC, ArcEm, Aemulor, something else?
> Why not merge
> the two problems to give you the solution, a RISC OS emulator on
> the NetBook that uses the ARM directly and calls EPOC to access the other
> hard.
Firstly, who are you proposing to do this work? Or indeed pay for it.
Many of your suggestions seem to involve volunteering other people's
time and money to make things happen, apart from the problem of finding
an EPOC programmer with an interest in RISC OS.
Secondly, how is this going to work technically? I can think of one
method that I've proposed (ARM on ARM emulation with ArcEm), but I don't
think you had this in mind. And, exactly where are you going to hook
in - I'll give you the benefit of the doubt, and presume you really
meant "RiscPC emulator" and not "RISC OS" emulator.
Finally, no matter the rest of the technical problems, any attempt to
run ARM code for a different OS on another ARM machine will still
result in considerable overheads, and the result will be somewhat slower
than an otherwise native solution (c.f. Aemulor)
--
Peter Naulls - pe...@chocky.org | http://www.chocky.org/
----------------------------------------------------------------------------
GCC for RISC OS | http://hard-mofo.dsvr.net/gcc/
Jess
Peter Naulls <pe...@chocky.org> wrote:
> In message <c1dc31a14...@localhost.local>
> Tarquin Mills <specc...@ntlworld.com> wrote:
>
> > Several RISC OS owners have Psion NetBooks thanks to the proposed
> > RON project, also we have seen the rise of the emulator.
>
> "The emulator"? Do you mean VirtulRPC, ArcEm, Aemulor, something else?
It's obvious he means the concept.
> > Why not merge the two problems to give you the solution, a RISC OS
> > emulator on the NetBook that uses the ARM directly and calls EPOC
> > to access the other hard.
>
> Firstly, who are you proposing to do this work? Or indeed pay for it.
> Many of your suggestions seem to involve volunteering other people's
> time and money to make things happen, apart from the problem of finding
> an EPOC programmer with an interest in RISC OS.
He's not proposing anyone. He's making a suggestion.
> Secondly, how is this going to work technically? I can think of one
> method that I've proposed (ARM on ARM emulation with ArcEm), but I don't
> think you had this in mind. And, exactly where are you going to hook
Surely what he was suggesting was something equivalent to a port of red
squirrel, but where you don't need to emulate the processor.
A bit like a virtual machine on windows, I think. Whether this is
possible without a horrid overhead (in addition to emulating the rest
of the hardware) on an Arm, you'd probably be able to answer. (The 386
is designed to support virtual machines)
> in - I'll give you the benefit of the doubt, and presume you really
> meant "RiscPC emulator" and not "RISC OS" emulator.
An obvious typo - what else could he mean.
> Finally, no matter the rest of the technical problems, any attempt to
> run ARM code for a different OS on another ARM machine will still
> result in considerable overheads, and the result will be somewhat slower
> than an otherwise native solution (c.f. Aemulor)
The question is whether the overheads are a killer or not - eg 7500
performance on an SA might be acceptable, arm 2 performance wouldn't.
--
Jess msn: phant...@hotmail.com icq: 91353267
mailto:nos...@itworkshop.uklinux.net Hotmail is spamtrap, don't email it
RISC OS 4.37 kinetic 64+128+2M Castle Storm DMA + 17GB 586-133 I-3 ADSL
http://www.itworkshop-online.co.uk http://www.b1-11.net
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----
Peter Naulls
Jess <phant...@hotmail.com> wrote:
> In message <3f4d7ea1...@chocky.org>
> Peter Naulls <pe...@chocky.org> wrote:
>
> > > Several RISC OS owners have Psion NetBooks thanks to the proposed
> > > RON project, also we have seen the rise of the emulator.
> >
> > "The emulator"? Do you mean VirtulRPC, ArcEm, Aemulor, something else?
>
> It's obvious he means the concept.
It's not obvious at all. There are at least a dozen concepts here.
> > Firstly, who are you proposing to do this work?
>
> He's not proposing anyone. He's making a suggestion.
No, he is proposing that someone do it. This is typical of Tarquin's
posts.
> Surely what he was suggesting was something equivalent to a port of red
> squirrel, but where you don't need to emulate the processor.
There must always be a degree of processor emulation.
> > in - I'll give you the benefit of the doubt, and presume you really
> > meant "RiscPC emulator" and not "RISC OS" emulator.
>
> An obvious typo - what else could he mean.
It's not obvious. A "RISC OS" emulator is a valid concept.
--
Peter Naulls - pe...@chocky.org | http://www.chocky.org/
----------------------------------------------------------------------------
RISC OS C Programming | http://www.riscos.info/
druck
> > Secondly, how is this going to work technically? I can think of one
> > method that I've proposed (ARM on ARM emulation with ArcEm), but I don't
> > think you had this in mind. And, exactly where are you going to hook
>
> Surely what he was suggesting was something equivalent to a port of red
> squirrel, but where you don't need to emulate the processor.
This is actually far more difficult. In a full emulator which does
instruction level emulation, you can easily trap all accesses to memory,
memory mapped I/O, privelidged instructions and the control co-processor,
then translate these to the emulated memory map, native OS calls to hardware,
and for the latter two, a simulated processor model.
When actually executing ARM instructions, you would have to manipulate the
native OS's memory page tables to make RISC OS use memory set asside for the
emulation and to cause a trappable exception when attempting to use memory
mapped I/O. You then have to prevent any RISC OS code running that uses
certain privelidged instructions and the control co-processor, so that RISC
OS doesn't also try to reprogram the native machines memory map and hardware.
This is extremely difficult to do, and would probably require you to run all
of RISC OS in user mode, so trappable exceptions are caused for all the
potentially danagerous things RISC OS could do, that either would be
destructive to the native OS, or would be prevented by it. There would be a
considerable speed penalty for this, as every one of the tens of thousands of
SWI's occuring a second would be subjected to a large overhead.
I estimate that something along these lines would be many times the work of
porting RISC OS 5 directly to the native hardware.
---druck
--
The ARM Club Free Software - http://www.armclub.org.uk/free/
The 32bit Conversions Page - http://www.quantumsoft.co.uk/druck/
Tarquin Mills
days, trying to prove how much smarter he is and this reply from him
is no exception.
In message <3f4d7ea1...@chocky.org> Peter Naulls wrote:
> In message <c1dc31a14...@localhost.local>
> Tarquin Mills <specc...@ntlworld.com> wrote:
> > Several RISC OS owners have Psion NetBooks thanks to the proposed
> > RON project, also we have seen the rise of the emulator.
>
> "The emulator"? Do you mean VirtulRPC, ArcEm, Aemulor, something else?
>
> > Why not merge
> > the two problems to give you the solution, a RISC OS emulator on
> > the NetBook that uses the ARM directly and calls EPOC to access the other
> > hard.
>
> Firstly, who are you proposing to do this work? Or indeed pay for it.
> Many of your suggestions seem to involve volunteering other people's
> time and money to make things happen, apart from the problem of finding
> an EPOC programmer with an interest in RISC OS.
Peter you seem to think you are the only programmer in the RISC OS world,
you are not. If the Sinclair QL community can find the talent to write a
emulator to run on EPOC, the much larger RISC OS world (with it's
connection to ARM) certainly can.
> Secondly, how is this going to work technically? I can think of one
> method that I've proposed (ARM on ARM emulation with ArcEm), but I don't
> think you had this in mind.
You know that is what I had in mind, from my discussion on #playpen last
night with aardvark. Where is the evidence you thought of it first, I
have the IRC logs.
> And, exactly where are you going to hook
> in - I'll give you the benefit of the doubt, and presume you really
> meant "RiscPC emulator" and not "RISC OS" emulator.
This is just pedantry, you know "RISC OS emulator" is short hand for an
emulator that runs RISC OS, it probably will not emulate a RiscPC but a
computer with some similarity to a RiscPC. I hope you intend to tell
Qercus (e.g. page 8 of issue 268) and Archive they are wrong on this to.
> Finally, no matter the rest of the technical problems, any attempt to
> run ARM code for a different OS on another ARM machine will still
> result in considerable overheads, and the result will be somewhat slower
> than an otherwise native solution (c.f. Aemulor)
There will be an overhead, but it will still be a better solution than
the A4 by far. The fact is you do not like me, and are jealous because I have
solved a problem that Acorn, Interconnex, MD, Riscstation, and ROL have
not solved. While in your Drobe article you have very publicly stated
it is completely impossible to make a portable. I bet myself you would say
my idea was not possible, and have nearly been proved right.
If in a few years time we still do not have an ARM based RISC OS portable
it will be because people are more interest in selling PC kit than doing
whats right. This will make a long thread but for the wrong reasons, I
only hope my idea does not get lost in this melee.
Peter Naulls
Tarquin Mills <specc...@ntlworld.com> wrote:
> Peter Naulls has been attacking Jess, Chris Evans and others in recent
> days, trying to prove how much smarter he is and this reply from him
> is no exception.
I've attacked nobody. Is this one of your conspiracy theories? If
pointing out the practicalities of situations is a problem for you,
then peraps you should consider not posting.
> Peter you seem to think you are the only programmer in the RISC OS world,
I've never made such a ridiculous claim.
> > Secondly, how is this going to work technically? I can think of one
> > method that I've proposed (ARM on ARM emulation with ArcEm), but I don't
> > think you had this in mind.
> You know that is what I had in mind, from my discussion on #playpen last
> night with aardvark. Where is the evidence you thought of it first, I
> have the IRC logs.
Actually, I don't know, which is why I asked. I wrote a document on
this very issue, which I dicussed privately with druck in some detail
at the time (early 2002). I don't claim to have come up with the idea,
but I've not seem mention of it anywhere else:
http://www.riscos.info/32bit/ARMEmu.txt
I would have to check with Alex, but I'm pretty sure he's well aware of
this too, and may have based his comments on it.
> > And, exactly where are you going to hook
> > in - I'll give you the benefit of the doubt, and presume you really
> > meant "RiscPC emulator" and not "RISC OS" emulator.
> This is just pedantry, you know "RISC OS emulator" is short hand for an
> emulator that runs RISC OS,
Not, it's not. "riscose" is a RISC OS emulator. Given the lack of
specifics in your idea, you could well have meant this. But I also
gave you benefit of the doubt, so whinging about it isn't really
achieving much.
> computer with some similarity to a RiscPC. I hope you intend to tell
> Qercus (e.g. page 8 of issue 268) and Archive they are wrong on this to.
I already advice Paul Beverly on a number of items, so thanks for
asking.
> There will be an overhead, but it will still be a better solution than
> the A4 by far.
It might be a similar speed to the A4, perhaps. The overheads are
considerable, bearing in mind what druck has said in this very thread.
> The fact is you do not like me, and are jealous because I have
> solved a problem that Acorn, Interconnex, MD, Riscstation, and ROL have
> not solved.
What a strange claim. I will let others point out the comedy in this,
I think.
Qercus editor
Peter Naulls <pe...@chocky.org> wrote:
> > This is just pedantry, you know "RISC OS emulator" is short hand for an
> > emulator that runs RISC OS,
> Not, it's not. "riscose" is a RISC OS emulator. Given the lack of
> specifics in your idea, you could well have meant this. But I also
> gave you benefit of the doubt, so whinging about it isn't really
> achieving much.
> I already advice Paul Beverly on a number of items, so thanks for
> asking.
We too are willing to learn. Are there faults with the following:
"[A6 & RISCube] are Windows machines running RISC OS in emulation"
and
"RISC OS Emulation (RISC OS on Windows)"
Note that both phrases need to be clear and the information needs to be
delivered in the same length of phrase.
Are they wrong, are they misleading? Advice (n.) would be appreciated...
--
John Cartmell editor Qercus - edi...@qercus.com www.qercus.com
Qercus: a fusion of Acorn Publisher & Acorn User magazines
one magazine for graphics & design - one magazine for all RISC OS users
Finnybank Ltd 30 Finnybank Rd Sale M33 6LR == 0161 969 9820
Peter Naulls
Qercus editor <edi...@qercus.com> wrote:
> "[A6 & RISCube] are Windows machines running RISC OS in emulation"
>
> and
>
> "RISC OS Emulation (RISC OS on Windows)"
>
> Note that both phrases need to be clear and the information needs to be
> delivered in the same length of phrase.
Well, given the nature of the context and target audience, perhaps.
Using "in emulation" is different to "emulating RISC OS".
The salient point is that it's the hardware being emulated, not the OS,
although in some instances, there is also a degree of OS emulation (you
could argue the networking layer is that).
--
Peter Naulls - pe...@chocky.org | http://www.chocky.org/
----------------------------------------------------------------------------
The RISC OS Browser Issue - http://www.chocky.org/unix/browser.html
Paul F. Johnson
Steven Pampling did utter the following words of wisdom:
> In article <f84e88a14...@localhost.local>,
> Tarquin Mills <specc...@ntlworld.com> wrote:
>> Peter you seem to think you are the only programmer in the RISC OS world,
>> you are not. If the Sinclair QL community can find the talent to write a
>> emulator to run on EPOC, the much larger RISC OS world (with it's
>> connection to ARM) certainly can.
>
> Had you considered the possibility that he's encouraging other people to
> have a go themselves?
No. He is not encouraging anyone. But then, this is not uncommon with
Peter. First he bitched on about no movement, then he starts the UPP
(which is damned fine IMO). However, any request for help or if other
released ports which didn't live up to his mega high standards, they were
hounded, so those doing that work give up. Even reporting bugs or
clarification of material on his site gets the same level of "help"
TTFN
Paul
--
"There are four stages to any war
First they ignore you, then they laugh at you
Then they fight you, then YOU win."
Ghandi
Steve Fryatt
<f84e88a14...@localhost.local>:
> In message <3f4d7ea1...@chocky.org> Peter Naulls wrote:
>
> > In message <c1dc31a14...@localhost.local>
> > Tarquin Mills <specc...@ntlworld.com> wrote:
> >
> > > Why not merge the two problems to give you the solution, a RISC OS
> > > emulator on the NetBook that uses the ARM directly and calls EPOC
> > > to access the other hard.
> >
> > Firstly, who are you proposing to do this work? Or indeed pay for it.
> > Many of your suggestions seem to involve volunteering other people's
> > time and money to make things happen, apart from the problem of
> > finding an EPOC programmer with an interest in RISC OS.
>
> Peter you seem to think you are the only programmer in the RISC OS
> world, you are not. If the Sinclair QL community can find the talent to
> write a emulator to run on EPOC, the much larger RISC OS world (with
> it's connection to ARM) certainly can.
I wasn't aware that Sinclair QLs used ARM based processors. If I'm right,
the QL community *haven't* done "[an] emulator on the NetBook that uses
the ARM directly and calls EPOC to access the other hard." They've done a
full emulator, which AIUI is both slower to execute and much easier to
implement than your suggestion would be.
--
Steve Fryatt - Leeds, England
Peter Naulls
"Paul F. Johnson" <pa...@all-the-johnsons.co.uk> wrote:
> Steven Pampling did utter the following words of wisdom:
> > Had you considered the possibility that he's encouraging other people to
> > have a go themselves?
>
> No. He is not encouraging anyone. But then, this is not uncommon with
> Peter. First he bitched on about no movement, then he starts the UPP
> (which is damned fine IMO). However, any request for help or if other
> released ports which didn't live up to his mega high standards, they were
> hounded, so those doing that work give up. Even reporting bugs or
> clarification of material on his site gets the same level of "help"
As usual, Paul is trying to generalise his own experiences, and
coming up completely wrong.
To clarify: I have no problem with most of the ports out there, and I
use many of them myself. Many of my own ports would not have been
possible without them.
I get many requests for help, many of which I answer, and most people
are happy with the help they get. It's true, that because of the
volume I received, I do often take some time to reply.
It's also true that I take time to check information I do receive
and not random post it. However, information from sources such as Paul
has often proved inaccurate in the past, so I would generally wait for
confirmation from elsewhere.
Steve is of course correct. After all, I would not have published my
ideas on ARM on ARM emulation if I was trying to be difficult about
this issue (even if I see it as impractical).
I doubt Paul has any geunine and specific complaints about my behaviour
on any of the things he's named, that would relate to anyone except
himself.
--
Peter Naulls - pe...@chocky.org | http://www.chocky.org/
----------------------------------------------------------------------------
druck
> I wasn't aware that Sinclair QLs used ARM based processors.
They didn't, IIRC the QL was one of the crippled 68008 variants.
> If I'm right, the QL community *haven't* done "[an] emulator on the NetBook
> that uses the ARM directly and calls EPOC to access the other hard."
> They've done a full emulator, which AIUI is both slower to execute and much
> easier to implement than your suggestion would be.
The Sinclar NetBook was a Z88. The PSION netbook uses an SA1100 and runs EPOC
5(?).
News poster
Jess <phant...@hotmail.com> wrote:
<snip>
> > Finally, no matter the rest of the technical problems, any attempt to
> > run ARM code for a different OS on another ARM machine will still
> > result in considerable overheads, and the result will be somewhat slower
> > than an otherwise native solution (c.f. Aemulor)
>
> The question is whether the overheads are a killer or not - eg 7500
> performance on an SA might be acceptable, arm 2 performance wouldn't.
Not forgetting that a netBook is not one of the worlds fastest
computing devices to start with. Disc access (microdrive or CF) does not
seem significantly faster than say the hard drive on my A4 for example.
Although the Psion is fine in daily use and has some nice features, it
amuses me to sit behind a StrongARM RiscPC and see how much more
responsive it feels doing similar tasks with a similar CPU.
The RON episode is just another reminder as to the pitfalls of
pre-announcing products before they actually exist and indeed before
you know if there are any unsolvable technical problems.
Better to buy and use a Netbook as it was intended, whilst saving up
just in case anyone produces a native RISC OS portable solution at
sometime in the future.
Regards
Stan
--
Jess
> > Surely what he was suggesting was something equivalent to a port of red
> > squirrel, but where you don't need to emulate the processor.
> This is actually far more difficult.
[snip long but useful explaination.]
> many times the work of porting RISC OS 5 directly to the native hardware.
Thanks, this concisly answered a question I asked later in the posting.
Would it be possible to forget the local OS (just use it as a launcer)
and have the hardware emulated by risc os processes (eg modules) or
would this be as much of a non starter?
Jess
Peter Naulls <pe...@chocky.org> wrote:
> In message <2fa283a...@itworkshop.invalid>
> Jess <phant...@hotmail.com> wrote:
> > In message <3f4d7ea1...@chocky.org>
> > Peter Naulls <pe...@chocky.org> wrote:
> > > Firstly, who are you proposing to do this work?
> > He's not proposing anyone. He's making a suggestion.
> No, he is proposing that someone do it. This is typical of Tarquin's
> posts.
But if the idea has merit both technically and financially then why
shouldn't he? They would get the benefit if it were a salable product.
If not, then it won't happen.
> > Surely what he was suggesting was something equivalent to a port of red
> > squirrel, but where you don't need to emulate the processor.
> There must always be a degree of processor emulation.
definately, but what I would like to know is whether (in simple non
programmer terms) it just involves switching to the code that the
processor subsystem is running, running that directly, then switching
back, or would it involve a whole layer of emulation?
> > > in - I'll give you the benefit of the doubt, and presume you really
> > > meant "RiscPC emulator" and not "RISC OS" emulator.
> >
> > An obvious typo - what else could he mean.
>
> It's not obvious. A "RISC OS" emulator is a valid concept.
It certainly is, and presumably an equivalent of wine would perform far
better that an RPC emulator, but in the context of what currently
exists (several working machine emulators vs riscose) very unlikely to
be achievable in the short term, surely?
Tarquin Mills
> Several RISC OS owners have Psion NetBooks thanks to the proposed
> RON project, also we have seen the rise of the emulator. Why not merge
> the two problems to give you the solution, a RISC OS emulator on
> the NetBook that uses the ARM directly and calls EPOC to access the other
> hard.
of the several M$ Windoze based emulators be to Windows CE, the extra
speed of the Xscale should help?
--
Tarquin Mills
Reboot Movement (An Anti-Wintel Campaign)
http://www.speccyverse.me.uk/comp/reboot/
Jess
Jess <phant...@hotmail.com> wrote:
> In message <f1ed84a1...@chocky.org>
> Peter Naulls <pe...@chocky.org> wrote:
> > There must always be a degree of processor emulation.
>
> definately, but what I would like to know is whether (in simple non
> programmer terms) it just involves switching to the code that the
> processor subsystem is running, running that directly, then switching
> back, or would it involve a whole layer of emulation?
I have just spotted druck's posting that answers this.
Jess
Tarquin Mills <specc...@ntlworld.com> wrote:
> In message <c1dc31a14...@localhost.local> Tarquin Mills wrote:
> > Several RISC OS owners have Psion NetBooks thanks to the proposed
> > RON project, also we have seen the rise of the emulator. Why not merge
> > the two problems to give you the solution, a RISC OS emulator on
> > the NetBook that uses the ARM directly and calls EPOC to access the other
> > hard.
> The new Psion NetBook 2/Pro runs Windows CE, how hard would a port one
> of the several M$ Windoze based emulators be to Windows CE, the extra
> speed of the Xscale should help?
Unfortuantely, what druck explained would probably make the whole thing
a non-starter (unless any techniques used in aemulor were of use, but
even if they were, the suppliers are probably close enough to castle
that a real port would be more sensible - a dual boot wince & ro system
would be nice).
RISC OS Emulation would be the way to look in the absence of a port, but
I would guess it would be a very long project.
druck
> Would it be possible to forget the local OS (just use it as a launcer)
Some may allow the level of priviledge necessary to achieve this, others
wont and you'll have to replace the boot loader and force a reset.
> and have the hardware emulated by risc os processes (eg modules) or
> would this be as much of a non starter?
You wouldn't be emulating in that case, you'd be using a RISC OS 5 HAL and
hardware specific modules.
druck
> In message <c1dc31a14...@localhost.local> Tarquin Mills wrote:
> > Several RISC OS owners have Psion NetBooks thanks to the proposed
> > RON project, also we have seen the rise of the emulator. Why not merge
> > the two problems to give you the solution, a RISC OS emulator on
> > the NetBook that uses the ARM directly and calls EPOC to access the other
> > hard.
> The new Psion NetBook 2/Pro runs Windows CE, how hard would a port one
> of the several M$ Windoze based emulators be to Windows CE, the extra
> speed of the Xscale should help?
Quite difficult, CE isn't Windows and is lacking many of the major Win32
components used by emulators such as Direct X. Its extremely badly designed
memory map makes difficult implement memory hungry programs such as
emulators, even if the device comes with more than the normal 64MB (some
128MB) which is split 50:50 between application memory and RAM disc.
Tarquin Mills
druck <ne...@druck.freeuk.com> wrote:
> On 18 Apr 2004 Tarquin Mills <specc...@ntlworld.com> wrote:
> > In message <c1dc31a14...@localhost.local> Tarquin Mills wrote:
> > > Several RISC OS owners have Psion NetBooks thanks to the proposed
> > > RON project, also we have seen the rise of the emulator. Why not merge
> > > the two problems to give you the solution, a RISC OS emulator on
> > > the NetBook that uses the ARM directly and calls EPOC to access the
> > > other hard.
> > The new Psion NetBook 2/Pro runs Windows CE, how hard would a port one
> > of the several M$ Windoze based emulators be to Windows CE, the extra
> > speed of the Xscale should help?
> Quite difficult, CE isn't Windows and is lacking many of the major Win32
> components used by emulators such as Direct X. Its extremely badly designed
> memory map makes difficult implement memory hungry programs such as
> emulators, even if the device comes with more than the normal 64MB (some
> 128MB) which is split 50:50 between application memory and RAM disc.
Psion have said in the past that they will port Linux to the Netbook 2/Pro,
and VirtRPC may one day appear for the Linux. The reason given for a normal
RISC OS portable not existing is the lack of a case, however Dreamwriter
(http://www.dreawriter.co.uk, who sell to the education market) have
produced portables. The Student Writer 500 uses a case first used at least
as early as 1991, while WiBook (with modern eMate esk case) has been in
production for 4 years already. Dreamwriter claim they have cases for 2-3
years.
--
Tarquin Mills
Norwich Sinclair and Clones Show (ORSAM 2004)
http://www.speccyverse.me.uk/orsam/
http://www.PetitionOnline.com/Sinclair/petition.html (Bring Back YS)
Peter Naulls
Tarquin Mills <ac...@nojunkmail.com> wrote:
> Psion have said in the past that they will port Linux to the Netbook 2/Pro,
I'm certain they haven't said that openly (unless you have a reference
and can demonstrate otherwise). What they _have_ mentioned is a general
interest in Linux, but not specifically to any of their many products.
But that's quite a different problem to porting RISC OS to a machine.
--
Peter Naulls - pe...@chocky.org | http://www.chocky.org/
----------------------------------------------------------------------------
Drobe - http://www.drobe.co.uk/ | The Premier RISC OS News Site
Tarquin Mills
> Tarquin Mills wrote:
> > Psion have said in the past that they will port Linux to the Netbook Pro
> I'm certain they haven't said that openly (unless you have a reference
> and can demonstrate otherwise). What they _have_ mentioned is a general
> interest in Linux, but not specifically to any of their many products.
> But that's quite a different problem to porting RISC OS to a machine.