Image Map Image Map
Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 29

Thread: Small generic kermit program .hex

  1. #11
    Join Date
    Oct 2011
    Location
    Bedford, NH, USA
    Posts
    1,606

    Default

    I've used PCGET and PCPUT from DERAMP.com heavily. They both are small programs that TeraTerm can slowly send into the editor running on CP/M, and from there, you fix the I/O port addresses, and assemble, and you're off and running.

    Here's links to the Northstar versions that he has available:

    http://deramp.com/downloads/north_st...cput/PCGET.ASM
    http://deramp.com/downloads/north_st...cput/PCPUT.ASM

    IMO, these are much easier to get running and to use than Kermit.

    Good luck!

    smp

  2. #12
    Join Date
    Aug 2017
    Location
    New Mexico, USA
    Posts
    113

    Default

    Quote Originally Posted by deramp5113 View Post
    "Generic" Kermit works by doing all I/O using standard CP/M calls. For this to work, the IOBYTE feature must be implemented in the BIOS. Kermit communicates with the remote computer through the PUN and RDR devices, so each time Kermit is started, the SET PORT command must be issued to properly assign the physical I/O device to the RDR and PUN. For example, enter the following command at the Kermit command prompt (not the CP/M prompt): SET PORT UR2. Note that UR2 is just an example - you’ll have to figure out which IOBYTE device name is assigned to the serial port you’re using for transfer.

    If IOBYTE is not fully implemented in your BIOS - including indirection through RDR and PUN - it won’t work.

    Mike
    I have XMODEM working on my homebrew Z80 hardware, but a friend really want to use Kermit, so I'm trying to figure out how to implement IOBYTE BIOS on CP/M 2.2. Is IOBYTE BIOS additional software above and beyond the device drivers for PUNCH, READER, LIST, and LISTST?

  3. #13

    Default

    Hi Plasmo

    Chuck's going to answer I'm sure, but no, IOBYTE is not an additional bit of software you can easily add. What it is is a specific location in memory (0003h) that tells the BIOS what physical device is associated with which logical device.

    So for example, you might have a serial port that you can access through the PUN: (punch) virtual device, but if IOBYTE is properly implemented you can redirect that to (for example) a parallel port by issuing a simple command (generally, STAT PUN:=LPT:). More details here: http://www.gaby.de/cpm/manuals/archi...#Section_1.6.1

    Your BIOS should then examine the IOBYTE to determine which port to send data to, when asked to send to PUN:.

    For the full low down, read this section of the CP/M Alteration Guide: http://www.gaby.de/cpm/manuals/archi...tm#Section_6.6

    However... as you can see, "implementing IOBYTE" means adding code to the BIOS that interprets what is in location 0003h before doing any I/O, and reacting appropriately; and not all vendors bothered to do this.

  4. #14
    Join Date
    Aug 2017
    Location
    New Mexico, USA
    Posts
    113

    Default

    Oh, I see. So let say all I have is 2 serial ports, one serial port is assigned to TTY:, CRT:, BAT:, the second serial port is assigned to the remaining devices. In the BIOS for CONSOLE, READER, PUNCH, LIST, I should first check the corresponding IOBYTE fields (at location 0x0003) then call the assigned serial port driver. Right?
    Bill

  5. #15

    Default

    Yep, more or less.

    New BIOS modders are advised to read the CP/M Alteration Guide.

    That’s the best bit of advice I received (from ChuckG) when writing the uIDE drivers.

  6. #16

    Default

    An old thread but not ancient. I have the same problem with Kermit411. It is too big for my 64kB Homebrew running CP/M 2.2

    I have just recovered my machine from my loft and its been up there about 25 years. I built it about 35 years ago. It has a 10Mb SASI/SCSI1 hard drive and although it also has interfaces for 5.25 and 8" floppy's the hardware and the media are long gone. A few minor problems getting it running but that was more about me trying to remember what I'd done.

    To get CP/M 2.2 to accommodate the drive I have segmented it as 4 drives (A and the files under user #. The hard drive is creaking a bit and I want to get everything off asap before it finally gives up. Doing individual file transfers is going to take too long so I'd prefer something that I can use wildcards and leave it to copy all the files over the serial link.

    The receiving end is is Ubuntu 18.04

    Any suggestions please?

    Pete

  7. #17

    Default

    Quote Originally Posted by Doubletop View Post
    An old thread but not ancient. I have the same problem with Kermit411. It is too big for my 64kB Homebrew running CP/M 2.2

    I have just recovered my machine from my loft and its been up there about 25 years. I built it about 35 years ago. It has a 10Mb SASI/SCSI1 hard drive and although it also has interfaces for 5.25 and 8" floppy's the hardware and the media are long gone. A few minor problems getting it running but that was more about me trying to remember what I'd done.

    ...............

    Any suggestions please?

    Pete
    I'm going to answer my own question. I've had another look at the Columbia University Kermit project site as it seemed strange to me that the build for CP/M 2.2 was bigger than a 64k system could load. The original poster has seen the 67K .hex file and asked how it could be loaded on a 64k system. Thats because it is in Intel Hex format so will be way bigger than the actual image.

    In my case I downloaded the CPSKER.HEX file, with PIP (PIP CPSKER.HEX=TTY: [H] ) and didn't get any complaints from PIP. When I loaded it with BUG (DDT equivalent) it told me it was too big. I now find that my serial port isn't handshaking so I was loosing parts of the file, corrupting it.

    So todays problem is getting a reliable CTS/RTS handshake working and then hope that KERMIT4.11 (latest release for CP/M80) is backwardly compatible with the latest Kermit version 8 or 9 that I'll have on my Ubuntu system.

    In the meantime any comments gratefully recieved.

    Pete

  8. #18
    Join Date
    Oct 2016
    Location
    Dutchess County, New York, USA
    Posts
    77

    Default

    Quote Originally Posted by Doubletop View Post
    I'm going to answer my own question. I've had another look at the Columbia University Kermit project site as it seemed strange to me that the build for CP/M 2.2 was bigger than a 64k system could load. The original poster has seen the 67K .hex file and asked how it could be loaded on a 64k system. Thats because it is in Intel Hex format so will be way bigger than the actual image.

    In my case I downloaded the CPSKER.HEX file, with PIP (PIP CPSKER.HEX=TTY: [H] ) and didn't get any complaints from PIP. When I loaded it with BUG (DDT equivalent) it told me it was too big. I now find that my serial port isn't handshaking so I was loosing parts of the file, corrupting it.

    So todays problem is getting a reliable CTS/RTS handshake working and then hope that KERMIT4.11 (latest release for CP/M80) is backwardly compatible with the latest Kermit version 8 or 9 that I'll have on my Ubuntu system.

    In the meantime any comments gratefully recieved.

    Pete
    If you have 8251 serial port chips then make sure the status byte checks for CTS. I had to change the checking to look for all RS-232 signals for a couple of S-100 CPU boards that were set up for Xon/Xoff flow control, which I wasn't using, when trying to use the 8251 pushed to 19.2 baud rates.

    Or slow down the transfer speed until there's no buffer overflow. If using 19,200 try 9,600 etc.
    Crazy old guy with a basement full of Pentium 1 laptops and parts

  9. #19

    Default

    Quote Originally Posted by DeltaDon View Post
    If you have 8251 serial port chips then make sure the status byte checks for CTS. I had to change the checking to look for all RS-232 signals for a couple of S-100 CPU boards that were set up for Xon/Xoff flow control, which I wasn't using, when trying to use the 8251 pushed to 19.2 baud rates.

    Or slow down the transfer speed until there's no buffer overflow. If using 19,200 try 9,600 etc.
    Strange as it may seem I'm using a 6850. My system started life grafted to a UK101 and the 'umbilical' was cut once it was able to stand on its own two feet. But hardware handshaking is the way I'm going. Yesterday I managed to get all the source off the CP/M system and onto a PC so now I've got a starting point. Today I'm going to resurrect the Eprom programmer and see if it will programme a 2716/32 I can then look at tweaking the BIOS. I'm currently running at 9600 but had tried it down to 300 and still the same problem, particularly on the disk writes.

    Slowly moving forwards

    Pete

  10. #20

    Default

    Well I’ve leapt forward since my last post. The Gotek drive arrived and I’ve got it working for now with small disks. That allows me to move files back and forth in small numbers which has meant I can get Kermit 80 onto my CP/M machine.

    Everything you need is in this Zip file, http://www.columbia.edu/kermit/ftp/archives/cpm80.zip including the MLOAD.HEX tool to link the core and system specific modules and a comprehensive .pdf file that gives you number of options for getting the files to your system, including simple serial program.

    I have C-Kermit on my Linux box and it connects to the CP/M machine and I can issue commands remotely.

    However, there is one fundamental problem, I cant get any files to transfer. Ive checked the serial protocol, have XON/XOFF set at both ends but the transfer dialogue just sits there racking up errors

    Any clues as to what to look at to find out what is happening or, more to the point, not?

    Pete

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
  •