Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Could someone explain PPC for me?

121 views
Skip to first unread message

Jon Colverson

unread,
Aug 24, 1998, 3:00:00 AM8/24/98
to
Hi, I've been out of the Amiga "loop" for a while and I missed the
introduction of these PPC cards that are out now. Obviously, I know
what an accelerator is, but I'm confused about how these PPC ones
work. Why is there a 680x0 processor on-board as well? Will software
which isn't PPC native use the PPC or can that only use the '040 or
'060?

Thanks for any help,
Jon

PGP key and Geekcode
http://www.brianco.dircon.co.uk/info.txt

Mark Howson

unread,
Aug 25, 1998, 3:00:00 AM8/25/98
to
Jon Colverson wrote:

> Hi, I've been out of the Amiga "loop" for a while and I missed the
> introduction of these PPC cards that are out now. Obviously, I know
> what an accelerator is, but I'm confused about how these PPC ones
> work. Why is there a 680x0 processor on-board as well? Will software
> which isn't PPC native use the PPC or can that only use the '040 or
> '060?

The PPC cards have, as you say, two processors. At the moment there is
no 0x0 emulation software available for the PPC (this may well change
soon), so the cards need an 0x0 too. Most software isn't PPC native, so
the PPC sits there like an idiot 95% of the time. Note the OS is still
completely 0x0 too :(

Typically, a card (eg. mine) will have a 68040/25 for normal usage and a
(say) 200MHz PPC 603e processor. There are versions with different 0x0
processors and better PPC models. See www.phase5.de

There is some PPC software now, which runs okay, but there's hardly any
of it and most of it is useless or bug filled. There's a nice Doom
conversion or two, but Quake still isn't here (unless you count the
hacks, and they're a) illegal b) crap :)

BTW: There are two different bits of PPC 'controller' software. The
'offical' one by Phase 5 (ppc.library) is better supported, but it's
still miles from perfect. The 'unoffical' one is by Haage&Partner,
written because the original Phase5 software is so horrible. Some say
H&P's version (WarpUP or WarpOS) is superior, some prefer Phase 5's
ppc.library.

I think that covers most of it.

Mark

Steffen Haeuser

unread,
Aug 25, 1998, 3:00:00 AM8/25/98
to

Mark....@nottingham.ac.uk wrote :

Hi!

Ma> The PPC cards have, as you say, two processors. At the moment there is
Ma> no 0x0 emulation software available for the PPC (this may well change

It is (at least for some Beta-Testers of Haage&Partner :) ) and it already
runs quite nice.

Ma> BTW: There are two different bits of PPC 'controller' software. The
Ma> 'offical' one by Phase 5 (ppc.library) is better supported, but it's
Ma> still miles from perfect. The 'unoffical' one is by Haage&Partner,
Ma> written because the original Phase5 software is so horrible. Some say
Ma> H&P's version (WarpUP or WarpOS) is superior, some prefer Phase 5's
Ma> ppc.library.

^^^^^^^^^^^^^^^

Out of wrong-understood "Hero-worship" for Phase 5...

Steffen Haeuser

Georg Rottlaender

unread,
Aug 25, 1998, 3:00:00 AM8/25/98
to

> Ma> BTW: There are two different bits of PPC 'controller' software. The
> Ma> 'offical' one by Phase 5 (ppc.library) is better supported, but it's
> Ma> still miles from perfect. The 'unoffical' one is by Haage&Partner,
> Ma> written because the original Phase5 software is so horrible. Some say
> Ma> H&P's version (WarpUP or WarpOS) is superior, some prefer Phase 5's
> Ma> ppc.library.
> ^^^^^^^^^^^^^^^
>
> Out of wrong-understood "Hero-worship" for Phase 5...

.. yes! You got it! All PPC owners are only using ppc.library
respectively developping for ppc.library because of 'wrong-understood
"Hero-worship" for Phase 5' ... *BS*!

Bye!

Georg

--
Georg Rottlaender - Friedrich-Ebert-Str. 4 - D-53721 Siegburg
Phone: +49-2241-590230 - E-Mail: Georg.Ro...@home.ivm.de
Homepage: http://home.ivm.de/~Georg.Rottlaender
-------------- Powered Up And Back From The Future --------------


Jon Colverson

unread,
Aug 25, 1998, 3:00:00 AM8/25/98
to
Thanks Mark, that's exactly what I wanted to know.

joe

unread,
Aug 25, 1998, 3:00:00 AM8/25/98
to
** To reply in e-mail, remove "cyhder." from address **

On Tue, 25 Aug 1998 10:49:42 +0100, Mark Howson wrote about Re: Could someone explain PPC for me?:

<snips>

> The PPC cards have, as you say, two processors. At the moment there is

> no 0x0 emulation software available for the PPC (this may well change

> soon), so the cards need an 0x0 too. Most software isn't PPC native, so
> the PPC sits there like an idiot 95% of the time. Note the OS is still
> completely 0x0 too :(
>
> Typically, a card (eg. mine) will have a 68040/25 for normal usage and a
> (say) 200MHz PPC 603e processor. There are versions with different 0x0
> processors and better PPC models. See www.phase5.de
>
> There is some PPC software now, which runs okay, but there's hardly any
> of it and most of it is useless or bug filled. There's a nice Doom
> conversion or two, but Quake still isn't here (unless you count the
> hacks, and they're a) illegal b) crap :)
>

> BTW: There are two different bits of PPC 'controller' software. The

> 'offical' one by Phase 5 (ppc.library) is better supported, but it's

> still miles from perfect. The 'unoffical' one is by Haage&Partner,

> written because the original Phase5 software is so horrible. Some say

> H&P's version (WarpUP or WarpOS) is superior, some prefer Phase 5's

> ppc.library.
>
> I think that covers most of it.


Congradulations Mark. That is the most honest statement about PPC to
date. No bias, no politics, no bs - just facts. Thank you and what the
hell are you doing here ;) .............joe

ark

unread,
Aug 26, 1998, 3:00:00 AM8/26/98
to
Steffen Haeuser (mag...@birdland.es.bawue.de) wrote:

: Out of wrong-understood "Hero-worship" for Phase 5...

It's interesting that a simple question like "Could someone explain
PPC for me" does suffice to cause another flame-war...

Steffen Haeuser

unread,
Aug 26, 1998, 3:00:00 AM8/26/98
to

klei...@studm.hrz.uni-siegen.de wrote :

Hi!

kl> Steffen Haeuser (mag...@birdland.es.bawue.de) wrote:

kl> : Out of wrong-understood "Hero-worship" for Phase 5...

kl> It's interesting that a simple question like "Could someone explain
kl> PPC for me" does suffice to cause another flame-war...

As to your position in this whole situation i would answer with a german
proverb "Wer im Glashaus sitzt, soll nicht mit Steinen werfen." :)

Steffen Haeuser

Johan Eriksson

unread,
Aug 26, 1998, 3:00:00 AM8/26/98
to
On Tue, 25 Aug 1998, Mark Howson wrote:

> Jon Colverson wrote:
>
> > Hi, I've been out of the Amiga "loop" for a while and I missed the
> > introduction of these PPC cards that are out now. Obviously, I know
> > what an accelerator is, but I'm confused about how these PPC ones
> > work. Why is there a 680x0 processor on-board as well? Will software
> > which isn't PPC native use the PPC or can that only use the '040 or
> > '060?

[SNIP]

> BTW: There are two different bits of PPC 'controller' software. The
> 'offical' one by Phase 5 (ppc.library) is better supported, but it's
> still miles from perfect. The 'unoffical' one is by Haage&Partner,
> written because the original Phase5 software is so horrible. Some say

~~
Mind the grammar, should be "was".

/Johan Eriksson, joh...@lysator.liu.se


Lowry Stiles

unread,
Aug 26, 1998, 3:00:00 AM8/26/98
to
On 26 Aug 1998 13:39:12, mag...@birdland.es.bawue.de (Steffen
Haeuser) wrote:

And for the Germanic-impaired folks, just what does this mean so we
may share in the laughter?


Love, peace, and chicken grease!

Lowry Stiles....Email: low...@hotmail.com

Steffen Haeuser

unread,
Aug 26, 1998, 3:00:00 AM8/26/98
to

joh...@sally.lysator.liu.se wrote :

Hi!


>> BTW: There are two different bits of PPC 'controller' software. The
>> 'offical' one by Phase 5 (ppc.library) is better supported, but it's
>> still miles from perfect. The 'unoffical' one is by Haage&Partner,
>> written because the original Phase5 software is so horrible. Some say

jo> ~~
jo> Mind the grammar, should be "was".

It is is...it is is...

And even if it would be good now... it still is a strange thing... while
WarpOS is the amiga-way of things... everything implemented like in exec and
such...

Steffen Haeuser


joe

unread,
Aug 27, 1998, 3:00:00 AM8/27/98
to
** To reply in e-mail, remove "qicmij." from address **

On Wed, 26 Aug 1998 20:55:36 GMT, Lowry Stiles wrote about Re: Could someone explain PPC for me?:


> On 26 Aug 1998 13:39:12, mag...@birdland.es.bawue.de (Steffen
> Haeuser) wrote:
>
> >
> > klei...@studm.hrz.uni-siegen.de wrote :
> >
> >Hi!
> >
> >kl> Steffen Haeuser (mag...@birdland.es.bawue.de) wrote:
> >
> >kl> : Out of wrong-understood "Hero-worship" for Phase 5...
> >
> >kl> It's interesting that a simple question like "Could someone explain
> >kl> PPC for me" does suffice to cause another flame-war...
> >
> >As to your position in this whole situation i would answer with a german
> >proverb "Wer im Glashaus sitzt, soll nicht mit Steinen werfen." :)
>
> And for the Germanic-impaired folks, just what does this mean so we
> may share in the laughter?


Flame war from such few posts? Someone hasn't been on the ngs very long...joe

ark

unread,
Aug 27, 1998, 3:00:00 AM8/27/98
to
Lowry Stiles (lowrys&sp...@hotmail.com) wrote:

: >kl> It's interesting that a simple question like "Could someone explain


: >kl> PPC for me" does suffice to cause another flame-war...
: >
: >As to your position in this whole situation i would answer with a german
: >proverb "Wer im Glashaus sitzt, soll nicht mit Steinen werfen." :)

You didn't get the point. I'm not starting new flame-wars when someone
asks a question to get some objective facts. As if the whole issue
wouldn't be strange enough as such.

: And for the Germanic-impaired folks, just what does this mean so we


: may share in the laughter?

It didn't fit, anyway.

ark

unread,
Aug 27, 1998, 3:00:00 AM8/27/98
to
Steffen Haeuser (mag...@birdland.es.bawue.de) wrote:

: As to your position in this whole situation i would answer with a german
: proverb "Wer im Glashaus sitzt, soll nicht mit Steinen werfen." :)

To reply in a german conclusion: "Wenn zwei sich streiten und in
demselben Glashaus mit wachsender Begeisterung bei jeder Gelegenheit
mit Steinen werfen, braucht sich hinterher keiner zu wundern, wenn es
irgendwann einfach irreparabel kaputt ist."

joe

unread,
Aug 27, 1998, 3:00:00 AM8/27/98
to
** To reply in e-mail, remove "hyvxob." from address **

On 26 Aug 1998 23:36:49, Steffen Haeuser wrote about Re: Could someone explain PPC for me?:


OK, I agree that WarpOS is better than PPC.library. I was branded a blasphemor
(or something similar) many many months ago when I hung out on the PPC mailing list
for that opinion. I paid attention to the software developers since they have to
write the PPC software I was going to buy. Made sense to me at the time.

So what's happening NOW? The H&P/Phase5 announcement was months ago. Do
we have a new standard yet? We've all read that "both standards will work on
the new standard" many times. Yeah, that's reassuring. We want the new
improved, stable, "everyone wants to program for it" PPC standard? If I missed
it please fill me in...................joe

PS I hope to God Phase5 had the good sense to implement H&Ps ideas. If not,
PPC is in worse shape now than it ever was.

Joe Cosby

