How does the PowerUP-accelerators actually work?

[patrik]

Hi everyone, I hope that someone can shed some light on this question.

How is the PowerPC-processor on the PowerUP-accelerators controlled?


/Patrik

[ajk]

Look up WarpOS or PowerUP in the net. Basically a separate PPC kernel that allows programs to use the extra processor. Not having the OS run on PPC held a lot of power back in some cases though, OS4 will help there.

[lempkee]

erm?=?

it works like this,  you do an ppc instruction (code) and the cpu works...wow..

there is 2 kernels for that , powerup (the first) and warpos (second and the best)

to them who ask such a question...hard to answer as its not a fantastic thing , besides you have alot of contextswitching between the 2 cpus and on a1200 u have contextswitching between the 3 cpus.

anyway to do ppc sw , then you need to do ppc calls, if thats what you wanted to know..

 the ppc wont do any work unless there is a tool or a game that takes advantage of it, ie just like an fpu, needs special commands to work.

also amigaos 3.x is 68k only , and the ppc wont be in use at all unless u install warpos or powerup and then later you need to install ppc datatypes and such...

and as ajk said...this is where os4 and morphos does a better job because its an ppc os.

i wont be suprised if there is a huge speed up when the os\s are finished.

cheers

[downix]

I will disagree on WarpUP being better than PowerUP.   I found WarpUP programs slower than PowerUP.

[patrik]

@lempkee:

When reading your answer I realise that my question was quite unprecise, aiming just about everywhere .

What I am curious about are things like these:

At startup, the 68k-processor first loads its supervisor stack pointer from address 0x00000000, then its program counter from address 0x00000004, and in this case, on an Amiga starts executing the exec kernel.

I guess a PowerPC processor is very eager to do something similar, but what happends in its case - does it have a ROM waiting for it with PowerPC code which initializes it with some appropriate interrupt-vectors etc?

I am also very curious about the details of how the 68k kernel(exec) processor communicates with the PowerPC kernel. Does it write something to a special area in memory and gives the PowerPC processor an interrupt making it read from that memory area or... I am full of questions .


/Patrik

[lempkee]

downix:i agree with you on a few things , like mame ..but that is because of the coder, there is alot of sloppy work around and more will come now that we have faster hw plattforms.

but there is a few things, ever seen 3d render with pup? ...
ever seen new stuff by the same developers ?

the good ones left sadly, and atm there is mostly only bloatware to port...ie like later versions of mame (which is a big bloat atm ;().

anyway i totally agree with you on it beeing faster for a few things, but by far all.


patrik: i will answer you in the morning if no other has posted some answers.

cheers

[Karlos]

@downix

I disagree strongly. I have used PPC on amiga since the BlizzPPC was first available here in the UK.

The only version of warpos that I have ever seen run slower than powerup on my machine was an early powerpc.library implementation that actually ran on powerup itself. I think this was powerpc.library v7.

The earlier versions of the powerup kernel were extremely poor and the warpup kernel (after v7 when it became removed from the ppc.library dependencies) proved considerably faster. It multitasked more smoothly and context switching times were roughly half that for powerup.

Later revisions of the powerup kernel improved performance dramatically, but were in my experience merely 'catching up' with warpup.

I guess in the final analysis it all comes down to the machine configuration and it's academic since both MOS and OS4 will never have to worry about a real 680x0 processor again ;-)

[patrik]

*wink* Anyone else got this straightened out and feels like sharing?


/Patrik

[lempkee]

patrik: i didnt make a kernel for it so basically your questions are way too deep for me.

cheers

[patrik]

@lempkee:

Damnit lempkee, why didnt you make a kernel for the PowerUp cards?!?? )) Erm.. sorry, couldnt help it .

Take care!


/Patrik

[bloodline]

a1200 u have contextswitching between the 3 cpus

Lempkee, what the hell are you talking about???


Anyway, The 68K boots the machine running AmigaOS from the ROM, the PPC processor also boots but it boots a custom OS (PowerUP forexample) from it's own ROM (on the PPC board). The PPC's OS is little more than an executive (like AmigaOS's exec.library), and it just sits there until the 68k gives it a task.

The PPC is then able to load the task an execute it. The 68K and the PPC run at the same time (but share their Memory), and the 68K and the PPC have to communicate using special structures defined by the system you are using.
The PPC is not allowed to access any AmigaOS structures but instead must ask the 68K to do OS things for it. I believe the PPC is allowed to access the Amiga Custom Chips.

[Karlos]

bloodline wrote:
The PPC is not allowed to access any AmigaOS structures but instead must ask the 68K to do OS things for it.

Not entirely true. The PPC read access amiga OS data structures fine as long as the basic alignment is limited to 2 byte boundaries. Thats why you have #pragma amiga-align in vbcc ;-)

Writing to OS data structures is fine too, provided they are allocated cache aligned, hence the AlocVec32() functions.

However, just as with 680x0 code, you *should* use the OS functions for dealing with OS structures where possible.

For writing 'good' code under warpos, the best thing is to gather all of your 680x0 OS routines that are called as part of an operation (updating the display, fetching input events from your window etc., waiting for the display sync) into a single 68K function that you can then manually context switch to from the PPC.

I used this approach in some experimental code in vbcc to test the idea and got a double/triple bufffered display with IDCMP input (the event data was copied to a shared area so the handler callbacks can be ppc native) down to one full PPC->68K->PPC context switch per frame.

Still, I am looking forward to forgetting all of these type tricks when OS4 is released :lol:

[lempkee]

bloodline: if you look whats been said then u would know what i was talking about , as in his question wasnt very "spot on".

context switching is the biggest issue on the classic powerup cards and will allways be as long as we are stuck with an 68k os , sure its gotten better as whas pointed out in earlier threads, but its still a major prob.

(68k cpu does still a major job even if its a ppc app (when running amigs os with wos/pup).

[Kronos]

You talked about context-switching between 3 CPUs on the A1200.

So there is the 603,and there is the 060 (or 040),that makes 2.

So where is numeber 3 ? You couldn't have meant the 020 on the mobo,
as this isn't active for 1 secound in such a setup.

[bloodline]

Karlos wrote:

bloodline wrote:
The PPC is not allowed to access any AmigaOS structures but instead must ask the 68K to do OS things for it.

Not entirely true. The PPC read access amiga OS data structures fine as long as the basic alignment is limited to 2 byte boundaries. Thats why you have #pragma amiga-align in vbcc ;-)

Writing to OS data structures is fine too, provided they are allocated cache aligned, hence the AlocVec32() functions.

However, just as with 680x0 code, you *should* use the OS functions for dealing with OS structures where possible.

For writing 'good' code under warpos, the best thing is to gather all of your 680x0 OS routines that are called as part of an operation (updating the display, fetching input events from your window etc., waiting for the display sync) into a single 68K function that you can then manually context switch to from the PPC.

I used this approach in some experimental code in vbcc to test the idea and got a double/triple bufffered display with IDCMP input (the event data was copied to a shared area so the handler callbacks can be ppc native) down to one full PPC->68K->PPC context switch per frame.

Still, I am looking forward to forgetting all of these type tricks when OS4 is released :lol:

I must confess that I never used WarpOS, I simply couldn't be bothered with it :-)

I did write a PPC (PowerUP) multithread library for BlitzzBasic though, that alowed you to to complex processing on the PPC Async with your 68k program.. (did anybody ever use it?).