I remembered this thread while browsing for information about PCL3GUI...

IMHO, the printer.device API was and is quite good for band printing, as most inkjets do. It is not the API?s fault that we lack modern drivers, its the manufacturer?s documentation policy.

If we really consider some kind of new printing API, we should consider a PDL for application level and a print spooler using disk space, especially for band printing devices. PDL capable printing devices don?t need banding for obvious reasons but could utilize this disk based spooler, too

But even if we manage to make up such an API, we still have the problem of lack of documentation from printing device manufacturers.

Some folks suggested CUPS for "solving" this, but hey, CUPS is a monster and its drivers mostly don?t support special features of certain inkjet printers.

If we really want to have a new API for printing, make it up the Amiga way, it can?t be such hard to do.

Not another memory eater, please please please...

Regards

Hello!

I search for a way to get mouse wheel events via input.device. Sadly, there are no IECODE defines for mouse wheel data, despite the fact that there is a IECLASS_MOUSEWHEEL class, so I dont have a clue if there is a way to use the mouse wheel events in some input.device dependend program. Anybody here can help on this and enlighten me if there is a way to get mouse wheel events from input.device directly?

Regards

@abalaban

AFAIK, the C/C++ addon install script of Cubic wont work with the latest SDK. Problem for new customers is, that there is only the newest SDK available for download, so no pre install with the older one is possible -> no functional C/C++ addon for OS4 yet.

@Atheist

No, we don?t need faster hardware or "faster progress" yet. What we urgently need instead is a more developer friendly SDK, a really stable OS release and, most important, genuine AmigaOS software in high quality.

We had all we need, all the time, and still people are whining about "catching up with ports of the software other OSses have", totally ignoring that those ports will win us nothing. You show to us with your link, how things are really going.

Stop the "port this & that" madness, support AmigaOS-only software and feel the speed of the AmigaOS!

Regards

@Slayer

It is not only the sometimes strange syntax error information, it is the "implicit" wrong behaviour of other tools of the toolchain, too. I was used to compilers doing a straight compile when called without any special options or at least breaking with some error report on the file types given.

frontend gcc doesnt, it tried to do very unusual things instead, which lead to very annoying and misleading messages.

Even more annoying is the behaviour of make respectively its older flavours. You could omit -o option in the makefiles and then project was done without any hassle. Now you cant, or it will bite on you with e.g. "undefined reference to...".

Well, I know these pitfalls now and can help, when the next new developer stumble over this

Regards

@magic

Youre welcome

@sundown:

you too

Regards

@Hans

Argh, you are right! Thank you very much, I thought I went mad on this ;) Those damn overcomplicated makefiles lead me to this error, too, I tried to compare other example makefiles, as the one used on 68k doesnt work with the OS4 make (dont know why), but I dont get this one :/

Again, thank you very much Hans!

Regards

Hello folks!

I hope that somebody can enlighten me on this:

It is not possible to compile bigger projects using so called "legacy" code, if it implies separate object link stages.

I tried with simplified command lines like this:


__USE_INLINE__ is #defined in the source code, btw.

Best bit on this: with



all works nice and slick.

Can anybody explain me, why gcc behaves like this?

Another one: If I try to make the project with a makefile, it fails utterly in the linking stage with tons of "undefined reference to...", although linking is done with -lauto and __USE_INLINE__ #define d.

Compiling and linking only works with the basic command line above. Why is it this way? Am I doing something wrong? If so, what??

A more in-deep answer is highly appreciated, thank you very much.

Regards

@orgin

No problem at all.

My post was ment as what it is, polarizing, but not as a complain about the topic itself.

But if you go back a few years of AmigaOS development you may see what I?m talking about and that most of it is not entirely prejudice or presentation of guesswork. You will see lots of examples even right here in this thread, no need to search in the past.

I just see AmigaOS development stalling in the effort to make it more and more similar to the established systems like Un*x and Windows and I fail to see the advantage of that. All efforts to e.g. implant things from the Un*x world so far lead to severe problems with AmigaOS software development, hence hindering active native development instead of supporting it.

Same goes for "to MUI or not to MUI", this struggle hinders development, as well as "ReAction is crap, do more work on integrating foreign GUI systems that will lead to even more work in order to get it integrated". This is pure nonsense and I don?t get why people still insist on that. Same goes for open source, as good as the idea itself is. How many open sourced projects grew mature in all this years? Not many and that is IMHO caused by misconception in using as many foreign solutions and paradigms as possible, completely ignoring the abilities AmigaOS has.

Hope this explanation was a little bit better to understand.

Regards

@olsen

