I see many AmigaOS 68k, AmigaOS4, MorphOS, and probably AROS programmers as well, complain that they need better development tools, to make programming new software for these platforms easier and quicker. What would it take in terms of man power to port existing development tools to the above mentioned platforms?

If a group of programmers could be formed (maybe the group already formed and supported by A-Eon), I would guess that the group would first need a consensus of which tools are wanted and needed. Then perhaps some progress could be made toward porting such tools, as a group effort.

I'd like to see something like that happen for 68k programmers, but who would organize such an effort?

I'm guessing that porting the tools needed, would be a very big task that might take 2 or 3 programmers working on it many months, or years to complete in their spare time, but perhaps it could be done more quickly if it were funded through something like a Kickstarter campaign, since there are still many more 68k Amiga users than any other NG platform. Of course programmers time is always hard to come by, no matter if it is funded, or they are doing it for free, since they always must keep their regular jobs, and also can't ignore their personal lives.

Just thought I would start this thread to see if there are any members who have ideas on how the problem of lacking great development tools could be resolved. Please add your CONSTRUCTIVE comments to this discussion, if you have any.

_________________
Amiga! The computer that inspired so many, to accomplish so much, but has ended up in the hands of . . . . . . . . . .

@amigadave

Quote:

Please add your CONSTRUCTIVE comments to this discussion, if you have any.

My constructive comment, is that its all excuses , because all 4 oses today have necessary tools for making software : fresh gcc compilers. Even 68k have it for few years already (before there was some too old one).

And everyone who want to make software fast, with all fancy IDE, can use cross-compilers with editors they need

The issue there is not miss of development tools (while, of course, there never will be many), but just lazyness of programmers, loosing of motivation of developers, and whole lack of energy pieces of which enough only for forum posts, sadly.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

@amigadave

Quote:

I see many ... programmers as well, complain that they need better development tools

Maybe it's not the actual lack of 'proper' developement tools that withholds these people from coding, maybe it's nothing more then an excuse to keep the arms akimbo. Remember that in the early stages of Amiga, the days when there was no hardware yet sufficiently coherent enough to call it an Amiga, software was developed on a very differently OS-ed machine. Today there are plenty of full-fledged developement tools on other platforms that sufficiently fill the described gap.
I fear that it is more a general lack of BCI's (Bright Coding Idea's) that chokes developement by newcomers.

A lot of moons ago a similar thread brought forward a number of enthousiast 'coders in spé', who simply lacked the basic knowledge of coding, spouting ideas of projects they were thinking of to undertake in order to take the Amiga back to its rightfull leading position software-wise, preferably overnight. The general gist of their posting was that embedded very question: "How do I do that and where do I start".
Like the want and dream of participating in the New York Marathon, without sufficiently mastering the basic concept of walking yet.

And that's then the core of coding for Amiga: when you want to, you first start with very, very simple projects, like opening a library and check whether it is open indeed. Or allocating memory and verifying whether the allocation was sucessfull.
Start off by taking small and overseeable steps until you master the matter in a better way.
Using a developement tool set is by no means a guarantee for high-quality software. It may turn out to produce the same buggy junk as handbuilt software, with the single difference that it took less time to accomplish.

I felt in a very POSITIVE mood when I wrote this and I still felt that way when posting.

OldFart

(Off into lurking mode again)

_________________
More then three levels of indigestion and you're scroomed!

@amigadave

To me the problem is the Amiga API which is rather primitive to todays standard. So developing software takes more time. The MorphOS Team understood this and created the ob.framework and MUI.framework that you program in Objective C. It is a bit like Cocoa on the Mac. Of course more frameworks/classes are needed and if they could also built an interface builder that would be awesome. They get it, they just need to expand it more.

@OldFart & kas1e,

Thanks for your replies. I wasn't really thinking about new programmers when I started this thread. I was thinking more about bringing in experienced programmers from other platforms, most probably Linux, who are used to having more programming tools, or at the very least, different programming tools, beyond the gcc, or vbcc compilers available to all of us. I also was thinking of existing programmers within our communities, who have complained, or asked for better development tools for debugging software code, or better integrated development environments, which are available for other platforms, and perhaps they are used to having available while coding for other platforms.

I think that Hollywood is an excellent programming language for beginners and there are dozens of other choices for someone to try out if they want to see if they can become a software programmer in this community.