unread,
Aug 27, 1998, 3:00:00 AM8/27/98
to
** To reply in e-mail, remove "feslan." from address **

On Wed, 26 Aug 1998 20:55:36 GMT, Lowry Stiles wrote about Re: Could someone explain PPC for me?:

[snip]

> >
> >As to your position in this whole situation i would answer with a german
> >proverb "Wer im Glashaus sitzt, soll nicht mit Steinen werfen." :)
>

> And for the Germanic-impaired folks, just what does this mean so we
> may share in the laughter?
>

Here, catch:

http://babelfish.altavista.digital.com/cgi-bin/translate?

--
-----------------------------------------------------------------------------
Joe Cosby

Devout member of the Church of Amiga since 1990

"Whatever you can do, or dream you can, begin it.
Boldness has genius, power and magic in it" - Goethe
-----------------------------------------------------------------------------

Joe Cosby

unread,
Aug 27, 1998, 3:00:00 AM8/27/98
to
** To reply in e-mail, remove "poscuw." from address **

Joe Cosby

unread,
Aug 27, 1998, 3:00:00 AM8/27/98
to
** To reply in e-mail, remove "xydfob." from address **

Joe Cosby

unread,
Aug 27, 1998, 3:00:00 AM8/27/98
to
** To reply in e-mail, remove "lywnod." from address **

Mark Howson

unread,
Aug 27, 1998, 3:00:00 AM8/27/98
to
Johan Eriksson wrote:

>
> I wrote:
> >
> > BTW: There are two different bits of PPC 'controller' software. The
> > 'offical' one by Phase 5 (ppc.library) is better supported, but it's
> > still miles from perfect. The 'unoffical' one is by Haage&Partner,
> > written because the original Phase5 software is so horrible. Some say
> ~~

> Mind the grammar, should be "was".

YMMV, but I'll leave it as 'is' :)

Mark

Steffen Haeuser

unread,
Aug 27, 1998, 3:00:00 AM8/27/98
to

klei...@studm.hrz.uni-siegen.de wrote :

Hi!

kl> : As to your position in this whole situation i would answer with a german
kl> : proverb "Wer im Glashaus sitzt, soll nicht mit Steinen werfen." :)

kl> To reply in a german conclusion: "Wenn zwei sich streiten und in
kl> demselben Glashaus mit wachsender Begeisterung bei jeder Gelegenheit
kl> mit Steinen werfen, braucht sich hinterher keiner zu wundern, wenn es
kl> irgendwann einfach irreparabel kaputt ist."

Okay, der Punkt geht an Dich...

Steffen

Steffen Haeuser

unread,
Aug 27, 1998, 3:00:00 AM8/27/98
to

klei...@studm.hrz.uni-siegen.de wrote :

Hi!

kl> : >As to your position in this whole situation i would answer with a german
kl> : >proverb "Wer im Glashaus sitzt, soll nicht mit Steinen werfen." :)

kl> You didn't get the point. I'm not starting new flame-wars when someone
kl> asks a question to get some objective facts. As if the whole issue
kl> wouldn't be strange enough as such.

As to my experience there are two ways to handle the flaming:

1) basic flaming
2) "playing" objective :)

I usually prefer the more direct method 1...

Steffen Haeuser

Steffen Haeuser

unread,
Aug 27, 1998, 3:00:00 AM8/27/98
to

lowrys&sp...@hotmail.com wrote :

Hi!

>>
>>kl> It's interesting that a simple question like "Could someone explain
>>kl> PPC for me" does suffice to cause another flame-war...
>>

>>As to your position in this whole situation i would answer with a german

>>proverb "Wer im Glashaus sitzt, soll nicht mit Steinen werfen." :)

lo> And for the Germanic-impaired folks, just what does this mean so we
lo> may share in the laughter?

Forget it, the old dispute between Andreas and me...

Steffen Haeuser

sjoerd de vries

unread,
Aug 28, 1998, 3:00:00 AM8/28/98
to

Steffen Haeuser heeft geschreven in bericht
<6000010651...@BIRDLAND.es.bawue.de>...
>
>
> joh...@sally.lysator.liu.se wrote :
>
>Hi!

>
>
>>> BTW: There are two different bits of PPC 'controller' software. The
>>> 'offical' one by Phase 5 (ppc.library) is better supported, but it's
>>> still miles from perfect. The 'unoffical' one is by Haage&Partner,
>>> written because the original Phase5 software is so horrible. Some say
>jo> ~~
>jo> Mind the grammar, should be "was".
>
>It is is...it is is...
>
>And even if it would be good now... it still is a strange thing... while
>WarpOS is the amiga-way of things... everything implemented like in exec
and
>such...
>
>Steffen Haeuser
>
And if there was No warpOS there would be more software for ppc.
And even Napalm DEMO would running better when RTG master didn't
call for powerpc.library.

bye,

Sjoerd


joe

unread,
Aug 28, 1998, 3:00:00 AM8/28/98
to
** To reply in e-mail, remove "rybjaq." from address **

On 28 Aug 1998 18:12:34 GMT, "sjoerd de vries" wrote about Re: Could someone explain PPC for me?:


Yeah, there would be more software that didn't work. Personal Paint
was written with ppc.library with Phase5's cooperation. Now Cloanto
is stuck with one of the few commercial PPC programs and it doesn't
work. Not Cloanto's fault since they checked with Phase5. No way it
can be H&Ps fault since WarpOS wasn't involved. Who does that leave?

Even if you can't bring yourself to answer that last question it still
puts PPC software developers between a rock and a hard place. And
guess where that leaves the rest of us?..........joe

John Murphy

unread,
Aug 28, 1998, 3:00:00 AM8/28/98
to
In article <35e4761e...@news.usit.net>, Lowry Stiles wrote:
>On 26 Aug 1998 13:39:12, mag...@birdland.es.bawue.de (Steffen
>Haeuser) wrote:
>>As to your position in this whole situation i would answer with a german
>>proverb "Wer im Glashaus sitzt, soll nicht mit Steinen werfen." :)
>
>And for the Germanic-impaired folks, just what does this mean so we
>may share in the laughter?

"People who live in glass houses shouldn't throw stones."


Georg Rottlaender

unread,
Aug 28, 1998, 3:00:00 AM8/28/98
to

> Yeah, there would be more software that didn't work. Personal Paint
> was written with ppc.library with Phase5's cooperation. Now Cloanto
> is stuck with one of the few commercial PPC programs and it doesn't
> work. Not Cloanto's fault since they checked with Phase5. No way it
> can be H&Ps fault since WarpOS wasn't involved. Who does that leave?

.. Cloanto isn't willing to adopt to the current ppc.library ... and
BTW Personal Paint was never written with ppc.library but
personal_ppc_blit.library ... nothing more and nothing less.

joe

unread,
Aug 29, 1998, 3:00:00 AM8/29/98
to
** To reply in e-mail, remove "nezleg." from address **

On 28 Aug 98 23:21:01 +0200, "Georg Rottlaender" wrote about Re: Could someone explain PPC for me?:


>
> > Yeah, there would be more software that didn't work. Personal Paint
> > was written with ppc.library with Phase5's cooperation. Now Cloanto
> > is stuck with one of the few commercial PPC programs and it doesn't
> > work. Not Cloanto's fault since they checked with Phase5. No way it
> > can be H&Ps fault since WarpOS wasn't involved. Who does that leave?
>
> .. Cloanto isn't willing to adopt to the current ppc.library ... and
> BTW Personal Paint was never written with ppc.library but
> personal_ppc_blit.library ... nothing more and nothing less.

I wouldn't either since it's about to be replaced. And since Phase5
was involved in this commercial endeavor, they might have helped to
make sure it wasn't crippled in the next release.........joe

Steffen Haeuser

unread,
Aug 29, 1998, 3:00:00 AM8/29/98
to

svr...@telekabel.nl wrote :

Hi!

sv> And if there was No warpOS there would be more software for ppc.

Doubt so. Many firms/people would not even CONSIDER PPC Support if only the
Phase 5 solution would exist. Also i doubt that AmigaOS 3.5 PPC project would
exist...

sv> And even Napalm DEMO would running better when RTG master didn't
sv> call for powerpc.library.

It runs fine here.

BTW: IsisPPC would run much finer, if it used WarpUP, and would not disable
Picasso96 also...
to give the opposite direction.

To tell it plain. Decision pro WarpUP for next OS is done. So it is better to
forget about ppc.library now, else problems later...

Steffen Haeuser

ark

unread,
Aug 29, 1998, 3:00:00 AM8/29/98
to
John Murphy (jcmu...@dircon.co.uk) wrote:

: "People who live in glass houses shouldn't throw stones."

roughly ;)

ark

unread,
Aug 29, 1998, 3:00:00 AM8/29/98
to
joe (e...@nezleg.epix.net) wrote:

: I wouldn't either since it's about to be replaced. And since Phase5


: was involved in this commercial endeavor, they might have helped to
: make sure it wasn't crippled in the next release.........joe

There was no *public* ppc.library release at the time the first
version of that ppc_blit.library had been released - while I
don't know about later incompatibilities, the *first* one
obviously was caused by 'late changes'.

Keith Blakemore-Noble

unread,
Aug 30, 1998, 3:00:00 AM8/30/98
to
In article <6s73pt$i9h$1...@news1.epix.net>, joe wrote:

>Yeah, there would be more software that didn't work. Personal Paint
>was written with ppc.library with Phase5's cooperation. Now Cloanto
>is stuck with one of the few commercial PPC programs and it doesn't
>work. Not Cloanto's fault since they checked with Phase5

Joe Joe Joe, please do try to get facts correct in these things! :)

PP's PPC plugins were written using a VERY OLD early version of the
ppc.library system, which was changed long long ago, but Cloanto have not
(for whatever reason) bothered to follow P5's suggestions for making the ppc
plugins actually conform to the ppc.library system, therefore P5 can hardly
be blamed for Cloanto's refusal to correct Cloanto's code!!!

(BTW, ppc.library is now a very very stable system indeed.)


Just thought I'd help to clarify any misimpression your original post may
have accidentally created.

HTH,
Keith


joe

unread,
Aug 30, 1998, 3:00:00 AM8/30/98
to
** To reply in e-mail, remove "siqfaw." from address **

On Sun, 30 Aug 1998 00:22:15 GMT, Keith Blakemore-Noble wrote about Re: Could someone explain PPC for me?:


Better check back on this thread Keith. The last poster claimed Cloanto
didn't even use ppc.library. I'm not saying you're wrong. Maybe they used
both libraries. Doesn't matter anyways since Phase5 was involved in
product testing. Commercial software can't be expected to make money
if it has to be updated as often as ppc.library.

BTW, *very old* for Phase5 is a poor (VERY POOR) excuse. We're are talking
about standards here. I can still run Sonix, Intellitype, and Sierra Games
Kondike (possibly the worst PC ported Amiga game ever) on OS3.0. It seems
CBM kept enough compatibility between revs to keep those commercial
titles running. And they weren't even AGA aware. Both the hardware AND
the system software changed. I don't expect Phase5 to go to those lengths.
That would be unreasonable. Besides, it's not even possible as PPC has
only been available for about a year.

I'd like to know what the result of the Phase5 / H&P cooperation has
yielded. That's where the future of PPC is going to be IMO. When are
we going to see it? Does anyone know?...............joe

Georg Rottlaender

unread,
Aug 30, 1998, 3:00:00 AM8/30/98
to

> BTW: IsisPPC would run much finer, if it used WarpUP, and would not disable
> Picasso96 also...
> to give the opposite direction.

.. if you'd use the latest version of IsisPPC, you'd realize that
Picasso96 is no longer disabled.

Georg Rottlaender

unread,
Aug 30, 1998, 3:00:00 AM8/30/98
to

> To tell it plain. Decision pro WarpUP for next OS is done. So it is better to
> forget about ppc.library now, else problems later...

.. could you provide us some more details? ;-)

What do you call 'next OS'? Who made this decision? ...

Keith Blakemore-Noble

unread,
Aug 30, 1998, 3:00:00 AM8/30/98
to
In article <6sause$slb$1...@news1.epix.net>, joe wrote:
>
>Better check back on this thread Keith. The last poster claimed Cloanto
>didn't even use ppc.library

I wasn't replying to that sub-thread though Joe (personally I woudl say that
Cloanto PP does use ppc.library, in addition to its own blit.library, but I
am just guessing here, I can't be bothered to install PP again just to
check, not now I use much better gfx software <g>).

The point I was making was simply that Cloanto are refusing to update their
software, and thus P5 cannot be blamed for Clonato's refusal!

>product testing. Commercial software can't be expected to make money
>if it has to be updated as often as ppc.library.

If it were true that software has to be updated every time a new ppc.library
revision is released, then I woudl definitly agree with you.

HOWEVER, given that it is completely UNTRUE to say that such updates are
required, then this is a non-issue.

Point of the matter is that Cloanto developed their (somewhat limited) ppc
addon based on a *beta* release of ppc.library, and once P5 fixed the
problems with the beta release giving us a lovely release version, Cloanto
were the ONLY people to refuse to make any necessary small modifications.

The alternative woudl have been for P5 to not fix the ppc.library -
something which I am sure no-body here coudl seriously suggest was a good
idea (not even You Know Who <g> ;-) )

>BTW, *very old* for Phase5 is a poor (VERY POOR) excuse.

No, it is a FACT.

If you develop based on a *BETA* then you can reasonably expect that the
possibility of potential changes *MAY* occur.

ANYONE with any programming experience and development sense wil know this.

> We're are talking
>about standards here. I can still run Sonix, Intellitype, and Sierra Games
>Kondike (possibly the worst PC ported Amiga game ever) on OS3.0. It seems

Now try running them all on the first *NETA* release of OS3 and tell me that
they all work flawlessly...?

There are countless examples of software written for 1.3 or 2.04 which
doesn't work on 3.1 - such is life.

Heck, it's funny how everyone else developing pc.library-based applications
manages to find thattheir code works fine and does not need to be updated
"after every ppc.library update"...

>I'd like to know what the result of the Phase5 / H&P cooperation has
>yielded. That's where the future of PPC is going to be IMO. When are
>we going to see it? Does anyone know?...............joe

Now that IS a question to which I woudllove to see a publically stated
definitive answer, definitly - once they do actualy get a final combined
solution out, then thngs can only improve for teh customer.

However, I leave you with one final question - if an old piece of ppc
software shodul fail to work under teh new syste,m for whatever reason, will
you be blaming P5 and H&P when the author of the old software refuses to
make the minor changes necessary to upgrade? :)


TTFN,
Keith

joe

unread,
Aug 30, 1998, 3:00:00 AM8/30/98
to
** To reply in e-mail, remove "wilfiw." from address **

On Mon, 31 Aug 1998 00:57:58 +0200, Johan Eriksson wrote about Re: Could someone explain PPC for me?:
> On 29 Aug 1998, Steffen Haeuser wrote:
>
> >
> > svr...@telekabel.nl wrote :
> >
> > Hi!
> >
> > sv> And if there was No warpOS there would be more software for ppc.
> >
> > Doubt so. Many firms/people would not even CONSIDER PPC Support if only the
> > Phase 5 solution would exist. Also i doubt that AmigaOS 3.5 PPC project would
> > exist...
>

> WarpOS might have helped getting things moving with the development of
> P5:s system. Competition speeds people up ;)

Yeah, especially if it works better than Phase5's :).......joe

Steffen Haeuser

unread,
Aug 30, 1998, 3:00:00 AM8/30/98
to

e...@siqfaw.epix.net wrote :

Hi!

ee> Better check back on this thread Keith. The last poster claimed Cloanto
ee> didn't even use ppc.library. I'm not saying you're wrong. Maybe they used
ee> both libraries. Doesn't matter anyways since Phase5 was involved in
ee> product testing. Commercial software can't be expected to make money
ee> if it has to be updated as often as ppc.library.

Well, AFAIK Cloanto quit the PPC-Stuff because of ppc.library changing all the
time so that recompiles where needed. Other firms also were disappointed of
this, but

a) took it like it came and did ppc.library support anyways

or

b) Changed to WarpOS

ee> BTW, *very old* for Phase5 is a poor (VERY POOR) excuse. We're are talking
ee> about standards here. I can still run Sonix, Intellitype, and Sierra Games
ee> Kondike (possibly the worst PC ported Amiga game ever) on OS3.0. It seems

And if we keep at PPC... WarpUP Applications compiled for powerpc.library V1
still run on V14...

ee> I'd like to know what the result of the Phase5 / H&P cooperation has
ee> yielded. That's where the future of PPC is going to be IMO. When are
ee> we going to see it? Does anyone know?...............joe

Well, yeah, sort of. AI now chose which kernel they want to use in OS 3.5 PPC,
and informed both H&P and P5. I hope an official announcement will come soon.

Steffen Haeuser

Steffen Haeuser

unread,
Aug 30, 1998, 3:00:00 AM8/30/98
to

ke...@amiga.u-net.com wrote :

Hi!

ke> Joe Joe Joe, please do try to get facts correct in these things! :)

ke> PP's PPC plugins were written using a VERY OLD early version of the
ke> ppc.library system, which was changed long long ago, but Cloanto have not
ke> (for whatever reason) bothered to follow P5's suggestions for making the ppc
ke> plugins actually conform to the ppc.library system, therefore P5 can hardly
ke> be blamed for Cloanto's refusal to correct Cloanto's code!!!

Actually this is not the problem. Even if you conformed to EVERYTHING,
programs using old versions of ppc.library had to be recompiled, appearently.
Cloanto was not the only firm having this problem.

And well... on WarpUP programs done for powerpc.library V1 still run...

Steffen Haeuser

Steffen Haeuser

unread,
Aug 30, 1998, 3:00:00 AM8/30/98
to

Georg.Ro...@home.ivm.de wrote :

Hi!

Ge> .. could you provide us some more details? ;-)

Actually, i don't have TOO much details, asides from information of a letter
that went from AI to both H&P and Phase 5. I guess you can expect official
information next week (i hope at least). Up to now, i only know that this is
finally really a DECISION, on a phone call, i was read parts of the letter...
it is not a "we would like to use WarpUP, but have not yet decided" like in
the past few weeks... finally they made a decision...

Ge> What do you call 'next OS'? Who made this decision? ...

OS3.5 PPC. I hope there will be out more info soon.

Steffen Haeuser

Johan Eriksson

unread,
Aug 31, 1998, 3:00:00 AM8/31/98
to
On 29 Aug 1998, Steffen Haeuser wrote:

>
> svr...@telekabel.nl wrote :
>
> Hi!
>
> sv> And if there was No warpOS there would be more software for ppc.
>
> Doubt so. Many firms/people would not even CONSIDER PPC Support if only the
> Phase 5 solution would exist. Also i doubt that AmigaOS 3.5 PPC project would
> exist...

WarpOS might have helped getting things moving with the development of
P5:s system. Competition speeds people up ;)

/Johan Eriksson, joh...@lysator.liu.se


joe

unread,
Aug 31, 1998, 3:00:00 AM8/31/98
to
** To reply in e-mail, remove "jyxtaf." from address **

On 30 Aug 1998 19:55:56, Steffen Haeuser wrote about Re: Could someone explain PPC for me?:

<snips>



> ee> I'd like to know what the result of the Phase5 / H&P cooperation has
> ee> yielded. That's where the future of PPC is going to be IMO. When are
> ee> we going to see it? Does anyone know?...............joe
>
> Well, yeah, sort of. AI now chose which kernel they want to use in OS 3.5 PPC,
> and informed both H&P and P5. I hope an official announcement will come soon.


It's only a crumb of info. But at least it's something. Maybe this has
been holding up Phase5 and H&P (I hope not).....................joe

joe

unread,
Aug 31, 1998, 3:00:00 AM8/31/98
to
** To reply in e-mail, remove "bimwij." from address **

On 30 Aug 1998 23:21:33, Steffen Haeuser wrote about Re: Could someone explain PPC for me?:


Can you just imagine how much different the PPC situation would be today
if H&P did the official PPC software right from the beginning? Your last
sentence speaks volumes. A damn shame.............joe

sam jordan

unread,
Aug 31, 1998, 3:00:00 AM8/31/98
to
Steffen Haeuser wrote:

> Actually this is not the problem. Even if you conformed to EVERYTHING,
> programs using old versions of ppc.library had to be recompiled, appearently.
> Cloanto was not the only firm having this problem.
>
> And well... on WarpUP programs done for powerpc.library V1 still run...

Not V1, but from V7 on. V1-6 were never released to the public and
had a different API.

bye
--
Sam Jordan
Member of Haage&Partner PowerPC Development Team

s.jo...@haage-partner.com (business related)
sam_j...@bluewin.ch (private related)

Johan Eriksson

unread,
Aug 31, 1998, 3:00:00 AM8/31/98
to
On 30 Aug 1998, Steffen Haeuser wrote:

>
> ee> Better check back on this thread Keith. The last poster claimed Cloanto
> ee> didn't even use ppc.library. I'm not saying you're wrong. Maybe they used
> ee> both libraries. Doesn't matter anyways since Phase5 was involved in
> ee> product testing. Commercial software can't be expected to make money
> ee> if it has to be updated as often as ppc.library.
>
> Well, AFAIK Cloanto quit the PPC-Stuff because of ppc.library changing all the
> time so that recompiles where needed. Other firms also were disappointed of
> this, but

Don't want to continue the flames, but a beta is a beta.

> Well, yeah, sort of. AI now chose which kernel they want to use in OS 3.5 PPC,
> and informed both H&P and P5. I hope an official announcement will come soon.

If WOS gets to be the standard I'll happily support it.
If PUP gets to be the standard I'll happily support it.
If a mysterious kernel written by Sean Connery gets to be..and so on.

As long as something united shows up I'll jump up and down in joy, unless
it is a crappy thingy with Gree7z 2 c00l d3wdz at boot time ;)

I hope nobody feels different about it.

/Johan Eriksson, joh...@lysator.liu.se


Johan Eriksson

unread,
Aug 31, 1998, 3:00:00 AM8/31/98
to
On Mon, 31 Aug 1998, sam jordan wrote:

> Steffen Haeuser wrote:
>
> > Actually this is not the problem. Even if you conformed to EVERYTHING,
> > programs using old versions of ppc.library had to be recompiled, appearently.
> > Cloanto was not the only firm having this problem.
> >
> > And well... on WarpUP programs done for powerpc.library V1 still run...
>
> Not V1, but from V7 on. V1-6 were never released to the public and
> had a different API.

As was the case with the betas of ppc.library...

/Johan Eriksson, joh...@lysator.liu.se


Johan Eriksson

unread,
Aug 31, 1998, 3:00:00 AM8/31/98
to

Ok, so the ppc.library betas were available to the public since V45. I'd
better point that out before someone else does.

/Johan Eriksson, joh...@lysator.liu.se


Wojciech Orlinski

unread,
Aug 31, 1998, 3:00:00 AM8/31/98
to
They made it - Haage-Partner releases the beta version of 68k
emulation for PPC cards. All I want to know now is: how good is
it. What 68k does it emulate exactly? A plain 68000 or something
closer to 68040? Is the emulated 68k better or worse than regular
040/25? Does the emulator emulates Data and Instruction CPU caches?
Does it emulate 060 superscalar mode?

It's a quite important question, I think - about a half of the
price of Blizzard/Cyberstorm PPC boards is the 68k chip. Would the
emulated 68k perform better than a real thing...

--
Wojciech Orlinski 'de omnibus dubitandum'
http://www.geocities.com/CapitolHill/2594

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum

Satoru

unread,
Sep 1, 1998, 3:00:00 AM9/1/98
to
Wojciech Orlinski (ig...@hotmail.com) wrote:
: They made it - Haage-Partner releases the beta version of 68k

: emulation for PPC cards. All I want to know now is: how good is
: it. What 68k does it emulate exactly? A plain 68000 or something
: closer to 68040? Is the emulated 68k better or worse than regular
: 040/25? Does the emulator emulates Data and Instruction CPU caches?
: Does it emulate 060 superscalar mode?

: It's a quite important question, I think - about a half of the
: price of Blizzard/Cyberstorm PPC boards is the 68k chip. Would the
: emulated 68k perform better than a real thing...

I think if someone comes out with a G3 type accelerator the 68k emu would
scream! So are we ever going to see one?!? I would especially want one for
my A1200 with BVisionPPC! (Hint P5, are you listening?)

sam jordan

unread,
Sep 1, 1998, 3:00:00 AM9/1/98
to
Wojciech Orlinski wrote:
>
> They made it - Haage-Partner releases the beta version of 68k
> emulation for PPC cards. All I want to know now is: how good is
> it. What 68k does it emulate exactly? A plain 68000 or something
> closer to 68040? Is the emulated 68k better or worse than regular

68040/FPU/MMU (MMU not completely finished yet, but address
translation works)

> 040/25? Does the emulator emulates Data and Instruction CPU caches?

Speed is about equal for 604E based systems.

Instruction cache is not emulated (why should I?), it's always on
(although the tools will tell you that it's off, if you try to
switch IC off). Data cache is emulated using the PPC MMU.

> Does it emulate 060 superscalar mode?

No, because it emulates a 68040. Anyway, it would not make sense
to emulate superscalar mode, the emulator is a software, not
a processor :)

Steffen Haeuser

unread,
Sep 1, 1998, 3:00:00 AM9/1/98
to

B...@Hawaii.Edu wrote :

Hi!

B@> : It's a quite important question, I think - about a half of the
B@> : price of Blizzard/Cyberstorm PPC boards is the 68k chip. Would the
B@> : emulated 68k perform better than a real thing...

B@> I think if someone comes out with a G3 type accelerator the 68k emu would

Yes, definitely. I was told before that 060-like speed should be reachable (or
even faster). An interesting factor is especially, that the G3 *always* has a
2nd-level cache...

B@> scream! So are we ever going to see one?!? I would especially want one for
B@> my A1200 with BVisionPPC! (Hint P5, are you listening?)

Hmmm, what has that do do with the BVisionPPC ? You probably meant
BlizzardPPC, don't you ? :)

Steffen Haeuser

Randy Vice

unread,
Sep 2, 1998, 3:00:00 AM9/2/98
to
On Tue 1-Sep-1998 11:51a, jord...@htlchur.ch wrote:
j> Wojciech Orlinski wrote:
j> >
j> > They made it - Haage-Partner releases the beta version of 68k
j> > emulation for PPC cards. All I want to know now is: how good is
j> > it. What 68k does it emulate exactly? A plain 68000 or something
j> > closer to 68040? Is the emulated 68k better or worse than regular

j> 68040/FPU/MMU (MMU not completely finished yet, but address
j> translation works)

j> > 040/25? Does the emulator emulates Data and Instruction CPU caches?

j> Speed is about equal for 604E based systems.

<snip>

Is it multithreaded? If so, love to see what it could do on a SMP.

: damo...@nostromo.gate.net : Bruce Morrow,a man before and after his time:
:"The Constitution shall never be construed to prevent the people of the :
:United States who are peaceable citizens from keeping their own arms." :
: - Samuel Adams : Morrow Project Science - Post-holocaust Party Animals! :

sam jordan

unread,
Sep 2, 1998, 3:00:00 AM9/2/98
to
Randy Vice wrote:

> Is it multithreaded? If so, love to see what it could do on a SMP.

The emulator is not multithreaded itself. But this doesn't mean that a
SMP system wouldn't speed up emulation: if we get a ported
AMIGA-OS-PPC (SMP capable) then multiple AMIGA-OS tasks, running
the emulation code would execute on several processors in parallel.
It is not the question, if the emulator is multithreading-capable,
it's the question, if AMIGA-OS will be.

The current emulator emulates the whole AMIGA-OS in a 'black box',
so this is a completely different situation to the one I described
above. We don't have AMIGA-OS-PPC tasks running in parallel, because
there is no AMIGA-OS-PPC. We have AMIGA-OS running as *one* PPC-Task
in the multitasking of the PPC kernel, allowing to execute PPC
applications asides the emulated AMIGA-OS.

Aram Iskenderian

unread,
Sep 2, 1998, 3:00:00 AM9/2/98
to
On Wed, 02 Sep 1998 10:14:11 -0700
in article <35ED7C...@htlchur.ch>
sam jordan <jord...@htlchur.ch> wrote:


>The current emulator emulates the whole AMIGA-OS in a 'black box',

The whole Amiga OS?
You guys did a complete "classic" Amiga emulation then?
I thought it was a 68K emulation and the OS runs on top of it, on a
PPC Amiga.

---

Aram Iskenderian.
ar...@ix.netcom.com, ar...@mailexcite.com

---

Ever noticed how fast Windows runs?
Hey, neither did I!


sam jordan

unread,
Sep 2, 1998, 3:00:00 AM9/2/98
to
Aram Iskenderian wrote:
>
> On Wed, 02 Sep 1998 10:14:11 -0700
> in article <35ED7C...@htlchur.ch>
> sam jordan <jord...@htlchur.ch> wrote:
>
> >The current emulator emulates the whole AMIGA-OS in a 'black box',
>
> The whole Amiga OS?
> You guys did a complete "classic" Amiga emulation then?

No. The emulator doesn't emulate the AMIGA hardware.

> I thought it was a 68K emulation and the OS runs on top of it, on a
> PPC Amiga.

It *is* a 68K emulation, just like the Mac emulator.

OK, I will shortly explain this. There are two emulator scenarios:

- blackbox emulation, this means, the 68K-AMIGA-OS is emulated
completely, inclusive interrupts, exceptions, scheduling, really
everything. The emulator starts its work at $f80002, all exec tasks
are running in the same emulator context/task. This emulator task
is a WarpOS task and is running on a modified version of WarpOS,
which is completely 68K- and AMIGA-OS-independent. It cares
for multitasking between PPC-native applications and the emulator
task. Or in other words: The high-level OS AMIGA-OS-68K is running
on the low-level OS WarpOS.

This solution already exists as image file and can easily
be put into a flash ROM, so that new PPC-hardware can directly
boot with the PPC instead of booting with a low-end 68K and then
starting the PPC software.

Due to the 'black box' nature of this concept, the compatibility
to existing 68K software is very high, so that it will be possible
even in 5 years to run old software on a Power-AMIGA, even hardware-
hacking games starting from the bootblock. And it will be even possible
to make software running, which doesn't run on the original 68040,
because the emulator can be patched with command emulations, which
are not 040-compatible, if desired. Or a busy loop can be activated,
if software is running too fast (remember all those games accessing
the disk motor too fast on faster processors?)

- emulator integrated into a PPC-AMIGA-OS (Mac-style solution). Every
task can run either native-code or use the emulator for 68K code.
That's the solution for the future, but now we can't use it, because
there is no PPC-AMIGA-OS. But the H&P emulator will be adapted to
such a solution, as soon as AMIGA-OS gets ported to PPC.

Using this type of emulation, you probably can't use the really
'dirty' software, like hardware-hack games etc. and many other
programs (for example applications, which use supervisor resources,
MMU etc.) probably also will have problems, since the supervisor
stuff will be handled by the PPC-AMIGA-OS in a different way,
because of many differences between 68K-supervisor handling and
PPC-supervisor handling.


By providing the blackbox emulation, we allow hardware manufacturers
to start *now* producing PPC-only hardware. If we only had developed
the emulator with the integration solution in mind, all HW
manufacturers would have to wait, until the AMIGA-OS-PPC would be
ready, and again, much time would be lost and we would be stuck with
the dual-processor boards (and we could never use L2 caches because
of the context switch problem).

So we see the future in the development of a ported AMIGA-OS, in
the integration of the emulator into this new OS. Additionally
the blackbox-solution will also be available, so that owners
of a PowerAMIGA can decide to use the modern PPC-AMIGA-OS
with integrated emulator or use the 'blackbox emulation' to
launch the old 68K-based AMIGA-OS, to achieve even higher
compatility to old software than with the integration solution.
And even with the blackbox-solution, PPC software can be used,
which is available today. I could image a kind of 'boot menu'
where the type of emulation could be selected.

Steffen Haeuser

unread,
Sep 2, 1998, 3:00:00 AM9/2/98
to

ar...@ix.netcom.com wrote :

Hi!

>>The current emulator emulates the whole AMIGA-OS in a 'black box',

ar> The whole Amiga OS?
ar> You guys did a complete "classic" Amiga emulation then?

Well, if you emulate the 68k, naturally the 68k OS "AmigaOS" will run on it
(as it is a 68k application). This emulator is NOT a "Custom-Chip-Emulator" or
such like UAE. It emulates the 68k of the Amiga. And the AmigaOS runs then in
Emulation. Of course this is only the first step which has to be done... for
the future the market needs a PPC Port of the OS... with the Emulation running
- so that the system works already - this could be done even "Step by Step".

Steffen Haeuser

Marius Lichte

unread,
Sep 2, 1998, 3:00:00 AM9/2/98
to
jord...@htlchur.ch (sam jordan) wrote :

> > They made it - Haage-Partner releases the beta version of 68k

> > emulation for PPC cards. All I want to know now is: how good is

> > it. What 68k does it emulate exactly? A plain 68000 or something

> > closer to 68040? Is the emulated 68k better or worse than regular
>

> 68040/FPU/MMU (MMU not completely finished yet, but address

> translation works)


>
> > 040/25? Does the emulator emulates Data and Instruction CPU caches?
>

> Speed is about equal for 604E based systems.
>

> Instruction cache is not emulated (why should I?), it's always on
> (although the tools will tell you that it's off, if you try to
> switch IC off). Data cache is emulated using the PPC MMU.
>
> > Does it emulate 060 superscalar mode?
>
> No, because it emulates a 68040. Anyway, it would not make sense
> to emulate superscalar mode, the emulator is a software, not
> a processor :)

Ok Sam, think one step beyond:
Is it possible to replace the P5 Bootstrap Flashroms with your
own PPC Startup-code and additionally replace the 68k Kickstart
Roms on the Motherboard with eproms containing a plain PPC
Bootup code, thus running the PPC Board WITHOUT an 68k CPU ?

Im not talking about an PPC-OS in ROM, just a bootstrap loader
for WarpUp. Software can be done later.

Regards,
Marius

--

Timo K Suoranta

unread,
Sep 3, 1998, 3:00:00 AM9/3/98
to
sam jordan <jord...@htlchur.ch> wrote:

> hacking games starting from the bootblock. And it will be even possible
> to make software running, which doesn't run on the original 68040,
> because the emulator can be patched with command emulations, which

I hope this 68k/fpu emulation is not related to gcc/egcs or uae.
Gcc/egcs 68k floating point machine descriptor is broken. Uae's
fpu emulation is broken in similar way.

> are not 040-compatible, if desired. Or a busy loop can be activated,

Busy loop? That's what people used in the 80's. You should know better
synchronization mechanisms.


--


Timo Suoranta ·· tksu...@cc.helsinki.fi ·· http://www.helsinki.fi/~tksuoran/


sam jordan

unread,
Sep 3, 1998, 3:00:00 AM9/3/98
to
Marius Lichte wrote:

> > No, because it emulates a 68040. Anyway, it would not make sense
> > to emulate superscalar mode, the emulator is a software, not
> > a processor :)
>
> Ok Sam, think one step beyond:
> Is it possible to replace the P5 Bootstrap Flashroms with your
> own PPC Startup-code and additionally replace the 68k Kickstart
> Roms on the Motherboard with eproms containing a plain PPC
> Bootup code, thus running the PPC Board WITHOUT an 68k CPU ?

The 68K kickstart is still needed, so you can't replace it. We
still need the 68K-AMIGA-OS :)

Theoretically it would be maybe possible to put our soft into
their flash. Currently it fits into 256K, but later it probably
won't (so the question is also, how big the flash is). But the
next question is: are the P5 boards able to boot directly with
the PPC? I don't know. If no, than it would not make sense, since
the 68K would be needed for startup and so the soft could be loaded
into RAM using the 68K, just like it's done now.

