Bulletins from the Pacific Packet Radio Society - page 102

packet is sent, so such editing is unreliable when the timeout is s e t. This is usually OK if the remote system also implements simple backspace (or delete) editing. I don't know if TIP accepts both to do the same thing; it should. It should also transmit them if they are keyed at the beginning of a buffer (with no chars keyed) incase the previously sent text is now being rubbed out. Probably the timeout set by the user is good enough to kick out these rubouts from the input buffer; they don't need to be expedited.

| The second thing to consider is that, on very brief reading, your new format for headers does NOT make forwarding via a repeater transparent, possibley losing the ability to forward thru multiple repeaters, since al (all) packets transmitted from repeater A to repeater B, no matter who they are ultimately for, must be sent with "All and "B" in their fields. This takes up further space in, and requires, a higher level protocol to deal with routing. I suppose it's a good first step, I just hate to think of changing all those proms again later. Can you put a few RAM hooks into the system? That is, indirect subroutine calls thru a transfer vector in RAM which the ROM sets up at RESET and which can be patched to cause new things to occur, at those particular points in the processing that we thought of BEFORE we burned the ROMS. The corollary is a patch facility, which I think can safely require a computer on the other end (use binary images instead of typing in hex or something, for ease of implementation). Two commands would be required, one (probably -followed by some control character) which would begin a download from the terminal side, follwed by a 1-byte length, 2-byte address, and n-byte data, followed by normal text. The length is limited to 31 bytes so that if the user accidentally invokes this command, the length they supply would probably be invalid, if it was a space or alphabetic. The second command would enable (--d for lack of a "TIP Reference card" to pick an unassigned letter) or disable (--nd) downloading of packets with patches in them. A particular packet "Protocol" field, say 1, would invoke the patch code. The information field of the packet would contain an address, data, and checksum (simple 8 bit sum) of the patch. Checksum prevents random packets which are not truly intended as patch packets from passing . The data is just moved directly from the packet buffer into the specified destination. Care must be taken to move only the exact number of bytes specified, so it can be used to make "delicate" patches of 1 or 2 bytes in transfer vectors. The default state of the TIP/LIP should permit downloading; the repeater can be programmed at some point to periodically or on request transmit the current set of patches to implement the next level of protocol we design, and these can run ' out of RAM on systems with old proms.

The transfer vector entries I can think of are:

Packet Received from 8273 in good shape

Packet ready to transmit to 8273 (with buffer space available to move it around, if it needs expanding. This probably means "Not in the interrupt routine").

Click for Original Graphic Image of this page.