Maybe I should have worded my first post in this thread differently? What tools do you think we need that would make it easier for programmers who are experienced on other platforms, to port existing software to any of the Amiga inspired platforms, or for them to create new native software for any Amiga inspired platform?

_________________
Amiga! The computer that inspired so many, to accomplish so much, but has ended up in the hands of . . . . . . . . . .

@kamelito

Quote:

kamelito wrote: @amigadave To me the problem is the Amiga API which is rather primitive to todays standard. So developing software takes more time. The MorphOS Team understood this and created the ob.framework and MUI.framework that you program in Objective C. It is a bit like Cocoa on the Mac. Of course more frameworks/classes are needed and if they could also built an interface builder that would be awesome. They get it, they just need to expand it more.

This is the kind of reply I was looking for.

So, how do we get more "frameworks/classes", and/or an "interface builder" for MorphOS? What level of programming expertise is needed to provide more frameworks/classes, or to create an interface builder? Is this a project that would take a couple hundred programming hours, or several thousand?

_________________
Amiga! The computer that inspired so many, to accomplish so much, but has ended up in the hands of . . . . . . . . . .

@amigadave

Well, I hope I am doing my part by writing a new text editor geared more towards programmers, not general purpose editing. I started it in March and was hoping to be a lot farther along than I am. Lack of time is a big killer of projects.

I code on my Windows machine, FTP it over to X5000, then compile. Slow and tedious. I want to write code on my Amiga in a fast, low overhead editor. So far it is looking good.

@amigadave

It would take time for sure, Next did it maybe in two years for the first version and they had money and talented engineers. The major bottlenecks is time and money. Let’s says there is 2000 MorphOS users they committed to give 2 to 4 dollars a month for as long as it takes then you could have depending on the country and cities 2 or more full time developers dedicated to such tasks. That way it will be quicker, but is there key devs from the MorphOS Team willing to do that?
There’s an open source implementation called Gnustep but I’m not sure if the code could speed up the développement except if you port the tools and frameworks on top of the OS like OpenStep did. Better ask Jadacaps.
Regarding OS4 I think that Steve Solie wanted to take the QT route...

Last edited by kamelito on 13-Sep-2019 at 07:02 AM.

@amigadave

Hello! It's been a while!

Currently my project is to make a text adventure framework on AmigaE as a proof of concept design. I'm implementing a feature called "interface inheritance" that is well-known on Java. Since it doesn't come natively with AmigaE, I'm doing so with other low-level features that AmigaE does have.

Once it's working on AmigaE as a proof of concept it can be recompiled for MorphOS and maybe OS 4 using ECX as a compiler. ECX is written in itself and is an able AmigaE compiler for both PPC and 68020 or greater on 68k. As a design limitation, ECX is presently limited to big-endian 32-bits as is AmigaE.

ChrisH tried to make a PortablE transpiler but last I heard, he's having health concerns. His code is also closed-source as opposed to the shared-source model of ECX.

EDIT:
I forgot to mention that Damien "Hypex" Stuart is working on some bugs in the EDBG "E Debugger" program to help me with my project.

EDIT2:
On the subject of GUI development, BOOPSI is a framework that both Reaction and MUI use internally. It has a fairly high overhead for an Amiga framework. Reaction originally worked around this by adding BOOPSI.library to the OS to share the boilerplate code that all BOOPSI classes need to implement. MUI used an even more extensive booster called MUIMaster.library, thus making the GUI frameworks even heavier.

Gofromiel tried to make a GUI framework independently of BOOPSI and Intuition called Feelin' but it was not finished properly and had a really weird license structure that probably wouldn't hold up in court.

Hollywood has a cross-platform GUI plugin called RapaGUI that acts as a wrapper for MUI on the Amiga-likes and wxWidgets on the other platforms.

My proposal for making a GUI is to make a GUI programming language compiler rather than a framework so that the dynamic layout code can be optimized down to a minimum in GCC. This will speed up the GUI layout engine so that a 40+ KB class called Layout.class or MUIMaster.library become less needed. The downside is that somebody has to do it or it will just be an idea. As for the basis of the language, using the XML syntax of RapaGUI and Feelin' makes a better and lower overhead design than does BOOPSI at a cost of modularity.

If somebody wants to discuss specifics about the GUI compiler, I'll entertain the idea farther using another thread.

