Kermit and CP/M - now working

[James Moxham]

After multiple experiments, now have Kermit working for file transfers on CP/M computers. Attached is a "Generic" Kermit. It has been tested with Teraterm on a PC.

Many thanks to Andrew Quinn for helping getting this working. The secret lies in some simple changes to the CP/M bios. Kermit changes a byte in ram at location 0003 (called iobyte). If this byte is zero, data is directed to the default port (TTY, which is the normal keyboard and display). 

In Kermit, you can run the command SET PORT ? and this displays the available ports. Not all of these seem to work but CRT and UC1 do. 

CRT changes iobyte to 85, and UC1 changes it to 87, so this can be used to redirect data to various physical ports. 

The CP/M bios needs to modified to redirect this data. In simple terms:

read iobyte at location 0003 in ram

if 0, send to normal port

if 85, send to CRT port

if 87, send to UC1 port

In the spirit of CP/M, you modify the bios for your particular hardware, and then all CP/M software should then run on your particular system. 

Any changes to CP/M bios are backwards compatible. At bootup, if CP/M sets iobyte to TTY (0) and the changed bios checks iobyte and if zero, sends to the TTY serial port, then everything works as per normal.

Having got it working, it is now possible to understand this iobyte description https://www.seasip.info/Cpm/iobyte.html There are 2 bits for the CONSOLE device in CP/M, and if we look at that 4^th column, these are 00 = TTY, 01 = CRT, 10 = BAT and 11 = UC1. Looking at what kermit changes with SET PORT and masking off the high 6 bits, we get 00 for TTY, 01 (85 = binary 01010101) for CRT and11 (87 = binary 10010111) for UC1. And SET PORT BAT gives an “unrecognized command” in Kermit so you can only use three ports, not four.

As an aside, other programs can modify iobyte as well. Eg STAT RDR:=UR2: change it to (I think) 12. STAT DEV: will print out what physical devices are linked to what virtual devices. What this means is that if I write a little program in C or Basic or assembly on my computer and every IN or OUT command is replaced with a bios call and /or a modification to iobyte, then that program will work on another CP/M computer that has completely different port assignment. So one can think of a 'generic' xmodem, for instance. Also, just as a little experiment, any port assignments done by STAT are overwritten by Kermit.

Kermit is a very flexible file transfer system. Hopefully this is of use to someone.

James Moxham

Adelaide, Australia

[James Moxham]

Addit, just trying to attach a copy of generic kermit. .COM files not allowed and .ZIP files giving an error "try again later". 

[phillip.stevens]

Hi James,

Not sure I understand why the standard bios of Grant Searle et al, needs to be modified. AFAIK, the IOBYTE is handled correctly already in each case.

In fact the changes that you’ve suggested are a bit unsubtle in some respects, as multiple behaviours are provided for in the existing bioses, including toggled printer enabling, for example.

Could you please help me understand what was the background of broken behaviour from current bioses, that led to the need to modify the bios?

Cheers, Phillip

[James Moxham]

Good points Philip.

Indeed, Grant's code may well be fine, I'll need to check it. This is more for all the other systems out there (eg N8VEM, FPGA systems, Arduino emulation, old computers). 

Cheers, James

[James Moxham]

Hi Phillip, I've taken a look at Grant's bios code and the good news is this should all work fine with Kermit on the RC2014 without any further bios changes. Run Kermit and, depending on which serial port is TTY and which is CRT, either type SET PORT TTY or SET PORT CRT. 

How to find out which one is which? 

Option 1 - try both and see which one works. Probably the simplest option!

Option 2 - set the port, then try sending a file from kermit at the CP/M end (no need to connect anything at the other end). Type SEND MYFILE.TXT (must be on the drive) and kermit should print a couple of '0'. If it also prints out about ten random characters, this is the startup packet, and it is going to the same port as the terminal which is wrong, it should go to the other port.

Option 3 - a more detailed understanding of what is happening. See the first post above for what Kermit is doing. Grant Searle's bios looks for a 'space' keyboard input on one of the serial ports and then defines this as the console port. The description on Grant's page is.

If you activate the terminal on the CRT port, the IOBYTE is set to 00000001b ie. List is TTY:, Punch is TTY:, Reader is TTY:, Console is CRT: 
If you activate the terminal on the TTY (RS232) port, the IOBYTE is set to 00000000b ie. List is TTY:, Punch is TTY:, Reader is TTY:, Console is TTY:

But maybe you have forgotten which port is which (I certainly have with my various boards, all I know is that you hit spacebar and it works on that port!). So it is worth noting what kermit is doing so you can remember to set the comms port to CRT or TTY.

And then there is port UC1 which kermit can also use but which is not implemented in the bios.

All good fun!

[phillip.stevens]

James Moxham wrote:

Hi Phillip, I've taken a look at Grant's bios code and the good news is this should all work fine with Kermit on the RC2014 without any further bios changes. Run Kermit and, depending on which serial port is TTY and which is CRT, either type SET PORT TTY or SET PORT CRT. 

All good fun!

James,

Good to know that the standard Grant Searle CP/M works too. As noted, that confirms AFAIK that all the BIOSen for RC2014 respect IOBYTE, and that Kermit works out of the box.

But for one simple thing, the attached picture could have had been an RC2014 running CP/M-IDE chatting with a HP48 using Kermit. But, unfortunately I don't have a way to slow down the CPU clock enough to generate 9600 baud on the RC2014 SIO/2.  ;-(   So in lieu of that, here's a YAZ180 chatting with a HP48 using Kermit. You'll just have to imagine.

Finally mass storage for the calculator generation..!

Cheers, Phillip