• Please review our updated Terms and Rules here

XMODEM question

W

Wawavoun

Experienced Member
Joined
May 17, 2020
Messages
69
Location
Alsace Yo !
Hi All,

I am facing a strange xmodem problem.

On one side I have a vintage 68008 board with a 16C750 which is working well for serial console to Linux Minicom.
The 16C750 is interfaced with a MAX232 so I use a serial db9 to usb adapter.

The board run SK*DOS 68K with the TMODEM program.
I have already used this combination on other computer with a different serial port and till now this has ever well worked.

Sending files from the board to the pc everything is ok. Minicom get the file smoothly.
In the reverse direction (pc to board) the transfer wont start.
I run tmodem on the board which go then in a waiting position (he say "he say you have then second") then I run xmodem send on Minicom and everything stay like that till I start to got time out message from Minicom.

If anybody has a good idea how to debug the problem ? Please not I have no access to tmodem source code...

Thanks.
Philippe
 
Usually, you would start Xmodem on the transmitter first which will wait for an ACK/NAK, then start the receiver which will send the NAK as soon as it starts. The receiver should keep re-sending the NAK every 10 seconds though.
Try starting in the reverse order, Minicom send first, then TMODEM, making sure to use TMODEM's -R flag (or the whatever it needs to start as a receiver).
 
I have a version of Kermit for the 68k. I've never used it because it requires handshake on the serial connection which I find troublesome. I could provide an S-rec file.

I wrote my own file transfer programs: "store" for ASCII material, and "srin" to process S-records. They were written in assembler using 68K CP/M system calls. They are for PC to 68k transfers. The capture functions of minicom (^a L) are what I find most useful for 68k to PC transfers. I use a Linux application I call "trickle" to throttle the transfers. It is written in C.

Roger

P.S. I think I see that you were involved with 2732 issues?? Maybe you have some words of wisdom about that?
 
The problem is that I loose the console as soon as I ask to Minicom to start a xmodem transfer.
So I have no way to run the receive command on 68008 board side.
 
The main thing I have learn about uvprom (2716, 2732...) is that some cells could be in an intermediate state if the erasing time under uv is to short.

The symptom is that, depending about the Vpp voltage (+5V or Gnd) during reading, some bits are one or zero. Of course the Vpp programming high voltage is not involved at this moment.
Reading the datasheet this should never be like that. The datasheet usually say 'dont care' about this voltage during reading. And this is the case if the erasing is correct.

A good thing that can be do at the first erasing you make with an eprom is to regularly read the eprom (every 5 mn ?) and as soon as you get all bits to one then add at least 15 mn before to stop the eraser.