I see the points you made, but I have a very different view on the actual situation of AmigaOS and its "development crisis".

@all

First of all, developers and users are divided into many slightly different groups, each one preferring their "preferred system of doing things" for every price. There are people preferring MUI, there are people preferring open source software, there are people constantly comparing AmigaOS to un*x like systems, people who are in an enduring race after most modern methods without a real use for AmigaOS, people that want to use one very modern programming language for all tasks only and so on. I ask you: Why should AmigaOS development take all these preferences in account? Why isn?t chosen a practical solution that can be used to build upon and is developed further?

So, let?s have a look on what have been achieved so far. We had a transition to different platforms now and it was more or less successfull. There were some modifications to the OS that are urgently needed and many that doesn?t made a real sence, except for very few people that needed them, e.g. for porting things over from the Linux world. There is support for the two mayor GUI systems.

Still people are complaining, and I think this is because they miss a straight direction in all this.

For example, what was achieved in regard to native AmigaOS software, except (more or less successfull) bug fixing of isolated OS parts (GUI, several libraries etc.), with all this modifications done to AmigaOS?

I will tell you: Very few. Head development people are complaining instead, e.g. complaining about ReActor as a mere super-duper texteditor. But what is done against this? Well, nothing. Is there any help in building GUIs on the Amiga to avoid the "macro madness"? Does the "ease of porting" paradigm help on this? (this is not meant as a personal offend, btw., it is a simple example for one of the biggest problems we have: No straight line of future development, just "use all nifty things some Linux oder Java nerds are proud of, regardless if it fit to the OS philosophy or not")

No, it doesn?t. Developers still have to search for documentation all over the web, are waiting for updated SDKs, struggling with GUI element bugs all over the place (or in half hearted ports like SDL), so they?re loosing drive for development over time, which in turn is complained about by the users.

All that is done against this is talking about e.g. GUI systems used on POSIX OSses that are contrary to productivity but filled up with "features we have just because it can be done and it is canonic!" (exaggeration).

Some very good improvement ideas for AmigaOS are talked to death instead of being supported, e.g. trying to set up a more modern datatypes system that doesn?t break compatibility as far as it goes and doesn?t try to adopt the bloatware method of "we have enough CPU power and RAM, let?s waste it for some nerd toys!" and "XML is a must, you can edit preferences easily, using a simple text editor (but we will not tell you about the fact that most users don?t want to edit preferences as ASCII text and want to have a GUI driven prefs program instead, as they are not willing to learn a "simple" programming language in order to find the right TRUE or FALSE value within a bunch of ASCII files of some hundred KB size each)".

The problem is very simple and very basic: What we now have is FIAT (fix it again Tony!) since a long time and with several paradigm changes within this process. Today we have the use-POSIX-and-open-source-wherever-you-can paradigm as lead paradigm and that opened Pandora?s box. More and more construction sites are opened without any idea of to what these paths may lead in regard to AmigaOS and its philosophy.

All these construction sites try to deal with several and very different ideas how AmigaOS could be improved using open source solutions, but they lead to nothing than half-ready solutions and some more or less useful ports yet.

Astonishingly, most native and usefullest applications we have today are developed without using these "improvements".

So, we need Amiga instead of open source Fiat

IMHO, we should have a go on ONE paradigm only and that is "AmigaOS". We should work on the problems that evolved over the years, trying to get a clean, lean and comfortable system again, then we can proceed with really new ideas (this definetly not means simply trying to adopt some "funky" academic fashions/solutions from the Un*x world over and over).

This includes heavy work on the development tools we have so far respectively that we are missing, e.g. GUI builders, source level debuggers, new shared libraries/devices for some badly needed functions, documentation, bug fixing or rewriting of key components that are known to be buggy (some ReAction classes like the listview, or, as mentioned, the good ol? Workbench or even multi-user-capability on a simpler level) and many, many more we forgot about for nearly a decade now (e.g. non-academic programming examples showing good programming practices, not like some of the OS4 ReActions examples that in some cases contain serious errors and bad practices).

Let?s face it, it doesn?t count if we implement nerd features that are told to be a must-have nowadays. 99,999% of all PC users out there doesn?t care if e.g. the system supports XML preference files for each and every occasion (and I don?t know any real Amiga user caring about it!). They simply care about how good they can actually use a system and that is a field AmigaOS still is very modern (besides the lack of some key applications that are constantly discussed but never really worked on because it has to be a port and a port of these "very portable solutions" isn?t possible because AmigaOS is not Un*x!).