Last edited by Samurai_Crow on 13-Sep-2019 at 09:29 AM.
Last edited by Samurai_Crow on 13-Sep-2019 at 09:14 AM.

@Samurai_Crow

Quote:

BOOPSI [...] has a fairly high overhead for an Amiga framework.

BOOPSI implements a system of methods based on Exec message passing. Few of the methods are called during a class' lifetime, which means the message traffic is quite low. GM_RENDER will be called more often for gadgets, but the method can be optimized to minimize redrawing. So the performance relies more on how the class is implemented and less on BOOPSI's inherent design.

Quote:

Reaction originally worked around this by adding BOOPSI.library to the OS

Never heard of this library - what was it exactly, and when was it added to the OS?

Quote:

using the XML syntax of RapaGUI and Feelin' makes a better and lower overhead design than does BOOPSI

This statement doesn't make any sense: GUI representation using XML syntax and BOOPSI design are apples and oranges. Plus, if there is something that implies overhead, it's XML

_________________
The Rear Window blog

AmigaOne X5000/020 @ 2GHz / 4GB RAM / Radeon RX 560 / ESI Juli@ / AmigaOS 4.1 Final Edition
SAM440ep-flex @ 667MHz / 1GB RAM / Radeon 9250 / AmigaOS 4.1 Final Edition

@amigadave

I don't think there is much missing.
Better documentation and examples maybe. But generally the community is pretty helpful: if you ask questions, you'll get help. Usually.

And while there is always room for improvement I guess we should concentrate on what's there. For me as occasional programmer C/C++ on Amiga is too complicated/takes too long, hence I switched to Hollywood where things are more easy.

It's not the lack of tools what is holding back development, it's lack of time.

_________________
My programs: via.bckrs.de
MorphOS user since V0.4 (2001)

@Trixie

While you posted this the deficiency of my post was becoming apparent to me as well. My goal is not to replace BOOPSI as a whole. That would be foolish because the Datatypes system is based on BOOPSI.

Layout.class is a one-size fits all solution to something that should be customized to the layout of each GUI individually. It's an interpreter that is too big to fit into the code caches of an '040 or even an '060 let-alone the lowly 68000 which has no caches at all.

The best way to target a 7 MHz 68000 is to make the code a custom fit to the application. My philosophy of how to achieve this is that "Everything Compiles". That means ditching the interpreters every chance we get in favor of custom compiled code.

On anything less than an '060, divide instructions take many clocks so being able to detect a divide by a power of 2 constant and convert to an arithmetic shift right instruction saves dozens of clocks even on an '040.

In order to accomplish this, we need to have a neutral format that can be processed easily. Earlier I mentioned XML formats but internally, a nested tag-list might be even better. Once that's done, we can see about generating custom C code that exports the layout for a GUI.

@Samurai_Crow

Quote:

On the subject of GUI development, BOOPSI is a framework that both Reaction and MUI use internally. It has a fairly high overhead for an Amiga framework. .

Actually the overhead is pretty low for what it can do and compared to established frameworks elsewhere. It is really only an issue when your running a 60000 or fairly basic 68020 system, in which cases the features offered would be mostly overkill.

_________________
- We don't need good ideas, we haven't run out on bad ones yet
- blame Canada

@amigadave
Well, I think tools we have for example the gcc, Amiblizt, BlitBasic, Amos, Hollywood, Amiga E, and game makers as redpills, backbone, the two problems today is there aren't many musicians and graphic designers and the second is the lack of motivation.

@amigadave

I learnt to program on C64 and Amiga, and never used anything like VisualC++ or Eclipse, so my development tool requirements are rather modest. I'd like to have a working debugger and profiler integrated in CodeBench, but apart from that, I don't feel a pressing need for anything else. If there's something that holds up my projects it's time. Things got much worse after I started a family and got a mortgage.

_________________
The Rear Window blog

AmigaOne X5000/020 @ 2GHz / 4GB RAM / Radeon RX 560 / ESI Juli@ / AmigaOS 4.1 Final Edition
SAM440ep-flex @ 667MHz / 1GB RAM / Radeon 9250 / AmigaOS 4.1 Final Edition

@Templario

gcc,
The compiler is bit outdated if I'm not mistaken, generally there no big issues expect the lack of support for some optimization options for AltiVec and other powerpc extensions.