sam jordan

unread,
Sep 3, 1998, 3:00:00 AM9/3/98
to
Timo K Suoranta wrote:

> > hacking games starting from the bootblock. And it will be even possible
> > to make software running, which doesn't run on the original 68040,
> > because the emulator can be patched with command emulations, which
>
> I hope this 68k/fpu emulation is not related to gcc/egcs or uae.
> Gcc/egcs 68k floating point machine descriptor is broken. Uae's
> fpu emulation is broken in similar way.

I wrote all FPU040 command emulations myself, in ASM.

The 6888x commands are currently handled by the 68040.library (not
tested yet). Maybe these commands will be added later to the emulator,
if enough applications benefit from it.

> > are not 040-compatible, if desired. Or a busy loop can be activated,
>
> Busy loop? That's what people used in the 80's. You should know better
> synchronization mechanisms.

Uff..., it seems that I have to explain this in more detail for you.

The emulator consists of a core loop, which is executed once for each
68K command. Now, assume you have an old-style game, which is running
too fast (and such a game is not multitasking-capable probably in 99
percent).

Now, let's look at the possibilites to make the emulator running at
lower speed. Please remember, that the whole AMIGA-OS is running under
this emulator, this is a very special situation.

a) busy loop at the beggining of the loop to enlarge the execution time
for each 68K command.
b) calling WarpOS/Wait() at the beginnig of the loop, to enter waiting
state with respect to PPC multitasking (and please tell me, which PPC
tasks should execute aside such a mentioned game). So this function
would be called several million times per second, so maybe you have
enough fun to calculate the total overhead of all this (oh, I forgot,
there are also several millions of PPC task switches around...)

We are talking about a loop, which takes a few '68K-cycles' in average!
And the goal is to increase this number of cycles for special
applications
like old games, and if you don't need it you won't activate it.

So usually 'busy loops' are avoided by calling exec/Wait() or something
similar. But I hope that you understand that this doesn't help at all
for slowing down the emulator itself, as the emulator is emulating the
OS providing exec/Wait() :)


You can expect that I know the advantages and disadvantages of busy
loops.


And you can also expect that this emulation situation is something very
special, so that you cannot simply carry your known concepts to this
new situation without having much experience with it. You have to start
thinking in a different way than before.

Janne P R Jalkanen

unread,
Sep 3, 1998, 3:00:00 AM9/3/98
to
sam jordan <jord...@htlchur.ch> writes:

> By providing the blackbox emulation, we allow hardware manufacturers
> to start *now* producing PPC-only hardware. If we only had developed
> the emulator with the integration solution in mind, all HW
> manufacturers would have to wait, until the AMIGA-OS-PPC would be
> ready, and again, much time would be lost and we would be stuck with
> the dual-processor boards (and we could never use L2 caches because
> of the context switch problem).

Does this system allow for gradual PPCization of the OS? Like do you
trap calls to OpenLibrary and allow old 68k programs to use PPC-native
routines? Or is the increased speed allowed only to full PPC-native
programs?

How about if a PPC program wants to use an old 68k library?

--
Janne Jalkanen //!
Janne.J...@iki.fi // ! Faith manages.
<*> \X/ !

Wojciech Orlinski

unread,
Sep 3, 1998, 3:00:00 AM9/3/98
to
In article <35EEEC...@htlchur.ch>,
sam jordan <jord...@htlchur.ch> wrote:

> The 68K kickstart is still needed, so you can't replace it. We
> still need the 68K-AMIGA-OS :)
>
> Theoretically it would be maybe possible to put our soft into
> their flash. Currently it fits into 256K, but later it probably
> won't (so the question is also, how big the flash is). But the
> next question is: are the P5 boards able to boot directly with
> the PPC? I don't know. If no, than it would not make sense, since
> the 68K would be needed for startup and so the soft could be loaded
> into RAM using the 68K, just like it's done now.

I have very little knowledge of Amiga architecture, so PLEASE don't
laugh on my question. I'm still anxious to hear if the Haage-Partner
emulation allows to manufacture single-CPU turbo boards. After all,
you'll find a 68k in ANY Amiga - be it A4000 or A1200. So technically
it could be possible for the lame old 68EC20 in A1200 to boot up
system and then switch into PPC mode?

Anyway, what does this 020 doing in my Amy right now, when it runs
a 040 turbo board? Which CPU is responsible for, say, displaying
the boot menu after the twin-mouse-button-pressing?

Steffen Haeuser

unread,
Sep 3, 1998, 3:00:00 AM9/3/98
to

jalk...@ametisti.hut.fi wrote :

Hi!

>> By providing the blackbox emulation, we allow hardware manufacturers
>> to start *now* producing PPC-only hardware. If we only had developed
>> the emulator with the integration solution in mind, all HW
>> manufacturers would have to wait, until the AMIGA-OS-PPC would be
>> ready, and again, much time would be lost and we would be stuck with
>> the dual-processor boards (and we could never use L2 caches because
>> of the context switch problem).

ja> Does this system allow for gradual PPCization of the OS? Like do you
ja> trap calls to OpenLibrary and allow old 68k programs to use PPC-native
ja> routines? Or is the increased speed allowed only to full PPC-native
ja> programs?

As a very simple method there would be (as an example, for intuition.library):

- Code a intuitionPPC.library which uses exactly the same functions like
intuition.library. This library would then be a WarpUP Shared Library
(using r3 as libbase, and registers from there on as parameters)
- PPC programs could now call the intuitionPPC.library
- 68k libs could then be done as stubs, that jump into intuitionPPC.library.
As intuition.library is ROM-based this would have to be done with System
Patches, like cybergraphics does with graphics.library...

Old libs have to exist IMHO at least as stubs, as different parameters are
used...

For example:

AllocVec: d0,d1, libbase in a6
AllocVecPPC: r4,r5, r6, libbase in r3

But AllocVec could then be defined as a Emulation call that just gives through
the values to the PPC function...

Of course there is the question, if this is worth it, or if it would slow down
the old programs to use those stubs. The different design would be to use both
sets of libraries parallel, and use the 68k versions only for old programs...

ja> How about if a PPC program wants to use an old 68k library?

Where should there be a problem about this ? The old libs are emulated...

Steffen Haeuser

Timo K Suoranta

unread,
Sep 3, 1998, 3:00:00 AM9/3/98
to
sam jordan <jord...@htlchur.ch> wrote:

> Now, let's look at the possibilites to make the emulator running at

...


> a) busy loop at the beggining of the loop to enlarge the execution time
> for each 68K command.
> b) calling WarpOS/Wait() at the beginnig of the loop, to enter waiting

...

c) interrupt - How about that?

Staf Verhaegen

unread,
Sep 4, 1998, 3:00:00 AM9/4/98
to
sam jordan wrote:
>
> Timo K Suoranta wrote:
>
> > > hacking games starting from the bootblock. And it will be even possible
> > > to make software running, which doesn't run on the original 68040,
> > > because the emulator can be patched with command emulations, which
> >
> > I hope this 68k/fpu emulation is not related to gcc/egcs or uae.
> > Gcc/egcs 68k floating point machine descriptor is broken. Uae's
> > fpu emulation is broken in similar way.
>
> I wrote all FPU040 command emulations myself, in ASM.
>
> The 6888x commands are currently handled by the 68040.library (not
> tested yet). Maybe these commands will be added later to the emulator,
> if enough applications benefit from it.
>
> > > are not 040-compatible, if desired. Or a busy loop can be activated,
> >
> > Busy loop? That's what people used in the 80's. You should know better
> > synchronization mechanisms.
>
> Uff..., it seems that I have to explain this in more detail for you.
>
> The emulator consists of a core loop, which is executed once for each
> 68K command. Now, assume you have an old-style game, which is running
> too fast (and such a game is not multitasking-capable probably in 99
> percent).
>
> Now, let's look at the possibilites to make the emulator running at
> lower speed. Please remember, that the whole AMIGA-OS is running under
> this emulator, this is a very special situation.
>
> a) busy loop at the beggining of the loop to enlarge the execution time
> for each 68K command.
> b) calling WarpOS/Wait() at the beginnig of the loop, to enter waiting
> state with respect to PPC multitasking (and please tell me, which PPC
> tasks should execute aside such a mentioned game). So this function
> would be called several million times per second, so maybe you have
> enough fun to calculate the total overhead of all this (oh, I forgot,
> there are also several millions of PPC task switches around...)


Or you could simulate the processor at full speed for the period of one screen
refresh and wait the total amount you have computed the results too fast. Much
less task switches, still able to multitask (this means also able to pause the
emulator, reorganise a database while running this game, ...).

>
> bye
> --
> Sam Jordan
> Member of Haage&Partner PowerPC Development Team
>
> s.jo...@haage-partner.com (business related)
> sam_j...@bluewin.ch (private related)

--
------------------------------------------------------------------------
Staf Verhaegen
IMEC vzw. - ASP/TCAD tel: (32)-(0)16/28 12 38
Kapeldreef 75 fax: (32)-(0)16/28 12 14
3001 Leuven (Belgium) email: verh...@imec.be
------------------------------------------------------------------------
For every tool there are at least 2 uses: the one it was designed for
and the other for which it wasn't.

ark

unread,
Sep 4, 1998, 3:00:00 AM9/4/98
to
Steffen Haeuser (mag...@birdland.es.bawue.de) wrote:

: ja> Does this system allow for gradual PPCization of the OS? Like do you
[...]
: - Code a intuitionPPC.library which uses exactly the same functions like


: intuition.library. This library would then be a WarpUP Shared Library
: (using r3 as libbase, and registers from there on as parameters)

Or code a PPC-Kernel stub (speaking about WarpOS' planned (?) ppc.library
emulation here ;) that does not use an 68k mirror task to translate library
calls from PPC to 68k library calls but instead directly calls the PPC
native library...

sam jordan

unread,
Sep 4, 1998, 3:00:00 AM9/4/98
to
Staf Verhaegen wrote:

> Or you could simulate the processor at full speed for the period of one screen
> refresh and wait the total amount you have computed the results too fast. Much
> less task switches, still able to multitask (this means also able to pause the
> emulator, reorganise a database while running this game, ...).

The emulator runs *below* the OS, it really emulates 68K command by 68K
command
it doesn't know anything about AMIGA-OS, it doesn't know anything about
screen
refreshs etc. it's really very low level, I simply can't perform high
level
functions on such a low layer.

I don't see any sense anyway, since we're only talking about old
games running too fast, where no PPC multitasking is required at all.

sam jordan

unread,
Sep 4, 1998, 3:00:00 AM9/4/98
to
Wojciech Orlinski wrote:

> I have very little knowledge of Amiga architecture, so PLEASE don't
> laugh on my question. I'm still anxious to hear if the Haage-Partner
> emulation allows to manufacture single-CPU turbo boards. After all,
> you'll find a 68k in ANY Amiga - be it A4000 or A1200. So technically
> it could be possible for the lame old 68EC20 in A1200 to boot up
> system and then switch into PPC mode?

Yes. But it would complicate the board design very much und thus
increase cost even more, if you create new boards with 68K and PPC.

> Anyway, what does this 020 doing in my Amy right now, when it runs
> a 040 turbo board? Which CPU is responsible for, say, displaying
> the boot menu after the twin-mouse-button-pressing?

If you are running the emulator on a dual processor board, then the
PPC does everything. The 68K currently only provides the AMIGA
interrupts
to the PPC, since I don't know how the PPC itself could do it.

sam jordan

unread,
Sep 4, 1998, 3:00:00 AM9/4/98
to
Janne P R Jalkanen wrote:

> > By providing the blackbox emulation, we allow hardware manufacturers
> > to start *now* producing PPC-only hardware. If we only had developed
> > the emulator with the integration solution in mind, all HW
> > manufacturers would have to wait, until the AMIGA-OS-PPC would be
> > ready, and again, much time would be lost and we would be stuck with
> > the dual-processor boards (and we could never use L2 caches because
> > of the context switch problem).
>

> Does this system allow for gradual PPCization of the OS? Like do you

