Amiga.org
Amiga computer related discussion => Amiga community support ideas => Topic started by: mechy on August 23, 2010, 06:36:13 PM
-
Hello all,
For a few weeks i have been talking with Olaf Barthel about releasing roadshow 68K for the amiga. He seems all for the idea for the most part but would like it if he could sell it for a reasonable price and if anyone would buy it. It would be the only current tcp/ip stack that can be registered/bought etc! His stack is quite a bit faster than both miami and amitcp as it stands,and he said it would be possible to use on 68000 (ala A600 with limited resources).Olaf expressed concern that there were no docs or mui front end currently,but i assured him someone would probabaly step up to make a gui.I think most amigans can get by with limited install docs and such.
If you want to see this happen,please reply to this thread expressing your interest so i have something to show him!
Obviously if people pirate it right off the bat and spread it and he gets no sales,he will be quite disgusted,so lets show some support by buying it,pay for the thing if it happens ok!
I suggested to him he offer it via a web download you can pay with paypal and maybe on CD for those who are want something they can touch :)
So come on everyone,lets get behind this,its not everyday the amiga might see a new,faster tcp/ip stack!
Mike
-
I would be interested, hopefully he would release cpu-specific versions of the binaries... (for 060)...
Cheers,
Dragster
-
Maybe the makers of Natami, FPGAArcade, Minimig improvements, etc, could license it for inclusion for a reasonable fee (per hardware device), and then these classic Amiga implementations would include a TCP/IP stack out of the box.
-
Hell, yes. I would love to patronize current Amiga development rather than continue to over-use my Miami registration since Holger apparently does not want my money.
As stated before, I think it would be beneficial to release CPU-specific binaries, unless there is compelling reason otherwise.
-
This sounds really interesting!
-
I also would be interested.
Regards,
Efren
-
I would be interested, hopefully he would release cpu-specific versions of the binaries... (for 060)...
Can you provide any reasons as to why there should be anything else than 68000 and 68020 binaries?
-
Can you provide any reasons as to why there should be anything else than 68000 and 68020 binaries?
Well, actually I can't, 000 version for plain 68K only and 020 version for 020+ is just fine... thanks for the clarification Piru.
Cheers,
Dragster
-
i AM interested, as long as it wouldnt cost the world (within 10eur) which is i think fair, but it should have some sorta options gui if it is going to be commercial release.
-
Olaf has not mentioned any pricing yet,but i expect it to be reasonable.Again this all hinges on the people interested and who are willing to buy it.Just to clarify this uses exhisting SanaII drivers.
-
A newer network stack for classics would indeed be no bad thing.
-
I'd also be interested.
kevin
amigau.com
-
I'd pay for this. Would prefer a hard copy CD.
-
Count me in! I've been waiting years for this and in fact I have already inquired about it.
-
Can you provide any reasons as to why there should be anything else than 68000 and 68020 binaries?
It may not add up to much, but with instruction scheduling enabled in the code generator, the '060 binary should do better than the plain '020 binary.
-
To add a few more facts to the mix: chances are that there will not be a GUI. In fact, it was tough to get a GUI made in the first place, and in the second and the third place, too. I tried three times to get this project off the ground and it was always the GUI development work which stalled it.
Instead of the GUI you'd be tinkering with configuration files, just like with AmiTCP in the old days. The difference this time being that Roadshow automatically rereads the config files after you have modified them. You won't have to restart the network just to make the changes stick.
As for documentation, I'd have to write a basic cookbook on how to set up and use Roadshow first. On top of that, there's always the SDK and the existing documentation for the individual shell commands and configuration files.
I have no idea what to do about the distribution yet. It could be a download from a web site, it could be mailed out on a CD-ROM. What would you prefer?
As for reasonable pricing, I haven't got the foggiest what a reasonable price would be. The nominal 10€ are at the lower edge of what I would consider reasonable. What amount would you consider reasonable?
-
I have no idea what to do about the distribution yet. It could be a download from a web site, it could be mailed out on a CD-ROM. What would you prefer?
As for reasonable pricing, I haven't got the foggiest what a reasonable price would be. The nominal 10€ are at the lower edge of what I would consider reasonable. What amount would you consider reasonable?
For me 10€ for a downloadable version would be very reasonable, i was not even intrested about this from the beginning but at that price it can be worth it even if i mostly use my OS4 machine nowdays.
-
It may not add up to much, but with instruction scheduling enabled in the code generator, the '060 binary should do better than the plain '020 binary.
It may, but as you know it is totally irrelevant for something as I/O bound as TCP/IP stack.
The performance difference I've seen between 020 and 060 optimized code has always been insignificant. This was, however, before gcc3/gcc4 so perhaps things have improved since then.
-
It may, but as you know it is totally irrelevant for something as I/O bound as TCP/IP stack.
The performance difference I've seen between 020 and 060 optimized code has always been insignificant. This was, however, before gcc3/gcc4 so perhaps things have improved since then.
Though the code builds with GCC, I haven't tried any of the newer 68k compilers yet. From what I hear the GCC 68k branch is not in quite as much demand as the other, more modern embedded processors. This does not bode well for the quality of the code generated. One more reason to stick with what has worked for more than a decade: SAS/C 6.59.
Building an '060 version probably doesn't hurt, though. If it's that what convinces the curious to become customers, who am I to doubt the wisdom in it?
-
To OP
Hey this is really interesting news and a feat to get it so close to a potential release! This should have been done 4+ yrs ago imho.. Well i'm sure the Amiga community would embrace it and there naturally will be sales. Optimized versions for OS4 and Morphos would be nice and a gui is a must.
-
To OP
Hey this is really interesting news and a feat to get it so close to a potential release! This should have been done 4+ yrs ago imho.. Well i'm sure the Amiga community would embrace it and there naturally will be sales. Optimized versions for OS4 and Morphos would be nice and a gui is a must.
Roadshow is the TCP/IP stack in OS4. Don't hate me, but contractual obligations prevent me from releasing a MorphOS version, even if I were able to make one. I can make and sell only the 68k version.
-
I'm all for it Olaf. I'd happily pay up to 15eu for the download version. Will it support multiple net interfaces like MiamiDX does?
-
I'm all for it Olaf. I'd happily pay up to 15eu for the download version. Will it support multiple net interfaces like MiamiDX does?
You can configure as many "physical" interfaces as the hardware and the driver units permit, and you can assign multiple IPv4 addresses to each network interface, too.
The only restrictions regarding the interfaces are in the length of the interface name (15 characters max; this is a limitation of the original 4.4BSD kernel code), and you cannot have two interfaces share the same SANA-II device and unit number.
Network interfaces are configured like "mount files", i.e. you set up the device name, the unit number, and optional IPv4 address, etc. in a file which goes into "DEVS:NetInterfaces". These files are read and processed as part of the S:Startup-Sequence, which means that as soon as you see the Workbench opening, your network connection can be up and running.
-
Sounds great, just like the os4 roadshow version works minus the gui. That's cool. I hope you decide to release it, I'll buy it as I can really only speak for myself, but I think you'll get a good amount of sales.
-
Hi!
If the price (at least for the dowloadable version) stays between 10 and 15 EUR, I think it would be ok almost for everybody (hoping that price is "resonable" for Olaf as well :) ).
I think it's very good to offer plain 68k support, even if with some limitations: I remember when I configured AmiTCP on my Amiga 500 with hard disk go to on the Internet in 1995!
It was great somehow! :D
Many people will appreciate! (A600 users especially)
The only complain is, of course, the lack of GUI: but if config files are plain ASCII or in a documented format, I think someone will provide a free option in the future.
Thanks for your work, Olaf!
-
Why would need it for MorphOS anyway, we have already got a stack
-
I would buy it IF I can keep it running while playing whdload games
-
@utri007
good thought! How about it Olaf? Is it something you can do about it or is it something the whdload developers should fix?
-
For a download version I think 15 EUR would be reasonable, add a bit to that if someone prefers a CD.
-
@olsen
I believe roadshow (at least for OS4) got rid of the following two limitations of other amiga TCP stacks:
- bsdsocketbase couldn't be shared, and bsdsocket.library had to be opened in each process.
- sockets couldn't be shared across threads.
First, is it right?
Second, as I have no idea if it also needs special support on the OS side itself, would the 68k version of roadshow also provide this?
-
Why would need it for MorphOS anyway, we have already got a stack
I only mentioned it because the question did come up before, and there was a demand for a TCP/IP stack. Given that Roadshow outperformed AmiTCP under identical circumstances it wasn't hard to expect that it could have done the same under MorphOS.
-
Don't hate me, but contractual obligations prevent me from releasing a MorphOS version, even if I were able to make one.
Interesting contract.
-
@utri007
good thought! How about it Olaf? Is it something you can do about it or is it something the whdload developers should fix?
I don't know why WHDLoad does not permit a TCP/IP stack to be active while it runs. Since both AmiTCP and Miami are apparently not supported, it might well be that the mere presence of a TCP/IP stack would be an issue. But then I do not know the technical background or justification behind this.
-
Interesting contract.
*Tactically* interesting contract, actually.
-
@olsen
I believe roadshow (at least for OS4) got rid of the following two limitations of other amiga TCP stacks:
- bsdsocketbase couldn't be shared, and bsdsocket.library had to be opened in each process.
- sockets couldn't be shared across threads.
First, is it right?
These limitations came out of the design of the original AmiTCP implementation. In Roadshow I found a way to avoid these specific limitations, but by default Roadshow still keeps enforcing them.
Client software can disable these limitations through API functionality quite easily, and this is what, for example, newlib.library on OS4 will do by default. The reason for keeping the limitations enabled is that I wanted to maintain backwards compatibility with how AmiTCP and Miami behaved when sockets and the library base were shared by different Processes. Roadshow consistently flags any such attempts as errors. But if the client software knows what it's doing, it can override this "protection".
Second, as I have no idea if it also needs special support on the OS side itself, would the 68k version of roadshow also provide this?
This is purely a feature of the TCP/IP stack implementation, or rather a side-effect, and is not rooted in operating system features.
-
I don't know why WHDLoad does not permit a TCP/IP stack to be active while it runs. Since both AmiTCP and Miami are apparently not supported, it might well be that the mere presence of a TCP/IP stack would be an issue. But then I do not know the technical background or justification behind this.
The interrupts generated by the network hardware I believe.
-
*Tactically* interesting contract, actually.
Much like the Directory Opus Magellan deal, except this one worked.. ;-)
-
It may, but as you know it is totally irrelevant for something as I/O bound as TCP/IP stack.
The performance difference I've seen between 020 and 060 optimized code has always been insignificant. This was, however, before gcc3/gcc4 so perhaps things have improved since then.
A 68060 version should be better than a 68020 version for the 68060 if the compiler can...
1) schedule instructions for the 68060
2) avoid missing trapped instructions (64 bit integer instructions only if no fp)
3) prefer instructions that work in both integer units of 68060
Most compilers generating 68060 code will do better with 1 & 2 while few understand 3 even though it can speed code by up to 2x alone. I would say a 68060 version is still justified for reasons 1 and 2. Separate 68000, 68020, 68040 and 68060 versions would be nice for stable major releases.
@olsen
GCC3 and GCC4 generate worse code than SAS/C. Switching to any other compiler for a 68k only release would be a waste of time IMHO.
I'm somewhat interested in RoadShow but I'm wary of orphaned programs with no bug fixes or source code available. Although you are a great Amiga stalwart, I would like some kind of future plan for the continuation of the product with or without you. I like the idea of a more reasonable price as a download from a website with a PayPal buy it now link. It's not that difficult to do anymore. I would buy the newest CED if it was distributed this way and was 1/2 the cost also.
-
A 68060 version should be better than a 68020 version for the 68060 if the compiler can...
1) schedule instructions for the 68060
2) avoid missing trapped instructions (64 bit integer instructions only if no fp)
3) prefer instructions that work in both integer units of 68060
Most compilers generating 68060 code will do better with 1 & 2 while few understand 3 even though it can speed code by up to 2x alone. I would say a 68060 version is still justified for reasons 1 and 2. Separate 68000, 68020, 68040 and 68060 versions would be nice for stable major releases.
This is the theory, indeed. In practice, however, I've never seen any real benefits in toggling between 020, 030 040 or 060 targets when running the code on 060. Even the case 2 is handled by Cyberpatcher.
In most cases the C compiler produces adequate results as long as you tell it to produce 020+ code. Back when I was still into 68k I used SAS/C and gcc and checked out the code produced for performance issues. It was quite awful. Even when I told gcc to produce code for 060 it would still use the instructions that would get generate an exception. The generated code had no sensible scheduling. If I really needed the speed I optimized the critical part(s) by hand.
-
@olsen
GCC3 and GCC4 generate worse code than SAS/C.
That was to be expected. GCC seems to have a slant towards the x86 platform these days. Other architectures receive far less attention. I recently read that because the quality of the code produced for embedded platforms such as ARM and PPC left so much to be desired, more and more commercial developers went with the compilers provided by the hardware vendors. Apple's support for the LLVM compilers also speaks for itself.
Switching to any other compiler for a 68k only release would be a waste of time IMHO.
The warnings flagged for the code are sometimes more helpful than what SAS/C manages to produce (and the other way round, actually). But I wouldn't want to use the old GCC I have at hand for high performance production code.
I'm somewhat interested in RoadShow but I'm wary of dwarfed programs with no bug fixes or source code available.
If it's any consolation, Roadshow has been used in OS4, and has evolved with it, for the past 8-9 years.
Although you are a great Amiga stalwart, I would like some kind of future plan for the continuation of the product with or without you.
Yes, this is how it ought to be. It didn't help that Holger Kruse suddenly dropped out of the picture with Miami, did it? As for my own plans, I admit that until about two weeks ago I did not have any for Roadshow 68k any more. So, give me a little time and a few ideas to wrestle with, and maybe I'll be able to come up with a long term perspective for Roadshow.
I like the idea of a more reasonable price as a download from a website with a PayPal buy it now link. It's not that difficult to do anymore. I would buy the newest CED if it was distributed this way and was 1/2 the cost also.
CygnusEd comes on a physical CD-ROM, each one specially made for the customer. There's a price tag for shipping, too, and the CD-ROM acts as something of a weak "copy protection". Meaning that updates & patches are based upon what's on the CD-ROM.
So, you suggest changes may be a good thing? I'm currently working on getting the next CygnusEd out the door. Something which I neglected to attend to in the past few years, on account of severe Amiga burnout.
-
There have been cheap offers for amigaish programs lately, and when it's stayed around 10e, I've bought them even if I don't need it that much. I think it's a good tactic in today's situation.
That 10e, for example, is cheap enough to attract even occasional Amiga triers to buy the software instead of pirating or giving up. At least when it's easily available (web download, paypal). And also for long time Amiga hobbyists, who are thinking if it's worth to buy new software or stick with old options.
I don't think there are that much heavy users who are willing to pay tens of euros anymore. Low price and availablility would benefit whole Amiga community, and I believe author too, better than rarely bought expensive product.
I'm happy with AmiTCP/IP Genesis on my classic Amigas with my current usage, but if it will be around 10e I'll promise to buy it anyway :)
EDIT: same apply to CED too. I've been thinking of buying later version, but it's just too expensive in current form and situation (I bought CubicIDE when it was on <20e offer, but I'd rather use CED ;)).
-
Add me to the list of people interested!!
-
I really don't see the point, yet another utterly limited and primitive IP stack for Amiga, and also this time one is supposed to pay for it - why bother?
Edit: The only thing I'd be willing to pay for, is for the sources to be released under open source license.
I strongly refuse to pay for binaries when it comes to Amiga these days, not because I cannot afford it, but because I have experienced how painfull it is with these binaries after relatively short time, as authors abandon them.
-
I really don't see the point, yet another utterly limited and primitive IP stack for Amiga, and also this time one is supposed to pay for it - why bother?
Currently it is impossible get any TCP/IP stack for real Amigas unless you pirate Miami. Better than not having TCP/IP stack at all although I dont think there are many users left... WinUAE users wont need it.
Another option would be porting MosNet/AROS TCP but I dont see it happening either...
-
Currently it is impossible get any TCP/IP stack for real Amigas unless you pirate Miami.
Actually that is not the case. GPL AmiTCP/IP is available (AmiTCP-bin-30b2.lha).
-
Currently it is impossible get any TCP/IP stack for real Amigas unless you pirate Miami.
Really? What, AmiTCP 2.3 suddenly no longer works? Or AmiTCP3.0beta2 or whatever it ended up on.
-
Building an '060 version probably doesn't hurt, though. If it's that what convinces the curious to become customers, who am I to doubt the wisdom in it?
Or you could just name a binary "roadshow-060" and pad it with a few bytes to fake some people out ;)
The WHDLoad problem is interesting as well and, as Piru said, I recall the issue is a matter of interrupts.
My primary concern with a new TCP/IP stack is the ability to set up PPTP VPNs with encryption, and fairly easily. I can do this with MiamiDX, but I cannot encrypt the tunnel and I cannot change target hosts very easily.
-
To add a few more facts to the mix: chances are that there will not be a GUI. In fact, it was tough to get a GUI made in the first place, and in the second and the third place, too. I tried three times to get this project off the ground and it was always the GUI development work which stalled it.
Instead of the GUI you'd be tinkering with configuration files, just like with AmiTCP in the old days. The difference this time being that Roadshow automatically rereads the config files after you have modified them. You won't have to restart the network just to make the changes stick.
As for documentation, I'd have to write a basic cookbook on how to set up and use Roadshow first. On top of that, there's always the SDK and the existing documentation for the individual shell commands and configuration files.
I have no idea what to do about the distribution yet. It could be a download from a web site, it could be mailed out on a CD-ROM. What would you prefer?
As for reasonable pricing, I haven't got the foggiest what a reasonable price would be. The nominal 10€ are at the lower edge of what I would consider reasonable. What amount would you consider reasonable?
Regarding GUI, is there a technical limitation preventing the back-porting of OS4's Internet prefs? Or were you thinking along the lines of something more work-intensive, like a full Genesis/Miami-style GUI?
I have always found your documentation to be absolutely excellent. :)
-
Really? What, AmiTCP 2.3 suddenly no longer works? Or AmiTCP3.0beta2 or whatever it ended up on.
Genesis was pirated by H&P when AmigaOS 3.9 was produced. Pirating AmiTCP is no better than pirating Miami.
-
Genesis was pirated by H&P when AmigaOS 3.9 was produced. Pirating AmiTCP is no better than pirating Miami.
AmiTCP versions prior to v4 were released under the GPL.
-
@kolla & Piru
Really? What, AmiTCP 2.3 suddenly no longer works? Or AmiTCP3.0beta2 or whatever it ended up on.
Oh, forgot about AmiTCP 3. But aint it quite old (IIRC MOSNet is based on it but was improved?) and difficult to install? I remember I tried AmiTCP when I was newbie and couldnt get anywhere... luckily Miami was released only few weeks earlier.
-
The interrupts generated by the network hardware I believe.
In the mean time I learned a bit how this goes wrong. WHDLoad apparently has to shut down most of the operating system while it runs, and killing off the int2/int6 handlers won't be enough for some hardware that requires a handler to go after the cause of an interrupt signal. If that kind of handler doesn't get invoked, the interrupt sticks and the system will hang.
-
There have been cheap offers for amigaish programs lately, and when it's stayed around 10e, I've bought them even if I don't need it that much. I think it's a good tactic in today's situation.
That 10e, for example, is cheap enough to attract even occasional Amiga triers to buy the software instead of pirating or giving up. At least when it's easily available (web download, paypal). And also for long time Amiga hobbyists, who are thinking if it's worth to buy new software or stick with old options.
I don't think there are that much heavy users who are willing to pay tens of euros anymore. Low price and availablility would benefit whole Amiga community, and I believe author too, better than rarely bought expensive product.
I'm happy with AmiTCP/IP Genesis on my classic Amigas with my current usage, but if it will be around 10e I'll promise to buy it anyway :)
EDIT: same apply to CED too. I've been thinking of buying later version, but it's just too expensive in current form and situation (I bought CubicIDE when it was on <20e offer, but I'd rather use CED ;)).
I can see your point, and while I can see the sense in it, it leaves me, as an author, unsatisfied. Most of the fun to be had in writing software comes (at least for me) out of actually writing the code and building something useful. If I can convince somebody to give me something in return for the work I did, I would be happier than if I had just constructed something marvelous for my own enjoyment. And 10€ is a little too little for that. If I'm going to release Roadshow 68k, I believe that whoever paid for it is entitled to updates, bug fixes and support. This won't pay for itself. Same thing for CygnusEd, which I admit I have neglected for too long.
-
I really don't see the point, yet another utterly limited and primitive IP stack for Amiga, and also this time one is supposed to pay for it - why bother?
Edit: The only thing I'd be willing to pay for, is for the sources to be released under open source license.
I strongly refuse to pay for binaries when it comes to Amiga these days, not because I cannot afford it, but because I have experienced how painfull it is with these binaries after relatively short time, as authors abandon them.
It takes effort and some highly specialized knowledge to port an old TCP/IP stack to the Amiga and make it compatible with the AmiTCP V3 API. This can be done in less than a month, in two weeks even.
If you were to try, I daresay you'll spend a lot of time solving one of the major complicated puzzles practical software engineering can throw at you. This can be fun and rewarding all by itself, or at least that's how I felt about it.
Problem is, this isn't the kind of challenge that just about anybody meets gladly and is satisfied to have overcome. Some people want their work to be seen, acknowledged, and they want to assume responsibility for it. I'm one of these guys.
The point of discussing how and if Roadshow 68k might be released was to find out who would want to give me, author, something in return for the work I did, and how that "something" could look like.
I take it you are less interested in these aspects of the process, and, well, you don't have to be.
If there is a need for another free TCP/IP stack for the Amiga that does better than the old AmiTCP and Miami products do (in your words, is not another primitive TCP/IP stack for the Amiga), has a completely free and open source code, it seems that it has not been satisfied. It could be that the amount of magic & energy it takes to make one of these things is just not present in the Amiga community any more.
So the next best thing you could get is this non-free, closed source primitive TCP/IP stack I've failed to find a way to release for the 68k platform in almost ten years. It could be much worse: nobody could care any more.
-
Really? What, AmiTCP 2.3 suddenly no longer works? Or AmiTCP3.0beta2 or whatever it ended up on.
Sorry, AmiTCP 2.x barely works in the first place. AmiTCP V3 is hardly a feature complete package. It shows its age, and the knowledge required to make it work is beyond what most people would feel comfortable about. Try connecting to an ADSL modem using AmiTCP V3 without frustration pouring out of you.
There has to be a better way to do this.
-
Regarding GUI, is there a technical limitation preventing the back-porting of OS4's Internet prefs? Or were you thinking along the lines of something more work-intensive, like a full Genesis/Miami-style GUI?
I have always found your documentation to be absolutely excellent. :)
I do not own the rights to the OS4 internet prefs or the dialer GUI. This is the essential obstacle. Porting it may be possible, but the first stumbling block are the rights issue.
What I tried to make happen is to have a feature complete management and dialer GUI written for OS 3.x. This turned out to be too much of a challenge. Designing interactions is hard, and writing a set of programs around an interaction design is even harder on the Amiga. It still is today, it was ten years ago.
-
AmiTCP V3 is hardly a feature complete package. It shows its age, and the knowledge required to make it work is beyond what most people would feel comfortable about. Try connecting to an ADSL modem using AmiTCP V3 without frustration pouring out of you.
It is somewhat complicated, but luckily there's a great guide about it:
http://www.acc.umu.se/~patrikax/amiga/guides/AmiTCP_Install/
-
Try connecting to an ADSL modem using AmiTCP V3 without frustration pouring out of you.
Right... what's an ADSL modem again? It's like complaining about how much it sucks at ISDN, really.
There has to be a better way to do this.
Yes, join forces, put aside old difference and nickpickings, set up a working group for implementing an open and modern TCP stack for all Amiga plattforms.
Just to be blunt, how much would be enough for you to hand out Roadshow sources?
-
It is somewhat complicated, but luckily there's a great guide about it:
http://www.acc.umu.se/~patrikax/amiga/guides/AmiTCP_Install/
Now that's typical :-( I wish I had know about this more than 10 years ago. I actually figured this out by myself, through trial & error, and while I learned something along the way, it was not a happy experience.
-
I would think the majority of people these days use an adsl router, so amitcp can do the job ok. Back when roadshow was first announced, I would have been interesting perhaps in purchasing it perhaps, although I did already buy miami (far too much money!).
If it was to become open source, then I would contribute to a fund for that though for example. This would guarantee availability for the future, and allow people to improve on it if they desire. Guess that's not possible contractually for you, but just to say where my feelings are.
Seems there are plenty who are interested though, so I hope it goes well.
-
@olaf:
i understand your pov about the distribution very well, but you, a coder, also have to take how users see it into account. having released your stack a few years ago not only you would prevent the severe misuse of miami licences and in the end sell more units but could also demand more money per licence i think. i dont understand what was stopping you to do so all the time? contacts again? but good thing that it has changed. nevertheless seing it in relation, if an operating system (featuring a tcp stack) is calculated around 100eur then a stack alone would be fair to be in a 10eur range. heck, i would pay 14,99 ;PD, for the sake of it even if i have no router to connect my amis just now. see the genuine amigan loyality.
-
Yes, join forces, put aside old difference and nickpickings, set up a working group for implementing an open and modern TCP stack for all Amiga plattforms.
Just to be blunt, how much would be enough for you to hand out Roadshow sources?
I second this, but in Amiga (stupid) land, things like this never happen, which is part of the reason I moved on in many ways. It's not always the case of course, there are a handful of decent open source cross amiga platform apps, but tis not the norm
-
@olaf:
i understand your pov about the distribution very well, but you, a coder, also have to take how users see it into account. having released your stack a few years ago not only you would prevent the severe misuse of miami licences and in the end sell more units but could also demand more money per licence i think. i dont understand what was stopping you to do so all the time?
It was the old story: boy meets girl, boy loses girl...
Wait, it was different old story, which went like this: bottom drops out of the Amiga market, harder than usual this time, companies you did consulting work for during the last 10 years go bust, an old friend and collaborator dies of a cardiac arrest, and you find out how hard it can be to overcome a burnout.
Sometimes you eat the bear, and sometimes, well, he eats you.
contacts again?
I'm more comfortable viewing it as a stroke of prolonged bad luck and burnout.
-
Right... what's an ADSL modem again? It's like complaining about how much it sucks at ISDN, really.
Yes, join forces, put aside old difference and nickpickings, set up a working group for implementing an open and modern TCP stack for all Amiga plattforms.
The need to have one of those doesn't seem to have woken up the people capable and willing to create it yet. Call me pessimistic, but from my experience a genuine need to have a solution for an urgent problem tends to attract the people who solve it. And if that hasn't happen yet, it's because the need isn't as great as you may feel it is.
Just to be blunt, how much would be enough for you to hand out Roadshow sources?
Well, if I were free to give it away, which I am not, I wouldn't sell it. I would give it away. Not everything is just for sale. Where would be the fun in that?
I'm not looking to get rich, it just bothers me that Roadshow never made it into the hands of the people who would have found it useful, and I never got the kind of feedback for it which I would have gotten if Roadshow had been properly released.
-
I honestly think that a 15-20 euros price range is not much for a lightweight and fast tcp-ip stack that'll be actually supported.
-
I'm very interested, has my full support :)
-
It is somewhat complicated, but luckily there's a great guide about it:
http://www.acc.umu.se/~patrikax/amiga/guides/AmiTCP_Install/
This is exactly the guide I was looking for in a previous thread. Now to find the thread :lol:
-
Wait, it was different old story, which went like this: bottom drops out of the Amiga market, harder than usual this time, companies you did consulting work for during the last 10 years go bust, an old friend and collaborator dies of a cardiac arrest, and you find out how hard it can be to overcome a burnout.
Sometimes you eat the bear, and sometimes, well, he eats you.
I hope you didn't mean HF passed away. Haven't heard of him for a very long time now. Anyway, five or six years ago I would have written your MUI frontend easily... but you know yourself, as time passes, so does the past... still a shame to see the Roadshow "If you liked the demo buy the real thing" requester popping up, when I forget to start up Miami...
I really hope you'll find enough supporters to get your fine product out on the streets. It deserves to be used.
-
And if that hasn't happen yet, it's because the need isn't as great as you may feel it is.
I don't think there is much of a need, since amiga people are blatantly ignorant about the entire networking thing. Till the day their oh so beloved supermodern browser, be it OWB or TimberWolf, stops working that is. I'm just saying that I don't see much point in Roadshow either at this point, what does it bring to the table that one cannot do already with old AmiTCP? Is it really that much better? What features are there? Will you continue to develop it, like some people here seem to think? If so, what is the road.. heh.. map?
In my view Hyperion are fools to think they can continue to maintain an IP stack in-house, they also have plenty of other things to worry about, like USB stack and whatnot.
Well, if I were free to give it away, which I am not, I wouldn't sell it. I would give it away. Not everything is just for sale. Where would be the fun in that?
Indeed, where is the fun in that - let me rephrase the question - how much would it cost to buy out Roadshow from whoever own it, Hyperion I presume?
I'm not looking to get rich, it just bothers me that Roadshow never made it into the hands of the people who would have found it useful, and I never got the kind of feedback for it which I would have gotten if Roadshow had been properly released.
What, OS4 users don't offer good enough feedback? Shocking! :roflmao:
-
It was the old story: boy meets girl, boy loses girl...
Wait, it was different old story, which went like this: bottom drops out of the Amiga market,
Speaking of Amiga market wouldnt it be better create bounty to release RoadShow/68k binaries for free? No need to worry about piracy, shipping costs, CD duplication or wondering if there will be enough buyers.
-
What, OS4 users don't offer good enough feedback? Shocking! :roflmao:
well, you configure it when installing the OS , after that it works in the background doing it's thing. it's not exactly in your face all the time, "sadly" for Olsen it works too good hence no feedback.
but i'll take this opportunity and thank Olsen for a great stack that "just works", thanks.
-
well, you configure it when installing the OS, after that it works in the background doing it's thing.
Right, and OS4 users aren't crazy enough to try using their machines as routers or bridges, sharing uplinks, having multi homed systems, sharing media from their machines over DLNA etc. At least I have used my A3000 as a router once :)
-
Right, and OS4 users aren't crazy enough to try using their machines as routers or bridges, sharing uplinks, having multi homed systems, sharing media from their machines over DLNA etc. At least I have used my A3000 as a router once :)
no, a standalone router is better suited and more energy effecient...besides, amigaos isn't a server os as you probably know.
-
no, a standalone router is better suited and more energy effecient...
How is running a router and an OS4.1 computer more energy efficient than just running an OS4.1 computer?
besides, amigaos isn't a server os as you probably know.
In my view there is no "server OS", that's just a term certain people invented in attempts to justify the shortcommings in their beloved system. Once you have a machine online, noone cares if the OS you're running is "server os" or not, it's what you do with it that matters, and shuffling around traffic as a router or bridge does not even sort under "server" activities.
-
and I never got the kind of feedback for it which I would have gotten if Roadshow had been properly released.
Does this mean you didn't get the expected feedback from OS4 Roadshow version ?
-
How is running a router and an OS4.1 computer more energy efficient than just running an OS4.1 computer?
it isn't...you would have to run os4.1 as a router to for my thesis to work.
In my view there is no "server OS", that's just a term certain people invented in attempts to justify the shortcommings in their beloved system. Once you have a machine online, noone cares if the OS you're running is "server os" or not, it's what you do with it that matters, and shuffling around traffic as a router or bridge does not even sort under "server" activities.
well calling it server os or not is quicker to type, yes?
-
I'm game.
-
How is running a router and an OS4.1 computer more energy efficient than just running an OS4.1 computer?
When your ADSL modem is built into your router, you don't really have much alternative. Besides, most people have more than one networked device. Who would want to run a full computer to service them all when a compact little router does the job for a few watts of power?
-
Most if not all broadband modems can be configured to operate as bridges. That's what I've always done. All moden SOHO routers support PPPoE, physical address spoofing, and all the other bits you need to work around your ISP's inane access policies. If your ISP is relying on your default use of their equipment and attempting to "manage" your service at the end point, well, they're being silly, especially if you own the equipment.
@olsen
I'd pay for it, in part as a thank you for all the help you provide re: other Amiga madness in your spare time.
Re: 68060, if the stack spends a relatively high amount of time computing checksums, a pipeline optimized checksum would be great. That same routine should run on other CPUs without issues, albeit linearly, yes?
-
When your ADSL modem is built into your router, you don't really have much alternative. Besides, most people have more than one networked device. Who would want to run a full computer to service them all when a compact little router does the job for a few watts of power?
This is getting totally side tracked, but some points...
* not every Amiga in the world is connected via ADSL (sheesh)
* many m68k Amiga systems do not have ethernet
* many m68k Amiga systems have alternatives, floppy link, ARCNet, parnet etc.
* to get those online, you typically end up using an Amiga with ethernet as a router or bridge between the various oddball links - a typical "standalone router" will not suffice.
* routing traffic is not "serving", it's something any half decent IP stack is supposed to be capable of.
-
* not every Amiga in the world is connected via ADSL (sheesh)
I guess I'm one of the lucky ones ;)
All my "used more than once in a blue moon" Amigas have a NIC in them. Only my not-working A600 is presently without one.
If I ever needed to use them all at once online though, I'd need an extra switch :lol:
-
I guess I'm one of the lucky ones ;)
Heh, that's funny - I meant it the other way around, not all Amiga users are unlucky enough to have to suffer from the misbehaviour that ADSL causes :lol:
-
@Olsen
I remember an article written during or near the end of Roadshow 68K development years ago. It was well written and spoke of how development process started with looking at the only available examples (AmiTCP sources?)
Do you remember the article? Perhaps you wrote it. It was a good read, I should have saved it. I remember emailing the author at the time about purchasing Roadshow 68K. I think it was released as part of a monthly Amiga.com update or something available for club members to read. Do you still have it?
-
Heh, that's funny - I meant it the other way around, not all Amiga users are unlucky enough to have to suffer from the misbehaviour that ADSL causes :lol:
Well, AmiTCP on the classic machines and Roadshow on the OS4 box never gave me any problems with my router. It's true that AmiTCP doesn't do DHCP, but all I did was to reserve IP addresses for all the devices that are permanently on the network that the classics might have to talk to and leave anything transient to get whatever address DHCP wants to give it out of what's left.
-
If there is a half-decent Amiga IP stack for sale, I'm in...
No GUI is no issue IMHO... if configuration is done using a command in startup-sequence and one or two config files in a logical manner (eg. like FreeBSD or Redhat) it's much more straightforward that a badly created GUI. Genesis is still driving me crazy ;)
-
I don't think there is much of a need, since amiga people are blatantly ignorant about the entire networking thing. Till the day their oh so beloved supermodern browser, be it OWB or TimberWolf, stops working that is. I'm just saying that I don't see much point in Roadshow either at this point, what does it bring to the table that one cannot do already with old AmiTCP?
I personally thought it was less of a headache to set up, and it has a couple of features which other TCP/IP stacks, owing to their age, could not bring to the table. Roadshow was the kind of software I needed myself, as I was dissatisfied with the existing offerings. Building the thing also was an interesting experience. I was curious how an Amiga TCP/IP stack worked, and watching it get faster as the code improved was rewarding all by itself.
Is it really that much better? What features are there? Will you continue to develop it, like some people here seem to think? If so, what is the road.. heh.. map?
Nothing is ever certain. I'm not going to walk away from Roadshow, and how it evolves depends upon the user feedback. If you don't know what it takes to make a better product, it probably won't become one.
In my view Hyperion are fools to think they can continue to maintain an IP stack in-house, they also have plenty of other things to worry about, like USB stack and whatnot.
Gee, you seem to have the wrong idea how OS4 is developed. While Hyperion has in-house developers working on the product, at least half of the work being done on the whole package is contributed by third party developers.
Indeed, where is the fun in that - let me rephrase the question - how much would it cost to buy out Roadshow from whoever own it, Hyperion I presume?
I own it alright. It's just that I am contractually restricted from doing with it whatever might strike my fancy. There are limits to what I can do.
What, OS4 users don't offer good enough feedback? Shocking! :roflmao:
More people can run 68k software than can run OS4. Even if each member of each groups (or sets; one being a superset of the other) were to come up with one bug report and one enhancement request each, the amount of feedback to come from OS4 users would still be very small by comparison.
-
Speaking of Amiga market wouldnt it be better create bounty to release RoadShow/68k binaries for free? No need to worry about piracy, shipping costs, CD duplication or wondering if there will be enough buyers.
Once it's free, who is going to take care of it? For free? This won't be as much fun as having some sort of carrot providing an incentive to keep pulling the cart.
-
Does this mean you didn't get the expected feedback from OS4 Roadshow version ?
I probably got just the amount of feedback to be expected. Since the number of OS4 users is smaller than the total number of users who can and would run a 68k TCP/IP stack, I did not receive as much feedback as I could have gotten.
-
Re: 68060, if the stack spends a relatively high amount of time computing checksums, a pipeline optimized checksum would be great. That same routine should run on other CPUs without issues, albeit linearly, yes?
The IP checksum calculation and verification function already is highly optimized and written in 68k assembly language (I borrowed it from NetBSD). But due to how the algorithm works, it's hard to avoid pipeline stalls altogether. It comes down to fetching one word at a time, adding it to the accumulator and checking for carry.
While the checksumming code certainly contributes to the performance, speed comes from how fast you can move data to/from the network I/O requests into/out of the TCP/IP stack's internal data structures. I'm lucky to have found one of the fastest copying routines to do this job.
-
@Olsen
I remember an article written during or near the end of Roadshow 68K development years ago. It was well written and spoke of how development process started with looking at the only available examples (AmiTCP sources?)
Do you remember the article? Perhaps you wrote it.
It's likely that I did. I also wrote the article about the FastFileSystem reimplementation I was was responsible for.
It was a good read, I should have saved it. I remember emailing the author at the time about purchasing Roadshow 68K. I think it was released as part of a monthly Amiga.com update or something available for club members to read. Do you still have it?
I'd have to dig. While I never throw stuff away, it's sometimes an issue to figure out where it ended up. Currently, all my old data sits on a NAS system at home. But once you've gone beyond 28 GBytes of Amiga-related data that have accumulated over some 25 years, it becomes difficult to locate anything...
-
First of all I would like to congratulate you to your work and thank you for your decision to continue support for the 68K AMIGA line!
While the checksumming code certainly contributes to the performance, speed comes from how fast you can move data to/from the network I/O requests into/out of the TCP/IP stack's internal data structures. I'm lucky to have found one of the fastest copying routines to do this job.
This sounds very interesting.
If you say the copy loop is important for the network performance.
Would you mind in the future to include a 68050 version of this routine which might be tuned to use a parallel load? We could handwrite this code for you if you are willing to include it.
-
@Olsen
I remember an article written during or near the end of Roadshow 68K development years ago. It was well written and spoke of how development process started with looking at the only available examples (AmiTCP sources?)
Polish translation:
http://www.ppa.pl/os4/artykuly-cam9.php
Translation from translation:
http://translate.google.pl/translate?u=http%3A%2F%2Fwww.ppa.pl%2Fos4%2Fartykuly-cam9.php&sl=pl&tl=en&hl=&ie=UTF-8
-
Olsen
I guess all things have their time. And now maybe its finally Roadshows time for the Classic Amiga crowd. The one thing I have learned being in the Amiga scene since 1988 is that the market never seems to die. It somehow stays alive. I think properly presented 68k Roadshow will be received well. Good luck. A gui is really important, i'd like to mention again :)
NOTE
*******
Nordic Global aka Holger Kruse
Miami
MiamiDX
********
Having met Holger Kruse at many US Amiga shows over the years. I purchased Miami DX through his registration system. I NEVER received my keyfile. Holger and Nordic Global were completely non responsive to emails. I learned from other amigans at conventions that there were many people out there this happened to and Holger dissapeared. well...
At one Amiga show in St Louis, Holger somehow appeared or something. I remember cornering him at a party and asking him why people didtn receive keyfiles or an explanation.. Well his explantion for the poor business practice was " I had all the registration software and names on my Amiga 1200hd and it died along with the drive and all the data. No backup" I kid you not. I think thats the last Amiga show he was seen at as well. Wild..
-
First of all I would like to congratulate you to your work and thank you for your decision to continue support for the 68K AMIGA line!
This sounds very interesting.
If you say the copy loop is important for the network performance.
Would you mind in the future to include a 68050 version of this routine which might be tuned to use a parallel load? We could handwrite this code for you if you are willing to include it.
Thank you for the offer, but it is likely not worth the stretch.
The tests I ran strongly suggest that memory performance trumps CPU capabilities, and that even a 40 MHz 68040 can outperform a 50 MHz 68060 if its memory interface gives it a bit more of an edge.
In 2003 Roadshow 4.205 managed to squeeze about as much out of an "Ariadne I" card as possible, and that's with a 40 MHz 68040 CPU in an A3000T. Once you get this far, the limiting factors are more with the expansion hardware than with how much faster a hand-optimized copying routine for a specific CPU may run.
-
Polish translation:
http://www.ppa.pl/os4/artykuly-cam9.php
Translation from translation:
http://translate.google.pl/translate?u=http%3A%2F%2Fwww.ppa.pl%2Fos4%2Fartykuly-cam9.php&sl=pl&tl=en&hl=&ie=UTF-8
Yes, that's the one, and it actually has my name on it. Funny how it reads back in the english translation...
And I just found the original HTML text, which I sent to Amiga, Inc. on November 23rd, 2003.
-
Olsen
I guess all things have their time. And now maybe its finally Roadshows time for the Classic Amiga crowd. The one thing I have learned being in the Amiga scene since 1988 is that the market never seems to die. It somehow stays alive. I think properly presented 68k Roadshow will be received well. Good luck. A gui is really important, i'd like to mention again :)
I know - the GUI issue, however, repeatedly managed to stall development work. Unless something like a miracle happens, I'd rather not rely upon having a GUI ready to ship with the product.
NOTE
*******
Nordic Global aka Holger Kruse
Miami
MiamiDX
********
Having met Holger Kruse at many US Amiga shows over the years. I purchased Miami DX through his registration system. I NEVER received my keyfile. Holger and Nordic Global were completely non responsive to emails. I learned from other amigans at conventions that there were many people out there this happened to and Holger dissapeared. well...
At one Amiga show in St Louis, Holger somehow appeared or something. I remember cornering him at a party and asking him why people didtn receive keyfiles or an explanation.. Well his explantion for the poor business practice was " I had all the registration software and names on my Amiga 1200hd and it died along with the drive and all the data. No backup" I kid you not. I think thats the last Amiga show he was seen at as well. Wild..
If the story is true to the facts, then I can perfectly understand why Holger chose to bow out. Talk about major embarrassment. How can you recover from this degree of desaster and still keep the trust of the customers who invested their money? I guess there may be more than one way to approach such a situation, but not all of them may be apparent or open at the time desaster strikes.
-
The CAM piece is online (http://web.archive.org/web/20031121153655/http://os.amiga.com/cam/index.php?i=9&p=4) at the Wayback Machine (http://web.archive.org/) as well.
-
In 2003 Roadshow 4.205 managed to squeeze about as much out of an "Ariadne I" card as possible, and that's with a 40 MHz 68040 CPU in an A3000T. Once you get this far, the limiting factors are more with the expansion hardware than with how much faster a hand-optimized copying routine for a specific CPU may run.
I see.
Of course for the NATAMI the 68K CPU has now access to 100MB and Gigabit Networkcards.
-
I see.
Of course for the NATAMI the 68K CPU has now access to 100MB and Gigabit Networkcards.
Then you are most likely to hit the limitations of the SANA-II architecture before the question comes up how to make the copying operations faster.
Gigabit traffic is practically unmanageable if the data has to be copied around using the CPU, for example. But this is the only option SANA-II currently offers. Also, the design of the TCP/IP stack Roadshow is built around knows not how to deal with DMA operations. Modern TCP/IP stacks cleverly mesh DMA operations with their own idea of how packets and TCP segments should be represented in their internal data structures.
Available CPU and network performance does not necessarily translate into actual TCP/IP stack performance. On OS4 Roadshow is hampered by the performance limitations imposed by its 1994 architecture, in spite of the fact that the networking hardware will do DMA just fine and the PPC CPU can push data around very quickly.
-
I know - the GUI issue, however, repeatedly managed to stall development work. Unless something like a miracle happens, I'd rather not rely upon having a GUI ready to ship with the product.
Well I am one of many (I guess) who contacted you over the years about possibility to buy 68k version of Roadshow, and you know what, i am still interested :-)
About the GUI and price. I think that the availability of the GUI would affect the price significantly. I mean the €10-15 for digital distribution sounds fair to me for GUIess version while the package with GUI incl. could be €25-35? (Would be more few years back...)
-
About the GUI and price. I think that the availability of the GUI would affect the price significantly. I mean the €10-15 for digital distribution sounds fair to me for GUIess version while the package with GUI incl. could be €25-35? (Would be more few years back...)
For now I won't bet that any GUI will be ready by the time the necessary work on preparing Roadshow 68k for release has completed. Time permitting, I'd like to see it getting out of the door as soon as possible. Who knows, maybe a GUI could follow later as an update for the project, but right now that's speculation on my part.
I'd rather see Roadshow 68k released with a decent documentation while there is still sufficient enthusiasm for the product. If you ship a product, you can update it. But if you never ship it...
-
I'd rather see Roadshow 68k released with a decent documentation while there is still sufficient enthusiasm for the product. If you ship a product, you can update it. But if you never ship it...
Cool. I just wanted say that GUI would justify higher price. I personaly dont need GUI at all. And I guess after people setup Roadshow for the first time without GUI there will be no way how to charge any more money for separate GUI later. Even though add GUI later on would be still nice.
-
Once it's free, who is going to take care of it? For free?
Does RoadShow need daily caring? I mean, I is mature project which is presumably out of beta stages since many years. If you were going to develop completely new features it could be another bounty project again.
This won't be as much fun as having some sort of carrot providing an incentive to keep pulling the cart.
I dont expect Amiga software is going to sell more than 50-100 copies in total these days... most of sales happen when product is released and then stagnate to very low numbers. In few months you have saturated entire Amiga market and it is not growing.
It is your choice of course but in my opinion with limited market bounty generates more pleasure to both users and developer.
-
@Golem!dk
Thanks! You have a very good memory.
-
Does RoadShow need daily caring? I mean, I is mature project which is presumably out of beta stages since many years. If you were going to develop completely new features it could be another bounty project again.
When you assume responsibility for software of your creation, you are supposed to be able to answer questions regarding its performance, its limitations and give hints on working around them. That's not counting in collecting the information required for fixing bugs or adding new features.
The first part of "caring" is in helping the product to reach its audience, and make the audience care about the product. I can understand that a bounty would neatly fit the first part of such a process. Get the thing out the door and into the hands of the users. That would cover the first act.
The second part of "caring" is the tedious bit. Now that you've slain the dragon, so to speak, the villagers will start to complain about the damage the animal did to their property and expect you, the guy who slew the dragon, to be sympathetic to their pleads. After all, you did the big thing, everybody was happy, and now you're going to get dragged back into the daily business, which is not very exciting. I can't see a bounty taking care of the bug fixes and the enhancements. It may sound neat when you think about it, but once reality settles back in, you'll find that chasing after bugs and preparing for the next iteration of the product is not as exciting and motivating as things were when you prepped for the first act of the effort. There may be a reward in the distant future, but as experience shows, that distant reward can be poisonous for software development.
I dont expect Amiga software is going to sell more than 50-100 copies in total these days... most of sales happen when product is released and then stagnate to very low numbers. In few months you have saturated entire Amiga market and it is not growing.
It is your choice of course but in my opinion with limited market bounty generates more pleasure to both users and developer.
You're talking about the software equivalent of a one-night-stand. Wham, bang, thank you ma'am. I'm not that kind of guy. If it's software, your responsibilities will last, and last longer than you may have expected when you made worst case predictions. And the best thing to make them last is to stretch out the rewards aspect of development. So, to put it into words, I do not believe in bounties to provide for a lasting development process.
-
I personally thought it was less of a headache to set up, and it has a couple of features which other TCP/IP stacks, owing to their age, could not bring to the table.
Would you mind sharing exactly what those are?
For example multicast, does Roadshow do multicast at all?
Nothing is ever certain. I'm not going to walk away from Roadshow, and how it evolves depends upon the user feedback. If you don't know what it takes to make a better product, it probably won't become one.
I'm probably the only person in the entire Amiga community who gives a rats ass about IPv6, but I'll repeat it - IPv6 is coming, whether people like it or not, and IPv4 will in short time (in amiga terms anyways) be obsoleted. Tough luck for those who want to use any of the NG systems as some sort of main system, and those who think a clever router will solve all your problems, then please elaborate how that is supposed to happen.
Gee, you seem to have the wrong idea how OS4 is developed. While Hyperion has in-house developers working on the product, at least half of the work being done on the whole package is contributed by third party developers.
I consider any development done by anyone who signs NDA with Hyperion as in-house, it's as close to in-house they can get anyhow - I do not have any illusion of Hyperion actually having a house... heh... :laughing:
I own it alright. It's just that I am contractually restricted from doing with it whatever might strike my fancy. There are limits to what I can do.
So in reality, you dont own it, and appearantly you're not pleased with that fact.
More people can run 68k software than can run OS4.
Sure, but a TCP stack? Considering that a vast majority of those running 68k software are doing so in UAE where bsdsocket.device is offered by emulator, I doubt that there really are that many.
Even if each member of each groups (or sets; one being a superset of the other) were to come up with one bug report and one enhancement request each, the amount of feedback to come from OS4 users would still be very small by comparison.
No doubt, but I really don't see one single person being able to maintain an entire IP stack over time, it just isn't realistic.
-
@olaf: estabilshing a bounty and open sourcing would be most practical for both sides i believe. if not too high calculated you might get your cash pretty soon without any distribution hassle and yet remain supervising the project, while others would have opportunity to help you out with it. but reading between your lines i suspect you are not in a position to do that. if so talking about it any further is senseless..
-
Would you mind sharing exactly what those are?
For example multicast, does Roadshow do multicast at all?
Roadshow supports ZeroConf network interface configuration, if there's no DHCP server around, for example. The API is much richer than the original AmiTCP design, allowing you to control the operation and configuration of the TCP/IP stack through AmigaOS-like functions, with hooks and tagitem lists. Also, you have access to the inner workings of the packet and connection dispatch and can plug in filters of your own choice to implement something like ZoneAlarm for Windows. I also wrote my own PPP and PPPoE drivers from scratch, which are faster than what Miami and AmiTCP Genesis had to offer.
The SDK is quite nice. It even has sample code and a tcpdump port which uses Roadshow's built-in Berkeley socket filter.
As for multicast, Roadshow does what can be done within the limitations of the SANA-II driver framework. The number of multicast addresses to listen to is limited by the design of the S2_ADDMULTICASTADDRESS command.
I'm probably the only person in the entire Amiga community who gives a rats ass about IPv6, but I'll repeat it - IPv6 is coming, whether people like it or not, and IPv4 will in short time (in amiga terms anyways) be obsoleted. Tough luck for those who want to use any of the NG systems as some sort of main system, and those who think a clever router will solve all your problems, then please elaborate how that is supposed to happen.
To support IPv6 properly, a new TCP/IP stack has to be ported. There's a compatibility layer developed for the 4.4BSD stack at the University of Lausanne, which Miami would use, but I suspect its functionality is hardly adequate any more.
For the time being I reckon there's a time window of at least 2-3 years left during which too many existing IPv4 devices have to be supported to make it easy to switch to IPv6, at least as far as the common end user is concerned (business operations will be a different matter; if you're running your own BGP router in the basement you'll have to switch sooner than later). Your typical ISP will likely switch your cable modem or ADSL service concentrator to IPv4 operations and internally reroute the traffic through a 4to6 proxy.
I agree that this issue has to be addressed, eventually, I just don't see it coming around the corner just yet.
I consider any development done by anyone who signs NDA with Hyperion as in-house, it's as close to in-house they can get anyhow - I do not have any illusion of Hyperion actually having a house... heh... :laughing:
Aren't we being negative today?
So in reality, you dont own it, and appearantly you're not pleased with that fact.
Could be worse. If I were completely free to make the software open, I could just dump the thing and leave it to its own devices. My suspicion is that it would stay largely untouched and unloved. The whole premise that once a package is open sourced great things are inevitably going to happen to it is too optimistic.
Sure, but a TCP stack? Considering that a vast majority of those running 68k software are doing so in UAE where bsdsocket.device is offered by emulator, I doubt that there really are that many.
Could be, but some funny things are possible with a 68k TCP/IP stack that runs inside the emulation rather than interfaces to the host's TCP/IP stack by means of a proxy. For example, take IPv6 support. The code that's hard-wired to WinUAE will stay AmiTCP V3 compatible until the bitter end.
No doubt, but I really don't see one single person being able to maintain an entire IP stack over time, it just isn't realistic.
Come on, this code was so mature in 1994 that it, essentially, has not changed in more than a decade since. The integration of IPv6 in FreeBSD, NetBSD and OpenBSD happened alongside the existing IPv4 support, and any major changes that went into the IPv4 code were concerned with security enhancements, bug fixes and very few functional additions, such as for T/TCP.
The last bug fix I applied to the mainline TCP/IP code came from "archeological research" in code that was at the time more than 20 years old. That was in 2007.
It's not as if you have to keep up with a boatload of code changes to keep this TCP/IP stack implementation reasonably robust and sound. One man can do it.
-
Could be worse. If I were completely free to make the software open, I could just dump the thing and leave it to its own devices. My suspicion is that it would stay largely untouched and unloved. The whole premise that once a package is open sourced great things are inevitably going to happen to it is too optimistic.
Sure open sourcing doesn't guarantee anything, but I don't see this being "untouched". I'm pretty sure AROS would like to incorporate it, and I can see 68k users getting involved too. For me personally, I find that I end up working on applications that I use that are open source, or at least contributing back something.
As you are unable to do this anyway, it's probably not worth discussing though right? :)
-
I'm interested and I would contribute. I would prefer it in this order:
1 opensourced
2 freeware after bounty is reached
3 released as demo product that works for some minutes allowing you to buy a key.
4 commercial product with no demo
I don't think GUI is a problem since it could be released later: Gadtools, MUI, Classact... I could help with any of these toolkits if Olaf is interested.
-
Sure open sourcing doesn't guarantee anything, but I don't see this being "untouched". I'm pretty sure AROS would like to incorporate it, and I can see 68k users getting involved too. For me personally, I find that I end up working on applications that I use that are open source, or at least contributing back something.
As you are unable to do this anyway, it's probably not worth discussing though right? :)
Give it some time...
Or spend some effort on porting your own TCP/IP stack. If Holger Kruse and yours truly could do it, so can anybody else. Here's how:
1) You have to have a working 'C' compiler setup with a debugger and advanced knowledge of Amiga system programming.
2) Buy quality professional documentation on the 4.4BSD-Lite2 TCP/IP stack, which is technically still the reference implementation for all the TCP/IP stacks that were developed from it, e.g. in OpenBSD, FreeBSD and NetBSD. I bought "TCP/IP illustrated, vol. 2" by W. Richard Stevens & Gary R. Wright and "Unix network programming, vol. 1, Networking APIs: Sockets and XTI" by W. Richard Stevens. You can buy used books, as the information concerning 4.4BSD-Lite2 was valid and current even 10 years ago.
3) Find and download the 4.4BSD-Lite2 operating system source code, including the utilities. This isn't hard to do. Google is your friend, e.g. try "ftp://ftp.dlut.edu.cn/pub1/unix/bsd-source/4.4BSD-Lite2.tar.gz".
4) Find and download the source code for AmiTCP V2.2 and the documentation that went along with it. It's still available from Aminet. While the code itself doesn't work perfectly, it still shows how the clever folks who wrote AmiTCP made it work on the Amiga. This is practically a blueprint for writing an Amiga TCP/IP stack based upon the BSD code.
5) Learn how the SANA-II device driver API works. The documentation is found on the Amiga Developer CD 2.1, for example.
There's a lot to learn from the two books, and you might want to get really familiar with the SANA-II documentation. Dig into the AmiTCP V2 source code and understand how it relates to the 4.4BSDLite-2 code.
Take care of this and you're set. If you're very motivated, you can port the whole thing in about two weeks, have the basic AmiTCP API up an running and run a web browser on top of it. It can be done.
-
Or spend some effort on porting your own TCP/IP stack. If Holger Kruse and yours truly could do it, so can anybody else. Here's how:
Not sure I have the interest in such a project "from scratch" nor the time (and I have no doubt my level of Amiga coding is not up to yours!). Also seems a shame to keep re-inventing the wheel, due to licensing and the death on previous projects. I suppose a project like this would be good to learn the ins and outs of tcp/ip though.
-
@olsen
The "amigazation" and access to inner workings of packets and connections is very nice. I have never had need for PPPoE, but PPP I use quite a bit, "tethering" (?), or lately on MiniMig using nullmodem or bluetooth link, and my experience is that stability is a heck lot more important than speed.
Zeroconf is nice (never needed it), but what I miss is media players capable of playing content streamed over multicast, which means support for PIM-SM, SDM, SSM...
As for IPv6, I think it's probably best to use KAME (http://www.kame.net), since that is what "all the others" in the BSD camp are using already. And as you probably know, it's not just a matter of "switching to IPv6", there's also the issue of running dual stack and deal with various transition technologies. What I hear more and more from ISPs is that they want to just push IPv6 to the end user and use NAT64/DNS64 to make IPv4 only services available - the implication of this is dropping native IPv4 on the customer side, but for a vast majority of users this is perfectly fine, since all major operating systems have been IPv6 ready for half a decade or more now. It's by far the easiest transition, is already implemented and proven to work well, and is also being deployed in a growing number of places (often for wireless networks with large number of clients)
Current estimate for IPv4 exhaustion is summer next year, we ("amiga land") are already a decade late in terms of what should have been done, and at least half a decade behind just about any other platform. Other hobbyist OSes already have projects for this, but none of the Amiga ones as far as I know. I'm just saying, the "switch" (as in "no more IPv4 address for you!") to IPv6 is predicted to become quite brutal in general, but many pretend that it's kinda like a Y2K problem that is all just hype, people have all kinds of weird theories as for why they think that it will never take off. For totally unprepared and happily ignorant Amiga users I suspect it will become quite entertaining... not only will there have to be a new IP stack, all the networking software will need to be rebuildt as well. Oh joy! :)
If I were completely free to make the software open, I could just dump the thing and leave it to its own devices.
And what guarantees are there that you wont do the same when selling it? I mean, seriously, it's not like it would be the first time in history of Amiga that this happens. I'll admit that your promises count alot more than most others, though.
My suspicion is that it would stay largely untouched and unloved. The whole premise that once a package is open sourced great things are inevitably going to happen to it is too optimistic.
That's totally beside the point, what is the point is that whoever willing then have a much better chance to fix whatever is bugging him/her without needing to contact some author who's no longer around, doesn't care anymore, no longer has the sources, has changed email address etc. as is the typical case for most 68k Amiga software. The point is to have the sources around so that there at least is a _chance_ to fix things when needed, by not having sources available you more or less guarantee that it will eventually be abandonware with dubious legal status, various incompatible dodgy binary patches etc. - all the stuff we hate about AmigaOS already.
I fix things in open source software all the time, but only rarely bother to contribute these fixes back upstream, as they're more quick work-arounds for my particual situations than anything else - I'm after all not a programmer. If there are stright out bugs, I do report them, but I don't think I'm at all qualified to suggest what the proper fix is, however quite alot of these bugs I can avoid simply by building the software with options to exclude the buggy part of the code, for example. Also, with open source software I can consult with programmers who are not involved with the code at all, to hear their oppinion on what might be wrong at a specific part of code - these things happen all the time and is what open source software is about.
Some funny things are possible with a 68k TCP/IP stack that runs inside the emulation rather than interfaces to the host's TCP/IP stack by means of a proxy.
Sure, but this is not something "most users" bother with.
The code that's hard-wired to WinUAE will stay AmiTCP V3 compatible until the bitter end.
Uhm, I dont get this part. The reason to stay AmiTCP V3 compatible is that this is what all software today use. Create an IPv6 stack tomorrow, it will still be the case. Nothing prevents an IPv6 capable bsdsocket.device in UAE. But on an emulator it is not so desperatly needed, due to perfectly functional IPv6 support in host OS. I run eUAE on Linux alot and the emulated Amiga can access filesystems I have made available over SSH, WebDAV, NFS, SMB, LUFS... over IPv6 as well as IPv4. And I prefer using hosts web browsers than messing around with mostly dysfunctional Amiga web browsers.
Anyways, WinUAE recently got A2065 emulation (iirc) - so anyone who want to play around with that can do so, but i really don't think there are many.
It's not as if you have to keep up with a boatload of code changes to keep this TCP/IP stack implementation reasonably robust and sound. One man can do it.
OK, I'm almost tempted to register in order to give you hell, then :laughing:
Btw - on a related note, people have been moaning about wireless stack for about half a decade as well now, feel free to port wpa_supplicant, opensea, open1x or make your own ... hohum... AirShow too. I can keep you busy there with testing and bug reports for years, really. And funny things are often needed to be changed in the IP stack as well when you start playing with wireless, the OSI model is after all just that - a model, in real life the layers typically become much more entangled :)
PS: Thanks for Term, although I admit I most often end up using VLTjr that doesn't suck up all that much RAM. I once started looking at how to strip off all the unneeded fluff in Term, but like so much I start doing on amiga, it never got far.
-
Kolla,
I have to ask, we're you born this cheerfull or did it take years to get to this point?
Reading some of your responses(good/accurate info aside),i think you could depress the most cheerfull people.
good for a laugh tho.
mike
-
Kolla,
I have to ask, we're you born this cheerfull or did it take years to get to this point?
I wa's born this cheerfull :)
Reading some of your responses(good/accurate info aside),i think you could depress the most cheerfull people.
Well, excuse me for pointing at the elephants in the room. This community is sometimes way too busy digging their heads in the sand, that's what really is depressing here, or entertaining, depending on how you chose to look at it. Life is short, so I prefer to be cheerfull rather than depressed about everything being done wrong in amiga land. Feel free to consider my rants therapy, if you like :laughing:
-
Also seems a shame to keep re-inventing the wheel
I agree... But seems like people like to do it in this Amiga world: TCP/IP stack ported 3 times, the whole OS rewritten 3 times (AROS, MorphOS, OS4 which had to rewrite lots of parts), applications ported 3 times (MUI/Gadtools, MorphOS/OS4/AROS,...),...
We could have a lot more apps and more modern OS if people were cooperating instead of fighting each other with closed source apps, stupid contracts,... since a decade.
-
i agree... But seems like people like to do it in this amiga world: Tcp/ip stack ported 3 times, the whole os rewritten 3 times (aros, morphos, os4 which had to rewrite lots of parts), applications ported 3 times (mui/gadtools, morphos/os4/aros,...),...
We could have a lot more apps and more modern os if people were cooperating instead of fighting each other with closed source apps, stupid contracts,... Since a decade.
Amen!!!
-
Not sure I have the interest in such a project "from scratch" nor the time (and I have no doubt my level of Amiga coding is not up to yours!).
Well, the question came up if I were interest to contribute the hard work of some odd 6-7 years to the open source pool, which for Amiga software hasn't been drawing that much water lately.
For me that question always has the tang of abandonware: you can't really do business in this market situation, so it's probably not such a big step to throw in the towel and just dump the product. Great things are then going to happen to it. Well, in the next 5-6 years probably will. Have to. Manifest destiny, if anything.
From my humble experience in this magic field of open source software, the best and the most loved software came about because somebody needed to scratch an itch, and did so by getting involved writing the code he needed.
The last thing the Amiga needs is more clamoring for free, and rather complex software, while at the same time the number of people who could create that complex software just keeps on shrinking and shrinking.
This stuff doesn't write or port itself. Some things are best done if you do them yourself. End of sermon.
Also seems a shame to keep re-inventing the wheel, due to licensing and the death on previous projects. I suppose a project like this would be good to learn the ins and outs of tcp/ip though.
Not a lot of people know how to use or even write a SANA-II device driver. Not a lot of people know how to program TCP/IP stack client software. Not a lot of people know how to implement a TCP/IP stack for the Amiga. And so on.
Saying that it's a shame to reinvent the wheel when the last guy who made a wheel isn't going to make any more wheels inevitably leads to the cart breaking down. It may be possible to borrow or steal another wheel, but this will only get you so far. At some point somebody will have to make more wheels. And the best reason for reinventing the wheel has always been: to make more wheels.
-
I agree... But seems like people like to do it in this Amiga world: TCP/IP stack ported 3 times,
I think your number is off. We had six different TCP/IP stacks so far: A225 (Commodore), AS225 (Commodore, cancelled product; later released as INet-225), AmiTCP, Miami, Termite, Roadshow. A225 was a static link library. AS225 was a shared library. AmiTCP, Miami, Termite and Roadshow were all shared libraries using the same basic API. AS225 and AmiTCP were not compatible.
the whole OS rewritten 3 times (AROS, MorphOS, OS4 which had to rewrite lots of parts), applications ported 3 times (MUI/Gadtools, MorphOS/OS4/AROS,...),...
We could have a lot more apps and more modern OS if people were cooperating instead of fighting each other with closed source apps, stupid contracts,... since a decade.
Closed source apps meant competition and a market, as long as the market existed. I'm not sure we have had one in the last 15 years.
Whoever wants to build and maintain an operating system probably isn't exactly in the same camp as an application software developer.
Cooperation only exists if there is a common ground. If the work being done leads to commercial work, you absolutely have to have competition. OK, it's one thing to be competetive and another thing to be snide and aggressive about it. We certainly had our share of drama queens and fanboys in this field, and this isn't going to change. If you cared about the Amiga you were probably really passionate about it, too. It's natural that the end result can involve the bile and the trolling we all came to expect.
Well, you don't have to like it, and you don't have to play that game.
Given how software developers tend to be, often socially somewhat inept, it's kinda inevitable that sparks will fly because of a failure to communicate what's being done, and why. Amiga software developers can play nice, they just didn't always do. Given that Commodore was always such an inept and weak force in the Amiga business, the 3rd party developers came to dominate the business. And this culture has persisted, with the nasty side-effects of the bullying and the name-calling.
If you ask for cooperation you ask for some degree of level-headedness and maturity. Funny thing: whenever somebody asks for exactly these two to be applied he's almost certainly not going to get them.
What can you do? Write your software, have fun with it, be a good boy and play nice with the others. But there's not that much software being written today, is there? The bickering is so much more productive.
-
@olsen
The "amigazation" and access to inner workings of packets and connections is very nice.
It's better than learning how to wrestle with the Unix APIs. The Unix APIs are still there if they are needed, but if you want to do interesting things, easier access to the power of the TCP/IP stack will get you there faster. I always believed in putting a match and a stick of dynamite into the hands of the developer, and leave him to figure out what to do with those two.
I have never had need for PPPoE, but PPP I use quite a bit, "tethering" (?), or lately on MiniMig using nullmodem or bluetooth link, and my experience is that stability is a heck lot more important than speed.
Stability can be a difficult thing with PPP. The problem with PPP was that quite a number of implementations were deployed while the specs were still under development. There's a nice book documenting PPP which came out of Sun, Inc. that details the gory bits, what works, what doesn't always work, and where the dragons are.
If you write your PPP driver from the specs chances are that there will be interoperability issues. If you port the Unix/BSD/Solaris PPP code you may end up having to jump through a number of hoops if your system's target architecture does not match the one the PPP code was written for. This happened, for example, with the Linux PPPoE daemon: it actually converts PPP packets intended for serial communications into PPPoE frames, and the other way round.
The code I came up should work reasonably well. It did outperform Holger Kruse's own ppp.device, and the PPPoE support provided by the special ppp-ethernet.device has extremely low overhead.
Zeroconf is nice (never needed it), but what I miss is media players capable of playing content streamed over multicast, which means support for PIM-SM, SDM, SSM...
Only one way to find out if it works.
Mind you, not all SANA-II Ethernet drivers support multicast operations robustly.
As for IPv6, I think it's probably best to use KAME (http://www.kame.net), since that is what "all the others" in the BSD camp are using already.
NetBSD took its sweet time integrating KAME into the mainline code, from where it spread to the other members of the family. I think this is the smart way to approach it: use the integrated code and try to not repeat the process yourself. By now the BSD line of TCP/IP stack code should be so well-groomed that it would be a bad idea not to adapt it, wholesale, for the Amiga. I only got started with 4.4BSDLite-2 in Roadshow because the documentation was so good. If I were to do this again, I'd use a more recent TCP/IP stack implementation.
And as you probably know, it's not just a matter of "switching to IPv6", there's also the issue of running dual stack and deal with various transition technologies.
Like I wrote, were are probably not going to see much of a demand on the consumer's side for IPv6 unless you don't have an ISP which does all the heavy lifting and protocol conversion for you. Given how long a rollout of proper broadband connectivity has taken in Europe already, I wouldn't want to bet on when exactly a move to IPv6 were to happen. Of cause, this IPv4 to IPv6 protocol conversion business stinks, since it defeats the very idea and purpose behind IPv6. But it wouldn't be the first time that business decisions being made keep overriding engineering decisions. ISO networking and protocols died a quiet death while IP was trampling all over it, in spite of the fact that the ISO ideas more often than not were better than what the designers of IP and TCP had come up with in the 1970'ies.
Current estimate for IPv4 exhaustion is summer next year, we ("amiga land") are already a decade late in terms of what should have been done, and at least half a decade behind just about any other platform.
All our APIs are IPv4 only. All our software is IPv4 only. Unless you can get every bit of software rewritten that's already out there, you won't see IPv6 adoption, at least in consumer/user land.
So, please, the priorities are somewhat skewed with Amiga TCP/IP stack software.
And what guarantees are there that you wont do the same when selling it? I mean, seriously, it's not like it would be the first time in history of Amiga that this happens. I'll admit that your promises count alot more than most others, though.
One thing I learned is that promises in the Amiga business tend to last as long as butterfly kisses. Sure, they can be nice, but they are more something of the moment than something that will last and keep you feeling warm and fuzzy all over.
I am not promising anything but that I'll try in my little way to hold up what I believe in.
That's totally beside the point, what is the point is that whoever willing then have a much better chance to fix whatever is bugging him/her without needing to contact some author who's no longer around, doesn't care anymore, no longer has the sources, has changed email address etc.
Sounds like you got burned like the rest of us, huh? This Amiga situation has never been pretty. I still recall how Commodore did business back in the 1990'ies, and that wasn't pretty either. When the company went bust the market turned. Some people got out of it altogether, some people flourished while the going was good, and they all were pretty much overshadowed by the con men, the hucksters and the scum that preys on other people's misery. And the really bad thing was that sometimes couldn't really tell which group the guy you were dealing with belonged to.
So, I can see where you're coming from. Seeing the train rumbling along, with no way to stop it, get it back on the tracks, can be a bitch. I've been on that train myself and found that it took me to strange places. But you don't have to stay where it takes you, and you don't have to like it. Either you get bitter about it, or you try to make that strange place you came to a better place.
I'd rather hang on to the stuff I built and try to make it better. There's a limit to how far this can be done. You can burn out (like I did) along the way, and you can find that your own standards are so hard to attain that you lose a lot of steam.
So there's always a chance that you'll let yourself and everybody else down. I'm not excluding myself from that group. It happened, will happen again. I just hope I'll pick myself up, dust myself off and try again.
I fix things in open source software all the time, but only rarely bother to contribute these fixes back upstream, as they're more quick work-arounds for my particual situations than anything else - I'm after all not a programmer.
Everything good and perfectly alright about it. Hey, I could use a hand maintaining my old code, too. It's just that I'm so old-fashioned that I try to dig myself out of my own mess first before I go about shouting for help. I'm just like that. Why make somebody else's life harder? It's bad enough that I made my own life harder.
Sure, but this is not something "most users" bother with.
Uhm, I dont get this part. The reason to stay AmiTCP V3 compatible is that this is what all software today use. Create an IPv6 stack tomorrow, it will still be the case. Nothing prevents an IPv6 capable bsdsocket.device in UAE.
Perfectly understandable. But without anybody using these toys, how will you build the knowledge of how to use and maintain such software? It's not just about getting the bugs out.
Anyways, WinUAE recently got A2065 emulation (iirc) - so anyone who want to play around with that can do so, but i really don't think there are many.
Well, the a2065.device driver is in really poor condition. The uaenet.device does work better. I suppose the A2065 hardware support came about so that you could use software deployed using the A225 kit. There is not a lot of it about, though. I only recall Maxis' "Robosport" title which supported multiplayer gaming over Ethernet through A225.
OK, I'm almost tempted to register in order to give you hell, then :laughing:
That's the spirit...
Btw - on a related note, people have been moaning about wireless stack for about half a decade as well now, feel free to port wpa_supplicant, opensea, open1x or make your own ... hohum... AirShow too. I can keep you busy there with testing and bug reports for years, really. And funny things are often needed to be changed in the IP stack as well when you start playing with wireless, the OSI model is after all just that - a model, in real life the layers typically become much more entangled :)
Well, I tend to try and make stuff I'd be likely to use myself. Of all the wireless gadgets I have at home, none I would like to use with an Amiga. Do I have to cook up my own crypto code for that, too? I'd rather not to. This sort of thing always ends in tears, if not worse. So there's probably not going to be any sort of WPA or VPN solution from my side for a while.
PS: Thanks for Term, although I admit I most often end up using VLTjr that doesn't suck up all that much RAM. I once started looking at how to strip off all the unneeded fluff in Term, but like so much I start doing on amiga, it never got far.
Gee, somebody's still looking at 'term'. I'm amazed, puzzled and a bit scared to read about it.
-
I dont get it, why so many people think open sourcing will save the world. It works well on platforms with large communities of developers and users but its not our current situation. Olaf is around for ages, take care, Raidshow works great as part of OS4, will work great as 68k tcp/ip stack, there are people who would like to purchase it.
So whats kolla's (and few others) problem?
-
Cooperation only exists if there is a common ground. If the work being done leads to commercial work, you absolutely have to have competition. OK, it's one thing to be competetive and another thing to be snide and aggressive about it.
Indeed. And don't you think AROS, MorphOS and OS4 all have a common ground (that is OS 3.x compatibility plus PowerPC/x86 native as a base) ?
Now I think you have to be competitive before even thinking about having competition... I don't think the current (and past decade) "competition" gave any positive results. Current competition and closed source only made AROS take more time to get where it is. It also means OS4 still doesn't have an USB stack to the level of the "competition"'s one (AROS/MorphOS Poseidon). And so on... Just because they had to keep reinventing the wheel. Reinventing the wheel is useful if your wheel is better, or has a different goal. And I don't think (just an example) rewriting the same PowerPC Radeon drivers (MorphOS/CGX and OS4/P96) has any use but wasting time and resources.
I only see waste of time and resource as a consequence of this competition: I don't see anything positive coming from here... Look: you're not even free to do what you want with the stack *you* wrote. And for what ? Now that MorphOS has its own native stack, what's the point ?
Seems like people are behaving like the big Apple: protecting their stuff,... like if there was a market and millions of people buying their stuff... problem is there are only hundreds (at most) people here. The real target is elsewhere... and surely doesn't care if their CPU is x86 or PowerPC...
-
I dont get it, why so many people think open sourcing will save the world. It works well on platforms with large communities of developers and users but its not our current situation. Olaf is around for ages, take care, Raidshow works great as part of OS4, will work great as 68k tcp/ip stack, there are people who would like to purchase it.
So whats kolla's (and few others) problem?
I suspect that this is just the tone of the community these days. Talk, talk, talk rather than do, do, do. It's so much easier to spin stories, to vent frustration in writing than to get out of the car, kick the tires, bend down into the mud and change the flat. You'll get dirty either way, but only one way will get the car moving again.
My little theory is that the Amiga community has learned to become helpless. Which is no surprise given how it has been treated by the people who were supposed to be in control of the platform and the situation. It's really bad if you are first considered an asset and then treated like a bunch of particularly idiotic idiots. Are we such easy marks?
I've always thought of myself as a realist with a nasty pessimistic streak bumping into the realism when I wasn't paying attention. It's so easy to lose heart and become bitter. But if I can drag myself out of the slump, anybody else can do it.
It might help to stow the bitterness, the snappy repartee and the needling. As I wrote, you don't have to play this game, and you don't have to like it. If the doers are constantly getting sniped at by the talkers, how is anybody else supposed to get anything done for the Amiga? If you want to make other people you don't even know miserable, you don't have to do it on an Amiga forum.
Just saying...
-
Closed source apps meant competition and a market, as long as the market existed. I'm not sure we have had one in the last 15 years.
Whoever wants to build and maintain an operating system probably isn't exactly in the same camp as an application software developer.
Cooperation only exists if there is a common ground. If the work being done leads to commercial work, you absolutely have to have competition. OK, it's one thing to be competetive and another thing to be snide and aggressive about it. We certainly had our share of drama queens and fanboys in this field, and this isn't going to change. If you cared about the Amiga you were probably really passionate about it, too. It's natural that the end result can involve the bile and the trolling we all came to expect.
Well, you don't have to like it, and you don't have to play that game.
Given how software developers tend to be, often socially somewhat inept, it's kinda inevitable that sparks will fly because of a failure to communicate what's being done, and why. Amiga software developers can play nice, they just didn't always do. Given that Commodore was always such an inept and weak force in the Amiga business, the 3rd party developers came to dominate the business. And this culture has persisted, with the nasty side-effects of the bullying and the name-calling.
If you ask for cooperation you ask for some degree of level-headedness and maturity. Funny thing: whenever somebody asks for exactly these two to be applied he's almost certainly not going to get them.
I have to say Olsen is making all very good points!
I fully agree with you that doing commercial closed source software is not wrong.
And open source software does not at all lead to better products.
But I can see two advantages of open source.
A) Especially for documented and not to big projects - open sourcing them allows more people to learn from it. This is nice.
B) Open sourcing "abandoned" projects is also a nice behaviour.
That AWEB sources where open sourced when the author decided to stop developing them was a good deed. While AWEB did not became a Firefoy killer the open source team working on AWEB did a huge number of bug fixes on AWEB since then.
Quake is another good example. After makind their revenue with the game the sources were released and people could learn from it or port it to other niche platforms as the AMIGA.
I think what a real problem with software is that you can no guarantees.
Someone can buy a piece of software as your "Roadshow"-stack today - and tomorrow the author can decide not to support it anymore. This situation kind of sucks.
I think its right to pay a price for a good price of software.
But I think its bad to have no guarentee of support and if the company or developer decides go not support it anymore - not being able to get even the smallest bugfixe or minor enhancements anymore.
I think a good solution would be some sort of "community" contract.
That before a project becomes abandoned the programmer will release the sources like is was done was AWEB.
This is at least my opinion. What do you think?
-
Indeed. And don't you think AROS, MorphOS and OS4 all have a common ground (that is OS 3.x compatibility plus PowerPC/x86 native as a base) ?
There's enough common ground for sure, but just as much need to be different and in control of doing what you are doing. The latter can work out to become friendly competition, or it can turn the other way. And it's always so much easier to turn that other way, isn't it?
Now I think you have to be competitive before even thinking about having competition... I don't think the current (and past decade) "competition" gave any positive results. Current competition and closed source only made AROS take more time to get where it is. It also means OS4 still doesn't have an USB stack to the level of the "competition"'s one (AROS/MorphOS Poseidon). And so on... Just because they had to keep reinventing the wheel. Reinventing the wheel is useful if your wheel is better, or has a different goal. And I don't think (just an example) rewriting the same PowerPC Radeon drivers (MorphOS/CGX and OS4/P96) has any use but wasting time and resources.
But I don't see this working out. There is not enough common ground to make shared development possible. Perhaps I'm wrong, but I see this more as a control issue. As long as you can hang onto the stuff you are making, you can be sure that nobody will mess it up but yourself. Since the development "teams" are so small, it's also so much easier to do this stuff all on your own than to make an effort to coordinate with others. Chances are that if you are doing Amiga development work, you never worked in a software development team either. You could learn to do that, and you are bound to make mistakes doing so. Given the Amiga community's capacity for taking offense, this will discourage cooperation even further.
You see where this is leading. This community needs to have its head examined, collectively.
I only see waste of time and resource as a consequence of this competition: I don't see anything positive coming from here... Look: you're not even free to do what you want with the stack *you* wrote. And for what ? Now that MorphOS has its own native stack, what's the point ?
The point is that they are all as much in control of their own destiny as possible, without having to deal with the extra double helping of frustration that comes with coordinating their work with other people. Now if the pressure was sufficiently high, you'd get cooperation out of a situation like this. But in this community I suspect the pressure never was that high, and if it was, the people just threw in the towel, walked away, sometimes into these popular forums where, if anything, you can take out your frustration on other people. Who then, in turn, have some frustration to take out on other people again. It's a suffer-suffer solution. You don't have to be a Buddhist to notice that this isn't how it is supposed to be done, if you know what's good for you.
And, for the record, I had to mull it over what MorphOS would do with its TCP/IP stack before I signed my contract. At the time MorphOS already had a TCP/IP stack up and running. OS4 had none. The decision I made at that point I hoped at least would have some good coming out of it, considering how I boxed myself in.
-
I have to say Olsen is making all very good points!
Yes, but I'm all talk here, myself. Unless that motivates anybody to examine his motives and become a doer, it's just words on the screen.
I fully agree with you that doing commercial closed source software is not wrong.
And open source software does not at all lead to better products.
But I can see two advantages of open source.
A) Especially for documented and not to big projects - open sourcing them allows more people to learn from it. This is nice.
B) Open sourcing "abandoned" projects is also a nice behaviour.
That AWEB sources where open sourced when the author decided to stop developing them was a good deed. While AWEB did not became a Firefoy killer the open source team working on AWEB did a huge number of bug fixes on AWEB since then.
Quake is another good example. After makind their revenue with the game the sources were released and people could learn from it or port it to other niche platforms as the AMIGA.
I can agree to that.
My point of view, however, is and was that what matters is that somebody has to care about the software first and foremost. If there is nobody who cares enough, then you don't have a product, even if it has been open sourced.
Back in 1999, when the Amiga was on the skids again, I voiced my opinion that it would not be helpful to open source the operating system just now, as had been suggested repeatedly and very strongly at the time. My feeling was that it would stand a better chance if somebody would really want to care for it in the first place, rather than assume that this new process of "open source" would certainly take care of everything, no questions asked.
I never got so much bitter e-mail in response to this my deluded opinion. Even Eric S. Raymond, the man himself, deigned to inform me via e-mail of the error of my ways.
Yes, the process that made the Bazaar can be more productive than the one that made the Cathedral. But in the decade since this idea was brought to the fore it has been thoroughly tested and looked into, and it turned out not to be a silver bullet either. It isn't just the process that matters, it's the people who use it, and the number of people who use it.
Given our shallow puddle of Amiga developer talent, open sourcing a project is not the most effective way to proceed. Put another way, a single lemonade stand is not a Bazaar, and it's certainly not a catheral either.
I think what a real problem with software is that you can no guarantees.
Someone can buy a piece of software as your "Roadshow"-stack today - and tomorrow the author can decide not to support it anymore. This situation kind of sucks.
I think its right to pay a price for a good price of software.
But I think its bad to have no guarentee of support and if the company or developer decides go not support it anymore - not being able to get even the smallest bugfixe or minor enhancements anymore.
I think a good solution would be some sort of "community" contract.
That before a project becomes abandoned the programmer will release the sources like is was done was AWEB.
This is at least my opinion. What do you think?
You sound very positive. Which is a good thing in this Amiga situation, in which people seem to have gotten used to the fact that they will face misery more often than the more desirable alternative.
A community contract I'm not so sure of. We have had organized goodwill operations in the Amiga community by the dozen, and where are we now?
Personally, I'd not start with something that lends itself to shaping into an organization that produces yet more words on the screen. It would help to know what the Amiga community would find helpful, if it were to materialize through the hard work of developers.
If you don't know where to steer this ship, you'll just follow the current, and that current leads to just more bitterness for the Amiga community.
-
I really don't get it...
Is it already really too much from Olaf to ask for a little donation for the time he spent implementing an TCP/IP stack?
At present, Amiga only serves IMHO as a pseudonym for a hobby like others - and many contributions in this forum speak about a maximum amount between 10 and 15 EUR.
The relations seem to be very shifted nowadays!
Just two days ago I paid 39 EUR for a CD-ROM, provided by a professional photographer, who photographed me and my machine on the racetrack. Whereupon are just about 37 photos. These 37 photos were made within 2 days and serve me only as memory to a beautiful time. Where does the relationship to a programme remain, which devoured a multiple with its production at time, compared to a one-shot event like this? IMHO, 10 to 15 EUR are just inacceptable for a product that is in daily use. At least, if I were in Olaf's shoes, I wouldn't accept this.
Next, if you are a smoker, how many EURs do you blow in the blue per day?
Or, if you visit a pub at the weekend, how much do you pay for the guinness you drink?
Don't get me wrong. I know that a lot of people cannot afford more than 10 to 15 EUR because they simply don't have more money to spend for one of their hobbies. But others like me can comfortably leave out other things in order to support Olaf. It's just a matter of will.
Because Olaf's isn't dead keen on money, he perhaps can make a special offer to those who really cannot afford the full price. But that's another story and a bit tricky because a lot of people aren't honest.
But what really strikes me badly on the belly is that some are crying to make Roadshow open source.
Who of you has got the knowledge that Olaf has in order to improve or apply bug-fixes to Roadshow?
If it goes open source I would speculate that it sooner than later has got so many bugs that it is not useable anymore!
If writing a TCP/IP stack is really that easy, why do you care about Roadshow at all? Write your own!
I admit that I don't have Olaf's know-how (for me it seems as if he is coming from an other star) and because of this I cannot write my own TCP/IP stack nor would I find the time to read about the essentials in first place.
To find an end, I would happily pay for Roadshow in case I can use an other payment as PayPal, because I don't have a PayPal account at all. Should be no problem at all because I can personally contact Olaf by email (which hasn't changed since years) and fulfill it via direct debit.
biggun
I think a good solution would be some sort of "community" contract.
That before a project becomes abandoned the programmer will release the sources like is was done was AWEB.
I would sign this with other programmers but not with Olaf. He is holding the fort when all others have already deserted.
He has an exceptionally high sense of responsibility regarding his programmes.
-
Saying that it's a shame to reinvent the wheel when the last guy who made a wheel isn't going to make any more wheels inevitably leads to the cart breaking down. It may be possible to borrow or steal another wheel, but this will only get you so far. At some point somebody will have to make more wheels. And the best reason for reinventing the wheel has always been: to make more wheels.
Not sure this analogy works for me, but I think the point is there may well be people who would contribute to an existing piece of software, who wouldn't have the time to make something from scratch anyway. That's at least how I see it.
-
I dont get it, why so many people think open sourcing will save the world. It works well on platforms with large communities of developers and users but its not our current situation. Olaf is around for ages, take care, Raidshow works great as part of OS4, will work great as 68k tcp/ip stack, there are people who would like to purchase it.
So whats kolla's (and few others) problem?
Scuse anyone else for sharing opinions then on a "forum". I don't see how discussing the open source stuff affects you really. Even if it went that way you would get your roadshow.
I'm currently working on a large project with only 2 main developers. sure we could do with more, but we manage. the code has been written over the last 8 years by many more people, so these days we are looking after it mostly, and working on improvements for a next point release. other people chip in with documentation, skins, and other things. This can and does work - especially with software like this that people still want to use.
-
I suspect that this is just the tone of the community these days. Talk, talk, talk rather than do, do, do. It's so much easier to spin stories, to vent frustration in writing than to get out of the car, kick the tires, bend down into the mud and change the flat. You'll get dirty either way, but only one way will get the car moving again.
Maybe I've read this differently, but I've not seen the discussion as any bitterness. Plenty of devs have left the Amiga of course, but there are some left. As a hobby machine, with people with jobs and families, I guess you can't expect people to be hacking away in their bedrooms for endless hours on the next amiga release that a handful of people will run. It still happens but in smaller numbers.
I'm pretty sure myself and others in the discussion as well as talking, have also done plenty.
-
Not sure this analogy works for me, but I think the point is there may well be people who would contribute to an existing piece of software, who wouldn't have the time to make something from scratch anyway. That's at least how I see it.
It definitely is easier to modify something that already exists than to start from scratch. Not all development work has to begin with ideas and no code written to play with.
My belief is that you can learn a lot by starting from scratch in a field which piques your curiousity and in which you had, so far, little experience. It helps you grow as a developer to carry everything in your head that makes up the project you started. To a lesser degree, carrying only part of such a project in your head can be a very rewarding learning experience, too.
It's just that if you can become a master of a field, no matter how small, it will be immensely satisfying and keep driving you to expand your horizon. Given how few Amiga developers are left who even dare to scratch the complex stuff, we need more people willing to master the field, or are at least willing to give it a shot.
A TCP/IP stack is a complex beast, but there are enough breadcrumbs to lead you to building one and learn a lot on the way. This is the kind of project your friendly professor hands you as a thesis project, as it happened for AmiTCP.
-
But what really strikes me badly on the belly is that some are crying to make Roadshow open source.
Who of you has got the knowledge that Olaf has in order to improve or apply bug-fixes to Roadshow?
If it goes open source I would speculate that it sooner than later has got so many bugs that it is not useable anymore!
If writing a TCP/IP stack is really that easy, why do you care about Roadshow at all? Write your own!
I admit that I don't have Olaf's know-how (for me it seems as if he is coming from an other star) and because of this I cannot write my own TCP/IP stack nor would I find the time to read about the essentials in first place.
It has been suggested as a possible model, no-one is crying I assure you. Due to the software license this doesn't seem possible anyway, but I don't see a problem in discussing various options.
Your speculation doesn't make sense to me. You can still fix up code without understanding every single aspect about it (and learn as you go). No-one but olaf has suggested writing a tcp/ip stack is easy ;-) I wouldn't put it on my easy list.
-
I dont get it, why so many people think open sourcing will save the world. It works well on platforms with large communities of developers and users but its not our current situation. Olaf is around for ages, take care, Raidshow works great as part of OS4, will work great as 68k tcp/ip stack, there are people who would like to purchase it.
So whats kolla's (and few others) problem?
I dont care for whether open sourcing saves the world or not, I only care for the bit where it makes my life easier. To use the size of the community as some sort of argument for why open source is not the way to go is just blatantly silly, a lot of devlopers have left Amiga exactly because one cannot do jack with amiga software without stepping on people's toes.
Look at who's fixing updates and patches for AmigaOS 3.x today - every single one of them have stated that they want OS3.x to be open sourced, to simplify their work, distribution and all.
-
I suspect that this is just the tone of the community these days. Talk, talk, talk rather than do, do, do.
I understand that what you're saying is that Amiga as a platform is only meant for developers, an not users. People who for various reasons do not write software themselves should have no saying around here, right?
It's quite like how I see the MorphOS situation; MorphOS is mostly about some developers doing an OS and software for themselves, and the rest of us are just a bunch of annoying whiners who at least should pay to compensate for all the unneeded noise we make.
-
I understand that what you're saying is that Amiga as a platform is only meant for developers, an not users.
I would not presume to be so pessimistic. My personal impression is that the number of people who make stuff in this community has dwindled so far that that the relation to the number of people who use the stuff has become unsound.
I'm a developer first and user second, so that may cloud my judgment in this matter, though.
People who for various reasons do not write software themselves should have no saying around here, right?
Now that sounds very pessimistic. Without the user, there is no real place for the developer either.
For one thing, a developer can't create magic in his backroom just for his own enjoyment forever. It has to get into the hands of people who put it to use. More importantly, without the user the developer is in a certain danger to produce something that isn't particularly useful or good.
It's quite like how I see the MorphOS situation; MorphOS is mostly about some developers doing an OS and software for themselves, and the rest of us are just a bunch of annoying whiners who at least should pay to compensate for all the unneeded noise we make.
Developers and users are by nature groups with little overlap. How each group member deals with the other group's members is something that comes down to social aptitude, or the lack of such graces. From my experience, the developer is more likely to offend the user than the other way round.
Who believes he does the dirty work of shaping the software? The developer thinks so, and may even suspect that the user isn't capable of it. Finding and fixing bugs certainly puts a lot of stress on the developer. But it's just as much the user who shapes the software by how he uses it, or fails to be able to use it properly, due to limitations of the design.
It's probably silly to say so, but developer and user are in complementary positions. It's poisonously easy to mislead oneself about this relationship.
-
I really don't get it...
Is it already really too much from Olaf to ask for a little donation for the time he spent implementing an TCP/IP stack?
No, ofcourse not, but it's a tad late to come dragging with this stack now, and many of us much more want to pay a large donation and get the sources too, that's all. It is either that or the old game of dealing with keyfiles, "how many machines am I allowed to use this on", various futile attempts at copy protections that many find of great joy in circumventing, binary patches to fix this and that.. all the nonsense that we have become used to.
Instead you could have a "here's my IP stack, here are the sources, here's the license and here's my paypal account - please donate if you find this usefull" - yeah, I know, way too boring, huh?
-
then you don't have a product, even if it has been open sourced.
And there is where you're flawed - thinking of software as products, that's just way old fashioned.
-
And there is where you're flawed - thinking of software as products, that's just way old fashioned.
That's where you make assumptions about why I used the term "product". In the dictionary definition of the term a product is eventually intended for sale. I used the term less precisely as the end result of the process which produced it. I could have used "outcome" instead, but it doesn't really fit the context.
If you have a better term for this thing, let's talk about it.
-
No, ofcourse not, but it's a tad late to come dragging with this stack now, and many of us much more want to pay a large donation and get the sources too, that's all. It is either that or the old game of dealing with keyfiles, "how many machines am I allowed to use this on", various futile attempts at copy protections that many find of great joy in circumventing, binary patches to fix this and that.. all the nonsense that we have become used to.
I don't have to play that game, and I do not intend to. No keyfiles, no copy protection. If there's going to be an impediment to using Roadshow, it will be in the demo version and nowhere else. I have been around long enough to know how this keyfile and copy protection business pans out. It's a fool's game, to use a more polite term for it.
Instead you could have a "here's my IP stack, here are the sources, here's the license and here's my paypal account - please donate if you find this usefull" - yeah, I know, way too boring, huh?
I cannot part with the source code, but the rest of the list sounds OK to me.
-
I would not presume to be so pessimistic. My personal impression is that the number of people who make stuff in this community has dwindled so far that that the relation to the number of people who use the stuff has become unsound.
This is just nonsense, first you're saying that you're not so pessimistic, and then you present an even more pessimistic view - seriouslly, if anyone's pessimistic here it is you, and not I :lol:
For one thing, a developer can't create magic in his backroom just for his own enjoyment forever.
True, every now and then they leak out youtube videos, or display some "magic" on various meetings, mostly to stir up the community and create a lot of entertaining noise. I here of developers in our community, not developers in general.
More importantly, without the user the developer is in a certain danger to produce something that isn't particularly useful or good.
That's hardly a danger when you don't really give a rats ass about other users than yourself and maybe the small group of people you share code with.
Developers and users are by nature groups with little overlap.
Nonsense - all developers are also users.
From my experience, the developer is more likely to offend the user than the other way round.
Since the developer is more inclined to have something that the user wants, so the user retain him-/herself from being upfront with the developer. Also alot of developers are notorious for striking down on anyone who say anything against them - many of them seem to suffer from god syndrom.
There's lots of crap software around, and many developers are easily offended if you criticize their work, and they typically have a certain following of mostly ignorant groupies. For example, I have been quite critical about certain developments in both OS4 and MorphOS, since I think lots of the choices made there are just totally bogus and more or less destroy what I find cool about Amiga, turning the OSes more into flawed Windows wannabes than cool Amiga systems. So I'm officially a troll in both camps.
-
This is just nonsense, first you're saying that you're not so pessimistic, and then you present an even more pessimistic view - seriouslly, if anyone's pessimistic here it is you, and not I :lol:
Don't try to undercut my pessimism. Just like everybody else I enjoy being miserable.
On a more pessimistic note, I entertain the idea that getting more people to produce software for the Amiga market will be beneficial for the community in general.
That's hardly a danger when you don't really give a rats ass about other users than yourself and maybe the small group of people you share code with.
If anybody claims to consider this a strategy worth following, it's only going to cause grief for him, and others. I can't see this working out any positive way at all. Why write software if you can get thoroughly drunk or high instead? There are shorter and narrower paths to debauchery or enlightenment.
Nonsense - all developers are also users.
So one set overlaps with itself. This isn't what I was saying: the number of producers is by its nature either smaller than the number of consumers, or equal to it. In the field of software it's likely much smaller than the number of consumers, i.e. users. This relation can be sound, or it can be unbalanced. I believe it is unbalanced in the Amiga community.
Since the developer is more inclined to have something that the user wants, so the user retain him-/herself from being upfront with the developer. Also alot of developers are notorious for striking down on anyone who say anything against them - many of them seem to suffer from god syndrom.
Occupational hazard. So what else is new? As I wrote, you don't have to play this game and you don't have to like it.
If you end up in a community where you are likely to be the target of ignorance, delusion and abuse, it's either a sign that the community needs to change, or to leave that community. Neither path may be easy.
There's lots of crap software around, and many developers are easily offended if you criticize their work, and they typically have a certain following of mostly ignorant groupies.
So? What responsibility do you have regarding what other people think? Holding a particular point of view is not an offensive tactic.
For example, I have been quite critical about certain developments in both OS4 and MorphOS, since I think lots of the choices made there are just totally bogus and more or less destroy what I find cool about Amiga, turning the OSes more into flawed Windows wannabes than cool Amiga systems.
Join the club. Change is not made without inconvenience, even from worse to better. Now what would be worse or better is a matter of opinion. The question is if you can make your voice heard and affect how the change plays out.
It's far from obvious how the current state of affairs in either camp will shape the development paths. I know, personally, that some of the choices I made for Roadshow did not work out so well, and the really bad thing (at least for me) is that finding an alternative is even more difficult to come up with than the original, (and in retrospect) flawed idea. You just can't predict all the outcomes and side-effects of any decision you make in software development. Your choices and your mistakes will catch up with you.
So we end up with things that don't match our intentions, even if we were not part of the decision making. Some of the decision making comes out of business practice, but in this Amiga business, a good part comes out of engineering. And engineering is susceptible to reason and reality. If you can make a case for what you feel is important, it's possible that it will have an effect in the engineering domain.
Of course, it helps if your creds include a bit of an engineering background. And if your input is not heard or heard, but ignored, it might not because your creds are considered to be lacking, it might just be insecurity on the part of the decision makers. Don't pity these guys, they have to make decisions in a high-risk environment. Making ever so slightly flawed decisions is part of the job.
How you deal with these conditions is up to you, of course. You can become bitter about it, you can consider this a reinforcement of your idea of being helpless, you can keep organizing your claim and ideas and keep trying. Just to name a few options.
So I'm officially a troll in both camps.
You're a troll as long as want to be a troll. Are you content being one?
-
You're a troll as long as want to be a troll. Are you content being one?
If by troll you mean someone who bothers to criticize the "progress" made in mentioned systems, then sure, I'm quite content. Hardly a day go by without me trolling (http://www.amigans.net/modules/newbb/viewtopic.php?post_id=55463#forumpost55463).
Edit: So it seems my comment on amigans.net was out of line and I was edited out, luckily I have a screenshot (http://amiga.nvg.org/moro/sollie1.png) of the post in question.
-
@Kolla: Problem is there's no real goal defined for both camps. So development just goes on, people follow a direction, then the other one,... You clearly have your vision, and maybe it's not what the developers have in mind. So when some decision is made you may not agree, so you critize, again, and again, and that's what they dislike. And then you're seen as a "troll".
Problems is communication is needed, but the developers, as you said, are mostly coding for themeselves, for their own pleasure,... following the direction they think is the good one.
-
@Kolla: Problem is there's no real goal defined for both camps. So development just goes on, people follow a direction, then the other one,...
Which is fine, if they were an open system like AROS for example, but they're not, they so desperatly try to delude themselves into thinking that they're doing it as a business, and they promote their stuff as if they have great plans and whatnot, when in reality it's all just futile attempts at smoke and mirror. And to top it off, they prevent anyone else from forking off by keeping their systems all locked and closed off.
You clearly have your vision, and maybe it's not what the developers have in mind.
And thanks to the political nonsense, people with slighly other vision than "the officials" will never bother to involve themselves either. This is one of the reasons so many developers have fled.
So when some decision is made you may not agree, so you critize, again, and again, and that's what they dislike. And then you're seen as a "troll".
And that's perfectly fine by me, it says more about them than about me.
Problems is communication is needed, but the developers, as you said, are mostly coding for themeselves, for their own pleasure,... following the direction they think is the good one.
I've noticed that the Friedens are getting fed up as well, with some luck OS4 is soon dead in water, and Hyperion launches some commercial desktop for Linux or whatever, as OS5, based on Qt it seems. And it too will fail, but who gives a damn...
-
@olsen
Quite a volume of well thought out and well intentioned posts from this thread. I'll respond briefly, to save some white space...
A community contract I'm not so sure of. We have had organized goodwill operations in the Amiga community by the dozen, and where are we now?
(1)Initiatives made in public are often well intentioned, but often doomed from the start for the very reason you state in your posts concerning community reaction.
(2)You know as well as I that unless you do a significant amount of research ahead of time, you are apt to draw a short sighted conclusion about what direction to take.
(3)All of this takes us back to "business", something which -all things amiga- is not.
Anyone who has yet to realize that poor communications is apt to be the amiga legacy, just hasn't been very intimately involved with same. That much is certain.
Personally, I'd not start with something that lends itself to shaping into an organization that produces yet more words on the screen. It would help to know what the Amiga community would find helpful, if it were to materialize through the hard work of developers.
I see some of that happening right now with the MUI/zune initiative, although I regret it appeared in public quite the way it did, again...for those reasons you expressed about community response.
I feel that when people start to talk about "limited resources" and use the term "hobby" over and over again, to describe current affairs, the prophecy becomes self-fulfilling. More times than I can count I've posed the notion that just because we are who we are should -not- preclude us from employing some businesslike thinking.
I'm not going to waste time detailing the failures of the past on this score.
#6
-
I have been quite critical about certain developments in both OS4 and MorphOS, ... So I'm officially a troll in both camps.
I'd hate to break your martyr complex, but people don't get classed as trolls for being criticial - they get classed as trolls for being rude, obnoxious, inflamatory, and generally socially inept (intentionally or not)... Which is a long way of saying if someone act's like a jerk then they'll get labelled as one.
It is of course possible to be criticial without being a jerk, although it does take more effort.
-
And to top it off, they prevent anyone else from forking off by keeping their systems all locked and closed off.
I thought you were against wasting of effort by having multiple Amiga-like systems? Cos forking would make the situation worse, not better.
I've noticed that the Friedens are getting fed up as well, with some luck OS4 is soon dead in water, and Hyperion launches some commercial desktop for Linux or whatever, as OS5, based on Qt it seems. And it too will fail, but who gives a damn...
You come across as very bitter. Has life been that bad to you? (i.e. You can't build anything good yourself, so you try to destroy others' efforts instead?)
-
No one can give their opinion at this times, just the support is the one and only valid answer, roadshow can be cool (in late 90s of course) maybe its more usefull a usable browser for 68k and FREE.
-
Hello, I am one of those too, who asked for a 68k release since
many moons. I feel having a tcp/ip stack available is mega
important, also for a niche retro platform like this.
Thanks to mechy for having stirred the interest. I hope that you
all get back on track, and help olsen getting his stack put
to good use on 68k systems.
@olsen
About the missing GUI, I would happily use the stack without,
provided basic documentation for the configuration files
is present. (I am sure they will be).
Regarding the distribution media, personally I would prefer
a download. However, with this method I can foresee some
users asking you for a re-download later on though.
As for the pricing, I am very flexible with important products
like this. I buy hardware without looking too much at the
price, deneb and zorram latest, and I believe I have an idea
of the amount of hours and work you put into this. I bought
AmiTcp and later MiamiDx, but I dont recall their price points.
Provided that NAT functionality is possible, 50 euro would
not make me think twice, but I agree with other post'ers, that
a low price certainly may invite to buy.
For the support load on the author, I would like to point to
the, in my view, back then, very well working solution which
the MiamiDx author used, the MiamiDx mailing list, where
users helped users. Perhaps this, the idea of users helping
users being the base support method, could possibly leave
you in a more relaxed position.
I still have a system running 24/7/365, with uptimes passing
the 200 days mark, and would still very much like to try
out Roadshow as the main router for my lan, for an
interesting comparison to MiamiDx in the same setup.
A side note; I feel you should have semi-included AmigaNOS
in your list of tcp/ip implementations, however I know
that it is mainly for radio amateur use and not for use
by the masses. I used it with an AX25 modem on my A1000,
and it was great fun improving functionality and make it
compile on latest sas/c version.
Best Regards
omgas
Oh My God, Another Stack ;)
-
If by troll you mean someone who bothers to criticize the "progress" made in mentioned systems, then sure, I'm quite content. Hardly a day go by without me trolling (http://www.amigans.net/modules/newbb/viewtopic.php?post_id=55463#forumpost55463).
Call me thick, but trolling usually involves baiting and watching for the resulting hullabaloo to tear a discussion apart. In its most benign form it can be a mild prank. At the other end of the spectrum it's a contagious he-said-she-said form of clusterbombing a community. Guaranteed to tarnish your karma if you follow it to the deep end.
For sure, criticism looks different. If you intend to make a point and be taken seriously, any form of pranks or trolling is guaranteed to undermine your credibility. Do it often enough and your chances become slimmer to ever become a contributing voice to the discussion. If what you really wanted was to make yourself heard, it will only become the more frustrating if you're being labeled a troll and get ignored. Don't mix your signals...
-
And thanks to the political nonsense, people with slighly other vision than "the officials" will never bother to involve themselves either. This is one of the reasons so many developers have fled.
If your daily work and commitment to a project involves making a contribution that implies a certain amount of risk-taking, it entitles you to take part in making decisions which you may not have to justify to anybody else. You should explain them, if you can, considering their impact on the existing community. I personally believe you have a duty to explain yourself, if not just to clear up any misconceptions your actions may leave.
But if your involvement does not even extend to the same degree of risk-taking then your criticism will not have the same degree of impact. It's as simple as that. This can be frustrating for sure. If you do not get involved in the game, you can't play.
I've noticed that the Friedens are getting fed up as well, with some luck OS4 is soon dead in water, and Hyperion launches some commercial desktop for Linux or whatever, as OS5, based on Qt it seems. And it too will fail, but who gives a damn...
If you think ill of the people who you merely disagree with, it will cloud your judgment. If you publicly wish them ill, it will reduce your standing in the public eye. This is the path best not taken.
You can disagree with anybody, but your chances to successfully understand what they are trying to achieve, and your chances to influence their decision making will be slim if you view them disagreeing with you in such a dismal light.
-
About the missing GUI, I would happily use the stack without, provided basic documentation for the configuration files is present. (I am sure they will be).
The documentation for the OS4 Roadshow is in decent shape, but I think I should do better.
Regarding the distribution media, personally I would prefer a download. However, with this method I can foresee some users asking you for a re-download later on though.
That calls for a certain, more refined infrastructure, and registration. Without the registration, there would be no re-downloads, of course.
Provided that NAT functionality is possible, 50 euro would not make me think twice, but I agree with other post'ers, that a low price certainly may invite to buy.
Well... 50€ is likely far too much for what Roadshow offers right now. The NAT is part of the IP filter package. It works, but it requires a certain amount of preparation and understanding to get it going. Sample scripts are provided for setting up the filter and the NAT. I've successfully used my A3000UX as a firewall/gateway for the rest of my wired LAN.
For the support load on the author, I would like to point tothe, in my view, back then, very well working solution which the MiamiDx author used, the MiamiDx mailing list, where users helped users. Perhaps this, the idea of users helping users being the base support method, could possibly leave you in a more relaxed position.
You'd have to have a dedicated forum for that. Hm... I have little experience with setting something like that up. Any suggestions?
I still have a system running 24/7/365, with uptimes passing the 200 days mark, and would still very much like to try out Roadshow as the main router for my lan, for an interesting comparison to MiamiDx in the same setup.
That may indeed turn out to be very interesting. I do not recall running Roadshow for such prolonged periods of time. AmigaOS is a single user, desktop operating system after all, isn't it? I rarely left my Amiga turned on for more than 24 hours. The cooling fans and the SCSI disk drive are just too loud.
A side note; I feel you should have semi-included AmigaNOS in your list of tcp/ip implementations, however I know that it is mainly for radio amateur use and not for use by the masses. I used it with an AX25 modem on my A1000, and it was great fun improving functionality and make it compile on latest sas/c version.
I'm sorry, AmigaNOS did not come to my mind. I never used it, but I darkly remember that it had been around for a long time while the Amiga TCP/IP solutions were just taking baby steps.
Oh My God, Another Stack ;)
And I thought it was full of stars ;-)
-
I'd hate to break your martyr complex, but people don't get classed as trolls for being criticial - they get classed as trolls for being rude, obnoxious, inflamatory, and generally socially inept (intentionally or not)... Which is a long way of saying if someone act's like a jerk then they'll get labelled as one.
Excuse me, but you obviously have no idea what trolling is - try a dictionary or the jargon file.
-
Excuse me, but you obviously have no idea what trolling is - try a dictionary or the jargon file.
It's a mixed metaphor and an excellent example of the degradation of the English language and communication in general.
-
I thought you were against wasting of effort by having multiple Amiga-like systems?
No - pay attention, I do not mind having multiple Amiga-like systems - how does sharing code contradict having multiple systems?
Cos forking would make the situation worse, not better.
Why? Forking would make more options to pick from, that's a good thing.
You come across as very bitter.
Because I dont put smileys all over the place? :)
Has life been that bad to you? (i.e. You can't build anything good yourself, so you try to destroy others' efforts instead?)
Life is good to me, don't worry. And exactly what am I destroying?
Wanna try my Gentoo/m68k (http://tinderbox.dev.gentoo.org/default-linux/m68k/) distro? It's all open source, runs on Amigas, is IPv6 enabled and all, just don't expect any support! :roflmao:
-
@olsen
At leat you know what trolling is :)
Don't mix your signals...
I'm not, you can find news postings by me in 1996 or so where I'm saying more or less the same things as now - that's where the trolling comes in, people are just tired of me constantly pointing out the elephants that they want to ignore.
-
Wanna try my Gentoo/m68k (http://tinderbox.dev.gentoo.org/default-linux/m68k/) distro? It's all open source, runs on Amigas, is IPv6 enabled and all, just don't expect any support! :roflmao:
Did you build it on cheezy ? ;-) (I'm assuming its binaries right? no way I'm compiling x.org / kde on my amiga :) )
-
But if your involvement does not even extend to the same degree of risk-taking then your criticism will not have the same degree of impact. It's as simple as that. This can be frustrating for sure. If you do not get involved in the game, you can't play.
Again speaking as if programming for Amiga today is some sort of profession - there is no game for crying out loud, that's just a stupid illusion, and only fools take risks here, meaning, by your logic, fools criticism should count most? That explains alot then :hammer:
If you think ill of the people who you merely disagree with, it will cloud your judgment. If you publicly wish them ill, it will reduce your standing in the public eye. This is the path best not taken.
I don't want anyone ill, did I give that impression?
You can disagree with anybody, but your chances to successfully understand what they are trying to achieve, and your chances to influence their decision making will be slim if you view them disagreeing with you in such a dismal light.
It's typically quite obvious what "they" are trying to achieve. And I'm sorry, but I have a life outside of "Amiga" where I have no problem communicating with people, I'm also involved in various software projects (all open source btw. - fancy stuff) where there's also no problem communicating. In my experience it's really only in the amiga community there are so many problems, since in other communities (open source ones) one can easily split out a fork or start a different distro or whatever. That's just so much better.
And still we have OS4 and MorphOS advocates that fly the "Linux suxx!!1" banner, it's quite hilarious.
-
Did you build it on cheezy ? ;-) (I'm assuming its binaries right? no way I'm compiling x.org / kde on my amiga :) )
Haha, no - it was mostly buildt on my A1200, but eventually I moved it to a PC running Aranym (atari emulator) where I build all the stuff now. Also, don't worry about x.org - there's no X11 in my distro ;)
Cheezy has received a mTec 68020i card btw. one of these days as I get the spirit (and find some room), I'll set it up and enjoy the upgrade :)
-
Haven't read the whole thread(!) but I'd buy it too, not just for the stack but to show support for the time Olaf takes answering all the questions at utilitybase. Unfortunately utilitybase can be somewhat dangerous to acess with an x86 machine nowdays though:)
-
In case you are interested, here are some speed test figures, which can also be found in the http://eab.abime.net/showthread.php?t=54698 thread. I just finished the A1200HD and A600HD tests, so let's have a look:
Ariadne I, Roadshow 4.69, A3000T (040, 40 MHz)
891 KBytes/s
Ariadne II, Roadshow 4.69, A3000T (040, 40 MHz)
845 KBytes/s
A2065, Roadshow 4.69, A3000T (040, 40 MHz)
781 KBytes/s
Ariadne I, Roadshow 4.69, A3000UX (060, 50 MHz)
891 KBytes/s
Ariadne I, Miami 3.2b SANA-II, A3000UX (060, 50 MHz)
669 KBytes/s
Ariadne I, Miami 3.2b MNI, A3000UX (060, 50 MHz)
882 KBytes/s
Ariadne I, Miami Deluxe 1.0c SANA-II, A3000UX (060, 50 MHz)
633 KBytes/s
Ariadne I, Miami Deluxe 1.0c MNI, A3000UX (060, 50 MHz)
860 KBytes/s
Ariadne I, AmiTCP/IP Genesis 4.6, A3000UX (060, 50 MHz)
812 KBytes/s
Ariadne I, Roadshow 4.71, A3000UX (060, 50 MHz)
916 KBytes/s
Ariadne I, Roadshow 4.162, A3000UX (060, 50 MHz)
941 KBytes/s
Ariadne I, Roadshow 4.205, A3000T (040, 40 MHz)
977 KBytes/s
As you can see, Roadshow goes about as fast as the 10 MBit/s Ethernet hardware will permit. None of the alternatives (Miami, AmiTCP) come as close to the hardware limit as Roadshow does.
Now for the downer:
PCMCIA NE2000 card with cnet.device 1.9, Roadshow 4.294, A1200HD (14 MHz 68EC020; 4 MBytes of fast memory)
480 KByte/s
PCMCIA NE2000 card with cnet.device 1.9, Roadshow 4.294, A600HD (7 MHz 68000; 2 MBytes of chip memory, no fast memory)
134 KByte/s
As you can see, the A600HD is about as fast as molasses going up a hill in January, on crutches. But it shows that the stack works under low memory conditions on the lowest of the low end configurations. This is barely faster than sneakernet...
-
I think that speed is pretty impressive for an a600! (and for the other machines). I used to have my a500 connected via PLIP and that is much slower :) (and before that SLIP.. eek)
-
Impressive speeds indeed. I'm also willing to pay €10-15 for it.
-
@Olaf
Very nice results. I see that an EAB topic is a bit more technical :) I wonder how many KB/s i can get using my 3com pcmcia lan card.
btw. How about making a new driver specification (SANA3) for all amigalike systems?. Morphos and OS4 have already drivers for 1 gbit NICs so i it could be useful.
-
Great results on pcmcia! I get those speeds (and often lower) on my A1200 w 060@80 via MiamiDX!
-
PCMCIA NE2000 card with cnet.device 1.9, Roadshow 4.294, A1200HD (14 MHz 68EC020; 4 MBytes of fast memory)
480 KByte/s
Wow, that's at least 30% faster than my PCMCIA NIC with a 68040 / AmiTCP
-
I can say i am not surprised by the results at the end on the 2 stock machines. both using 16bit pcmcia interface. I am sure that accelerating them would make quite a difference.
the 600 going to chip is well, definately expected.. LOL
nice list of results here Olaf!
Was the ariadne II you have fixed to run full duplex? i recall back in the day contacting villagetronic about this on mine.Seems there were bugs with some thatcould use a hardware fix?
mike
-
Olsen
Thanks for the speed comparisons very interesting and good illustration of Roadshow speed. Can i ask you again why it is that you decide to release this NOW instead of back in 2003 when everyone was trying to get you to? Before the last of the amigans jumped ship?
-
@Olaf
Very nice results. I see that an EAB topic is a bit more technical :) I wonder how many KB/s i can get using my 3com pcmcia lan card.
btw. How about making a new driver specification (SANA3) for all amigalike systems?.
The word is "difficult", not just "challenging".
Morphos and OS4 have already drivers for 1 gbit NICs so i it could be useful.
I do not know about MorphOS, but OS4 uses the SANA-II driver architecture, and it has no support for DMA-assisted network data transfer which severely hampers its performance with gigabit NICs. This is still an unsolved problem, due to the state of the SANA-II standardization.
-
Great results on pcmcia! I get those speeds (and often lower) on my A1200 w 060@80 via MiamiDX!
Do you get these speeds with a PCMCIA networking interface, or do you use something else?
-
Wow, that's at least 30% faster than my PCMCIA NIC with a 68040 / AmiTCP
Hm... I had no idea how far the performance range actually goes. So this is better than I could hope to expect.
It also suggests that the actual performance of the CPU is less of a factor here. I suspect that the PCMCIA interface may be what is limiting overall performance in this area.
-
Was the ariadne II you have fixed to run full duplex?
I have no idea. The test setup I ran back then (in 2003; these are older test figures) probably did not benefit from full duplex operations. The tests exercised data reception, in the LAN, over a prolonged period of time: the Amiga received data, the ftp server on the other end of the connection just pumped it to the Amiga. In this scenario the receiver just sends ACK responses for every few KBytes of data received correctly. There is not enough I/O overlap to make full duplex operations contribute significant performance improvements over a half duplex card, such as the Ariadne I. As you may see among the performance figures I posted, the Ariadne I did significantly better than the Ariadne II.
i recall back in the day contacting villagetronic about this on mine.Seems there were bugs with some thatcould use a hardware fix?
I also remember that the hardware had issues with the full duplex operations, and that this was not something that could be corrected just in software.
-
Olsen
Thanks for the speed comparisons very interesting and good illustration of Roadshow speed. Can i ask you again why it is that you decide to release this NOW instead of back in 2003 when everyone was trying to get you to? Before the last of the amigans jumped ship?
The short answer is: because I burnt out. I was originally trying to get Roadshow released with the publisher providing a GUI, and me contributing the TCP/IP stack, the drivers, tools, SDK, etc. The first attempt collapsed as the Amiga market collapsed. The second attempt stalled until it became really painful to continue. The third attempt collapsed because I was, as I now see it in retrospect, burn out already.
I blame myself for trying too hard to do too much for a long time. It wasn't just that I was trying to get Roadshow off the ground, I also juggled university, my own company, the OS4 development work and a handful of other things that needed attention. This will go down well (for some definitions of "well") as long as your energy and constitution permit, but you're actually living on borrowed time, so to speak.
So, all of this had to come to a stop at some point. And I've just crawled out of from whatever stone I was hiding under to see if there was still enough fun left in me and the Amiga community for another round of doing what I believe I do best...
-
Hello,
@olsen
for your question about ideas for setting up support, for me personally
having a user2user mailinglist would be just fine. Perhaps the web
Google Groups service could be used. Maybe someone here knows
if it is possible to use this in a moderated mode, and if
this suits the intended use at all.
Thankyou for the speed tests on base hardware. Networking easily wins
over sneakernet for moving larger files, and convenience often wins
over any speed limitations there might be.
Also I cant wait to try your stack on my A1000/68010 A590/acard/CF/2MB
RX500/1MB Zorro/A2065 setup. Here a GUI-less stack with a relatively
low memory footprint would be very useful.
Btw, for those having a network interface on many systems, and wanting
to run more than one system at the same time, perhaps you could share
your thoughts on this? I feel that complicated license terms tends to
put people off, personally however, I would not mind having some kind
of site license option.
I hope that you decide for a relaxed release,
Best Regards
omgas
-
Hello,
@olsen
for your question about ideas for setting up support, for me personally
having a user2user mailinglist would be just fine. Perhaps the web
Google Groups service could be used. Maybe someone here knows
if it is possible to use this in a moderated mode, and if
this suits the intended use at all.
A searchable archive of notes would be nice to have, and probably a Wiki, too. I'm still looking at the options, and the cost involved. If this turns out to be affordable, it won't affect the price of the stack, I hope. Now that everybody seems to suggest that going beyond 25€ would not be a good idea, this is probably what the upper end of the scale must look like.
Thankyou for the speed tests on base hardware. Networking easily wins
over sneakernet for moving larger files, and convenience often wins
over any speed limitations there might be.
I was asked, over at eab.abime.net, how today's most commonly used configurations would fare, and I promised to look into providing the figures by this weekend. This turned out to be an interesting exercise all by itself, before I even managed to run the tests. Looking for the NIC, the power supply, the mouse, the video cable, etc. I discovered stuff I thought I had lost years ago, and I also found and fixed two bugs in Roadshow and the PPP drivers as well.
Also I cant wait to try your stack on my A1000/68010 A590/acard/CF/2MB
RX500/1MB Zorro/A2065 setup. Here a GUI-less stack with a relatively
low memory footprint would be very useful.
Roadshow works surprisingly well on a configuration like that. The hardest part of testing on the A600 was in sitting down, cross-legged, in front of the TV and typing on that tiny keyboard. My back still aches, just thinking back to it.
Btw, for those having a network interface on many systems, and wanting
to run more than one system at the same time, perhaps you could share
your thoughts on this? I feel that complicated license terms tends to
put people off, personally however, I would not mind having some kind
of site license option.
The original plan was to let you install and use your copy of Roadshow on up to two machines without your conscience bothering you. If you wanted to use it on more than this number of machines, then, scout's honour, you should have chipped in for another copy of the package.
-
Do you get these speeds with a PCMCIA networking interface, or do you use something else?
Yes, with a 3com ethernet card. I think pcmcia is not the limit though as it can reach about 2mb/sec at max, at least that's the speed with a squirrel scsi so the interface itself has more throughput capacity than what's achieved via Miami or AmiTCP.
-
@olson:
Actually your question regarding interest is a god's send at this point in time. Seeing I have about 15 to 20 ethernet equipped Amiga's standing around I have recently been looking for a nice TCP/IP solution. AmiTCP is either a dog to configure, slow and outdated or a more recent version simply not available after the H&P OS3.9 debacle.
Miami is no longer available, I would have loved to buy a proper keyfile for it, it's just not possible. That leaves no other really viable and available option.
So, in that regard, yes!! Please do release a 68K version, specially now that you've shown the speed increase possible on a classic machine I would most certainly pay for a valid license!
Thanx for your support for the classic machine, I extend that gratitude to all coders still active on the classic platform, if it wasn't for you all computing on this wonderful machine would be a lot less enjoyable!
-
Just want to toss in some numbers from a slightly different world, using wget to download a 88,616,960 bytes file from a webserver on same LAN, over IPv6 (for what it's worth), to /dev/null - all machines running Linux 2.6.30:
A1200, Blizzard 1230IV 50MHz 68030, Micronik-ZII, A2065 (http://amiga.nvg.org/daneel/): 169 s, ~512 KB/s
A1200, Blizzard 1260, 50MHz 68060, N2000 PCMCIA (http://amiga.nvg.org/chetter/): 95s, ~910 KB/s
Macintosh Quadra 610, 25MHz 68040: 94s, ~920 KB/sec
-
Olsen
thanks for your response. I understand what you mean by burnt out. After my time with Genesi I couldnt even turn on my peg... glad you are back. Enjoy the amiga community its still alive!
-
@tahoe: looks like u will need to buy 20 keyfiles..
-
Just want to toss in some numbers from a slightly different world, using wget to download a 88,616,960 bytes file from a webserver on same LAN, over IPv6 (for what it's worth), to /dev/null - all machines running Linux 2.6.30:
A1200, Blizzard 1230IV 50MHz 68030, Micronik-ZII, A2065 (http://amiga.nvg.org/daneel/): 169 s, ~512 KB/s
A1200, Blizzard 1260, 50MHz 68060, N2000 PCMCIA (http://amiga.nvg.org/chetter/): 95s, ~910 KB/s
Macintosh Quadra 610, 25MHz 68040: 94s, ~920 KB/sec
I recently moved 3 TBytes in thirty seconds when I replaced the two drives in my NAS ;-)
But seriously, you see what kind of hardware the A2065 is. This is the oldest kind of networking gear for the Amiga you might find that still works. Curiously, the Ariadne I uses an AMD clone of the same chip that's in the A2065 (the A2065 uses the original CMOS LANCE chip, if I remember correctly), but it runs so much faster. The original Amiga a2065.device is also known not to be the fastest design, although your test didn't use it.
The NE2000 PCMCIA NIC test suggests that the CPU and memory performance does have a significant impact on the NIC performance after all. I was skeptical about that, but the somewhat disappointing performance of an NE2000 PCMCIA card in the plain vanilla 68EC020 A1200 (480 KByte/s) speaks for itself, if you can get almost 910 KByte/s out of the same type of hardware.
-
Olsen
thanks for your response. I understand what you mean by burnt out. After my time with Genesi I couldnt even turn on my peg... glad you are back.
Thank you. I always thought that it would never happen to me that way, but you get burned more easily than you might think.
It's never a good idea to read up on ailments (because, as even Mark Twain noted, all the symptoms you read about always match your symptoms, regardless of what you're reading, even it's about the bubonic plague), but I was surprised that the description of burnout symptoms I eventually stumbled upon matched what I was going through. Understanding what kind of monkey's sitting on your back tends to be helpful for recovery.
Enjoy the amiga community its still alive!
The community was always the best thing about the Amiga...
-
At least the A2065 and driver works on my A1000 setup. I once tried
my Ariadne1 wanting to compare the two, but the system was then
stuck in a boot or reboot loop, I think it was right at powerup,
but it could have been after kickdisk load ofcourse.
Having used the A2065 mostly for Envoy, I am now looking forward
to (hopefully) try out a lean tcp/ip stack, crossing fingers ;)
omgas
-
And I've just crawled out of from whatever stone I was hiding under to see if there was still enough fun left in me and the Amiga community for another round of doing what I believe I do best...
I'm very happy that you are coming back again. I'm sure we all are.
-
I recently moved 3 TBytes in thirty seconds when I replaced the two drives in my NAS ;-)
How did you manage that ? Faster than any HD's i've ever heard of.
-
HD speeds are pretty nice now. I have an external E-Sata HD in my laptop and 100 MB copy goes so fast that Windows progress bar doesn't even pop up - quite a difference to my ex USB2 drive.
-
Yes, but they are not so fast as to move 3TB in 30 seconds. However I've reread and I think this is geek humour. he "moved" 3tb by moving the disks. hoho :)
-
How did you manage that ? Faster than any HD's i've ever heard of.
Easy: turn off NAS device, take two old drives out of the NAS device, remove old drives from their clips, put two new drives into the clips, put new drives into the NAS device. Easiest hardware upgrade I ever did. Note tongue in cheek in diagram A above ;-)
Seriously, if you want to move a lot of data quickly, pushing it down an Internet connection is not necessarily the way to go unless you have major bandwidth to spare. It can be much more cost efficient to just put it on a disk of sufficient size and move it physically yourself, or by hiring a courier service.
This is how, for example, some of the post production work was done in the "Lord of the Rings" films, in London. They put the data on an iPod and somebody carried it to where it was needed.
-
Make it happen but do please release separate cpu binary builds. Thanks!
-
If it was easier to use than Miami ie. offered some kind of functionality improvements I'd buy one... as it's always a struggle to find my current version of Miami or some other stack and get it working. Plus Holger has not developed Miami for ages... and seems to have stopped taking registrations as well.
So as long as the rego is reasonable... there seems no reason not to jump on it early rather than later.
Alternatively if the rego is a bit steep then I'd first evaluate it and then buy it.
:-)
-
I would purchase roadshow for 68k - ocs a500...
sorry but im not gunna read 11 pages here and on aw
but i will buy it. for 68000
-
Only just noticed this thread....count me in for definate...
-
Maybe the makers of Natami, FPGAArcade, Minimig improvements, etc, could license it for inclusion for a reasonable fee (per hardware device), and then these classic Amiga implementations would include a TCP/IP stack out of the box.
that would be the way to go ..if natami can play a decent tennis game ..an browse the net what would i want a pc for ?? ..all i do is log online browse a bit emails ..with apple podacts taking over the world windows surely looks like its time is coming to a end ..eventually ..
-
with apple podacts taking over the world windows surely looks like its time is coming to a end ..eventually ..
:crazy:
-
Yeah a bet Microsoft is quaking in its boots. :)
-
Any news on Roadshow? I'm about to get my A1200 networked so a decent TCP/IP stack would be very useful right now :)
-
Last message i sent to olaf was about a week or 2 ago, he mentioned he is tidying up stuff and fixing a few small bugs.He didnt reply with a eta though,but expect it will be soon to be released.
Mike
-
Any news on Roadshow? I'm about to get my A1200 networked so a decent TCP/IP stack would be very useful right now :)
Thank you for asking :)
I am still in the process of squashing one of the known bugs, namely the DHCP client code not working correctly with certain cable modems and whatnot. One thing led to another, and while the DHCP support now works where it previously did not, this uncovered related problems that did not show up because the DHCP client code previously did not work as intended. It's bug fixes and more bug fixes... Which I believe is a good thing. A number of necessary changes, and code reviews did not happen in the past couple of years. I am just catching up :)
My current plan is to look over the documentation during the weekend of September 18/19 and figure out what needs to be updated or added to. To be followed by putting a distribution disk together, and writing/testing an installer script.
The software is (basically) ready, has been for years, it's just that I never went the extra mile to mold it into something you could install ;)
-
yes l be into that l reg both maimi and miami dx back in the day
whould buy roadshow ive run it on classic ppc os 4.0 was nice
since have sold ppc blizzard and use 020 1200 and just getting my cnet bbs going
so whould be perfect for me
-
Olsen
Ok. Good news. Flawless DHCP is very important. Also a good installer. And last but not least as I said before take the time and do a gui for the stack. In amigaworld this is important. Just look up countless gui threads..the last thing anyone wants to do after spending $30=$40 on a tcp stack is manual configs
-
What wouldn't be more natural than a GUI made with gtlayout? :)
-
Olsen
Ok. Good news. Flawless DHCP is very important.
But surprisingly hard to implement. My original DHCP client code was written according to the relevant RFCs current in 2001/2002, and I tested it with the ISC reference implementation. Further tweaks were made as I upgraded my home network over the years, and following reports from the OS4 beta testers. This was not enough, though :(
Today's DHCP servers, as found in embedded systems, or as part of dedicated server hardware, are an odd bunch. Some expect you to carry information in the DHCP requests which according to the documentation is not even mandatory, and duplicates the information already provided in the basic BOOTP packet. Some refuse to respond to your DHCP requests unless these requests are at least 300 bytes in size. Some respond with more data than your client code stated it can handle.
These discoveries prompted a slew of changes...
Also a good installer. And last but not least as I said before take the time and do a gui for the stack. In amigaworld this is important. Just look up countless gui threads..
I hear you. The GUI issue is still unresolved. I am not going to put any work into writing one, as I have been there and it contributed to the excessive delay in getting the product published.
I did get an interesting offer in the last two weeks which may help to resolve the GUI issue. But in the mean time, I'd rather get Roadshow "finished" as far as is this may be possible, and prepare it for a GUI-less release. I really cannot tell how long it would take to make a proper GUI for Roadshow, if that would come to pass in the first place. So it's (for now) a decision of shipping Roadshow, or not to ship it at all.
the last thing anyone wants to do after spending $30=$40 on a tcp stack is manual configs
Some assembly will always be required. And the absensence of a GUI would have to affect the price. I don't expect Roadshow to sell in the $30+ range without a GUI.
-
What wouldn't be more natural than a GUI made with gtlayout? :)
I would have to spend time debugging gtlayout.library first :( As nice as gtlayout.library was for its time, building a Roadshow GUI from it would probably delay the creation of the GUI even further.
Whatever happens next, it probably won't be using gtlayout.library for development.
-
But surprisingly hard to implement. My original DHCP client code was written according to the relevant RFCs current in 2001/2002, and I tested it with the ISC reference implementation. Further tweaks were made as I upgraded my home network over the years, and following reports from the OS4 beta testers. This was not enough, though :(
Today's DHCP servers, as found in embedded systems, or as part of dedicated server hardware, are an odd bunch. Some expect you to carry information in the DHCP requests which according to the documentation is not even mandatory, and duplicates the information already provided in the basic BOOTP packet. Some refuse to respond to your DHCP requests unless these requests are at least 300 bytes in size. Some respond with more data than your client code stated it can handle.
These discoveries prompted a slew of changes...
This illustrates a small problem with the notion of "be liberal in what you accept, and conservative in what you send." I have seen many network services which completely ignore the second part and absolutely demand the first, irrespective of the consequences.
I hear you. The GUI issue is still unresolved. I am not going to put any work into writing one, as I have been there and it contributed to the excessive delay in getting the product published.
I did get an interesting offer in the last two weeks which may help to resolve the GUI issue. But in the mean time, I'd rather get Roadshow "finished" as far as is this may be possible, and prepare it for a GUI-less release. I really cannot tell how long it would take to make a proper GUI for Roadshow, if that would come to pass in the first place. So it's (for now) a decision of shipping Roadshow, or not to ship it at all.
SHIP SHIP! As for the GUI, I think leaving it without one gives the option of providing our own. Have an officially-supported one, but not make it mandatory, that way some of us MUI-Rexx hacks or C/C++ jockeys (or E, or whatever your flavor) can make simple ones for ourselves, or even complex ones. I am a "function over form" kind of person for the most part, so having a fast and workable TCP/IP stack is far more important to me than a pretty interface.
Some assembly will always be required. And the absensence of a GUI would have to affect the price. I don't expect Roadshow to sell in the $30+ range without a GUI.
What about a volume discount? ;) Seriously, I, for one, like the price notion.
-
I'll buy just as soon as it's available!
I assume the command line would be similar to ifconfig under linux? Lack of GUI doesn't bother me but I can appreciate others would prefer this.
Will basic network commands (ping, traceroute etc) come with this?
I'm new to networking on the amiga - I guess as long as we have a working interface and tcp/ip stack any other tools could be downloaded from Aminet? :)
*waiting with anticipation*
Steve
-
This illustrates a small problem with the notion of "be liberal in what you accept, and conservative in what you send." I have seen many network services which completely ignore the second part and absolutely demand the first, irrespective of the consequences.
I suspect that the design of the DHCP protocol contributed to the odd client and server behaviour. The purpose of DHCP is to allow a client to learn about the network it is part of, and to share network resources without interfering with other clients. To this end DHCP makes sure that the exchange of information between clients and servers is well-defined and produces results: either the client gets what it wants, or it can be certain that no requested information will be forthcoming.
That's the plan, but there is no mechanism in DHCP to specifically help uncovering implementation errors. You have packet exchanges which say something along the lines of "here is the choice I can offer you", "this is what I want", "here is what I can give you".
But there is no packet exchange which says "I did not understand what you asked for". In place of that missing packet there is only silence. And that silence is interpreted as the complete absence of a server, which may be wrong since the server may have chosen to reject the (subjectively) malformed packet.
I remember that during OS4 testing, there were reports from cable modem users who said that they were losing their DHCP-assigned IP addresses. It turned out that the IP address leases assigned by DHCP were relatively short, and the Roadshow DHCP client correctly sent out lease extension requests, and eventually address renewal requests. Only that the DHCP server paid no attention to either, which eventually led Roadshow to stop using its assigned IP address altogether (all according to spec).
It would have been helpful to know why the DHCP server chose not to respond to the DHCP client messages. I now believe that the DHCP server found something in the packets it did not like. But as the DHCP protocol has no mechanism for notifying the client of such glitches, there was no way to figure out what was going on.
SHIP SHIP! As for the GUI, I think leaving it without one gives the option of providing our own. Have an officially-supported one, but not make it mandatory, that way some of us MUI-Rexx hacks or C/C++ jockeys (or E, or whatever your flavor) can make simple ones for ourselves, or even complex ones. I am a "function over form" kind of person for the most part, so having a fast and workable TCP/IP stack is far more important to me than a pretty interface.
How the configuration files work, where they are stored, etc. is documented. Source code for all the shell tools is included, right down to the tcpdump/libpcap ports I cooked up. Anybody curious enough to start tinkering can do so with my blessings.
If you want to make a GUI, using the provided SDK material should allow you to do so.
What about a volume discount? ;) Seriously, I, for one, like the price notion.
Whoa! I haven't thought that far yet. Really, the imperative now is to get the thing ready to ship, and then ask the really difficult questions.
-
I'll buy just as soon as it's available!
I assume the command line would be similar to ifconfig under linux?
Um, no. I hope that they are better than that :)
Since the TCP/IP stack I built upon comes out of the BSD Unix heritage, the usual set of network setup/control/information commands to ship with it would include "ifconfig", "route", "arp", "netstat", "traceroute" and "ping". Of these I chose only to keep "arp", "traceroute" and "ping" and wrote Amiga-fied versions of the rest.
For example, to set up and configure interfaces and routing you would use the "AddNetInterface" and/or "ConfigureNetInterface" commands (they combine what "ifconfig" and "route" can do). To change the routing, you would use the "AddNetRoute" and "DeleteNetRoute" commands (these do what "route" could do). To obtain information about the state of the network you would use the "ShowNetStatus" and/or "GetNetStatus" commands (these do what "netstat" could do, and a bit more than that).
The point of making new commands was that, well, the originals were very terse and cryptic, and if they had been deliberately designed to make them harder to use, the designers couldn't have done a better job. I repeatedly ran afoul of the BSD "ifconfig" and "route" syntax, at which point I really had it, and I started to write Amiga-specific APIs for doing what these configuration tools would do (the "ifconfig" and "route" code itself is incredibly convoluted and crufty, too). Then I wrote new Amiga-specific commands to use these APIs.
I hope that these replacements provide better control, better error reporting and better platform-specific functionality than the original Unix commands would do. For example, you can use "GetNetStatus" (especially in script files) to test if specific aspects of the network are configured and operational; to the best of my knowledge there is no single Unix command which would provide you with this set of information.
I realize that ditching the "ifconfig", "route" and "netstat" commands may make it a bit more difficult to learn how Roadshow is set up and configured, assuming that you have prior knowledge of these Unix commands. But: to the best of my knowledge no two Unix/POSIX systems use the same syntax and switches, regarding these three commands. For example, the OpenBSD versions of "ifconfig" and "route" do not work like the Linux versions, or the Mac OS X versions, etc.
Bonus: the "traceroute" command has bugs fixed which have been around since 1987 and are still present in today's *BSD implementations of the command :)
Lack of GUI doesn't bother me but I can appreciate others would prefer this.
Will basic network commands (ping, traceroute etc) come with this?
Yes. "arp", "ping" and "traceroute" are included, as well as "tcpdump" and the BSD "ftp" client, and the tools that are part of Darren Reed's ip filter package. Source code for tcpdump/libpcap and the Amiga-fied shell commands is included (but not for the "ftp" client, etc. mentioned above; I didn't quite see the point since these tools are so simple).
I also ported "wget", which should become part of the shell command collection, but I'm not sure where I put the source code :(
-
But there is no packet exchange which says "I did not understand what you asked for". In place of that missing packet there is only silence. And that silence is interpreted as the complete absence of a server, which may be wrong since the server may have chosen to reject the (subjectively) malformed packet.
A cursory review of RFC 2131 would give me the notion that DHCPNAK should cover a situation of a bad client request, although the RFC only states a couple of scenarios in which the server would respond with a DHCPNAK. I suppose that could encourage continuous bad behavior from a bad client, however. I have never spent time delving into DHCP mechanics, and now I have yet more information that I am absolutely compelled to absorb... thanks :lol:
A problem I frequently saw in the past was that of identical IP schemes in use in multiple places. The problem was DNS. A laptop coming from home on 192.168.1.x would go to work and request the same IP address it was using at home. The office DHCP server would happily approve the request, provided the IP was not in use on the network. The client would then retain all of its network configurations including DNS, which may or may not work on the office network. Or vice-versa.
-
A cursory review of RFC 2131 would give me the notion that DHCPNAK should cover a situation of a bad client request, although the RFC only states a couple of scenarios in which the server would respond with a DHCPNAK.
The purpose of the NAK message is to tell the client/server that the contents of a request are unsuitable. But in order to get as far as knowing that a NAK message should be sent in response, you have to have processed the meaning of the original message first.
If your code reads that original message and considers it malformed, prompting it to ignore it altogether, processing will never reach the state where a specific NAK would be sent in response.
What DHCP is lacking is a mechanism to notify the client/server of the rejection of a message prior to analyzing its meaning.
I suppose that could encourage continuous bad behavior from a bad client, however. I have never spent time delving into DHCP mechanics, and now I have yet more information that I am absolutely compelled to absorb... thanks :lol:
There is a lot of bad news in how DHCP implementations actually behave, as compared to the deceptively simple RFC specification. Some of the quirks are really outlandish, such as the minimum packet size. With a lot of handwringing, that minimum packet size comes out of the original BOOTP specification (RFC 951). Why a server would have to reject such a packet purely based upon its size, rather than its contents, is (at least for me) puzzling.
A problem I frequently saw in the past was that of identical IP schemes in use in multiple places. The problem was DNS. A laptop coming from home on 192.168.1.x would go to work and request the same IP address it was using at home. The office DHCP server would happily approve the request, provided the IP was not in use on the network. The client would then retain all of its network configurations including DNS, which may or may not work on the office network. Or vice-versa.
Sounds like a poorly-configured DHCP server to me :)
For example, the ISC DHCP server reference implementation allows you to lock down unsuitable address ranges, preventing clients from appropriating them.
-
If your code reads that original message and considers it malformed, prompting it to ignore it altogether, processing will never reach the state where a specific NAK would be sent in response.
What DHCP is lacking is a mechanism to notify the client/server of the rejection of a message prior to analyzing its meaning.
And thus I propose the DHCPSAYWHAT packet.
Sounds like a poorly-configured DHCP server to me :)
For example, the ISC DHCP server reference implementation allows you to lock down unsuitable address ranges, preventing clients from appropriating them.
Well, it is a pretty common issue between the LinkSys, D-Link, and Microsoft 2003 DNS services, so there you go. But in this case it was not an issue of unsuitable address ranges, but identical ranges. 192.168.1.x at home AND at the office, so the machine would ask to use 192.168.1.100 and the DHCP server says yes, and the client keeps the same DNS settings because it does not see the need to change.
Now, it could be the client's fault and not the DNS server. But I never bothered to sniff traffic to make that determination. I may now just for shits and giggles.
-
"Wait, it was different old story, which went like this: bottom drops out of the Amiga market, harder than usual this time, companies you did consulting work for during the last 10 years go bust, an old friend and collaborator dies of a cardiac arrest, and you find out how hard it can be to overcome a burnout."
I remember Gateway coming to the Amigaorg show. I knew after that weekend the Amiga was going to die. It was way better before "someone" bought the license
-
You can put me on the list as a buyer even though I am quite happy with Miami.
I have the Miami Version 3.0 (bought at the Midwest Amiga Show) in an 060 Amiga 3000T with a C=2065 card and I use Roadrunner for my service.
Not sure I'll get it to work with no GUI but I'll try.
If there is a web browser that works on my system I would be very interested.
Bought and paid for Aweb, Ibroswe and Voyager, they all quit working on my system.
Still use my Amiga for upkeep of my website and email.
-
Hello!
I read about the "evolution" of this thread and Roadshow, but I missed (or wasn't stated) something about the limitations of the plain 68k version: it's written it's going to be, but there are no details about.
Could you tell us something Olaf?
I own many Amigas, but I like my A500 in particular (even if at the moment I have no ethernet option on it).
Thanks!
-
Hello!
I read about the "evolution" of this thread and Roadshow, but I missed (or wasn't stated) something about the limitations of the plain 68k version: it's written it's going to be, but there are no details about.
Could you tell us something Olaf?
Limitations? Hm... there are not going to be any functional limitations, compared to the version of Roadshow available as part of OS4.
Given the age of the code Roadshow is based upon, you won't see TCP/IP stack features which were added after 1994. This means that features such as path MTU discovery, T/TCP or IPv6 support will not be available. But they are not available in the OS4 version of Roadshow either.
I am determined not to put any DRM or anti-piracy measures into the 68k version, if this is what's mainly on your mind.
The current plan is that you will be able to legally use each copy of Roadshow on up to two computers at the same time, provided you paid for your copy. If you intend to use that copy on more than two computers at the same time, you will have to buy another copy. But (read the bit about DRM and anti-piracy measure above), I will not try to stop you from using your copy on more than two machines at the same time. It's your responsibility to comply with the usage requirements.
Due to how Roadshow works, it requires Kickstart 2.04 or higher. AmigaOS 1.x is thoroughly unsupported.
The devices, libraries and tools that come with Roadshow will all work on a plain 68000 machine. A special 68020-060 version of "bsdsocket.library", which implements the TCP/IP stack, will be included.
That's about as many "limitations" as I can think of right now.
I own many Amigas, but I like my A500 in particular (even if at the moment I have no ethernet option on it).
Thanks!
Not sure how the A500 will be supported, if it doesn't have a dedicated networking interface. You could probably rig something up with "plip.device", "slip.device", "liana.device" or "ppp-serial.device" and the necessary cabling, but it probably won't be quite so much fun ;)
-
Limitations? Hm... there are not going to be any functional limitations, compared to the version of Roadshow available as part of OS4.
That's good news: I've read something just in the first messages on this thread...
Given the age of the code Roadshow is based upon, you won't see TCP/IP stack features which were added after 1994. This means that features such as path MTU discovery, T/TCP or IPv6 support will not be available. But they are not available in the OS4 version of Roadshow either.
I just have the basics of networking, and I don't know how much MTU path discovery could help in communications, but it's ok; IPv6 would be nice just to be "ready for the future" (if this "future" will come :) ).
I am determined not to put any DRM or anti-piracy measures into the 68k version, if this is what's mainly on your mind.
The current plan is that you will be able to legally use each copy of Roadshow on up to two computers at the same time, provided you paid for your copy. If you intend to use that copy on more than two computers at the same time, you will have to buy another copy. But (read the bit about DRM and anti-piracy measure above), I will not try to stop you from using your copy on more than two machines at the same time. It's your responsibility to comply with the usage requirements.
Thanks for trusting in the community! :)
Due to how Roadshow works, it requires Kickstart 2.04 or higher. AmigaOS 1.x is thoroughly unsupported.
The devices, libraries and tools that come with Roadshow will all work on a plain 68000 machine. A special 68020-060 version of "bsdsocket.library", which implements the TCP/IP stack, will be included.
That's about as many "limitations" as I can think of right now.
My A500 is equipped with KS2.04 at the moment, so no problem, and doesn't matter to have it under 1.x.
Not sure how the A500 will be supported, if it doesn't have a dedicated networking interface. You could probably rig something up with "plip.device", "slip.device", "liana.device" or "ppp-serial.device" and the necessary cabling, but it probably won't be quite so much fun ;)
Yes, I know! :)
I'm thinking about setting up a net with a serial cable and proper device to another Amiga, and using this last one as gateway.
Hope that a rumored ethernet interface for A500 will come to light as well (otherwise I'll use on my A600 with a proper PCMCIA adapter).
Thanks for the precise info! ;)
-
@ ognix
Hope that a rumored ethernet interface for A500 will come to light as well
There's always the 68000 socket -> Clockport adapter -> Subway -> USB Ethernet dongle route :)
@ olsen
Does Roadshow include a dialer? Or is the OS4 dialer something different?
-
You know, I have absolutely *NO* use for this at all, but I'd drop down a 20$ for it's release to the public. A very noble gesture on your part. Thank you.
-
I don't know how much MTU path discovery could help in communications
Without support for path MTU discovery you can end up in a situation where for example you seemingly at random can download from certain sites but not from others, even though you can ping them and reach them from other machines. I had this problem years and years ago with AmiTCP (it must have been, since Miami, appearantly, does support path MTU discovery).
The real culprit here is that since Roadshow is closed, the features of Roadshow is at the whim of one single person, which renders it rather useless for me at least, as I already have Miami.
-
Without support for path MTU discovery you can end up in a situation where for example you seemingly at random can download from certain sites but not from others, even though you can ping them and reach them from other machines. I had this problem years and years ago with AmiTCP (it must have been, since Miami, appearantly, does support path MTU discovery).
That would only be a problem if a router could not fragment the packet (either because of the packet's don't fragment flag or other reasons) or the remote host couldn't accept the MTU used. The easiest way to fix that in all cases is to use an MTU of 576 bytes, the minimum that all hosts are required to accept. Performance may suffer, but that's how it goes.
If that doesn't work, you could write a packet filter that snoops for applicable ICMP responses, e.g. type 3, code 4 (fragmentation required), adjusts the MTU accordingly (probably using a path MTU discovery process to decide on the size), and drops the ICMP response. Assuming your MTU adjustment code is written properly, the IP stack would either retransmit the packet after not receiving an acknowledgement or not know even about the problem, depending on the transport protocol being used.
I know that's a lot of work, but it does solve the problem. :-P
The real culprit here is that since Roadshow is closed, the features of Roadshow is at the whim of one single person, which renders it rather useless for me at least, as I already have Miami.
That's kind of the same for all commercial software, including AmigaOS itself. Miami, on the other hand, is ... dead? ;-)
-
I know that's a lot of work, but it does solve the problem. :-P
Yes, one could implement something path MTU discovery-ish as a filter :p
That's kind of the same for all commercial software, including AmigaOS itself.
Yes, and many of us have been promoting the liberation of AmigaOS sources since 1994, but nah - we still have to resort to hack&patch to fix things, and anyone who _dare_ distributing prepatched binaries is officially to be treated as an outcast (yet everyone and their dogs happily share whatever on the zone over at EAB).
Miami, on the other hand, is ... dead? ;-)
And how long till Roadshow is dead? I don't see the big difference, really.
-
Yes, one could implement something path MTU discovery-ish as a filter.
;-) I'll give you this, though: a stack without path MTU discovery should probably automatically use an MTU of 576 (or a smaller MSS or whatever it needs to do given the architecture) when sending data to remote networks. It should be "safe" to assume the local MTU can be used, but as you experienced, that's not always the case.
And how long till Roadshow is dead? I don't see the big difference, really.
As long as Hyperion uses it as part of AmigaOS, I suspect it will be around. But let's not go down that path in this thread. :-P I've never heard or read a single bad thing about Olaf, so I don't have any reason not to trust that he won't continue to support the software as long as people are using it. (He still supports clib2, despite Hyperion moving to newlib as their default C library, and clib2 is free and open source.)
-
Yes, one could implement something path MTU discovery-ish as a filter :p
Yes, and many of us have been promoting the liberation of AmigaOS sources since 1994, but nah - we still have to resort to hack&patch to fix things, and anyone who _dare_ distributing prepatched binaries is officially to be treated as an outcast (yet everyone and their dogs happily share whatever on the zone over at EAB).
Light a candle instead of cursing the darkness...
And how long till Roadshow is dead? I don't see the big difference, really.
I intend to stick around for a while, been doing it for almost 23 years now.
Holger's not even posting to this forum. But I am ;)
-
Light a candle instead of cursing the darkness...
Best line of the whole thread so far.
I'm one of the lucky ones that managed my own licensed copy of MiamiDX well before the Holger system crash. It's done well for my limited classic needs. But I will definitely consider a copy of Roadshow also if it can support my Prometheus/Realtek card set up.
Plaz
-
Will this be released in time for xmas? :)
-
Will this be released in time for xmas? :)
Actually, I haven't thought that far ahead. It's just that the work I put into the documentation, the installer script, etc. finally came together this weekend.
As far as I'm concerned the result is ready to ship right now. I likely won't be selling Roadshow 68k by myself, and there's a standing offer from one publisher to take care of it for me, on short notice. There's another offer from a different publisher to integrate Roadshow 68k with a GUI and sell this integrated product, but I haven't heard back from him yet.
Likely I'll wait until next week before I make a decision on how things will move ahead. It's possible that Roadshow 68k will indeed be available for sale before Christmas this year :)
-
There's another offer from a different publisher to integrate Roadshow 68k with a GUI and sell this integrated product, but I haven't heard back from him yet.
Careful that no-one sells that GUI while including the Roadshow 68k in the transaction... No kidding, similar thing happened once already and the result was that the Workbench 3.9 release includes an unauthorized AmiTCP/IP.
-
Actually, I haven't thought that far ahead. It's just that the work I put into the documentation, the installer script, etc. finally came together this weekend.
As far as I'm concerned the result is ready to ship right now. I likely won't be selling Roadshow 68k by myself, and there's a standing offer from one publisher to take care of it for me, on short notice. There's another offer from a different publisher to integrate Roadshow 68k with a GUI and sell this integrated product, but I haven't heard back from him yet.
Likely I'll wait until next week before I make a decision on how things will move ahead. It's possible that Roadshow 68k will indeed be available for sale before Christmas this year :)
Nice!
And regarding the GUI side, maybe someone will come up with a third party option for free on Aminet! :D (since you documented how to control the stack well, right? It's all done by modifying some ASCII text files...)
One side note about future releases: do you plan to make them free for registered users?
Just little updates?
I know it sounds a bit ahead, but just to know your ideas...
BY! :)
-
Nice!
And regarding the GUI side, maybe someone will come up with a third party option for free on Aminet! :D (since you documented how to control the stack well, right? It's all done by modifying some ASCII text files...)
I hope I've got everything covered. The printable documentation runs to about 112 A4-sized pages, and it describes the file formats and commands in great detail. Plus, the SDK has the source code of the individual configuration commands, for reference and tinkering.
One side note about future releases: do you plan to make them free for registered users?
Just little updates?
I know it sounds a bit ahead, but just to know your ideas...
BY! :)
I strongly believe in free updates. But, just like with CygnusEd, I reserve the right to ship them as incremental patches. Which also makes for shorter distribution archives :)
-
To olsen:
Sounds good :) But I have some questions:
1) What are the advantages of Roadshow compared to MiamiDX (lack of Gui is not a concern)?
2) What kind of price do you have in mind (downloadable distribution)?
3) Will it be possible to pay by bank transfer?
If those questions can be answered in a positive way, then you've got a customer right here :)
-
As far as I'm concerned the result is ready to ship right now. I likely won't be selling Roadshow 68k by myself, and there's a standing offer from one publisher to take care of it for me, on short notice. There's another offer from a different publisher to integrate Roadshow 68k with a GUI and sell this integrated product, but I haven't heard back from him yet.
If GUI is a problem I could prepare a MUI/Reaction/Gadtool GUI in case you need it.
-
To olsen:
Sounds good :) But I have some questions:
1) What are the advantages of Roadshow compared to MiamiDX (lack of Gui is not a concern)?
You can rely upon me to be a poor salesman. Here are the disadvantages:
- TCP/IP stack code is older than what Miami uses (Miami = NetBSD; Roadshow = 4.4BSD-Lite2)
- No built-in GUI
- Configuration works through text files
- No IPv6 support
- No built-in SSL support
- No ARexx interface
Here are some of the advantages of Roadshow:
- Significantly higher performance than Miami; according to my tests Roadshow is the fastest Amiga TCP/IP stack
- Uses far less memory once it's running than Miami, which means that you can run Roadshow on an extreme low-end configuration (Amiga 600HD with 2 MBytes of memory) and still have enough free memory available to run client software
- Controlled entirely through shell commands, which makes the whole thing scriptable
- Implemented a a single shared library, not as a big monolithic application
- Requires no assignments or shell paths to be set up, installs to your boot partition and acts as if it were part of the operating system
- Has a built-in DNS cache
- DNS client supports international domain names (ISO Latin 1 only, though), and transparently translates between the Punycode encoding and the human-readable form
- Built-in support for ZeroConf interface address assignment
- Comes with SANA-II drivers for PPP (modem/ISDN dialup) and PPPoE (ADSL)
- Supports the standard AmiTCP V4 API, plus a boatload of extensions which, among other things, allow for monitoring and manipulating traffic
- Source code for all configuration commands included in the SDK
- Developed and maintained by somebody who still answers questions and is likely to provide for support and bug fixes in the future ;)
2) What kind of price do you have in mind (downloadable distribution)?
It's possible that this will be a downloadable archive which will have to be unpacked and copied to an installation medium. I don't know yet how it will come out, though, as I haven't signed with a publisher yet, and it's unlikely that I will publish the thing myself.
As for the price, I've asked around and the general consensus seems to be that you can't really charge more than 25€ per copy for this kind of software. Maybe add another 5€ for media costs and shipping. Maybe add some more if the package were to ship with a GUI.
So, I expect the end product price to be somewhere around 30€.
3) Will it be possible to pay by bank transfer?
If I sign with a publisher, this would be one option. I expect PayPal to be another option.
If those questions can be answered in a positive way, then you've got a customer right here :)
Well, some of the questions are still unanswered from my own perspective. I know where this project is going, but the definitive answers will still have to wait a bit...
-
To olsen:
Thank you for the great reply :) I suppose I'll just have to wait until everything is finalized, but that's not a big deal.
Anyway, this software sounds like it would be quite good, and I'm certainly looking forward to see it running. Keep up the good work.
-
I am willing to pay for the current product and new technology.
AROS uses wikkibooks to keep documentation : http://en.wikibooks.org/wiki/Aros
Google groups to work together :
https://groups.google.com/grphp?hl=en&tab=sg&pli=1
I came across an interesting site about someone implemented 802.11 (wireless b) using microcontrollers :
http://www.globalspec.com/reference/33070/203279/chapter-3-the-airdrop-a
Its a step by step hands on teaching type book and its quite interesting - it may help us :
http://www.ebooksdownloadfree.com/Cisco-Networking/Implementing-802-11-with-Microcontrollers-Wireless-Networki-BI7664.html
Also we should also look into SANA III, maybe google groups/docs can be used to create work for those interested in working together ?
-
Anything new about this?
-
Could you pay some attention to WHDload compaptibility?
-
Anything new about this?
Still waiting for one prospective publisher to respond. Should this fall through, I'll go with another one. The TCP/IP stack is still good to go, with a manual, installer script, SDK, everything.
-
Could you pay some attention to WHDload compaptibility?
Last time I checked, there was no sound approach to getting this worked out: you have to turn off the interrupt processing triggered by incoming packets, and the proper way to do that is to shut down the TCP/IP stack.
-
Still waiting for one prospective publisher to respond. Should this fall through, I'll go with another one. The TCP/IP stack is still good to go, with a manual, installer script, SDK, everything.
hah! get the lead out olaf! I want to get my hands on this before i'm too old and broken down to use a computer!..
All joking aside, i hope you find a way to release it soon.
mech
-
Forgive me, what exactly is "Roadshow 68k" ?
-
@darkage
It is another commercial Amiga tcp-ip stack, still unpublished, that has no gui, and claims to have a lower memory footprint for 68k Amigas, between other things.
-
@darkage
It is another commercial Amiga tcp-ip stack, still unpublished, that has no gui, and claims to have a lower memory footprint for 68k Amigas, between other things.
Whao! Okay.. I saw some references to TCP/IP stack just didnt find a rock solid explanation of it. Cooool!
-
Could you pay some attention to WHDload compaptibility?
Last time I checked, there was no sound approach to getting this worked out: you have to turn off the interrupt processing triggered by incoming packets, and the proper way to do that is to shut down the TCP/IP stack.
WHDload has support for a startup and exit script.
So you can disable the tcp stack before startup and enable when whdload exits.
See http://www.whdload.de/docs/en/opt.html#ExecuteStartup
A similar problem occurs with the Poseidon USB stack, see
http://www.amiga.org/forums/showpost.php?p=544518&postcount=5
-
Could you pay some attention to WHDload compaptibility?
Last time I checked, there was no sound approach to getting this worked out: you have to turn off the interrupt processing triggered by incoming packets, and the proper way to do that is to shut down the TCP/IP stack.
WHDload has support for a startup and exit script.
So you can disable the tcp stack before startup and enable when whdload exits.
See http://www.whdload.de/docs/en/opt.html#ExecuteStartup
A similar problem occurs with the Poseidon USB stack, see
http://www.amiga.org/forums/showpost.php?p=544518&postcount=5
-
hah! get the lead out olaf! I want to get my hands on this before i'm too old and broken down to use a computer!..
All joking aside, i hope you find a way to release it soon.
mech
Newsflash: right this very minute I'm working on getting the publishing deal off the ground, to be concluded soonish, with hopefully the final product to become available within February.
-
Would be nice if roadshow could automatically shutdown itself when WHDLoad is running. I like to have TCP/IP allways running and I allways forget to shutdown it before I start WHDLoad.
-
Would be nice if roadshow could automatically shutdown itself when WHDLoad is running. I like to have TCP/IP allways running and I allways forget to shutdown it before I start WHDLoad.
Now go reread the WHDLoad documentation (http://www.amiga.org/forums/showpost.php?p=608089&postcount=242) and change your global settings to handle this. I don't think that this is something Roadshow needs to handle by itself.
-
Would be nice if roadshow could automatically shutdown itself when WHDLoad is running. I like to have TCP/IP allways running and I allways forget to shutdown it before I start WHDLoad.
You just have to enter it once in the whdload prefs, then for every whdload game, it will stop/start the tcp stack. See my previous post for the details.
-
Bump
-
Bump
I hear you... This is taking longer than I had expected. The release software and the demo version were delivered to the publisher more than two weeks ago. I thought we'd have a web site by now, and the product would be available for order. But stuff happens, and the whole thing has been delayed again :(
-
I hear you... This is taking longer than I had expected. The release software and the demo version were delivered to the publisher more than two weeks ago. I thought we'd have a web site by now, and the product would be available for order. But stuff happens, and the whole thing has been delayed again :(
Why don't you just sell it yourself by paypal and email licence keys to people that buy it?
-
Why don't you just sell it yourself by paypal and email licence keys to people that buy it?
Two reasons. First, the product needs a web site and a public support forum. These things are not a luxury. For the kind of product Roadshow is, it's inevitable that questions will come up which need to be answered, and the answers ought to be available for everyone in one single place. I don't have a web site or a public support forum, and setting them up means paying for them. I'm not sure if selling Roadshow would even manage to pay for the cost of setting up a web server. Second, I signed a contract with a publisher who already has the infrastructure in place. I can't just walk away from that.
Yes, it has been a long journey since the Christmas holidays in the year 2000 when I started working on what became Roadshow. But will a few days more hurt? I hope not...
-
Two reasons. First, the product needs a web site and a public support forum. These things are not a luxury. For the kind of product Roadshow is, it's inevitable that questions will come up which need to be answered, and the answers ought to be available for everyone in one single place. I don't have a web site or a public support forum, and setting them up means paying for them. I'm not sure if selling Roadshow would even manage to pay for the cost of setting up a web server. Second, I signed a contract with a publisher who already has the infrastructure in place. I can't just walk away from that.
Yes, it has been a long journey since the Christmas holidays in the year 2000 when I started working on what became Roadshow. But will a few days more hurt? I hope not...
I see. Oh well, put me down for two copies once it's available. :)
-
I hear you... This is taking longer than I had expected. The release software and the demo version were delivered to the publisher more than two weeks ago. I thought we'd have a web site by now, and the product would be available for order. But stuff happens, and the whole thing has been delayed again :(
No stress, i can wait a while (i don't have enough cash to buy it right now anyway) :)
-
olsen
This was discussed months ago and it was ready months ago. What in the world could take so long? You are losing a lot of momentum.
-
EDIT: oops! didnt notice olaf had replied above.. :)
When i set out to get Olaf to try and release this, i could not of imagined it would take this long.Most of the time was from him wanting to optomise and do some bug fixing ,as well as making the docs a bit better. sadly the last bit has been distribution. i talked to him about a week ago and he has someone that is going to distribute it. I dont know why this is so hard or time consuming,but he has not told me why.he says its in the works tho. This is all the info have.
Mech
-
olsen
This was discussed months ago and it was ready months ago. What in the world could take so long? You are losing a lot of momentum.
Well, i can understand him, if people pay for it they'll automatically want support/help for it.
-
I'm happy it's going to be available, if it takes a little while longer that's OK with me. :)
-
olsen
This was discussed months ago and it was ready months ago. What in the world could take so long?
There's ready and there's 80% ready. Roadshow was 80% ready when the DHCP client bug fix was implemented and tested. The remaining tasks were 1) to find a publisher or publish Roadshow myself, 2) write installation instructions, a tutorial and a reference manual, 3) compile the distribution files and write an installation script, and 4) set up a web site and payment system and make the product available.
All but the last task have been taken care of. I'd like to think that I used to be a wee bit faster at writing manuals and installation scripts than I am today, but that's probably just delusion ;) But this stuff takes its time if you want to produce something that satisfies you.
For all the software I wrote by myself, I always attempted to make something that I would find useful. Hence the 112 page tutorial/reference manual, which has absolutely everything in it, and the installer script which not only installs the software, but can uninstall it again, too, and make backup copies of your configuration files.
Some may view this as gold plating, and there certainly is the danger here to go overboard and go from 80% ready to 90% ready, to 95%, to 97.5%, to 98.5%, to 99.7% and so forth in the Zeno school of product development. I hope that the end result will be more useful, and not just shinier as a consequence.
You are losing a lot of momentum.
Well, you'd have to thank mech for getting the ball rolling again, and far as I can tell the ball is still tumbling along. I'm going to see this through, even if it takes a bit longer. Part of the journey is getting there, but you might as well enjoy the journey itself, too :)
-
Hi there, any updates on this?
I'm eager to ditch the inferior TCP/IP stacks installed on my Amigas. :-)
-
We're just discussing this on IRC (I wasn't aware of it before but am now).. and I'm looking forward to see this too
-
Any news?
I'm waiting, money in hand.
-
Any news?
I'm waiting, money in hand.
Sadly i talked with Olaf and last time he was busy with other projects and i "think" the problem was distributing roadshow with the people who he was working with. This was about a month ago i talked with him.
sadly i expected we would see this long before now but things have moved at a snails pace.
I haven't had much luck lighting a fire under his butt :)
Mech
-
I had forgotten about this. I hope it's still in the works.
(says another paying customer...)
-
another argument against closed source on amiga. as soon as a developer of an essential element gets demotivated or limited by agreements the work must begin from the start. it is deadly in this tiny community. the only luck is we have got alternatives for about to everything.
-
another argument against closed source on amiga. as soon as a developer of an essential element gets demotivated or limited by agreements the work must begin from the start. it is deadly in this tiny community. the only luck is we have got alternatives for about to everything.
there has been lots of stuff about not wanting to release as open due to quality control, documentation etc. but actually, if it had just been dumped on sourceforge, its quite probable by now the community, would have cleaned it up, made some documentation and a website etc.
can only hope something is done with this before we are in retirement homes ;-)
-
Hopefully it's still on track and will be released soon, fingers crossed...
-
I'm pretty sure that eventually anything useful in Aros will become the defacto standard for most AOS-alike systems including AOS itself.
Network stack, RTG, USB, PCI access, everything, for exactly this reason. Companies die and software gets abandoned, but open source is forever.
-
Any news?
I'm waiting, money in hand.
Sorry this has been taking so long. I was still on a roll in March, got the distribution archive ready, got the demo version ready, got the SDK ready, but then something happened :(
I burnt out and I am still recovering.
-
Sadly i talked with Olaf and last time he was busy with other projects and i "think" the problem was distributing roadshow with the people who he was working with. This was about a month ago i talked with him.
Let's say there were some problems beyond my control, since resolved, and the only thing that keeps the product from getting released is that the web page, etc. text needs to be written. I have been trying to do that for quite a while now, but I am having big trouble summoning the energy.
All this will pass, as it always will, but until it does, I hope the project will not be forgotten. It's 99.76% ready to go.
-
there has been lots of stuff about not wanting to release as open due to quality control, documentation etc.
Done and done (most of it was already done in late 2010). The problem here is that I am currently very willing but very unable to get that last simple bit finished, namely writing the text that should go on the web site on which the product will be sold.
It happens, it happened before, it will happen again. It just sucks that after all the work that went into making Roadshow happen, it's the smallest thing that manages to stop it.
but actually, if it had just been dumped on sourceforge, its quite probable by now the community, would have cleaned it up, made some documentation and a website etc.
Well, my outlook on this is pessimistic. If it really were that easy, we'd have a lot more projects on sourceforge.net (or Google code, whatever) than is currently the case. Fact is, hardly anybody who went through the hassle of learning Amiga software development is still doing it, and the state of the platform being as it is, few people want to learn it.
-
Well, my outlook on this is pessimistic. If it really were that easy, we'd have a lot more projects on sourceforge.net (or Google code, whatever) than is currently the case. Fact is, hardly anybody who went through the hassle of learning Amiga software development is still doing it, and the state of the platform being as it is, few people want to learn it.
no, open source does not guarantee anything, but at least the code would not go lost, as in case you quit for whatever reason or your backups get missing. so many people are leaving here quietly, somtimes with their precious stuff, never to be seen again. but positive example to what may happen is pfs3, open sourced with piru working on it and already included in aros.
speaking of which aros is a perfect place to accomodate all that. people there have extremly different interests and views about amiga (f.e. toni willlen with his only-68k) yet they are working together. aros attemts to stay compatible to as much as possible amiga alternatives (1.x-3.x, mos, os4) and offers potential support to widest variety of platforms including custom ones. aros gathers skilled coders, what it lacks is audience, hopefully to get interested as soon as 68k port gets usable.
-
Well, my outlook on this is pessimistic. If it really were that easy, we'd have a lot more projects on sourceforge.net (or Google code, whatever) than is currently the case. Fact is, hardly anybody who went through the hassle of learning Amiga software development is still doing it, and the state of the platform being as it is, few people want to learn it.
Many open source amiga apps have become successful, been ported across multiple amiga platforms, and still get a little tlc even if not actively developed. however if you take the attitude there is no point, and don't do it, then of course, nothing will improve.
it's your project and your choice. but I think you are wrong regarding this. I actively work on multiple open source projects. it was the fact i could pick up and hack the code that got me started on them.
-
Sorry this has been taking so long. I was still on a roll in March, got the distribution archive ready, got the demo version ready, got the SDK ready, but then something happened :(
I burnt out and I am still recovering.
Thanks for the status update, I'll keep waiting.
Meanwhile, the inferior stack still moves packets, so I'm not in a hurry. Just thought I'd ask what's happening with this.
Enjoy the summer, maybe you'll have more interest towards this when autumn comes. :-)
-
Many open source amiga apps have become successful, been ported across multiple amiga platforms, and still get a little tlc even if not actively developed. however if you take the attitude there is no point, and don't do it, then of course, nothing will improve.
it's your project and your choice. but I think you are wrong regarding this. I actively work on multiple open source projects. it was the fact i could pick up and hack the code that got me started on them.
And many do not become successful, are completely abandoned, or relegated to commercial development.
There is an Apache module I need for my web server. While I have programming in my background, I do not have the time to tinker with the inner workings of Apache to learn how this module works or to recreate it. The author is uninterested in updating his patch, and only a handful of Linux distros have maintained this module. And those distros are useless to my Solaris installations.
There are a number of really good FOSS projects which simply become abandoned. In theory, the nice thing about FOSS is that the motivation for a project is not money, but rather the usability and necessity. Until the developer or developers no longer find it necessary for themselves. So, in some ways, I feel the flaw with FOSS is that projects are often necessarily selfish.
In any case, I, too, am very interested in a 68k Roadshow, and stand ready.
-
There is an Apache module I need for my web server. While I have programming in my background, I do not have the time to tinker with the inner workings of Apache to learn how this module works or to recreate it. The author is uninterested in updating his patch, and only a handful of Linux distros have maintained this module. And those distros are useless to my Solaris installations.
doesnt sound like you are arguing against my case. whether or not the code was open, the original author has lost interest. at least someone can still maintain it if they want. if it had been closed, then tough and the situation would be even worse. the fact you don't have the time is neither here nor there. you could if you really wanted to update the code, as could someone else. if it was something I needed, i would personally make the time to sort it, and I would feel that by being open it had benefited me as I was able to continue to use it.
what module btw ?
-
Agreed.. My wife was a Windows programmer (she's a business analyst now.. better? worse? tough call.. ;-) and I remember a problem she had with an app.
They "bought" a fully supported library for file transfers (sftp I think??). Great reviews and support.. And it was great, for about 3 years..
Then the company folded, no support. New standard at work and this library wouldn't work with the move (I think it was VB6 to VB .NET)...
Finding another solution was a hassle..
It happens tho. In both commercial and OSS..
desiv
p.s. I do remember her grumbling that if she had the code rather than just the library, she could have fixed it herself. ;-)
-
Many open source amiga apps have become successful, been ported across multiple amiga platforms, and still get a little tlc even if not actively developed. however if you take the attitude there is no point, and don't do it, then of course, nothing will improve.
I am not disputing that good can come of it, stress on "can". Amiga programming is hard, like any other programming task is. Only this platform has today even less material available than possibly any other that is more than 25 years old. Some men (and women) like a challenge, I suppose. But some don't.
As for Roadshow, let's say I'm not ready to part with a project that has been with me for more than 10 years, and for which I feel responsible. I don't want to walk away from it.
Ask me again in ten years time ;)
-
I am not disputing that good can come of it, stress on "can". Let's say I'm not ready to part with a project that has been with me for more than 10 years, and for which I feel responsible. I don't want to walk away from it.
Ask me again in ten years time ;)
You sound like you would be giving it away never to see it again. not quite the same thing, but anyway, i wish you luck with it.
I have a little open source perl module I maintain. it's gpl licensed, and on cpan, but it still feels like mine. I mean, I still maintain it myself. I do get useful patches (and bug reports) from users though which is handy. If i decided to stop developing it, then someone else can pick it up. win win surely? :)
-
Still waiting..... :/
-
Ask me again in ten years time ;)
Noone will have any use for it in ten years time, it's just marginally of any use today.
-
@Olaf
Come on, just finish the God damn thing, you know you want it too!
BTW, finances permiting I'll probably be another paying customer.
-
I'd be interested in buying it, even though I have the full Miami, and AmiTCP packages. There's always room for a new TCP/IP on this platform, as long as it will be well supported, as I wouldn't want an instant departure similar to the support that occurred when Holger Kruse abandoned Miami.
So, yeah, come on let's see it completed for the Classic 68k hardware, I'd pay for it.
My only reservation is that I feel any commercial package should come with an easy to use GUI, online help, and PDF manual - if there isn't a printed one, and a good installation script.
-
My money is still in my hand too.. You can do it, Olsen! :-)
-
I'd pay for this too!
-
I want it and will pay for it!
-
Right... what's an ADSL modem again? It's like complaining about how much it sucks at ISDN, really.
As a fellow norwegian you dont have to travel so far from the major cities before you might need to rediscover ADSL and maybe even ISDN...
Until recently the only option where I live was ISDN, and then a wimax solution came up. But pretty expensive for the 1.5MBit you get, so I would be happy to get the chance to get ADSL if it ever comes available.
Regarding the topic:
I thought there was quite a few TCP/IP solutions available in its time for the classic. Its a bit surprising to me if none are available today.
- AmiTCP/IP (some versions available, but no GUI and complicated)
- Genesis (standalone or part of the NetConnect bundle)
- Miami/MiamiDx
- TermiteTCP
- EasyNet
Easynet is still available in the webshop on amigakit, and at a resonable price at £8.95 for a CD version. Can also be baught bundled with a wireless interface card for A1200/A600.
Reading the product description for the bundle I notice that the CD also contains AmiTC3, so that makes me unsure whether Easynet is a full TCP solution, or if its just a clever GUI that works together with AmiTCP3. But for the end user I guess it doesnt matter, as long as the package is a complete solution that configures easily.
-
The majoprity of the UK uses ASDL. Whilst the bigger towns and cities have access to 100mbit cable through virign or firber a lot of rural uk does not, and ASDL is still the cheapest form of broadband if up to 20mb speeds are your bag.
I live 3 and hlaf miles from telephone exchange i get 2mb tops. Moving soon and its straight onto 100mb then
Though i have not seen ISDN is a very liong time in the uk, and dial-up nobody uses anymore
-
There are loads of stacks, roadshow for 68k is pointless and a waste of everones time
-
There are loads of stacks, roadshow for 68k is pointless and a waste of everones time
I disagree. I think that it's nice to have an alternative to buggy old stacks and would buy it for my classics.
-
I disagree. I think that it's nice to have an alternative to buggy old stacks and would buy it for my classics.
On top of that he might be able to use it on his MorphOS machine. It is always good to have alternatives, even if some MorphOS/AROS users/developers don't think so, and throw garbage against the additional software ported to the Amiga.
-
I'll certainly support this! Go ahead and release it as is and update it in the future.
-
I am not against things, and its got f all to do with being a MorphOS user. Given the limited number of devs and resources in AmigaLand these days, I just don't see the point in porting software that we don't really need, when there are things we do need still not done.
-
On top of that he might be able to use it on his MorphOS machine. It is always good to have alternatives, even if some MorphOS/AROS users/developers don't think so, and throw garbage against the additional software ported to the Amiga.
Aros/morphos users/developers should be angry with Hyperion for forbiding Olsen to release native versions for MorphOS/AROS.
It may be useful for old MorphOS 1.4.5 due to lack of tcp/ip stack but I don't think it's really needed at all on MorphOS 2.x since NetStack works great. Perhaps MosNet/aros tcp/ip stack is more interesting for MorphOS1.4.5 because it's native ppc.
For classic amigas it's still quite interesting.
-
I am not against things, and its got f all to do with being a MorphOS user. Given the limited number of devs and resources in AmigaLand these days, I just don't see the point in porting software that we don't really need, when there are things we do need still not done.
Everyone does what they want with their free time whatever you say or would like them to do !
-
Everyone does what they want with their free time whatever you say or would like them to do !
I dont give a flying **** to be honest. Its a dead platform, its getting deader by the year.
-
I dont give a flying **** to be honest. Its a dead platform, its getting deader by the year.
Not to those of us buying new 68K hardware such as the Minimig, FPGA Arcade and Natami :)
I still have my Miami registration key so I can use Miami on my Minimig anyway to link to a gateway PC acting as a serial to lan gateway if I need lan access to my mini Amiga clone.
-
I dont give a flying **** to be honest. Its a dead platform, its getting deader by the year.
Then why make your comment in the first place? Seems like waste of energy to besmirch a dead platform.
-
I am not against things, and its got f all to do with being a MorphOS user. Given the limited number of devs and resources in AmigaLand these days, I just don't see the point in porting software that we don't really need, when there are things we do need still not done.
1) Great way of saying someones efforts are bull :madashell:
2) Perhaps you should start doing the work that needs to be done instead of complaining that no one else is doing it :madashell:
-
There are loads of stacks, roadshow for 68k is pointless and a waste of everones time
Where can you get them or licenses to avoid time limits?
Roadshow is not yet a dead product. (ie, there's still someone around to work on it to fix bugs, add features, whatever) Holger is gone. Oregon Research is gone. Are the Genesis/AmiTCP guys still around?
Sorry, but I cannot agree with your opinion. Besides, how can it possibly waste anyone's time other than Olsen himself? And if he chooses to waste his time on it, why do you care?
-
Most Amiga users probably use WinUAE where they dont need TCP/IP stack anymore.
-
As a fellow norwegian you dont have to travel so far from the major cities before you might need to rediscover ADSL and maybe even ISDN...
But I will not have to deal with an ADSL modem directly connected to the computer, like there used to be. Instead there are "smart" ADSL and ISDN routers that you configure through a LAN port.
-
Roadshow is not yet a dead product. (ie, there's still someone around to work on it to fix bugs, add features, whatever) Holger is gone. Oregon Research is gone. Are the Genesis/AmiTCP guys still around?
The activity on the thread is casting doubt on whether there is someone around for roadshow either.
-
Most Amiga users probably use WinUAE where they dont need TCP/IP stack anymore.
Clearly emulation users don't need this. Amiga users on the other hand may find this interesting.
Can people stop slagging of this product please?
To olsen:
Don't let these complainers demotivate you. People like them are to be found everywhere, and what they say is not important at all :)
-
who has slagged it off? Surely some people were only questioning how much something like this is needed, not the product itself, and some don't see the need. I do, but I fear it may never see the light of day.
-
who has slagged it off? Surely some people were only questioning how much something like this is needed, not the product itself, and some don't see the need.
They're still just complaining about something that someone made. Also, Roadshow seems to be a good alternative to the current 680x0 stacks and plenty of people have shown interest. Apparently a product like this is still welcomed by people, and that they don't see it as useful doesn't matter. Their complaining can only serve to demotivate the developer, and that's not a good thing.
-
They're still just complaining about something that someone made.
The only complaint is that it isn't available already. I really do not grasp why Olsen isn't just putting it out as-is, sources and all, and to heck with Hyperion, it's just an old TCP stack for a long dead plattform for crying out loud. But do I really need Roadshow? No, I already have paid Miami and MiamiDx from 12-13 years ago already.
Their complaining can only serve to demotivate the developer, and that's not a good thing.
The developer seems pretty good at demotivating himself all on his own here, sadly. And I'm sure Hyperion isn't helping. Would be so much better to just let it go, and have some more motivated people pick it up and do the finishing touches and continued support. These ego-tripping perfectionists who insists on doing everything themselves, typically end up miserable, and the end products die.
-
OLSEN:
Put up a bounty for the complete sources. Presumably you still own the copyright. Sell the whole project to the community. I'm sure we could put up a good sum to make it worthwhile. Probably much more so than selling individual copies.
-
Put up a bounty for the complete sources
That's the only thing I'd be willing to pay for, as I mentioned in August last year, in comment 43 on this thread. :hammer:
-
I'm fairly new to Amiga (and brand new to this board), but I for one would also purchase this if it ever comes out. I just switched from MiamiDX to AmiTCP (thankfully someone found the mirror of the guide that shows you how to edit what needs to be edited). It's a huge perfomance boost for my 2000. I for one would love a non-gui new stack that could do dhcp, and any resource improvements. I read through most of the thread, and am kind of disappointed in the nay-sayers. I think anyone who has the skills to make something for old hardware is awesome. I mean, they are making Commodore PET storage devices now. I don't think anyone should depress anyone else for being creative, even if it only helps one person.
You can put me on the "will buy" list, you know, as long as it's not too expensive.
whdload was expensive to me since I'm poor, but I am all for supporting people who have the knowledge to support the hardware I love. Besides, shouldn't we let the market decide? If nobody buys it, then he has the answer, if a ton of people buy it, then even better. The price can also be adjusted!
More power to you Olaf!
-
I'm fairly new to Amiga (and brand new to this board), but I for one would also purchase this if it ever comes out. I just switched from MiamiDX to AmiTCP (thankfully someone found the mirror of the guide that shows you how to edit what needs to be edited). It's a huge perfomance boost for my 2000. I for one would love a non-gui new stack that could do dhcp, and any resource improvements. I read through most of the thread, and am kind of disappointed in the nay-sayers. I think anyone who has the skills to make something for old hardware is awesome. I mean, they are making Commodore PET storage devices now. I don't think anyone should depress anyone else for being creative, even if it only helps one person.
You can put me on the "will buy" list, you know, as long as it's not too expensive.
whdload was expensive to me since I'm poor, but I am all for supporting people who have the knowledge to support the hardware I love. Besides, shouldn't we let the market decide? If nobody buys it, then he has the answer, if a ton of people buy it, then even better. The price can also be adjusted!
More power to you Olaf!
Well said, and +1 Insightful. Welcome to Amiga.org.
-
I'm fairly new to Amiga (and brand new to this board), but I for one would also purchase this if it ever comes out. I just switched from MiamiDX to AmiTCP (thankfully someone found the mirror of the guide that shows you how to edit what needs to be edited). It's a huge perfomance boost for my 2000. I for one would love a non-gui new stack that could do dhcp, and any resource improvements. I read through most of the thread, and am kind of disappointed in the nay-sayers. I think anyone who has the skills to make something for old hardware is awesome. I mean, they are making Commodore PET storage devices now. I don't think anyone should depress anyone else for being creative, even if it only helps one person.
You can put me on the "will buy" list, you know, as long as it's not too expensive.
whdload was expensive to me since I'm poor, but I am all for supporting people who have the knowledge to support the hardware I love. Besides, shouldn't we let the market decide? If nobody buys it, then he has the answer, if a ton of people buy it, then even better. The price can also be adjusted!
More power to you Olaf!
More thumbs up with this positive thinking! :)
-
OLSEN:
Put up a bounty for the complete sources. Presumably you still own the copyright. Sell the whole project to the community. I'm sure we could put up a good sum to make it worthwhile. Probably much more so than selling individual copies.
+1
-
+1
-100
I don't think me should kill off commercial Amiga software development just because some people are to cheap to pay for anything.
Equally open sources it not bad or evil but software authorise need to be given the freedom to release their software in the way that works best for them.
If you are unwilling to pay the full going hourly rate for work, software, office work or any other type of work you have no right to expect anyone to give their work away, but they are always free to do charity work if they wish to do so.
Open sources in the Amiga market is the same. We can't afford to pay bounties at the going hourly rate for good software developers, but we don't want to discourage them from offering us software of any sort free or commercial.
-
Any news on this?
Also, I would love this to be able to establish a Network connection with my standard Windows7x64 installation and make the Amiga visible to the Network. The perfect Network solution for Amiga :)
-
Any news Olaf? Hope there's progress :)
-
forget it.
-
forget it.
why? what happened?
-
why? what happened?
exactly: nothing. so what do you expect to happen yet?
-
ok, so nothing has happened so I wouldn't expect anything to happen in the future as well. I can see your point , but my mentality differs. Thx anyway.
-
Let's not forget it.
-
new year bump.
-
Sorry :(
This isn't how I thought it would go. "Roadshow" 68k isn't dead, it's just that I got so heavily side-tracked in the past months that literally everything else I had in the pipeline got short shrift.
I still want to get Roadshow published properly, and the only obstacle right now is me and my spare time.
-
Thanks for letting us know.
Don't let your piece of software die before got born.
-
I still hope this sees the light of day sometime.
-
To olsen:
Any news yet?
-
i dont think there is much to expect from the project here. roadshow is told to be best amiga tcp stack, it would be cool to have it, but the burden to devolop and maintain amiga software has become too much for every single person, no matter how talented.
in this context i just might report that as side effect of having owb on aros 68k also its native arostcp stack has started working on my amiga set to corresponding genuine 68k device (in my case xsurf .device). it is slower than miamidx but its there and the sources are free. it will likely improve, and given that it does, someone might even port it back to 3.x if necessary. we cant let amiga its development and its software base die even if individuals cannot carry on or become demotivated, we must push open source.
-
* bumpsi daisy *
Update? Where can I throw my money? Is this getting anywhere? Olsen answers please :bump:
-
To olsen:
Any news yet?
yes. when all works how we think, you can read in some days a press-release from us :)
-
Oh, that would be a nice surprise, just in time for Christmas! :)
-
Oh, that would be a nice surprise, just in time for Christmas! :)
Yup, and just about time. Sorry for the delay, but the last two years in which I had been trying to get this show on the road have been a lot more arduous than I had expected.
So, without further ado, I'll go back to getting the missing pieces on the board. Not that there are many pieces to speak of, which are not exactly missing, but you get the general idea ;)
-
So the project's not been buried after all :), thanks for this knowledge!
-
So the project's not been buried after all :), thanks for this knowledge!
No, neither buried, nor dead, nor "resting", just terribly embarrassed :(
-
This isn't how I thought it would go. "Roadshow" 68k isn't dead, it's just that I got so heavily side-tracked in the past months that literally everything else I had in the pipeline got short shrift.
I still want to get Roadshow published properly, and the only obstacle right now is me and my spare time.
Is that all that happened?
*whew*
I thought you had gotten old or something. :razz: :lol:
-
Is that all that happened?
*whew*
I thought you had gotten old or something. :razz: :lol:
Well, we all do in the end...
Incidentally, the product page is up: http://www.apc-tcp.de/support/0042e.php
The demo version and the SDK are already available for download. The demo version is virtually identical to the commercial release version (which will be available in January 2013), except for a time limit on how long it allows you to stay online.
-
Great news Olsen! Can't wait for its proper release. Any idea what the price will be?
-
Awesome! Time to pull the classics out of storage.
-
Incidentally, the product page is up: http://www.apc-tcp.de/support/0042e.php
The demo version and the SDK are already available for download. The demo version is virtually identical to the commercial release version (which will be available in January 2013), except for a time limit on how long it allows you to stay online.
way to go, olsen! very pleased to see the best IP stack for amiga being made available for OS3 users!
-- eliyahu
-
Great news Olsen! Can't wait for its proper release. Any idea what the price will be?
Honestly, we haven't quite decided yet. Given the price range discussed in this very thread, my best guess is that the price will be in the 20-25€ range for the digital download (yes, I am aware of the irony of downloading a TCP/IP stack from the Internet), plus some extra money should you prefer a CD-R (with the installation software and the SDK on it) mailed to your home (no idea how that much would cost, though).
-
way to go, olsen! very pleased to see the best IP stack for amiga being made available for OS3 users!
-- eliyahu
Well... it's been an epic *thirteen* years since the initial work I did over Christmas 1999 until now. I just hope I didn't do something completely and utterly unredeemably stupid in the end which causes the software to fail or something like it.
-
How to read amiga guide documents with windows? I would like to read documentations first with my PC
-
How to read amiga guide documents with windows? I would like to read documentations first with my PC
The documentation also comes in PDF format. Just download the demo version, unpack it, then look into the "Roadshow/Documentation/Printable" drawer. There should be a file "Roadshow.pdf" inside.
This file covers just about everything, from installation to the all the configuration and command options. I managed to edit it down to some 105 pages after cleaning out some duplicate sections.
-
How to read amiga guide documents with windows? I would like to read documentations first with my PC
http://aminet.net/package/misc/emu/winguide
Although, as Olsen says, you don't need it.
-
http://aminet.net/package/misc/emu/winguide
Although, as Olsen says, you don't need it.
@Chris,
Not to steal your thunder, but try this instead. It's *VASTLY* superior to WinGuide. Second application from the top.
http://www.stone-oakvalley-studios.com/index_software.php
Cheers! :)
-
I downloaded and tested. It feels faster than Miami. I'm using SANA-II and a Mediator with 100 Mbps card. Very easy to set up. I will definitely pay for this!
-
@Chris,
Not to steal your thunder, but try this instead. It's *VASTLY* superior to WinGuide. Second application from the top.
http://www.stone-oakvalley-studios.com/index_software.php
Cheers! :)
Oooh, I hadn't seen that before. WinGuide is a bit crashy under Windows 7 (I just discovered after comparing the two), however agwviewer is not supporting or filtering @{lindent} and chucking HTML codes visibily in one of the pages I just tried it out on.
I agree that it's better though, especially under Windows 7.
-
Honestly, we haven't quite decided yet. Given the price range discussed in this very thread, my best guess is that the price will be in the 20-25€ range for the digital download (yes, I am aware of the irony of downloading a TCP/IP stack from the Internet), plus some extra money should you prefer a CD-R (with the installation software and the SDK on it) mailed to your home (no idea how that much would cost, though).
I'd say that 20-25e would be ok for physical copy, but if download version would be considerably lower (10-15e), then it would sell a lot more. It would be easier to toss the money for occasional hobbyists which the most of the users seem to be nowadays.
With that 20e for download copy I'll stick with the old stacks. With 10e I'd buy this new for sure, even when I could do with the old stacks.
I downloaded and tested. It feels faster than Miami. I'm using SANA-II and a Mediator with 100 Mbps card.
Yeah, it doesn't need much to be faster than Miami ;) I think it's about the same speeds with AmiTCP.
-
I downloaded and tested. It feels faster than Miami. I'm using SANA-II and a Mediator with 100 Mbps card. Very easy to set up. I will definitely pay for this!
You can tweak the device configuration file, increasing the number of read/write requests as necessary. When I performed my initial testing back in 2001, I found that the default settings were too conservative. Once I turned them up to 32 (used to be 10), performance went through the roof.
I'm curious about the setup process. The installation script should put everything on the boot volume, but you still need to edit the networking device configuration. I know how to do that, but is there something you think could be done better? It's not exactly user-friendly :-/
-
I'm curious about the setup process. The installation script should put everything on the boot volume, but you still need to edit the networking device configuration. I know how to do that, but is there something you think could be done better? It's not exactly user-friendly :-/
Yes, that will cause complains by less experienced users for sure. Maybe installation script should ask basic network settings and apply it to configuration file in devs:. Doesn't need much, just little playing with scripts. And then you could reconfigure it by running installation script again. Pretty old fashioned, but would be better than nothing if you're not up to write full prefs program.
And btw. could you add preconfigured interface file for 3com driver (http://aminet.net/package/driver/net/3c589) too? And Hydra & X-surf too...
-
And btw. could you add preconfigured interface file for 3com driver (http://aminet.net/package/driver/net/3c589) too? And Hydra & X-surf too...
It should include preconfigured interface files for cnet.device/g-rex/prometheus/xsurf/... otherwise users will complain.
-
It should include preconfigured interface files for cnet.device/g-rex/prometheus/xsurf/... otherwise users will complain.
It has for cnet...
-
Yes, that will cause complains by less experienced users for sure. Maybe installation script should ask basic network settings and apply it to configuration file in devs:. Doesn't need much, just little playing with scripts. And then you could reconfigure it by running installation script again. Pretty old fashioned, but would be better than nothing if you're not up to write full prefs program.
Picking the right configuration is hard. If you assume that DHCP ought to work, it would make the basic setup easier. But, trouble is, if DHCP does not work, then the boot process will stall until the failed negotiation times out. I don't have a good solution for this yet (yes, the OS4 version of Roadshow has exactly the same problem).
Specific configuration options which suit your local network are more often than not tough to get exactly right. I remember that when I used AmiTCP for the first time, back in 1994, I didn't understand exactly how IP-Adress, subnet mask and default gateway would play together. If I remember correctly, DNS servers were configured separately. Any small mistake would render the whole configuration useless, and not being an expert greatly increased the likelihood of making that small mistake :(
And btw. could you add preconfigured interface file for 3com driver (http://aminet.net/package/driver/net/3c589) too? And Hydra & X-surf too...
I'd be happy to. The current set of files represents only the hardware which I had access to and could test by myself. If you could point me to working configurations (e.g. what goes into the "device=" line of the respective Storage/NetInterfaces config file), I'll update the demo version and the release version archives.
-
I'd be happy to. The current set of files represents only the hardware which I had access to and could test by myself. If you could point me to working configurations (e.g. what goes into the "device=" line of the respective Storage/NetInterfaces config file), I'll update the demo version and the release version archives.
These to devices:
3c589.device (3Com Etherlink III PCMCIA cards)
hydra.device (Hydra Systems' Amiganet cards)
norway.device (Norway ethernet add-on for Highway USB controller)
x-surf.device (Individual Computers' X-Surf cards)
I haven't tested them with Roadshow, but they do work without any tricks with old amitcp at least. I may be able to test at least some of them later, if needed.
-
Does it work with poseidon usb-ethernet adapters? IIRC there was some problem on OS4 using Roadshow+Poseidon because it was mandatory to use a file based device (and in contrast Poseidon created the network device in memory so choosing it was not possible)
-
So, without further ado, I'll go back to getting the missing pieces on the board. Not that there are many pieces to speak of, which are not exactly missing, but you get the general idea ;)
Wonderful! Hope no last minute blockers get in your way. :-)
-
You can tweak the device configuration file, increasing the number of read/write requests as necessary. When I performed my initial testing back in 2001, I found that the default settings were too conservative. Once I turned them up to 32 (used to be 10), performance went through the roof.
I'm curious about the setup process. The installation script should put everything on the boot volume, but you still need to edit the networking device configuration. I know how to do that, but is there something you think could be done better? It's not exactly user-friendly :-/
I'll give that a try! I never ran the installer, just extracted the files to a temp place and made some assigns, copied and checked the config file and then ran the startup command.
I think I prefer the stack not to have a gui, maybe a prefs editior for those less experienced.
-
Does it work with poseidon usb-ethernet adapters? IIRC there was some problem on OS4 using Roadshow+Poseidon because it was mandatory to use a file based device (and in contrast Poseidon created the network device in memory so choosing it was not possible)
Whatever it is, it is AOS4 introduced horror (which can be worked around by creating a dummy zero byte file of same name as the memory-created device in DEVS:Networks). As the Roadshow config is text based, it is easy to configure it for USB based devices. I successfully have tried the Roadshow demo since 2003 (for use with Norway, later for the USB adapters).
Roadshow is the most performant TCP/IP stack I've seen. With the Deneb and ASIX USB adapter I reached transfer rates of over 1200 KB/sec, if I remember it correctly (measured with TCPSpeed).
Congrats to Olsen for finally releasing it.
-
Don't forget prism.device
-
WOOT! I've definitely been looking forward to this, thank you! :pint:
FWIW, I'm no expert, and it took about 10 minutes to have IBrowse up and running with my A4066 (just a slight edit of the Ariadne interface). Lack of a GUI is really not a problem at all.
I'll try tweaking the config over the next few days, then run some tcpspeed tests against Miami. So far it works well - noticed my MP3 streams don't hang during the initial buffering process, as they often do with the other 2 stacks.
-
It should include preconfigured interface files for cnet.device/g-rex/prometheus/xsurf/... otherwise users will complain.
And one for whatever Mediator+PCI Ethernet card uses.
(Maybe it already comes with one, I did not look)
-
Where are the timing tests?
You know I can't live without my timing tests :)
-
Surely it would be feasible and indeed trivial to port the OS4 Roadshow GUI to OS3, as they are both ReAction-based...is there some compelling reason this isn't possible?
-
Yeah. If Hyperion support the Amiga, they should have no reason to let that GUI be ported to 3.x.
-
These to devices:
3c589.device (3Com Etherlink III PCMCIA cards)
hydra.device (Hydra Systems' Amiganet cards)
norway.device (Norway ethernet add-on for Highway USB controller)
x-surf.device (Individual Computers' X-Surf cards)
I haven't tested them with Roadshow, but they do work without any tricks with old amitcp at least. I may be able to test at least some of them later, if needed.
Thank you, I have just added new ready-made configuration files for these devices, and these changes will hopefully soon appear in the demo version, and eventually the commercial release in January next year.
-
Does it work with poseidon usb-ethernet adapters? IIRC there was some problem on OS4 using Roadshow+Poseidon because it was mandatory to use a file based device (and in contrast Poseidon created the network device in memory so choosing it was not possible)
Which name does the Poseidon SANA-II driver have?
Since Roadshow on 68k does not have a GUI to select the driver with, adding the driver's name to the configuration file by means of a text editor should help to avoid that SNAFU :)
If you can tell me the name of the driver, I'll add another ready-made configuration file for it right now.
-
I'll give that a try! I never ran the installer, just extracted the files to a temp place and made some assigns, copied and checked the config file and then ran the startup command.
I think I prefer the stack not to have a gui, maybe a prefs editior for those less experienced.
That's what I was (and still am) uncertain about.
The current configuration process works something like this:
1) You run the installer, which copies everything to the boot volume
2) You restart your system, so the S:Network-Startup will get invoked
3) You pick one of the network interface configuration files in SYS:Storage/NetInterfaces which matches the hardware you have installed
4) If that works out, you move that configuration file into DEVS:NetInterfaces
5) The next time you reboot your system, the network should come up automatically, configured using DHCP
If you don't know much about how TCP/IP networking actually does work out, and what the configuration options do, then this approach should still work. You do not need expert knowledge to get going. It would be easier, however, if Roadshow could suggest the network interface driver you ought to use, if you don't know it already (which brings further complications: what if you have two Ariadne cards installed? then you'd need to make copies of the Ariadne config files and change the unit number in one of them).
Assuming that there was a GUI for Roadshow, how would the setup process look like? My guess is that it would not be more complicated, and probably not much simpler either.
If you were to venture beyond the simple setup process, I'd say you would have to have sufficient experience to set up your network, picking the right IPv4 address, the right default route, the right DNS server. If you know how to do that, you won't be deterred by having to use a text editor to make these changes to the Roadshow configuration files, and maybe open the shell and use the Roadshow shell commands that may be required.
Chances are that you set up your network once and rarely if ever make changes to the configuration.
And the same would be true if there was a GUI. A GUI which would likely be used once only, and which would take quite some effort to get it right. I have tried to get this off the ground four times, and it always came to nothing. Part of me wants to see this as the Universe giving me a hint that I ought to have smartened up after the second attempt.
-
Don't forget prism.device
Is that prism.device or prism2.device? I already have a ready-made configuration file for prism2.device in the demo version.
-
Surely it would be feasible and indeed trivial to port the OS4 Roadshow GUI to OS3, as they are both ReAction-based...is there some compelling reason this isn't possible?
Honestly, I didn't ask if I might borrow or adapt the OS4 GUI. I would have had to pay for it like everybody else, since I do not own it.
As for "surely if would be feasible", I've had to learn my lesson and eat humble pie. If there ever was something I thought would certainly be doable and not too challenging, it was writing a GUI for Roadshow.
You just cannot take this for granted. I tried four times, I failed four times over the course of 8+ years. And these repeated failures took their toll on the whole project.
-
Yeah. If Hyperion support the Amiga, they should have no reason to let that GUI be ported to 3.x.
Is that so? Well, I didn't ask. And I'm not so sure if the GUI is that badly necessary any more, the longer I think about it, and the more I reactions to the current state of things I'm reading.
-
Which name does the Poseidon SANA-II driver have?
Since Roadshow on 68k does not have a GUI to select the driver with, adding the driver's name to the configuration file by means of a text editor should help to avoid that SNAFU :)
If you can tell me the name of the driver, I'll add another ready-made configuration file for it right now.
It seems that typing even though it doesn't exist physically should do the trick, so it should be:
"Devs:Network/dm9601eth.device" for Davicom (or should it be usbdm9601eth.device?)
"Devs:Network/usbasixeth.device" for Asix
"Devs:Network/usbpegasus.device" for Pegasus
"Devs:Network/usbmoschipeth.device" for MosChip MCS7830
I have a pair of asix adapters but I won't have access to my Deneb until weekend.
I can't remember if there are more drivers.
I could help with a Reaction/ClassAct GUI and give all the rights to Olaf Barthel although I don't think I have a lot of time to do it until christmas.
-
Thank you, I have just added new ready-made configuration files for these devices, and these changes will hopefully soon appear in the demo version, and eventually the commercial release in January next year.
And one more thing... you have Mediator configuration file, which has FastEthernet.device. Mediator software has actually two different network devices. FastEthernet.device is for RTL8139 compatible 10/100Mbps cards, while MediatorNET.device is used for RTL8029 compatible 10Mbps cards. So, you should make two different config files for Mediator use.
-
It seems that typing even though it doesn't exist physically should do the trick, so it should be:
"Devs:Network/dm9601eth.device" for Davicom (or should it be usbdm9601eth.device?)
"Devs:Network/usbasixeth.device" for Asix
"Devs:Network/usbpegasus.device" for Pegasus
"Devs:Network/usbmoschipeth.device" for MosChip MCS7830
Thank you, I have added configuration files for the lot (and it's "usbdm9601eth.device", as far as Google tells me).
I have a pair of asix adapters but I won't have access to my Deneb until weekend.
I can't remember if there are more drivers.
I could help with a Reaction/ClassAct GUI and give all the rights to Olaf Barthel although I don't think I have a lot of time to do it until christmas.
Thank you, but this could quickly turn into an overwhelming task. Just a word of caution...
-
And one more thing... you have Mediator configuration file, which has FastEthernet.device. Mediator software has actually two different network devices. FastEthernet.device is for RTL8139 compatible 10/100Mbps cards, while MediatorNET.device is used for RTL8029 compatible 10Mbps cards. So, you should make two different config files for Mediator use.
Thank you, I didn't know that. There are now two different Mediator interface files instead of one: one MediatorFast (formerly known as "Mediator", for "FastEthernet.device") and MediatorNET (MediatorNET.device).
-
Yeah!!!
Have just install it with my X-Surf.device
And it works great ;-)
Can't wait to get a copy.
Keep up the great work.
-
If there ever was something I thought would certainly be doable and not too challenging, it was writing a GUI for Roadshow.
You just cannot take this for granted. I tried four times, I failed four times over the course of 8+ years.
so whats so difficult about it if it is so easy? i really dont get it..
jason mcmullan when he introduced prnter support for aros wrote quickly a gui for it, without any experience with mui/zune before. arostcp has a working prefs gui, i can set xsurf device on my a4k and it works.. so why an oldskool amiga developer cant write a simple prefs gui? maybe the problem is delegating it to others who actually dont get it done. maybe doing it self is the fastest and most secure of choices. i for my part would expect a tcp stack for twenty bucks to come with a gui even if basic one. im not bashing here, its just my opinion.
-
Some of us coderz get writer's block when asked to code a GUI. It happens to me a lot. My brain wave patterns have to be in the right shape to do it.
Anyway, someone else who is good at GUI writing can whip one out anytime they like.
-
The GUI comment was in no way meant as "must have". It was just my comment on the thing nothing more. GUI isn't a necessity here since there's gonna be so many default configs included.
-
so whats so difficult about it if it is so easy? i really dont get it..
I did not claim it was easy, just that it was doable, and in my opinion not too challenging (I know a thing or two about user interface design, and implemented a good number by myself).
jason mcmullan when he introduced prnter support for aros wrote quickly a gui for it, without any experience with mui/zune before. arostcp has a working prefs gui, i can set xsurf device on my a4k and it works.. so why an oldskool amiga developer cant write a simple prefs gui?
First thing, it is not a simple GUI.
The TCP/IP stack uses a number of flat file databases, so to speak, e.g. for services, servers, name resolution, routes, hosts and a bit more. The GUI would have to provide for a "database management" front-end for all of these. In total, I think it comes down to writing 10 editors, one for each flat file database.
On top of that you also need to manage the network interfaces. Configuring these is the most complex task that needs to be done, on account of having to pick the right driver, and the proper settings. Roadshow stores network interface configuration files in two separate drawers (one set is activated at system startup time, the other can be activated manually). So that complicates matters further. Add to that the number of network interface options that may be required and you have got quite the package.
If you have all that, then you already have your basic network prefs GUI. But that's not enough, because it still requires special knowledge to set up the network. This is why you also need a simplified setup tool (often called a "wizard", which is the term Microsoft used for this tool). That tool has to be designed to be smart enough to make decisions on what should constitute a robust default setup, while still giving the user enough flexibility to make his own choices (within reason). That tool also has to validate the choices made by the user so that they make sense.
Let's say you have all of this, then you still need to add functionality which performs consistency checks on the data the user entered, both in the prefs editor and the wizard, to avoid common mistakes. For example, you should make sure that you have a default gateway, at least one DNS server, and one interface set up. Either that, or the interface at least ought to be using DHCP. If not, you ought to verify that the network interface's IPv4 address is in the same subnet as the default gateway, or things will get ugly. Some may call this gold-plating, but I call it necessary.
Still with me? Back in 2006 you still needed PPP or PPPoE support in the network drivers for the TCP/IP stack, for modem/ADSL dial-up networking. In addition to the prefs editor and the wizard, Roadshow needed another set of setup tools just for the PPP/PPPoE feature (or integrate it into the regular prefs editor/wizard). So this kind of tool also needed to be written. I doubt it's still necessary today, now that everybody has a gateway router at home to which you can hook up your Amiga via Ethernet.
I don't know how AROS solved the same problems I had to take care of. Writing a decent GUI for the networking infrastructure of an operating system is really hard, as anyone could attest who's seen what even Microsoft and Apple offer (Ubuntu, etc. also have a hard time). It's a lot of work, even if the results have plenty of rough edges. Much of what the network configuration constitutes does not make great sense on first sight, and unlike with other prefs editors, there is no common thread which lends itself to building a GUI that tells something of a story and shows the user cause, effect and consequences of the dials & switches he can play with.
maybe the problem is delegating it to others who actually dont get it done.
A general's only as good as his lieutenants and troops allow him to be...
maybe doing it self is the fastest and most secure of choices. i for my part would expect a tcp stack for twenty bucks to come with a gui even if basic one. im not bashing here, its just my opinion.
I share that opinion, but I just didn't have the time to do it myself, otherwise I would have done so. I already spent plenty of time figuring out how the GUI should work, and how the configuration files should look like so that the GUI could use them more easily. The overall design of Roadshow was strongly influenced by the needs of the GUI that never materialized.
Back in 2003 I was rewriting the Amiga FFS from scratch for OS4, I was heavily involved in OS4 development, I had my own company to take care of, and I was working on my CS degree. There was a lot on my plate, and something had to give. In the end, more gave than I expected it to, and I'm still dealing with the after-effects.
I suffered for my art, now it's your turn ;)
-
so whats so difficult about it if it is so easy? i really dont get it..
jason mcmullan when he introduced prnter support for aros wrote quickly a gui for it, without any experience with mui/zune before. arostcp has a working prefs gui, i can set xsurf device on my a4k and it works.. so why an oldskool amiga developer cant write a simple prefs gui? maybe the problem is delegating it to others who actually dont get it done. maybe doing it self is the fastest and most secure of choices. i for my part would expect a tcp stack for twenty bucks to come with a gui even if basic one. im not bashing here, its just my opinion.
Absolute worst case scenario, you have to edit a text file and change a couple variables. Should be a cakewalk for anyone still tinkering with 68k Amigas.
20 bucks (if that is indeed the final cost) yields 1789 kB/s here to my A4000 with a DENEB and USB stick, you certainly won't get that kind of performance with Miami or AmiTCP.
-
Absolute worst case scenario, you have to edit a text file and change a couple variables. Should be a cakewalk for anyone still tinkering with 68k Amigas.
20 bucks (if that is indeed the final cost) yields 1789 kB/s here to my A4000 with a DENEB and USB stick, you certainly won't get that kind of performance with Miami or AmiTCP.
setting up tcp stack may be a major trouble for some including me, unregarded system, gui or no gui. i tend to think that editinf text files isnt the easiest way.
-
I don't know how AROS solved the same problems
sources are open. i dont say its the perfect solution, but it has worked for me out of the box, perhaps because i use router, and do not need in depth settings;)
-
Hello Rolf
I gave the Demo Version a go today,i use a mediator 4000di, did what you informed us Setting it up Mediator file.in Network Interfaces etc. and wow worked straight away. quickly tested it, due to the 15min Demo
restriction.
Copied a file from my home Server using first Miami and then Roadshow and can confirm ist about 100cps/sec quicker showing 270 cps/sec thats fast.
Manythanks for your effort all i have to do know is wait for january2013 so i can buy it.
Regards Laurence.
-
I suffered for my art, now it's your turn ;)
I feel ya. :drink:
There are plenty of times I have to deal with my own customers telling me how "all that has to be done is x." *sigh* None the less, with MUI and MUIRexx, just about anyone here who knows all that needs to be done could throw together a simple GUI.
Anyone want to be the hero? Just sayin'. ;)
-
Honestly, we haven't quite decided yet. Given the price range discussed in this very thread, my best guess is that the price will be in the 20-25€ range for the digital download (yes, I am aware of the irony of downloading a TCP/IP stack from the Internet), plus some extra money should you prefer a CD-R (with the installation software and the SDK on it) mailed to your home (no idea how that much would cost, though).
I find 20-25 euros, digital download and covering two running systems, I find that very reasonable. I had no problems editing just 3 txt files for getting online with a static lan setup. Anyone seriously complaining about having to use a txt editor, he/she is just plain lazy. Looking forward to buy the commercial time-unrestricted release. Best regards to you and late Felix, omgas.
-
Yeah!!!
Have just install it with my X-Surf.device
And it works great ;-)
Can't wait to get a copy.
Keep up the great work.
Just in case: I just added a couple more ready-made network interface configurations to the demo version (3c589, AmigaNet, MediatorFast, MediatorNET, Norway, Poseidon-Asix, Poseidon-Davicom, Poseidon-MosChip, Poseidon-Pegasus and X-Surf). The new demo version (should be available for download right now) also includes an updated documentation, which corrects typos and one error.
The old demo version's installer script had a bug (now corrected) which may require manual fixes if you already have the old demo version installed. The demo version adds a few lines to the S:User-Startup file. One of these lines has a letter missing, which makes all the difference regarding whether or not the network will be activated after a reboot.
That line reads "IF EXIST S:Network-Startup" and should read "IF EXISTS S:Network-Startup" (note the letter 'S' added to 'EXIST').
-
Hello all,
For a few weeks i have been talking with Olaf Barthel about releasing roadshow 68K for the amiga. He seems all for the idea for the most part but would like it if he could sell it for a reasonable price and if anyone would buy it. It would be the only current tcp/ip stack that can be registered/bought etc! His stack is quite a bit faster than both miami and amitcp as it stands,and he said it would be possible to use on 68000 (ala A600 with limited resources).Olaf expressed concern that there were no docs or mui front end currently,but i assured him someone would probabaly step up to make a gui.I think most amigans can get by with limited install docs and such.
If you want to see this happen,please reply to this thread expressing your interest so i have something to show him!
Obviously if people pirate it right off the bat and spread it and he gets no sales,he will be quite disgusted,so lets show some support by buying it,pay for the thing if it happens ok!
I suggested to him he offer it via a web download you can pay with paypal and maybe on CD for those who are want something they can touch :)
So come on everyone,lets get behind this,its not everyday the amiga might see a new,faster tcp/ip stack!
Mike
Hooray! looks like roadshow finally has come to life.
For those of you that didnt see it in the announcements:
http://roadshow.apc-tcp.de/
-
Hooray! looks like roadshow finally has come to life.
Yay! Purchased. :-)
-
Made my purchase yesterday!!
-
Hey Olsen, thanks for your effort on making this a reality.. I'm very interested to run it on my MorphOS machines.. eventhough the documentation states that it should work under MorphOS, it doesn't... I've done several tests on my Pegasos II with MorphOS 3.1 with no success as of yet (though made it work right out of the box in my A1200D with pcmcia wifi nic)... is there any chance you could take a look to find out why it doesn't work in MorphOS?
Cheers,
Dragster
-
I plan to buy a copy after my next paycheck!
-
Hey Olsen, thanks for your effort on making this a reality.. I'm very interested to run it on my MorphOS machines.. eventhough the documentation states that it should work under MorphOS, it doesn't... I've done several tests on my Pegasos II with MorphOS 3.1 with no success as of yet (though made it work right out of the box in my A1200D with pcmcia wifi nic)... is there any chance you could take a look to find out why it doesn't work in MorphOS?
First off, I never tested this with MorphOS myself (for lack of hardware; I spent a lot of time testing Roadshow with the low end A1200/A600 configurations). From all I know about MorphOS, there should be no obvious reason why Roadshow should fail to work with it.
Save for the arguably intrusive use of DEVS:Internet, DEVS:NetInterfaces and SYS:Storage/NetInterfaces the software is written to work with the baseline Kickstart/Workbench 2.04 system configuration, and the SANA-IIR3 (R3 = R2 plus multicast operations) network driver standard. As far as I know MorphOS backwards compatibility extends across these operating system features: if Miami or the 68k AmiTCP Genesis work, so should Roadshow.
Getting to the bottom of this issue might prove difficult since I don't have a MorphOS machine handy which I could check the specific problems with. Any help would be appreciated, although that help might end up taking up a lot of time (just so you know how tough chasing a bug can be).
-
I plan to buy a copy after my next paycheck!
Same here! :mickeymouse:
-
Hey Olsen, thanks for your effort on making this a reality.. I'm very interested to run it on my MorphOS machines..
Doesn't MorphOS have its own TCP/IP-stack?
-
Doesn't MorphOS have its own TCP/IP-stack?
Indeed it has, and it is even being updated as we speak using a newer FreeBSD code base, and it seems it might be included in the MorphOS 3.2 release already!
Link (http://www.morphzone.org/modules/newbb_plus/viewtopic.php?forum=9&topic_id=8962&post_id=97689&viewmode=flat&sortorder=0&showonepost=1)
:D
-
Hey, don't you hijack the thread now granny! ;)
-
Hey, don't you hijack the thread now granny! ;)
:lol:
-
Doesn't MorphOS have its own TCP/IP-stack?
It does, but it's outdated and slow...
-
I just ordered and downloaded it. Many Thanks for making this happen!
-
It does, but it's outdated and slow...
Only until Morphos 3.2 is released...
I'll order this package too soon. Might be useful for the FPGA Arcade. :)
-
First off, I never tested this with MorphOS myself (for lack of hardware; I spent a lot of time testing Roadshow with the low end A1200/A600 configurations). From all I know about MorphOS, there should be no obvious reason why Roadshow should fail to work.
It seems you can make it to work (post 14 and 15) (http://www.morphzone.org/modules/newbb_plus/viewtopic.php?topic_id=8962&forum=9&start=13) by initializing the network device manually yourself, since Roadshow fails in doing that. Haven't tried it myself yet.
:)
EDIT: And a reply to that is found in this thread (http://www.amiga.org/forums/showpost.php?p=721764&postcount=21)!
:)
-
Paid for roadshow tonight at amigashop.de and paypal took my money. Its still showing I havent paid when I go back to download it? Anyone know how to reach the shop for an answer on my registration copy? Demo works amazing.
-
Paid for roadshow tonight at amigashop.de and paypal took my money. Its still showing I havent paid when I go back to download it? Anyone know how to reach the shop for an answer on my registration copy? Demo works amazing.
Give them a couple of days to transfer the money. For me, it took only a day until I could download the software.
-
Give them a couple of days to transfer the money. For me, it took only a day until I could download the software.
Got the email in spam about the download info. WOW is it so much faster than MiamiDX! I about gave up on my FastEthernet card in the mediator. It wouldnt get anything from Miami. I moved over the MEdiatorFast config supplied with Roadshow and it just worked, nothing to do further after a reboot.
If you are thinking of getting thing and are not sure, DO IT!! Fantastic software.
-
Yes, I agree. Great piece of software :) I had been using MiamiDX for many years but now Roadshow is my primary TCP/IP stack.
-
Yeah long as the price isn't very much I would definitely support it and any new Amiga software products anyone develops
-
Yeah long as the price isn't very much I would definitely support it and any new Amiga software products anyone develops
I'm with you! Dang it, all you folks resurrecting the Roadshow thread. I always recommend it to people but have yet to try it for myself. Can someone clone me, so at least then maybe the other 'me' could spend a little more quality time with the Miggy's? :lol:
On the bright side, sounds like TheDaddy is making good progress on his latest keyboards and custom keycaps project (https://www.kickstarter.com/projects/505470364/amiga-inspired-key-caps-for-mechanical-keyboards/description). I'm excited to hopefully get mine soon! :)
-
I'll go ahead and say Roadshow does rock! Seriously, if you have a network capable Amiga, get it right meow! Seriously night and day performance between Genesis and Roadshow. Plus, I always hated that you I could never quite get Genesis to start on boot up, but with Roadshow it basically did right away. Boot up the Miggy, and immediately I can browse, use IRC, etc. I know he's released at least one bug fix update since I downloaded, I should check again once I have my Miggy back to how I want it set up.
I say if you have the money, even if you don't really need it (for example you only use WinUAE, which has it's own bsdsocket setup) you should get it. I actually recently bought HDDriver for the Atari ST. 1) because I wanted the best to partition out my Falcon. 2) because I wanted to support the guy writing software for our beloved platforms! Oddly, I think I bought a copy of it many many moons ago, but I'm not sure (I know it was one of the different hard drive drivers, just can't recall which one!) Good times!
-
Dag-gummit. So my old install of Miami apparently didn't seem to like my new '060 card, and decided it only wanted to work about half the time, so I figured I'd give Roadshow a shot. Of course things never work out like they're supposed to and I'm getting the following two problems:
(1) Execute S:Network-Startup seems to take about 30 seconds to complete. If I run it as part of User-Startup it won't let Workbench display until it's done, and
(2) AddNetInterface X-Surf-100 gives the error message: "Could not add interface "X-Surf-100" (Object exists)"
This is with the default config of Roadshow, no options changed other than the first text file (bumped the buffers up from 32 to 64). I also tried changing "unit #" to 1, no difference. Other settings are all still at their default for DHCP, etc.
....Next I also tried renaming the DEVS:X-Surf-100.device file that came with my card to ".old", and then "AddNetInterface X-Surf-100" fails with "Failed to open "bsdsocket.library" V4". I confirm that I have bsdsocket.library version 4.310 in LIBS:.
...Next I tried commenting out all the Assigns for the legacy Genesis/AmiTCP/Miami on my 3.9 setup, now "Execute S:Network-Startup" completes in a second or so, but "AddNetworkInterface X-Surf-100" fails with ""X-Surf-100 configuration attempt timed out".
I've been at this for two hours already. Obviously I have some conflict with either the Genesis/AmiTCP stuff that's installed as part of 3.9, or my Miami install. While I continue to poke around at it, anyone have any suggestions? It's never easy, but this is why we love our Amiga's, right? Thanks! :)
Edit - strike all that. After fighting with it for 3 hours I decided my time was better spent working on getting Miami running right again. Maybe if someone wants to point me in the direction of a "dummies guide for Roadshow" I'll give it another shot sometime. After I've had more coffee. ;)
Bah, now I understand what the other guy was complaining about Roadshow leaving directories all over the place. :(
-
All I did was install it using the installer. Go to storage and take the MediatorFast from the configs and put it in the real devs location. Rebooted and I was online. Thats was it.
-
All I did was install it using the installer. Go to storage and take the MediatorFast from the configs and put it in the real devs location. Rebooted and I was online. Thats was it.
Did that, only in my case it was the X-Surf-100 file. No love, and no end to the string of error messages. Oh well, after some tweaking Miami is now working better than ever. I even fixed AWeb and got it working now, too! :roflmao:
-
Did that, only in my case it was the X-Surf-100 file. No love, and no end to the string of error messages. Oh well, after some tweaking Miami is now working better than ever. I even fixed AWeb and got it working now, too! :roflmao:
I'm glad I read your post before trying it, as I have a similar setup.
(New protocol: Let Mike fight with it first. :))
-
I'm glad I read your post before trying it, as I have a similar setup.
(New protocol: Let Mike fight with it first. :))
LOL. By all means, try the demo. Just give yourself a couple of hours to mess with it if it doesn't work "out of the box", as they say. Think my issue was compatibility issues with my previously installed TCP/IP programs, since my system is pretty heavily tweaked. Dunno, will try it again when I have more time. ;)
-
Bah, now I understand what the other guy was complaining about Roadshow leaving directories all over the place. :(
Wow, some unexpected understanding ;)
-
Hi I bought Roadshow a while ago and it was easy to install and works like a dream on my Amiga 1200 and my Amiga 600 and is the best thing I ever bought.:):):) oh but I do have to write Netshutdown if I play games but that is worth the effort to watch both my Amiga beauties surfing the Net,Brian
-
Hi I bought Roadshow a while ago and it was easy to install and works like a dream on my Amiga 1200 and my Amiga 600 and is the best thing I ever bought.:):):) oh but I do have to write Netshutdown if I play games but that is worth the effort to watch both my Amiga beauties surfing the Net,Brian
You mean WHDLoad games. :)
-
You mean WHDLoad games. :)
LOL Hi there and yes WHDLoad games
:):):):)
-
Do US customers exclude the 19% tax in their payment?
http://www.amigashop.org/product_info.php?products_id=200
-
I am now using the x-surf 100 file with mine and same thing, just worked once I moved it to devs. There are two files to move! One in devs for the card and another that goes in networks. Be sure to get them both in correctly!
-
Acill,
Since I know you are in the US, did you need to pay the tax as well for your purchase?
Just want to be sure so I do not overpay.