Amiga.org
Amiga computer related discussion => General chat about Amiga topics => Topic started by: Mrs Beanbag on January 30, 2012, 07:52:53 PM
-
Ok so I know the PowerPC accelerators for classic Amigas have both a PPC chip and a 68040 on board, but when does the PowerPC chip come in and how does it know? Does a program have to run on the 68k at first (like a bootstrap) and then trigger some kind of switch, throw an exception, or call a library function or something?
-
Ok so I know the PowerPC accelerators for classic Amigas have both a PPC chip and a 68040 on board, but when does the PowerPC chip come in and how does it know? Does a program have to run on the 68k at first (like a bootstrap) and then trigger some kind of switch, throw an exception, or call a library function or something?
Neglecting OS4.x and MorphOS 1.x for the moment, there are 2 solutions on OS3.x. The following description is somewhat generalized and may have mistakes and omissions as it was a long time ago that I last looked at it.
First there was PowerUP (or just PUP). This was developed by phase5 as the software to allow applications to take advantage of the PPC. Essentially, it comprises a kernel for the PPC, along with some APIs for developers and a set of patches to the host operating system to bootstrap the processor.
Once the system was up and running, the (patched) host OS was able to load PPC binaries in ELF format (it may have been modified a bit, but essentially the same format described in the old System V). An ELF could be an entire application for the PPC, or just a set of PPC optimised functions to be used by an otherwise 68K application. Code running on the PPC was basically independent of the 68K until it needed to call a host OS function (note that the PUP kernel provides memory management, tasks and so on for the PPC side).
The mechanism required to call 68K code from the PPC (or vice versa) necessitated that both processors flush their data cache. The parameters for the call would then be passed through memory from one to the other. While the "other" CPU is working, the corresponding process on the current CPU is basically asleep until the opposite CPU completed and returned. This process was simply called a "context switch" (a widely used term in other areas of computing, but technically accurate nonetheless). I'm afraid I forget the specific underlying details on how all this was achieved exactly. If memory serves, there was an arbitration "server" process involved in the communication between the two processors. Perhaps someone better qualified can answer that.
The system worked, but early versions suffered poor performance due to the overhead of said context switches (this was addressed later). In the time it took either processor to flush it's cache, it could have done millions of instructions. Other criticisms revolved around the use of ELF which was seen as an alien standard on the Amiga* which had it's own hunk format for binaries. Soon thereafter, WarpUP appeared (later called WarpOS), a rival system that extended the amiga hunk format to allow PPC code segments in executables, leading to "fat" binaries.
Fundamentally, it was similar to PUP: a PPC kernel, API and a set of OS patches. The main differences were in the implementation. WarpUP tried to mirror Exec's structure for the services it provided. Threads were in pairs, one for each CPU and only one of which would be active at any time (there were asynchronous context switches but they were tricky to use). A single threaded application that used the PPC would thus really be two threads, one on either chip, only one of which was running at any instant, the other sleeping and waiting for it's counterpart to return. However, they shared many fundamental components, such as signals. If you sent CTRL-C to one, the corresponding signal bit would be set in both the Task and TaskPPC (or at least it was routed to whichever was active, I forget).
It still required cache flushing in the same way as PUP, the main advantage of the system (at the time) was that it offered considerably quicker at it. That performance gap closed in later versions of PUP, but by then we'd enjoyed the "kernel" wars and WarpUP had become the unofficial standard. At least until OS3.9 where the picture.datatype used it. That's about as official as it ever got.
Each system had it's strengths and weaknesses. The Achilles heel of both was the context switch. It may have been faster on WarpUp, but in real terms it was still shockingly expensive. You had to carefully design code to minimise these if you wanted your application to run acceptably.
*ironically, all the offshoot operating systems use it for their native binary format.
-
Neglecting OS4.x and MorphOS 1.x for the moment, there are 2 solutions on OS3.x. The following description is somewhat generalized and may have mistakes and omissions as it was a long time ago that I last looked at it.
First there was PowerUP (or just PUP). This was developed by phase5 as the software to allow applications to take advantage of the PPC. Essentially, it comprises a kernel for the PPC, along with some APIs for developers and a set of patches to the host operating system to bootstrap the processor.
Once the system was up and running, the (patched) host OS was able to load PPC binaries in ELF format (it may have been modified a bit, but essentially the same format described in the old System V). An ELF could be an entire application for the PPC, or just a set of PPC optimised functions to be used by an otherwise 68K application. Code running on the PPC was basically independent of the 68K until it needed to call a host OS function (note that the PUP kernel provides memory management, tasks and so on for the PPC side).
The mechanism required to call 68K code from the PPC (or vice versa) necessitated that both processors flush their data cache. The parameters for the call would then be passed through memory from one to the other. While the "other" CPU is working, the corresponding process on the current CPU is basically asleep until the opposite CPU completed and returned. This process was simply called a "context switch" (a widely used term in other areas of computing, but technically accurate nonetheless). I'm afraid I forget the specific underlying details on how all this was achieved exactly. If memory serves, there was an arbitration "server" process involved in the communication between the two processors. Perhaps someone better qualified can answer that.
The system worked, but early versions suffered poor performance due to the overhead of said context switches (this was addressed later). In the time it took either processor to flush it's cache, it could have done millions of instructions. Other criticisms revolved around the use of ELF which was seen as an alien standard on the Amiga* which had it's own hunk format for binaries. Soon thereafter, WarpUP appeared (later called WarpOS), a rival system that extended the amiga hunk format to allow PPC code segments in executables, leading to "fat" binaries.
Fundamentally, it was similar to PUP: a PPC kernel, API and a set of OS patches. The main differences were in the implementation. WarpUP tried to mirror Exec's structure for the services it provided. Threads were in pairs, one for each CPU and only one of which would be active at any time (there were asynchronous context switches but they were tricky to use). A single threaded application that used the PPC would thus really be two threads, one on either chip, only one of which was running at any instant, the other sleeping and waiting for it's counterpart to return. However, they shared many fundamental components, such as signals. If you sent CTRL-C to one, the corresponding signal bit would be set in both the Task and TaskPPC (or at least it was routed to whichever was active, I forget).
It still required cache flushing in the same way as PUP, the main advantage of the system (at the time) was that it offered considerably quicker at it. That performance gap closed in later versions of PUP, but by then we'd enjoyed the "kernel" wars and WarpUP had become the unofficial standard. At least until OS3.9 where the picture.datatype used it. That's about as official as it ever got.
Each system had it's strengths and weaknesses. The Achilles heel of both was the context switch. It may have been faster on WarpUp, but in real terms it was still shockingly expensive. You had to carefully design code to minimise these if you wanted your application to run acceptably.
*ironically, all the offshoot operating systems use it for their native binary format.
barry do teh money dance
-
Or to make long story short: PPC is usable only as co-processor where it is completing heavy computing on a background. Calling an OS from PPC is too expensive.
-
Or to make long story short: PPC is usable only as co-processor where it is completing heavy computing on a background. Calling an OS from PPC is too expensive.
That's not exactly true, though, is it? There were plenty of applications that ran almost entirely on the PPC, calling the OS to do IO, graphics etc.
The way I used to write code (albeit for WarpUP, never really did much for PUP) was to have a main 68K function that was polled from the PPC (usually once per frame in a graphical application). That function would then do all the OS stuff; switch screenbuffers, collect the contents of IDCMP messages and so on, before returning to the PPC. The PPC would then do a bunch of native callbacks for said messages before continuing on with it's main loop. It was surprisingly effective :)
-
An interesting side-effect of the way both systems worked is that you actually got a degree of multiprocessing.
When a 68K thread invoked a PPC operation, it basically went to sleep until the PPC finished working and returned, and vice versa.
The PPC kernels were both, as far as I know, preemptive, as of course is exec. So, while a given 68K thread is asleep and the PPC doing some work for it, Exec is able to run a different 68K thread during that time (memory bandwidth permitting). Likewise, when any given PPC thread is asleep waiting for the 68K, the PPC kernel is able to run a different PPC thread.
Both processors ran with cache and copyback enabled and so if whatever they were executing didn't hit memory at the same time, you could get a 68K thread and (unrelated) PPC thread running concurrently.
Still, it probably didn't happen that often given that most people ran only one PPC application at a time.
-
barry do teh money dance
Also, the above...
/me slowly edges backwards towards the door, smiling at the strange man from Belfast in a non-threatening manner :lol:
-
So nobody outside of OS4/MOS went the Apple route and simply did 68k in emulation? Huh.
-
So nobody outside of OS4/MOS went the Apple route and simply did 68k in emulation? Huh.
That was the plan for later PPC accelerators that never materialized. Phase5 had announced the CyberstormG4 and BlizzardG4 line. I badly wanted the latter and had already located a source of spare kidneys to fund one, but alas it never appeared. Which is probably good news for one black market transplant recipient, I don't think any credible surgeon would be fooled by what I found at my local butchers...
Later, there was the AmiJoe G3, but again, it was never released.
All of these boards lacked a 68K processor and would require emulation resources in their firmware.
-
Wow, now that's a far more detailed answer than I was expecting! Thanks!
-
Also, the above...
/me slowly edges backwards towards the door, smiling at the strange man from Belfast in a non-threatening manner :lol:
Sorry, I think moobunny is starting to get inside my head. ;)
-
So nobody outside of OS4/MOS went the Apple route and simply did 68k in emulation? Huh.
Exact reason why OS 4 and MOS are seen as natural progression of Amiga PPC Cards. Unlike CUSA trolls that try to explain it was meant to be x86 way.
Sadly, while AmigaOS and MOS went PPC routes,
PPC kind of died as dekstop platforn, primary because it was left by Microsoft, IBM, Apple and most of Linux distro in that exact order of time (and all of them were part of lets replace x86 with PPC alliance in the beginning)
-
PPC kind of died as dekstop platform
Now that's a common misconception. It's not more dead than Amiga itself. As long as we, the users, are alive the platform is not dead.
-
My Power Macs still work like new...
-
oyeah! karlos provided an answer in depth i was hoping for.
i d like to mention that even i now own one, i have considered and still consider the ppc accels too complicated, too clumsy, too expensive and in the long run not dependable enough a solution as it was worth to copy. at its time they mark a point when i decided to finally turn my back on what was going to happen to amiga and i am very happy i have been not aware of the whole ppc tragedy.
-
Exact reason why OS 4 and MOS are seen as natural progression of Amiga PPC Cards. Unlike CUSA trolls that try to explain it was meant to be x86 way.
Bernd Meyer would disagree with you.
-
Let's be clear about one thing. Commodore (the original) never produced any PPC hardware for Amiga at any time and future PPC compatibility was not on their radar. They did, however, produce x86 boards but they were designed to run x86 operating systems (typically MS-DOS) for business use. They weren't integrated with AmigaOS to any extent.
The PPC boards were entirely third party aftermarket expansions. However, their intent was to augment the host machine and allow AmigaOS to run applications that would otherwise be too processor intensive for 68K.
-
Let's be clear about one thing. Commodore (the original) never produced any PPC hardware for Amiga at any time and future PPC compatibility was not on their radar. They did, however, produce x86 boards but they were designed to run x86 operating systems (typically MS-DOS) for business use. They weren't integrated with AmigaOS to any extent.
The PPC boards were entirely third party aftermarket expansions. However, their intent was to augment the host machine and allow AmigaOS to run applications that would otherwise be too processor intensive for 68K.
Surely, because PowerPC wasn`t avail at time Commodore died.
And yes, they made PC clones, but that didn`t do well.
They also did Sidecar AT/XT expansion boards to make Amiga hardware compatibile with PC, but only up to 286 or 386. On original Amiga 1000 1985 presentation PC Task or similar was demonstrated with machine.
So there is no trouble Commodore wanted soft or hard x86 compatibility to utilize the bussiness software, but AmigaOS never went x86 in any part.
However, there were many PPC related projects
http://www.amigahistory.co.uk/ppchistory.html
out of which only MOS and OS4 (and AROS PPC) survived
Amiga DE / OS 5 was supposed to support both PPC and x86 but never went real.
pOS, a WB enhancement that was independent idea of ProDAD was made beta 68k and also supposed to become PowerPC
http://www.amigahistory.co.uk/pos.html
-
Let's be clear about one thing. Commodore (the original) never produced any PPC hardware for Amiga at any time and future PPC compatibility was not on their radar. They did, however, produce x86 boards but they were designed to run x86 operating systems (typically MS-DOS) for business use. They weren't integrated with AmigaOS to any extent.
The PPC boards were entirely third party aftermarket expansions. However, their intent was to augment the host machine and allow AmigaOS to run applications that would otherwise be too processor intensive for 68K.
Note that Phase 5 wanted to move AmigaOS to PPC
http://www.amigahistory.co.uk/prebox.html
So Phase5 card was a transition.
Even with OS4 / MOS times, first a G3/G4 card for A1200/A4000 was planned first before amigaOne board, but manufacturer failed.
Only x86 system that bare Amiga name was Amiga Inc improvisation
that had nothing to do with AmigaOS
http://www.amigahistory.co.uk/os4dev.html
So surely there was much more effort in AmigaOS + PPC ways
-
Bernd Meyer would disagree with you.
UAE and Amithlon are emulation boxes that provided like AmiKit, AmiSYS and AmigaForever later way to emulate the OS 3.x but not an inch way forward (like PowerUp, WarUp, MorphOS and AmigaOS 4 did).
Dammy and Baron would surely disagree too.
-
That's not true. Yes amithlon does emulate a 680x0, but its not an amiga emulator as such and shares little in common with uae. Amithlon is more a way to get os3.x running on the metal on pc hardware as opposed to emulating an amiga.
Amithlon also lets a person run x86 AmigaOS3.x code under AmigaOS. You could compile 68k components to x86 code and run then in tandem with 68k.
While the OS itself makes only minor changes its not really accurate to say it didnt move forward and shares next to nothing in common with 68k "distros".
Perhaps you should learn about what it is youre typing before you type it?
-
@vox
What about AROS on x86? The first versions of that go back to mid to late 90's. I may be wrong, but I'm sure it appeared before there were any PPC boards on sale.
Also, regarding Amithlon, see the "big-endian x86" target. You could compile code for x86 with the automatic modification that all memory accesses are swapped (according to their size) to ensure interoperability with the OS. It was clever stuff.
-
That's not true. Yes amithlon does emulate a 680x0, but its not an amiga emulator as such and shares little in common with uae. Amithlon is more a way to get os3.x running on the metal on pc hardware as opposed to emulating an amiga.
Amithlon also lets a person run x86 AmigaOS3.x code under AmigaOS. You could compile 68k components to x86 code and run then in tandem with 68k.
While the OS itself makes only minor changes its not really accurate to say it didnt move forward and shares next to nothing in common with 68k "distros".
Perhaps you should learn about what it is youre typing before you type it?
OK, I know all about Amithlon, tested it at the time, yes its only x86 recompile of AmigaOS 3.x not new OS or any way forward. Yes, some apps in it are x86, some could be recompiled. Its not emulation and that is why its fastest of all x86 toys. Sadly doesn`t support much hardware and there are no x86 apps to run it. It dead ended quick even for some time it was considered as way forward. But didn`t produced any new code in terms of OS advancement. And is only AmigaOS related product that was taken out of sale as illegal.
http://www.amigahistory.co.uk/emulators/amithlon.html
And in fact it isn`t progress, it was just straight port. Layers like PowerUp, WarUp, PPC supported new apps and games, and later MOS and OS4 brought real progress ahead (In early stage that never made it to public OS4 was also just an OS 3.1 PPC port. But it took 30 months before it was public with many improvements in libs, execSG etc.). MOS approach was also great and innovative, first to make 68k emulation within the new OS! To bring new MUI, optimize everything and bring first completely native PPC apps - no coprecessing! 68k off and retired!
About AROS x86, yes it first appeared in 1997 but only recently did it implement most of AmigaOS 3.x features and went ahead.
OK?
So x86 Amiga developments, beside AROS, didn`t went much. With AROS I appriciate realy its multiplatform and open source, only one to be, so its kind of different.
This was most infamous anti x86 speech by Hyperion.
http://www.amigahistory.co.uk/emulators/hyperionblast.html
Surely, many things changed since then.
MOS was supposed to be first choice for next gen AmigaOS, but eventualy decision was make to do PPC port of AmigaOS 3.1 and from there go to today.
http://www.amigahistory.co.uk/aros.html
It was idea to make open AmigaOS
http://www.amigahistory.co.uk/oafaros.html
and they made it - my salute!
But its not that x86 tied at all, and now it returned even to 68k!
So most of the OS progress was done on PPC in those terms, apart from AROS.
-
Ok, please don't kill me. I know this has been beaten to death in one way or another. I also know OS4 is very anti-x86 right now (for now) as is MOS with their reuse PowerPC hardware drive (which I appreciate as I own both old PowerMacs as wells a A1200T/PPC).
My question is wouldn't something like a x86 SOC with a 68K emulation layer be a good fit? A trapdoor expansion for the A500/A1200 style machines could offer up SATA, Ethernet, possibly even a RTG driver for the SOC graphics driver and much faster performance than any 68K.
Intel CPUs haven't been very good at emulating PPC hardware to my knowledge (aka PearPC and what not) but that could simply have just been the software and not the chips fault.
It seems as long as the Amiga thinks it's getting a 68K CPU, it really doesn't matter what the architecture of the accelerator is. And if it comes with lots of the features provided by a SOC style solution and perhaps a DDR3 (not for speed reasons but rather availability reasons) RAM slot then woohoo!
I'm guessing this isn't viable only because nobody would spend the time to invest this type of development on the Amiga community.
Thoughts, please, not angry flame war comments.
-
My question there would be, why make an expansion at all? If you're going to replace every component, you might as well just put a picoITX x86 board in an Amiga case, load 'er up with WinUAE, and call it a day - you'll save a lot of time, money, and hassle.
-
Ok, please don't kill me. I know this has been beaten to death in one way or another. I also know OS4 is very anti-x86 right now (for now) as is MOS with their reuse PowerPC hardware drive (which I appreciate as I own both old PowerMacs as wells a A1200T/PPC).
My question is wouldn't something like a x86 SOC with a 68K emulation layer be a good fit? A trapdoor expansion for the A500/A1200 style machines could offer up SATA, Ethernet, possibly even a RTG driver for the SOC graphics driver and much faster performance than any 68K.
Intel CPUs haven't been very good at emulating PPC hardware to my knowledge (aka PearPC and what not) but that could simply have just been the software and not the chips fault.
It seems as long as the Amiga thinks it's getting a 68K CPU, it really doesn't matter what the architecture of the accelerator is. And if it comes with lots of the features provided by a SOC style solution and perhaps a DDR3 (not for speed reasons but rather availability reasons) RAM slot then woohoo!
I'm guessing this isn't viable only because nobody would spend the time to invest this type of development on the Amiga community.
Thoughts, please, not angry flame war comments.
No prob. Well, idea is overall good: but that is exactly what Natami does with FPGA and 68k emulation (or what Blizzard card offered with SCSI connector, faster RAM and faster 68k onboard beside PPC). We all wanted Natami on PCI card for our PeeCees and AmigaOnes, but its not planned so far. A Zorro version of it would fit all your dreams. However, all A1200/A4000 expansions advance the Classics to some high end (USB boards like mediator, Blizzard cards etc.) but still system has some remaining limitations (except completely Zorro based design like DraCo
http://www.amiga-hardware.com/showhardware.cgi?HARDID=43
But again, 68060 has its limits (and is exactly reason why Motorola - now Freescale moved to PowerPC) and it would limit performance of SATA, DDR3 etc. Natami designers are trying to overlap this limits to the max by designing "68070" softcore, but again, they plan to reach about 100Mhz PPC performance at all.
If something is dead, sadly its 68k since 1997 or so when 68060 production stop. ColdFire and similar follow ups are not compatibile enough even they bring 300Mhz performance.
Maybe a port of AROS to ColdFire could be possible as way ahead and ColdFire PCI accelerator for Natami board in the future, or similar.
I believe Natami is right chioce for you :-)
-
Amiga DE / OS 5 was supposed to support both PPC and x86 but never went real.http://www.amigahistory.co.uk/pos.html
lol!
and was "Better than OSX"
I assume "never went real" should translate to "Never existed".
-
I believe Natami is right chioce for you :-)
Well it's certainly on my shopping list. Whenever the damn add to cart button appears I'll be pressing it :)
The design and implementation of any new hardware expansion for classic Amigas is a massive undertaking with no real profit gains to be had. So, yeah, I totally understand there are more reasons to not do it than to do it.
@commodorejohn - I run UAE too and it's not quite the same thing. I was pointing at the relatively "free" nature of all the features of most SOC style chips. All the things I spoke of would be additions to the Amiga chipset.
Assuming someone were to undertake a new classic expansion, it seems like a big bang could be had for fewer dollars going with a SOC style chip only because of what you get for free with the chip alone.
There may be some life in the idea only because it could offer for non-towered systems what a mediator style setup would for big box and expanded A1200s (namely ethernet, sata, graphics, etc...)
I know it's a pipe dream but it was a fun thought.
-
lol!
and was "Better than OSX"
I assume "never went real" should translate to "Never existed".
In best tradition of Amiga Inc claims believe CUSA claimed they will kind of beat Apple, Dell etc.
And promised Workbench 5.0
http://www.commodore-amiga.org/en?start=15
"Workbench 5 will also be 100% Commodore compatible, able to run classic 8-bit, 16-bit and 32-bit era software via emulation. Our next generation Commodores and AMIGAs also provide optimum software flexibility by providing the option to run Windows software either from a dual boot menu at start up, or seamlessly integrated within Workbench 5 itself."
Fun never ends
-
OK, I know all about Amithlon, tested it at the time, yes its only x86 recompile of AmigaOS 3.x not new OS or any way forward.
It was the way forward, McEwen knew it, and rejected it. Perhaps an act
of big-corporation tampering. All other things you mentioned about Amithlon,
would have turned out quite different, with some minimal financial support for the project, which was on the precipice of greatness.
-
In best tradition of Amiga Inc claims believe CUSA claimed they will kind of beat Apple, Dell etc.
Yep reminiscent of when McEwen announced his fantasy AmigaOS 5, which was supposedly better than OS X. :D
http://downloadsquad.switched.com/2007/10/07/amiga-os5-to-be-better-than-mac-os-x/
Well I'll say one thing, CUSA and Ainc are perfect business partners.
-
That's not exactly true, though, is it? There were plenty of applications that ran almost entirely on the PPC, calling the OS to do IO, graphics etc.
What applications? Unless you mean games, do you?
Anything using native UI is fail. Software like IBrowse/PPC was not an option.
Nevertheless PPC boards were expensive doorstops. Fast 68060 accelerator boards would have been much better investment.
-
Nevertheless PPC boards were expensive doorstops. Fast 68060 accelerator boards would have been much better investment.
Not sure Id go so far as to say they were useless, but I agree an '060 is a better option for classics than ppc.
My old bppc+grex+voodoo3 system rarely got touched in favor of amithlon and not just becuase of the vastly superior performance amithlon offers. There simply wasnt much worthwhile for ppc. Given the choice of the same hardware again ('040 + ppc in my case) or an '060 Id go for the '060 any day of the week. Overall its a much better experience.
-
Even an '060 is overrated IMHO as it can cause major headache's with the different versions of 68060.library... The 060 also came out after Commodore left us, there never was a 060 card from Commodore or AT. Only a rebadged Quickpack card if I'm not mistaken. They are faster than a 040 for sure, but feature and compatibility-wise nothing beats a 40MHz 040 such as the WarpEngine.
@Karlos
Great explanation of the PPC/68K coexistence on Classic Amiga's! I've done much reading about it the last year but this is the best summary I've seen ;-)
If you have any guides to programming for WarpOS that would be much appreciated... I cannot get the gcc 2.95 running properly to build native WarpOS binaries (apparently the powerpc assembler is missing)...
edit: making it easy to port programs, having an easily installable compiler with SDK is my "classic 3.9 holy grail" ;-)
-
Even an '060 is overrated IMHO as it can cause major headache's with the different versions of 68060.library... The 060 also came out after Commodore left us, there never was a 060 card from Commodore or AT. Only a rebadged Quickpack card if I'm not mistaken. They are faster than a 040 for sure, but feature and compatibility-wise nothing beats a 40MHz 040 such as the WarpEngine.
I couldn't agree more, I owned a CS060 MKII and still own a WE 3040. Side by side in normal usage test, the 3040 was faster in some aspects. The built in SCSI in the WE certainly helped, in a 3000D the SCSI for the CS didn't fit.
-
Not sure Id go so far as to say they were useless, but I agree an '060 is a better option for classics than ppc.
I had BPPC+BVision with PPC native JPEG datatypes and mpega.library installed but that is all. Few games (often buggy) and few demos didn't really justify investment.
Later I got chance to run MorphOS 0.x on it but in the end it was just waste of money.
I think culmination point was when I tried PPC native Unzip program that was slower than 68k native Unzip on my lousy 68040 @ 25 MHz.
-
I couldn't agree more, I owned a CS060 MKII and still own a WE 3040. Side by side in normal usage test, the 3040 was faster in some aspects. The built in SCSI in the WE certainly helped, in a 3000D the SCSI for the CS didn't fit.
I guess you never used Oxyron Patcher. It is best installation any 68060 can do. It speeded everything - games, demos, utilities, gave more compatibility.
No 68040 can beat 68060 with Oxyron in any test.
Oxyron Patcher Benchmarks (http://www.vesalia.de/d_oxyron.htm)
-
OK, I'll give it a try! Still need to figure out the correct jumpers for my GVP 4060DT (now quite unstable) but after I do, I'll give it a go. For the money a WE is the best card there is IMHO...
The nice folks at EAB pointed me to VBCC as a better alternative to gcc for creating 68K / PPC code. Will try that as well...
And 'zip' and 'unzip' versions on the PPC really fly compared to the 68K version... I'd say a factor 10x speedup. If I ever figure out how I'll recompile a nice version of LHA and ZIP for AmigaOS 3.x and WarpOS.
-
What applications? Unless you mean games, do you
Processor intensive applications; typically games and media players principally. Not much productivity wise, though there were some utilities that could benefit. PPC accelerated datatypes were handy, particularly image ones with the OS3.9 picture.datatype where colour conversion and dithering can be offloaded to PPC too.
Even StormC 4 had ppc native compiler backends for both PPC and 68K which helped when compiling larger projects with it (storm had plenty of issues but that's a different discussion).
-
One example is Wildfire7\PPC image processing sw.
-
Processor intensive applications; typically games and media players principally. Not much productivity wise, though there were some utilities that could benefit. PPC accelerated datatypes were handy, particularly image ones with the OS3.9 picture.datatype where colour conversion and dithering can be offloaded to PPC too.
PPC native picture datatypes were nice but they were slower than 68k counterparts for small images. Still fast enough to replace 68k datatypes on my system where possible.
Video players on Amiga were always outdated and could display only few formats. And often my BlizzardPPC @ 160MHz was not fast enough to play videos at full frame rate.... PPC accelerated MP3 players were nice even if I had only 8-bit Paula.
PPC native Quake was very cool though. Even if little illegal. I am sure Quake sold more PPC accelerators than anything else...
But when I think about it paying 250-300 euro for PPC accelerator maybe was not that bad... it is just funny when an accelerator board costs more than your computer is worth :-)
-
It was the way forward, McEwen knew it, and rejected it. Perhaps an act
of big-corporation tampering. All other things you mentioned about Amithlon,
would have turned out quite different, with some minimal financial support for the project, which was on the precipice of greatness.
Well what was used in initial release was an emulation box with not a single library improved, just some CGX AHI drivers for PC stuff and very few and buggy ones. I don`t say that project didn`t have potential, but there is nothing to be found but few user updates that made things less buggy and more usable, but soon the pace of PC hardware has left any PC that could use Amithlon as anceient history.
From AmigaHistory Amithlon page
The emulator, developed by Bernd Meyer, is based upon the authors' experience with the WinUAE JiT emulation, but features some dramatic changes to increase emulation speed (at the loss of compatibility). The slim-line ISOLinux distribution is used to boot directly into the Amiga emulation, removing the need for users to interact with a host operating system. This simple, yet effective change resulted in many users favouring Amithlon over AmigaOS XL as the emulation of choice.
So its kind of myth its complete x86 port.
Similar approach was AmigaOS XL
or this Linux driven UAE called Xamiga
http://www.amiga.org/forums/archive/index.php/t-27682.html
These are just different approaches to emulation on 68k at time x86 JIT was not so fast and PC`s were not such grants that they could emulate high end Amiga with ease as today.
Interesting was that all this effort was made to make 68k AmigaOS emulated look like it really went PowerPC. As NovaDesign says at that time:
Unlike the slow versions of WinUAE and WinUAE JiT, AmigaOS XL forgoes on the chipset emulation, using the extra processing cycles to emulate the processor. The result is an Amiga emulator capable of running 68k applications between 5 - 10 times faster than a 68060 system. According to SysInfo (an Amiga benchmark utility), a 1 GHz AMD Athlon emulates an Amiga equivalent to a 450 MHz 68040. The benchmark was supported by Kermit Woodall of Nova Design, who tested one of their applications:
"We installed ImageFX on AmigaXL during a private meeting in St.Louis and the speed was amazing.
It was like having ImageFX completely native on a fast PowerPC machine!!"
Kermit Woodall, Nova Design
-
What applications? Unless you mean games, do you?
Anything using native UI is fail. Software like IBrowse/PPC was not an option.
Nevertheless PPC boards were expensive doorstops. Fast 68060 accelerator boards would have been much better investment.
Well, there were quite a lot software supporting PPC use, as well as small libs, datatypes etc. For some time PPC saved the day, but it was short breathed as newer PPC cards never appeared, new PPC Amigas didn`t made it and MorphOS as first PPC AmigaOS took a lot of time to develop with new first real PPC only apps that would utilize 603/604 to the max.
Well, there were PPC cards with 060 where at that time (before MOS and OS4) card with slower PPC (low end 603) and 060 performed quite better because of OS 68k dependency then card with 040 and high end 604. Surely, with MorphOS and OS 4.0/4.1 that "table has turned"
And yes - first thanks to MOS! for first trully native PPC apps and games.
My belief would be that AmigaOS today would be far more advanced if it was based on latest MOS 1.x or MOS 2.x whatever was there in 2002-2004, instead of starting from AmigaOS 3.1 bare recompile and execSG. Not that I DO praise Hyperion for all the good work, but AmigaInc made wrong descision at that time prolonging PPC development, as well as later with court case, MacMini port and SAM restrictions, inability to find partner to continue AmigaOne series etc.
Even that (as promised) first OS 4 was just simple PPC recompile, it would take a lot of extra work OS4 team has done later on (OS 4.0 was way far away from its humble simple promises)
Compare
http://en.wikipedia.org/wiki/AmigaOS_4#AmigaOS_4.0_.28The_Final_Update.29
to
http://www.intuitionbase.com/os4features.pdf
-
And 'zip' and 'unzip' versions on the PPC really fly compared to the 68K version... I'd say a factor 10x speedup. If I ever figure out how I'll recompile a nice version of LHA and ZIP for AmigaOS 3.x and WarpOS.
Saw your thread on EAB :). Go mousehouse, we want more PPC-optimized tools & utils :)!
-
But when I think about it paying 250-300 euro for PPC accelerator maybe was not that bad... it is just funny when an accelerator board costs more than your computer is worth :-)
Could never afford them at the time (Serbian economy was crippled too at the time) but waiting made two things possible: both hardware to advance to new and faster solutions and software to get fully PPC and more feature rich. But after the court case, newer incarnations of Amiga Inc lost even the OS4 and finally aliniated itself from anything remotely close to Amiga. Possibly because in process they lost the rights to use AmigaOS, didn`t payed the Hyperion for its work and didn`t provided OS 3.9 code as assumed in original plan.
A very good acrhieve of AmigaInc history until the newest CUSA/iCoin saga and court case is avail here https://sites.google.com/site/freeamiga/
(author SHOULD add the new events spice!)
Problem is that all app and game development software houses didn`t have that kind of patience in shrinking market situation.
Hope its visible how clearly PPC Amiga boards are part of Amiga evolution in both software and hardware, and its sad CUSA just tries to erase that part of history on its Amiga history (and own ego) representation under capitalist motto "Why would we promote someone elses product"? Because you try to mimick to be part of it. Same backfire would be "Why would we allow promotion of your product?" anywhere - but yet it is allowed.
So there I see quite of double standard.
And even today if mass produced (ordered) PPC chips could be affordable and fast enough for some last MacOS X, maybe ReactOS, Android, Linux, MOS and AmigaOS 4 - but CUSA likes to play on what`s easily avail and sure and not to really invest in R&D. And nuff about rebranders of everything including Amiga name.
Hope that it was nice educational voyage :-)
-
I guess you never used Oxyron Patcher. It is best installation any 68060 can do. It speeded everything - games, demos, utilities, gave more compatibility.
No 68040 can beat 68060 with Oxyron in any test.
Oxyron Patcher Benchmarks (http://www.vesalia.de/d_oxyron.htm)
Its 20 euros today
http://amigakit.leamancomputing.com/catalog/product_info.php?products_id=780
Could it help 68k emulation or Natami in any way? :-)
-
Its 20 euros today
http://amigakit.leamancomputing.com/catalog/product_info.php?products_id=780
Could it help 68k emulation or Natami in any way? :-)
Okay, at the risk of going on an OT tangent, what is the difference between Oxyron and OxyPatcher?
-
@itix: it was ok as a temporary solution. The thing is the port of the OS to PowerPC took a lot longer than expected (I remember the fancy roadmaps published by Hyperion,... showing it would take a year or two :))
-
@itix: it was ok as a temporary solution. The thing is the port of the OS to PowerPC took a lot longer than expected (I remember the fancy roadmaps published by Hyperion,... showing it would take a year or two :))
no. it was not. it scared the rest of the remaining users away. me amongst others. pretty much like x1k today only on even smaller scale.
-
The reason I asked this very question is that I've got plans (read "pipe dream" if you know me well enough) to make an ARM based accelerator card for A1200, using Freescale i.MX series CPU, and 68k emulator in flash ROM.
I think it's possible, considering a Blizzard 1260 goes for £500 on ebay...
-
Okay, at the risk of going on an OT tangent, what is the difference between Oxyron and OxyPatcher?
Oxy is short for Oxyron - no difference.
There was however a CyberPatcher that did the kind of same or similar and came with Blizzard cards. Anyway, interestingly it software patched missing instructions from 040 and 060 that existed in 00-030 and that had to be emulated (=slow)
-
@itix: it was ok as a temporary solution. The thing is the port of the OS to PowerPC took a lot longer than expected (I remember the fancy roadmaps published by Hyperion,... showing it would take a year or two :))
Well, first OS4 developer realise was posted on 16 April 2004
http://amigaworld.net/modules/news/article.php?item_id=1387
But it took longer way to final version that provided more functionality then promised.
Bigger problem was that Mai Logic AmigaOne board ceased production meanwhile and Eyetech died (=there was no hardware on sale at time of release) and first OS 4.0 didn`t support PPC equipped Classics.
For PPC Classics, OS 4.0 came on November 2007, about 10 years after these cards were made.
-
So what you guys are saying that do not waste your money buying a PPC card for the Amiga 1200, that instead the best investment on an Amiga 1200 for an upgrade is either a 68040 or a 68060 and that is that? Are you guys saying that if I wish to go PPC in Amiga that it should be either a SAM or the new Amiga hardware other than that the Amiga 1200 PPC are waste of money and useless?
-
So what you guys are saying that do not waste your money buying a PPC card for the Amiga 1200, that instead the best investment on an Amiga 1200 for an upgrade is either a 68040 or a 68060 and that is that? Are you guys saying that if I wish to go PPC in Amiga that it should be either a SAM or the new Amiga hardware other than that the Amiga 1200 PPC are waste of money and useless?
If using Classic games and software is the key - PPC card is not needed, 060 is cheaper solution. But Natami when out will be the best experience.
Yes, if you want to use OS 4.1 even maxed out A1200 or A4000 with PPC cards is way too slow compared to slowest SAM 440 (however SAM 460 would be recommended). If you want to use MorphOS, proper MacMini G4 is the way.
So, yes to both. Blizzard cards are today very rare and quite overpriced for what they offer.
-
The reason I asked this very question is that I've got plans (read "pipe dream" if you know me well enough) to make an ARM based accelerator card for A1200, using Freescale i.MX series CPU, and 68k emulator in flash ROM.
I think it's possible, considering a Blizzard 1260 goes for £500 on ebay...
sure, but forget about these clumsy multiprocessor designs. the best would be an arm cpu starting emulation from flash and then starting the system under emu. but isnt there some obstacle, like some expected memory layout in low address space not available on other than 68k cpus?
-
Hello this might be a bit off topic but I just wanted to say that I really love my ppc card and never regret buying one a few years ago. Sure, there isnt much classic (os3) software that utilises the cpu, but just for the Bvision alone its well worth the cash. And hey, OS4 isnt half bad either.
-
I had BPPC+BVision with PPC native JPEG datatypes and mpega.library installed but that is all. Few games (often buggy) and few demos didn't really justify investment.
Later I got chance to run MorphOS 0.x on it but in the end it was just waste of money.
I think culmination point was when I tried PPC native Unzip program that was slower than 68k native Unzip on my lousy 68040 @ 25 MHz.
Well if you don't want any of that old hardware, go ahead and throw it my bin. I'd like another OS4.x compatible classic. :)
-
PPC native picture datatypes were nice but they were slower than 68k counterparts for small images. Still fast enough to replace 68k datatypes on my system where possible.
That's a bit over simplistic. Well-written code could use 68K where the cache flush overhead of invoking the PPC becomes too significant for something like decoding a small image. Not sure how many datatypes did that, but I experimented with patching things CopyMem() on my A1200 and used PPC for large copies (those bigger than 2x the combined cache size). Of course, most copies are too small to benefit, but synthetic tests validated the concept.
Video players on Amiga were always outdated and could display only few formats. And often my BlizzardPPC @ 160MHz was not fast enough to play videos at full frame rate.... PPC accelerated MP3 players were nice even if I had only 8-bit Paula.
Well, I was luckier in that my PPC was 240MHz, but my 040 only 25. The gulf in performance between the two is pretty conspicuous. At least one of the PPC players for 3.x was capable of using cgxvideo.library on my BVision. The Permedia2 doesn't have any video acceleration per se, but it does allow YUV textures to be scaled and painted onto trapezoids (judging by the occasional diagonal shear when not vsynced, it would seem this is exactly how it worked).
PPC native Quake was very cool though. Even if little illegal. I am sure Quake sold more PPC accelerators than anything else...
But when I think about it paying 250-300 euro for PPC accelerator maybe was not that bad... it is just funny when an accelerator board costs more than your computer is worth :-)
Well, one can slam the old PPC boards, but ever since fully PPC native operating systems have worked on them, they've shown that they are capable of giving a significant boost in performance over 68K when not shackled down by the old context switch mechanisms necessitated by the dual processor approach. My PPC board can run almost all my 68K classic software faster on OS4.1 than my 040 could, sometimes by a wide margin. The next generation of PPC accelerator cards from phase5 were set to be PPC only.
-
Ok so I know the PowerPC accelerators for classic Amigas have both a PPC chip and a 68040 on board, but when does the PowerPC chip come in and how does it know? Does a program have to run on the 68k at first (like a bootstrap) and then trigger some kind of switch, throw an exception, or call a library function or something?
I had a blizzard 603e PPC 240/060. I had problems getting the PPC to run stable in the desktop case. It would run stable in a PAWS case interestingly enough, but I never could get the LCD of the PAWS working. I ended up towering the system and eventually added the g-rex PCI bussboard and a Voodoo-III.
Honestly the PPC experience was underwhelming. I recall having some datatypes (that made browsing fast) and was able to play mp3s on the PPC. In the early days most PPC apps I tried would instantly crash. I did know the PPC worked though as I could run that supplied voxel terrain demo. Otherwise I was starting to think I had been duped on a bad card :) Stability did get better, but being in the middle of that whole WarpUp/PowerUP saga watching that unfolded(compatibility wrappers, bickering, etc.) was enough for me. I never could get smooth frame-rates on those Hyperion ports.
I was able to utilize the PPC with a Shapeshifter video driver that made AGA run really quickly, but I think the MMU drivers I run now are probably almost as fast. The worst I was waiting and waiting for Fusion PPC to work with the Blizzard PPC. I don't know if that ever happened.
This time around I have a nice 1200D/060 :) I really don't miss the PPC experience. I had one of the faster PPC cards as well, so I could imagine one of the slower ones would be even more disappointing.
I do feel that comparing the 1200D I have now to that 1200T (with all the PC parts) I had is like comparing Darth Vader to Anakin. And the bloodshot puffy eyes(that no longer see for themselves) are the AGA chips...
-
Well if you don't want any of that old hardware, go ahead and throw it my bin.
I sold it many years ago :-)
-
and didn`t provided OS 3.9 code as assumed in original plan.
Oh, you can blame Haage & Partner for that...
Problem is that all app and game development software houses didn`t have that kind of patience in shrinking market situation.
For companies staying with Amiga was only waste of time. The market was not growing at all while other platforms were booming.
And even today if mass produced (ordered) PPC chips could be affordable and fast enough for some last MacOS X, maybe ReactOS, Android, Linux, MOS and AmigaOS 4 - but CUSA likes to play on what`s easily avail and sure and not to really invest in R&D. And nuff about rebranders of everything including Amiga name.
Commodore didn't choose 68000 because they wanted to make Motorola big. Motorola was already big and successful with their 68000.
This is how it should work with PPC chips. Freescale and AMCC make it big. Freescale have been trying it very hard but I guess they are failing...
Nevertheless the market situation is not in our hands. If CUSA is scucessful with their products, good for them. If not, I still dont care.
I enjoyed MorphOS on my Amiga 1200 with BlizzardPPC and I still enjoy it on my Mac mini, Efika, everything. Even if I consider BPPC/CSPPC ddin't deliver what I expected in 90s.
Hope that it was nice educational voyage :-)
Thanks :-)
-
Oh, you can blame Haage & Partner for that...
Well, since OS 3.9 just couldn`t make that much revenues, they could donate source code. Even today OS 4.1 misses some small features of OS 3.9 and it took significant time to catch up from PPC 3.1 code to all 3.9 features and beyond
For companies staying with Amiga was only waste of time. The market was not growing at all while other platforms were booming.
True, Freescale did it at Apple PPC times, IBM with consoles, but sadly AmigaOS just missed those times (even making OS4 work on a bit older PS3 that allow OS would be like X1000 for everyone alongside great Yellow Dog Linux, but yet they choose Acube/A-EON Alliances)
Nevertheless the market situation is not in our hands. If CUSA is scucessful with their products, good for them. If not, I still dont care.
In my own opinion, if something kills them it will not be angre me: it will be their own stupid strategies, announcements and choices: like one to move Amiga line to "PRO" category and compete with most expensive PCs
I enjoyed MorphOS on my Amiga 1200 with BlizzardPPC and I still enjoy it on my Mac mini, Efika, everything. Even if I consider BPPC/CSPPC ddin't deliver what I expected in 90s.
To me it was like puting ferrari engine in old Fiat 500 ... :-)
But it worked, lived and allowed MOS to develop as well as pathway for decision to make OS4 PPC
Thanks :-)
It is good to serve this small community. Sadly, low number of users goes with slow SW development and weird HW prices and avaliabilities, but we managed to live with it