With some restrictions, yes (since the AMIGA-OS kernel would still be
68K).
But the integration solution would be much better suitable for this.

> trap calls to OpenLibrary and allow old 68k programs to use PPC-native

> routines? Or is the increased speed allowed only to full PPC-native

> programs?

This is a possibility which might indeed be used, if no integration
solution could be done for some amount of time (if AMIGA-OS does't
get ported soon).

> How about if a PPC program wants to use an old 68k library?

We didn't specifiy this up to now, but I think it should be possible
to perform such switches.

ark

unread,
Sep 4, 1998, 3:00:00 AM9/4/98
to
Keith Blakemore-Noble (ke...@amiga.u-net.com) wrote:

: I wasn't replying to that sub-thread though Joe (personally I woudl say that
: Cloanto PP does use ppc.library, in addition to its own blit.library, but I

There was a "personal_ppc_blit.library" (as replacement for other
"personal_#?_blit.library's) and nothing more (or less).

ark

unread,
Sep 4, 1998, 3:00:00 AM9/4/98
to
Johan Eriksson (joh...@sara.lysator.liu.se) wrote:

: Ok, so the ppc.library betas were available to the public since V45. I'd


: better point that out before someone else does.

The (first) PPaint problem happened with late V44 (inofficial beta) IIRC.

Eelke Blok

unread,
Sep 4, 1998, 3:00:00 AM9/4/98
to
Wojciech Orlinski wrote:
> Anyway, what does this 020 doing in my Amy right now, when it runs
> a 040 turbo board? Which CPU is responsible for, say, displaying
> the boot menu after the twin-mouse-button-pressing?
>
Since I think Sam mis-interpreted your question, I'll answer it. To my
knowledge, the accelerator-CPU takes is there from the start, so it also
is the CPU handling the boot-menu. I don't think it would be very easy
to switch CPU's somewhere in the booting-process.
The computers "standard" CPU becomes idle the moment you fit an
accelerator.

Cheers,

Eelke
--
Eelke Blok, student Electrical Engineering, University of Twente
http://home.student.utwente.nl/e.blok
Amiga-page: http://home.student.utwente.nl/e.blok/amiga
"Our Lady of Blessed Acceleration, don't fail us now!"
-- Elwood Blues

sam jordan

unread,
Sep 4, 1998, 3:00:00 AM9/4/98
to
Timo K Suoranta wrote:

> > Now, let's look at the possibilites to make the emulator running at

> ...


> > a) busy loop at the beggining of the loop to enlarge the execution time
> > for each 68K command.
> > b) calling WarpOS/Wait() at the beginnig of the loop, to enter waiting

> ...
>
> c) interrupt - How about that?

Theoretically it would be possible to install such kind of 'timer
interrupt'
which would put the emulator then into powersave mode, but just think
about
how much work would be necessary for some special case, which is not
important
for general use. And I really don't want to implement more code into the
inner loop to slow down the general emulator performance just for these
theoretical cases.

And anyway, like I'm writing in all these mails: I don't believe that
this
discussion about 'emulator brakedown' is the really most senseful one (I
wonder, why no discussion is done about all the other text), since
it is not really an important feature. We are talking about making very
old
games running on the emulator, which don't work with too much speed, and
since neither 68K tasks nor PPC tasks are running in parallel, there is
absolutely no sense to spend much time for all this. If you only have
one
task and would like to slow it down, then the best (and easiest) method
is to let it run in a small loop for every iteration.

sam jordan

unread,
Sep 4, 1998, 3:00:00 AM9/4/98
to
Steffen Haeuser wrote:

> ja> How about if a PPC program wants to use an old 68k library?
>
> Where should there be a problem about this ? The old libs are emulated...

It is a problem, since PPC programs don't execute in a exec-task-context
and I believe that many AMIGA-shared libraries would not be happy, if
a WarpOS tasks jumps directly in there (with the emulator) with other
task structure and scheduled by another scheduler (WarpOS) and also
think
about all the synchonisation problems (Disable,Forbid etc.) etc.
Therefore
switches between PPC context and 68K context are still necessary, until
the
emulator is used in the integration solution, together with a ported
AMIGA-OS.

The blackbox solution is really an intermediate solution, which should
be a bridge between the past and the future. In the integration
solution,
many things would be handled differently than with the blackbox
solution.

Ian Gledhill

unread,
Sep 4, 1998, 3:00:00 AM9/4/98
to
Wojciech Orlinski wrote:
>
> Anyway, what does this 020 doing in my Amy right now, when it runs
> a 040 turbo board? Which CPU is responsible for, say, displaying
> the boot menu after the twin-mouse-button-pressing?

A1200s do indeed keep the 020, but the big box Amigas have CPU cards:
these are taken out when you fit the PPC. I have an A4000/030 CPU card
lying around in a bag at home, not being used.

--
Ian Gledhill
Ia...@amiganet.org im...@aber.ac.uk
Amiga Doom Editor Utilities - http://www.aber.ac.uk/~img4

Eelke Blok

unread,
Sep 4, 1998, 3:00:00 AM9/4/98
to
Ian Gledhill wrote:
>
> Wojciech Orlinski wrote:
> >
> > Anyway, what does this 020 doing in my Amy right now, when it runs
> > a 040 turbo board? Which CPU is responsible for, say, displaying
> > the boot menu after the twin-mouse-button-pressing?
>
> A1200s do indeed keep the 020, but the big box Amigas have CPU cards:
> these are taken out when you fit the PPC. I have an A4000/030 CPU card
> lying around in a bag at home, not being used.
>
Not entirely true. The A3000 and early A4000's do use that (very
elegant) solution, but A2000's and newer A4000's have a CPU on the
MB, just like the A1200 has. I'm not exactly sure which A4000's have the
CPU on the MB, but I do believe that at one point at least both the 030
and 040 desktop models had that.

Cheers,

Eelke


> --
> Ian Gledhill
> Ia...@amiganet.org im...@aber.ac.uk
> Amiga Doom Editor Utilities - http://www.aber.ac.uk/~img4

--

Steffen Haeuser

unread,
Sep 4, 1998, 3:00:00 AM9/4/98
to

klei...@studm.hrz.uni-siegen.de wrote :

Hi!

kl> Or code a PPC-Kernel stub (speaking about WarpOS' planned (?) ppc.library
kl> emulation here ;) that does not use an 68k mirror task to translate libra
Hmmm... what should that have to do with ppc.library Emulation ? I thought we
talked about Integration of a PPC Native OS and 68k, not about integration of
WarpUP and ppc.library...

kl> calls from PPC to 68k library calls but instead directly calls the PPC
kl> native library...

I think there would still be a problem of how a function that wants its
parameters in 68k registers... some mechanism probably would be needed to
handle this... but i have to admit, i don't know exactly how the Emulator
would deal with this, this is probably up to Sam to answer...

Steffen

ark

unread,
Sep 4, 1998, 3:00:00 AM9/4/98
to
Steffen Haeuser (mag...@birdland.es.bawue.de) wrote:

: Hmmm... what should that have to do with ppc.library Emulation ? I thought we

: talked about Integration of a PPC Native OS and 68k, not about integration of
: WarpUP and ppc.library...

The relation is obvious.

: I think there would still be a problem of how a function that wants its

: parameters in 68k registers... some mechanism probably would be needed to
: handle this... but i have to admit, i don't know exactly how the Emulator
: would deal with this, this is probably up to Sam to answer...

It's all passed in a clearly documented structure. No problem to
write a wrapper (the problems will appear elsewhere, though).

Janne P R Jalkanen

unread,
Sep 4, 1998, 3:00:00 AM9/4/98
to
sam jordan <jord...@htlchur.ch> writes:

> > ja> How about if a PPC program wants to use an old 68k library?
> >
> > Where should there be a problem about this ? The old libs are emulated...
>
> It is a problem, since PPC programs don't execute in a exec-task-context
> and I believe that many AMIGA-shared libraries would not be happy, if

Figured as much.

> Therefore
> switches between PPC context and 68K context are still necessary, until
> the
> emulator is used in the integration solution, together with a ported
> AMIGA-OS.

Just out of curiosity: how does the PPC recognize the 68k code, or
does it have to be explicitly stated (using something like Call68k())?
Does the method cause much overhead?

If I understood Steffen's explanation correctly, the old 68k program
would benefit from PPC speed by calling a 68k library, which in turn
would call the PPC code. How much overhead do the context switches
take in this case? Won't it cause performance degradation, if Exec
has to be emulated - GetMsg(), PutMsg() are very fast on 68k.

> Sam Jordan

Mike

unread,
Sep 4, 1998, 3:00:00 AM9/4/98
to
>
>
> klei...@studm.hrz.uni-siegen.de wrote :
>
> Hi!
>
> kl> Or code a PPC-Kernel stub (speaking about WarpOS' planned (?) ppc.library
> kl> emulation here ;) that does not use an 68k mirror task to translate libra
> Hmmm... what should that have to do with ppc.library Emulation ? I thought we
> talked about Integration of a PPC Native OS and 68k, not about integration of
> WarpUP and ppc.library...
>
> kl> calls from PPC to 68k library calls but instead directly calls the PPC
> kl> native library...

>
> I think there would still be a problem of how a function that wants its
> parameters in 68k registers... some mechanism probably would be needed to
> handle this... but i have to admit, i don't know exactly how the Emulator
> would deal with this, this is probably up to Sam to answer...
>
> Steffen

Seems like it would be possible to provide seperate library bases for
different processors. The tasks on the non-native processor would get
a psuedo-base that would provide a jumptable to stub code that would
swap registers as needed, load the real library base, then change
processor context or switch processors altogether, and call the original
function.

These psuedo-bases, jumptables, and stub code could be constructed
by MakeLibrary() and OpenLibrary(), (or new functions) so that the
library itself need not know of other processors.

This would allow 680x0 programs to call PPC libs and vise-versa without
the task or library even knowing.


Steffen Haeuser

unread,
Sep 4, 1998, 3:00:00 AM9/4/98
to

klei...@studm.hrz.uni-siegen.de wrote :

Hi!

kl> The relation is obvious.

Still, the discussion was about integration of 68k Shared Libraries and PPC
Shared Libraries into one OS, not about ppc.library... PPC Shared Libraries
would be used through WarpUP Shared Libs, and 68k Shared Libs would be - just
68k Shared Libs. ppc.library has nothing to do with this.

Steffen Haeuser

Steffen Haeuser

unread,
Sep 4, 1998, 3:00:00 AM9/4/98
to

jalk...@ametisti.hut.fi wrote :

Hi!

ja> If I understood Steffen's explanation correctly, the old 68k program
ja> would benefit from PPC speed by calling a 68k library, which in turn

Well, this was just an IDEA. I don't know what Sam is planning... but i see
mainly these two methods:

1) "68k" calls PPC, and PPC contains the real code (68k in "", as it is
only emulated)
2) both exist parallel (which makes the OS big, of course...), emulated
68k programs call emulated 68k functions, PPC programs call the PPC
functions directly, and there exists a ...PPC.library for each
...library

Anyone having different ideas ?

ja> would call the PPC code. How much overhead do the context switches
ja> take in this case? Won't it cause performance degradation, if Exec
ja> has to be emulated - GetMsg(), PutMsg() are very fast on 68k.

Well, "contextswitches" are faster in Emulation, as no Cache-Clears are needed
like with the real contextswitches... surely still some overhead, but faster...

I am not sure, though, if it is not better to leave some functions exist in
both version (68k version which will be emulated, and PPC version for PPC
Executables...). Of course Emulation is also overhead...

Steffen Haeuser

ark

unread,
Sep 5, 1998, 3:00:00 AM9/5/98
to
Steffen Haeuser (mag...@birdland.es.bawue.de) wrote:

: kl> The relation is obvious.


: Still, the discussion was about integration of 68k Shared Libraries and PPC
: Shared Libraries into one OS, not about ppc.library... PPC Shared Libraries
: would be used through WarpUP Shared Libs, and 68k Shared Libs would be - just
: 68k Shared Libs. ppc.library has nothing to do with this.

ppc.library calls 68k libraries/code through PPCCallOS() or PPCCall68k().

So, if you turn those into no-ops (replace calls to emulated 68k code
by calls to native PPC code) you could avoid emulation here too - and
instead jump into the same PPC-native libraries as you've suggested them.

If WOS/PPC get merged, this is an issue.

Steffen Haeuser

unread,
Sep 5, 1998, 3:00:00 AM9/5/98
to

klei...@studm.hrz.uni-siegen.de wrote :

Hi!

kl> ppc.library calls 68k libraries/code through PPCCallOS() or PPCCall68k().

kl> So, if you turn those into no-ops (replace calls to emulated 68k code
kl> by calls to native PPC code) you could avoid emulation here too - and
kl> instead jump into the same PPC-native libraries as you've suggested them.

kl> If WOS/PPC get merged, this is an issue.

Well, why use the ppc.library API ? Why not simply use Run68k() of WarpUP
which does the same like PPCCallOS() for ppc.library ?

Actually, this is like it works, with Run68k...

I don't see any sense to take an API-Call of ppc.library into the standard if
it also exists in WarpUP in a similar way...

Also, i doubt you COULD merge it just like that... of course you could do an
API Emulation to support both functions... (mostly some parameter changes,
most likely...). But internally the two kernels work VERY different.

Steffen Haeuser

Steffen Haeuser

unread,
Sep 5, 1998, 3:00:00 AM9/5/98
to

mri...@gte.net wrote :

Hi!

mr> Seems like it would be possible to provide seperate library bases for
mr> different processors. The tasks on the non-native processor would get
mr> a psuedo-base that would provide a jumptable to stub code that would
mr> swap registers as needed, load the real library base, then change
mr> processor context or switch processors altogether, and call the original
mr> function.

Okay... Run68k()/RunPPC() are overtaking this probably...

Steffen

Janne P R Jalkanen

unread,
Sep 6, 1998, 3:00:00 AM9/6/98
to
sam jordan <jord...@htlchur.ch> writes:

> > trap calls to OpenLibrary and allow old 68k programs to use PPC-native
> > routines? Or is the increased speed allowed only to full PPC-native
> > programs?
>
> This is a possibility which might indeed be used, if no integration
> solution could be done for some amount of time (if AMIGA-OS does't
> get ported soon).

Not to mention third party authors, who might want to release PPC
versions of their software, but are unable to provide all parts of the
software in PPC code (due to lots of assembly, for example.)

> > How about if a PPC program wants to use an old 68k library?
>

> We didn't specifiy this up to now, but I think it should be possible
> to perform such switches.

Some programs use third party libraries, for which a PPC version might
not be available. It would speed up porting applications, if you can
just compile your own program to PPC code without having to worry
about rewriting the entire GUI, for example, just because it uses an
old GUI library which is not available for PPC.

What would the penalty be in mixing 68k and PPC code within your
emulator? Can we expect faster context-switches than the 0.5 ms? I'd
guess so, since you only have one CPU to worry about ;-)

> Sam Jordan

Thanks for hanging around here, answering our questions!

ark

unread,
Sep 6, 1998, 3:00:00 AM9/6/98
to
Steffen Haeuser (mag...@birdland.es.bawue.de) wrote:

: Well, why use the ppc.library API ? Why not simply use Run68k() of WarpUP

: which does the same like PPCCallOS() for ppc.library ?

The answer basically is the same as for the reason why there'd be
a need for a ppc-lib emulation.

: I don't see any sense to take an API-Call of ppc.library into the standard if

: it also exists in WarpUP in a similar way...

Well, there still only are 2 WOS compilers. And we're not only talking
about 'open source' freeware programs here, which easily might be
recompiled.

: Also, i doubt you COULD merge it just like that... of course you could do an

: API Emulation to support both functions... (mostly some parameter changes,
: most likely...). But internally the two kernels work VERY different.

It's a simple matter of logics: if you get the ppc-lib emulation for WOS
done, you could get that API translation done as well. Otherwise neither
one.

Take a look into the description of PPCCallOS() - its parameter
struct does contain a pointer to the library base, the function
parameter registers (a0..a7, d0..d7) are listed as well. You could
easily figure out e.g. a call to "graphics.library" and translate
it to a call to your suggested "graphicsPPC.library".

If the calling convention is defined in a consistent way, it might
even be possible to implement it as a basic automatism instead
of having to do this for each library separately.

Steffen Haeuser

unread,
Sep 6, 1998, 3:00:00 AM9/6/98
to

klei...@studm.hrz.uni-siegen.de wrote :

Hi!

kl> Steffen Haeuser (mag...@birdland.es.bawue.de) wrote:

kl> : Well, why use the ppc.library API ? Why not simply use Run68k() of WarpUP
kl> : which does the same like PPCCallOS() for ppc.library ?

kl> The answer basically is the same as for the reason why there'd be
kl> a need for a ppc-lib emulation.

Yeah, but then PPCCallOS() would belong to the Emulation, not to the Kernel...

kl> It's a simple matter of logics: if you get the ppc-lib emulation for WOS
kl> done, you could get that API translation done as well. Otherwise neither
kl> one.

Sure.

kl> Take a look into the description of PPCCallOS() - its parameter
kl> struct does contain a pointer to the library base, the function
kl> parameter registers (a0..a7, d0..d7) are listed as well. You could
kl> easily figure out e.g. a call to "graphics.library" and translate
kl> it to a call to your suggested "graphicsPPC.library".

Yeah, but it would make more sense to use the syntax of Run68k(), as WarpUP is
the kernel which will be used... why use a function with a similar function of
a different API ? There is no sense in it... It WOULD make sense if there is a
function in ppc.library, which is NOT contained in WarpUP, to overtake them
into the new Kernel... but as WarpUP will be the Kernel to be used, it's
functions should be used primarily... everything else belongs to the
Emulation-Lib, nowhere else...

Take a look at the description of Run68k... its parameter structure contains a
pointer to the library base (or to the function, in case of a
non-library-function), the function parameter registers (a0..a6, d0..d7,
fp0..fp7), the Library Offset, if the function should be run synchrone
(normally) or asynchrone, the stackpointer, the stackarea to be transferred.

One argument more for this function to be used: It handles stack-frames
conforming to the PowerOpen Standard. As ppc.library does not use PowerOpen,
it uses the System 4 ABI... so if this function would be used, some Emulation
code would have to be used - i guess - which would create overhead.

kl> If the calling convention is defined in a consistent way, it might
kl> even be possible to implement it as a basic automatism instead
kl> of having to do this for each library separately.

And surely this will be done like that. But not with the ppc.library API. What
is the use of this thread ? "And i want ppc.library API anyways ?" :) Can you
tell ONE reason why a function in the WarpUP API should be replaced by a
effect-similar function of ppc.library ? I see none.

Steffen

Steffen Haeuser

unread,
Sep 6, 1998, 3:00:00 AM9/6/98
to

gpe...@wt.net wrote :

Hi!

gp> For those of us not enlightened in this matter, can you tell us
gp> exactly how PPC would be included in or incorporated into the AmigaOS
gp> in an upgrade?

Well, as i am not an official person and also not integrated into the OS
developpement, i can't tell you "this is how it is done, and nothing else". I
can only make my guesses...

gp> My understanding, which is obviously not correct, is that calls and
gp> IO's would have to be done thru the OS to the PPC card to become
gp> effective? Isn't offloading IO and things like that what could add
gp> speed and effectiveness to the PPC environment when laid on or in
gp> AmigaOS? So that, until this is done, the only real use of PPC is for
gp> specific programs written to jump to the PPC card?

gp> Help!!! :)

Well, there are several problematic areas (note that this is no official
information or anything, it is only some guesses by myselves how i would try
it...)

1. Calls to the OS by PPC programs
2. Calls to the OS by old 68k programs

As to 1. there is the need of new PPC-Native libraries (could be implemented
through the WarpUP-PPC-Libraries for example). These libraries should not
(like currently) use the 68k-Libs for I/O for example, but implement
everything "from the start", so that the PPC directly accesses the I/O (means:
no contextswitches).

As to 2. there are several option. One idea was having a PPC-Library, and a
68k-library, so that PPC-programs call the PPC-lib, 68k-programs call the
68k-lib (which in turn is emulated by the PPC). The second idea was that the
68k-lib is only a stub (executed by the Emulator) which then calls
the PPC-lib. Bad about it, is that a sort of a switch would have to be
executed. Good, that the function once it started, has not to be emulated.

There are several open issues as to the implementation (of course it is
possible, that the involved people already made their mind up of how to solve
this all... i just don't know...):

- Having all libraries exist twice is somehow not ideal ?
- Can we somehow make the choice between 68k/PPC library (at least
semi-) automatic ?

Steffen Haeuser


ark

unread,
Sep 6, 1998, 3:00:00 AM9/6/98
to
Steffen Haeuser (mag...@birdland.es.bawue.de) wrote:

: kl> The answer basically is the same as for the reason why there'd be


: kl> a need for a ppc-lib emulation.
: Yeah, but then PPCCallOS() would belong to the Emulation, not to the Kernel...

No.

: Yeah, but it would make more sense to use the syntax of Run68k(), as WarpUP is

You don't understand. A *compiled* PPC-lib based program does contain
calls to PPCCallOS(). The function itself, however, is dynamically
linked into the program when the ELF object gets loaded (however,
even if it would work differently, there wouldn't be a problem in
replacing a kernel function if the whole kernel is just an emulation/
replacement, provided by WarpUP, anyway...)

If you want to keep ELF programs running under the WarpUP emulation
of ppc-lib even for the future (and not just as an alibi feature)
it's an issue to minimize 68k emulation here as well - the same
way as you suggested for WOS based programs... (this isn't even
remotely related to further development of the ppc-lib kernel).

: the kernel which will be used... why use a function with a similar function of

: a different API ? There is no sense in it... It WOULD make sense if there is a

Be careful with "no sense". Maybe you just didn't notice/understand
(or didn't want to ;-)

: Take a look at the description of Run68k... its parameter structure contains a

: pointer to the library base (or to the function, in case of a
: non-library-function), the function parameter registers (a0..a6, d0..d7,
: fp0..fp7), the Library Offset, if the function should be run synchrone
: (normally) or asynchrone, the stackpointer, the stackarea to be transferred.

Well, nice. I don't care, whether PPCCallOS() calls Run68k() or something
else. However, I was talking about replacing calls to 68k code with
calls to native PPC code - this obviously isn't related to Run68k() anymore.

And I wasn't talking about WarpUP but about letting the possibly integrated
ppc-lib emulation of WarpUP participate in the possible creation
of PPC native replacment libraries for 68k libs.

: And surely this will be done like that. But not with the ppc.library API. What

: is the use of this thread ? "And i want ppc.library API anyways ?" :) Can you
: tell ONE reason why a function in the WarpUP API should be replaced by a
: effect-similar function of ppc.library ? I see none.

Steffen, please try to *understand* what I said. (*)

The idea was not about replacing anything in WarpUP, it just was about
_not_ _only_ allowing replacement of 68k calls with PPC native calls
for WarpUP itself _but_ _also_ for the planned integrated ppc-lib
emulation of WarpUP. Talking about calls to libraries, here. Got it ?


(*) even if the original thread was about something different - it
must be possible to come up with new/additional suggestions;
that's what's the purpose of a discussion ;-)

sam jordan

unread,
Sep 7, 1998, 3:00:00 AM9/7/98
to
Janne P R Jalkanen wrote:

> > > How about if a PPC program wants to use an old 68k library?
> >
> > We didn't specifiy this up to now, but I think it should be possible
> > to perform such switches.
>
> Some programs use third party libraries, for which a PPC version might
> not be available. It would speed up porting applications, if you can
> just compile your own program to PPC code without having to worry
> about rewriting the entire GUI, for example, just because it uses an
> old GUI library which is not available for PPC.
>
> What would the penalty be in mixing 68k and PPC code within your
> emulator? Can we expect faster context-switches than the 0.5 ms? I'd
> guess so, since you only have one CPU to worry about ;-)

Well, the situation entirely depends on the type of emulation used:

a) blackbox emulation (the current solution). As I said, the whole
AMIGA-OS
is running as a task under WarpOS and all other PPC-native tasks are
running
as other WarpOS tasks. Calls from emulated to 68K and vice versa still
have
to be performed using mode switches, because a WarpOS task can not jump
directly into AMIGA-OS functions. Such a mode switch requires to change
from
the emulator task to the native task and vice versa, therefore it is not
possible to reduce the mode switch overhead to almost zero (because task
switches need some time for saving and restoring the whole processor
context).
Currently the mode switches are performed 8 times faster on the blackbox
emulation system than on the dual-processor solution with WarpOS, so
about 70us
for a call of an empty function (PPC to 68K and back again).

b) integration solution (which we hope to have in future). There the
emulator
is integrated into a PPC-AMIGA-OS and all AMIGA-OS tasks can either
execute
native code or emulated code, but there is absolutely no change of the
active
context, therefore mode switches can be reduced to almost zero, since
only
parameters have to be adapted to the programming model and the
appropriate
functions for mode changes have to be called. So if the emulation would
be
fast enough their would be no more penalty in using many mode switches.

ark

unread,
Sep 7, 1998, 3:00:00 AM9/7/98
to
Steffen Haeuser (mag...@birdland.es.bawue.de) wrote:

[...]

After overthinking it again: we've perhaps talked about the same
(while BTW using the term emulation for two things, 68k and ppc-lib).

However, I just was additionally mentioning two points:

- not excluding ppc-lib (emu) from automatic 'ppc-native'ation
- suggestion to actually build an *automatism* for replacing
from-PPC calls to 68k libs with calls to ppc-native libs
(how that's done for from-68k calls isn't of interest, here)

Forget about the rest. By mentioning Run68k() you perhaps already
have been assuming that this one would take care about that
'turn to PPC-native' conversion and that ppc-lib emulation
automatically would participate since it would be calling it,
anyway. However, although one might consider that being 'trivial'
or 'naturally' it's IMHO important to mention...

Steffen Haeuser

unread,
Sep 7, 1998, 3:00:00 AM9/7/98
to

klei...@studm.hrz.uni-siegen.de wrote :

Hi!

kl> You don't understand. A *compiled* PPC-lib based program does contain
kl> calls to PPCCallOS(). The function itself, however, is dynamically
kl> linked into the program when the ELF object gets loaded (however,
kl> even if it would work differently, there wouldn't be a problem in
kl> replacing a kernel function if the whole kernel is just an emulation/
kl> replacement, provided by WarpUP, anyway...)

I don't see the problem. If powerpc.library would provide PPCCallOS() this
would not help the ELF-Object in *ANY* way... as ELF-Object can't even call
PowerOpen-Shared-Libs (like powerpc.library is). I would say this problem has
to be handled by the ELF-Emulation.

kl> If you want to keep ELF programs running under the WarpUP emulation
kl> of ppc-lib even for the future (and not just as an alibi feature)
kl> it's an issue to minimize 68k emulation here as well - the same
kl> way as you suggested for WOS based programs... (this isn't even
kl> remotely related to further development of the ppc-lib kernel).

Oops, this really sucks. Could be a problem. Well, all i can say, is that the
guy doing the ppc.library Emulation has nothing to do with the Kernel coding.
These are two completely independent projects. So i guess it HAS to be
emulated somehow.

And about minimize 68k Emulation... this logically would not have to do
ANYTHING with the elf... it would be done using the Run68k function of the
powerpc.library directly, without any use of the ELF-Emulation...

kl> : the kernel which will be used... why use a function with a similar function of
kl> : a different API ? There is no sense in it... It WOULD make sense if there is a

kl> Be careful with "no sense". Maybe you just didn't notice/understand
kl> (or didn't want to ;-)

Or both did not want to :)

kl> Well, nice. I don't care, whether PPCCallOS() calls Run68k() or something
kl> else. However, I was talking about replacing calls to 68k code with
kl> calls to native PPC code - this obviously isn't related to Run68k() anymore.

Well, okay, let's get our definitions straight. The concept (AFA know it is):

warp.library/warpHW.library: HAL, Lowlevel Interface
powerpc.library: The Kernel
ppc.library: Emulation Library
emul68k.library: The Emulator (there also is a ROM and a Starter for it, still
- which in the future might sit in the ROM, currently is
a program on HD - .

ppc.library would contain:

- An Emulated ELF Loader (Just a program that can load ELF Files, translate
them, and execute them)
- API Emulations (for example a PPCCallOS() which calls Run68k() ).

emul68k.library sits completely on top of powerpc.library, it has nothing to
do with the ppc.library... the ppc.library just - asides from API Emulations -
contains the ELF Loader.

kl> And I wasn't talking about WarpUP but about letting the possibly integrated
kl> ppc-lib emulation of WarpUP participate in the possible creation
kl> of PPC native replacment libraries for 68k libs.

Why should it ? It is just an emulation for old software. There is no use it
to have anything to do with the Emulation. Actually it won't have anything to
do with it, simply out of the reason as the guys doing both projects work
totally independent from each other. Sam does Kernel/68k Emulation, someone
else does ppc.library Emulation (using the WarpUP API internally).

kl> The idea was not about replacing anything in WarpUP, it just was about
kl> _not_ _only_ allowing replacement of 68k calls with PPC native calls
kl> for WarpUP itself _but_ _also_ for the planned integrated ppc-lib
kl> emulation of WarpUP. Talking about calls to libraries, here. Got it ?

I don't see the problem. It would happen like that:

PPCCallOS() in ppc.library program -> calls Run68k() -> calls the Emulator

where actually do you see here a problem ?

Steffen Haeuser

Steffen Haeuser

unread,
Sep 7, 1998, 3:00:00 AM9/7/98
to

klei...@studm.hrz.uni-siegen.de wrote :

Hi!

kl> [...]

kl> After overthinking it again: we've perhaps talked about the same
kl> (while BTW using the term emulation for two things, 68k and ppc-lib).

I am absolutely confinced to it.

kl> However, I just was additionally mentioning two points:

kl> - not excluding ppc-lib (emu) from automatic 'ppc-native'ation

Why should it ?

ppc.library's PPCCallOS calls Run68k() of WarpOS which calls the Emulator :)

kl> Forget about the rest. By mentioning Run68k() you perhaps already
kl> have been assuming that this one would take care about that
kl> 'turn to PPC-native' conversion and that ppc-lib emulation
kl> automatically would participate since it would be calling it,
kl> anyway. However, although one might consider that being 'trivial'
kl> or 'naturally' it's IMHO important to mention...

Okay... yeah, i thought it to be "trivial".

Steffen

Randy Vice

unread,
Sep 8, 1998, 3:00:00 AM9/8/98
to
On Wed 2-Sep-1998 1:14p, mag...@birdland.es.bawue.de wrote:

m> ar...@ix.netcom.com wrote :

m> Hi!

m> >>The current emulator emulates the whole AMIGA-OS in a 'black box',

m> ar> The whole Amiga OS?
m> ar> You guys did a complete "classic" Amiga emulation then?

m> Well, if you emulate the 68k, naturally the 68k OS "AmigaOS" will run on
m> it
m> (as it is a 68k application). This emulator is NOT a
m> "Custom-Chip-Emulator" or
m> such like UAE. It emulates the 68k of the Amiga. And the AmigaOS runs then
m> in
m> Emulation. Of course this is only the first step which has to be done...
m> for
m> the future the market needs a PPC Port of the OS... with the Emulation
m> running
m> - so that the system works already - this could be done even "Step by
m> Step".

Does this make PPC system running 68K emulator equal to say a Draco system in
running AOS/apps?

: damo...@nostromo.gate.net : Bruce Morrow,a man before and after his time:
:"The Constitution shall never be construed to prevent the people of the :
:United States who are peaceable citizens from keeping their own arms." :
: - Samuel Adams : Morrow Project Science - Post-holocaust Party Animals! :

Steffen Haeuser

unread,
Sep 8, 1998, 3:00:00 AM9/8/98
to

damo...@nostromo.gate.net wrote :

Hi!

>m> it
>m> (as it is a 68k application). This emulator is NOT a
>m> "Custom-Chip-Emulator" or
>m> such like UAE. It emulates the 68k of the Amiga. And the AmigaOS runs then
>m> in
>m> Emulation. Of course this is only the first step which has to be done...
>m> for
>m> the future the market needs a PPC Port of the OS... with the Emulation
>m> running
>m> - so that the system works already - this could be done even "Step by
>m> Step".

da> Does this make PPC system running 68K emulator equal to say a Draco system in
da> running AOS/apps?

Do you mean as to speed or as to compatibility ?

Steffen Haeuser

ark

unread,
Sep 8, 1998, 3:00:00 AM9/8/98
to
Steffen Haeuser (mag...@birdland.es.bawue.de) wrote:

: I don't see the problem. If powerpc.library would provide PPCCallOS() this

: would not help the ELF-Object in *ANY* way... as ELF-Object can't even call
: PowerOpen-Shared-Libs (like powerpc.library is). I would say this problem has
: to be handled by the ELF-Emulation.

I didn't mean that, anyway...

: And about minimize 68k Emulation... this logically would not have to do

: ANYTHING with the elf... it would be done using the Run68k function of the
: powerpc.library directly, without any use of the ELF-Emulation...

Yes - assuming the redirection will work for both the same way (using
Run68k).

: emul68k.library sits completely on top of powerpc.library, it has nothing to

: do with the ppc.library... the ppc.library just - asides from API Emulations -
: contains the ELF Loader.

Logically.

: kl> And I wasn't talking about WarpUP but about letting the possibly integrated


: kl> ppc-lib emulation of WarpUP participate in the possible creation
: kl> of PPC native replacment libraries for 68k libs.
: Why should it ?

Because - if done right - it *could* be very easily (assumed that the
rest already had been done before).

: I don't see the problem. It would happen like that:


: PPCCallOS() in ppc.library program -> calls Run68k() -> calls the Emulator
: where actually do you see here a problem ?

It's not a *technical* problem, that's right :-)

ark

unread,
Sep 8, 1998, 3:00:00 AM9/8/98
to
Steffen Haeuser (mag...@birdland.es.bawue.de) wrote:

: kl> - not excluding ppc-lib (emu) from automatic 'ppc-native'ation


: Why should it ?
: ppc.library's PPCCallOS calls Run68k() of WarpOS which calls the Emulator :)

As I said: it won't be a *technical* matter, yes.

: Okay... yeah, i thought it to be "trivial".

And I *could* have assumed it to be naturally and then be very surprised...
- so, it perhaps makes sense to discuss any open technical matters _before_.

Especially because there are more 'facts' spreading around the
new WarpOS than the planned ppc-lib emulation.

ark

unread,
Sep 8, 1998, 3:00:00 AM9/8/98
to
ark (klei...@studm.hrz.uni-siegen.de) wrote:

: : kl> of PPC native replacment libraries for 68k libs.


: : Why should it ?
: Because - if done right - it *could* be very easily (assumed that the
: rest already had been done before).

I forgot to mention: it could be a task for Run68k(), too...

Randy Vice

unread,
Sep 8, 1998, 3:00:00 AM9/8/98
to
On Tue 8-Sep-1998 10:58a, mag...@birdland.es.bawue.de wrote:

m> damo...@nostromo.gate.net wrote :

m> Hi!

m> >m> it
m> >m> (as it is a 68k application). This emulator is NOT a
m> >m> "Custom-Chip-Emulator" or
m> >m> such like UAE. It emulates the 68k of the Amiga. And the AmigaOS runs
m> then
m> >m> in
m> >m> Emulation. Of course this is only the first step which has to be
m> done...
m> >m> for
m> >m> the future the market needs a PPC Port of the OS... with the Emulation
m> >m> running
m> >m> - so that the system works already - this could be done even "Step by
m> >m> Step".

m> da> Does this make PPC system running 68K emulator equal to say a Draco
m> system in
m> da> running AOS/apps?

m> Do you mean as to speed or as to compatibility ?

Compatibility.

It is loading more messages.
0 new messages