I tried to adapt the kermit program in UZI180.

The program code is in the repository https://github.com/nikitinprior/Kermit_UZI180

The attempt was once again unsuccessful.
The program is working. The remote server sees it, but the exchange does not occur.

I hope there are knowledgeable people on the net who can help in solving this problem. I hope so.

Andrey Nikitin

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

четверг, 2 июня 2022 г. в 01:41:56 UTC+3, Андрей Никитин:

I tried to adapt the kermit program in UZI180.

The program code is in the repository https://github.com/nikitinprior/Kermit_UZI180

The attempt was once again unsuccessful.
The program is working. The remote server sees it, but the exchange does not occur.

I hope there are knowledgeable people on the net who can help in solving this problem. I hope so.

Andrey Nikitin

I was able to change the source code of the unix kermit version 3.0(1) 11/5/84 program to compile with gcc. With the help of conditional compilation, I added more modern code for working with the serial port based on termios. kermit compiled with one
warning and produced an executable.

As a second computer, I used an old 386SX with a COHERENT unix-like operating system. To compile the program, K&R style code was added, since the compiler of the COHERENT operating system does not support the ANSI style of describing function prototypes.

The program compiled successfully on the COHERENT operating system without any warning message. The termios interface was also used to set up serial lines.

As a result, I was able to transfer files from MacOS MacBook Pro to 386SX with COHERENT. Normally binary and text files are transferred. To test the program, I used ckermit on the MacBook Pro and 386SX side, and kermit version 3.0 on the opposite side.
In all cases, sending and receiving files was completed successfully.

I compiled the same source file with the kermit.c program using the Hitech C v3.09 compiler for CP/M for the UZI-180 operating system. In this case, the older BCD-style RS-232 line configuration code was used with the included file sgtty.h, since termios
functions are not implemented in the UZI-180 operating system. The source code compiled without a single warning message, but failed to transfer files from the MacBook Pro to the P112 microcomputer, and vice versa.

The kermit version 3.0 program is quite simple and its source code is divided into several parts. Only a few functions depend on how the serial lines are configured. To make it easier to work with the program code, I created one common file from three
original files, since my program compiles only for UNIX.

The successful operation of the program in MacOS and COHERENT gives me the right to believe that the kermit protocol works fine.

Problems arise when setting up a serial line in the sgtty.h style on the UZI-180 side.

Most likely, it is not possible to switch the serial line to RAW mode, and when transmitting packets using the kermit protocol, they are distorted beyond recognition. When sending a file from MacOS to UZI-180, the receiving side does not recognize the
sent packets at all. In the opposite direction, they come in a distorted form and are not perceived by the receiving party. After 10 attempts have been exhausted, both programs exit with a message about an unsuccessful attempt to send and receive the
file.

I'm not at all familiar with how the operating system kernel works with serial lines. Unfortunately, I do not have the opportunity to test the program on any old operating system with the sgtty.h interface and make sure that it works. All the code for
these functions remained in its original form, and this suggests that the source of the problem is the UZI-180. The kernel source code seems to allow serial lines to be converted to RAW mode. It is clear that this part of the UZI-180 either contains
errors or is not finished.

Not being a system programmer, it is difficult for me to determine the cause of the malfunction and eliminate it.

Unfortunately UZI-180 only works on P112 microcomputer. There aren't many of them. And those who have them either lack the necessary knowledge, or have no interest in a unix-like operating system.

Maybe there are some old school programmers out there who remember how it should work and looking at the serial line driver source code will be able to tell what's wrong and how to fix it.

After restoring the source code of the Hitech C v3.09 compiler for CP/M, it became possible to make it native to UZI-180. The presence of the make program allows you to develop programs in C and Z80 assembly directly on this microcomputer in a fairly
friendly environment.

Despite the existing problems, I hope to overcome them sooner or later. Source code is easier to edit on modern computers. It is faster and more convenient to compile the source code using a cross compiler created from the restored code. It remains to
implement a more or less convenient way to transfer code or programs from a modern computer to the UZI-180.

There is already a kermit version 3.0 program for this. It remains to make it work properly. I naively hope for help from outside. Sometimes miracles do happen.

Andrey Nikitin

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

When sending a file from MacOS to UZI-180, the receiving side does not recognize the sent packets at all. In the opposite direction, they come
in a distorted form and are not perceived by the receiving party.

The kermit protocol is designed to run over links that are not 8-bit
clean, and in environments where many control characters are blocked.
It should even work in line-mode environments, since each packet ends
with a carriage return.

Several things could be informative here:

1. Find a way to log all serial port traffic. This could be done using existing facilities in the kermit programs, by modifying the programs to
make a crude log to disk, or by sniffing the serial line.

2. Kermit has a number of options for managing difficult communications environments, for example, some control over which control characters
need to be escaped, ability to set packet start characters, etc. Some
programs have more controls than others. Modifying settings to be very conservative -- short packet lengths, escape as many control characters
as possible, etc might be productive.

3. Some smaller micros have trouble keeping up with faster line speeds.
A P112 isn't particularly slow, but some combination of bad serial i/o
code, small buffers, and higher line rates might be the issue. Does the
thing work better at relatively low speeds, like maybe 1200 baud?

De

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

[email protected] schrieb am Mittwoch, 21. September 2022 um 01:44:14 UTC+2:

As a second computer, I used an old 386SX with a COHERENT unix-like operating system.
To compile the program, K&R style code was added, since the compiler of the COHERENT
operating system does not support the ANSI style of describing function prototypes.

This was not necessary, for this we use
https://github.com/udo-munk/unproto
Includes support for COHERENT 3.x and 4.x systems.

I'm not at all familiar with how the operating system kernel works with serial lines. Unfortunately,
I do not have the opportunity to test the program on any old operating system with the sgtty.h interface
and make sure that it works.

Yes you can test this with COHERENT 3.2. This was a clone of UNIX V7 and so still uses the
sgtty serial line discipline, termio and termios came later with UNIX System V and so are
also implemented in the later COHERENT 4.x releases.
For testing you can run a COHERENT 3.x VM with Qemu, allows access to the serial ports.
Some documentation is here: https://www.autometer.de/unix4fun/coherent/coh_qemu.html
Practical usage shown in a video here: https://www.youtube.com/watch?v=kXQa5RBa8fs

The Kermit version on the COH 3.x boxes is even older from 1983, still in K&R C and known and
proved to work OK, also against modern Ckermit versions. You could try to build this one and
see it it work better.

Maybe there are some old school programmers out there who remember how it should work
and looking at the serial line driver source code will be able to tell what's wrong and how to fix it.

Well, I know all any anything about the various UNIX serial line functionality, because
I have used that for decades for communication, but I don't have any UZI system and no time
or urgend needs to get one, so no idea about the implementation or bugs.
I would sugest to write simple test programs that set the tty into raw mode and verify with
a terminal emulation what is happening, should give at least an idea if it works or not.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)