I think an intelligent eraser could do that automagically (a board with a support connected to an Arduino Mega and a relay and that's it...). If you erase several uvprom at the same time this is a little bit more complicated.

At this moment I leave my eprom 45 mn under uv so I am sure and I have never got bad surprise since I do that.
Of course may be the eraser quality is involved in this history... and old chip quality also !
 
Trying to find the problem with strace the difference I found is that after transfer init they come in the log

ioctl(3, TIOCMGET, [TIOCM_DTR|TIOCM_RTS|TIOCM_CTS|TIOCM_CAR|TIOCM_DSR]) = 0

in the bad case and

ioctl(3, TIOCMGET, [TIOCM_DTR|TIOCM_RTS]) = 0

in the working case.

I am at the end of my knowledge here. What does these sentences mean ? What is the difference between them ?

I assume these differences come from the usb/serial driver ?

What is the way to change this behavior (if there is one) ?

Thanks and regards.
Philippe

ps : - I have try to slowdown the connection, enable or disable rts-cts etc... and no change !
- The problem is the same with a FTDI FT232RNL usb-RS232 interface.
 
If TMODEM is in receive mode, it should be sending the NAK character when it starts and every 10 seconds after.
Do you see any characters in Minicom if you don't run xmodem send?
Try starting minicom with the -H flag to see the hex character codes.
If you aren't receiving the NAK character every 10 seconds, then TMODEM is not properly in receive mode.
 
Using a logic analyzer I have look on what flow on the serial line.

What you say is exactly what I see with the working device (same os and also using TMODEM).

On the bad one I can see that Minicom + sx send the first packet but then never receive the ACK from the board.
I have continue to try various configuration and again try to slow down the connection (115200 -> 2400 bauds)... and then see some change and strange display on the board side.
Its like if a receive buffer flush when TMODEM terminate with an error. But fifo on the TL16C750 is disabled so normally no buffer is involved in this history.
I have no idea how to explain this.
The serial port is perfectly working with the console and I think with rts/cts flow control no byte can be dropped.

I think that without the source file of TMODEM things will become hard...

I will try the -H option tomorrow.
 
Wawavoun -
Just a thought about how you are wiring the connection between your 68k SBC and your "Host" PC.

I have sometimes heard of there being problems with RS232 -to- USB Adapters. So I am just wondering
if you have tried NOT using the USB Device and instead have used ONLY RS-232 Port on SBC to ONLY
RS-232 on the "Host" PC ?? If you did try this, How did it go ?? If you have not yet eliminated the USB
"variable", then I suggest that you give it a try. Requires an actual RS-232 Serial Port in your "host" PC.

I acknowledge hearing that "this has always worked in the
Past. I hear you. I am simply trying to suggest that you try "Debugging" this WITHOUT the USB Converter.
Often-Times in the past, I have debugged "stuff" by changing the "testing conditions" and "simplifying" things.
It is possible that one thing that "went bad" was the USB Converter itself.

It's been a while since I had to
debug RS-232 PC-to-PC Data transfers, way back in about the 1980s. I had a Serial RS-232 Cable between
a Sage-2 68000-based "personal computer" and an old Apple-II Computer, Both using RS-232 serial ports.

The Apple end had
to use 6502 Assembly Language to be "fast enough" whereas the Sage-2 68000 end was running in "regular"
non-assembly Language. Both of them were running the UCSD Pascal P-system OS but it could have been any
other OS being used at both ends. My point being it was Serial Port RS232 -serial cable- Serial Port RS-232 and the cable was a "simple" RS-232 cable which May, or May Not, have been using Handshaking like RTS / CTS.

So I am simply trying to "eliminate variables" in testing, and, in this case, that means removing the USB "variable" from the "equation".
My best wishes for your success,
Harry S. Speer
 
I've used boards before in which the provided XMODEM bits weren't 100% compliant, one of the control bytes was not being sent back, I think whichever happens from the receiving side after one frame has been transmitted. I wrote a modified tool that simply waited a reasonable amount of time before sending the next frame and had no trouble after that. Not sure that's what is happening in your case, but may be worth trying to send stuff without awaiting the ACK or SOH or whichever it was that is involved.
 
Has it worked before?
Meaning... have you configured it correctly?
IIRC XMODEM had configuration params for different UARTS.
As the control bits were different among them due to early lack of standardization.
-J
 
There's a newer version of XMODEM written by Martin Eberhard (sp?) that works from a small config file, where you define the UART params. Very easy to use. The only downside that I've found is that the config file seems to have to be in the same directory as the executable? Maybe I'm using it wrong?

Roger
 
The UART params should be a separate concern from the XMODEM protocol, that's handled by your terminal driver, not XMODEM generally. For instance "sx" is a canonical XMODEM send utility, you typically invoke it in the context of a cu (uucp) or GNU screen session with stdio hitting the XMODEM daemon or listening process. Of course if you have access to your target as a file directly, you can also just invoke sx and use < and > redirects to connect to your device file.

Of course ymmv with non-UNIX platforms but I've found the concerns of serial protocol vs XMODEM protocol are quite separate in UNIX contexts, like HTTP vs TCP.
 
Some of the later XMODEM programs had conditional assembly. By appropriate commenting/uncommenting of lines, in the source, you could then assemble it for the proper UART. I find them much handier than having another config file lying around you have to keep track of.

And while the UART params are not part of the XMODEM protocol (of course), the protocol itself is merely a technical abstraction. The early XMODEM code was written for the 8080 in assembly for CP/M not *NIX. And the params are actually there in the code.

When running XMODEM between vintage systems, and modern *NIX boxes, the *NIX usually works fine. It's the old system that needs to be configured unless you are lucky enough to have some of the original disks with XMODEM already on them, properly configured.

Both ends have to work for successful transfers.

-J
 
Last edited:
You must log in or register to reply here.
Back
Top