I don?t talk about such pure eye-candy features like "3D-Desktops" or "transparent windows", I talk about pure usability. Eyecandy is nice and attracts many users as long as it?s "new", but in the end the user only sees how easy or hard the work is using a computer system. A good example for this is Windows Vista. Most users don?t like it and try to get back to XP, if they can. Vista has lesser usability than XP despite the fact that it contains lots of nerd features and eye candy!

AmigaOS could be even more usable as it is right now, if we would concentrate on its very own strengths and a good developer support, so more Amiga-like applications will be released and more new ideas could be tried out again.

Hope this helps a bit, thank you for your patience.

Regards

@Spirantho

Well, if I could answer these questions I would have done it the first time All I can say is that there should be no problem using Highway with OS4 and its native driver, because it works absolutely flawless with my machine (and several others it seems).

We did the OS4 install with all cards plugged in (including the Highway) and had no problems at all. The machine has several other cards plugged in, Toccata (working very fine), IOBlix MultiIO (not tested yet), Ariadne2 ethernet (working very fine) and a GVP SCSI controller (likely not working because of the driver glitches with DMA thingie, but we didn't test it for now).

Later on the friend changed to a USB keyboard and is still very happy with my machine. Its an A4000 Elbox towered and the CSPPC has serial # 69, so it is very likely of the same charge as yours.

Maybe your Eagle backplane is the cause of your problems, but it is very difficult to say if the hardware isn't available for diagnostics. Maybe it is a really severe problem, maybe it is simply a capacitor dried up.

All I can say is, that it can't be a driver problem as there are many people out there using the A4000/Highway/OS4 combo without any glitches (sometimes even with Poseidon instead of Sirion and they still have no problems like yours).

Regarding the differences to OS3.9, you should count in that most likely some timings has changed and bus stressing is much higher with a PPC doing all the hardware related work than it is when the 68k is the "master" of the system.

Very frustrating problem, I know, and I wish I could help easily. But I can't, I'm sorry

@Spirantho

That sounds like a severe hardware problem. We (a friend of mine and myself) had no formatting problems at all with the Highway plugged in and using the Highway OS4 driver. I bet it would be possible to format a USB hard drive without any problem (if we would use FFS2/SFS). The A4000 is still running very fine (astonishing fast for 233MHz), no freezes or crashes that would be Highway related, so we have really no clue what your problem may be

Regards

@Spirantho

I don?t know, if there are different revisions of the Highway card... mine is one of the first cards (bought the Highway right after first release). I think that handling of the card is different with OS4, which may lead to strange problems that never occur with OS3.x.

In fact, the friend of mine is using the Highway with OS4 and the OS4 drivers and it works like a charm in my machine. The Toccata is doing a great job, too (as long as Amplifier isn?t used). We shouldn?t expect to find software related problems by discussion, so we should exclude possible hardware problems (like problems with the Zorro sockets) first and submit possible software bug reports after.

Regards

@Spirantho

A friend of mine does, I lend him my A4000 with Highway USB (and some other Zorro cards installed). It works very well overall and he is using an USB keyboard/mouse combo with it. It is quite stable (besides we have some issues with AHI, the Toccata driver and Amplifier, but the issues are not that serious) and runs _very_ smooth.

I had one strange thing with this machine some time back, it won't like to start sometimes, constant flashing power LED and such. The reason was, the Highway card came out of it's socket a little bit. After reseating the card the machine runs fine as it did the 10 years before ;)

Maybe yours is suffering from some slot problems, dirt or dust in the socket? Try to clean the card contacts and the socket contacts (be very careful with them!), maybe your machine will get far more stable after the cleaning.

Regards

@AmiGame

Well, I had this "corruption" from time to time in the past and I had the deep impression that it originated from the HTML view part of SimpleMail.

Size seemed to be no point, as I had this corruption even with very small mails (there was a very small mail breaking SimpleMail, something about 2K of size). For the last months, the corruption problem didn't occur for me anymore, don't know exactly what the reason is.

But I can tell you that PPS files are not the cause, because I received several PPS, even very big ones, and SimpleMail doesn't crash because of them.

Regards

@samwel

Well, partly you understand my "problem"... LifeForIt doesn?t really, I think.

To make it clear: I see the need for MP in future versions of OS4, no doubt. BUT (a BIG but) I don?t see any chances to get OS4 in a more advanced state, if we change the path every now and then. I don?t believe in all drivers being useable under a new MP enabled system, I don?t see all the 3rd party libraries running under this system, I don?t see many vital parts of a future OS4 running under a MP enabled system in a relatively short time.

So, we will stay at this half finished level we just reached and we will stay there for a long time, just because we lack developers and many parts of the actual OS4 are not polished or even finished yet.

My problem still is, that development of OS4 only software will be stalled because there are no good development tools, lack of documentation, new OS-features without the right SDK (which now is stalled for an unknown time) and so on.

I have no problem with some discussion about future must have features, but I think that there are much more urgent problems we should solve right now, before we start to work actively on MP and such (and no, I?m not able to solve all this alone but I?m doing my part on it).

Btw., I just own Cubic and I?m working with it. But if you compare it to the tools other systems have, you will see it lacks some very important features (not important for me but for other developers not used to develop for AmigaOS and that are the developers we want).

I understand Rogue?s post and fully agree to it, but I think we think and dream much too far right now. There should be more work concentrated on finishing and polishing the parts we have and then going on to new and must have features with full energy. Actually I have the feeling that this energy is put on too much construction sites, so it may be used very inefficient.

Greetings

@samwel

pls read carefully... it won't have benefit if we didn't manage to earn more devloper's interest for the platform.

This isn't possible yet, just because the development system is not even fully useable (latest SDK isn't there, gdb is more work to guess the failure than a help etc.).

All I say is that we should concentrate right now on the OS/development system before we put useless efforts on theories that will possibly last another 5-6 years before they become reality.

It's all the same when such discussions emerge: Everybody is talking about fine "must have" features that are just a pancake on the top, if they will appear one day in the far future, but the flaws of the system that exist yet will be forgotten every time.

Nobody is seriously using the possibilities AmigaOS bears right now. Where are the really good games everybody wants to see? Some SDL based efforts were made (ports), that's it. The often demanded development tools? Well, some half-finished ports, again. Very few AmigaOS only programs saw the light of the world until now.

OS4 is transformed to a never ending construction site, because lots of the new features and enhancements we just have don't get the attention they badly need because everybody is dreaming of things like MP and so on.

What about AmigaInput? What about the USB subsystem? What about 2D/3D hardware acceleration? More SCSI drivers? A real good debugger? More development documentation? I can ask the whole day on, there will be no satisfying answer.

I really know that there are not as much developers as needed, but to dream every day of new things to implement to the OS won't make the situation better.

All I ask is to start to use the things we have right now, polish them, make them more useful, expand them where it is badly needed (there are lots of fields to explore, polish and expand, believe me).

We have enough time to implement e.g. MP half a year or a year later. AmigaOS cannot compete in the actual market in this half finished state it is in, regardless if it bears MP facilties or not. It could, even without MP, if it would be in a better state than it is yet.

Greetings

P.S.: I own a OS4 system and I'm quite happy with it as a user, but not as a developer. I don't like command line developing using e.g. vi or NotePad, abcshell and a command line gcc with make. We all know that there were gui driven development tools in the past (and they weren't such bad as was said again and again) and that other platforms have these tools for years now. But for AmigaOS such tools are simply not possible, because lots of people don't see the point and keep on dreaming about things they don't need that urgently.

@LiveForIt

No, I don?t make a mistake here... you mentioned the exact problem... there will be no benefit of MP and such, IF there will not be more programmers (regardless if fulltime or hobbyists). What?s the big use of a handful (possibly ported and bloated) programs that won?t break the system?

So, first stage should be making really useable build tools, fully working compilers, debuggers and such. MP is a future topic, but I fear that people use too much energy on it instead of doing all they can to get a good foundation for development again.

Greetings,

Hm, I think we make too many steps in advance here... I see lots of people writing things like "MP eases software development", "helps writing better code" et al, but (please excuse me) where the hell is these software?

Let?s face it: We discuss future features of the OS without having that much software that will definetly need these features right now (or even in near future).

Where is the need to publish software before a competitor does? Where?s the competition?

Where is the advantage of MP, if there?s even no actual SDK for the final update providing the "great" feature of shared objects (which I consider really unnecessary but for plain porting and "gcc pleasant" development)?

Well, we discuss the benefits of MP and just have a half usable development system for OS4.

I don?t want to fight the thoughts about OS future of anybody here, but I want to say that we face other, much more urgent, problems that need to be solved right now and that more energy should be put on them instead using all this energy for some nice dreams about future bloatware development (sorry, can?t resist).

Greetings,

@shoe

I had these quirks recently, too. Solution was a complete re-install of the cgfx software. I used V42rc6 for this. CVPPC works flawlessy now.

Notez bien: I had no success reactivating the CVPPC by installing the CGFX V4 (CD version) software over my old installation. Only a complete reinstall with rc6 (rc5 should do the trick too) worked. Perhaps it has something to do with the OS-version installation quirks older CGFX versions had. Remember? There were problems with OS3.9 and older versions of cgfx V4, no CGFX screen modes and such.

Greetz