@Mark

What about using the information found within CUPS, GutenPrint et al to write AmigaOS printer drivers with it instead of doing another half-working port of some bloated *nix subsystem?

The effort for doing the port (and, even more important, the bunch of dependencies it needs to work) would be much, much higher than doing a Amiga printer driver with the information found in the CUPS/GutenPrint open source drivers.

Regards

@freddix

Pls calm down, people only try to be helpful, even if they arent at all...

As youre a computer technician you should know that such sort of problems is very hard to judge and/or cure from the distance.

First of all, we need some more information about what exactly happened to your SAM board at the time you stored it in your bin and at the time you transported it to your friend. Maybe it was smashed to the ground accidentally?

Second, did you check the BIOS battery? Does it provide nominal voltage or is it drowned to <2.8V in the meantime? If you have some spare battery, replace it and try again. Sometimes a faulty BIOS battery may cause such a board behaviour (for the A1 machines, at least).

I dont know the SAM very good, but there should be a jumper that must be shortened in order to clear the BIOS NVRAM. If the battery change doesnt help, short it and try again.

Just my 2 cents of help...

Regards

@my_pc_is_amiga

Part-answer to question f: there where 4 player adaptors for the Amiga, connected to the parallel port of the classics. lowlevel.library supports these adaptors, and so does AmigaInput?s lowlevel.library wrapper.

There where some classic games that support 4 joysticks via lowlevel.library, too.

Regards

@orgin

*scratches head* wouldnt be the source device buffer size the optimum? I mean, you read the whole device buffer into your own buffer, so the device may use any readahead features (like sfs do) to fill the device buffer "instantly" and you will have next copy data ready to transfer into your own buffer when your write cycle is done... but what happens, if read and write device are the same?... *scratches head again*

Regards

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

Noticed another one... when using Samba shares, Filer states "No disk in drive SMBFS0" for all accesses. If I click "Cancel", it proceeds nonetheless and the file copy is okay. No real bug, but annoying

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