The bigger problem is generally configure scripts, that crash do not work, problem with Linux based shell commands that do not work as they should like "Grep", and other command do not work well with Amiga Paths and sometimes are broken if you try use this with Linux paths.

My impression is biggest issue is network support and lack of modern API's in AmigaOS4, basally roadshow is out dated. It's not really GCC problem its a bit bigger problem.

(the libsocket or other wrapper libs don't work well if combined with pthreads or use child processes, you end up rewriting large parts which is impractical, and of course is counterproductive when working with cross platform or Linux ports. )

Amos,

AmigaOS4 support for Amos is a bit lacking, the work on implementing Amos Kittens interpreter continues. We can dream about editor or compiled AMOS programs for AmigaOS4, but that will have to come after the interpreter is feature complete.

Hollywood,

Rocks on all platforms, maybe batter on high-end computers, not so good on low-end maybe.

Amiga E,

AmigaOS4 should be already support "Portable E"

"redpills, backbone," this are only for Classic AmigaOS3.x and do not work on AmigaOS4.

redpill if I'm not mistaken is made in BlitzBasic, not sure about status of AmiBlitz3 and if there any work on making it redpill and AmiBlitz3 system friendly.

Backbone created in AMOS, any hope of backbone running natively on AmigaOS4, will depend on the completion of Amos Kittens. And hope that source code of Backbone is made available.

python.

I'm not sure how many has tried to use on AmigaOS4.x but I have my impression is some stuff works ok, and some stuff is buggy, and needs a lots of work.

Then there are lots interesting languages that are on the horizon, like RUST and "MONO" used is used lots of games. the R programing language,

So there are lot interesting things happening outside of Amiga platform.

Java is on the way out, while cool to have, my impression is that C# (MONO) has taken over.

Last edited by NutsAboutAmiga on 14-Sep-2019 at 12:28 PM.
Last edited by NutsAboutAmiga on 14-Sep-2019 at 09:03 AM.
Last edited by NutsAboutAmiga on 14-Sep-2019 at 09:02 AM.
Last edited by NutsAboutAmiga on 13-Sep-2019 at 06:11 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@amigadave

So the thing what really, really like to have on AmigaOS is gitkraken, it really nice GIT client, that use almost every day on Windows.

Also I like to see something like sublime on Amiga, I know there some editors that can do almost the same thing, but almost is not the same as the same thing.

Last edited by NutsAboutAmiga on 13-Sep-2019 at 06:26 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@amigadave

Quote:

might take 2 or 3 programmers working on it many months, or years to complete in their spare time,

in reallty the work is never done, as every things gets old and outdated, so you need to keep updating things, make sure they work.

When lose interest or lack of motivation or other projects gets priorities older projects gets left behind. some times I hope I can find the time or motivation to return to this projects and make this what they where supose to be.

so in siganture I have few things I worked on.

Excalibur, Basilisk 2, AmigaInputAnywhere.

Excalibur - was broken when Hyperion created AmigaOS3.1 final, and broke Picasso96, I have fixed version, but its not better version so was not updated. (it was also becoming popular to make toolbars programs, so I felt it was unneeded)

Basilisk 2 - also broke when Hyperion created changed graphic system, while source code has been available for year no one else decided to fix it, there are some changes source forge, but as its mix of 0.9 and 1.0 it can be merge back to the official repository. (beside there other none offical repo's on GitHub that might be more updated) Some changed are only AmigaOS4.x related, some changed can be back ported to OS3.x if anyone is interested.

AmigaInputAnywhere - it should work, but there some stuff peaple are not happy about, don't remember what.

Personally I think it's good to not get stuck with projects, doing different things helps expand experience and can help increase the knowledge to solve issue what left unsolved.

Last edited by NutsAboutAmiga on 14-Sep-2019 at 08:21 AM.
Last edited by NutsAboutAmiga on 13-Sep-2019 at 07:34 PM.
Last edited by NutsAboutAmiga on 13-Sep-2019 at 07:32 PM.
Last edited by NutsAboutAmiga on 13-Sep-2019 at 06:48 PM.
Last edited by NutsAboutAmiga on 13-Sep-2019 at 06:24 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

Re:Git

Bitbucket has announced they are dropping support for Mercurial so Git is it. There's no other choice any more.

@mritter0

Your interview gave good insights too, thanks for your work!
https://amigaonthelake.com/blog/interview-with-mark-ritter/