, a 16-bit bloAMCALL COM9UNLOAD COM<AUTOST COMBMCALL-C DOCUREADME DOCAMCALL HLP PHONE NUM I have found that if a cmulative total of reTXs' is kpt by both TX and RX system, then the equality of these *K͞+U'+FÎr ͖ 8{ Ăw#w#w^#V#*~#fo^#*~#fo^#V#*n^#*n^#V# ~#fo^#& ~#fo!+!#!+!#!+!+}|z{|}|z7||7zZZ)|/g}/o#|͉k|/g}/o#ɯ2qZZk:q|/g}/o#|/g}/o#:q<2qqDM!xxGyO҃)v|͔`i|)Öxڷz/W{/_ѯzW{_=yOxGæ2qZZ͉M|}ȯ|g}o)|/g}/o#z/W{/_!9~#fo! ! ! ! ! ! !9~#A"s!`*"!"!Y">2>2>22!"!"!@"!" ʞ!F#x±~#±!b2r~# "2r+}|~#G:rx"2r+w# +6#!6#2w2x*s!>r<o&F=-` r'~h6!+`W?_!~7z?` :>ª@w#G.¶ww#?*>?w#> w#.7:77!a{   `OE!y6$ -7rBo&))T])))!yR!9DM! n}&1<G!TR!ZR!`R!jRHALF FULL ECHOPLEX ??? !$'+/26:=AEHLPPUTR!9DM! n}ENEYdEoEzEʅEʐʛEʦEʱEʼ!!!!!!!!!!!! !NOP1103001504505006001200240048009600??? BAUD 3!&+05:?DILOSWZ^beimptx{PUT!9DM! 6 #6͐n*#s! ~#fo##~#fo! s#r*##6! 6! ^#Vr+sn}-͐n&ͻ|Y!0 !2  *6`i6!M *-! ^#Vr+s!|D ! ^#Vr+s~#fon}-D `in}}`i6*##6 ! ~#fo~#fo#! s#r͐n}A ͐n&ͻ>A´>G >B>S >C>_ >E>k >F>w >H>ʃ >M>ʏ >N >ʧ >O >ʳ >X >ʿ >#, > >@8 > >.D >  *63 *63 *6 3 *63 *63 *63 *60*6n3 *6@3 *63 *6P3 * 63 ! 63 !Y ͫ! ^#Vr+sn! s! n}1 3ʊ 4ʞ 5ʲ 6 ! ^#Vr+sn! s! n}1K 2_ 5s Ç *###6E*6Ç *###6*6Ç *###6E*6Ç *###6*6 *###6E*6 *###6E*6 *###6E*6  ! ^#Vr+sn&c| ! ^#Vr+s3 ͐n&! ͒! ͒! ͒! ͒ͫ! ^#Vr+sÒ;͐ +|h ! ~#fo~#fo*-w} *##6w}œ ! n&͔|ʙ  ! n&g|ʶ  *6 w} w} J | *##6! n&͔|  ! n&g|  !9 RESUME COMMUNICATIONS DEFAULT.FIL Unsupported switch '.'; baudrate fixed at 300 BAUD Unsupported switch: %c Usage: AMCALL - = {O,A;H,F,E;B,C,M,N,X;#;@;Z} *###6*6*6*6P* s* s* s*6!9DM͌p!ͷ`is{z !0!2ͫ`in} † 'v!ͷͻ`is!H`in} D F PU # !K!Mͫ[$!c*-ͮ!|$̓\$ʹ^$]$'!?ۗ$Æ !9 RETURN TO CP/M  RETURN TO CP/M ENTER .. BEGIN FILE TRANSFER !9DMDP! s#rw}*6͐ͻ>q>@>B}>Q>D‰>W>E•>]>F¡>]>G­>|>H¹>ʂ>K>ʈ>L>ʎ>N>ʝ>P>ʣ>R>ʩ>T>ʿ>U >>Z>>#%>>?1>>^=>͐! ón[!ͷͻ! s#r!1͐>D>ʴ>I™>>V¥>>±>6O*##6*6!(*6!(r"! w#w͐|!4! ! ^#Vr+s!8!b!ͷ*6!(!!S" ͫ!Z!*-ͮ!bo~5`*-\_a̓\w}0¹Güi,͝"ʹ^ͣX!!!ͫ]rA^o~"͐|*6"͐KT!(!9 . TIME OUT COMPLETED, GOTO VOICE COMM. ENTER ANY CHARACTER TO RELEASE THE LINE  RETURN TO CP/M CONTINUE COMMUNICATIONS ENTER ..>f/>B.>z/>C.>ʀ/>D/>ʋ/>E/>ʑ/>G/>ʝ/>H'/>ʣ/>K3/>ʩ/>V?/>ʯ/>WK/>/>#W/>0>^c/> 00! n&! o0́n0!2Ã-[0! 6#60b0|05`0!2! MJ! s#r͐͐/͐n&ͨ! ^#Vr+s/0! 6#60]0A^0|0b0! n}-0*6b0! n&KTw}M0w}b0! ^#Vr+s! nsÐ-w}Pz0!KT}0́n! w#w͐|0͐S|ʽ0! ^#Vr+sn&Q! w#w! ^#Vr+sÅ0͐|0!2͐! s#rMJ! s#r͐͐B1*<͐n& #|41!2͐1! ^#Vr+s0͐|ʭ1*<! *</͐|Ҋ1*-! 3͒1w}Ÿ1!#3Uç1!H311͐|1! w#w!m31w}P1!KT1! KTÃ-!"9 *** DUPLICATE FILENAME -- CREATING BACKUP *** BAK Can't create file: %s *** READY TO RECEIVE FILE *** *** READY TO RECEIVE FILE *** *** BUFFER CLEARED *** BUFFER REVIEW: *** END OF FILE *** *** Disk write error -- transfer terminated *** Can't close file: %s *** FILE TRANSFER COMPLETED *** *** FILE TRANSFER COMPLETED *** *** READY TO CONTINUE FILE TRANSFER *** !9DM!*-! s#rz3*-!x8͒!o8! w#ww! s*6!KT!8!8! ͐֙! s#r`iw#w! ^#Vr+s͐|k4͐! ͐ns`i^#Vr+s! ^#Vr+s44͐! 6! ! s#r! s#r`is#r͐n}5͐n! s! ~#fo! nѯgs#r! n&KT! n} 4! n&ۗ͐|4!.ۗ! ^#Vr+s`i^#Vr+sÒ4!KT͐ ͐V!8͸R! s{S5!8! n*s!o8! n}q5! ^#Vr+s!KT! n}w4MMJ͐! s#r!|7! w#wMJ! s#r͐͐7! 6`iw#w͐|6͐͐n! s{6͐! s6`i^#Vr+s5!KT! n&KT! s#r`is#r͐! nѯg7͐͐n! s! ~#fo! nѯgs#r! n&KT! n}ʖ6! n&ۗ! S|6! n}6! ^#Vr+s!86! n}6!8! n*s!o8IQ| 7! n*s!o8`i^#Vr+s66!KT͐ ͐V͸R! s{H7K7h7~7Ô7ò7!9! n*s!o8! ^#Vr+s!39ò7! ^#Vr+s!W9ò7! ^#Vr+s!s9!KTò7! n}6! ^#Vr+s! ~#fos#rù5|5! !KT͐KT!ͨ͸R|8!9'8!9͐!9͒! n*s͐|i8*-!:͒!o8!o8!"9 Can't open file: %s  BEGIN FILE TRANSFER *** TRANSFER TERMINATED *** *** RESYNC REQUEST *** *** TRANSFER TERMINATED *** *** TRANSFER TERMINATED *** *** RETRANSMISSION REQUEST *** *** RESYNC REQUEST *** *** IMPROPER ACKNOWLEDGMENT RECEIVED *** *** SUCCESSFUL FILE TRANSFER *** *** UNSUCCESSFUL FILE TRANSFER *** Total number of retransmissions = %3d Can't close file: %s !9DM! w#ww!# s*6! w#w͐|S*! s#r!$ w#w$S! s! s#6͐|d>$S! s{>!@!# n*s!@!$ ~#fo! nѯgs#r! n}A>! n&ۗ! ^#Vr+s! ns! ^#Vr+s=͐$ X|~>! 6#6Ì>! ^#Vr+sZ=ì=! w#w*! s#r͐! nѯg>*<͐n& ! ^#Vr+s! ^#Vr+sæ>!KT$S! s{?! A!# n*s!@! n}9?! n}9?!KT! n}O?! n}>! n}¤=!ͨ͐$S‹?!KT!/AÛ?!KT!VA͐!A͒!# n*s*<! *</͐|?*-!A͒!@!@!&9 *** TRANSFER TERMINATED *** *** TRANSFER TERMINATED *** *** TRANSFER TERMINATED *** *** DUPLICATE FILENAME -- CREATING BACKUP *** BAK.BAK Can't create file: %s *** TRANSFER TERMINATED *** *** TRANSFER TERMINATED *** *** TRANSFER TERMINATED *** *** SUCCESSFUL FILE TRANSFER *** *** UNSUCCESSFUL FILE TRANSFER *** total error count = %d Can't close file: %s !9DM!*-! s#rzA*-!E͒!Ew! s*6!FU! !͎O#|/B! n},B/B B! n}`B!F͐! n*s!E! s#r! s*Ls#r*Ns#rMMJ͐! s#r!|8E! w#wMJ! s#r͐͐5E*Lw#w!KT! 4n&KT! n}/o&&KT! ^#Vr+s͐͐!@F͒! 6`iw#w͐|C͐͐n! s! n! nѯgWs! n&KT! S|ʰC! n}°C!^F͐! n*s!EIQ|C͐! n*s!E`i^#Vr+s2C! n&|g}oKT! ! ͎O#|D! 6! n}.DeDhDʟDD*N^#Vr+s*L^#Vr+s! 5! ^#Vr+s!FDD*N^#Vr+s*L^#Vr+s! 5! ^#Vr+s!FD!F͐! n*s!E*N^#Vr+s*L^#Vr+s! 5! ^#Vr+s!FD! n}EML|B! ^#Vr+s! ~#fos#rBÉBML|lE!G͐! n*s!E!KT͒R|‹E!0GÓE!WGMN!G͒! n*s!ͨ͐|E*-!G͒!E!E!9 Can't open file: %s Awaiting initial NAK *** TIMEOUT TERMINATION *** Sending sector: %04d (%04xH) *** TRANSFER TERMINATED *** *** ACK TIMEOUT **** *** RETRANSMISSION REQUEST *** *** TRANSFER TERMINATED *** *** IMPROPER ACKNOWLEDGMENT RECEIVED *** *** TRANSFER TERMINATED *** *** SUCCESSFUL FILE TRANSFER *** *** UNSUCCESSFUL FILE TRANSFER *** Total number of retransmissions = %3d Can't close file: %s !9DMw!$ s*6!*-! s#rzڃH!?M͐*-! *-!.͇b`is#r!|ZH͐! 6!sM! VhH!wM! V! b! *-w*<*-͸! s#rzH*-!|M͒!KT!$ n*s!6M*-!M͒*Ls#r*Ns#r! s#r! s*P6#6! 6͐ ͐ !M͒NM?!& s#rMJ!" s#r! w#w!KTMP|ʋI! ! ͎O! s#rÔI͒R! s! n}¼K͒R! s͒R! s! n! nѯgW|I! n! n} J! n&! n&!M͒͐ !MN! 65L!% 6*! s#r! w#w͐|yJ͒R! s!% n! nѯgWs͐! ns! ^#Vr+s! ^#Vr+s)J!% n͒R¥K! w#w*! s#r͐|J͐"͐ns! ^#Vr+s! ^#Vr+s!" ^#Vr+sâJ! ^#Vr+s!|K͐MZKMJ! s#r͐͐"EK*<͐n& ! ^#Vr+sKMJ!" s#r! w#w*Lw#w*Pw#w! 4! ^#Vr+s͐ ͐ !N͒!KT! 6ùK͐ !"NN! 65L͐#|K! n}K! n}K͐ !3NN! 65L͐#|5L!>N*L^#Vr+s*N^#Vr+s*P6#6!KT! n}YL! n}YLML|hI͐|ڦLMJ! s#r͐͐"ҦL*<͐n& ! ^#Vr+ssL!ͨ! n}L!KT!]NL!KT!N!$ n*s*<! *</͐|'M*-!N͒MN!N͒!(9 *** DUPLICATE FILENAME -- CREATING BACKUP *** BAK.BAK Can't create file: %s Receiving file: %s Receiving sector: %04d (%04xH) sect_num = %0x, sect_cmp = %0x SECTOR NUMBER ERRORReceiving sector: %04d (%04xH) CHECKSUM FAILURESYNC ERROR *** 10 SECOND TIMEOUT *** *** SUCCESSFUL FILE TRANSFER *** *** UNSUCCESSFUL FILE TRANSFER *** Can't close file: %s total error count = %d !9DM͐!^O͒*L^#Vr+s*N^#Vr+s*P6#6! n&! n&!nO͒`i!͎O#|MO8O!KT!9 *** %s *** Receiving sector: %04d (%04xH) !9DM!?͐?|g}o?! s#r͐ S|P! ^#Vr+s!|P`iw#w͐|P!| Ps͐ 6!;P`i^#Vr+sOùO͐|/P!;P;P͐ 6!;P!9!9DM!!|aPLP!!|g}o`isw}ʌP`in&Qw}ʠPw}P`in&|P`in} P`in} P`in} P`in} P`in}P`in&Qw}Q`in} Q! Q! KT`in&Q!9!9DM! n&ۗw }GQ!! n& !!|ʀQDP|€Q!Q!KT!ÅQ! *** TRANSMISSION TERMINATED *** !9DM!͐*Ds#rzQ!*Fw#wMD!9DM*F^#Vr+sz R*H^#Vr+sn&ÉR!MJMD`is#r!|KR!ÉR͐?+*Fs#rMJ*Hs#r*H^#Vr+sn&ÉR!9!@Co|g}o|¬RÓR!Co!9DM!@Co|g}o|S!!|SDP`is{R`in}S!SR!Co|g}oS!9!9DM͸R`is{AS`in&vSw}nS`in&KT`in} nS! ۗ! KT`in&vS!9!9DM!@Co|g}o|Sw}0ºS͐!CosS͐!Co|g}os!!!9DM! 6#6͐|]`in}B\C\M\N ]X]#]*65]*6 5]*60!A]*6n5]*6@5]*6P5]!?ۗ`i62]Ï\!9 Setting UART: 8 data bits, no parity * n&|g}osw }ʕ]!]Ý]!] *** PRINTER LOGGING ON *** PRINTER LOGGING OFF * n&|g}osw }^!^^!(^ *** SCREEN ON *** *** SCREEN OFF *** * n&|g}osw }m^!w^u^!^ *** CTRL-DISPLAY ON *** *** CTRL-DISPLAY OFF *** !9DM`i6`in}M_x!ͷ`is!Y_`in}1^2 _3_4#_5/_;_*6J_*6 J_*6J_*6J_*6J_!?ۗ`i6J_^n!9 !9DM*<͐̓|Ҍ_͐!`͒_͐!`͒*<ͷ`is#r!|_͐#|_͐ۗ!|_DP|_!2`_Ú_*<-!9 Can't open file: %s Listing file: %s !9DM!a! ͮ! !*͇b|ʁa! ! s#r! !! s#r!# w#w͐n`is{xa`in}:ʥ`.`*`Ia!! ^#Vr+s`ins!# w#wja!! ^#Vr+s`ins!# 6#6ja͐#|a͐#|a!! ^#Vr+s6?!# ^#Vr+s`Fa͐#|Fa!! ^#Vr+s6?!# ^#Vr+saja!! ^#Vr+s`ins!# ^#Vr+sja! ^#Vr+sÁ`͐!6Ða! ! ! !a͒! b!a!%9 ENTER .. Enter New . OK !9DM͐ n! s#r`i6#6͐͐b! n! ^#Vr+sn}b͐b`i^#Vr+sçb!b!9!9DM!Zcsͻ`is! ͨ`in} 1c!vc! Hc!zc! `in! s! ̀c!9 DRIVE SELECT (A thru P): *.*z:*.*!9DM!B w#w̓L! \!# 6?!% s!$ s!!!A s! n}c!A n&#! s! n&+!!! |g}o|yd!!! s#r̓##n! s̓###n! s̓n! s̓~#fo! s#r̓~#fo! s#rd!= 6#6̓=~#fo4! s#r̓##n! s̓###n! s! 6̓n! s#6̓#n! s#6!!! !!F s#r̓F|f̓B|e̓F|g}o ?!; s#r! ̓;#̓Bk`i4k̓Bk`i ̓; ns̓Bk`i ̓; #ns̓Bk`i ̓;nse!l!̓B`iͫ!B `iͻg̓B|ef! !!F s#r!B ^#Vr+se̓F|4f!`g͒!l!̓B`iͫ!B `iͻg! ͨ!F w#w̓F̓BҼf! ̓B̓F̓Fk`i͞h!F ~#fo,s#rif!F s#r!? s#r̓F̓Bg!? ~#fo! ̓Fk`iIms#r!F ^#Vr+sf! n&@! }l̓B̓?!g͒!A n&!!H9 Too many entries, not all will be shownTotal of %d k in %d files. %d k left on disk %c: !9DM`iw#w! 6#6͐͐ ~#foҕh! ! ~#fo͐k! ~#fo͐k͛k|~h͐ ~#fo͐k! ~#fo͐k! ~#fo͐k|͐ ~#fo+s#rÒh`i^#Vr+s! ^#Vr+sg!9!9DM!,͐! s#r͐##+! s#r! w#w͐ |i͐ )! ͐ ͐?s#r! ^#Vr+sh͐`is#r͐|ʊi! 6#6͐! s#r͐ ͐ |Ҋi͐ ͐ )! ~#fo͐ s#r! ^#Vr+sBi! w#w͐ ͐j! w#w͐ |j͐|i͐ ͐i͐ ͐+Ҫj! w#w͐ ͐?! s#r͐|]j! ~#fo͐ )! ~#fok͐n&ͨ͐|Oj!.ͨ! ^#Vr+si͐ |pj! ksj!k͐! ~#fo͐ )! ~#fokIm!k͒͐ )! ^#Vr+s! ^#Vr+sêi! ͨ! ^#Vr+sÒi͐͐k!ks! ͨ!9 | %3dk%sStrike any key to continue!9DM͐`is#r͐ |ʋk͐͐n&|g}os! ^#Vr+s! ^#Vr+s! ^#Vr+sFk͐Òk!9!9DM! ^#Vr+szk͐n͐n}k͐n͐nѯgWk!k!! ^#Vr+s! ^#Vr+sãk!!9DM`i6#6`i^#Vr+sznl͐n͐n}Ul͐n͐nѯgWOl!Rl!tl! ^#Vr+s! ^#Vr+sl!tl!9!9DM!!! s#r͐ ###~#fo#! s#r`iw#w! ^#Vr+sn! s! w#w͐|=m! n&|g}o|l`i^#Vr+s! ^#Vr+sz!m͐͐ n&+++@m! n&)! s! ^#Vr+slôl! 9!9DM͐#n&#`is#r! 6#6͐ n&͐ ng! s#r͐ n&|g}o͐ n&)))))! s#r͐͐+͉͐! s#r͐͐nѯg! s#r͐͐k͐! s#r͐ n! 9!!!!!R!!0ow&@|g}owѯg|g}o*RskR&!0okR&`|g}o!0o!kR&!0o*Rn&|g}os*RnwѯgW|g}oskR&!0o*Rn&|g}os*RnwѯgW|g}oskR&!0o!9DM! n}co@ʁo`ʟoýo!!!!!CR!!!!!R!!!!!R!oͫ *** Inp error *** !9DM! n} p0#pPEpgp!!!! n&!,R!!!! n&!R!!!! n&!R!vpͫ *** Outp error *** !Xq!!Zq!q!q!q!qw&s!rw&[t!rw&lu!$rw&v*-!2r͒w })q!Br,q!Er!Ir͒!_r!~r!r!rAMCALL (Auto MicroCALL Communications Program) COPYRIGHT (C) 1982 by MicroCALL SERVICES VERSION: 2.06 OSBORNE1 DEFAULT CONFIGURATION: DUPLEX MODE: SIGNAL RATE: PROTOCOL: UART MODE: FILENAME: %s ONOFF SCREEN SWITCH: %s ENTER ONE OF THE FOLLOWING: SP (SPACE) CONFIGURATION MODIFICATION CR USE THE DEFAULT CONFIGURATION ESC EXIT TO CP/M !gs!sw&s!sw&[t!sw&lu!sw&v*-!s͒w }Xs!s[s!s!s͒ CURRENT SYSTEM CONFIGURATION DUPLEX MODE: SIGNAL RATE: PROTOCOL: UART MODE: FILENAME: %s ONOFF SCREEN SWITCH: %s !9DM! n}tt(t3t!@t>t!Ft>t!Lt>t!Vt>tHALF FULL ECHOPLEX ??? !9DM! n}EʣtEʮtʹtEtEtEtEttEtEuEuu!1u'u!5u'u!9u'u!=u'u!Au'u!Eu'u!Iu'u!Mu'u!Ru'u!Wu'u!\u'u!au'u!euNOP1103001504505006001200240048009600??? BAUD !9DM! n}@ʖu ʡuPʬuʷu0uu!uu!uu!uu!uu!vu! vuNULL MCALL-C X-ON/X-OFF BREAK/RETURN MODEM ??? !9DM! n}9v DvOvZvevpv!}v{v!v{v!v{v!v{v!v{v!v{v7 BITS, EVEN PARITY 7 BITS, ODD PARITY 8 BITS, NO PARITY 8 BITS, EVEN PARITY 8 BITS, ODD PARITY ??? !2w!Ow!mw!w!w!w!w!x!0x CONFIGURATION SELECTION ENTER ONE OF THE FOLLOWING: 'D' Duplex mode selection 'F' File name specification 'P' Protocol selection 'U' UART data bits specification '#' control character screen on/off switch CR selection completed ESC exit to CP/M !px!x!x!x!x MAJOR MODE SELECTION ENTER ONE OF THE FOLLOWING: 'A' Answer mode 'O' Originate mode ESC exit - return to config. selection !8y!Yy!{y!y!y!y!z BIT CONFIGURATION SELECTION ENTER THE APPROPRIATE NUMBER: '1' (7 data, even parity, 1 stop) '2' (7 data, odd parity, 1 stop) '3' (8 data, no parity, 1 stop) '4' (8 data, even parity, 1 stop) '5' (8 data, odd parity, 1 stop) !Wz!rz!z!z!z DUPLEX MODE SELECTION ENTER THE APPROPRIATE CHARACTER: 'F' Full duplex 'H' Half duplex 'E' Echoplex !{! {!D{!q{!{!{!{ PROTOCOL SELECTION ENTER THE APPROPRIATE CHARACTER: 'B' BREAK/RETURN (UNIVAC & IBM Computers) 'C' MCALL-C (MICRO PROTOCOL - CHARACTER) 'M' MODEM (RCP/M) 'N' NULL (no end of line handshake) 'X' X-ON/X-OFF (i.e. CTRL-Q/CTRL-S) !l|!|!|!|!}!+}!G}!q}!}!}!}! ~!:~ CONTROL CHARACTERS SUPPORTED [RX file mode] ESC B Break transmission (send a 'break') ESC C Clear big_buffer ESC D Duplex mode selection ESC E Exit current mode & close file ESC G Get file directory ESC H Help - display this command list ESC K Kill (erase) disk file ESC V View the big_buffer contents ESC W Write big_buffer to disk ESC # control character screen on/off switch ESC ^ control character display on/off switch ESC ESC send an ASCII ESC char. to remote device ! !+!X!w!!!!!!I!s!!Ā!!!8!h!!́ CONTROL CHARACTERS SUPPORTED ESC B Break transmission (send a 'break') ESC D Duplex mode selection ESC E Exit current mode ESC F Filename specification ESC G Get file directory ESC H Help - display this command list ESC K Kill (erase) disk file ESC L List (type) disk file to display device ESC N Name change (rename) a disk file ESC P Protocol selection ESC R Receive (RX) a disk file from remote device ESC T Transmit (TX) a disk file to remote device ESC U UART data bits specification ESC Z Zip back to CP/M ESC # control character screen on/off switch ESC ? what is the current system configuration? ESC ^ control character display on/off switch ESC ESC send an ASCII ESC char. to remote device ! BEGIN COMMUNICATIONS AMCALL (Auto MicroCALL Communications Program) COPYRIGHT (C) 1982 by MicroCALL SERVICES VERSION: 2.06 OSBORNE1 CONNECTION ESTABLISHED - BEGIN COMMUNICATIONS 222*>22:*>222*>22:*>2ɷGz`]: ʀ! Ã!C+|ƒk:@—k:¥ :@>X!9DM! n&-|! n&! n&&!9DM͐n}! ^#Vr+sn&ͨ!9DM͐`is#r! ^#Vr+s! ^#Vr+sns{S-͐Z!9!9DM! n&|ͯڎ! n&|ͩ!y9DM! `i\`i!9!9DM͐|Άsz͐+++|!z͐##^#Vr+s|c!͐͐~#fo`is#r!|6͐##^#Vr+sz͐##͐?+s#r͐͐s#r͐^#Vr+sn&z!9!9DM͐!͐s#rzҭ!͐##w#w͐~#fo!y9DM͐`iͼ|!! `iͰ!9!9DM! n&ͼ|ͣ)! n&-|ͣ!9DM͐E!͐~#fo!9DM͐`is#r͐n}ʀ! ^#Vr+sh! ^#Vr+s͐ns! ^#Vr+sn}€͐ï!9!9DM͚͐͐s#rz݈!͐͐s#r͐##6#6͐~#fo!9DM͐ڳ͐>->T>9>b>E>u>Q>ʈó! n&ͨ! n&!! n&!! n}  ! !! n&!͐##^#Vr+s|!͐͐~#fo+|!͐##6#6͐͐s#r͐^#Vr+s! ns&!9DM͐H!e͐##~#fo|a!e͐##~#fo`is#r͐͐͐~#fo͐ʮ!e͐+?`is#r͐##~#fo|>!͐͐͐|͐##~#fo͐s#r͐~#fo͐s#r!!͐~#fo]e͐##6#6͐͐s#r!e!9!9DM`iw#w! ^#Vr+sn}ʛ`i^#Vr+s|͐â!9!9DM͐͐k! s#r͉͐! s#r͐|͐͐k! s#r͐͐! s#r͐͐! s#r͐ `is#r͐͐͐͐ ! s#r͐|ό͐͐ ͐͐͐!!9~#fo|ґό͐ ͐͐͐͐! ~#fo͐s#rO`i~#fo͐s#r)! ~#fo͉s#rۋ!9!9DM͐͐%͐)͐!9DM! n&|ͯX! n&|ͩ!h9DM! ^#Vr+s~#fo! s#r͐! s#r! ^#Vr+sn`is{ʭ`in}%—! ! s#r! 6#6! s! s! s͐n}-! ^#Vr+s! 4͐n}0! 4͐n&c}! !! s#r! ^#Vr+sn`is{.d! ! s#r! 4! ^#Vr+sn`is`in&ͻ}DʐU̎XՎOގC$SUÁ͐~#fo|̎! ^#Vr+s6-͐͐~#fos#r! ^#Vr+s! 6 ! 6! 6! ~#fo! n&! ^#Vr+s~#fo! Aѯgs#r͏! ^#Vr+s! ^#Vr+s~#fos! ^#Vr+s͏! n}h! 6#6! ^#Vr+s~#fo! s#r͐n}͏͐|͏! ^#Vr+s! ^#Vr+sns! ^#Vr+s! ^#Vr+sÃ͐6! ! s#r! n}$! ^#Vr+s!|$! ^#Vr+s! n}!0! s͐! ^#Vr+sns{M! ^#Vr+s$! n}~! ^#Vr+s!|~! ^#Vr+s6 WÔ! ^#Vr+s`insê! ^#Vr+s`insË͐6!9!9DM`i6#6͐ ! s#r͐ ͷ! s#r!|͐#|!ç! ^#Vr+s͐s{ K͐͐ #H͐++n} H! ^#Vr+s6 ~`i^#Vr+sz~͐ ͷ! s#rz~͐|͐|š͐ ͐@͐6͐ ç!9!9DM! ^#Vr+s~#fo! s#r͐! s#r! 6! ^#Vr+sn! s{ʩ! n&ͮ|! n}%P! n! B! n&óM! ^#Vr+sÒ! 6#6! 6 `i6! ^#Vr+sn! s{*”`i4! ^#Vr+sn! s! n&ͻ}X’O˒DԒUSʆCU! 6! 6! |! 6#6! ^#Vr+s! w#w! n&! !#|)! n&ó! n&! ^#Vr+sn&!! s{x͐ ! nѯg?! nѯg! s#r)! ^#Vr+s_! ͐ ~#fo! s#r! ^#Vr+sn! s{! n͐n}ד! ^#Vr+s`in}! ^#Vr+s! nsß`in}! 4͐6! ^#Vr+s`in}G͐n&! ^#Vr+s~#fo›! 4! ^#Vr+s! n&ó`in}’! ^#Vr+s~#fo͐ ͐?s#r! 4͐n}¦! n&ó! n&ó!9!9DM! n&|ͯ! n&|ͩ!9DM! ^#Vr+sz8͐n`is! ^#Vr+s͐ ns! ^#Vr+s`ins!9!9DM͐͐ ҏ͐^#Vr+s͐|͐0Ä͐7s!&ڕ͐ ͐͐ ͉͐A`is͐ ͐͐ )͐A`in&#&ڕ!9!9DM`iw#w͐~#fon&c}0͐ ?͐^#Vr+snѯg`is#r͐7!9!9DM͐|_! n&͛͐}͐##~#fo|‚!͐^#Vr+s! ns͐##^#Vr+s!!9DM! n} ͝ݖ! n} ͝ݖ! n} ͝!9DM͐~#fon`isͮ|͐^#Vr+s`in&!9!9DM! n&ͻ! s|Y! n&sÁ! n&c}|! n&sÁ!! n! n&+Ҡ!é! n&  6  #F#x֗~#ɗ _   7*+++:G_*DM!o& #+|&'z) *+*7**DM:!n**o&:woʂ2w&!o ¥ . &  ¼ > _ ˘7**:Ozq#7:O*#:w&o !,7,2q*&:q):Z=Z=r:qo& !\&!7*!&*!&!&="&! BL<"e=L ) ,7:)~:,"s!"u*|<**sA! ~<6*u*+"*"*u#"u7*~# c c+*&!7*|DM**ǚګ><Ꟛ~# xŸ ><껚~+ x»|}7*b\!*7:)~:,"s!"u*|*u[*~#2"*s*u[#"u*+"7:,*ܛ:*}|2q ʰ¦:qwʡ! {w7*:w:wo2w& , FNxg>Goy$6!;P`i^#Vr+sOùO͐|/P!;P;P͐ 6!;P!9!9DM!!|aPLP!!|g}o`isw}6!;P`i^#Vr+sOùO͐|/P!;P;P͐ 6!;P!9!9DM!!|aPLP!!|g}o`isw}6!;P`i^#Vr+sOùO͐|/P!;P;P͐ 6!;P!9!9DM!!|aPLP!!|g}o`isw}*+~# !\ Fo|ggCOM=U DM!>))| ~ö*B*D}|ڟ!"D*B{zґ*@‹*D"D]*D"B!"D*@*B}>*D#"Dɯ2+2?!"B"D<  NO IFILE FILE$!\ "D y*+HEX~# !\ oå** }|ڕ!" *{z҇*h* " : t DISK FULL: OFILE$!" ** #" ɯ22!"!" <  NO DIR SPACE: OFILE$!m0 ))))O "Iʊ>:%2>N:N:NNNpI?O:2y_y0:j%:N> %> %*>:%N‘> %> %* }±">%¥<  CANNOT CLOSE OFILE$*.|g"e A xs`! u`g *e.U*e.>w*e.|w*ew# xU ͻAMCALL$=0! LOADING AMCALL... Osborne Computer Corporation 26538 Danti Court Hayward, CA 94545 $YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaKWWWWWWWWWWWWWWWWWWWWIaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYIaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaKWWWWWWZaaaaaaaaaaVWWWWWWIaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaWWWWWWWaaaaaaaaaaaaWWWWWWWaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaWWWWWWWaaaaaaaaaaaaWWWWWWWaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaWWWWWWWaaaaaaaaaaaaWWWWWWWaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaVWWWWWWIaaaaaaaaaaKWWWWWWZaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYZaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaVWWWWWWWWWWWWWWWWWWWWZaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa$ MCALL-C: A Communications Protocol for Personal Computers Copyright (C) 1980 by Tim J. Pugh, Jr. In the protocol description which follows, I will identify alternative approaches that were considered in arriving at the present protocol. But before getting into the protocol itself I would like to try to clear up a misunderstanding that may exist concerning telecommunications protocols. The type of protocol which I am describing has no bearing on the information content of the data. The protocol acts simply as an envelope or container of data. The data is inserted into the envelope at the originating (transmitting) end and automatically removed at the receiving end. Thus, by the time the data is placed on disk, it looks exactly the same as it did on the disk of the originator. Perhaps the first question to answer is "why have a protocol?". The principal reason for having one is to insure, as far as possible, that no data is lost or garbled in the transmission. One can, and I often do, transmit and/or receive data files with a large Time Sharing Computer (TSC). These TSCs' are typically very uncooperative beasts which output the data to you in "their own good time", usually as fast as it can be sent. They are not concerned whether you had noise on the line or whether you had time to write the last record to disk. That's your problem. Thus, if you have a system which pays rapt attention to the incoming data and if the weather is good and you have a high quality modem, then you have an excellent chance of receiving error free data. However, one cannot depend on all the above stated conditions being met, especially when two personal computers are involved. Such a transfer will frequently be "long distance". Each additional TELCO switching center involved in the "call" reduces the signal to noise ratio and often there is line "echo" distortion present. Thus, reliable data transfer becomes questionable without an intervening mechanism. An appropriate communications protocol supplies this mechanism. SERIAL VERSUS BLOCKED DATA FORMAT The simplest way to transfer a file is the way it is done with a TSC. The file is simply transferred serially to completion. It is assumed the the receiving file has already been created and that the TSC is capable of recording the data at the maximum BAUD rate; e.g., 300 BAUD. Such an approach can also be used for transfers between two Personal Computers (PCs') provided the operation is properly coordinated and synchronized. However, it is much preferable to have the two computers do the necessary synchronization and coordination since it is then both more convenient for the users and less error prone. We have thus posited a protocol whereby the file is automatically opened at the Transmitting (TX) end and created at the receiving (RX) end and might look something like this: --> @SOH <-- @ACK --> The directed arrows indicate the direction of data transfer where "-->" indicates data from the TX to the RX. The "@" signifies ASCII and thus @SOH indicates the ASCII Start Of Header control character. Similarly, "@ACK" signifies ASCII ACKnowledge. Assuming that the originating (TX) operator has previously specified the name of the file to be transferred; i.e., and further assuming that communications has been established between the two parties, then the transfer is initiated by the TX end issuing an @SOH followed by the name of the file. Since an indeterminate amount of time is required for the RX system to create the corresponding file, and ACKnowledgment is required before the data transfer can begin. Why an indeterminate amount of time to open a file? Partly because there is such a variety of floppy disks and controllers capable of running under CP/M (both 8" and 5 1/4"). Since a "handshake" character, @ACK, was required to signify "file created OK"; why not include the option of sending @NAK (Negative AcKnowledge) to signify some problem in opening the file? Lets further assume that if @NAK is received by the TX end, the "@SOH " will be repeated. Since we have provided for retransmission (reTX) of the Header Record, the next question is how can we discontinue the retransmission, assuming the problem persists over several reTXs'. This introduces a third control character, @CAN (ASCII CANcel). Thus our "handshake" in response to the Header Record can take one of three forms. This situation is handled nicely by the BACKUS-NAUR notation which follows: ::= @ACK | @NAK | @CAN Which states that the acknowledge form is defined equal to either @ACK or @NAK or @CAN. We next look at the . The most conventional method for "recording" received data is to first buffer it in memory and subsequently write it to disk. This allows the RX system to handle high BAUD rates, e.g., 1200 BAUD, without data loss. However, if large files are transferred, buffer overflow might result. Thus, it is desirable to allow the buffer to be "dumped" to disk at appropriate times. A simple solution to this problem is to break the into small blocks followed by an . Thus, if the data is broken into equal blocks of 128 characters the protocol would look something like this: --> @SOH <-- @ACK --> <-- @ACK --> <-- @ACK ... ... --> <-- @ACK The @ACK following each tells the TX system that the buffer write operation is complete and the next block can be sent. The above considerations argues strongly for a BLOCKED rather than a SERIAL data format for our protocol. DATA INTEGRITY CONSIDERATIONS The blocked protocol specified thus far provides for error recovery (reTX) in the the was garbled; e.g., noise caused a given character to be converted to a character which is not legal when specifying file names. It also provided time for data blocks to be transferred from memory to disk. However, no provision has been made to insure that data integrity is maintained. The most commonly employed techniques for handling this problem is to use either a Cyclic Redundancy Check (CRC) or a Checksum. The CRC usually employs a polynomial equation for its realization. The term checksum, as used here, simply means a sum of all the characters in a given data block. Since each character in the ASCII set can be represented by seven data bits, this simply means the accumulated total obtained by adding each character, in turn, to the previous partial sum. I have chosen the checksum because of its simplicity and ease of implementation. In implementing the checksum two choices must be made: (1) The block size over which the checksum is to be taken; (2) The number of bits to be allocated to the checksum. The most convenient block size appears to be that associated with one physical record on disk; i.e., a disk sector of 128 bytes. Having chosen the first parameter we find that the largest value the checksum could take on occurs if the ASCII rubout character (@DEL = 07FH) is repeated 128 times. Since 07FH is equivalent to 127 decimal, the worst case checksum would be: SUM = 128 * 127 = 16256 This value falls between 2^15 and 2^16. Thus, a 16- bit checksum would insure a unique sum for each unique data block. I am using the term "unique" rather loosely here. Two data blocks consisting of the same characters but in different order are not considered unique, by this definition. At least one popular "serial I/O" card employs a UART who's output is fixed at 7 data bits. The Cromemco TU-ART employs the Texas Instruments TMS5501 device to support serial I/O. The serial output of this device is fixed at 7 data bits with a parity bit of zero. Thus, while it would be most efficient to transfer the 16-bit checksum as two eight-bit characters, this approach would exclude systems employing the TU-ART card to drive an acoustic coupler. For this reason, an ASCII HEX encoding of the checksum was employed. This results in the 16-bit value being broken into four "nibbles" of 4 bits each. The ASCII representation of each nibble ranges from ASCII 0 through 9 and ASCII A through F. There remains the question of ordering the output value; i.e., what sequence should be used in transferring the nibbles. I somewhat arbitrarily chose the most significant nibble first and least significant nibble last. We now have a protocol where each data block, including the header block, has a checksum associated with it. As each character is transferred, both the TX and RX systems accumulate individual checksums. The TX system transfers its final value to the RX, who tests it for equality with its own value. If the values agree, an @ACK is returned, otherwise a @NAK is returned and the data block is retransmitted. How many times should reTX be allowed to occur on the same data block before canceling (@CAN) the transfer? I have somewhat arbitrarily chosen the value of 5. Remember, it takes quite a bit of time to repeat a data block 5 times. Five repeats plus the original at 300 BAUD requires approximately: retry time = 6*(128+4)/30 Sec. = 26.4 Sec. Also remember we are not dealing with "crud" on a disk (which uses 10 retries) but with noise on the line. If the line noise, or perhaps some system problem, causes a reTX in excess of 5 times on the same data block, brother, you have a problem! Note further that many more than 5 reTXs' are allowed provided no more than 5 occur on a given data block. While we seem to have solved the data integrity question on a data block basis we still need some way of assuring ourselves that each and every block was received properly and that some reTXed block didn't get recorded twice by mistake. One approach is to include a block or frame count as part of the block transfer. Since the files transferred might be quite large, a 16-bit block count might be needed. Given the 7 data bit limit mentioned above, this would require an additional 4 characters per block. I chose a different approach which does not add to the size of the data block. I have found that if a cumulative total of reTXs' is kept by both TX and RX systems, then the equality of these values virtually assures the transfer was error free. Thus, the TX systems sends his retry count to the RX system as a part of the End of TeXt (@ETX) record. This record immediately follows the last record. If the counts agree, the RX system sends @ACK. Else, a @NAK is sent. Both systems then display on their respective consoles that the transfer was either successful or unsuccessful along with the total number of reTXs'. We now have a protocol that looks something like the following: --> @SOH FILENAMETYP SUM <-- @ACK --> AAAAAAAAAAAAAAAA SUM <-- @ACK --> BBBBBBBBBBBBBBBB SUM ... ... --> JJJJJJJJJJJJJJJJ SUM <-- @NAK (RETRANSMISSION REQUEST) --> JJJJJJJJJJJJJJJJ SUM <-- @ACK --> KKKKKKKKKKKKKKKK SUM <-- @ACK ... ... --> ZZZZZZZZZZZZZZZZ SUM <-- @ACK --> @ETX CNT <-- @ACK The "SUM" associated with each data block represents the four ASCII HEX characters associated with the checksum. The "CNT" at the end represents a single character value interpreted as a binary retransmission count value. Thus, it represents the count modulo 128 since the number of data bits in the protocol is set to 7 data bits. VARIABLE BLOCK SIZE AND DATA PARITY CHECK The above protocol is about as far as we can go if limited to 7 data bits and no parity. However, since most UARTS/USARTS provide for both software control of the number of data bits (5 thru 8) and additional control over parity selection (even or odd) coupled with parity enable/disable, valuable additions can be made to the protocol. Lets first consider variable block size. If we limit the block size to one sector (128 characters) then we must access and write the disk every 4 seconds (approx.) at 300 BAUD. The read/write head on most drives unloads within this interval. Thus, the head is being loaded each time a write operation is performed. This takes on the order of 35 Msec or about one character time at 300 BAUD (33.3 Msec per character). In addition, the proper sector must be found - assuming the head is already positioned at the appropriate track. Since it takes 166.6 Msec for one rotation of the disk, the average "latency" is one half that value; i.e., 83.3 Msec. Thus, each time we write the disk costs us, on average, write time = 83.3 + 35 Msec = 118.3 Msec. This is approximately 4 character times at 1200 BAUD. The worst case time would be approximately 211.6 Msec or approximately 6 character times at 300 BAUD (includes 10 Msec track stepping time). These times apply to the Shugart 800 drive. The times should be fairly representative of all floppy disk drives. Given the above statistics, it seems desirable to increase the block size and thereby reduce the number of times a disk write operation is performed. In arriving at an optimum block size (if one exists) we must consider the impact of increased block size on both buffer memory size and time lost in retransmitting a larger data block. I have no firm number in mind but since CP/M allocates disk space in 8 sector blocks, a value of 1024 = 8 * 128 seems a good starting point. This calls for a 16-bit block size value which can be sent as two 8-bit bytes interpreted as binary values rather than ASCII characters. To be consistent with the checksum ordering the most significant byte is transmitted first. The next protocol enhancement to be introduced provides for a parity error test. If a data parity error is found, there is no need to continue the block transfer. Instead, the block should be immediately retransmitted. This further facilitates the introduction of larger block sizes. To accommodate the retransmission request due to parity error, two additions to our protocol are needed. First, we must add a resync (@SYN) request to our . In response to the receipt of an @SYN from the RX device, the TX device will discontinue the block transfer and begin a retransmission of the same block. Second, to assure proper synchronization, each data block should begin with a distinguishing character. I have selected the ASCII Record Separator (@RS) for this task. Thus, if the RX device detects an @RS following his transmission of an @SYN, he knows the block retransmission request has been received by the TX device and that this is the beginning of that block. Finally, it is desirable to be able to identify a block with more or less characters than specified by the block count. This can be done by inserting a special character between the end of data and the beginning of the checksum. I have selected the ASCII Unit Separator (@US) for this task. If there is such a disagreement, an @SYN is immediately sent by the RX to the TX causing a retransmission. This completes the protocol specification and leaves us with a typical data block that looks something like, --> @RS N XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX @US SUM <-- @ACK Where N denotes the block count and, as before, SUM denotes the checksum. I have given this protocol the name "MCALL-C", which stands for Micro proto"CALL" - Clear. The clear means that the data is not encoded, as is the case for the PCNET protocol. In PCNET protocol, the data is encoded in a radix 41 code rather than pure ASCII. This encoding allows binary information to be transferred while using only 41 "printable" characters to encode the data. The complete MCALL-C definition both in BACKUS-NAUR form and in a more graphic form (section (3)) is shown next. The definition is from the point of view of the originator or (TX) system. *********************************** (1) DATA TRANSMITTED (@XXX SIGNIFIES AN ASCII CONTROL CHAR) ::= ::= @SOH
@US
::= <8 CHAR FILENAME> <3 CHAR FILETYPE> ::= <16 BIT CHECKSUM ENCODED IN ASCII HEX MS-NIBBLE FIRST, LS-NIBBLE LAST> ::= @ETX ::= | ::= @RS @US ::= > ::= ::= (2) DATA RECEIVED (HANDSHAKING PROTOCOL) ::= <@ACK> | <@NAK> | <@SYN> | <@CAN> <@ACK> ::= @ACK (SUCCESSFUL TRANSFER OF DATA) <@NAK> ::= @NAK (RETRANSMISSION REQUEST) <@SYN> ::= @SYN (RESYNC REQUEST) <@CAN> ::= @CAN (ABORT TRANSMISSION) ::= ::= ::= @ETX (FILE CLOSED ACK) (3) SAMPLE FILE TRANSMISSION --> @SOH FILENAMETYP @US SUM (HEADER BLOCK) <-- @ACK --> @RS N AAAAA...AAAAA @US SUM (FIRST DATA BLOCK) <-- @ACK --> @RS N BBBBB...BBBBB @US SUM (SECOND DATA BLOCK) <-- @ACK ..... ..... ..... --> @RS N VVVVV...VVVVV @US SUM <-- @NAK (RETRANSMISSION REQ) --> @RS N VVVVV...VVVVV @US SUM <-- @ACK ..... ..... ..... --> @RS N YYYYY...YYYYY @US SUM <-- @ACK --> @RS N ZZZZZ...ZZZZZ @US SUM <-- @ACK --> @ETX M (END OF FILE) <-- @ACK *********************************** Having specified the protocol, we must now resolve the problem presented by the existence of UARTS whose number of data bits is limited to seven and whose operation does not support parity generation and testing. The best approach might be to have two similar but different protocols. One to accommodate the TMS5501 and another to take advantage of the 8 data bits plus parity. Lets call the 7-bit version MCALL-C and the 8-bit version, MCALL-BC. The "B" related to the Big data block size. The two protocols are identical except in the way the block size and the checksum are represented and the use of parity testing in one but not the other. By limiting the differences to these three parameters, both protocols can be accommodated by the same program. A "flag" could be set in response to operator input to specify which processing path was selected. For MCALL-C we define the block size and the checksum as follows: ::= IN THE RANGE 0 TO 127> ::= <16-BIT CHECKSUM ENCODED IN ASCII HEX WITH MS-NIBBLE FIRST> For MCALL-BC we define these two parameters as follows: ::= IN THE RANGE 0 TO 65535 WITH MS-BYTE FIRST> ::= <16 BIT CHECKSUM WITH MS-BYTE FIRST> As to the effectiveness of the protocol, I have implemented the MCALL-C protocol as part of a program I have written called "MCALL". The program fixes the UART data format at 7 data bits with even parity, although no parity test is currently performed. This protocol has been tested on a variety of I/O cards for the S-100 BUS and includes the Cromemco TU-ART. I find the protocol very effective in file transfers and have never had an unsuccessful transfer under normal circumstances. By normal I mean under both good and foul weather conditions with total reTX counts ranging up to 10 or more per message. I generally get error-free performance even when I tap on the telephone handset with a pencil to introduce noise. Occasionally, however, using the "bang approach" I have caused the system to "bomb" or record the same block twice. However, the operator is alerted to the latter case via an "unsuccessful file transfer" message at the end. This is where the comparison of reTX counts pays off. The current version of MCALL supports only MCALL-C. I hope to add MCALL-BC in the future, along with other protocols and program enhancements. Further information relating to MCALL can be obtained by contacting: MICRO-CALL SERVICES 9655-M Homestead Court Laurel, MD 20810 (301) 776-5253  AMCALL & MCALL Availability In addition to the OSBORNE1 computer, AMCALL is available on a number of other computer systems: o Any S-100 BUS computer system running under CP/M. o Certain single board computer systems: ALTOS ACS8000 TeleVideo TS802 Heath/Zenith H-8, H-89 There are available several S-100 modem board which provide auto-answer and auto-dial capability. Of these, AMCALL is supported on the following: (1) Potomac Micro-Magic (PMMI) MM-103 modem board. (2) D.C Hayes MICROMODEM-100 board. (3) International Data Systems (IDS) 88-MODEM board. In the case of the single board computer systems, AMCALL is supported on the Hayes SmartModem and will soon be available on the BIZCOMP Intelligent Modem. AMCALL is written in the C programming language developed at Bell Labs and used to write the UNIX operating system. The 'C' language is currently supported uder: CP/M-80, CP/M-86, MSDOS, and UNIX. Thus AMCALL will soon be available under these operating systems as well as other single board computers -- especially the IBM Personal Computer. Soon to be released is the MCALL II program. This program is designed to support manually operated modems, not possessing the auto-ans/dial features. Excluding those commands associated with auto-dial and auto-answer, MCALL II will support all commands that AMCALL now supports. Finally, an assembly language version of MCALL supporting most, but not all, of the AMCALL commands has been available since 1979. This program is currently available with source code and conditional assembly statements which provide for the support of 24 different S-100 serial cards and single board computer systems. For further information contact: MicroCall Services 9655-M Homestead Court Laurel, MD 20707 (301) 776-5253 AMCALL COMMAND LINE SYNTAX: AMCALL [-] [] where [....] -- denotes optional arguments = {A,O;E,F,H;B,C,M,N,X;#;@} where (A)nswer mode, (O)riginate mode; (E)choplex, (F)ull duplex, (H)alf duplex; (B)reak/return, mcall-(C), (M)odem, (N)ull, (X)-on/x-off; (#)control character screen on; (@)bypass auto-answer/auto-dial AMCALL INVOCATION EXAMPLES: AMCALL FILENAME.TYP ;CONVENTIONAL INVOCATION AMCALL -O ;DIRECT TO (O)RIGINATE ;DUPLEX = FULL ;PROTOCOL = X-ON/X-OFF ;FILENAME = DEFAULT.FIL AMCALL -A B:FOO.FIL ;DIRECT TO (A)NSWER MODE ;DUPLEX = ECHOPLEX ;PROTOCOL = X-ON/X-OFF ;FILENAME = B:FOO.FIL AMCALL -OC ;DIRECT TO (O)RIGINATE ;PROTOCOL = MCALL-(C) AMCALL -OEN ;DIRECT TO (O)RIGINATE ;DUPLEX = (E)CHOPLEX ;PROTOCOL = (N)ULL AMCALL -OHB JUNK.FIL ;DIRECT TO (O)RIGINATE, ;DUPLEX = (H)ALF ;PROTOCOL = (B)REAK ;FILENAME = JUNK.FIL AMCALL -@O ;BYPASS AUTO_DIAL, ;DIRECT TO (O)RIGINATE, ;i.e. TO DIAL CALL ;MANUALLY. A, RCP/M Allentown PA,215-398-3937; B, RCP/M Beaverton OR,503-641-7276; D, RCP/M Dearborn MI,313-846-6127; F, RCP/M Flanders NJ,201-584-9227; H, RCP/M Hyde Park IL,312-955-4493; K, RCP/M Mission KS,913-362-9583; L, RCP/M Logan Sq. IL,312-252-2136; M, RCP/M McLean VA,703-524-2549; P, RCP/M Pasadena CA,213-799-1632; R, RCP/M Rochester NY,716-223-1100; S, RCP/M San Diego CA,714-273-4354; T, THE SOURCE ,local number; J, DOW JONES ,local number: