XMODEM - Knowledge

36: 199:(BBS) market, largely because it was simple to implement. It was also fairly inefficient, and as modem speeds increased, this problem led to the development of a number of modified versions of XMODEM to improve performance or address other problems with the protocol. Christensen believed his original XMODEM to be "the single most modified program in computing history". 921:

protocol. Forsberg suggested that the various improvements were optional, expecting software authors to implement as many of them as possible. Instead, they generally implemented the bare minimum, leading to a profusion of semi-compatible implementations, and eventually, the splitting out of the name

426:

XMODEM was designed for simplicity, without much knowledge of other file transfer protocols – which were fairly rare anyway. Due to its simplicity, there were a number of very basic errors that could cause a transfer to fail, or worse, result in an incorrect file which went unnoticed by the protocol.

683:

A number of new versions of XMODEM were introduced in order to address these problems. Like earlier extensions, these versions tended to be backward-compatible with the original XMODEM, and like those extensions, this led to further fracturing of the XMODEM landscape in the user's terminal emulator.

894:

Another way to solve the throughput problem is to increase the packet size. Although the fundamental problem of latency remains, the speed at which it becomes a problem is higher. XMODEM-1K with 1024-byte packets was the most popular such solution. In this case, the throughput at 9600 bit/s is

457:

Another problem with XMODEM was that it required the transfer to be user-driven rather than automated. Typically this meant the user would navigate on the sender's system to select the file they wanted, and then use a command to put that system into the "ready to send" mode. They would then trigger

332:

was sent by the receiver. This was a logical outcome of the way the user interacted with the sending machine, which would be remotely located. The user would navigate to the requested file on the sending machine, and then ask that machine to transfer it. Once this command was issued, the user would

815:

every four packets makes the system work like it has a packet size of 512 bytes, but in the case of an error, typically only requires 128 bytes to be re-sent. Moreover, it reduces the amount of data flowing in the reverse direction by four times. This is of little interest in the typical

670:

process was a fixed function of the underlying communications network, not of the performance of the modems. As modem speeds increased, the fixed delay grew in proportion to time needed to send the packet. For instance, at 2400 bit/s the packets took only 0.55 seconds to send, so if the

597:

in place of the 8-bit checksum. CRCs encode not only the data in the packet, but its location as well, allowing it to notice the bit-replacement errors that a checksum would miss. Statistically, this made the chance of detecting an error less than 16 bits long 99.9969%, and even higher for longer

746:

in front of them, and then modifying the character by XORing it with 64. In theory, this meant the packet might be as long as 264 bytes if it originally consisted entirely of characters that required escaping. These inserted and modified characters are not part of the CRC calculation, they are

636:

To avoid the delay, the sender and receiver would generally list XMODEM-CRC separately from XMODEM, allowing the user to select "basic" XMODEM if the sender didn't explicitly list it. To the average user, XMODEM-CRC was essentially a "second protocol", and treated as such. This was not true of

264:

character sent after the last block. This character was not in a packet, but sent alone as a single byte. Since the file length was not sent as part of the protocol, the last packet was padded out with a "known character" that could be dropped. In the original specification, this defaulted to

653:

message from the receiver, it tended to be quite slow. In the era of 300 bit/s modems, the entire 132-byte packet required 4.4 seconds to send (132 bytes * (8 bits per byte + 1 start bit + 1 stop bit) / 300 bits per second). Assuming it takes 0.2 seconds for the receiver's

882:

character that WXmodem had re-purposed. On top of these changes, it added an "Overdrive" mode for half duplex links. This suppressed ACKs for packets that were successfully transferred, in effect making the window of infinite size. This mode was indicated by a flag in the zero block.

192:" that are sent to the receiver, along with additional information allowing the receiver to determine whether that packet was correctly received. If an error is detected, the receiver requests that the packet be re-sent. A string of bad packets causes the transfer to abort. 333:

then execute a command in their local software to start receiving. Since the delay between asking the remote system for the file and issuing a local command to receive was unknown, XMODEM allowed up to 90 seconds for the receiver to begin issuing requests for data packets.

444:

It was a quick hack I threw together, very unplanned (like everything I do), to satisfy a personal need to communicate with some other people. ONLY the fact that it was done in 8/77, and that I put it in the public domain immediately, made it become the standard that it

561:

A normal XMODEM implementation would simply discard the packet, the assumption being that the packet number had been corrupted. But this led to a potential time delay if the packet were discarded, as the sender could not tell whether the receiver had responded with a

320:

The block numbers were also examined in a simple way to check for errors. After receiving a packet successfully, the next packet should have a one-higher number. If it instead received the same block number this was not considered serious, it was implied that the

934:

protocol developed by L. B. Neal, who released it in 1990. NMODEM is essentially a version of XMODEM-CRC using larger 2048 byte blocks, as opposed to XMODEM's 128 byte blocks. NMODEM was implemented as a separate program, written in Turbo Pascal 5.0 for the

461:

For automated transfers between two sites, a number of add-ons to the XMODEM protocol were implemented over time. These generally assumed the sender would continue sending file after file, with the receiver attempting to trigger the next file by sending a

448:...People who suggest I make SIGNIFICANT changes to the protocol, such as 'full duplex', 'multiple outstanding blocks', 'multiple destinations', etc etc don't understand that the incredible simplicity of the protocol is one of the reasons it survived. 236:

character, a "block number" from 1-255, and the "inverse" block number—255 minus the block number. Block numbering starts with 1 for the first block sent, not 0. The header was followed by the 128 bytes of data, and then a single-byte

435:

Many authors introduced extensions to XMODEM to address these and other problems. Many asked for these extensions to be included as part of a new XMODEM standard. However, Ward Christensen refused to do this, as it was precisely the

281:

Files were transferred one packet at a time. When received, the packet's checksum was calculated by the receiver and compared to the one received from the sender at the end of the packet. If the two matched, the receiver sent an

512:

to arrive, so the characters would not be echoed and the implementation could fall back to conventional XMODEM. With "aware" software, the file name could be used to save the file locally. Transfers could continue with another

624:

character would be lost or corrupted, it could not be assumed that the receiver did not support XMODEM-CRC if the first attempt to trigger the transfer failed. The receiver thus tried to start the transfer three times with

679:

still took 0.2 seconds to make it back to the user's machine, the efficiency has fallen to 71%. At 9600 bit/s it is just under 40% – more time is spent waiting for the reply than is needed to send the packet.

977:

as soon as the packet started, in the same fashion as the Telebit modems. Since this feature is only an alteration of the receiver-side behavior, it does not require any changes in the protocol on the sender's side.

658:

to make it back to the sender and the next packet to start hitting the receiver (0.1 seconds in both directions), the overall time for one packet would be 4.6 seconds, just over 92% channel efficiency.

431:

bits are reversed, which can happen with a suitably short burst of noise. Additionally, similar damage to the header or checksum could lead to a failed transfer in cases where the data itself was undamaged.

508:. Each character was sent individually and had to be echoed by the receiver as a form of error correction. For a non-aware XMODEM implementation, this data would simply be ignored while it waited for the 858:

One difference is that SEAlink supported the "zero packet" introduced by TeLink, which is needed in order to operate as a drop-in replacement for TeLink in FidoNet systems where the header was expected.

886:

SEAlink later added a number of other improvements and was a useful general-purpose protocol. However, it remained rare outside the FidoNet world, and was rarely seen in user-facing software.

910:. Like other backward-compatible XMODEM extensions, it was intended that a -1K transfer could be started with any implementation of XMODEM on the other end, backing off features as required. 269:

or 26 decimal, which CP/M used as the end-of-file marker inside its own disk format. The standard suggested any character could be used for padding, but there was no way for it to be changed

369:

character. These characteristics were transplanted directly into XMODEM. However, other operating systems did not feature either of these peculiarities, and the widespread introduction of

878:

SEAlink was not expected to operate over X.25 or similar links, and thus did not perform escaping. This was also needed so the zero packet would work properly, as this standard used the

