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.

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.

October 13,1999 - Porting to a different assembler (and linker) is now complete.  I have also separated the program into a few more logical modules(files).  Now I should hopefully be able to get some work done on it.  For those interested the new assembler/linker being used in ca65/ld65 which are the cross assembler and linker for the commodore port of CC65 (something I would like to get an Atari library back working on sometime).   I dropped ATASM because of a few bugs:  lda zero,y (I think - might be x) not translating automatically to lda abs,y; jmp indirect not getting handled properly when the specified address is on zero page, and its bad syntax checking.

October 5,1999 - I received a second positive response of someone being able to download a page.  I am currently switching the source to compile with a different assembler and seems to be progressing ok.

September 27,1999 - Updating the executable on this page.  Although it does not do anything different is a lot more robust.  It ignores TCP/IP packets destined to other ports or to/from other IP addresses.  It also has some VBI timer routines that are a lot better than the stuff I was doing with locations
19 & 20.  The main problem I am currently have is if I bust doing something on my end (lets just say pause the screen with ctrl-1 for testing purposes).
I might receive a packet 2-3 times as it is resent.  Then I see all 2-3 packets and ACK them all,  from then on I will receive lots of duplicate packets.
I would assume (but am not sure) if the other end receives a duplicate ACK it will discard it so maybe I am not generating the ACK 100% correctly.
Haven't had time to look deep into it.  If anyone has a good understanding of TCP/IP or can point me to some minimalistic code.  My code currently
doesn't do things like sliding windows and stuff so it can be hard to compare to real tcp/ip code.  If there are any good 6502 assembler programmers
(even other platforms) with tcp/ip knowledge and would like to assist send me a message.  I am considering releasing source code with some stipulations.
I have only received on confirmation of a person who received HTML data and one who couldn't get past the login.  In the past I had one other person who got connected - which is all the program did at that time.  I have received several replies from people who don't have the stuff currently set up and would like to try it someday.  I am beginning to think there is lowering support for the 8-bits.  I hope this is not the case.  I am also looking for good recommendations for 6502 cross assemblers (preferably that can generate and atari executable or output that can easily be changed to an Atari executable.  I have been using atasm which I sort of like since it is MAC/65 like in syntax but some of the bugs in it are starting to get annoying.  Is there a version after .92 and does the author have a home page?  Well guess I have typed enough for now.

September 8,1999 - No new programs to release yet but hopefully soon.  I am working on the real api functions.  Most of the last few days I have worked on it has been wasted to trying to track down a buffer overrun problem - which I finally solved.  For those interested, a very prelimary document on the API is HERE.  It is highly subject to change and there may be some typos.  A based CIO interface may also be added.

August 30,1999 - No more programs or major information to report.  I am now trying to write some real receive functions.  The demo programs just send the GET command for the page and just dump every TCP/IP packet to the screen.  I am now trying to write (or more accurately... debug) some smarter easily callable receive functions.

August 17,1999 - Nothing earth shattering.  I put up a new executable (as well as a debug version).  The only changes are:  I moved some of the code to usuable functions (making an API), I now ignore PPP packets with bad checksums, it pulls down my ICE page instead of my main Atari page.  For those experienced with hex editors or debuggers the IP address/port and page name are easy to edit.  They are located at the beginning of the program and have some null space at the end of each so you can change them to try to load other pages (remember numeric address only followed by :80 for port).  The other download is a debug version.  It can be run if you are having problems in the negotiation phase.  It prints diagnostic messages to the screen and after hangup will write out a log file of all bytes exchanged.

August 16,1999 - I am back from vacation.  Hopefully I will have some time this week to do some more work.  I have received one success and one failure from people trying the program.  Please send me positive or negative feedback if you have had the opportunity to try out the test executable.

August 6,1999 - I am mostly working first on getting some better error checking into the program.  I now verify received PPP packets so a bad packet won't cause weird things to happen.  I am working on checking for duplicate TCP packets and possible checking checksums for the TCP data although I might let the PPP check be the only check for now.  I will be out of town next week so don't expect an update until or week and a half or so.

August 2,1999 - I can now download a web page!!!!!  I need testers to try this on a real atari.  The program is currently hardcoded to download my page at http://home.columbus.rr.com/ksiders/atari.htm.  A new download is available.

July 27,1999 - A few more adjustments and I am getting the page data now - Yipee.  Actually I am only getting the start of it since I got a few more things to fix yet but it is a start.   NO new downloads or trace have been added to the page yet.

July 26,1999 (2nd update)  - Bad News.  Seemed to be a fluke.  Haven't been able to replicate it again :-(

July 26,1999  - Good News.  I discovered I wasn't incrementing the ACK number on the HTTP get requests packet.  After fixing that I now seem to get HTML page data.  I have some work to do to get this in a usable form but thought I would update the progress here.  Download and trace have NOT been updated yet.

July 17,1999  - Revised some of the above text which I forgot to do last update.  Due to vacation and work related activities I was limited on time last week and this upcoming week.  Hopefully I can back to work on it Thursday (July 22). Added preliminary FAQ section.
 

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.

There are two 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   5506 bytes.  Last Updated 12-Oct-1999
Click to download the debug/logging version:  tcpdebug.arc   6805 bytes.  Last Updated 12-Oct-1999 NOTE:  This  version is now current.

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

  Click here to send me email.