@Leo

Quote:

Leo wrote: Quote: And this motivates you to get up to speed in Amiga system development and join the cause to deliver an updated SANA standard? Unfortunately I am no low-level programmer. The best I have done so far is some basic C stuff. So writing driver specifications + actual implementation surely isn't for me. You have to understand everyone cannot magically become a developer.

Like all the things in life that require a certain lasting commitment, it takes determination, a certain amount of immunity to frustration and patience. I'm not trying to push you along into Amiga system development. This is hard to get into, not in the least because the available documentation is fragmented and not necessarily in the best readable shape.

But by this time, I believe every little bit helps if it succeeds in bringing more software development work to the platform. In the little time span I've written about Roadshow in diverse forums I was always struck by how much greater the demand for Amiga software getting written was than the capacity for having it written.

As I wrote on the amiga.org forum, I believe that the relation between the number of developers still working and the number of users who still actively use the platform and expect software to be created, has become unsound.

Everything else being equal, the Amiga may be one of the last platforms for which you can create software that does not require a huge investment into resources and learning complex concepts. If you understand how the Amiga operating system works, you can conveniently carry it around in your head. This is a much larger challenge with Linux, Mac OS X or other operating systems whose source code is available for review and whose architectures have been well-documented.

It may just be worth looking into AmigaOS system development work. If you can manage it, it would be conductive for further work in the fields of today's more complex operating systems. Not everybody is cut out to be a JavaScript programmer. Some people find more satisfaction in looking how the very things the JavaScript interpreter lives merely on top of are put together.

Quote:

That being said, if I was to do such a thing, I would surely make sure all 3 major AmigaOS of today would agree on a specification and all adopt it. Otherwise I wouldn't see the point... I'm against having to reinvent the wheel. I'm also against closing everything: this is what prevented the Amiga from evolving for at least a decade, and that's a shame. And I fear they wouldn't accept, not because it wouldn't be well-thought/written, but because they don't wanna open themeselves to other "camps"... Seeing some sort of non-existing enemy there.

If you build it, they will come.

Trying to herd this collection of cats that comprise the fragmented Amiga developer community will likely take much, much more effort than writing code that works, and pushing that code along until it makes everybody curious who has an interest in the field. If I'm not mistaken, this is how the Internet Engineering Taskforce develops its standards, and it is quite successful with this approach.

I don't want to sound discouraging here. It is always harder to manage a team, and keep everybody involved, and on the same page, than to crank out something all by yourself, or with the help of your buddy. This is not something unique to the Amiga.

What I'm saying is that you (as always) need to choose wisely how you deploy your resources. And sometimes it may make sense to start small, work on it until it looks good enough to share, and then come out looking for friends to play with, who can take the work further. It's often much harder to find the friends first and build something, than to build something first and then find the friends to help you along.

Last edited by olsen on 28-Aug-2010 at 11:48 AM.

@asymetrix

Quote:

asymetrix wrote: @thread maybe the asm source code to cnet device (PCMCIA SANA2 Network Card driver) is of use to developers. A bounty would be ideal. http://aminet.net/driver/net/cnetdevice.lha

Having a working driver to use for reference is a good thing. There are, as far as I know, no Ethernet drivers available for general scrutiny and experimentation, aimed at teaching you how such a driver should look like and how it ought to work. There is a slip/cslip driver, but its usefulness is rather limited.

One problem I see with the cnet.device driver is that it's source code is written in, well, an almost obsolete programming language. You can't really learn 68k assembly language out of a book any more, whereas, for example, it is still possible for the 'C' programming language.

@olsen Quote:

In the little time span I've written about Roadshow in diverse forums I was always struck by how much greater the demand for Amiga software getting written was than the capacity for having it written.

You think so? I've always felt that there has been a high pressure for Amigans to become coders, so that there is an unnaturally *high* number of developers per user. (Maybe not all great coders yet, but that's another issue.) It's not entirely without cause that someone said they thought Amigans.net was a programmer's site! (Recently many of the posts have been programming related.)

I think that the actual problem is that despite a high number of developers per user, the number of developers is still too small to meet the high expectations (in all areas) set by Windows/Mac/Linux.

IMHO the best solution is to make our existing developers more productive, which means making better tools from them to use, as well as better documentation. Sharing development effort (where possible) between different Amiga-like platforms would also help (by effectively increasing the number of developers on each platform).

Quote:

As I wrote on the amiga.org forum, I believe that the relation between the number of developers still working and the number of users who still actively use the platform and expect software to be created, has become unsound.

When you wrote this, I was never clear whether you meant there were too few developers per user, or too users per developer! From the previous quote it would appear you think there are too few developers per user? (I of course disagree with this, as stated above.)

Quote:

Trying to herd this collection of cats that comprise the fragmented Amiga developer community will likely take much, much more effort than writing code that works, and pushing that code along until it makes everybody curious who has an interest in the field.

This sounds similar to the "worse is better" theory of how C beat Lisp.

Last edited by ChrisH on 29-Aug-2010 at 01:24 PM.
Last edited by ChrisH on 29-Aug-2010 at 01:22 PM.

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

@ChrisH

Quote:

ChrisH wrote: @olsen Quote: In the little time span I've written about Roadshow in diverse forums I was always struck by how much greater the demand for Amiga software getting written was than the capacity for having it written. You think so? I've always felt that there has been a high pressure for Amigans to become coders, so that there is an unnaturally *high* number of developers per user. (Maybe not all great coders yet, but that's another issue.)

I don't know about pressure, question is who or what is causing it. If you suspect your mechanic is ripping you off, telling you somewhat plausible-sounding tales about what's causing that strangely high bill for repairing your car, you may feel some pressure to learn more about what makes your car tick, so to speak.

Quote:

It's not entirely without cause that someone said they thought Amigans.net was a programmer's site! (Recently many of the posts have been programming related.)

Or it might be because what is being discussed are subjects that are not commonly an issue with other operating systems.

As an Amiga user you are probably more likely to be familiar with the inner workings of the operating system, its tools and the applications than may be the case with other operating systems.

Although it happens, I cannot quite picture the typical Windows user needing or wanting to go beyond what the application software layer on top of the operating system offers, for example.

By necessity you have to be more crafty if you use an Amiga.

Quote:

I think that the actual problem is that despite a high number of developers per user, the number of developers is still too small to meet the high expectations (in all areas) set by Windows/Mac/Linux.

Some of the complex features found in these operating systems came about because highly productive developers in greater numbers collaborated to make them happen. While the Amiga still has productive developers, it's likely that the number of developers and the amount of time they can invest into creating software for the Amiga cannot compare to that. Maybe it's just not the number of brains involved. Hm... :-/

Quote:

IMHO the best solution is to make our existing developers more productive, which means making better tools from them to use, as well as better documentation. Sharing development effort (where possible) between different Amiga-like platforms would also help (by effectively increasing the number of developers on each platform).

This is still tough; fragmentation of the community and everything, the need to cooperate among developers isn't so great. There has been enough bad blood and turf wars, "tribalization" even.

Quote:

Quote: As I wrote on the amiga.org forum, I believe that the relation between the number of developers still working and the number of users who still actively use the platform and expect software to be created, has become unsound. When you wrote this, I was never clear whether you meant there were too few developers per user, or too users per developer! From the previous quote it would appear you think there are too few developers per user? (I of course disagree with this, as stated above.)

My point of view is that the Amiga community ought to be able to help itself. This can involve achieving greater technical competence.

In this special Amiga niche in many cases the level of technical competence is already so high that the step to become involved in software development might not be so big after all.

I know, programming is not for everyone. And not everyone is interested in building tools and application software (when I started out in 1983, my area of interest was game development, for example).

But, perhaps a little more optimistically than I may be known to be, I believe that the more software development knowledge there is to go around, the greater the chances are to have a level playing field. That is, you don't have to wait for somebody to graciously deign to look into creating a require tool, you might be able to build it yourself, or at least build it to the level which satisfies your need.

Quote:

Quote: Trying to herd this collection of cats that comprise the fragmented Amiga developer community will likely take much, much more effort than writing code that works, and pushing that code along until it makes everybody curious who has an interest in the field. This sounds similar to the "worse is better" theory of how C beat Lisp.

Could be. My idea was that curiousity is often more powerful as an incentive to get involved than merely the promise of building software that will take a while to get into shape and accomplish something. If you have an idea how to build something and start, in your own time, to apply your ideas until the result has grown enough, you might attract more help than had you started by calling for talent first.

Last edited by olsen on 29-Aug-2010 at 07:41 PM.

Quote:

Could be. My idea was that curiousity is often more powerful as an incentive to get involved than merely the promise of building software that will take a while to get into shape and accomplish something. If you have an idea how to build something and start, in your own time, to apply your ideas until the result has grown enough, you might attract more help than had you started by calling for talent first.

I agree. But most of the time, new "curious" coders don't start something from scratch, but port some existing application instead. There has been numerous SDL games being ported this way for example. And the problem is, the ports (most of the time direct recompilations) are quite buggy. And other more experienced developers do not help, but point these "crappy" ports instead... So in the end I'm not sure it's that useful. Neither for the newbie who just wanted to add one more software to the tiny Amiga library, nor to the community.

But maybe you're right and more commitment and less questioning ("can I do that ?" "Isn't it too hard ?', "I'd like to create a team for that",...) or reflexion would be useful.

_________________
http://www.warpdesign.fr/

@Leo

Quote:

Leo wrote: Quote: Could be. My idea was that curiousity is often more powerful as an incentive to get involved than merely the promise of building software that will take a while to get into shape and accomplish something. If you have an idea how to build something and start, in your own time, to apply your ideas until the result has grown enough, you might attract more help than had you started by calling for talent first. I agree. But most of the time, new "curious" coders don't start something from scratch, but port some existing application instead. There has been numerous SDL games being ported this way for example. And the problem is, the ports (most of the time direct recompilations) are quite buggy.

What else is new? When did you last see software that did not have its share of obvious flaws I do not know how much of a challenge porting SDL-based games is, but I'd be surprised if it were an easy, straightforward process. As far as programming goes, that still counts as exercising and building your skill set.

Quote:

And other more experienced developers do not help, but point these "crappy" ports instead... So in the end I'm not sure it's that useful.

Games are not necessarily "useful" either. If you're into system programming on the Amiga, I guess that you might be less interested in digging into issues related to middleware (SDL) and how ported code scrapes along in using it. It's never easy to deal with middleware which runs on a variety of platforms. Some platform specific issues are bound to cause trouble, as the original author may not be aware of platform dependencies introduced when the code was written

Quote:

Neither for the newbie who just wanted to add one more software to the tiny Amiga library, nor to the community. But maybe you're right and more commitment and less questioning ("can I do that ?" "Isn't it too hard ?', "I'd like to create a team for that",...) or reflexion would be useful.

Sometimes it helps to put into context first what you want to accomplish. If you want to learn something and possibly have fun along the way, a "top down" planning session, with all that this entails, can quickly drain all the enthusiasm you may have started out with. The alternative is to use a "bottom up" approach instead, where you can reuse existing code and ideas and build upon what you may already know. This is a better approach for experimentation, and for writing code that is not supposed to last.

Heaven beware if you try the bottom up approach for every programming task. This will only lead to trouble. But if you go beyond the experimentation and get a bit more serious about the craft, you'll learn your limits, and hopefully how to expand them ("Code Complete" by Steve McConnell may be the best book to browse or read if you want to expand your scope and abilities concerning the craft of software development).

@olsen (& Leo)

Now I''m not entirely new to Amigaprogramming or to programming in general, but what strikes me all the time is the information available. Information about various parts of the AmigaOS'' internals. It is simply quite lacking. OK, the AutoDocs do a nice job, but they are of a type ""very clear when you know what it is about"", meaning for a newbee, be it absolute or relative, it may prove very disappointing in gathering knowledge about a specific topic.
How are things related to each other? What are prerequisites in order to make a (OS-)function work as intended?
There are various archives available about ReAction examples and they do a nice job, but what about other aspects of the OS? Very hard to come by, let alone understanding it. Over the years I found various ''examples'' in archives that came from the stone age: hardly useable as they are outdated, in asm and/or simply incorrect.
I scan UtilityBase at a regular base for snippets of code and I feel a compliment is at place here for a number of contributors here like you, Olaf, for Thomas, for TBoeckel, Salass00, Corto and many, many others. It brings a relative newbee a bit further every now and then, but it still does not cut the cake. For every answer one gets, and despite the sometimes high quality of the answers, more questions often arise, leaving me to take the route of trial and error and hence, great frustration.
I think it might prove usefull if all this information was centralised in one point like UtilityBase, but when that site lets you down one may look elsewhere ( maybe the reason for Amigans.net to being flooded by programming-related threads of late?), concluding that there is a huge eagerness to program under Amigans in general, but little knowledge exists about where and how (and why so!) to start.
Currently I''m working on some 10 or 12 projects of various sizes, all ground to a halt as I lack proper information or do not understand the (scarce and/or outdated, maybe even incorrect) information available.
One of those projects concerns a way to show an Assign as a Volume on WB (out of sheer, but a strong personal desire to have such a thing available), so I try to build a handler based upon the sources of SMB-handler. To that end I posted a question on UtilityBase and got a number of answers, some more usefull then others, but actually not what I was looking for. The project has come to a halt as it crashes, locks up WB and shows other not knowingly and willingly implemented misfeatures.

To get to the point again, I would appreciate a centralised extensive, up-to-date(m/l) and robust source of information and would quite happily contribute to that source myself.

OldFart

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

@OldFart

Quote:

One of those projects concerns a way to show an Assign as a Volume on WB

Does it have to be a handler. Could it be a commodity, which would be easier to do ?

_________________
Rock lobster bit me. My Workbench has always preferences. X1000 + AmigaOS4.1 FE
"Anyone can build a fast CPU. The trick is to build a fast system." -Seymour Cray

@OldFart

Quote:

OldFart wrote: @olsen (& Leo) Now I''m not entirely new to Amigaprogramming or to programming in general, but what strikes me all the time is the information available. Information about various parts of the AmigaOS'' internals. It is simply quite lacking. OK, the AutoDocs do a nice job, but they are of a type ""very clear when you know what it is about"", meaning for a newbee, be it absolute or relative, it may prove very disappointing in gathering knowledge about a specific topic. How are things related to each other? What are prerequisites in order to make a (OS-)function work as intended?

That's why the RKMs existed. And the rights to these books are in such a legal tangle that reissuing their contents has so far not come up as a priority issue. Not that it hasn't been tried. The talk I heard always seemed to stress how old the RKM documentation is, and that much of it is no longer relevant. Sad fact, the amount of information that is still relevant oughtweighs the obsolete parts, even though the text was last published in 1991-1992. I suspect that the talk of irrelevance merely masks the fact that it's so hard to get a hold of it, so the frustration is more or less couched in putting the material down that cannot be obtained. Oh well

Quote:

There are various archives available about ReAction examples and they do a nice job, but what about other aspects of the OS? Very hard to come by, let alone understanding it. Over the years I found various ''examples'' in archives that came from the stone age: hardly useable as they are outdated, in asm and/or simply incorrect.

That's how it is. And it is frustrating. Unless you got into Amiga development while the professional level of support was still something useful, you're in for a lot of discouragement. I blame the legal wrangling and the bad contracts Commodore made when they published the RKMs and the AmigaDOS manual. It's not as if all this information went away. It even exists in electronic form. Hey, there's even an unpublished manuscript about dos.library that should have been part of the RKM Libraries, 3rd edition, which the publisher of the AmigaDOS manual persuaded Commodore not to release.

What is to be done? I'm not overly optimistic here because the work that went into OS4 already took so much effort out of the Hyperion people, but theirs is the only company for now which could lay claim to the RKM text and make something useful out of it (note the combination). There are things higher on the priority list.

But we have to have the RKM text as part of the developer support material. It's the cornerstone.

Quote:

I scan UtilityBase at a regular base for snippets of code and I feel a compliment is at place here for a number of contributors here like you, Olaf, for Thomas, for TBoeckel, Salass00, Corto and many, many others. It brings a relative newbee a bit further every now and then, but it still does not cut the cake. For every answer one gets, and despite the sometimes high quality of the answers, more questions often arise, leaving me to take the route of trial and error and hence, great frustration.

You are persistent in the face of inevitable frustration, though. The mark of a true Amiga developer

Quote:

I think it might prove usefull if all this information was centralised in one point like UtilityBase, but when that site lets you down one may look elsewhere ( maybe the reason for Amigans.net to being flooded by programming-related threads of late?), concluding that there is a huge eagerness to program under Amigans in general, but little knowledge exists about where and how (and why so!) to start. Currently I''m working on some 10 or 12 projects of various sizes, all ground to a halt as I lack proper information or do not understand the (scarce and/or outdated, maybe even incorrect) information available. One of those projects concerns a way to show an Assign as a Volume on WB (out of sheer, but a strong personal desire to have such a thing available), so I try to build a handler based upon the sources of SMB-handler. To that end I posted a question on UtilityBase and got a number of answers, some more usefull then others, but actually not what I was looking for. The project has come to a halt as it crashes, locks up WB and shows other not knowingly and willingly implemented misfeatures.

You are certainly not picking the easy tasks. Writing an Amiga file system is the most difficult challenge the operating system has to offer. It's not just the lack of documentation, there are also scores of rules and side-effects that need to be taken into account, because lots of people practiced unsound programming techniques in the past that give file systems a hard time. Some of these things come out of the limitations of the dos.library architecture, some of them are just the result of unfortunate (which is a kinder way to say "stupid") design decisions.

Quote:

To get to the point again, I would appreciate a centralised extensive, up-to-date(m/l) and robust source of information and would quite happily contribute to that source myself. OldFart

I see where this is going, and it has been going on like this for more than a decade. The pressure was never high enough to make the owners of the technology walk into the fire, to pull out the rights to the old developer documentation. What surrounds it is a tangled, ugly mess, but we have to have this documentation, eventually.

Last edited by olsen on 31-Aug-2010 at 08:41 AM.

@olsen Quote:

Heaven beware if you try the bottom up approach for every programming task. This will only lead to trouble.

Hard-core fans of eXtreme Programming would no-doubt disagree! Just refactor when the current bottom-up design is no-longer suitable... (Not that I personally advocate such an extreme view, but neither do I think the idea of designing absolutely everything up-front works well either.)

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

@ChrisH

Quote:

ChrisH wrote: @olsen Quote: Heaven beware if you try the bottom up approach for every programming task. This will only lead to trouble. Hard-core fans of eXtreme Programming would no-doubt disagree! Just refactor when the current bottom-up design is no-longer suitable...

Hey, whatever floats your boat... It makes sense to view software as malleable, but only up to the point where the complexity threatens the bring the house down.

There were big fights in the computer science community over the choice of bottom up or top down design/implementation in the 1970'ies, which left large tracts of land uninhabitable. Turns out that there is no pure bottom up/top down approach. Unless you practice the theoretical branch of computer science, you always end up blending top down and bottom up work.

Quote:

(Not that I personally advocate such an extreme view, but neither do I think the idea of designing absolutely everything up-front works well either.)

As I wrote above, it has its limits. But you are more likely to hit the ground running if you start with a small set of things that can be built upon.

@olsen

Quote:

You are certainly not picking the easy tasks. Writing an Amiga file system is the most difficult challenge the operating system has to offer. It's not just the lack of documentation, there are also scores of rules and side-effects that need to be taken into account, because lots of people practiced unsound programming techniques in the past that give file systems a hard time. Some of these things come out of the limitations of the dos.library architecture, some of them are just the result of unfortunate (which is a kinder way to say "stupid") design decisions.

I guess I must like a good challenge then , because I've just started working on a project that I've decided to call XADFileSystem (can anyone here guess what it's for?).

@OldFart

I'm not sure how you were going to implement your Assign-Handler but if you need to use dos.library calls for file i/o inside a handler/filesystem then you can't use pr_MsgPort to wait for packets but must instead create a new one for this purpose with either AllocSysObject or CreateMsgPort.

If it helps you can take a look at the current XADFS source code which I've uploaded here (not many packet types supported yet though).

@salass00

Hello salass00! I only read this thread today as it had popped past the horizon of AW.net''s frontpage.
I will look at this source of yours and try to roll muy own out of it. Thank you!

OldFart

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

@salass00

Quote:

I guess I must like a good challenge then , because I've just started working on a project that I've decided to call XADFileSystem (can anyone here guess what it's for?).

Can you say more about please ? What it will be, for what, what is differences , what is new and so on ?:)

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

@Olsen
Dunno if you right person for ask about, but: when i buy aos4.1 , and trying to use my ADSL router with it (on peg2), i always have crashes after some data are transfered in ppp-ethernet.device . As far as i remember, year ago it was common problem, and users just use static hubs-routers for (as i do), to avoid such problems with ADSL routers. Was it fixed ?

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

@kas1e

Quote:

kas1e wrote: @Olsen Dunno if you right person for ask about, but: when i buy aos4.1 , and trying to use my ADSL router with it (on peg2), i always have crashes after some data are transfered in ppp-ethernet.device . As far as i remember, year ago it was common problem, and users just use static hubs-routers for (as i do), to avoid such problems with ADSL routers. Was it fixed ?

As far as I can recall there were no reports for ppp-ethernet.device issues that prompted error reporting, research and bug fixes. So anything that didn't work so well then probably doesn't work so well now

Not knowing what happened, it's possible that the issues stem from ppp-ethernet.device problems, or the Ethernet driver. Back when I was actively using the code with my A3000UX I was either lucky, or the issues didn't exist in the context I was using it.

@OldFart

I've uploaded a slightly newer version today. This adds support for ACTION_LOCATE_OBJECT, ACTION_FREE_LOCK, ACTION_EXAMINE and ACTION_EXAMINE_NEXT as well as some other packets. Download url is the same as before.

@kas1e

@salass00

Wow that is really cool! Peeking inside an archive!!

@salass00

If i understand it right, it can be used by Filer, to create browsing/editing/packing/repacking of archives ? (did it was the main reassons for working on it ?)

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