Amiga.org
Amiga.org specific forums => New User Introductions => Topic started by: Templario on December 04, 2010, 04:01:49 PM
-
Hello friends this is my first Thread, thanks to Karlos and his help, thank you friend!
-
As this thread isn't really news, I've moved it to "new user introductions" ;)
-
Hello friends this is my first Thread, thanks to Karlos and his help, thank you friend!
So you weren't kidding... :lol:
Well done... now say something... :)
-
Hello friends this is my first Thread, thanks to Karlos and his help, thank you friend!
are you here cause being restricted for this week on aw.net? ;P btw. was really not nice to call *such* names over there..
-
I just wanna know which one of the characters in your avatar you are! The half naked chick blowing a kiss or the tiny knight? :lol:
-
are you here cause being restricted for this week on aw.net? ;P btw. was really not nice to call *such* names over there..
yeah and not, is true that I have restricted in AW, but also is true that I'm in this forum but the restriction has encouraged me to ask how put one thread, but also you can find mein other Amiga forum, and about the restriction is incredible, because isn't the first time that I speak to join AmigaOS4 and MorphOS, join forces and resources, but is the fist time that to one MorphOS user feels offend for this same words, a only PPC OS, called as the people wants, but with one only purspose to avoid spend our time develop programs for two systems, or reporting games and programs in both sides, this works will be more useful working together, with much more ideas, tricks, etc., but this is an inconvenient for some users, as the user that I dedicated the word fa... because of his words.
In this times we need work togethers and not in two ways, is good AROS for X86 as only system for this machines, and Amiga OS3.5-3.9 with AfA_OS and other patches for 68k machines. Why not the same in PPC?
-
I just wanna know which one of the characters in your avatar you are! The half naked chick blowing a kiss or the tiny knight? :lol:
I know which one I'd prefer... ;)
Ere.. Templario, have you been a naughty boy/girl over on AW... :)
-
I just wanna know which one of the characters in your avatar you are! The half naked chick blowing a kiss or the tiny knight? :lol:
The Templar Knight of course, the lady is for the "beauty and the beast", and she doesn't launch a kiss, she give a rreath of life to this knight.
-
I just wanna know which one of the characters in your avatar you are! The half naked chick blowing a kiss or the tiny knight? :lol:
Only it seems on the Amiga sites I visit many dudes have hot woman as their avatars. Often makes me think they are woman but knowing the percent woman to men that are computer nerds are normally men, I know it must be a dude.
So, I say the Knight. :hammer::hammer:
tj
-
Congratulations on your first thread Templario
:drink:
-
...In this times we need work togethers and not in two ways, is good AROS for X86 as only system for this machines, and Amiga OS3.5-3.9 with AfA_OS and other patches for 68k machines. Why not the same in PPC?
hi Templario, you will soon find out that it's best to not talk too much about AmigaOS4.x on this site anymore unfortunately...just a friendly word of warning
-
Hello thread.
Oh, and don't let anyone bully you into not talking about AmigaOS 4 if you want to talk about it.
-
hi Templario, you will soon find out that it's best to not talk too much about AmigaOS4.x on this site anymore unfortunately...just a friendly word of warning
Nonsense. It's fine to talk about OS4, just don't expect everybody to share your enthusiasm for it. The only points to note is that the Operating Systems Specific Discussions (http://www.amiga.org/forums/forumdisplay.php?f=47) section does not have an OS 4.x specific sub-forum (actually, there is a one for 4.x compatible hardware discussion). AmigaOS is considered to be everything from 1.x to 4.x inclusive. Likewise, MorphOS is not split into 1.x / 2.x sub-forums and AROS is not split into distro-specific sub-forums.
-
I saved for years to get a CSPPC to go in an A4000 and then waited more years for OS4 to finally come out. I would be shocked and surprised if it couldnt be talked about here at A.org of all places :(
-
I saved for years to get a CSPPC to go in an A4000 and then waited more years for OS4 to finally come out. I would be shocked and surprised if it couldnt be talked about here at A.org of all places :(
You can talk about OS4 here, I have done so in the recent past and still say OS4.0 is slower than my grannie on a bad day taking her one legged tortoise for a walk... :)
-
You can talk about OS4 here, I have done so in the recent past and still say OS4.0 is slower than my grannie on a bad day taking her one legged tortoise for a walk... :)
Well that's a relief Franko :) I think that was my first ever post ending with a sad smilie. I was here cheering with everyone else as the countdown to OS4's release was underway and hoping that my copy was next in the post from AmigaKit. I don't know if those threads still exist after the change over, but they were very exciting times :)
Oh, and tell your grannie to just glue the tortoise to a roller-skate ;)
:drink:
-
Oh, and tell your grannie to just glue the tortoise to a roller-skate ;):
Ah cannay she's been deed fur aboot 30 years and tortie passed oan aboot six years ago (he made a nice ashtray though... :))
-
Nonsense. It's fine to talk about OS4, just don't expect everybody to share your enthusiasm for it. The only points to note is that the Operating Systems Specific Discussions (http://www.amiga.org/forums/forumdisplay.php?f=47) section does not have an OS 4.x specific sub-forum (actually, there is a one for 4.x compatible hardware discussion). AmigaOS is considered to be everything from 1.x to 4.x inclusive. Likewise, MorphOS is not split into 1.x / 2.x sub-forums and AROS is not split into distro-specific sub-forums.
I really wish it was nonsense....anyhow I hope the OP finds my comment to be nonsense too
-
You can talk about OS4 here, I have done so in the recent past and still say OS4.0 is slower than my grannie on a bad day taking her one legged tortoise for a walk... :)
time to upgrade from that 2MB of Ram, pre-release of OS4.0 and make the poor tortoise a go-kart:)
-
I really wish it was nonsense....anyhow I hope the OP finds my comment to be nonsense too
Well, in my experience it is. There's no amiga.org bias to/against OS4, MorphOS, AROS or classic. Any perceived bias is merely a reflection of us, site members. Discussion of any and all is welcome.
-
time to upgrade from that 2MB of Ram, pre-release of OS4.0 and make the poor tortoise a go-kart:)
Blizzard060/PPC 60Mhz/240Mhz 256MB RAM Full OS4.0 including the one and only update, RESULT = One dead grannie & one dead tortoise (both still more useful & faster than OS4.0)... ;)
-
Blizzard060/PPC 60Mhz/240Mhz 256MB RAM Full OS4.0 including the one and only update, RESULT = One dead grannie & one dead tortoise (both still more useful & faster than OS4.0)... ;)
I was almost ready to go and buy a copy for my (currently) non-RTG A1200, but if it's really that bad I might pass. I wonder if they ever put out a demo version.
-
I was almost ready to go and buy a copy for my (currently) non-RTG A1200, but if it's really that bad I might pass. I wonder if they ever put out a demo version.
Your far better off with the dead grannie & tortoise option, bit smelly but much more fun... :)
-
I was almost ready to go and buy a copy for my (currently) non-RTG A1200, but if it's really that bad I might pass. I wonder if they ever put out a demo version.
I'd say thats exactly the reason why there is no demo version....
@templario
The reason why you ended up restricted on that other side is that your english is just good enough to encourage severe misunderstandings (your orginal comment surely looked like a not-so-clever attempt at trolling). Now that was bad enough, but calling another user a facist should have gotten yourself more than just one week (atleast in my book).
-
On the flip side of the coin, I've used OS4.0 on the same 240MHz 603 with 256MB, motherboard IDE and basic PCMCIA network and just vanilla AGA.
It works fine provided that you apply the same common sense you do to 3.x and remember that just because you are now using a CPU with up to 5-10x the clock speed of your 68K, your native chipset is no faster than it ever was:
1) You stick to the same rules you use for native displays that you do under 3.x. That is to say, don't use 256 colour dblPAL modes and the like. I ran a flicker-fixed 16-colour PAL laced display and it was fine.
2) Turn off all the gradient fills and related candy. They are designed for RGB mode displays. Hence they don't look so hot on a 16 colour display anyway and they do slow down rendering.
3) Turn off solid window moving/sizing. AGA/ECS is no faster than it was under 3.x.
4) Don't use anti-aliased fonts, for the same reason as (2).
5) Replace the default 4.x RGBA icon set with icons from 3.x. Again, they are designed for real RGB displays, not indexed colour modes on planar hardware.
If you apply these simple steps, you will find that far from being as slow as a tortoise, it's perfectly usable. OS4 cannot make your AGA display go faster and the default installation is heavily biased towards RTG.
Of course, just like OS3.x, the experience on RTG is much improved.
-
@ Karlos
I tried those setting as you'd already explained them in an earlier post, but honestly it was still way too slow for me. It's just my own personal opinion on OS4.0, if other folk want to give it a try then don't be put off by my opinion, give it a try at least then decide. :)
Biggest gripe I have with OS4.0 is Hyperion released it, I bought it brand new, then they only ever released one update for it before abandoning all support for it after only a few months... :(
-
I'm not disputing your experience of it, I'm just providing some balance. Those settings worked fine for me, 256 colours / solid moving / gradient filled / antialias font / ARGB icon stuff made the system very slow. Ditching those, corrected the problem.
Other things that may help are editing the kicklayout to remove unwanted modules and using SFS rather than FFS, but I don't know if that applies to your situation or not.
I certainly dispute the claim it was as fast as a "chip ram only" machine that you made previously, I mean if that's not exaggeration then there had to be something seriously wrong somewhere. Running 3.x my 040 on just chip ram is insanely slow.
-
I'm not disputing your experience of it, I'm just providing some balance. Those settings worked fine for me, 256 colours / solid moving / gradient filled / antialias font / ARGB icon stuff made the system very slow.
I certainly dispute the claim it was as fast as a "chip ram only" machine that you made previously, I mean if that's not exaggeration then there had to be something seriously wrong somewhere. Running my 040 on just chip ram is insanely slow.
Before I tried the settings you gave I stick by my chipram statement, the settings you give does improve the speed to a reasonable level, but still too slow for my liking.
Think I'm so used to running a highly optimised set up under OS3.5 on the 060 side that anything seems slow in comparison... :)
-
Try running your 68K only setup without any PPC datatypes, media players or anything like that. You may have gotten used to your PPC doing some of the lifting in the background that you forgot about.
-
I remember my first thread....
-
I remember my first thread....
I think I remember mine...
In fact, it might even have been to do with threads...
-
I'd say thats exactly the reason why there is no demo version....
@templario
The reason why you ended up restricted on that other side is that your english is just good enough to encourage severe misunderstandings (your orginal comment surely looked like a not-so-clever attempt at trolling). Now that was bad enough, but calling another user a facist should have gotten yourself more than just one week (atleast in my book).
Is the second time that a commnet about MorphOS is "misunderstanding" my bad english in other cases don't give me so problems as when I speak about that OS.
-
I think I remember mine...
In fact, it might even have been to do with threads...
:lol: I think I found it: http://www.amiga.org/forums/showthread.php?t=525 (http://www.amiga.org/forums/showthread.php?t=525)
Certainly not my first post, but I think the first thread I created. Sure enough, it was thread related, too.
-
:lol: I think I found it: http://www.amiga.org/forums/showthread.php?t=525 (http://www.amiga.org/forums/showthread.php?t=525)
Certainly not my first post, but I think the first thread I created. Sure enough, it was thread related, too.
I just necromanced it for old times sake. :lol:
-
Before I tried the settings you gave I stick by my chipram statement, the settings you give does improve the speed to a reasonable level, but still too slow for my liking.
Think I'm so used to running a highly optimised set up under OS3.5 on the 060 side that anything seems slow in comparison... :)
So how does MorphOS (http://powerup.morphos-team.net/) for BPPC compare to OS4 in your esteemed opinion Frank? :)
-
One of my first threads (http://www.amiga.org/forums/showthread.php?t=4063)
I even received some advice from HGC himself! I'd lurked for quite a while before joining, pretty much joined to get some help with the A2000 I'd just picked up.
-
@ Karlos
Try running your 68K only setup without any PPC datatypes, media players or anything like that. You may have gotten used to your PPC doing some of the lifting in the background that you forgot about.
I never use datatypes (worst thing ever invented for 68K). On the 68K side of things I have no PPC software that does any background processes, the only time the PPC gets used is for encoding MP3s (Lame), playing MP3s (SongPlayer) and the Frodo C64 emulator and on the odd occasion viewing some PDFs, everything is else is in standard 68K or 060 where possible. (seems pretty pointless having a PPC now when I look at it...) :)
@ nicholas
So how does MorphOS for BPPC compare to OS4 in your esteemed opinion Frank?
I never use any MorphOS progs prefer the plain vanilla PPC code anything I've tested, for example Lame or Frodo run much faster and better using plain PPC when compared to their MorphOS counterparts, so for me MorphOS on my A1200s is a big no no.... :)
And before you all jump on my head saying I must be doing this wrong or that wrong, the answer is no I'm not. 25 years of using the Amiga on a daily basis has led me to carry out extensive tests to find the best & fastest possible set ups for my hardware using either software available or writing my own which I'm happy with... :)
PS: This threads meant to be Templario's introduction not a debate on OS 4.X, PPC's or when did you first post a thread, apologies to Templario for the hijacking of your thread... :)
-
I never use datatypes (worst thing ever invented for 68K).
Erm, since when did you have the choice? In OS3.x, <> alone uses datatypes for all image and sound decoding.
I never use any MorphOS progs prefer the plain vanilla PPC code anything I've tested, for example Lame or Frodo run much faster and better using plain PPC when compared to their MorphOS counterparts, so for me MorphOS on my A1200s is a big no no.... :)
Ok, just so we are clear, you've actually tried MorphOS 1.4.x (or possibly an earlier version) on your BizzardPPC and found native applications for it to be slower than their basic WOS/PUP versions under OS3.x?
PS: This threads meant to be Templario's introduction not a debate on OS 4.X, PPC's or when did you first post a thread, apologies to Templario for the hijacking of your thread...
I don't think he'll mind, it was a test thread to make sure he knew how to do it, not a formal introduction.
-
Ok, just so we are clear, you've actually tried MorphOS 1.4.x (or possibly an earlier version) on your BizzardPPC and found native applications for it to be slower than their basic WOS/PUP versions under OS3.x?
You see, I only ask, because on my MorphOS 1.4.5 installation disk's MorphOS.readme file it states:
$VER: MorphOS.readme 1.4.5 Release 4 (6.6.2006)
Hardware supported:
-------------------
- Amiga4000, 4000T with phase5 CyberStormPPC
- Amiga3000 with phase5 CyberStormPPC
- Amiga1200 with phase5 BlizzardPPC
- Grex PCI slots
Graphic cards supported:
------------------------
- Voodoo3/4/5 (with GRex)
- SiS6326, SiS305 (with GRex)
- Permedia2/Permedia2v (either BVisionPPC, CyberVisionPPC or GRex)
- PicassoIV (68k driver)
- CyberVision 64 (68k driver)
- CyberVision 64/3D (68k driver)
AGA chipset is NOT supported.
So, fine on the BlizzardPPC side, but you've said a few times you have no RTG card at all. I was just wondering what you were using for your Ambient/Workbench/ display, given that according to the last line cited above, AGA isn't actually supported.
(http://extropia.co.uk/xwf_web/images/em/O_o.png)
Obviously if the MorphOS team have added that line in error, they should be informed.
-
@ Karlos
I know iprefs use the ruddy useless things (datatypes) I was meaning for viewing GFX or playing audio, I prefer to use a dedicated util for such things.
I've never read much of the docs for MorphOS and can't tell you which versions I tried as I deleted them all a long time ago, yep still no RTG board.
Most of the time I run a plain old 640 x 256 128 colour screen for Workbench and for GFX or DTP (ImageFX, DPaint, Pagestream, Final Writer etc..) I usually use 640 x 512 or higher.
Quick example of Lame V3.92, encoding an MP3 (10 seconds Audio)
Plain PPC = 31 seconds
MorphOS = 46 seconds
FrodoC64 emulator
Plain PPC Version = full screen GFX, full framerate + Audio
MorphOS Version = Window on Workbench no option for full screen/ skip every 2 to 3 frames (depending on game) No Audio
All I know is after years of testing I have found the best way for me to get every bit of speed I can out of my set up and tried all sorts things and different versions of various software along the way, but as I've said before I've disassembled a lot of stuff along the way and optimised it for my own use including the roms. I know from helping out others over the years unless your using the exact same set up as me then the way my miggies are set up you'd never get be able to get the same speed or use some of the modified code I use... :)
-
I've never read much of the docs for MorphOS and can't tell you which versions I tried as I deleted them all a long time ago, yep still no RTG board.
...
MorphOS Version = Window on Workbench no option for full screen/ skip every 2 to 3 frames (depending on game) No Audio
Erm, ok... You know how I wasn't convinced about the OS4 being as slow as you made out? I have to say I am just an incy bit sceptical now too...
It's the fact you were able to run it in a "Window on Workbench", on MorphOS without a supported display mode. The mind boggles. How did you persuade it to open an AGA mode in the first place?
-
@ Karlos
Dunno to be honest, as I say I never read much of the docs just installed (as far as I remember) the MorphOS stuff my sister downloaded for me years ago along with some utils from places like Aminet and a lot of hacks that were available on CD Magazine I used to subscribe to (100% Amiga it was called) and gave it a go.
Never knew it wasn't meant to support AGA and from the few things I tried plain old PPC version won out on speed tests so I stuck with that and spent years optimising my system to get the best out of a combination of 68k, 060 & PPC... :)
-
I remember my first thread....
http://voicesofaorg.extropia.co.uk/
Awwwwww... mel_zoom sounds as lovely as she looks :)
@ Karlos & Franko
Keep up the OS4/PPC/MorphOS chat please guys as it's very interesting :drink:
-
@ Karlos & Franko
Keep up the OS4/PPC/MorphOS chat please guys as it's very interesting :drink:
Well, I can see I am going to have to revisit my 1.4.5 installation and possibly one or two older versions, because other than the odd game or demo that took over the native hardware, I never got it to open an intuition screen under AGA.
-
Well, I can see I am going to have to revisit my 1.4.5 installation and possibly one or two older versions, because other than the odd game or demo that took over the native hardware, I never got it to open an intuition screen under AGA.
Weren't the early MorphOS incarnations patches onto the OS3.x installation? I seem to (vaguely) remember that MorphOS was developed kinda piecemeal, requiring significant chunks of OS3.x in order to function. Perhaps Franko tried an early 0.x release?
@Franko - you're not thinking of PowerUP (rather than MorphOS) are you?
-
@ Karlos
BIG OOOOPPPSSS...
I couldn't get to sleep earlier this morning as I wondered why you had said it was not AGA compatible, so I dug out an old HD that I had used the alleged MorphOS on, now I know you'll laugh but... erm... with all the posts & threads I've been reading recently about AROS and MorphOS, I think MorphOS must have somehow been engrained on my brain cell and I've made just a teeny weeny wee totey smidgen of an error here... but it was WarpOS I was actually talking about and not MorphOS (sound a bit the same, dont they)... :o
So apologies for any confusion caused and hopefully I won't get lynched by the MorphOS crowd, simple mistake really, any numptie could have made... :o
(PS: I blame nicholas for inserting his post inbetween posts with the word MorphOS in it... :))
(so with regard to the above posts please read WarpOS and not MorphOS and direct all comments and complaints to care of : nicholas...) :)
Oh... someone's at the front door, sorry gotta go now...
-
@Karlos
I assume he was useing one of the really really old MorphOS-Betas from 2001 (0.4 or so). Those had no Ambient and AFAIK they also worked on AGA.
-
@franko
I did wonder if you meant WarpOS as it does sound superficially similar to "MorphOS", but you seemed quite insistent.
@kronos
I can't even remember getting that version working at all, let alone on AGA.
-
@franko
Now that this MOS/WOS mystery has been put to rest, what's your specific beef with datatypes?
I'm a bit surprised to hear them referred to as the "worst thing ever invented for 68K". How is a modular system of file descriptors and corresponding codecs that allows applications to open new formats they couldn't support previously a bad thing?
If anything, my only criticism of them has been that their implementation did not run far enough, support for exporting data in a particular format was often overlooked. As an import mechanism, however, they are incredibly useful.
-
MorphOS/WarpOS, Datatypes/Bagpipes?
..nah.
-
@franko
Now that this MOS/WOS mystery has been put to rest, what's your specific beef with datatypes?
I'm a bit surprised to hear them referred to as the "worst thing ever invented for 68K". How is a modular system of file descriptors and corresponding codecs that allows applications to open new formats they couldn't support previously a bad thing?
If anything, my only criticism of them has been that their implementation did not run far enough, support for exporting data in a particular format was often overlooked. As an import mechanism, however, they are incredibly useful.
Just having my breakfast right now... :)
I'll get back to you on all things wrong with Datatypes shortly... :)
(At least I can't mix up DataTypes with anything else... :))
-
@ Karlos
I tried those setting as you'd already explained them in an earlier post, but honestly it was still way too slow for me. It's just my own personal opinion on OS4.0, if other folk want to give it a try then don't be put off by my opinion, give it a try at least then decide. :)
Biggest gripe I have with OS4.0 is Hyperion released it, I bought it brand new, then they only ever released one update for it before abandoning all support for it after only a few months... :(
Well clearly you need a 24 bit graphics card too when using OS4, AGA is slow compared to the basic PCI graphics cards for PC. AGA is barely faster than old ISA graphics cards which could never run any GUI that fast.
-
@ Karlos
Right then... DataTypes... where do I start... :rolleyes:
Generally, using Datatypes in comparison to a dedicated self contained util are slow in comparison... :)
The modular concept of Datatypes is another big no no for me, I prefer code to be one piece (ie: self contained) where possible and not rely on installing lots of extra libraries and other small files scattered here there and everywhere all over your HD... :(
I know so called self contained utils use various OS libraries and sometime some external ones, but these are usually contained in the ROM and not scattered all over the HD to the same extent that most Datatypes requires.
It's one of my biggest bugbears on the Amiga is a program or util that uses this so called modular approach and is not as self contained as it could be, the likes of MUI or ImageStudio for example and the hundereds of so called modules that they use scattered all over the place... :(
I reckon my reasons for disliking such things goes way back to the day's when things mostly ran from floppies and if you had 4Meg of fastram this was a luxury (MUI was totally unusable if you had no HD). This was when I first began coding in 68k and I followed the path of what most coders were doing back then, make your prog as small as possible, self contained as much as possible and to run on as basic a system as much as you could.
I know those constraints don't apply as much today, with almost everyone having HDs, plenty of extra ram & accelerators, but it's just a habit and method that has stuck with me to this day. I very rarely use Workbench to do anything and operate mainly from the Cli/Shell and a customised version of DirWork that I made cos I don't like Dopus that much either, but thats another story... :)
-
@ Karlos
Right then... DataTypes... where do I start... :rolleyes:
Generally, using Datatypes in comparison to a dedicated self contained util are slow in comparison... :)
That depends very strongly on the datatype. On OS3.9, the picture.datatype is capable of using PPC for colour remapping and dithering. That made a big difference on my machine. Coupled with PPC capable datatypes for png, jpg etc. I found that multiview ended up being significantly faster than most "dedicated" 68K image viewers that were capable of viewing such formats directly (Hardly a surprise, considering the performance difference between 68040@25MHz versus 603e@240MHz).
The modular concept of Datatypes is another big no no for me, I prefer code to be one piece (ie: self contained) where possible and not rely on installing lots of extra libraries and other small files scattered here there and everywhere all over your HD... :(
The whole OS is modular and always has been. If a criticism of datatypes is that it's modular, then you might as well regard the whole OS as the "worst thing ever invented for 68K" for exactly the same reason.
Far from being scattered all over the place, datatypes live in SYS:Devs/Datatypes (descriptors) and SYS:Classes/Datatypes for the actual implementations. Client applications also require SYS:Libs/datatypes.library.
I know so called self contained utils use various OS libraries and sometime some external ones, but these are usually contained in the ROM and not scattered all over the HD to the same extent that most Datatypes requires.
Again, scattered is a big misnomer. The AmigaDOS directory structure is very well organised compared to most operating systems.
It's one of my biggest bugbears on the Amiga is a program or util that uses this so called modular approach and is not as self contained as it could be, the likes of MUI or ImageStudio for example and the hundereds of so called modules that they use scattered all over the place... :(
MUI classes and libraries pretty much live in the one place on your HD too.
I reckon my reasons for disliking such things goes way back to the day's when things mostly ran from floppies and if you had 4Meg of fastram this was a luxury (MUI was totally unusable if you had no HD). This was when I first began coding in 68k and I followed the path of what most coders were doing back then, make your prog as small as possible, self contained as much as possible and to run on as basic a system as much as you could.
I know those constraints don't apply as much today, with almost everyone having HDs, plenty of extra ram & accelerators, but it's just a habit and method that has stuck with me to this day. I very rarely use Workbench to do anything and operate mainly from the Cli/Shell and a customised version of DirWork that I made cos I don't like Dopus that much either, but thats another story... :)
You have a BlizzardPPC with 256MB of RAM on it and I strongly doubt you are still using a floppy-only system. I don't see how your criticism of stuff being "scattered" all over your HD really apply any more.
-
That depends very strongly on the datatype. On OS3.9, the picture.datatype is capable of using PPC for colour remapping and dithering. That made a big difference on my machine. Coupled with PPC capable datatypes for png, jpg etc. I found that multiview ended up being significantly faster than most "dedicated" 68K image viewers that were capable of viewing such formats directly (Hardly a surprise, considering the performance difference between 68040@25MHz versus 603e@240MHz).
Don't like OS3.9 (ask MrMoonlight about that one)... I've had enough of OS3.9 recently to last me a lifetime with that bloated piece of nonsense that is OS3.9 :)
The whole OS is modular and always has been. If a criticism of datatypes is that it's modular, then you might as well regard the whole OS as the "worst thing ever invented for 68K" for exactly the same reason.
I know, but the real workings of the OS is held in ROM and not on the HD, again that's a whole other debate... :)
Far from being scattered all over the place, datatypes live in SYS:Devs/Datatypes (descriptors) and SYS:Classes/Datatypes for the actual implementations. Client applications also require SYS:Libs/datatypes.library.
Not true, they may live in a directory but unless you've defragged the HD the actual code/data wont all be sitting happily side by side, you'll find blocks of data scattered all over the HD... :)
Again, scattered is a big misnomer. The AmigaDOS directory structure is very well organised compared to most operating systems.
Agreed it's better than most, but before you defrag your disk run something like ReOrg and see just how scattered your files in any one directory really are... :)
MUI classes and libraries pretty much live in the one place on your HD too.
I refer you to the above answers... :)
You have a BlizzardPPC with 256MB of RAM on it and I strongly doubt you are still using a floppy-only system. I don't see how your criticism of stuff being "scattered" all over your HD really apply any more.
I already said in my previous post that it doesn't apply as much these days. I haven't used a floppy in about 10 years and dumped about 4000 of them about 4 years back as I couldn't even give them away... :)
-
Don't like OS3.9 (ask MrMoonlight about that one)... I've had enough of OS3.9 recently to last me a lifetime with that bloated piece of nonsense that is OS3.9 :)
Fair enough, but you have to accept that having your PPC do all the decoding, colour conversion/reduction and dithering to support your old 68K application is a lot faster than your old 68K application doing it all by itself.
I know, but the real workings of the OS is held in ROM and not on the HD, again that's a whole other debate... :)
Not true, they may live in a directory but unless you've defragged the HD the actual code/data wont all be sitting happily side by side, you'll find blocks of data scattered all over the HD... :)
That's a pretty irrelevant statement - your system partition is only going to end up defragmented if you routinely delete and add files on it. Even then, you could be using a solid state drive, in which case our objection to fragmentation makes even less sense since seek time is totally unaffected.
My used 3.x installs tend to run entirely from RAD, btw ;) See this 3.9 screenshot (http://www.amiga.org/gallery/images/810/1_midiin.png). Notice the drive labelled "Booty" ? That's actually a RAD disk that is created on cold boot. My 3,x disk based startup-sequence opens an ASL file requester asking which image to use. There are images (basically lzx archives) from 3.0 up to 3.9 with various configurations. These are then extracted to the RAD, it is made bootable and then the system reboots.
Agreed it's better than most, but before you defrag your disk run something like ReOrg and see just how scattered your files in any one directory really are... :)
I refer you to the statements above ;)
I already said in my previous post that it doesn't apply as much these days. I haven't used a floppy in about 10 years and dumped about 4000 of them about 4 years back as I couldn't even give them away... :)
So, you agree that your objections don't really apply any more but still regard modular operating system components as a really bad idea?
Curious :)
-
Round & Round & Round we go, where it will end I just don't know... :lol:
Fair enough, but you have to accept that having your PPC do all the decoding, colour conversion/reduction and dithering to support your old 68K application is a lot faster than your old 68K application doing it all by itself.
Sound's nice in theory but to do so would require me using OS3.9 or 4.0 and me no likey that... :)
(PS: I don't like those CF drives either... :))
That's a pretty irrelevant statement - your system partition is only going to end up defragmented if you routinely delete and add files on it. Even then, you could be using a solid state drive, in which case our objection to fragmentation makes even less sense since seek time is totally unaffected.
Anything that can help to speed up the use of an Amiga even HD access to files that aren't scattered all over the shop, can only be a good thing so my statement is perfectly relevant... :)
My used 3.x installs tend to run entirely from RAD, btw ;) See this 3.9 screenshot (http://www.amiga.org/gallery/images/810/1_midiin.png). Notice the drive labelled "Booty" ? That's actually a RAD disk that is created on cold boot. My 3,x disk based startup-sequence opens an ASL file requester asking which image to use. There are images (basically lzx archives) from 3.0 up to 3.9 with various configurations. These are then extracted to the RAD, it is made bootable and then the system reboots.
I have enough memory to comfortably to run the system from RAD: but due to the fact that I'm always disassembling and rewriting code and generally hacking software to see what can be done with them, RADs not a good option for me as the aforementioned activities can corrupt it... :)
So, you agree that your objections don't really apply any more but still regard modular operating system components as a really bad idea?
Curious :)
I've already answered that one twice... :)
-
I have enough memory to comfortably to run the system from RAD: but due to the fact that I'm always disassembling and rewriting code and generally hacking software to see what can be done with them, RADs not a good option for me as the aforementioned activities can corrupt it... :)
Exactly, which is precisely why I use it as I tend to use 3.x for development and testing. I'd much rather trash a volatile and easily restored memory disk than my actual HD.
-
Exactly, which is precisely why I use it as I tend to use 3.x for development and testing. I'd much rather trash a volatile and easily restored memory disk than my actual HD.
After all that, you come back with a short two sentence reply like that, where's your gumption man... :lol:
Only kidding... ;)
I get your point about using the RAD: but when you poke about with stuff as much as I do it gets a wee bit tiresome going through all the initial bootup sequences to restore RAD again once it's been damaged. Oddly enough I've never had a major HD corruption happen (fingers crossed)... :)
-
@ Karlos
I know iprefs use the ruddy useless things (datatypes) I was meaning for viewing GFX or playing audio, I prefer to use a dedicated util for such things.
I've never read much of the docs for MorphOS and can't tell you which versions I tried as I deleted them all a long time ago, yep still no RTG board.
PowerUP MorphOS has always required a RTG card. I don't know what you've tried but it doesn't sound you have been running MorphOS.
And after reading the thread a bit, indeed you weren't. Yes, indeed WarpUP sucked.
-
I remember MorphOS 0.4 ran on AGA aswell.
-
PowerUP MorphOS has always required a RTG card. I don't know what you've tried but it doesn't sound you have been running MorphOS.
And after reading the thread a bit, indeed you weren't. Yes, indeed WarpUP sucked.
That's something I don't understand why most software for the 68k/PPC side of things on the Amiga was released in the WarpOS versions and not the vanilla PPC versions instead. As when you do any speed comparisons WarpUP versions always run slower... :confused:
Was it easier to program in WarpUP than plain old PPC (PowerUp) , I wouldn't have thought so, anyone who has ever written something in WarpUP able to clarify this... :)
-
That's something I don't understand why most software for the 68k/PPC side of things on the Amiga was released in the WarpOS versions and not the vanilla PPC versions instead. As when you do any speed comparisons WarpUP versions always run slower... :confused:
It depends. Early versions of PowerUp suffered a larger performance hit when switching between 68K <-> PPC.
On my machine, timing a round trip context from PPC to an empty 68K routine and back took around 2ms for PowerUP and 1ms for WarpOS. For context-switch heavy code, that made quite a difference. Later versions of the PowerUP kernel seemed to close that gap.
Was it easier to program in WarpUP than plain old PPC (PowerUp) , I wouldn't have thought so, anyone who has ever written something in WarpUP able to clarify this... :)
No, the same caveat applied to both: write your code to minimise context switches.
Back in those days, I wrote myself a simple library in vbcc that provided a simple multiple buffered Screen (or window with offscreen BitMap) with input handling, stream handling and other features. The implementation of the display context had a single "refresh" method, that when you invoke it, does a Run68K() call (WarpOS). The 68K code it invoked then does all the screen buffer switching and gathers all the IDCMP messages into a local buffer where keypresses were decoded into their character codes and other such things. On return, the PPC then invoked user-supplied callbacks for the buffered input events before returning completely to the callee.
In this manner, refreshing the display and processing the input events took just 2 context switches - to 68K and back. Hard to optimize it any further than that.
I saw a lot of code written in those days that just treat OS calls normal. This was in part encouraged by compilers like StormC that made it transparent. End result was code that resulted in a context-switch orgy.
-
@Franko
Haven't you actually written any PPC code for your machine? Seems an odd accelerator card to have bought for a guy that seems to hate almost everything about the platform that appeared after OS2.1. You could have gotten a faster clocked 68060 board for less than you probably paid for yours...
-
@ karlos
I've always fancied having a go at writing some PPC code, all those extra registers to play with and the challenge of mastering a new language. Only trouble is I don't know of any specific assembler package for writing in PPC.
I wouldn't want to write using C as I prefer coding in assembly, you wouldn't happen to know of an assembly compiler for writing in PPC would you... :)
Also have you ever heard of PPC680X0 from Coyote Flux, It was/is a 68K to PPC source-code convertor. I have two demo versions of this that were released in 1999 but I don't think a full package was ever released or completed (can't seem to find anything on the net about it though, the demos were found on an old 100% Amiga CD I used to subscribe to)...
Cheers
Franko
(just notice your last post, I already have a faster Blizzard060 board, the only reason I really bought the PPC one was to be able to run some PPC software like Lame and Frodo. As I found out over time there was not really that much software available to take advantage of the PPC and thought OS4.0 would do the trick, but as you know by now I still haven't found a BVision board to take advantage of this.. :))
(PS: I don't really hate OS3.5 & 3.9, just reckon they could have been written a bit better and tidied up somewhat... :))
-
I wouldn't want to write using C as I prefer coding in assembly, you wouldn't happen to know of an assembly compiler for writing in PPC would you... :)
Also have you ever heard of PPC680X0 from Coyote Flux, It was/is a 68K to PPC source-code convertor. I have two demo versions of this that were released in 1999 but I don't think a full package was ever released or completed (can't seem to find anything on the net about it though, the demos were found on an old 100% Amiga CD I used to subscribe to)...
gas (the gnu assembler) should support PPC. Personally I'd code in C though, because manually optimising code on a pipelined processor is quite hard. On a lot of recent processors it's quite hard to beat the compiler in some circumstances.
I met the coyote flux guys at a show when they were touting ppc680x0. It became free in 2004, http://www.coyoteflux.nl/ (http://www.coyoteflux.nl/) I doubt they ever made any money on it.
They were pretty crazy guys, IIRC one of them had really mad hair. Pretty unlucky too, their last project for the GBA came out just after the DS.
-
gas (the gnu assembler) should support PPC. Personally I'd code in C though, because manually optimising code on a pipelined processor is quite hard. On a lot of recent processors it's quite hard to beat the compiler in some circumstances.
I met the coyote flux guys at a show when they were touting ppc680x0. It became free in 2004, http://www.coyoteflux.nl/ (http://www.coyoteflux.nl/) I doubt they ever made any money on it.
They were pretty crazy guys, IIRC one of them had really mad hair. Pretty unlucky too, their last project for the GBA came out just after the DS.
Thank's for the info, I don't fancy learning C though as I really don't like C code and the bloated results it gives... :)
Reckon those CoyoteFlux guys must be a bit crazy to have even produced that bit of code in the first place, need to have a look on the link you gave and see if they actually finished it... :)
-
@ psxphill
Drat... the download link on the CoyotteFlux site for PPC680X0 doesn't work, I can download the source code sample files but not the actual program itself... :(
-
@Templario
Really are you restricted of aw.net for this reason? Theres so much users like extremist islamic these days.
-
@ karlos
I've always fancied having a go at writing some PPC code, all those extra registers to play with and the challenge of mastering a new language. Only trouble is I don't know of any specific assembler package for writing in PPC.
vasm would be an obvious one.
I wouldn't want to write using C as I prefer coding in assembly, you wouldn't happen to know of an assembly compiler for writing in PPC would you... :)
Also have you ever heard of PPC680X0 from Coyote Flux, It was/is a 68K to PPC source-code convertor. I have two demo versions of this that were released in 1999 but I don't think a full package was ever released or completed (can't seem to find anything on the net about it though, the demos were found on an old 100% Amiga CD I used to subscribe to)...)
Sure, I have the last trial version, but I can't say I used it much.
-
Theres so much users like extremist islamic these days.
Do you mind? Some of us take offence at that.
-
Thank's for the info, I don't fancy learning C though as I really don't like C code and the bloated results it gives... :)
I dunno, it isn't that bad. Sure you can write much more compact code in assembler if you know what you are doing but I see the real advantage of using assembler as a means for performance, rather than size optimisation.
Personally, I'd much rather develop code in C, then tune the algorithms and finally, if necessary, reimplement any bottleneck parts that would benefit (ie aren't bound by IO or whatever) in assembler.
-
Do you mind? Some of us take offence at that.
Sorry but offense for this sentence its so stupid.
-
Cheers Karlos
Found VAsm here and downloaded it, need to start studying PPC opcodes now...:)
http://sun.hasenbraten.de/vasm/index.php?view=binaries
Pity it's not an integrated package like DevPac, seems I need to use VLink and it's not 100% compatible with DevPac produced source, shouldn't be a problem though...:)
Ah well beggars can't be choosers...:)
-
Sorry but offense for this sentence its so stupid.
Considering someone was given a temporary ban for basically using the word "zionist", explain why I shouldn't take an equal measure off offence at people banding around expressions like "islamic extremist"?
Besides, I've yet to meet another muslim anywhere that's as loony and extreme as your average amiga user ;)
-
Cheers Karlos
Found VAsm here and downloaded it, need to start studying PPC opcodes now...:)
Most obvious differences from 68k assembly are:
1) It's a load/store architecture. None of the basic arithmetic/logic operations work on effective address operands like they can on 68K. One reason why you have so many registers ;)
2) Not as many effective addressing modes (for load/store), but all the obvious ones are more or less covered (indirect, indirect with displacement, indirect with increment/decrement).
3) Triple operand instructions. Well, most of them are of the form A @ B -> C, where any of A, B and C can be the same register. Some instructions take even more operands.
4) Bit positions are enumerated the opposite way round for bitwise/bitfield type operations. Thus Bit 0 is the MSB, rather than the LSB.
5) There are useful bitwise operations (such as masked rotate and masked shift, fused floating point multiply-add) that exist as single instructions on ppc that are good for improving performance of certain algorithms.
6) Optional CC update. Basically, most logic/arithmetic instructions have a notation that allows you to decide whether or not you want the side effects of that instruction to be written to the condition codes. This is especially useful once you start to optimise your code by reordering instructions and you don't want to destroy condition codes that you need to test later.
-
Besides, I've yet to meet another muslim anywhere that's as loony and extreme as your average amiga user ;)
Amiga extremist young fundamentalist mad mental team rulz ok... ;)
-
This isnt a religion thread and its better dont talk of religion with religious people, i dont care about any religion, so its only a sentence at this case but feel free to give me a temporal ban.
-
Most obvious differences from 68k assembly are:.
Should help pass some of these long winter nights though... :)
(They finally dug our street out after 10 days of being snowed in, been no post or bins emptied here for over a week now... :) )
-
This isnt a religion thread...
Neither was the other one... meh.
... so its only a sentence at this case but feel free to give me a temporal ban.
:roflmao:
Ok, I hereby ban you from time travel/manipulation for 3 days.
-
Should help pass some of these long winter nights though... :)
Oh, don't forget that you can also do some load and store with endian conversion on the fly if necessary.
-
I wouldn't want to write using C as I prefer coding in assembly, you wouldn't happen to know of an assembly compiler for writing in PPC would you... :)
Maybe you could have a look at ECX (http://blubbedev.net/ecx/). It is a follow up of the AmigaE (http://en.wikipedia.org/wiki/Amiga_E) with support for PPC. It has support for inline PPC and M68K asm so everything but the function headers could be in asm.
You may even like the language as it is kind of asm like language (mostly not typechecked) with a nice syntax that even allows object oriented programming but still with a low level feel.
greets,
Staf.
-
Cheers for that info Fats... :)
I'll have a look into this "E" stuff on the link you gave. It's going to take a while to learn all the PPC stuff so I'd rather stick with coding in assembler for now if I can as I reckon trying to learn both "E" and PPC at the same time may be pushing things a wee bit... :)