22 Feb
2013
22 Feb
'13
8:24 p.m.
OK, so I hacked a quick 'n dirty xmodem implementation together in RSI
BASIC on the QX10 so that I could transfer a few essentials over via the
serial link.
It worked on a few files, but I've found a couple of problem files where it
will consistently block when trying to send an ACK back to the sender
following a packet receive - in one file it's on packet 76 every single
time, while in the other it's always packet 161 (it receives the complete
packet OK, checksum is valid, packet sequence numbers are all good, but it
stalls writing to the serial port).
Any thoughts? I can't think of a reason why it should work fine on some
files, but barf consistently - and at different points - with these other
two. I did wonder if there was a particular byte encountered in these
packets which hadn't been seen previously in these files (or any of the
others I've sent successfully) which was somehow tripping up the underlying
serial code on the QX-10, but that's not the case. I suppose there might be
a particular magic *sequence* of bytes which is received and causing
problems, but that's harder[1] to check for.
Oh, I've disabled the disk-write code on the QX-10 just to rule that out,
too; it still fails even when it's just tossing received data away.
[1] hmm, although I could just zero out the problem packets and see if that
stops it happening, I suppose. Will report back.
cheers
Jules
22 Feb
22 Feb
10:30 p.m.
On 02/22/2013 07:24 PM, Jules Richardson wrote:
[1] hmm, although I could just zero out the problem
packets and see if that
stops it happening, I suppose. Will report back.
Well... that's confusing! It seems that it's not a particular sequence of
data as such; it stalls when the packet checksum byte read from the sender
happens to be 19d - which is XOFF.
What I don't get is that my packet read code is basically:
/// read packet sequence and "anti-sequence" bytes prior
to this using byte(3) ///
260 cksum = 0
270 for i = 0 to 127 step 1
280 poke &A000 + i, byte(3)
290 cksum = cksum + db
300 next i
310 cksum = cksum AND 255
320 ckr = byte(3)
/// see if computed and read checksums match at this
point; send ACK or NAK to the sender accordingly. ///
('byte(3)' is just a blocking call which returns the next byte
from the QX10's serial port. The pokes are to an area of mem I
set aside for a receive buffer).
There's no difference in the way I read packet sequence numbers, packet
data, and the checksum byte - it's all done using byte(3) calls - and yet
the presence of an XOFF char within the sequence byte (i.e. receiving
packet #19) or within the packet's actual data doesn't cause a problem, but
it does when #19 happens to be sent as the checksum byte.
It's boggling my brain... it seems more like a problem on the sender's side
(i.e. the sender is doing something abnormal when sending 19d as a checksum
byte that it doesn't do when sending 19d at other times) - but I'm using
the stock linux 'sx' command, which I thought had been around for pretty
much as long as linux has, and so surely something as fundamental as this
would have been found and fixed years ago...
cheers
Jules
23 Feb
23 Feb
3:24 a.m.
On 23 February 2013 03:30, Jules Richardson
<jules.richardson99 at gmail.com> wrote:
Well... that's confusing! It seems that it's not a particular sequence of
data as such; it stalls when the packet checksum byte read from the sender
happens to be 19d - which is XOFF.
Argh... you are bringing back lots of horrible memories about serial
systems and flow control...
Two thoughts:
I presume you've gone through all the options relating to the serial
ports on both systems to disable all types of flow control? (not just
soft, as some systems like misleading you and implement both anyway.)
Would you be able to code up a crc-16 test rather than checksum?
less chance of hitting 19d on the last byte..
Rob
11:01 a.m.
On 02/23/2013 03:24 AM, Rob wrote:
On 23 February 2013 03:30, Jules Richardson
<jules.richardson99 at gmail.com> wrote:
Simple solution, SLOW DOWN the data rate until it works.
Flow control is only needed in systems that cannot handle high rates of
traffic.
On a lot of the older micros hardware flow control was best if available as
the system often was so slow it could not keep up or send xoff in a timely
fashion. Also pre enhanced 16450 usart most only could buffer maybe
1 to 3 chars in the part.
Allison
Allison
Well... that's confusing! It seems that
it's not a particular sequence of
data as such; it stalls when the packet checksum byte read from the sender
happens to be 19d - which is XOFF.
Argh... you are bringing back lots of horrible
memories about serial
systems and flow control...
Two thoughts:
I presume you've gone through all the options relating to the serial
ports on both systems to disable all types of flow control? (not just
soft, as some systems like misleading you and implement both anyway.)
Would you be able to code up a crc-16 test rather than checksum?
less chance of hitting 19d on the last byte..
Rob
1:07 p.m.
On 2/23/13 9:01 AM, allison wrote:
On 02/23/2013 03:24 AM, Rob wrote:
I would definitely agree with that! I have a Xerox 820-II that simply won't
transfer anything at higher than 1200 baud, even though it has options for
data rates up to 19200. Text transfer was a different story and it would
accurately accept text up to 9600, but on binaries, 1200 was max for a
successful transfer. ;)
Dave Land
Land Computer Service
On 23 February
2013 03:30, Jules Richardson
<jules.richardson99 at gmail.com> wrote:
Simple solution, SLOW DOWN the data rate until it works.
Flow control is only needed in systems that cannot handle high rates of
traffic.
On a lot of the older micros hardware flow control was best if available as
the system often was so slow it could not keep up or send xoff in a timely
fashion. Also pre enhanced 16450 usart most only could buffer maybe
1 to 3 chars in the part.
Allison Well... that's confusing! It seems that
it's not a particular sequence of
data as such; it stalls when the packet checksum byte read from the sender
happens to be 19d - which is XOFF.
Argh... you are bringing back lots of horrible memories about serial
systems and flow control...
Two thoughts:
I presume you've gone through all the options relating to the serial
ports on both systems to disable all types of flow control? (not just
soft, as some systems like misleading you and implement both anyway.)
Would you be able to code up a crc-16 test rather than checksum?
less chance of hitting 19d on the last byte..
Rob
2:10 p.m.
On 02/23/2013 10:01 AM, allison wrote:
Simple solution, SLOW DOWN the data rate until it
works.
Flow control is only needed in systems that cannot handle high rates of
traffic.
On a lot of the older micros hardware flow control was best if available as
the system often was so slow it could not keep up or send xoff in a timely
fashion. Also pre enhanced 16450 usart most only could buffer maybe
1 to 3 chars in the part.
Yes, having slept on it this seems sensible - the transfer rates I'm
getting at 9600 seem to be far worse than I'd expect even with the receiver
having the overhead of a slow BASIC interpreter, suggesting that the link
might be almost saturated with XON/XOFF flow control chars. It still seems
odd that receipt of 19d as the checksum byte trips it up, when 19d at other
times doesn't; I've looked at the Linux sx code now and it doesn't seem to
be doing anything special when it sends the checksum byte that it doesn't
do for other data.
I don't think I can turn off software flow control from RSI basic (the
manual suggests that it's always present), and there seems to be no way of
changing the line speed via the basic environment either - but I think
there is a TPM util (just not included in the TPM 'install' on the RSI
disk) to set the line parameters, so I'll go hunting for that. Hopefully
the RSI interpreter honors whatever the OS has previously set up, rather
than resetting to its own defaults at startup.
Worst-case I suppose I can hack the sx code on the Linux side and introduce
some time-wasting loops so that it doesn't send as fast across the 9600
link, but it'd be nice to avoid having to do that if I can.
cheers
Jules
25 Feb
25 Feb
2:01 p.m.
On 02/23/2013 01:10 PM, Jules Richardson wrote:
On 02/23/2013 10:01 AM, allison wrote:
Well, I found the util and dropped the line speed down to 1200 baud - and
it still dies at exactly the same point!
I seem to have a workaround in that I found a modem.sys util with a file
transfer mode that's 'compatible enough' with xmodem (it always times out
on the first packet receive, but then does the right thing and gets the
sender to re-send, after which everything transfers without trouble).
I'm still puzzled by why this was failing though; something somewhere was
obviously getting confused, but it's hard to tell what the root cause is
(or quite why it only affects the checksum byte and not other transmitted data)
Once I've got MEX or IMP set up on there (as suggested by Gene) then it
doesn't really matter, I suppose. :-)
cheers
Jules
Simple solution, SLOW DOWN the data rate until it
works.
Flow control is only needed in systems that cannot handle high rates of
traffic.
On a lot of the older micros hardware flow control was best if available as
the system often was so slow it could not keep up or send xoff in a timely
fashion. Also pre enhanced 16450 usart most only could buffer maybe
1 to 3 chars in the part.
Yes, having slept on it this seems sensible - the transfer rates I'm
getting at 9600 seem to be far worse than I'd expect even with the receiver
having the overhead of a slow BASIC interpreter, suggesting that the link
might be almost saturated with XON/XOFF flow control chars. It still seems
odd that receipt of 19d as the checksum byte trips it up, when 19d at other
times doesn't; I've looked at the Linux sx code now and it doesn't seem to
be doing anything special when it sends the checksum byte that it doesn't
do for other data.
I don't think I can turn off software flow control from RSI basic (the
manual suggests that it's always present), and there seems to be no way of
changing the line speed via the basic environment either - but I think
there is a TPM util (just not included in the TPM 'install' on the RSI
disk) to set the line parameters, so I'll go hunting for that. Hopefully
the RSI interpreter honors whatever the OS has previously set up, rather
than resetting to its own defaults at startup.
4164
days inactive
4166
days old
6 comments
4 participants
participants (4)
-
ajp166＠verizon.net -
jules.richardson99＠gmail.com -
robert＠irrelevant.com -
xmechanic＠landcomp.net