Ehm.
> >As for "everything slows down" - when applications use CPU time, this
> >happens. It's how all computers in all the world work. It's how all
> >applications on your Amiga work. Because you notice it more with
> >V is down to the fact that V is doing one hell of a lot more than other
> But if the used CPU is a PPC, the unused 68k is not slowed down. For a CPU
> to slow down, it needs to be used. As far as I know (not that i have deep
> technical knowledge. But I can figure basic things like this out)
Not entierly true. There is only ONE memory controler/bus, so if one of both
CPUs are heawily loaded, the another one (68k into this case) also cant
work,
because it cant acess memory. At least not as fast, as it would like to
acess it.
Simple as ass.
Dual CPU solution and sharing memory always has strong drawback.
Especialy if the CPUs lack of L2 cache and are diferent (not so easy
chaching
syncing)...
> > This has been explained MANY times before, please LISTEN this time so
that
> > you don't end up asking the same stupid questions again and again!
> I don't think this question is stupid.. I told you that AWeb JPegPPC
plugin makes
> *"EVERYTHING"* much faster leaving more time for 68k..
Good writen jpeg decoder for 68k will be faster, as for the heawy contex
switches
you encounter, is using PPC NOT ideal. Besides, AWeb is terribly slow, when
come
to pictures - compared to it, where complete 68k IBrowse just FLYing, so the
problem
is into the software, not into the HW.
> And when you decode proggressive jpegs in large hunks (there is a setting
> for this), it speeds up more. Because of reduced context switches.
> I am talking about a speed up here!
Yea, and? Progresive jpegs is insane to be decoded into passes, everyone
with at least one braincell must see, that 5x passes eat 5x more time, as
the writing into graphic memory is the main bottleneck there, not the CPU
power. And this is possible to disable, jsut change one variable into jpeg
docoder sources and - viola - after first small wait, progressive jpeg is
decoded
into ONE pass, resulting into about 4x faster (!!!) speed.
There is the way, how to get more speed. Use more clover solutions, with
performace limitations into mind.
Even on AGP4x machines with over GHz CPUs this way of optimalization
makes really sense, as we tried.
> *I am not going to give any bugreport again nor am i going to request
> anthing. Morphos is nice.. But it's not what i am using or what i am going
to use.
MorphOS is maybe nice, but mainly illegal into the pure beginning. Lets see
Hyperion statement about it.
Altrought i can say - fuck legal, lets go illegaly - when AI dont going to
give us
a PPC system for HW we have. But no matter of that this is true, i still see
a MorphOS as good as it are. Instead of lies and fake/lame promises (AI) is
there finaly a something what gets materialized.
Hoooray!
> I am using and will use AmigaOS till development stop.
I also only using AmigaOS.
> Why don't you drop AmigaOS support? This way you can improve the Morphos
> version more.
Because there are more AmigaOS guys that MorphOS ones, and we regged
V for AmigaOS, for 68k. Not for PPC and MorphOS.
Yes, even i have a 233Mhy 604e, i still prefer my belowed 68k 68060 cpu
over it. At least it not crashing during mpeg playback with AUDIO, as
PPC doing while AMP is used...
Trodas
_____________________________________________________________________
Voyager Mailing List - http://v3.vapor.com/
Voyager FAQ....: http://faq.vapor.com/voyager/
Listserver Help: mailto:[EMAIL PROTECTED]?Subject=HELP
Unsubscribe....: mailto:[EMAIL PROTECTED]?Subject=UNSUBSCRIBE
