Classic Amiga development vs NG

What are the advantages In developing for AmigaOS 4.1 compare to say 3.2.
Is it easier now? Time to release is shorter? Development tools and API changes made it easier to develop for NG or is it the same?

I'd say it's just as follows:
- there's a common SDK distribution. So you can expect everyone to have the same toolchain and same includes and libs in same location
- Better C libs (newlib, clib2, and even other options) means better POSIX support
- Newer GCC, though you're still better off using cross compiler, but at least unlike 68K you're not forced to choose between either ancient C compilers or making your own bastardized GCC build
- Those two things above (better C lib, better compiler) together with bigger main memory mean easier to port cross platform code from the mainstream platforms, and more readily available defacto standard core libs e.g. cairo has been ported

Apart from that it's basically the same isn't it?

It depends on what you want to do actually.
That's how I see it.

AmigaOS 4.1
Pros
- Newer tools and GCC versions
- Easier to port and use libraries from other operating systems, i.e. sdl, curl, openssl etc.
- Better API for fast development
- More mature Reaction classes
- Many different classes available from third parties and developers

Cons
- Your application runs only on AmigaOS 4
- Problematic debugging tools for some of the supported hardware


AmigaOS 3.2
Pros
- Use old development environments that have embeded debugging tools
- Reaction on 3.2 get's closer to AmigaOS 4.1
- Your apps can work in many different setups, even on NG systems
- Easier to work in a cross-development environment with emulators for testing and debugging
- More debugging tools that are working pretty good

Cons
- Use old compilers, except if you want to use vbcc
- Hard to use libraries, so to speed up your development

I am not referring here in MUI because both OS4 and OS3 API is similar, so no differences there.

In Morphos land they build one or two framework in the same philosophy as NextStep using also Objective C and MUI to speed up development time and when I see their Iris email client and Wayfarer done by the same developer in a short period of time for Amiga land they maybe onto something.

@Kamelito
Usage of ObjectiveC on MorphOS is just a personals wish of some core morphos devs, and that is in no way better or faster in developing software than pure plain C. It's just a matter of developers willing to use one or another language and its extensions to have to do something. If no jacadaps, then no IRIS/Wayfarer on morphos. Find out the same jacadaps for os4, and there will be the same IRIS/Wayfarer just on C.

As for the original question and to add more to picture: i love on OS4 the way how you program hooks and callbacks now. They are MUCH better understandable and easy to look/code than in aos3, aros, and morphos.

@Kamelito

I developed for OS3.x back in the day, so I think I am able to compare. I find writing software for OS4 a much more pleasant affair, due to a number of reasons:

* an overally more stable operating system;
* better system APIs, which - among other things - allow you to allocate system resources in a safe and future-proof way, using dedicated functions such as AllocSysObject();
* more advanced and better-documented memory subsystem with cool stuff such as semaphore-protected memory pools and (for repeated allocations of same-sized memory blocks) item pools;
* a recent, industry-standard compiler (GCC) and a feature-rich IDE (CodeBench);
* a lot of useful stuff such as link libraries has been (or can relatively easily be) ported over from other OSes, which brings advanced technology that can be used in native OS4 applications;
* I could go on.

@Kamelito

Just to cover few topics not talked about.
there more don’t in AmigaOS4.1 then on AmigaOS3.1

Well, you can do lot of same things on AmigaOS4 as you can do on a classic AmigaOS3, but you need to replace some tools, if you’re writing 68k programs in assembler for example, the type of program you write in 68K assembler also has to be system friendly. And most example you find about 68k assembler is not.

If you need a mod player, use an external player like ptreplayer.library, ptplayer.library.

Equally other tools like Blitz Basic were not designed for purely system friendly OS, and might be doing dirty stuff, e extra care has to be taken when using old tool, and you might find that AmigaOS4.1 don’t like dirty tricks. (Blitz Basic Debug is not working..)

While you can’t bang hardware, you can do something similar with a few workarounds in software. But that type of code is not recommended, as it be sub optimal. (at least for blitter)

Amos Pro, is not working natively on AmigaOS4.1, but you can run code in Amos Kittens. (Not all extensions are supported, and not all commands, but most of your code will work, something like 90%.)

Writing C or assembler programs:
AmigaOS4.1 behave different, for ensample ScreenOpenTags will pick chunky screen if you don’t tell it what mode id to use. While AmigaOS3.1 always picks planar mode by default, (this breaks a lot of old programs and games.) AmigaOS4.1 don’t have planar modes by default, only if you activate fake modes, and they are fake!! No copper, no blitter, if your code is not using graphic.library function then forget it, it wont work.

BitMaps BytesPerRow is not the same as width of the bitmaps, never assume that anymore. It was never legal but some games do that.

you’re not allowed to peek and poke into lots of places in Exec.library anymore.

Large files are supported on AmigaOS4, but you must use new functions in dos.library

timer.device, ticks are not the same on AmigaOS4.1 as on OS3.1, games sometimes run too fast because of faulty assumptions.

Planar modes are shit slow on AmigaOS4.1 use chunky modes.

@LiveForIt
Quote:Like some of your other comments that's just plain wrong, there is no difference at all to neither AmigaOS 1.x nor 3.x in AmigaOS 4.x.
If you are using AmigaOS 4.x on hardware with hardware planar bitmap support(for example AGA screen modes on an A1200 or A4000) there is no difference at all.
Of course if you are using a gfx card instead (for example a Radeon HD card without any hardware support for planar modes) it either doesn't work at all, or it's emulated by the gfx card driver resulting in unusable slow emulation.

@joerg

Quote:

Just tell me what think is wrong. Maybe thing changed while you where gone.

Quote:

Most people use AmigaOS4.1 on AmigaONE hardware, so in most cases what I say is true.

My experiments writing my own, gave a lot better FPS.

https://github.com/khval/BetterFakeMode

(but it’s a dirty hack.)

Quote:

yes it, does not support DBPAL, DBNTSC mode id's
and PAL, NTSC modes are too large, resulting bad BPR.
Resulting in scabbled graphics. most 68k software use hardcoded BPR.

Of course, that is the tip of iceberg for anyone wont port their old programs.

@joerg

What's your problem? You tell him he's wrong, then prove that he's right by making it clear you mean only when running OS4 on classic hardware, which was obvious to all readers to not be what Kjetil is talking about. Leave him alone.

@LiveForIt

Quote:But that's neither the fault of the software (using planar gfx modes emulated on chunky hardware on AmigaOS 1.x/2.x/3.x wouldn't have been any better than on AmigaOS 4. P-OS did try it, but without much more success).
Not sure about the AmigaONE sales numbers any more, there is probably much more hardware from A-Cube and A-Eon now, but it doesn't make any difference.
If you put a Voodoo3 gfx card into your Amiga (no matter which NG vendor or classic Amiga) you can still use planar modes without emulation nor speed penalty, but if you are using a Radeon gfx card it's something completely different.

@joerg

here where not that many who owned a real Cyberstrom PPC / BlizzardPPC, 68060 where more popular.

We do now have this hardware:

AmigaONE-SE
AmigaONE-XE
MicroAmigaONE
Sam440
Sam460
AmigaONE-X1000
Pegasus II
AmigaONE-X5000
AmigaONE-A1222

Most of the peaple who buy AmigaOS4 for classic Amiga use it under WinUAE emulation, so AGA is emulated there.

@LiveForIt
We do how this hardware now:

Quote:Never had a SE, but "just" 2 "AmigaOne XE". At least one of the CPUs died for sure because of inadequate cooling. Don't rememberer what the problem was with the 2nd X2E I got was, but it's just an unusable brick now as well.
A-Cube (Sam440ep, and a Sam460ex board for some months, but I failed to implement an usable SATA driver for it) and A-EON (X5000) did provide me with usable hardware instead

@joerg

My XE cpu module was sent to ACube-System for repair, they also provided me with better CPU cooler. My guess is most SE/XE computer are backup, for something else now.

Did not Acube-systems take over driver development?
m3x?

looks like the driver is working:

https://www.youtube.com/watch?v=X75KbnOpZhA

not the fastest CPU but it works.

@kas1e I’m pretty sure he wrote somewhere that development time was shorter it is more a combination of ObjC and the framework than the language itself.
It is known that NextStep and now OSX made it possible for a single developer or a small team to deliver apps faster and be able to be competitive against big companies. (See pimp my code by Will Shipley) of course MorphOS framework is not on par with nexstep/ISX but it’ll grow.
https://www.morphos-team.net/guide/objective-c

@Kamelito
It still all a very little percent of the problem what language to use and what frameworks. Every skilled developer has his own preferences, and they in no way are the main reason to have new software be written. Main reasons are developers' wishes, skills, and motivation. As i say, be it objectivec, plain c, c++, c# or anything of that sort it is no way radically help if you have no developer(s) using it. Some morphos devs have preferences over objectivec and it's integration, so why not, but as i say that of no way is the main reason to have software, or, speed up anything _radically_. Once Jacadaps and Piru will have no time/interest in morphos, be it objective-c, or shmojective-b, it all will stop. The only matter is developers, not the languages they use.

Developing and maintaining an ObjC runtime is itself a huge job, and no one is going to port the MorphOS one to OS4. Once you've got it it can help a bit because it so happens it's very developer friendly, moreso than say MFC or .Net runtime or Java. But since there isn't much non-macOS/iOS ObjC code out there it wouldn't help much in increasing the available ported software catalogue. For that one would be better off doing what Haiku is doing with their Win32 and X windows compatibility layers.