Hello my first Thread

[Franko]

@ 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...

[Franko]

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...

[Franko]

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. 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...

[Franko]

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)...

[Franko]

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...

[Franko]

@ 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...

[Franko]

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/ 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...

[Franko]

@ 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...

[Franko]

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...

[Franko]

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...

[Franko]

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... )

[Franko]

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...