Image Map Image Map
Page 3 of 3 FirstFirst 123
Results 21 to 29 of 29

Thread: Small generic kermit program .hex

  1. #21
    Join Date
    Jun 2016
    Location
    Guisborough, England
    Posts
    235

    Default

    What speed are you using? I'd usually start with a slower speed and work up.

    Whar are you trying to send. ASCII or Binary? Dows this make any difference?

    What are the error messages,? They are supposed to give clues to you, they give clues to us as well! Which end of the link is giving the errors?

    Geoff
    Vintage Devices: Epson HX-20/TF-20, Amstrad PCW 8256 (with extras), 386 and 486 PCs with 5.25 and 3.5 floppy drives, Pentium 75 with Roland LAPC-I midi card

  2. #22
    Join Date
    Aug 2009
    Location
    Oslo, Norway
    Posts
    1,343
    Blog Entries
    3

    Default

    How are you starting the transfer? Older versions of the Kermit programs didn't support automatic receive, so you have to manually start receive at the remote end, switch back to local and start send. I'm going by memory, and it is a few years since I did this last so I might have details wrong.
    Torfinn

  3. #23
    Join Date
    Mar 2013
    Location
    Chaffee, MO
    Posts
    1,445

    Default

    Sure, Check the Signal states for RTS and DTR on both ends. They MUST be correct for each port (on both ends of the cable)
    for Hardware Handshaking. Or Looped Back RTS to CTS on both ends and use XON/XOFF for control of data. Hardware must
    be satisfied to get Transmissions to receiving equipment.

    Detailed PM sent.

    Larry

  4. #24

    Default

    Larry - I got your PM thanks but I'm in null modem mode, and I'm running both ends as XON/XOFF and only 9600baud


    I don't have a CRT as the cheap VGA adapter I purchased doesn't do MDAso I'm running serial into Putty on the Linux system. I'm thinking that running the CRT over the serial port as well as Kermit may be corrupting up the data being sent. But then I'm trying to reconcile that with a scenario of a remote Kermit connecting to a host. All that has is a single serial line so once the Kermit session is established on the host (CP/M) the remote Kermit session (Linux in my case) should be able to control the Kermit on the host and request files.

    Here are some screen shots.

    Kermit on Remote (Linux)

    Screenshot from 2020-01-26 11-28-52.jpg

    Connect to Host (CP/M)

    Screenshot from 2020-01-26 11-29-16.jpg

    Directory on Host and request to send a file

    Screenshot from 2020-01-26 11-30-23.jpg

    File transfer screen with no data sent and errors

    Screenshot from 2020-01-26 11-32-39.jpg

    Cancel and back to session on remote (Linux)

    Screenshot from 2020-01-26 11-33-38.jpg

    The spurious characters on this last screen look like running at the wrong baud rate but as the terminal session works I must have a good connection

    Maybe its a case of my conceptual view of how Kermit works is getting in the wy of how it actually works.

    Pete

  5. #25

    Default

    Did you try different parity bits? Also, how about stop bits?
    Dwight

  6. #26

    Default

    At the risk of sending this discussion in the wrong direction, as I recall CP/M kermit does not support server mode and so the CP/M system must be the initiator (client). What we would do was:

    Code:
    1) Start KERMIT on CP/M
    2) CONNECT to remote (Linux)
    3) Login, etc, and get a shell on remote
    4) Set current directory as desired on remote
    5) start C-kermit in server mode
    6) "break" back to CP/M kermit
    7) send/recv files as needed
    8) issue "end server" command (I forget what it was)
    9) CONNECT to remote (Linux)
    10) cleanup and logout
    11) "break" back to CP/M kermit, end kermit
    Step (3) requires that, on Linux, you have a "getty" running on whatever TTY this is (or otherwise arrange for a shell to attach to the TTY).
    - Doug

  7. #27

    Default

    Doug

    Thanks; the fact CP/M may not support server mode is useful. And thinking about it it is probably better for Kermit 4.11 (CP/M) to be in control rather than C-Kermit 9.0.3 (Linux) as the later version is more likely to be backward compatible and work with the subset of Version 4.11.

    I do believe I tried a connection from the CP/M end and the transfer screen came up on the C-Kermit end but with the same results. A high error/retry count but no data passed.

    However, it is all on hold at the moment as my hard drive has a boot problem and the only way I can resolve it is using the low level ROM BIOS sector read write routines. Although the BIOS can redirect to the TTY it is configured for CRT and I don't have one, I could redirect when I had CP/M running but not now. The solution is a MCE2VGA adaptor, which is on its way from Serdaco in Belgium.

    It could be a couple of weeks before I get back to this.

    Pete

  8. #28

    Default

    Now I've got the hard disk problem sorted, the console running through a MCE2VGA adaptor and Gotek disk functionioning I thought I'd give Kermit 411 another go. It worked just about straight away, Set port TTY, Set Flow On (XON/OFF), Set file Binary and I was away. In my system the baud rate is set outside Kermit.

    The problem was that Kermit wants the serial port to itself, which is probably to be expected.

    Pete

  9. #29
    Join Date
    Aug 2009
    Location
    Oslo, Norway
    Posts
    1,343
    Blog Entries
    3

    Default

    Yes, that is the way kermit works.
    Torfinn

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •