Kermit on the HP48 (Was: One-Way Transfer)
Frank da Cruz
In article <wkvhqye...@jhuapl.edu>,
Skip Collins <coll...@jhuapl.edu> wrote:
: jal...@watsun.cc.columbia.edu (Jeffrey Altman) writes:
:
: > The HP48 can not handle 9600 baud transfers without flow control
: > Turn on XON/XOFF flow control on the calculator and SET FLOW CONTROL
: > XON/XOFF on K95.
:
: The HP48 Kermit can handle 9600 baud transfers in both directions
: without flow control. I do it all the time. In fact, the calculator
: will automatically _disable_ flow control for Kermit transfers even
: when it is enabled for other serial I/O (I think). There is a 255
: character input buffer. The bare bones Kermit on the HP48 does not
: implement long packets so the buffer is plenty big to handle Kermit
: packets without flow control.
:
: Last month there was an interesting discussion about the limitations
: of HP48 Kermit on comp.sys.hp48. Search dejanews for Dan Kirkland's
: posts with the subject "Re: a better kermit". Due to a basic flaw in
: the HP ROM kermit, throughput in receiving is slower than it should
: be. Perhaps someone will reimplement the binary receive routing to
: overcome this problem.
:
: As for the original poster's problem, I have no idea. Perhaps he
: should try mskermit. I works for me.
:
Thanks for the comp.sys.hp48 reference. I'm copying this response to that
newsgroup.
As noted in an earlier posting in this thread, I would like to straighten
out the massive confusion about Kermit file transfer with the HP-48. We (at
the Kermit Project) are not HP-48 experts, but we do have an early model
HP-48 for testing. When we get complaints or questions about file transfer
with the HP-48, we check our answers on it.
But we usually find that what works for us fails to work for others, or vice
versa. No doubt because there are many and varied HP-48 models, ROM
versions, etc etc.
I would like to set up an HP-48 resource at the Kermit web site where all
HP-48 users could look to find answers to frequently asked questions, hints
and tips, etc.
To that end, first let me suggest that all postings to comp.sys.hp48 be
copied to comp.protocols.kermit.misc so that people who might know more
about the Kermit program on the other end can help out.
Second, a few points of clarification on recent comp.sys.hp48 postings:
1. Kermit is not a slow protocol. The HP-48 implementation of the Kermit
protocol is slow. It was written by HP (or whoever HP hired to do it)
without our knowledge or advice. For an analysis of Kermit protocol
performance, see:
http://www.columbia.edu/kermit/newsn6.html#perf
2. Whatever Kermit software might have been provided to HP-48 users by
HP is not necessarily appropriate. Current versions of Kermit software
are found at the Kermit Project website:
http://www.columbia.edu/kermit/
Let's see if we can set up a simple set of guidelines for how to set up
Kermit software (on DOS, Windows, UNIX, etc) for communicating with the
HP-48, or for each model thereof, when the models make a difference.
1. The top serial speed is 9600, right?
2. Should the flow control setting be NONE or XON/XOFF? We have
conflicting reports (see above). Obviously the HP-48 *should* be
exercising some form of flow control, but some reports indicate that
it does not (even if it is set to do so).
3. Is the link transparent to incoming control characters? Can the
client Kermit program use control-character unprefixing when sending
to the HP-48? If not, the client program must be told to
SET CONTROL PREFIX ALL prior to sending files to the HP-48.
4. Does the link allow 8-bit data? If not, the client must be given
the appropriate SET PARITY command.
The HP-48 does not support long packets; thus the maximum packet length
is 94, but this should be negotiated automatically.
The HP communication port is half duplex, meaning that data can go in both
directions, but only in one direction at a time. Therefore sliding windows
can not be used (this too should be negotiated automatically).
More to the point, I have also heard that (at least some models of) the
HP-48 become "deaf" to incoming bytes for some number of milliseconds while
switching their serial port from "send" to "receive", so if the client
program is too fast, file transfers can fail. The solution to this is to
tell the client program to pause for a sufficient number of milliseconds
prior to sending each packet:
set send pause 100 ; or whatever number works
Postings on comp.sys.hp48 indicate that the HP-48 Kermit implementation
"parses" incoming text-mode material on the fly, and appends the material
from each incoming packet to a "string", resulting in a steadily
deteriorating transfer rate, at least up to some point at which the HP-48
dumps the string to storage and starts over with a new string. There's not
much that the Kermit client can do about that.
Any other hints from HP-48 users will be appreciated; I'll be glad to
collect them into an FAQ.
- Frank
Frank da Cruz
In article <wk67iy1...@jhuapl.edu>,
Skip Collins <coll...@jhuapl.edu> wrote:
: f...@watsun.cc.columbia.edu (Frank da Cruz) writes:
: > But we usually find that what works for us fails to work for others, or
: > vice versa. No doubt because there are many and varied HP-48 models, ROM
: > versions, etc etc.
:
:
: > 1. The top serial speed is 9600, right?
:
: As far as the built-in kermit is concerned this it true. But there are
: user programs that claim to support 19.2k. I have not tried them.
:
: > 2. Should the flow control setting be NONE or XON/XOFF? We have
: > conflicting reports (see above). Obviously the HP-48 *should* be
: > exercising some form of flow control, but some reports indicate that
: > it does not (even if it is set to do so).
: Why is flow control necessary or even desirable given the maximum
: packet size is 94 and the receive buffer is 255?
:
Theoretically, it would not be necessary. But I don't know how their
Kermit implementation works internally. Does it parse incoming packets as
it reads them, or does it read them first and then parse them? Can anything
else happen during a read? Garbage collection, etc?
: > 3. Is the link transparent to incoming control characters? Can the
: > client Kermit program use control-character unprefixing when sending
: > to the HP-48? If not, the client program must be told to
: > SET CONTROL PREFIX ALL prior to sending files to the HP-48.
:
: Shouldn't control char unprefixing be a negotiated feature?
:
It would seem so, but no. The reason is that the two parties have no idea
what lies between them, and so there is no way they can negotiate a safe
set of control characters.
: If it is not, I can see where this might be the cause of many people's
: problems. Surely it is not the default?
:
Most Kermit programs prefix all control characters by default when sending a
file. Kermit 95 is the exception, since most Windows 95 users demand "high
performance". Kermit 95's default is to unprefix a fairly safe subset of
control characters.
: I think the physical link is transparent to control characters. But perhaps
: the hp48 kermit software assumes prefixing.
:
The cardinal rule of any communications protocol is "be conservative in
what you send, be liberal in what you receive". The HP48 has it backwards.
There is no prohibition in the protocol definition against sending bare
control characters, thus any Kermit receiver should be prepared to get them,
in which case they are treated like any other data character. Refusing to
accept them is a mistake. Almost every Kermit implementation, no matter how
old, accepts bare control characters (assuming they get through the physical
link unscathed). The programmer has to go out of her/his way to prevent
this from working.
: > 4. Does the link allow 8-bit data? If not, the client must be given
: > the appropriate SET PARITY command.
:
: Yes, the link allows 8-bit data.
:
Good...
: > The HP-48 does not support long packets; thus the maximum packet length
: > is 94, but this should be negotiated automatically.
:
: It is negotiated. As far as I can tell, the only "advanced" feature
: supported by the hp48 is a choice of block checking options 1, 2, or 3.
:
: > The HP communication port is half duplex, meaning that data can go in both
: > directions, but only in one direction at a time. Therefore sliding
: > windows can not be used (this too should be negotiated automatically).
:
: The serial port is full duplex. The infrared port is only half-duplex
: because of optical feedback.
:
Does this apply to all models? I got my information about dead periods in
the serial port from an HP engineer, circa 1990.
: The hp48 kermit certainly has not implemented sliding windows. There would
: be very little advantage to doing so for most users who only use a short
: cable to connect to a PC.
:
: > Postings on comp.sys.hp48 indicate that the HP-48 Kermit implementation
: > "parses" incoming text-mode material on the fly, and appends the material
: > from each incoming packet to a "string", resulting in a steadily
: > deteriorating transfer rate, at least up to some point at which the HP-48
: > dumps the string to storage and starts over with a new string. There's
: > not much that the Kermit client can do about that.
:
: This is the biggest problem with hp48 kermit.
:
Can you help clear this up? What is the deal? Text-mode transfers into
the HP-48 are the ones that get progressively slower? But binary-mode
transfers into the HP-48 are OK?
Is it true that incoming text-mode packets are parsed as HP-48 programs?
So this means that only HP-48 programs may be sent in text mode, and any
other text files sent to the HP-48 are likely to be rejected. One user
reported that any text file containing a "-" character would be rejected
for "Invalid syntax".
This means that non-HP-48-program files must be sent to the HP-48 in binary
mode, right?
So let's start trying to put together the settings to use with MS-DOS Kermit,
C-Kermit, and Kermit 95 for transferring files with the HP-48:
set modem type direct ; (Skip this in MS-DOS Kermit)
set carrier-watch off ; (Does the HP-48 assert DCD? If so, use ON.)
set port <whatever>
set speed 9600 ; (The best the HP-48 can do)
set flow none ; (or Xon/Xoff)
set parity none ; (The HP can accept 8-bit data)
set control prefix all ; (Don't send bare control chars)
set receive timeout 99 ; (see Note 1 below...)
set send pause 100 ; (see Note 2 below...)
Items such as packet length and window size are negotiated automatically;
there is no need to set them.
1. If it takes the HP-48 a long time acknowledge data packets (e.g.
in text mode), tell the file sender to wait a long time for the
acknowledgement. (Newer versions of C-Kermit and K95 will adjust
their timeouts dynamically according to the actual behavior, in
which case the SET RECEIVE TIMEOUT command is not needed.)
2. The SET SEND PAUSE command is needed if the HP-48's serial port is
half duplex. The number (100 milliseconds) might need adjustment.
I'm sure this is highly dependent on the exact model and ROM version.
Finally:
set file type text ; For HP-48 programs
or:
set file type binary ; For all other forms of data
Oh, by the way, another peculiarity I noticed... If the HP-48 is set up to
be client of a Kermit server, its method for getting directory listings is
rather odd. Instead of sending a REMOTE DIRECTORY protocol message, it
sends REMOTE HOST DIR/W. Of course, this won't work unless the server:
a. Is a DOS or Windows or OS/2 system, and:
b. Has HOST ENABLE'd in its Kermit server.
- Frank
Andy Fox
Hi Frank,
I wanted to thank you and Jeff both for helping me get files transferred
in both directions between my HP-48GX and K95 (V1.1.16).
The important points seem to be:
Run the HP-48 in server mode.
HP set up for binary transfers (at least for variables)
K95 "SET CONTROL PREFIX ALL"
Here is a little more information:
<snip>
> : > Postings on comp.sys.hp48 indicate that the HP-48 Kermit implementation
> : > "parses" incoming text-mode material on the fly, and appends the material
> : > from each incoming packet to a "string", resulting in a steadily
> : > deteriorating transfer rate, at least up to some point at which the HP-48
> : > dumps the string to storage and starts over with a new string. There's
> : > not much that the Kermit client can do about that.
> :
> : This is the biggest problem with hp48 kermit.
> :
> Can you help clear this up? What is the deal? Text-mode transfers into
> the HP-48 are the ones that get progressively slower? But binary-mode
> transfers into the HP-48 are OK?
>
It appears to me that it slows down in binary mode also.
<snip>
> So let's start trying to put together the settings to use with MS-DOS Kermit,
> C-Kermit, and Kermit 95 for transferring files with the HP-48:
>
> set modem type direct ; (Skip this in MS-DOS Kermit)
> set carrier-watch off ; (Does the HP-48 assert DCD? If so, use ON.)
There are only four wires, TX, RX, GND and Shield. No hardware flow
control.
> set port <whatever>
> set speed 9600 ; (The best the HP-48 can do)
> set flow none ; (or Xon/Xoff)
> set parity none ; (The HP can accept 8-bit data)
> set control prefix all ; (Don't send bare control chars)
> set receive timeout 99 ; (see Note 1 below...)
> set send pause 100 ; (see Note 2 below...)
>
> Items such as packet length and window size are negotiated automatically;
> there is no need to set them.
>
> 1. If it takes the HP-48 a long time acknowledge data packets (e.g.
> in text mode), tell the file sender to wait a long time for the
> acknowledgement. (Newer versions of C-Kermit and K95 will adjust
> their timeouts dynamically according to the actual behavior, in
> which case the SET RECEIVE TIMEOUT command is not needed.)
>
> 2. The SET SEND PAUSE command is needed if the HP-48's serial port is
> half duplex. The number (100 milliseconds) might need adjustment.
> I'm sure this is highly dependent on the exact model and ROM version.
>
> Finally:
>
> set file type text ; For HP-48 programs
>
> or:
>
> set file type binary ; For all other forms of data
>
I'll have to try transferring programs later, maybe this weekend...
> Oh, by the way, another peculiarity I noticed... If the HP-48 is set up to
> be client of a Kermit server, its method for getting directory listings is
> rather odd. Instead of sending a REMOTE DIRECTORY protocol message, it
> sends REMOTE HOST DIR/W. Of course, this won't work unless the server:
>
> a. Is a DOS or Windows or OS/2 system, and:
>
> b. Has HOST ENABLE'd in its Kermit server.
>
> - Frank
I was able to get a directory listing displayed on my HP, but couldn't
receive the file from the server. Jeff recommended, and I concur, that
the HP should be the server.
Thanks again. I have been impressed with your tech support for several
years (since I became aware of it, actually). I have found your manuals
to be the best written, along with the "Nutshell" series of books by
O'Reilly.
--
72/73 de Andy, KK7HV - QRP-L #1286 - Benson, AZ
Matthew Mastracci
On 22 May 1998, Frank da Cruz wrote:
> As noted in an earlier posting in this thread, I would like to straighten
> out the massive confusion about Kermit file transfer with the HP-48. We (at
> the Kermit Project) are not HP-48 experts, but we do have an early model
> HP-48 for testing. When we get complaints or questions about file transfer
> with the HP-48, we check our answers on it.
I've written a Kermit program for transferring between the PC and the
HP48, so I'd like to offer my discoveries (I've spent a long time getting
my client to connect to the calculator).
> 1. The top serial speed is 9600, right?
Yes.
> 2. Should the flow control setting be NONE or XON/XOFF? We have
> conflicting reports (see above). Obviously the HP-48 *should* be
> exercising some form of flow control, but some reports indicate that
> it does not (even if it is set to do so).
The calculation doesn't need flow control, as the size of a packet will
never exceed the internal buffer (sliding windows aren't supported).
Having XON/XOFF interferes with the transfer, from what I can tell, as the
HP48 picks the control characters up as unquoted data. I can tell you
*absolutely* that flow control is not required.
> 3. Is the link transparent to incoming control characters? Can the
> client Kermit program use control-character unprefixing when sending
> to the HP-48? If not, the client program must be told to
> SET CONTROL PREFIX ALL prior to sending files to the HP-48.
The link is transparent to all characters. The HP48 will reject any
packet that contains an unquoted control character with a NAK packet (this
is probably because the calculator can also send via IR, which may
introduce errors). Control-character prefixing must be used to send to
the HP48.
> 4. Does the link allow 8-bit data? If not, the client must be given
> the appropriate SET PARITY command.
The default setting for the HP48's serial port is 9600 baud, no parity, 8
bits and 1 stop bit. If it has been set to something else, you can
restore it to this default by deleting the IOPAR variable.
> The HP-48 does not support long packets; thus the maximum packet length
> is 94, but this should be negotiated automatically.
This is negotiated properly.
> The HP communication port is half duplex, meaning that data can go in both
> directions, but only in one direction at a time. Therefore sliding windows
> can not be used (this too should be negotiated automatically).
Yes. The HP48's info is something like "~* @-#N1".
> More to the point, I have also heard that (at least some models of) the
> HP-48 become "deaf" to incoming bytes for some number of milliseconds while
> switching their serial port from "send" to "receive", so if the client
> program is too fast, file transfers can fail. The solution to this is to
> tell the client program to pause for a sufficient number of milliseconds
> prior to sending each packet:
This only happens every dozen packets or so. A client that can resubmit a
NAK'd packet will be able to recover from this. If you watch a transfer
at high speeds, you'll see every few packets fail (for no apparent reason:
the link cable is a very clean line). Setting the flag you mentioned will
fix the problem.
> Postings on comp.sys.hp48 indicate that the HP-48 Kermit implementation
> "parses" incoming text-mode material on the fly, and appends the material
> from each incoming packet to a "string", resulting in a steadily
> deteriorating transfer rate, at least up to some point at which the HP-48
> dumps the string to storage and starts over with a new string. There's not
> much that the Kermit client can do about that.
Actually, it has to copy the *entire* received buffer for each packet,
from what I understand.
> Any other hints from HP-48 users will be appreciated; I'll be glad to
> collect them into an FAQ.
The '48 is very picky about some aspects of the Kermit protocol. Here are
a few additional points about the HP48's server:
- The only way to change the working directory is with a command packet
that reads: { Relative_directory_name } EVAL
- Each command packet will send back data containing a stack dump.
- Directory dumps are in the format:
---
{ Current_directory } Free_space
Object_name Object_size_bytes Object_type Object_CRC
... etc ...
---
- Error packets should contain CR+LF (#M#J) at the end of the string
- You can shut the HP48's server down with a 'G' packet, data "F"
/\/\att /\/\astracci mmas...@acs.ucalgary.ca
"Tout choses sont dites deja, mais comme personne n'ecoute, il faut
toujours recommencer."
Diego Berge
Hi,
PFJI
In article <wk4syi5...@jhuapl.edu>, coll...@jhuapl.edu says...
>
>> set carrier-watch off ; (Does the HP-48 assert DCD? If so, use ON.)
The 48 doesn't detect DCD.
>
>It has no hardware flow control, if that's what you mean.
>
>> set flow none ; (or Xon/Xoff)
>
>Should be none.
It does have. You can activate Xon/Xoff flow control by editing IOPAR
manually { x x 1 1 x } to activate xon/xoff both in transmit and receive. Read
the manual, it's in there.
Regards,
Diego Berge.
John H Meyers
As to the flow-control debate (Xon/Xoff vs. none) with HP48 Kermit,
I do not see how it could possibly hurt to leave it set to Xon/Xoff,
unless "control-character prefixing" were inadvertently
disabled even for Xon/Xoff, since in the absence of a buffer
actually becoming filled to the specified point, no Xoff will
get sent and no time will be wasted; however, not many people
are likely to have enabled Xon/Xoff flow control within
the HP48 itself, since to do so requires manually editing
the IOPAR variable in the HOME directory per directions
in the manual, which no one ever reads anyway :)
Being a conservative person, I always enable Xon/Xoff
flow control on both sides, just in case the theoretical
argument that it's impossible to trigger the condition
should ever fail on either side, which certainly would
cause a problem if it did, especially if the elected
block-check-type was minimal or none on either side.
People tend to forget that even "official" Kermit
"negotiates down" the "block check" option to the lesser of
what both sides propose, and that non-official implementations
of Kermit in various "terminal emulators" generally never even
state or give the user any option for choosing block checking;
at least the HP48 gives the user a choice (unfortunately defaulting
to 1, rather than 3, much as flow-control defaults to none).
The HP48 does support block-check-type 3, however, as it has
the same CRC algorithm built into its hardware.
As to parsing of ascii, the HP48 Kermit implementation embeds
two extra services not normally considered part of Kermit;
if the HP48 is told to send in "ascii mode," it both "decompiles"
(translates an internal binary object into ascii words) and translates
some or all of the ascii characters having decimal value 128-255
into "backslash-prefixed" codes (some digraphs, some numeric codes);
carriage-returns may also be inserted before linefeeds as this occurs.
Conversely, if the HP48 is told to receive in "ascii mode,"
it performs character translation (backslash-prefixed codes
into single characters) and then also "compiles" on the fly
(translating text words into binary internal objects), in which case
any syntax error terminates the transfer immediately (thus compiling
is performed per packet, rather than after receipt of the entire file).
When sending in "binary mode," no translation occurs, and no
slowdown occurs. When receiving in "binary" mode, the entire
file is received as a string; however, the appending of each
new packet to the string, copying the entire received string each time,
is what causes the slowdown (every now and then it may suddenly revert
to the original speed, perhaps after storing a large chunk of the
received string, or else after an internal "garbage collection").
I do not know for sure, but if the internal 256-byte default
HP48 I/O buffer is a fixed area, then no "garbage collection"
(or other processing) ought to be required in the middle of a packet;
otherwise one would expect to see more re-transmissions, especially
with flow-control set to "none," but generally none occur.
Only after the entire "binary" file is received does the HP48 take
one more step, unrelated to Kermit, in which it checks to see whether
the received file begins with a specific prefix "HPHP48-x" and if so,
whether all the rest of the received bytes constitutes a valid
internal HP48 binary object; if so, the HP48 delivers the
extracted binary object as its result, and otherwise it leaves
the received string as the result (thus allowing any computer
file to be received literally as a string, even if it does not
represent anything meaningful to the HP48).
As to the version of Kermit supplied by HP, the one I received with
my connection kit (and the only one still found posted on HP's FTP
and web site) responds as follows to the VERSION command:
IBM-PC Kermit-MS: 2.32/A 21 Jan 1989
Copyright (C) Trustees of Columbia University 1982, 1989.
I find this version to work perfectly with the HP48 in an MS-DOS
window under Win 3.1, although other people may report problems
under Win95, possibly due to improper configurations (I can furnish
a list of past postings about such failures and successes, if desired).
In fact, I am using this very Kermit at this very moment, inasmuch as
no other terminal emulator or Telnet program I have yet tried out
emulates the VT-100 as perfectly as does Kermit, and my connection
is via a login to various systems which require a VT-100 emulation.
Congratulations to the Kermit Project for a job long well done,
and even for still caring about the HP48 :)
-----------------------------------------------------------
With best wishes from: John H Meyers <jhme...@mum.edu>
Frank da Cruz
In article <wk4syi5...@jhuapl.edu>,: > Most Kermit programs prefix all control characters by default when sending
: > a file. Kermit 95 is the exception, since most Windows 95 users demand
: > "high performance". Kermit 95's default is to unprefix a fairly safe
: > subset of control characters.
:
: is control-char unprefixing. I will try it with mskermit when I get a
: chance. What command should I issue to mimic the K95 default?
:
Something like this:
SET CONTROL UNPREFIX ALL
SET CONTROL PREFIX 0 1 13 17 19 129 141 145 147
: > : I think the physical link is transparent to control characters. But
: > : perhaps the hp48 kermit software assumes prefixing.
: >
: > The cardinal rule of any communications protocol is "be conservative in
: > what you send, be liberal in what you receive". The HP48 has it backwards.
: > There is no prohibition in the protocol definition against sending bare
: > control characters,
:
: This seems to contradict "Kermit: A File Transfer Protocol", 1987 ed.,
: which states on page 248, under the heading Encoding Summary: "Prefix
: encoding for control characters is mandatory."
:
No good deed goes unpunished. The conservative original design of the
protocol (to protect users from nontransparent connections) resulted in
so much heckling from the ZMODEM contingent that we now allow the user to
specify a list of control characters that may be unprefixed. This is,
strictly speaking, in violation of the protocol definition, and as such
it is not (and, as explained previously, can not be) negotiated at the
protocol level.
Nevertheless, the sample code that accompanies the protocol definition
(op.cit., p.231) allows for bare control characters to be received.
: As long as you are cataloguing peculiarities, the HP48 sends packet
: sequence numbers that are larger than 63. One can compensate by doing
: mod63 before verifying. Is this right?
:
No. Packets numbers should be 0-63, period. The packet length field is
one byte long, and contains a printable character. Even if the receiver
chopped off the high bits from an incoming packet number, this would work
only up to packet 95, since the packet after that would be out of sequence.
Thus if it's true that HP does not wrap packet sequence numbers from 63 to
0, then it would appear that it could never, under any circumstances, send
files or objects that do not fit into 64 or 96 packets, depending on how
the Kermit receiver is coded.
- Frank
Frank da Cruz
There's a preliminary tip sheet for Kermit file transfer with the
HP-48 at:
http://www.columbia.edu/kermit/hp48.html
which is also accessible via the Kermit FAQ:
http://www.columbia.edu/kermit/faq.html
If anybody has any corrections, suggestions, or new material for
it, please let me know. Thanks.
- Frank
joe...@usa.net
Frank da Cruz wrote:
>
> If anybody has any corrections, suggestions, or new material for
> it, please let me know. Thanks.
The HP48's complete list of SERVER responses can be found at
http://www.dejanews.com/getdoc.xp?AN=109002555
-Joe-
Joseph K. Horn (1537) [13] <53> {NaN}
http://users.kcyb.com/joehorn/HP48.htm
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading
John H Meyers
Someone:
: As long as you are cataloging peculiarities, the HP48 sends packet
: sequence numbers that are larger than 63. One can compensate by doing
: mod63 before verifying. Is this right?
Frank da Cruz (who wrote the book:)
> Packet numbers should be 0-63, period. The packet length field
> is one byte long, and contains a printable character.
Could it be that the original writer did not account for
"adding 32" to the binary count value? My HP48 transfers files
requiring hundreds of packets, without problem, so we can
credit HP with not implementing a completely non-functional Kermit,
inasmuch as no one has ever reported a file which it could not
transfer (if it fits in memory).
Frank da Cruz
In article <wk67is4...@jhuapl.edu>,
Skip Collins <coll...@jhuapl.edu> wrote:
: I think I remember reading somewhere that there was some sort of
: problem between the kermit project and the hp48 designers. Is this
: true? If so, it's a shame that there could not have been closer
: cooperation between the two parties. These programming problems should
: have been fixed years ago.
:
HP is a big company with many parts. We have extraordinarily good
relations with some parts of HP. For example, C-Kermit is now an
offical, supported part of HP-UX. See:
http://www.columbia.edu/kermit/hp.html
We have not had such good luck with the calculator and palmtop divisions,
even though they put Kermit protocol in their products. We would like
to have a better relationship with them.
- Frank
Dan Kirkland
In article <wk4syi5...@jhuapl.edu>,
Skip Collins <coll...@jhuapl.edu> writes:
>f...@watsun.cc.columbia.edu (Frank da Cruz) writes:
>> set receive timeout 99 ; (see Note 1 below...)
>> set send pause 100 ; (see Note 2 below...)
>
>I don't think these are needed, your notes notwithstanding. I very
>rarely see packets retransmitted, which one might expect if there were
>a serious turn-around problem.
This seems to vary from person to person (machine to machine,
kermit to kermit, ...). Likely should leave it in for a default.
>> set file type text ; For HP-48 programs
>> set file type binary ; For all other forms of data
I think that binary mode will work for all HP48 transfers...?
dan
Jeffrey Altman
In article <wk3edv6...@jhuapl.edu>,
Skip Collins <coll...@jhuapl.edu> wrote:
: kirk...@ee.utah.edu (Dan Kirkland) writes:
:
: > Sadly, the HP48 REQUIRES control character prefixing.
: > All characters less than character 32, characters 127 to 159, and
: > character 255, ALL MUST BE PREFIXED!
:
: Just out of curiosity, despite the problems it causes on the hp48, is
: it ever permissible to unprefix 127 or 255? When I do
: set con unpre all
: They are not included. When I do
: set con unpre 127/255
: I get the error "Number is not in range of 0..31, 128..159"
:
: Skip Collins
C-Kermit and K95 both allow 127 and 255 to be unprefixed IF and
ONLY IFF the characters are not known to be dangerous. For instance
255 cannot be sent unprefixed on a telnet connection. 127 with some
forms of parity would be 255 so that is treated the same.
The MS-DOS Kermit rules are left over from a more conservative day.
Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
The Kermit Project * Columbia University
612 West 115th St #716 * New York, NY * 10025
http://www.kermit-project.org/k95.html * kermit-...@kermit-project.org