185:. It allowed users to transmit files between their computers when both sides used MODEM. Keith Petersen made a minor update to always turn on "quiet mode", and called the result XMODEM. 1390: 962:". This is normally accomplished in the link hardware, notably Telebit modems. The modems, when the option was turned on, would notice the XMODEM header and immediately sent an 966:. This would cause the sending XMODEM program to immediately send the next packet, making the transfer continuous, like an infinite-sized window. The modems also suppress the 875:, then the packet number, then the complement of the packet number, in the same fashion as the original XMODEM packet header. The window size was normally set to six packets. 558:. The packet contained the file creation date and time, filename up to 16 characters, the file size as a 4-byte value, and the name of the program sending the file. 531:

MODEM7 sent the filename as normal text, which meant it could be corrupted by the same problems that XMODEM was attempting to avoid. This led to the introduction of

1496: 458:

the transfer from their end using a command in their terminal emulator. If the user wanted to transfer another file, they would have to repeat this process again.

985:

This concept should be contrasted with the one used in SEAlink, which changes the behavior on both sides of the link. In SEAlink, the receiver stops sending the

406:

indicated the sender wished to cancel the transfer. However, this character could be easily "created" via simple noise-related errors of what was meant to be an

546:

TeLink avoided MODEM7's problems by standardizing a new "zero packet" containing information about the original file. This included the file's name, size, and

273:

itself – if an implementation changed the padding character, only clients using the same implementation would correctly interpret the new padding character.

1383: 1032:... but the protocol itself was long ago placed in the public domain by its creator, Chicagoan Ward Christensen. Since its introduction in 1978, XMODEM ... 570:

software, which demanded it as part of the FidoNet standards, this did not present a real-world problem as both ends would always support this standard.

973:

The system can also be implemented in the protocol itself, and variations of XMODEM offered this feature. In these cases, the receiver would send the

958:

Over reliable (error-free) connections, it is possible to eliminate latency by "pre-acknowledging" the packets, a technique known more generally as "

609:

to start the transfer. If the sender responded by sending a packet, it was assumed the sender "knew" XMODEM-CRC, and the receiver continued sending

589:

The checksum used in the original protocol was extremely simple, and errors within the packet could go unnoticed. This led to the introduction of

1376: 290:

message back to the sender, which then sent the next packet in sequence. If there was a problem with the checksum, the receiver instead sent a

550:, which were placed in a regular 128 byte XMODEM block. Whereas a normal XMODEM transfer would start with the sender sending "block 1" with a 1472: 695:, short for "Windowed Xmodem", is a variant of XMODEM developed by Peter Boswell in 1986 for use on high-latency lines, specifically public 1491: 1110: 325:

had not been received by the sender, which had then re-sent the packet. Any other packet number signalled that packets had been lost.

1335: 79: 57: 302:

was received, the sender would re-send the packet, and continued to try several times, normally ten, before aborting the transfer.

922:"YMODEM" into "XMODEM-1K" and a variety of YMODEMs. Thus XMODEM-1K actually post-dates YMODEM, but remained fairly common anyway. 1221: 1083: 855:, an improved transfer protocol based on the same sliding window concept as WXmodem. It differed from WXmodem mostly in details. 427:

Most of this was due to the use of a simple checksum for error correction, which is susceptible to missing errors in the data if

1351: 1246: 489:, was the first known extension of the XMODEM protocol. A normal XMODEM file transfer starts with the receiver sending a single 309:

was also sent if the receiver did not receive a valid packet within ten seconds while still expecting data due to the lack of a

719:

will stop the data flow. Finally, in the case of an error that required a resend, it was sometimes difficult to know whether a

189: 566:

because it did not understand the zero packet or because there was a transmission error. As TeLink was normally used only by

293: 1027: 573:

The basic "block 0" system became a standard in the FidoNet community, and was re-used by a number of future protocols like

440:

of these features, and the associated coding needed to support them, which led to XMODEM's widespread use. As he explained:

1042: 629:, waiting three seconds between each attempt. This meant that if the user selected XMODEM-CRC while attempting to talk to 341:

Although XMODEM was robust enough for a journalist in 1982 to transmit stories from Pakistan to the United States with an

259: 704: 1302: 50: 44: 365:. Notably, files on CP/M were always multiples of 128 bytes, and their end was marked within a block with the 620:

Unfortunately, this attempt at backward compatibility had a downside. Since it was possible that the initial

594: 231: 523:

in 1983 described MODEM7 as "probably the most popular microcomputer communications program in existence".

1405: 98: 61: 613:'s. If no packet was forthcoming, the receiver assumed the sender did not know the protocol, and sent an 943: 285: 196: 209:

protocol, but poor implementation led to a further fracturing before they were re-unified by his later

470:

s timed out, it could be assumed that either there were no more files, or the link was broken anyway.

1055: 970:

being sent by the XMODEM software at the far end, thereby freeing up the low-speed return channel.

712: 246: 1290: 601:

XMODEM-CRC was designed to be backwardly compatible with XMODEM. To do this, the receiver sent a

250: 633:

XMODEM, as it was intended, there was a potential 10 second delay before the transfer started.

1441: 1319: 1003: 959: 936: 898:

XMODEM-1K was an expanded version of XMODEM-CRC, which indicated the longer block size in the

828:

models which have 19 kB speed in one direction and 75 bits/s in the return channel.

708: 398:

should be supported in order to easily abort the transfer from the receiving end. Likewise, a

213:

protocol. ZMODEM became very popular, but never completely replaced XMODEM in the BBS market.

171: 1421: 1286: 998: 848: 723:

was a packet indicator or more noise. WXmodem adapted XMODEM-CRC to address these problems.

362: 346: 242: 182: 175: 116: 637:

FidoNet mailers, however, where CRC was defined as the standard for all TeLink transfers.

520: 328:

Transfers were receiver-driven; the transmitter would not send any data until an initial

188:

XMODEM, like most file transfer protocols, breaks up the original data into a series of "

707:, which leads to very poor efficiency in XMODEM. Additionally, these networks often use 418:

was proposed to avoid this problem, but it is not clear if this was widely implemented.

1298: 939:

family of computers. The block size was chosen to match the common cluster size of the

914: 773: 202: 1347: 1485: 1402: 931: 167: 1068: 808:

to be sent immediately, with all packets from that number and after being re-sent.

536: 501: 1225: 1368: 821: 817: 225: 1250: 1426: 1341: 947: 913:

XMODEM-1K was originally one of the many improvements to XMODEM introduced by

700: 221:

The original XMODEM used a 128-byte data packet, the basic block size used on

547: 342: 765:

would be confused for a packet header in various error cases. An unescaped

245:

256. The complete packet was thus 132 bytes long, containing 128 bytes of

1111:"Interstellar Drives, Osborne Accessories, DEDICATE/32, and Death Valley" 716: 373:

in the early 1980s led to XMODEM having to be updated to notice either a

238: 1043:

In Focus: History lesson: Ward Christensen's free free-exchange software

554:

header, the TeLink header packet was labeled "block 0" and began with a

500:

MODEM7 changed this behavior only slightly, by sending the filename, in

1431: 1416: 852: 837: 825: 747:

removed and converted at the receiving end before calculating the CRC.

574: 567: 540: 1362: 645:

Since the XMODEM protocol required the sender to stop and wait for an

17: 1461: 1456: 1446: 1436: 1356: 1311: 979: 940: 918: 578: 370: 210: 206: 144: 1276: 349:

over poor-quality telephone lines, the protocol had several flaws.

1399: 989:

entirely, and the sender changes its behavior to not expect them.

851:

format. SEAdog included a wide variety of improvements, including

155: 228:. The packet was prefixed by a simple 3-byte header containing a 845: 696: 517:, each file is saved under the name being sent to the receiver. 358: 222: 1372: 1030:, By Alfred Glossbrenner, PC Mag, 17 April 1984, Page 451-452, 241:. The checksum was the sum of all 128 data bytes in the packet 317:

a packet, guarding against dropped connections in mid-packet.

29: 497:

to indicate the start of the data, and then packets of data.

726:

One change was to escape a small set of control characters:

493:

character to the sender, which then starts sending a single

1338:, original source code, Ward Christensen, October 10, 1977. 867:

s were extended to three-byte "packets", starting with the

776:

to improve throughput on high-latency links. To do so, the

1350:, June 18, 1988 (document reformatted October 14, 1988) 1204: 1202: 1200: 1198: 1185: 1183: 1181: 1179: 1177: 1175: 1173: 780:

messages were followed by the packet number they were

1357:

XMODEM / XMODEM-CRC / WXMODEM File Transfer Protocols

1312:"XMODEM, CRC XMODEM, WXMODEM File Transfer Protocols" 1136: 1134: 1132: 800:

with the fourth packet sequence number is assumed to

1348:

XMODEM / YMODEM Protocol Reference by Chuck Forsberg

1342:

XMODEM / YMODEM Protocol Reference by Chuck Forsberg

703:. These have latencies that are far higher than the 205:

collected a number of common modifications into his

1045:, By Michael Swaine, InfoWorld, 1 Nov 1982, Page 26 151: 140: 122: 112: 104: 684:In the end, dozens of versions of XMODEM emerged. 844:, written by the same author as the then-popular 313:character. A seven-second timeout was also used 750:Additionally, all packets were prefixed with a 466:as normal at the start of a transfer. When the 1028:Telecommunications: XMODEM: A Standard Is Born 754:character, which meant the packet lead-in was 386:For some time it was suggested that sending a 1384: 950:, making buffering data for writing simpler. 836:One of the first third-party mailers for the 195:XMODEM became extremely popular in the early 8: 1363:Adontec XMODEM/32k and XMODEM/64k extensions 796:any number between one and four packets. An 772:The major change in WXMODEM is the use of a 769:found in the body of a packet was an error. 92: 1152: 1391: 1377: 1369: 895:81%, given the same assumptions as above. 617:to start a "traditional" XMODEM transfer. 361:machines, and bears several marks of that 91: 80:Learn how and when to remove this message 1164: 43:This article includes a list of general 1208: 1189: 1020: 1497:Computer-related introductions in 1977 256:The file was marked "complete" with a 1473:Comparison of file transfer protocols 1222:"NMODEM 1.12 program and source code" 7: 1140: 804:all four packets. An error causes a 742:. These were escaped by inserting a 1324:(Technical report). 24 August 1987. 1278:FidoNet Technical Standard FTS-0001 788:ing. The receiver does not have to 761:, reducing the chance that a stray 605:(capital C) character instead of a 593:by John Byrns, which used a 16-bit 1303:"XMODEM/YMODEM PROTOCOL REFERENCE" 49:it lacks sufficient corresponding 25: 1275:Bush, Randy (30 September 1995). 1084:"Osborne—Behind Guerrilla Lines" 34: 1352:(HTML version with text issues) 1310:Boswell, Peter (20 June 1986). 820:operation, but is important in 792:every packet; it is allowed to 1321:SEALINK File Transfer Protocol 1109:Pournelle, Jerry (July 1983). 902:by starting a packet with the 170:protocol developed as a quick 1: 946:file system on contemporary 1492:BBS file transfer protocols 705:plain-old telephone service 383:as the end-of-file marker. 128:; 47 years ago 1513: 1291:"XMODEM Protocol Overview" 1082:Kline, David (July 1982). 1470: 1412: 715:and other tasks, notably 539:, author of the original 402:received in place of the 97: 982:formalized this system. 390:character instead of an 1069:"The Virtual Community" 357:XMODEM was written for 64:more precise citations. 1247:"NMODEM documentation" 108:file transfer protocol 99:Communication protocol 27:File transfer protocol 1301:(11 September 1986). 906:character instead of 197:bulletin board system 178:for use in his 1977 1281:(Technical report). 598:error bit strings. 504:format, before the 271:within the protocol 94: 1344:, October 10, 1985 1289:(1 January 1982). 1058:, 25 November 1992 1054:Ward Christensen, 709:control characters 251:channel efficiency 1479: 1478: 1287:Christensen, Ward 1004:Kermit (protocol) 960:protocol spoofing 954:Protocol spoofing 937:IBM PC compatible 662:The time for the 641:Higher throughput 161: 160: 90: 89: 82: 16:(Redirected from 1504: 1393: 1386: 1379: 1370: 1325: 1315: 1306: 1294: 1282: 1262: 1261: 1259: 1258: 1249:. Archived from 1243: 1237: 1236: 1234: 1233: 1224:. Archived from 1218: 1212: 1206: 1193: 1187: 1168: 1162: 1156: 1153:Christensen 1982 1150: 1144: 1138: 1127: 1126: 1124: 1122: 1106: 1100: 1099: 1097: 1095: 1090:. pp. 42–50 1079: 1073: 1072: 1065: 1059: 1052: 1046: 1040: 1034: 1025: 999:BLAST (protocol) 988: 976: 969: 965: 881: 874: 870: 866: 862: 849:data compression 814: 807: 803: 799: 795: 791: 787: 783: 779: 768: 764: 760: 757: 753: 745: 741: 737: 733: 729: 722: 565: 557: 553: 516: 511: 496: 492: 481:, also known as 469: 465: 363:operating system 347:acoustic coupler 277:Transfer details 217:Packet structure 183:terminal program 176:Ward Christensen 136: 134: 129: 117:Ward Christensen 95: 85: 78: 74: 71: 65: 60:this article by 51:inline citations 38: 37: 30: 21: 1512: 1511: 1507: 1506: 1505: 1503: 1502: 1501: 1482: 1481: 1480: 1475: 1466: 1408: 1397: 1332: 1318: 1309: 1299:Forsberg, Chuck 1297: 1285: 1274: 1271: 1266: 1265: 1256: 1254: 1245: 1244: 1240: 1231: 1229: 1220: 1219: 1215: 1207: 1196: 1188: 1171: 1163: 1159: 1151: 1147: 1139: 1130: 1120: 1118: 1108: 1107: 1103: 1093: 1091: 1081: 1080: 1076: 1067: 1066: 1062: 1053: 1049: 1041: 1037: 1026: 1022: 1017: 1012: 995: 986: 974: 967: 963: 956: 928: 909: 905: 892: 879: 872: 868: 864: 860: 834: 812: 805: 801: 797: 793: 789: 785: 781: 777: 766: 762: 758: 755: 751: 743: 739: 735: 731: 727: 720: 690: 678: 674: 669: 665: 657: 652: 648: 643: 628: 623: 616: 612: 608: 604: 587: 563: 555: 551: 529: 521:Jerry Pournelle 514: 509: 507: 494: 490: 476: 467: 463: 455: 453:Batch transfers 424: 417: 413: 409: 405: 401: 397: 393: 389: 382: 376: 368: 355: 339: 331: 324: 312: 308: 301: 297: 289: 279: 268: 263: 235: 219: 132: 130: 127: 86: 75: 69: 66: 56:Please help to 55: 39: 35: 28: 23: 22: 15: 12: 11: 5: 1510: 1508: 1500: 1499: 1494: 1484: 1483: 1477: 1476: 1471: 1468: 1467: 1465: 1464: 1459: 1454: 1449: 1444: 1439: 1434: 1429: 1424: 1419: 1413: 1410: 1409: 1398: 1396: 1395: 1388: 1381: 1373: 1367: 1366: 1360: 1354: 1345: 1339: 1331: 1330:External links 1328: 1327: 1326: 1316: 1307: 1295: 1283: 1270: 1267: 1264: 1263: 1238: 1213: 1194: 1169: 1157: 1145: 1143:, p. G.1. 1128: 1101: 1088:Microcomputing 1074: 1060: 1047: 1035: 1019: 1018: 1016: 1013: 1011: 1008: 1007: 1006: 1001: 994: 991: 955: 952: 927: 924: 915:Chuck Forsberg 907: 903: 891: 888: 833: 830: 774:sliding window 689: 686: 676: 672: 667: 663: 655: 650: 646: 642: 639: 626: 621: 614: 610: 606: 602: 586: 583: 528: 525: 505: 475: 472: 454: 451: 450: 449: 446: 423: 422:Major problems 420: 415: 411: 407: 403: 399: 395: 391: 387: 380: 374: 366: 354: 353:Minor problems 351: 338: 335: 329: 322: 310: 306: 299: 291: 283: 278: 275: 266: 257: 253:of about 97%. 249:, for a total 229: 218: 215: 203:Chuck Forsberg 159: 158: 153: 149: 148: 142: 138: 137: 124: 120: 119: 114: 110: 109: 106: 102: 101: 88: 87: 42: 40: 33: 26: 24: 14: 13: 10: 9: 6: 4: 3: 2: 1509: 1498: 1495: 1493: 1490: 1489: 1487: 1474: 1469: 1463: 1460: 1458: 1455: 1453: 1450: 1448: 1445: 1443: 1440: 1438: 1435: 1433: 1430: 1428: 1425: 1423: 1420: 1418: 1415: 1414: 1411: 1407: 1404: 1403:file transfer 1401: 1394: 1389: 1387: 1382: 1380: 1375: 1374: 1371: 1365:, adontec.com 1364: 1361: 1359:, synchro.net 1358: 1355: 1353: 1349: 1346: 1343: 1340: 1337: 1334: 1333: 1329: 1323: 1322: 1317: 1314:. CRC XMODEM. 1313: 1308: 1304: 1300: 1296: 1292: 1288: 1284: 1280: 1279: 1273: 1272: 1268: 1253:on 2016-04-09 1252: 1248: 1242: 1239: 1228:on 2011-08-07 1227: 1223: 1217: 1214: 1210: 1205: 1203: 1201: 1199: 1195: 1191: 1186: 1184: 1182: 1180: 1178: 1176: 1174: 1170: 1166: 1165:Forsberg 1986 1161: 1158: 1154: 1149: 1146: 1142: 1137: 1135: 1133: 1129: 1117:. p. 334 1116: 1112: 1105: 1102: 1089: 1085: 1078: 1075: 1070: 1064: 1061: 1057: 1051: 1048: 1044: 1039: 1036: 1033: 1029: 1024: 1021: 1014: 1009: 1005: 1002: 1000: 997: 996: 992: 990: 983: 981: 971: 961: 953: 951: 949: 945: 942: 938: 933: 932:file transfer 925: 923: 920: 916: 911: 901: 896: 889: 887: 884: 876: 856: 854: 850: 847: 843: 839: 831: 829: 827: 824:systems like 823: 819: 811:Requiring an 809: 775: 770: 748: 724: 718: 714: 710: 706: 702: 698: 694: 687: 685: 681: 660: 640: 638: 634: 632: 618: 599: 596: 592: 584: 582: 580: 576: 571: 569: 559: 549: 544: 542: 538: 534: 526: 524: 522: 518: 503: 498: 488: 484: 480: 473: 471: 459: 452: 447: 443: 442: 441: 439: 433: 430: 421: 419: 384: 379: 372: 364: 360: 352: 350: 348: 344: 336: 334: 326: 318: 316: 303: 295: 287: 276: 274: 272: 261: 254: 252: 248: 244: 240: 233: 227: 224: 216: 214: 212: 208: 204: 200: 198: 193: 191: 186: 184: 181: 177: 173: 169: 168:file transfer 165: 157: 154: 150: 147:, many others 146: 143: 139: 125: 121: 118: 115: 111: 107: 103: 100: 96: 84: 81: 73: 63: 59: 53: 52: 46: 41: 32: 31: 19: 1451: 1320: 1277: 1269:Bibliography 1255:. Retrieved 1251:the original 1241: 1230:. Retrieved 1226:the original 1216: 1209:SEAlink 1987 1190:Boswell 1986 1160: 1148: 1119:. Retrieved 1114: 1104: 1092:. Retrieved 1087: 1077: 1063: 1050: 1038: 1031: 1023: 984: 972: 957: 930:NMODEM is a 929: 912: 899: 897: 893: 885: 877: 857: 841: 835: 810: 771: 749: 725: 713:flow control 699:systems and 692: 691: 682: 661: 644: 635: 630: 619: 600: 590: 588: 572: 560: 545: 537:Tom Jennings 532: 530: 519: 502:8.3 filename 499: 487:Batch XMODEM 486: 483:MODEM7 batch 482: 478: 477: 460: 456: 437: 434: 428: 425: 385: 377: 356: 340: 327: 319: 314: 304: 280: 270: 255: 247:payload data 226:floppy disks 220: 201: 194: 187: 179: 166:is a simple 163: 162: 123:Introduction 113:Developer(s) 76: 70:January 2009 67: 48: 1094:15 February 948:hard drives 908:<SOH> 904:<STX> 840:system was 822:half duplex 818:full duplex 677:<NAK> 673:<ACK> 668:<NAK> 664:<ACK> 656:<ACK> 651:<NAK> 647:<ACK> 615:<NAK> 607:<NAK> 564:<NAK> 556:<SYN> 552:<SOH> 515:<NAK> 506:<SOH> 416:<CAN> 414:. A double- 412:<NAK> 408:<ACK> 404:<SOH> 400:<CAN> 396:<NAK> 392:<ACK> 388:<CAN> 381:<EOF> 375:<EOT> 367:<EOT> 330:<NAK> 323:<ACK> 311:<EOT> 307:<NAK> 300:<NAK> 267:<SUB> 62:introducing 1486:Categories 1427:B protocol 1257:2020-02-13 1232:2020-02-13 1056:"Memories" 1010:References 701:PC Pursuit 591:XMODEM-CRC 585:XMODEM-CRC 141:Influenced 45:references 1406:protocols 1336:MODEM.ASM 1141:Bush 1995 1121:28 August 1015:Citations 890:XMODEM-1K 548:timestamp 543:mailers. 343:Osborne 1 180:MODEM.ASM 993:See also 816:modem's 717:XON/XOFF 337:Problems 239:checksum 152:Hardware 1432:HS/Link 1417:BiModem 917:in his 853:SEAlink 838:FidoNet 832:SEAlink 826:Telebit 784:ing or 693:WXmodem 688:WXModem 575:SEAlink 568:FidoNet 541:FidoNet 298:. If a 190:packets 131: ( 105:Purpose 58:improve 1462:ZMODEM 1457:YMODEM 1452:XMODEM 1447:SMODEM 1442:Kermit 1437:JMODEM 980:YMODEM 941:MS-DOS 926:NMODEM 919:YMODEM 900:sender 863:s and 842:SEAdog 579:YMODEM 533:TeLink 527:TeLink 479:MODEM7 474:MODEM7 371:MS-DOS 315:within 243:modulo 211:ZMODEM 207:YMODEM 164:XMODEM 156:modems 145:YMODEM 93:XMODEM 47:, but 18:XModem 1422:BLAST 1400:Modem 445:is... 1123:2016 1115:BYTE 1096:2016 846:.arc 738:and 736:XOFF 711:for 697:X.25 577:and 438:lack 359:CP/M 345:and 296:> 292:< 288:> 284:< 262:> 258:< 234:> 230:< 223:CP/M 172:hack 133:1977 126:1977 987:ACK 975:ACK 968:ACK 964:ACK 944:FAT 880:SYN 873:NAK 871:or 869:ACK 865:NAK 861:ACK 813:ACK 806:NAK 802:ACK 798:ACK 794:ACK 790:ACK 786:NAK 782:ACK 778:ACK 767:SYN 763:SOH 759:SOH 756:SYN 752:SYN 744:DLE 740:SYN 732:XON 728:DLE 721:SOH 649:or 631:any 595:CRC 535:by 510:SOH 495:SOH 491:NAK 485:or 468:NAK 464:NAK 429:two 410:or 394:or 294:NAK 286:ACK 260:EOT 232:SOH 174:by 1488:: 1197:^ 1172:^ 1131:^ 1113:. 1086:. 734:, 730:, 581:. 378:or 305:A 1392:e 1385:t 1378:v 1305:. 1293:. 1260:. 1235:. 1211:. 1192:. 1167:. 1155:. 1125:. 1098:. 1071:. 675:/ 666:/ 627:C 622:C 611:C 603:C 135:) 83:) 77:( 72:) 68:( 54:. 20:)

Text is available under the Creative Commons Attribution-ShareAlike License. Additional terms may apply.

Index