Roadshow for 68K -Needs your support!

[olsen]

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.

[olsen]

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?

[olsen]

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?

[olsen]

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.

[olsen]

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.

[olsen]

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.

[olsen]

@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.

[olsen]

Interesting contract.

*Tactically* interesting contract, actually.

[olsen]

@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.

[olsen]

@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.

[olsen]

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.

[olsen]

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.

[olsen]

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.

[olsen]

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.

[olsen]

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.