project ICE  


Internet Connectivity for Eight-bit ataris


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 and provide telnet, simple browser, and maybe email clients or IRC.


Progress


June 10, 2005 - Since I haven't touched this project in years, I through up a zip file of a backup of the source code from about the time of the last release.  Maybe there will be something useful in it, but there are a lot better attempts at tcp/ip available today.

November 7, 2000 - New version to download. Fix problem in PPP packet receive. Packets do not necessarily have to begin with $7E, the $7E could not be there especially when receiving multiple packets in a row. This should stop loss of lots of received packets with some ISP's.

October 29, 2000 - Finally got a chance to get my real Atari hooked back up and do some testing. I have pretty much concluded that 9600 baud is going to be tops (at least with my setup). If you try the program and get lots of long pauses and data received seems to be erratic in time, be sure you set the speed to 9600 and also issue the AT command to set to 9600 baud. At 9600 baud, I had very few problems with the program. A 14400 connect with rate set to 19200 was pretty bad. A more efficient hander with a larger recieve buffer would help. Tested config: 800XL stock system(64K), US Doubler 1050 drive (not relevant), RVerter type interface using Bobverter handler (rverter handler from Bobterm), A Zoom 56K external modem. Dialup was Earthlink (using a Sprint dialup number although I have also used Earthlink and UUNET provided POP's in the past without incident). I have received no feedback on the current version yet :-(.

October 12, 2000 - Ok, the program now downloads (or attempts to download) a web page (this one in fact) and displays the html source on the screen. I don't know how reliable it will be and would like any feedback from as many as possible. Downloads have been updated -- GO4IT.

October 8, 2000 - I got the TCP connect procedure working the past couple weeks. Spent several days tracking down a problem that was just a misplaced label I was branching to. I now have the test program sending a GET command to try to pull down by Atari page. It actually starts pulling it down (but I am not sending Acks yet so I don't get that much of the page yet) but it least I am getting close to the functionality of what the program was at one time. There will probably be no new download available until I get it to pull down the entire page and actually echo it to the screen.

September 13, 2000 - I have the first part of TCP connection establishment implemented after a few days of trying to figure out while I was not getting a response. (gee...picky servers that actually expect the tcp header size field to be set to the proper value and not zero :-) ). Hopefully things will progress a little faster now. Unfornately I will be gone next week so there will probably not be a new download for a couple of weeks (unless I accomplish something in the remainder of this week.

August 30, 2000 - Minor updates to the two program. There was one initialization function not being called for the connection phase although I am not sure it would necessarily cause any PPP negotiation problems. The program also now restores the CAPS lock state and left margin on exit.

August 25, 2000 - I finally broke down and got a real modem to hook to my real Atari and was able to test the program on the real thing. Things worked pretty much as they did under emulation which is a good thing. The connection success rate was a little lower than I seemed to get under emulation but was probably 60-70%. I will eventually work on some fine tuning and adding some retry logic to the PPP connection routines. Pings to 127.0.0.1 were around 3/60th second. Pings to my own IP (two round trips to first router) were around 1 second. Pings to a couple of sites and my cable modem (completely different ISP) were less than 500ms. All of this was with a 14.4 connection. I only had one timeout in all of the ping tests which was encouraging. I am currently working on adding back some TCP connect routines.

August 18, 2000 - I have started on the TCP layer now. I have a little code built to establish the connection but haven't tested it yet (Of course since it assembles without errors it will work :-) -- Ok, it probably won't work the first time). It will be next Tuesday before I continue work unfornately. Hopefully by then I will hear from someone who was able to establish a connection and ping something :-).

August 15, 2000 - Another new version released. This version handles loop back addresses. Packets sent to 127.x.x.x will be rerouted internally to the receive packet buffer. You can now ping 127.0.0.1 and get a really low ping.

August 13, 2000 - I now have the program set so it will relocate to memlo on whatever computer is loaded on. This will allow as much space free for programs as possible which will probably also relocate. The relocatable version is created by assembling two version of the program at start address that differs by 256 bytes (It also loads at an even page boundry to make things simpler). A program then diffs the two files and generates a relocation table. A non resident relocator routines as well as the data is then added to the end of the program. All C or ASM programs built for use under the core will probably do the same. The relocation table is simple a table of offsets most all of which are one byte and length since it is actually the offset from the previous offset. There is also a prevision if there is more than a 255 byte offset is needed. New download is not yet available since there should not be any difference in operation to yesterday's release. I am now going to work on separating the terminal portion and ping programs from the core into separate loadable modules. There will be a fixed jump table somewhere (probably in Page 6) that will serve as the API.

August 12, 2000 - Finally found a temporary solution to an emulation problem I was having (aka bluescreen when start any version of Atari800 Dos). Using -nosound is a temporary fix but have no idea when things became broken. Now for the important information -- there are new versions available for download. You can now be the pinger as well as the pingee. When running the test programs, it will now let you enter an IP address to ping (numeric addresses only since DNS isn't implemented yet). You can even ping yourself if you put in the IP address it says you have. Note: 127.x.x.x is not defined to be yourself yet, doing so will probably cause the first router to ping itself and return the result to you.


FAQ


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 will currently just establish a PPP connection, say if it was successful.  It will respond to any echo requests it receives (pings).  You may press START at anytime to hangup -- Exciting huh?  There were older version still available that attempt to download and display a fixed page but they are not very robust that are no longer available.

Q. Are you going to release source code?
A. I may or may not eventually release source although I will have to be to a much further state.  Is someone else has the capability of working on the project I would release source to individuals who would want to contribute.  You would need to know assembly, know about TCP/IP, and possible about the R: device on the Atari.

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. My main eventual goal is to have a main PPP module load and run.  It would then launch other programs like the dialer and then the actual applications themselves.

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.

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?

 


Technical Information


Development tools:
Currently the assembler available in the new distribution of CC65 cross compiler is being used to compile ICE. The lastest version of CC65 has now also finally had the libraries ported back to being able to produce Atari 8-bit code so hopefully I can write some minor utilities in C that can call the core ASM routines. CC65 is available at http://www.cc65.org/. The assembler and linker in this package are very powerful and easily able to targer output files to different systems. Testing is done under a custom version of Atari800 Dos with serial port emulation and now on a REAL atari with a REAL external modem. This allows Editing in one window, comiling in another, and instant load and execution on an emulator (computer or peripheral) in another (Provided Windows 98 doesn't crash :-) )


Downloads


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 - (Should work with most national ISPs that use non-proprietary dial up programs) or you know you can use PAP protocol to authenticate.  (Note: CHAP protocol is not implemented so if your ISP only supports it you may be out of luck for now). If you do get a manual login prompt, I would recommend trying method 2 first.

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. 
5. Press START to attempt web page download. It will hopefully start scrolling up the screen. I have had test connects where it worked perfect, some with just occasional short pause. A couple other times with a really lengthy pause or a stop. Any pause longer than 30 seconds should be considered a failure. The program currently does not recognize when the connection is closed. If you see the </HTML> tag at the files end, it is the end. Press START to terminate the test.

Method 2 - (Manual login)  Use this if you normally would need a script to login.  Should work with Compuserve (Classic service) for example.  It may also work with some of the same ISPs that also use PAP in method 1.
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)
4. Type ATDTxxxxxxx and hit RETURN  xxxxxxx is your ISP phone number (you may need to type blindly, use ATDP for pulse dialing)
5. 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.
6. Answer the login and password prompts or do whatever it takes to logon.  With CompuServe I think you would answer CIS for host name, then your user PPN and password when prompted.  Then use go ppp command eventually using ! to engage PPP mode.
7. After you see the CONNECT xxxx prompt, type a ! to send the first configuration packet.  PPP mode should automatically engage. 
8. Press START to attempt web page download. It will hopefully start scrolling up the screen. I have had test connects where it worked perfect, some with just occasional short pause. A couple other times with a really lengthy pause or a stop. Any pause longer than 30 seconds should be considered a failure. The program currently does not recognize when the connection is closed. If you see the </HTML> tag at the files end, it is the end. Press START to terminate the test.

note: I recommend limiting speeds to 19200 or less (and possible even 9600).

It is possible some may need a manual login and PAP.  If so, use method 2 and answer the login/user and password prompts.

Good Luck!

Below are the current versions.  There are two builds.  One keeps a log of bytes sent and received bytes once PPP has been engaged.  After the program hangs up it will write out a log file to D:PPP.LOG of the bytes exchanged.  This can be used to determine PPP connection problems.  If you are mailing me a log (and you were using PAP authentication) you may want to search for your user name/password in hex and replace them with XX's.  Although I guarentee I would do nothing with this info, you never know if anyone else could somehow see the email -- In other word I take no responsibilities.

This version will (1) Establish a PPP connection.  (2) Will attempt to download this webpage at http://home.columbus.rr.com/ksiders/ice.htm.  (3) Allow you to ping other computers on the internet. I can run it in an emulator in one window on my PC and ping it through my cable modem in another window.  When you are done having fun, pressing Enter at the prompt and then pressing START should disconnect the session. One current flaw is that it cannot respond to a Ping request while it waiting for input. This is only because of the input line routine being used which precludes calling the HandlePackets routine. 

Click to download  tcptest.arc   8789bytes.  Last Updated 07-Nov-2000
Click to download the logging version:  tcpdebug.arc   9404 bytes.  Last Updated 07-Nov-2000.  (This version writes a log of bytes sent/received to D:PPP.LOG after hanging up)
Click to download  ICE1111.ZIP   43402 bytes.  Last Updated 07-Nov-2000, Added for download June 10, 2005.

ICE1111.ZIP

For those who care what the indicators are on the status bar (for my debugging purposes):
0-7- at far left of status bar.  Internal link status. Ranges from 0 not connected to 7
w - near left of status bar (normally not present).  Blinks on when packet is waiting to be sent.
A- spins one notch for any packet received in a call to HandlePackets
T - spins one notch for TCP packet received.
U - spins one notch for UDP packet received.
I - spins one notch for ICMP packets received (Echo Request aka a received ping is one)
R - spins one notch for any packet received of any kind even if it not for us
S - spins one notch for any packet sent by us.
B - Free buffer count.  Will range from 0 to 4 for the number of free 1K buffers available to receive packets.


Information



 TCP/IP, PPP, related links
 Commented trace of PPP negotiation phase to one of my internet connections using PAP authentication
 Commented trace of PPP negotiation phase to another one of my internet connections not needed PAP authentication


To send me e-mail please send to atari8bit AT columbus DOT rr DOT com (replacing 'AT' with '@' and 'DOT' with '.' - duh)

Hit Counter

SPAMMER Food Follows...Please Ignore
email@jrallies.com, sales@jralliers.com, support@jrallies.com, webmaster@jrallies.com, improvements@jrallies.com, help@franchisesolutions.com, fitness789@mailcity.com, bfreen629@mailcity.com,
abuse@popsite.net, postmaster@popsite.net