|
What is the TCPIP99 project? |
|
|
|
The TCPIP99 project is aimed towards providing Internet access capability to the TI and Geneve. Every communication on the Internet is based on one single protocol family. This family is sometimes refered to as the TCP/IP stack although there are other protocols involved besides TCP and IP. The basic idea of this protocol family is that different protocols are stacked with protocols of the same layer being able to communicate with each other. The TCP/IP project involves the design of several protocol implementations to provide a minimum functionality to process these protocol messages. In order to actively take part in the Internet, applications have to be written that utilize this protocol stack. |
|
|
|
|
Do you think you'll ever get your TI on the Internet? LOL! |
|
|
|
Of course, no joke. The TCP/IP standards do not require any processing speed by the sender or the receiver. It is possible to connect to the Internet at any baud rate (although 300 bps should not be much fun) if the peer modem accepts the connection rate. It is not a question of speed but rather of memory that is a little limited. Anyway, we only need a very basic set of features: We won't use our TI as a gateway, and it will certainly never get an Ethernet card but stay with its RS232 modems. |
|
|
|
|
What programming language are you using? |
|
|
|
I'm using TMS9900 assembler. I avoid using TMS9995-specific features so that the portability to the TI is ensured. Therefore, I'm using the GPL mode of the Geneve. |
|
|
|
|
Why don't you use C? |
|
|
|
For the TI and Geneve there are two C compilers, c99 and TIC. Both do quite a good job. However, I need to do a lot of optimizations:
|
|
|
|
|
Why don't you re-use already existing implementations, e.g. from Linux? |
|
|
|
As I said above, I have to use TMS9900 assembler. Existing implementations are written in C. I'm sure it will definitely take more time to figure out how to convert the C program structures to assembler than the complete redesign. |
|
|
|
|
You're using a Geneve. Will it also run on the plain TI-99/4A? |
|
|
|
Hard to say from here. I would guess no. Sorry. It is mainly a matter of available memory and of processor speed. If you own an appropriately expanded TI (more memory, faster processor), the odds are much, much better. Although I said that speed does not matter, we should take into account that some service providers probably limit the minimum connect rate. We should be well off with 14400 bps, and I hope the Geneve will do it (mine already did the 9600 bps without dropouts), but I don't know what can be expected from the TI. |
|
|
|
|
Can I use the TI/Geneve to download files from the Internet? |
|
|
|
At first, no. This holds for all questions of this kind. When we have a working TCP/IP stack, we must write applications that utilize the stack. For example, someone could write an FTP client. (No, not me again.) If that is done --- yes, you can download files from any FTP server right on your TI/Geneve. That means we do not need shell accounts or BBS anymore. Some files, however, are stored under HTTP addresses. That requires some kind of browser (see below). |
|
|
|
|
Can I use the TI/Geneve to read my e-Mails? |
|
|
|
If anyone writes an ELM clone or a similar tool, of course. Provided that the TCP/IP stack already works. |
|
|
|
|
Can I use the TI/Geneve to read news in the USENET? |
|
|
|
Again: If the TCP/IP stack is working and someone writes a news client, that should not pose a problem. In this case we could be able to transfer some communication to the comp.sys.ti newsgroup that suffers a little from the listserver that sucks away the traffic from it. |
|
|
|
|
Can I use the TI/Geneve to surf the web? |
|
|
|
Oh dear. That depends on what you understand by surfing.
|
|
|
|
|
How will it look like when TCP/IP is running on the TI? Is it some sort of a operating system extension? |
|
|
|
You'll probably have already noticed that neither the TI nor the Geneve operating systems are easy to extend. In this case, a simple extension like on the PC operating systems where you just don't notice if you're connected or not, is impossible. This is mainly due to all these optimizations and interrupt problems. This means the TCP/IP routines have to be integral parts of the mail, news, FTP applications that we have to write. If we're lucky, we can write some sort of shell where the TCP/IP part is shared between applications that can be loaded and removed at run-time. |
|
|
|
|
What do you think are the most difficult problems to solve? |
|
|
|
The really hard problem is to plan the size and optimal utilization and allocation of buffers. If we need more than 64K, we'll have to do some sophisticated banking. The next problem is the interrupt routine. I'm using the Circular Input Buffer to receive the data; when interrupts are blocked (and be it only for a short time), bytes are lost, invalidating the whole data block. To give you an idea: I just used the VMBR/VMBW routine to do some scrolling screen output from my PING server. If you read or write more than 100 bytes (!) to/from the video buffer, data will be lost. (Was some kinda shock for me, to tell the truth.) Therefore, I cannot use the output routine from the RS232 DSR either: It blocks interrupts. We'll have to use a different module for each different interface card. And then: What shall we do with the downloaded data? When we save it, a lot of incoming data will be discarded in the meantime. In the best case, the data will be resent (according to the standards). In the worst case, the connection will break up. |
|
|
|
|
Why are you using that slow Circular Input Buffer? |
|
|
|
The interrupt-driven reception of data is not that slow. It works flawlessly even with 9600 bps. Unlike common terminal emulators, a TCP/IP stack must always be ready to receive data unattendedly. Even if you're typing at the moment. Furthermore, if I wanted to use polling I'd have to include the subroutine call in every single upper-layer routine at many, many points. This will be very tedious. |
|
|
|
|
How far have you come with the implementation? |
|
|
|
I wish I'd have come farther. Up to now, the SLIP driver is ready and is indeed able to communicate with its Linux or OS/2 SLIP peer. The SLIP driver is the low-level driver and the first to get the data from the interface. Then, the IP driver is partially functional: It can detect checksum errors and call the appropriate upper-layer routines. The ICMP driver can correctly answer to PING requests: I managed to write a PING server on the Geneve which means I could enter a PING command on my PC, and the Geneve responded. And no packet was lost! I have prepared a module that can do packet reassembly which is required for an IP driver implementation, but it is not yet included, and this will involve more than a simple line merge. |
|
|
|
|
How many people are involved in the development? |
|
|
|
There are some people that expressed their interest in participating in the development. However, at this time, the implementation has not matured far enough so that several people could work at it simultaneously. I hope that when I complete the work on the IP driver and probably on the UDP layer, I can animate some persons to actively join me. |
|
|
|
|
How long do you think it will take until this TCP/IP implementation is available? |
|
|
|
Very hard to say. The more people help me, the faster we'll advance. After I promised to have significant progress for so many times without being able to fulfill my promises, I'll not give any promises any more. |
|
|
|
|
The project's up since 1996; why does it take that long? Have you already given up? |
|
|
|
It's crawling. Even that is exaggerated, I let it sleep for nearly all of 1998. You'll probably accept my excuse that - although I love my Geneve and I would really be glad to have this TCP/IP stack - my scientific career has definitely a higher priority. I will allocate as much time on my work as necessary. My spare time has become increasingly valuable for me, and if I tell you that my everyday work means sitting in front of a workstation doing programming and system administration, you'll understand that working on the TCP/IP stack means continuing my daily work in the evening hours and at the week-ends. But to make that clear: The TCP/IP stack for the TI/Geneve is a challenge for me, and I'll do it. I won't give up because it sounds to me as the most useful application I could ever write for my TI/Geneve. |
|
|
|
|
Do you have a communications means for the implementors? |
|
|
|
Unfortunately no, at the moment. During my time at the university I had a mailing list, but I had to abandon it after leaving the university. |
mz, 01-05-1999
