Does the availability to Castle of the RO sources make it any easier to
implement Aemulor?
Could Aemulor be built into RO and provide extra speed / compatability?
Would it potentially allow old podules to work?
Or is it all just fine and hunky dory as is?
James
> A random thought that crossed my mind:
>
> Does the availability to Castle of the RO sources make it any easier to
> implement Aemulor?
Can't see why.
First of all, just to avoid any misunderstandings: What Castle have done
recently was that they bought the intellectual property rights to the
whole of RISC OS. That was a mere legal act and does not have any
technical consequences. Of course, the purchase included the sources, but
do you think they created RISC OS 5 without the RISC OS sources? The
difference is only that they did not own the copyright before whereas they
do now.
Secondly, the question whether it would make it easier to IMPLEMENT
Aemulor is pretty academic because Aemulor has been implemented already.
Of course, the author of Aemulor would have loved to see the RISC OS
sources because a lot of his work was to hide the various changes to the
RISC OS API to emulated programs.
> Could Aemulor be built into RO and provide extra speed / compatability?
I do not think this would be a good idea. Aemulor has to twiddle a lot of
low-level things that can affect proper 32-bit software, so Aemulor is not
a thing I would want to run all the time by default.
As for extra speed: Certainly not. Extra compatibility: The only extra
thing an integrated solution could do would be to handle podules as you
suggest below.
> Would it potentially allow old podules to work?
I do not think this would be worth the effort. As you suggest, if you
really wanted to do that, some support would have to be put into the OS
because the podule initialisation code would have to emulated and that
happens before the system is booted so Aemulor cannot be loaded at that
point.
The chances that such an emulation would finally work are very slim
though. I would certainly not want to run a system with emulated
interrupt-driven hardware access. Sounds like a nightmare to me.
> Or is it all just fine and hunky dory as is?
I would say, just forget about the idea.
Martin
--
---------------------------------------------------------------------
Martin Wuerthner MW Software mar...@invalidMW-software.com
remove "invalid" to reply
---------------------------------------------------------------------
Not in the slightest.
> Could Aemulor be built into RO and provide extra speed /
> compatability? Would it potentially allow old podules to work?
Even if it could (its just a module, afterall) it wouldnt improve its speed.
Aemulor is probably the most XScale-optimised piece of software in
existance. The only advantage an OS change might give us is putting hooks
into the Podule-initialisation code which Aemulor could use perhaps, but
Castle arent likely to make OS-changes to help a third-party application.
Version 2.20 of Aemulor is almost ready for release, which will provide
greater compatibility over 2.10, and fixes a whole load of bugs too.
> Or is it all just fine and hunky dory as is?
We like to think so :-)
And we havnt even talked about Aemulor Pro yet! :-)
Cheers,
/Neil/
--Neil Spellings
Aemulor - the 26-bit emulator for Iyonix
www.aemulor.com
Agreed.
> Aemulor is probably the most XScale-optimised piece of software in
> existance.
In fact it's so highly optimised for the XScale that it won't run on
anything else!!! Or, did I perhaps read that wrong?! ;-)
> The only advantage an OS change might give us is putting hooks
> into the Podule-initialisation code which Aemulor could use perhaps,
> but Castle arent likely to make OS-changes to help a third-party application.
And in some ways I think that's right....I still like the idea of keeping
the OS clean, 32-bit only; even though it has meant a lot more work for me!
Adrian
> Secondly, the question whether it would make it easier to IMPLEMENT
> Aemulor is pretty academic
LOL! :-) It is NOW.... truth be told, it would have made my life a good
deal easier, especially if I/Castle put the necessary hooks into the
RISC OS kernel. Instead I've had to do a lot of work, effectively
re-implementing much of the kernel's functionality from scratch to
support 26-bit apps, utilities, modules.... unsqueezing/patching of
apps that aren't StrongARM-aware etc etc.
BUT, I think there's a good argument for keeping the OS clean,
ie. purely 32-bit rather than cluttering it up with 26-bit code.
What we've now ended up with is an independent module that you can
start/stop as you wish - ie. it's self-contained and if you suspect
that some 26-bit code is interfering with the 32-bit world then
you can just kill Aemulor and all the 26-bit stuff disappears.
Also, though I think many (perhaps most?) of us thought that the
success of the Iyonix would depend critically upon 26-bit software
and thus Aemulor, I/we no longer think this is the case..... apps
have been converted much faster than we hoped, which is brilliant; now
we can move forwards! The Iyonix is a great machine in its own right
even without Aemulor's help.
> ...because the podule initialisation code would have to emulated and that
> happens before the system is booted so Aemulor cannot be loaded at that
> point.
We could, at least in theory, achieve the same result by putting Aemulor
in a ROM in podule slot 0 and adding some code to load 26-bit modules/
drivers from the others podules. It hasn't happened because it wouldn't
really gain us much as, in fact, we've only had one serious inquiry
about doing this.
> The chances that such an emulation would finally work are very slim
> though. I would certainly not want to run a system with emulated
> interrupt-driven hardware access. Sounds like a nightmare to me.
Hmmm... not sure that I agree with you there.... granted I haven't
emulated any podule drivers yet, but emulating 26-bit voice modules
(ie. sound) differs very little; the code is still interrupt driven,
and has to execute under the constraints that that imposes - not an
easy feat to achieve technically but I believe we're almost there.
That's from the technical viewpoint... but, in practice, as we've
both said before, it probably isn't worth the effort, and it'd be
preferable (and probably easier!) to convert the podule driver.
> Or is it all just fine and hunky dory as is?
Now, it would help to put Aemulor's core in ROM /IF/ you had an
XScale-based machine but the only OS you can get is a 26-bit one....
but I didn't say that! ;-) <fx:ducks & runs>
Adrian
[snip]
> Also, though I think many (perhaps most?) of us thought that the
> success of the Iyonix would depend critically upon 26-bit software
> and thus Aemulor, I/we no longer think this is the case..... apps
> have been converted much faster than we hoped, which is brilliant; now
> we can move forwards! The Iyonix is a great machine in its own right
> even without Aemulor's help.
Might it be the case that the success of Iyonix depended initially on
the confidence that Aemulor would exist? (ie if Aemulor had not been
offered as a future option, Iyonix might have enjoyed far less success)
--
Jess icq: 91353267 msn: phant...@hotmail.com http://www.kentwebnet.com
Hotmail is my spam trap - don't use for email
mailto:nos...@itworkshop.uklinux.net
RISC OS 4.36 kinetic 64+128+2M Castle Storm DMA + 17GB 586-133 I-3 ADSL
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
> In message <87caf02e.03071...@posting.google.com>
> Adria...@compuserve.com (Adrian Lees) wrote:
>
> [snip]
>
> > Also, though I think many (perhaps most?) of us thought that the
> > success of the Iyonix would depend critically upon 26-bit software
> > and thus Aemulor, I/we no longer think this is the case..... apps
> > have been converted much faster than we hoped, which is brilliant; now
> > we can move forwards! The Iyonix is a great machine in its own right
> > even without Aemulor's help.
>
> Might it be the case that the success of Iyonix depended initially on
> the confidence that Aemulor would exist? (ie if Aemulor had not been
> offered as a future option, Iyonix might have enjoyed far less success)
Yes, I think there is no doubt about that. Even nowadays it is crucial in
order to convince existing RISC OS users to upgrade to an Iyonix. There
are still a few important pieces of software out there that are not (or
not yet) converted.
Indeed. When Sibelius is runnable on an Iyonix is when I have to start
talking myself into buying one.
Well, that and Select.
James
A little more than that I would think.
For example if they wished to help you with some Artworks support module
then they could (if they wished) now give you access to the RO source where
previously they would have had to seek permission from Pace.
Your requirement for such source access is a more unlikely scenario than
for anyone working on Aemulor.
> In article <d2607f13...@mw-software.com>, Martin Wuerthner
> <mar...@invalidMW-software.com.invalid> wrote:
> > That was a mere legal act and does not have any technical consequences.
> > Of course, the purchase included the sources, but do you think they
> > created RISC OS 5 without the RISC OS sources? The difference is only
> > that they did not own the copyright before whereas they do now.
>
> A little more than that I would think.
>
> For example if they wished to help you with some Artworks support module
> then they could (if they wished) now give you access to the RO source where
> previously they would have had to seek permission from Pace.
Yes, that is correct. But my point was that it does not have any technical
consequences for Castle themselves. And yes, it is good to know that
source access via Castle is a possibility now. However, before that, it
was already possible to get source access via RiscOS Ltd. Of course, this
would not have helped if you had had a specific RISC OS 5 problem, but for
those components that are the same, having two possible parties to turn to
is a good thing.
> Your requirement for such source access is a more unlikely scenario than
> for anyone working on Aemulor.
Indeed.
> Well, that and Select.
Don't you think that these things are more likely to happen if
you buy an Iyonix now?
Evan.
Watch this space, as they say :-)
Cheers,
/Neil/
--
I did mean including the other parts of RISC OS 5, and everything else which
runs on an XScale (a la Pocket PC etc)
Cheers,
/Neil/
--
Probably, but it depends what else the OP wants to do on it. If the
answer is "nothing" (I see he's using a PC and Windows for usenet access),
then buying an Iyonix only to leave it in its box until Aemulor Pro
comes out is a bit of a waste. OTOH, if the answer is "lots of things",
then sitting back and saying "it does most of what I want now, but I'll
just wait until it makes the coffee as well" may not be the most helpful
way to support that extra development.
That said, RISC OS companies aren't charities.
--
Steve Fryatt - Leeds, England http://www.stevefryatt.org.uk/
* "Whenever you find you are on the side of the majority, it's time to
reform." - Mark Twain
> > In article <VHPRa.2$v6...@news.oracle.com>, James Sargent
> > <ro...@127.0.0.1> wrote:
> > > Indeed. When Sibelius is runnable on an Iyonix is when I
> > > have to start talking myself into buying one.
> >
> > > Well, that and Select.
> >
> > Don't you think that these things are more likely to happen
> > if you buy an Iyonix now?
> Probably, but it depends what else the OP wants to do on it.
> If the answer is "nothing" (I see he's using a PC and Windows
> for usenet access), then buying an Iyonix only to leave it in
> its box until Aemulor Pro comes out is a bit of a waste.
> OTOH, if the answer is "lots of things", then sitting back and
> saying "it does most of what I want now, but I'll just wait
> until it makes the coffee as well" may not be the most helpful
> way to support that extra development.
Agreed, but the impression I had was that James would like to
continue using RISC OS.
> That said, RISC OS companies aren't charities.
If that were the case, I wouldn't expect anything in return for
any money I gave them.
All I was trying to suggest is that if too many people adopt a
'wait and see' attitude, then it is less likely that they will
ever get what they want from RISC OS.
Evan.
> On 18 Jul, Evan Clark wrote in message
> <4c141f7...@ejclark.fsnet.co.uk>:
>
>> In article <VHPRa.2$v6...@news.oracle.com>, James Sargent
>> <ro...@127.0.0.1> wrote:
>>
>>> Indeed. When Sibelius is runnable on an Iyonix is when I have to
>>> start talking myself into buying one.
>>
>>> Well, that and Select.
>>
>> Don't you think that these things are more likely to happen if you
>> buy an Iyonix now?
Well, I do have Select for my RPC at the moment, so that's at least one
item I'm buying (and enjoying)!
> Probably, but it depends what else the OP wants to do on it. If the
> answer is "nothing" (I see he's using a PC and Windows for usenet
> access), then buying an Iyonix only to leave it in its box until
> Aemulor Pro comes out is a bit of a waste.
Exactly. One of the main reasons for buying an Acorn in the first place
was Sibelius. If I can't run that on an Iyonix (yet) then I have no need
for one (yet). Indeed, I could just buy a copy for PC or can continue to
use the copy I have on RPC.
I'm using Windows for this because (a) it's convenient and (b) I've
never successfully got to grips with setting up email / news on an
Acorn. It's always seemed horribly, horribly complicated.
James
(Who's been on holiday, which is why it took him so long to reply).
[snip]
> I'm using Windows for this because (a) it's convenient and (b) I've
> never successfully got to grips with setting up email / news on an
> Acorn. It's always seemed horribly, horribly complicated.
Get dial-up (or netfetch, whichever is relevant for your setup) and
messenger pro and stronged (or zap). This is easier to set up than
windows email.
what eh damn. I just bought new palm RAD apps to write my RISC OS
stuff on palm.
does that mean that aemulor will allow 26bit RISC OS apps to riun on a
pocketpc machine. (mind you easiwriter did this 3 years ago, albeit
with dificulty.
cheers
bob
>
> Cheers,
>
> /Neil/
> what eh damn. I just bought new palm RAD apps to write my RISC OS
> stuff on palm.
>
> does that mean that aemulor will allow 26bit RISC OS apps to riun on a
> pocketpc machine. (mind you easiwriter did this 3 years ago, albeit
> with dificulty.
Why would it? Aemulor is a RISC OS program; it requires a RISC OS
machine to run on. It doesn't magically allow RISC OS programs to run
anywhere. Tell us when RISC OS runs on your PDA :-)
--
Peter Naulls - pe...@chocky.org | http://www.chocky.org/
----------------------------------------------------------------------------
GCC for RISC OS | http://hard-mofo.dsvr.net/gcc/
Watch this space for the Palm release of Aemulor.... you wish! I wish! :-)
Aemulor 'only' contains code to hide the differences between RO4 & RO5;
you still need a full copy of RO5 & hardware capable of running it in
order to run your old RO4 programs.
Sorry!
Adrian