Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A2CLOUD: support SLIP or PPP for Marinetti #3

Open
knghtbrd opened this issue Oct 26, 2015 · 7 comments
Open

A2CLOUD: support SLIP or PPP for Marinetti #3

knghtbrd opened this issue Oct 26, 2015 · 7 comments

Comments

@knghtbrd
Copy link
Member

From @IvanExpert on October 25, 2015 22:19

I looked into this and once got it cooking with SLIrP, but SLIrP is super slow, and I could never get the right script going. The bigger problem is that the lack of conditional logic in Marinetti's scripting makes it impossible to determine whether the serial shell is in any of three states: logged out, logged in, logged in with SLIP (or PPP) running.

I also suspect that even with proper SLIP or PPP server running on the Pi, it would still be just too slow; I'm not even sure that GS/OS can keep up with the theoretically 57,600 available.

Copied from original issue: RasppleII/a2server#35

@knghtbrd
Copy link
Member Author

I've done PPP before on Linux and OS/2, both almost 20 years ago now. I can dust off that knowledge, but I am definitely gonna need an assist with the Marinetti side of things.

SLIP may be easier (and lower impact on the IIgs's processor). I'll see what I can accomplish when my Uthernet IIs get here. If I can make it do something useful with that, I'm willing to work with someone to make it happen over serial as well.

@IvanExpert
Copy link
Contributor

I think in general this will be a difficult road to hoe due to Marinetti's lack of conditional scripting makes it impossible to reliably detect state, unless you want to get those devs to implement something. Still, would be interesting to try. The one time I succeeded in getting it to work with SLIrP it was unusably, pointlessly slow, but SLIrP is (from what I gather) an inefficient implementation, so I don't know if that's a relevant factor.

@pneubauer
Copy link

SLiRP is a user-space only program and is best for folks with dial-up shell access. PPPD uses kernel support and does not have the shell as an intermediary --- PPPD should be much faster but requires admin support to configure.

Also, beware of links that aren't 8-bit clean. Both SLIP and PPP have the option to avoid sending certain characters over the link (such as escape sequences for a terminal server). If this is enabled inadvertently, performance will drop substantially.

Bigger picture, it probably makes sense to support one of SLIP/PPP or MacIP for machines without an Uthernet. I'm unsure which is easier and more reliable, but MacIP does have the advantage of working with all classic Apple hardware.

@IvanExpert
Copy link
Contributor

MacIP would appear to be the clear winner to me if it can be made to work, if only because you'd potentially get up to 230 kbps over LocalTalk, as opposed to the 57.6 kbps you'd get over ordinary RS-232 as supported by Marinetti. The only real downside I see is that it depends on hardware that is no longer made (a LocalTalk bridge), though for the moment still seemingly in abundance and inexpensive, and even sold new if Asante's web site doesn't lie (not clear; you can't get to it from the home page, I don't think, but this still exists: http://www.asante.com/shop/shopdisplayproducts.asp?id=16&cat=+AsanteTalk)

In addition, you'd get both TCP and AppleShare on the same port, whereas with PPP, you'd have to dedicate a port to it (leaving only one other for virtual drives, shell login, or AppleShare).

On Oct 26, 2015, at 12:53 PM, Peter Neubauer [email protected] wrote:

SLiRP is a user-space only program and is best for folks with dial-up shell access. PPPD uses kernel support and does not have the shell as an intermediary --- PPPD should be much faster but requires admin support to configure.

Also, beware of links that aren't 8-bit clean. Both SLIP and PPP have the option to avoid sending certain characters over the link (such as escape sequences for a terminal server). If this is enabled inadvertently, performance will drop substantially.

Bigger picture, it probably makes sense to support one of SLIP/PPP or MacIP for machines without an Uthernet. I'm unsure which is easier and more reliable, but MacIP does have the advantage of working with all classic Apple hardware.


Reply to this email directly or view it on GitHub.

@knghtbrd
Copy link
Member Author

On Mon, Oct 26, 2015 at 09:53:25AM -0700, Peter Neubauer wrote:

Bigger picture, it probably makes sense to support one of SLIP/PPP or MacIP for machines without an Uthernet. I'm unsure which is easier and more reliable, but MacIP does have the advantage of working with all classic Apple hardware.

My concern with this is that SLIP/PPP could theoretically be done on
a //e or //c or possibly even a ][+ for some versions of heavily
upgraded ][+ which I haven't got so don't ask me how to do it. :) I
dunno what you'd use, maybe contiki or something?

However, for the IIgs, MacIP is going to be a much better choice.

At this point I'm pretty well assuming AppleTalk cards for the //e
are reasonably close to unobtanium. The last two I saw for sale were
new in box (because who bought the things back in the day?) and had
asking prices approaching that of the TransWarp GS. I really wish
Plamen or someone would clone the card because it'd make a lot of
things a lot easier.

Joseph

@IvanExpert
Copy link
Contributor

My concern with this is that SLIP/PPP could theoretically be done on
a //e or //c or possibly even a ][+ for some versions of heavily
upgraded ][+ which I haven't got so don't ask me how to do it. :) I
dunno what you'd use, maybe contiki or something?

Sure, I'd love to see an 8-bit solution, and you're right that Workstation Cards have become scarce (5 years ago, they popped up about once a month; now, it seems more like once a year.) However, Contiki is the only 8-bit TCP/IP stack, and it doesn't support SLIP or PPP, so unless you want to add that to it yourself, I'd say we're a long way off from TCP/IP on 8-bit Apple II's. (Plus I find Contiki to be less than enjoyable to use, but that's just one person's opinion.)

However, for the IIgs, MacIP is going to be a much better choice.

At this point I'm pretty well assuming AppleTalk cards for the //e
are reasonably close to unobtanium. The last two I saw for sale were
new in box (because who bought the things back in the day?) and had
asking prices approaching that of the TransWarp GS. I really wish
Plamen or someone would clone the card because it'd make a lot of
things a lot easier.

Me too. But it's a pretty complex card. it's got a 65C02 copressor on it and whatnot.

@knghtbrd
Copy link
Member Author

Since MacIP is now a thing for AppleTalk, is this still desired? Technically that solution requires some hardware and configuration of AppleTalk/A2SERVER whereas a SLIP or possibly PPP solution could be done fully within the scope of A2CLOUD.

Moreover, if SLIrP was slow, @IvanExpert was it on a lower-spec Pi that you tried it? A good number of slow things on the ARMv6 Pi are quite acceptable if you have a quad ARMv7 or faster.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants