Establishing TCP/IP through Serial on Apple II
Ole Voss
standard TCP/IP network by using a serial connection. The idea would be to
implement the TCP/IP protocol on the Apple II and use it to connect to a
gateway on a PC using a serial line. The PC (which is cheap and omnipresent)
could then be used to connect to the internet without the need of buying an
expensive NIC for the Apple II. I know the speed wouldn't be terrific with
the low SCC bandwidth, but the idea I think is worth pursuing because there
are no cheap NICs for the Apple II. The only card I know of is actually the
10MB card by SHH Systems for the IIGS.
This is probably an old idea which has been done before, so if anybody knows
of such a project, maybe you could point me in the right direction?
Does anybody know how to activate such a PC Gateway which listens for the
TCP/IP over the serial line (would this be the slipp protocol?)
Thanks,
Ole.
Redskull
"Ole Voss" <ole....@netrogue.de> wrote in message
news:b4v413$240h2f$1...@ID-118921.news.dfncis.de...
Sound feasible.
Why not build a 16550 based serial interface card?
Would speed things up a fair bit, plus there is already some 6502 based
driver code available on the net to suit.
Red
Ole Voss
> Would speed things up a fair bit, plus there is already some 6502 based
> driver code available on the net to suit.
Yes it would, but then it wouldn't be openly available for all the people
who don't use that card. My aim is to let all Apple users with an existing
SCC be able to get access to a TCP/IP network without investing in new
hardware. I read an article recently where some C64 users developed a
browser with TCP/IP stack and made it usable within 64K... that sort of
piqued my curiosity :-)
Ole.
Bill Garber
> Why not build a 16550 based serial interface card?
> Would speed things up a fair bit, plus there is already some 6502 based
> driver code available on the net to suit.
>
> Red
Funny you should mention that as I am looking into the
probability of modding the SSC to work as a high speed
connection port. Problems so far include:
1) Finding IC packages that won't require a 1" stack of
components on the card.
2) Patching the chip into the switches, or possible complete
removal of the switches.
3) Crystal value needed to drive said device without burning
out the present traces.
4) Finding schematic and/or existing card ( any system ) to
utilize as a guide.
Bill @ GarberStreet Enterprises
http://garberstreet.netfirms.com
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.449 / Virus Database: 251 - Release Date: 1/27/03
Ole Voss
> probability of modding the SSC to work as a high speed
> connection port. Problems so far include:
But you still want to use it as a normal SCC? I cannot quit imagine how that
would work, seeing that every other chip would include totally different
registers - or not?
Ole.
Bill Garber
It should still revert to normal speed mode, hence the question
on switch usage. Adding the 16550 and leaving the 6551 on the
card and utilizing a switch on the +5v it should be capable of
being switched back and forth, however, the increased rating
of crystal would give you increased baud also, so the switch
settings would not correspond to the proper baud rates now.
Of course if you had a network card in, you'd still need another
SSC to handle serial modem or printer access, so It shouldn't
make a difference whether you could or not.
Ole Voss
that hassle, a new PCB would probably be less to fiddle with :-)
Bill Garber
> Wouldn't it make more sense to just develop a new card? Before going to
all
> that hassle, a new PCB would probably be less to fiddle with :-)
True, but not as much fun, challenge or time consuming. ;-)
Redskull
"Bill Garber" <will...@comcast.net> wrote in message
news:j1-dnWV1J7b...@comcast.com...
>
> > Why not build a 16550 based serial interface card?
> > Would speed things up a fair bit, plus there is already some 6502 based
> > driver code available on the net to suit.
> >
> > Red
>
> Funny you should mention that as I am looking into the
> probability of modding the SSC to work as a high speed
> connection port. Problems so far include:
Easier to build a new card, only requires 3 chips:
1 x 16550 UART
1 x 74LS259 for address decoding
1 x MAX232 for TTL<->RS232 level changes
1 small signal transistor to generate open-collector interrupt signal
several caps to operate the voltage converter in the MAX chip.
I can post the circuit if you like, since I built one several years ago.
I will have to find wherever I put it though.
> 1) Finding IC packages that won't require a 1" stack of
> components on the card.
???
>
> 2) Patching the chip into the switches, or possible complete
> removal of the switches.
No need for the switches since the internal architecture of the 16550 is
different from the 6551, the driver rom on the ssc will not work.
>
> 3) Crystal value needed to drive said device without burning
> out the present traces.
18.432MHz xtal oscillator can 14DIL package size is recommended.
This oscillator frequency makes all of the standard baud rates possible,
and gives the chip a theoretical top speed of 460k bps if I remember
correctly.
>
> 4) Finding schematic and/or existing card ( any system ) to
> utilize as a guide.
As above.
Cheers,
Red
Bill Garber
> > > Why not build a 16550 based serial interface card?
> > > Would speed things up a fair bit, plus there is already some 6502
based
> > > driver code available on the net to suit.
> > >
> > > Red
> >
> > Funny you should mention that as I am looking into the
> > probability of modding the SSC to work as a high speed
> > connection port. Problems so far include:
>
> Easier to build a new card, only requires 3 chips:
> 1 x 16550 UART
> 1 x 74LS259 for address decoding
> 1 x MAX232 for TTL<->RS232 level changes
> 1 small signal transistor to generate open-collector interrupt signal
> several caps to operate the voltage converter in the MAX chip.
>
> I can post the circuit if you like, since I built one several years ago.
> I will have to find wherever I put it though.
Please post away. That sounds like what I am looking for. Thanks
Bill @ GarberStreet Enterprises
http://garberstreet.netfirms.com
> > 1) Finding IC packages that won't require a 1" stack of
> > components on the card.
> ???
> >
> > 2) Patching the chip into the switches, or possible complete
> > removal of the switches.
>
> No need for the switches since the internal architecture of the 16550 is
> different from the 6551, the driver rom on the ssc will not work.
> >
> > 3) Crystal value needed to drive said device without burning
> > out the present traces.
>
> 18.432MHz xtal oscillator can 14DIL package size is recommended.
>
> This oscillator frequency makes all of the standard baud rates possible,
> and gives the chip a theoretical top speed of 460k bps if I remember
> correctly.
> >
> > 4) Finding schematic and/or existing card ( any system ) to
> > utilize as a guide.
>
> As above.
>
> Cheers,
>
> Red
>
>
Rob
>>Why not build a 16550 based serial interface card?
>>Would speed things up a fair bit, plus there is already some 6502 based
>>driver code available on the net to suit.
>>
>>Red
>
>
> Funny you should mention that as I am looking into the
> probability of modding the SSC to work as a high speed
> connection port. Problems so far include:
There was a post a few days ago about a guy who had develpoed a mod to
the SSC which allowed it to go to 230kbps. It changes 2 chips on the
card. He was selling it for >$30 a few years ago.
I'm not sure what speed a the various apples will actually support. Has
anyone got any reliable information on that? I woudl be interested in
actual transfer rates for the LANceGS card and of rthe Appletalk card. I
expect it would be much lower that the published maximum rates.
--
Rob
"Never ascribe to malice that which can be adequately explained by
stupidity"
CHRIS MORSE
wrote:
>I've been thinking about the possibility of hooking Apple II computers to a
>standard TCP/IP network by using a serial connection. The idea would be to
>implement the TCP/IP protocol on the Apple II and use it to connect to a
>gateway on a PC using a serial line.
If you look back a few messages, you should see a whole bunch talking
about Contiki. Contiki is built on top of uIP, a small TCP/IP stack
for 8-bit computers; developed by Adam Dunkels.
The Contiki web site, with links to uIP is here:
http://dunkels.com/adam/contiki/
This is specifically why I was trying to get SSC information, so I
could port the source code to the Apple // systems.
Unfortunately, the process has been slow. The cc65 compiler seems to
have changed in the latest release, and it's not generating correct
6502 code for me. I recompiled a simple hello world program (from the
samples) and the machine language output in the final binary was
completely different than before. And it doesn't run at all... so I'm
looking into that. I think the latest CC65 compiler is buggy for some
reason. www.cc65.org
>The PC (which is cheap and omnipresent)
>could then be used to connect to the internet without the need of buying an
>expensive NIC for the Apple II. I know the speed wouldn't be terrific with
>the low SCC bandwidth, but the idea I think is worth pursuing because there
>are no cheap NICs for the Apple II. The only card I know of is actually the
>10MB card by SHH Systems for the IIGS.
Actually, the LANceGS card also works on the Apple //e, but no one has
written drivers for it (from what I understand.) So it's possible to
go that route too.
uIP currently supports SLIP, and unfortunately (again!) Windows will
not be a SLIP server. It will only talk PPP. Lawrence Chitty is
working on a PPP implementation for uIP/Contiki, but it's still in
early development.
My first idea was to write a Windows application that listens on one
or more COM: ports and acted as a direct-link interface for the Apple
// running any sort of Comm software like ProTERM. The Windows app
would then present a sort of text menu interface that would allow it
to connect out to the internet - FTP, HTTP, NNTP, Telnet, etc. as
well as do file transfers from the host PC. This would allow the
Apple // to talk on the internet without the overhead of a TCP/IP
stack and SLIP/PPP.
The Windows app could also act like a sort of proxy server. The apple
could send "CONNECT HTTP hostname port" to the windows app and the
host PC would make the socket connection and relay the bytes
sent/received. This would allow more Apple //'s to connect to the
internet, I think. Until PPP is available for Contiki, there's no
real way to hop on the internet without a seperate unix box
(Linux/FreeBSD/etc) running a slip server. (Which I don't have
myself!)
>Thanks,
>
>Ole.
Cheers!
// CHRIS
Rob
>>
> If you look back a few messages, you should see a whole bunch talking
> about Contiki. Contiki is built on top of uIP, a small TCP/IP stack
> for 8-bit computers; developed by Adam Dunkels.
>
> The Contiki web site, with links to uIP is here:
> http://dunkels.com/adam/contiki/
>
> This is specifically why I was trying to get SSC information, so I
> could port the source code to the Apple // systems.
>
> Unfortunately, the process has been slow. The cc65 compiler seems to
> have changed in the latest release, and it's not generating correct
> 6502 code for me. I recompiled a simple hello world program (from
> the samples) and the machine language output in the final binary was
> completely different than before. And it doesn't run at all... so
> I'm looking into that. I think the latest CC65 compiler is buggy for
> some reason. www.cc65.org
Really sorry to hear that. How are you compiling the source? I was
looking at cc65 myself and it looks like it primarily intended to be run
under linux.
>
> Actually, the LANceGS card also works on the Apple //e, but no one
> has written drivers for it (from what I understand.) So it's
> possible to go that route too.
There is also a discussion here of adapting Adams TFE for the Apple ][.
Interestingly enough some of the chips for the embedded market have a
built in TCP/IP stack. That is probably the route which places least
demand on the Apple ][s limited resources.
>
> uIP currently supports SLIP, and unfortunately (again!) Windows will
> not be a SLIP server. It will only talk PPP. Lawrence Chitty is
> working on a PPP implementation for uIP/Contiki, but it's still in
> early development.
This is clearly desirable I hope development goes quickly.
>
> My first idea was to write a Windows application that listens on one
> or more COM: ports and acted as a direct-link interface for the Apple
> // running any sort of Comm software like ProTERM. The Windows app
> would then present a sort of text menu interface that would allow it
> to connect out to the internet - FTP, HTTP, NNTP, Telnet, etc. as
> well as do file transfers from the host PC. This would allow the
> Apple // to talk on the internet without the overhead of a TCP/IP
> stack and SLIP/PPP.
This can already be accomplished on Linux or Unix, by a simple serial
login. Given the low cost of obsolete hardware, that is a more cost
effective approach.
>
> The Windows app could also act like a sort of proxy server. The
> apple could send "CONNECT HTTP hostname port" to the windows app and
> the host PC would make the socket connection and relay the bytes
> sent/received. This would allow more Apple //'s to connect to the
> internet, I think. Until PPP is available for Contiki, there's no
> real way to hop on the internet without a separate unix box
> (Linux/FreeBSD/etc) running a slip server. (Which I don't have
> myself!)
>
When the Contiki desktop is available, even with its current
limitations, I think there are a number of people will jump to the task
of solving these problems. Whether is is PPP, or ethernet adapters. The
real problem has been up to now several efforts to create a working
TCP/IP stack for the 8 bit Apples have not been completed.
Ole Voss
> anyone got any reliable information on that? I woudl be interested in
> actual transfer rates for the LANceGS card and of rthe Appletalk card. I
> expect it would be much lower that the published maximum rates.
Sorry, I haven't gotten around to actually using my LANceGS. The card seems
to work, but I was a bit disappointed due to the lack of software (ftp,
telnet, browser) for the GS. I know these programs are available, but either
for a price or not complete yet. Seeing that the IIGS has been around for so
long I'm frustrated about the desire of some people to still make a business
of it.
Ole.
Ole Voss
> about Contiki. Contiki is built on top of uIP, a small TCP/IP stack
> for 8-bit computers; developed by Adam Dunkels.
Yes, I've been looking into uIP since it was one of the first entry google
presented on the subject :-)
I was going to take a peek at the source when writing my own TCP/IP stack.
> Actually, the LANceGS card also works on the Apple //e, but no one has
> written drivers for it (from what I understand.) So it's possible to
> go that route too.
That's true, but my aim was to do it cheap. The lancegs is just too
expensive for broad application - however good it is, the price (alas)
disqualifies it.
> My first idea was to write a Windows application that listens on one
> or more COM: ports and acted as a direct-link interface for the Apple
> // running any sort of Comm software like ProTERM. The Windows app
> would then present a sort of text menu interface that would allow it
> to connect out to the internet - FTP, HTTP, NNTP, Telnet, etc. as
> well as do file transfers from the host PC. This would allow the
> Apple // to talk on the internet without the overhead of a TCP/IP
> stack and SLIP/PPP.
That's an interesting idea.
> The Windows app could also act like a sort of proxy server. The apple
> could send "CONNECT HTTP hostname port" to the windows app and the
> host PC would make the socket connection and relay the bytes
> sent/received. This would allow more Apple //'s to connect to the
> internet, I think. Until PPP is available for Contiki, there's no
> real way to hop on the internet without a seperate unix box
> (Linux/FreeBSD/etc) running a slip server. (Which I don't have
> myself!)
If you were going to program a Win32 program like that, then adding SLIP
capability would not be the problem. Basically SLIP only consits of two
extra characters ;-)
I think your idea is very interesting. Unfortunately I'm looking into this
matter as part of a program I'm writing for University. My aim is to write a
TCP/IP stack (even if it has been done thousands of times before). The whole
thing will be done in Java. Once I've finished that I hope that I'll be fit
enough to hammer it into 6502/65816 code. My ultimate goal is to do
something cool with it, like write an HTTP webserver and actually run
websites of an Apple II, or write a multiplayer adventure game or something.
That is, ofcourse, in the far distant future. The idea just exites me and I
though now would be a good time to start :-)
Cheers,
Ole.
CHRIS MORSE
wrote:
>> The Windows app could also act like a sort of proxy server. The apple
>> could send "CONNECT HTTP hostname port" to the windows app and the
>> host PC would make the socket connection and relay the bytes
>> sent/received. This would allow more Apple //'s to connect to the
>> internet, I think. Until PPP is available for Contiki, there's no
>> real way to hop on the internet without a seperate unix box
>> (Linux/FreeBSD/etc) running a slip server. (Which I don't have
>> myself!)
>
>If you were going to program a Win32 program like that, then adding SLIP
>capability would not be the problem. Basically SLIP only consits of two
>extra characters ;-)
Well, no.. The Apple // and PC would be doing direct text-based
communication, much like a Telnet session. SLIP would be for a TCP/IP
stack and would be a much lower-level protocol than what I am talking
about.
I am definitely going to do this project. I've already written a
multi-threaded / multi-user BBS program in Win32/MFC using VC++.
All I have to do is take the code and rip out the old BBS-specifc code
and replace it with new stuff.
Unfortunately, it is put on hold right now as all my Apple // hardware
is in boxes - I'm in the process of closing on a new house and moving.
The closing is in 2 weeks, but then I have to stay where I am for 2
more months, due to work. I'll be at the new house only on weekends
during the next two months.. After June 1st, I'll have all my
computer hardware (two tower PC's, 2 portables, and an Apple //c+)
hooked up in my (woo hoo!) computer/work room.
As another project, I want to write a new Telnet BBS program for
Windows geared towards real Apple // clients.
Hmm.. I could probably run an RS232 cable from COM1: to COM2: and
configure the AppleWin emulator to use one port while Windows uses the
second port. Dang- why didn't I think of that before...
>I think your idea is very interesting. Unfortunately I'm looking into this
>matter as part of a program I'm writing for University. My aim is to write a
>TCP/IP stack (even if it has been done thousands of times before). The whole
>thing will be done in Java. Once I've finished that I hope that I'll be fit
>enough to hammer it into 6502/65816 code. My ultimate goal is to do
>something cool with it, like write an HTTP webserver and actually run
>websites of an Apple II, or write a multiplayer adventure game or something.
>That is, ofcourse, in the far distant future. The idea just exites me and I
>though now would be a good time to start :-)
I've always been interested in TCP/IP implementations, and when I saw
uIP I was pretty excited - even if only from an academic point of
view. And I'd still like to get it working on the //e.
Marinetti, the Apple II GS TCP/IP stack supports SLIP/PPP. I thought
the whole project was available in source code form, but I recently
found out it's not. I think you can get the code for the SLIP/PPP
portion, but you can't get the code for the actual TCP/IP stack.
>Cheers,
>
>Ole.
>
Cheers!
// CHRIS
Ole Voss
> the whole project was available in source code form, but I recently
> found out it's not. I think you can get the code for the SLIP/PPP
> portion, but you can't get the code for the actual TCP/IP stack.
Ontop of that, it only works on the IIGS. The real thrill is in getting
older, less powerful machines to utilize this protocol :-)
Ole.
Rob
>
> Marinetti, the Apple II GS TCP/IP stack supports SLIP/PPP. I thought
> the whole project was available in source code form, but I recently
> found out it's not. I think you can get the code for the SLIP/PPP
> portion, but you can't get the code for the actual TCP/IP stack.
>
>
> Cheers!
> // CHRIS
>
The open source project is here;
http://sourceforge.net/projects/marinetti
Simon Williams
Hear! Hear!
Time to overthrow the GS elite -- the 8-bit revolution is at hand !!!
:)
--
Simon Williams
Luddite Enterprises
http://www.luddite.ca