project ICE   

Project ICE is an attempt to provide better Internet connectivity for Atari 8-bit computers.  Currently, internet connectivity is primary limited to shell accounts utilizing a text interface.  The hope of this project it to provide true PPP connectivity through almost any ISP.  Telnet, primitive browsers, and mail/news clients could then be developed.  The first step is to receive a web page via TCP/IP/PPP to aid in getting the TCP/IP routines perfected.

Step 1: Get PPP connection working.  Completed
This includes getting the basic communication routines, the PPP packet handling and connection negotiation working (IPCP & LCP).
This portion is basically done.  I am able to establish a connection and get through the IPCP and LCP phases, get an IP, reject protocols I don't want, etc.

Step 2: Get TCP/IP working. Complete!
Actually transmit a SYN (connection) packet somewhere and get a SYNACK (response).
This portion seem to work ok.

Step 3: Send and Receive Data. Mostly Complete.
Send and receive real data.
The program will now download a specific web page and dump it to the screen.  I am currently working on a stable API other applications can use if this program seems to work for most people.  I now dump irrelevant TCP packets, reject duplicate packets, fill an input buffer and use it as the windows size sent to the server.  I now need to add some retry code in case my ACK's don't make it to the server.

Step 4: Develop programs to use the routines. A dream?
Write a basic vt100 telnet client (or a handler that could be used by existing terminal programs), a text web browser, etc.

December 16,1999 - New version released to test new interrupt driven packet receive routines.  Note:  This version will not download a web page or anything useful, it will just establish a PPP connection.  I need this tested on real Atari's and different R: handlers.

November 11,1999 - Fixed bug in connection negotiation logic.  If CHAP authentication protocol was request the program would appear to lock up instead of attempting to request PAP protocol.  This is now fixed and the downloads section has been updated.  I can now log onto my one ISP using the manual login or immediately engaging PPP and letting PAP authorize me.  The tcp/ip portion still needs some work and this is on my list soon.

November 8,1999 - Making slow progress and some code rewrites.  Added an Information section at the bottom of the page with a link to a page with TCP/IP/PPP links.  Also added a link to a page with commented PPP negotiation traces to my Internet Providers for those interested.

November 1,1999 - Things are progressing slowly due to limited time.  I have made some changes to the connection routines (it is now more state driven with retries built in) and am in the process of partially rewriting some of the PPP code to make it a little more generic (modules not dependent on each other).  I am considering adapting tcp/ip code at  http://www.heilbronn.netsurf.de/~dallmann/lunix/lng.html (for C64 and using SLIP) to work with my PPP code.  And lastly, I am also going to experiment with making the receive packet routines interupt driven (during vbi) to see if it is feasable.

October 13,1999 (2nd update) - Updated both test program.  TCPTEST.ARC hold TCPTEST.EXE which should function practically identically to the last version.  It is just built with the new assembler.  TCPDEBUG.ARC is now current with TCPTEST and displays diagnostic information.  After hangup, it should write an ASCII log to D1: called PPP.LOG.
 

Q. Can ICE be used to get on the internet?
A. Yes and No.  It in theory should be possible to establish a PPP connection to your ISP.  The program is hardcoded to try and pull a specific URL down via HTTP (web) - My Atari page actually.  It should dump the page to the screen as it downloads and hangup when done.

Q. Are you going to release source code?
A. I intend to more than likely eventually release some source code.  I would like to have something to release that is useful on the Atari before releasing source so these programs actually appear on an Atari first and not other 6502 based machines :-).  Also I need to do a lot of cleanup in the code.  I might still consider putting up the code with conditions that any deritive work must have source code published then maybe programmers of other 6502 computers could be an asset.

Q. Are you going to release interface specifiications so other programs can be written?
A. That would probably need to be a necessity since I will not have the time or knowledge to write some of the applications that use tcp/ip.  Since nothing is currently finalized this is not possible yet.

Q. Will the routines be separate from the applications that use them?
A. That would be the most useful possibility.  One real problem on the Atari 8-bit is that most interfaces can not do disk i/o and serial communication at the same time.  Being idle for too long would drop connections or disconnect from a server - probably wouldn't be a problem for most programs though.  Don't be expecting to run more than one program at a time though, these routines more than likely will only handle one connection at a time.

Q. How can I help?
A. Download the software and try it.  Let me know if you are able to dial.  Let me know if you get PPP connected and if you logged in manually or used the authentication protocol.  Let me know if you get the entire page (you see the </HTML> tag at the end) or if you at least get part of it.

Q. When will it be done?
A. Don't know.

Q. What applications will there be.
A. Telnet would be good for telnetable BBS's.  A simple text web browser (or even limited graphics) would be possible.  Probably SMTP, POP3 should be doable.  Maybe even IRC.  Concerning a web browser how about having Atari specific tag options like <IMG SRC="title.gif" A8SRC="title.a8g" ALT="My Page"> or something like that where title.a8g might be an atari specific graphic format?

READ THIS: Always read the instructions with each new download since there may be changes made each time as the program progresses.  Baud rate in the program is fixed at 9600.  The server it will connect to is 207.211.212.45 (in hex... CF.D3.D4.2D  or host name.... home.columbus.rr.com) on the normal HTTP port of 80.  It will download my Atari page from /ksiders/atari.htm.  The file is provided for download is in ARC format.  It only contains one file: TCPTEST.EXE.

Warning:  A general knowledge of modem and handler usage is assumed.  I can only provide basic information and you are on your own.  The first download is the test program.  This program also does not perform any completely useful function other than negotiating and establishing the PPP connection and trying to download a page (it almost works).  A handler for your interface/modem must be loaded before the program will work.  This is usually established by making a copy of your R: handler and appending this program to it.  Loading the combined file should then, in theory, work.  Before downloading here are the basic steps to testing the program:

Method 1 - (Tested with my GTE.NET account)  This is if you get a login and a password prompt when you connect (try this first)
1. Load the file (duh)
2. Some text should display.  You don't need to answer the "User:" and "Pass:" prompts, just press RETURN.
3. Type 'AT' and hit RETURN and see if your modem is working.  It should respond with OK.  (The AT you type may or not display depending on your modem settings)
3. Type ATDTxxxxxxx and hit RETURN  xxxxxxx is your ISP phone number (you may need to type blindly, use ATDP for pulse dialing)
4. After connection you will hopefully get some kind of login prompt.  If you don't try hitting RETURN.  If you get no response then try method two below.
5. Answer the login and password prompts.
6. After this you may get some info displayed.  Type a ! to send the first configuration packet.  PPP mode should automatically engage and you will see all kind of interesting info (or not so interesting) as the negotiation takes place.  If it fails, please try reloading the program and trying again.  There is not much in the way of retries built into the program yet.
7. Eventually you should see that a PPP connection was established.  If so, that is great and progress is made.  If it gets stuck in the negotiation part then there is more work to do.
8. The program will then try to connect to home.columbus.rr.com ( 207.211.212.45 or in hex CF.D3.D4.2D )  Hopefully, it will say a SYN was sent and then after a second a SYN-ACK was recieved.  Afterwards it will send an ACK and the a GET /ksiders/atari.htm request.
9. If all goes well, you will see the html from my web page streaming by.  When done and all goes well it will hangup.  If all doesn't go well then it will probably retry and fail.

Method 2 - (Tested with a work account)  This is if you do not get a login and a password prompt when you connect (or you know you have to use PAP protocol)
1. Load the file (duh)
2. Some text should display.  Answer the "User:" prompt with your username and the "Pass:" prompt with your password.  It is probably case sensitive so be sure to get that right.
3. Type 'AT' and hit RETURN and see if your modem is working.  It should respond with OK.  (The AT you type may or not display depending on your modem settings)
3. Type ATDTxxxxxxx and hit RETURN  xxxxxxx is your ISP phone number (you may need to type blindly, use ATDP for pulse dialing)
4. After you see the CONNECT xxxx prompt, type a ! to send the first configuration packet.  PPP mode should automatically engage and you will see all kind of interesting info (or not so interesting) as the negotiation takes place.  If it fails, please try reloading the program and trying again.  There is not much in the way of retries built into the program yet.
5. Eventually you should see that a PPP connection was established.  If so, that is great and progress is made.  If it gets stuck in the negotiation part then there is more work to do.
6. The program will then try to connect to home.columbus.rr.com ( 207.211.212.45 or in hex CF.D3.D4.2D )  Hopefully, it will say a SYN was sent and then after a second a SYN-ACK was recieved.  Afterwards it will send an ACK and the a GET /ksiders/atari.htm request.
7. If all goes well, you will see the html from my web page streaming by.  When done and all goes well it will hangup.  If all doesn't go well then it will probably retry and fail.

If your ISP requires a script under windows to connect then the method to connect may differ.  Usually you would just follow method 1 with some alterations.  With CompuServe (classic) you should use host name CIS and add a /go:pppconnect after your user name. (not tested)
NOTE: In reading PPP newsgroups with  messages on Linux users trying to get PPP working it seems lots of ISP's do things differently.  Don't be afraid to try other things.  For instance if the above methods fail, try filling in the username and password and also log in if you get prompts.  Try filling in the user name and password and don't log in and just press ! immediately after connect.  Good luck.

If you receive some page data please let me know.  If you recieve all of the data ( </HTML> tag will be last), let me know.  If you receive no data let me know if you get connected or not and how far that you do get.
 

A new downloadable version is available.  It actually does LESS than the prior versions but is to test the new interrupt driven receive packet routines.  I need this to be test with as many R: handlers as possible. This version will establish a PPP connection and then hang up.  It doesn't do anything else yet until the TCP/IP portion is rewritten.  So far it has only been tested under emulation.  Note: This version also adds a debug status line at the screen top.  S: is a spinner that moves for every packet sent.  R: is a spinner that moves for every packet received.  B: Is the number of free buffers (always 4 in this version).  In this version you are also prompted for baud rate since this has been requested by a couple of people.

Click to download  tcptest2.arc  6688 bytes.  Last Updated 16-Dec-1999

There are two older downloads.  The first is the main version.  The second is the "debug/logging version".  This version displays more messages and after
hanging up will write a log file to D:PPP.LOG (be sure to have space).  It shouldn't grow past 10K.  Use it if you are having problems in the negotiation
phase and want to provide it to me for diagnosis.  Note: the log may have your username and password in it if you answered the prompts and the negotiation got that far.  If you are concerned find them in hex and xx them out.  The log is in ASCII not ATASCII.

Click to download  tcptest.arc   6235 bytes.  Last Updated 11-Nov-1999
Click to download the debug/logging version:  tcpdebug.arc   7409 bytes.  Last Updated 11-Nov-1999.  (Note: this writes a log to D2:PPP.LOG, I forgot to change it from D1:.)

Click here to send me email.  (atari@columbus.rr.com)

  Click here to send me email.