Serial transfer on CP/M?
James M. Knox
>Is it possible to do any kind of simple, reliable file transfer
>via RS232 port by using the standard tools that CP/M offers? I'm
>thinking about the command line tools here: is there an equivalent
>of MS-DOS's debug.com in CP/M -
Last question first... It's called DDT and will allow you to type in a
program. It will even translate mnemonics into opcodes and display binary vs.
ascii and disassemble (minimally) binary.
As to RS-232 file transfers... It's possible (with a little work) to use PIP
to transfer files over the serial port. The files need to be fairly short,
however, as most PIP implementations did not support handshake lines. That
means that when the program has to write to the disk you will tend to miss
incoming data. Works for short programs or very slow data rates.
There are versions of popular file transfer protocol programs available.
KERMIT and MODEM (in its various flavors -- MODEM7, XMODEM, ZMODEM, etc.).
These are compatible with their PC equivalents and most PC comm tools (such as
PCPlus). The trick is getting the program into the Osborne in the first
place. That's where you may have to do a little programming - after you
download the program to your PC, then hack a little routine with DDT on the
Osborne to accept KERMIT or whatever over to an Osborne disk.
jmk
-----------------------------------------------
James M. Knox
TriSoft ph 512-385-0316
1109-A Shady Lane fax 512-366-4331
Austin, Tx 78721 tri...@texas.net
-----------------------------------------------
Richard Erlacher
including, first of all, Modem7. This is what it sounds like, i.e. a
comm. program intended for file transfer.
Next, there's PIP, which allows you to send files to whatever device
you like, provided there's a handler for it in the BIOS. You can send
a file via PIP using the TTY, punch, or printer as an output device.
You must be sure you have a complimentary driver in the receiving
station, thoug.,
Using Modem7, a PC, for example, can receive data VERY well.
Additionally, DDT provides means to key in a program.
Dick
On Thu, 3 Feb 2000 10:28:23 +0200, "Jukka Aho" <jukk...@iki.fi>
wrote:
>Is it possible to do any kind of simple, reliable file transfer
>via RS232 port by using the standard tools that CP/M offers? I'm
>thinking about the command line tools here: is there an equivalent
>of MS-DOS's debug.com in CP/M - one that could be used for typing
>in machine language routines, or perhaps a little MBASIC program
>that could be typed in?
>
>Getting a PC to read Osborne I disks would apparently require
>purchasing a special software as well as finding/buying/modifying
>some 286-era vintage disk controller / drive hardware. A bit too
>much trouble as all I want to do is to transfer some files.
>
>It would be nice if I could at least somehow dump a CP/M terminal
>emulator program from PC to an Osborne I by using a serial cable
>(and then use that terminal program for actual file transfer).
>Speed is not an issue; I can easily live with 300 bps or 150
>bps if it only enables me to transfer the files reliably.
>
>* * *
>
>BTW, does anyone know about any CP/M disk imaging software that
>would read the disk block by block (including the system/boot
>area) and send the data out through the serial port?
>
> -- znark
>
>
Jeff Jonas
"Jukka Aho" <jukk...@iki.fi> wrote:
>>Is it possible to do any kind of simple, reliable file transfer
>>via RS232 port by using the standard tools that CP/M offers? I'm
>>thinking about the command line tools here: is there an equivalent
>>of MS-DOS's debug.com in CP/M -
In article <3bgm4.4616$OI1.2...@news5.giganews.com>
tri...@texas.net (James M. Knox) writes:
>As to RS-232 file transfers... It's possible (with a little work) to use PIP
>to transfer files over the serial port. The files need to be fairly short,
>however, as most PIP implementations did not support handshake lines. That
>means that when the program has to write to the disk you will tend to miss
>incoming data. Works for short programs or very slow data rates.
Ya, and transferring binary data's a problem as a control-S will
stop the xfer, some characters won't go thru at all,
and you will probably need to manually signal end-of-file for each file.
As well as the usual problems of losing characters
if the receiver overruns, etc.
When I was transferring files from CP/M to DOS, I used a terminal
program on the CP/M side that used an Xmodem-batch protocol,
transmitting the files via the 2nd serial port
(console on the 1st serial port).
Much to my happiness, such a program came with the machine
else I'd have to download something and possible configure/compile it.
On the DOS side I used ProComm 4.something (the free version)
receiving the files with something like "modem7"
which corresponds to xmodem-batch.
That way, *all* the files flew along (even binaries) unattended.
The "zmodem" or "kermit" protocol would be better,
if available for the CP/M side.
--
Jeffrey Jonas
jeffj@panix(dot)com
The original Dr. JCL and Mr .hide
Barry Watzman
without writing special software, would be to use a "Modem" program such
as Modem7. You could even use a PC on the other end, but you'd have to
have one that supported the same protocol. Modem7 uses XMODEM with
checksum, today XModem with CRC is more common, but a lot of programs
still support the older and less reliable checksum.
Jukka Aho wrote:
> Is it possible to do any kind of simple, reliable file transfer
> via RS232 port by using the standard tools that CP/M offers? I'm
> thinking about the command line tools here: is there an equivalent
Paul Schlyter
James M. Knox <tri...@texas.net> wrote:
> In article <87bedv$te7$1...@haavi.uwasa.fi>, "Jukka Aho" <jukk...@iki.fi> wrote:
>> Is it possible to do any kind of simple, reliable file transfer
>> via RS232 port by using the standard tools that CP/M offers? I'm
>> thinking about the command line tools here: is there an equivalent
>> of MS-DOS's debug.com in CP/M -
>
> program. It will even translate mnemonics into opcodes and display binary vs.
> ascii and disassemble (minimally) binary.
>
> to transfer files over the serial port. The files need to be fairly short,
> however, as most PIP implementations did not support handshake lines. That
> means that when the program has to write to the disk you will tend to miss
> incoming data. Works for short programs or very slow data rates.
>
> KERMIT and MODEM (in its various flavors -- MODEM7, XMODEM, ZMODEM, etc.).
where it can be found?
> These are compatible with their PC equivalents and most PC comm tools (such as
> PCPlus). The trick is getting the program into the Osborne in the first
> place. That's where you may have to do a little programming - after you
> download the program to your PC, then hack a little routine with DDT on the
> Osborne to accept KERMIT or whatever over to an Osborne disk.
----------------------------------------------------------------
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pau...@saaf.se paul.s...@ausys.se pa...@inorbit.com
WWW: http://hotel04.ausys.se/pausch http://welcome.to/pausch
anon...@bogus_address.con
On 2000-02-03 je...@panix.com(JeffJonas) said:
>>In article <87bedv$te7$1...@haavi.uwasa.fi>,
>"Jukka Aho" <jukk...@iki.fi> wrote:
>>>Is it possible to do any kind of simple, reliable file transfer
>>>via RS232 port by using the standard tools that CP/M offers? I'm
>>>thinking about the command line tools here: is there an equivalent
>>>of MS-DOS's debug.com in CP/M -
>
>In article <3bgm4.4616$OI1.2...@news5.giganews.com>
>tri...@texas.net (James M. Knox) writes:
>>As to RS-232 file transfers... It's possible (with a little work)
>>to use PIP to transfer files over the serial port. The files need
>>to be fairly short, however, as most PIP implementations did not
>>support handshake lines. That means that when the program has to
>>write to the disk you will tend to miss incoming data. Works for
>>short programs or very slow data rates.
>
>Ya, and transferring binary data's a problem as a control-S will
>stop the xfer, some characters won't go thru at all...
Not so. There's a command line 'switch' for PIP which allows transfer
of binary files. The 'switch' is: [O (that's the capital letter O,
not zero).
evans_t...@dontbothermewithspam.tesco.net
wrote:
>
>I've *never* seen a CP/M-80 implementation of ZModem. Could you tell me
>where it can be found?
>
Oh, this is an old memory....
do a bit of web-crawling for "ZMP". It's got zmodem. Ran zmp on a
xerox 16/8 for years.
Jeff Jonas
> >stop the xfer, some characters won't go thru at all...
>Not so. There's a command line 'switch' for PIP which allows transfer
>of binary files. The 'switch' is: [O (that's the capital letter O,
>not zero).
That's good to know, but I was more concerned with the receiving side.
I guess I am too Unix-centric where tty lines usually have processing
enabled (raw mode is used for true byte-at-a-time work).
I somehow remember having problems even with Procomm
trying to capture raw binary files (having to make a special
profile for no newline, CR translations, etc).
Fred J. Scipione
Jukka Aho wrote in message <87bedv$te7$1...@haavi.uwasa.fi>...
>Is it possible to do any kind of simple, reliable file transfer
>via RS232 port by using the standard tools that CP/M offers? I'm
>thinking about the command line tools here: is there an equivalent
>in machine language routines, or perhaps a little MBASIC program
>that could be typed in?
>
Search the internet archives for Kermit. The versions for CP/M include
documents and a program for overcoming the "bootstrap" problem
you are facing. You will probably use the PC version of Kermit on
your MS-DOS machine as well.
Jukka Aho
news:3bgm4.4616$OI1.2...@news5.giganews.com...
> There are versions of popular file transfer protocol programs available.
> KERMIT and MODEM (in its various flavors -- MODEM7, XMODEM, ZMODEM, etc.).
> These are compatible with their PC equivalents and most PC comm tools
(such
> as PCPlus). The trick is getting the program into the Osborne in the
first
> place. That's where you may have to do a little programming - after you
> download the program to your PC, then hack a little routine with DDT on
the
> Osborne to accept KERMIT or whatever over to an Osborne disk.
Thank you, and thanks to all the others who kindly replied to
my question.
Now, is there any place on the Internet where I could find
Z80 assembly source code for serial port routines? Or would
it be possible (perhaps easier?) to do binary transfers by
designing a suitable MBASIC program? (Is it possible to use
MBASIC for serial transfer at all under CP/M? If it is,
where could I find more information about this subject?)
Of course I would like to be able to use a "real" comm program,
but as you said, I had to get it over to Osborne in the first
place. This apparently isn't possible without some kind of
custom-made machine language routine or BASIC program for
transferring binary files via the serial port.
-- znark
Robert McConnell
>> >Ya, and transferring binary data's a problem as a control-S will
>> >stop the xfer, some characters won't go thru at all...
>
>>Not so. There's a command line 'switch' for PIP which allows transfer
>>of binary files. The 'switch' is: [O (that's the capital letter O,
>>not zero).
>
>That's good to know, but I was more concerned with the receiving side.
>I guess I am too Unix-centric where tty lines usually have processing
>enabled (raw mode is used for true byte-at-a-time work).
>I somehow remember having problems even with Procomm
>trying to capture raw binary files (having to make a special
>profile for no newline, CR translations, etc).
I recall a patch for PIP that enabled an INP and OUTP variation that
used the AUX port with an echo. Each character received was echoed
back to the sender, which waited for the echo before sending the next
character. When the buffer was written to disk, the echo of the last
byte was held until the write was complete.
What I don't remember is if it could handle binary data, or if it was
only for text files.
Bob McConnell
N2SPP
Bruce Morgen
>In article <3bgm4.4616$OI1.2...@news5.giganews.com>,
>James M. Knox <tri...@texas.net> wrote:
>
>> In article <87bedv$te7$1...@haavi.uwasa.fi>, "Jukka Aho" <jukk...@iki.fi> wrote:
>>>
[snip]
>
>I've *never* seen a CP/M-80 implementation of ZModem. Could you tell me
>where it can be found?
>
I don't know "where," but the
programs were "ZMP" (complete
terminal program with ZModem)
and "RZMP" (standalone
command line ZModem program
for RCP/Ms). They were both
coded in Hi-Tech C and
required quite a bit of TPA,
which limited their
popularity quite a bit since
they came out at a time when
so many serious 8-bitters
were running comparatively
low-TPA Z-System setups. As
recall, the source was
released, so perhaps the TPA
weakness can be addressed.
[snip]
__________________________________________________
http://come.to/realization
http://www.atman.net/realization
http://www.users.uniserve.com/~samuel/brucemrg.htm
http://www.users.uniserve.com/~samuel/brucsong.htm
Paul Schlyter
Were you posting this from a Commodore-64, Apple II, or some other old
40-column computer btw?
Lee Hart
> Is it possible to do any kind of simple, reliable file transfer
> via RS232 port by using the standard tools that CP/M offers?
I've been lurking on comp.os.cpm for a while but haven't posted to it
before. The difficulties that people seem to have with this simple
problem prompted me to respond.
To exchange data with another computer using only CP/M's standard
commands, you need to:
- find the name of your computer's serial port
- configure it for the desired format (baud rate, parity, etc.)
- choose an appropriate device driver
- get a cable that connects the appropriate pins between computers
- use PIP to transfer the data
First, every computer has different serial port hardware. They use
different chips, different I/O addresses, etc. Therefore, your computer
should have come with a configuration utility program. You need it to
set things like the baud rate, number of start and stop bits, type of
parity, I/O port address, handshaking, etc.
Next, the software to talk to your serial port hardware is also
machine-specific. Your computer's BIOS is where all this
machine-specific software goes, so it will have device drivers to do it.
The CP/M STAT command tells you what device drivers you've got.
A>STAT VAL:
(I deleted stuff here that's not relevant)
Iobyte Assign:
CON: = TTY: CRT: BAT: UC1:
RDR: = TTY: PTR: UR1: UR2:
PUN: = TTY: PTP: UP1: UP2:
LST: = TTY: CRT: LPT: UL1:
Just as CP/M disks have a 1-letter or 2-letter name followed by a colon
(A: B: C1: etc.), CP/M gives I/O devices a 3-character name (CON: LST:
etc.). PIP can send and receive data to these I/O devices as easily as
it can to disks.
The names on the left (CON: RDR: PUN: LST:) are CP/M's generic I/O
devices; all CP/M systems have them. The names on the right (TTY: CRT:
etc.) are the actual device drivers in your BIOS; they will vary a bit
from computer to computer.
Each of the 4 generic I/O devices can use any 1 of 4 actual drivers. The
Iobyte determines which of these hardware-specific drivers is actually
being used at the moment. The STAT command will tell you this assignment
as well:
A>STAT DEV:
CON: is CRT:
RDR: is UR1:
PUN: is UP1:
LST: is LPT:
CON: is the console; the thing CP/M uses as your keyboard and screen. In
the example above, STAT says it is currently assigned to the CRT:
driver. Thus, PIPping a file to the CON: will send it to the CRT:
driver, which in turn displays it on the screen. For example, PIP
CON:=A:MYFILE.DOC displays the file on the screen.
Similarly, LST: is the generic printer ("list" device), currently set to
the LPT: driver. PIPping a file to LST: sends it to the LPT: driver,
which in turn sends it to your printer.
RDR: and PUN: are the generic input ("reader") and output ("punch") I/O
devices. They are currently set to the TTY: device driver, named for the
old teletype with its paper tape reader and punch. The RDR: and PUN: are
normally configured to use whatever serial port isn't being used by the
console and printer, so they are the ones we'll use for file transfers.
Now we need a cable to connect the computers. As a start, it should
connect the RS-232 ports as follows:
chassis ground = pin 1 ________ pin 1 chassis ground
transmit data = pin 2 ___ ___ pin 2 transmit data
\/
receive data = pin 3 ___/\___ pin 3 receive data
signal ground = pin 7 ________ pin 7 signal ground
This is called a null modem cable, because it crosses pins 2-3. It lets
one computer receive what the other sends, and vice versa. If you happen
to be connecting a DCE connector on one computer to a DTE plug on the
other, then pins 2-3 don't need to be swapped.
Now, to send a simple text file from one computer to the other. On the
receiving computer, type:
PIP A:MYFILE.DOC=RDR: <return>
This will receive data from the RDR: device (currently the TTY: device
driver) and save it in a file on the A: disk named MYFILE.DOC. Nothing
happens while it waits for data to be received.
Then, on the sending computer, type:
PIP PUN:=B:SOMEFILE.DOC <return>
This will send SOMEFILE.DOC from the B: drive to the PUN: device
(currently the TTY: device driver). The other computer will receive it,
and save it on disk.
Except for .COM files, the last character of a CP/M file is a control-Z.
When the sending computer finds the control-Z, it sends it and then
exits PIP to return to its A> prompt. When the receiving computer's PIP
receives the control-Z, it closes the file being received, writes it to
disk, then exits PIP to its A> prompt. Thus, we have a simple way to
send small text files.
.COM files
.COM files (and some other types of non-text files) don't end in a
control-Z because programs can use all 256 combinations of 8 bits; a
control-Z might occur anywhere in a file. PIP knows this; when it sends
a .COM file, it keeps on sending until the physical end of the file.
But the receiving computer doesn't know when it has reached the end. It
waits forever for an end-of-file it will never receive.
The usual way around this is to convert .COM files to .HEX files. PIP
knows what a .HEX file is, and will check the checksums, ignore
extraneous characters, etc. UNLOAD.COM will convert a .COM file into a
.HEX file, and LOAD.COM will convert the .HEX back into a .COM file.
Large files:
PIP receives until RAM is full; then it stops receiving while it writes
to disk. If there is no handshaking, it will thus miss characters.
TTY: is usually a "dumb" device driver; it pays no attention to what is
being sent, and just sends each character as-is immediately with no
handshaking. But other device drivers will have special features. Many
consoles and printer can't keep up with the computer, and so need
handshaking. You can use one of these drivers for your serial
communications.
For example, notice that my RDR: can be set to TTY: PTR: UR1: or UR2:
and my PUN: can be TTY: PTP: UP1: or UP2:. Using the TTY: device for
both results in no handshake. Using UR1: for the reader and UP1 for the
punch gives me hardware handshaking. By connecting the RS-232 RTS and
CTS lines, the sending computer will pause as the receiving computer
writes to disk. Similarly, UR2: and UP2: use software handshaking
(control-S and control Q).
Use STAT to change the Iobyte. For example:
STAT PUN:=UP2: <return>
changes the PUN: device to use the UP2: device driver.
Whew! This was longer than I thought! I hope it helps. As you can see,
it can be done, but there are a lot of little details that you have to
get "just right". Once you have mastered the proper incantations, it
works great. But you can see why most people just use a modem program.
--
Lee A. Hart Ring the bells that you can ring
4209 France Ave. N. Forget the perfect offering
Robbinsdale, MN 55422 USA There is a crack in everything
phone (612) 533-3226 That's how the light gets in
leea...@earthlink.net Leonard Cohen
Walter P. Zaehl
I'm simply fascinated that there are still people around who
can write such a complete description of CP/M interconnection!
(20 years ago I could have done it as well, but now -
reduced to stupid user of a WinNT box, who has to call system
support when an application hangs ... I should really try to
revive my Exidy Sorcerer clone again ... ;-)
Amazed,
Walter
Lee Hart wrote:
>
> Jukka Aho asked:
> > Is it possible to do any kind of simple, reliable file transfer
> > via RS232 port by using the standard tools that CP/M offers?
>
> I've been lurking on comp.os.cpm for a while but haven't posted to it
> before. The difficulties that people seem to have with this simple
> problem prompted me to respond.
>
>... amazingly exhaustive description deleted
Jukka Aho
news:38A0FF...@earthlink.net...
>> Is it possible to do any kind of simple, reliable file transfer
>> via RS232 port by using the standard tools that CP/M offers?
> I've been lurking on comp.os.cpm for a while but haven't posted to it
> before. The difficulties that people seem to have with this simple
> problem prompted me to respond.
>
> To exchange data with another computer using only CP/M's standard
> commands, you need to:
>
> [lots of good advice deleted]
>
> Whew! This was longer than I thought! I hope it helps.
Thank you very much for such an insightful and informative
tutorial! I must say I did not have very good understanding
of CP/M device handling until reading this. Your article
really cleared up things quite nicely. Thanks again.
-- znark
mike
Paul Schlyter <pau...@merope.saaf.se> wrote in message
news:87e0u4$4vu$1...@merope.saaf.se...
> In article <3bgm4.4616$OI1.2...@news5.giganews.com>,
> James M. Knox <tri...@texas.net> wrote:
>
> > In article <87bedv$te7$1...@haavi.uwasa.fi>, "Jukka Aho" <jukk...@iki.fi>
wrote:
> >> thinking about the command line tools here: is there an equivalent
> >> of MS-DOS's debug.com in CP/M -
> >
> > program. It will even translate mnemonics into opcodes and display
binary vs.
> > ascii and disassemble (minimally) binary.
> >
use PIP
> > to transfer files over the serial port. The files need to be fairly
short,
> > however, as most PIP implementations did not support handshake lines.
That
> > means that when the program has to write to the disk you will tend to
miss
> > incoming data. Works for short programs or very slow data rates.
> >
> > KERMIT and MODEM (in its various flavors -- MODEM7, XMODEM, ZMODEM,
etc.).
>
> where it can be found?
>
(such as
> > PCPlus). The trick is getting the program into the Osborne in the first
> > place. That's where you may have to do a little programming - after you
> > download the program to your PC, then hack a little routine with DDT on
the
> > Osborne to accept KERMIT or whatever over to an Osborne disk.
>
Paul Ryan
you get it for 8 and 16 bit CP/M?
evans_t...@dontbothermewithspam.tesco.net wrote:
>
> On 4 Feb 2000 09:00:04 +0100, pau...@merope.saaf.se (Paul Schlyter)
> wrote:
>
> >
> >I've *never* seen a CP/M-80 implementation of ZModem. Could you tell me
> >where it can be found?
> >
>
Paul Ryan
different CP/M formats, including Osborne. You will need a 5.25" drive
in the PC though. An old 360K is the best bet, as a 1.2Mb could be
unreliable.
Paul
Jukka Aho wrote:
>
> "James M. Knox" <tri...@texas.net> wrote in message
> news:3bgm4.4616$OI1.2...@news5.giganews.com...
>
> > There are versions of popular file transfer protocol programs available.
> > KERMIT and MODEM (in its various flavors -- MODEM7, XMODEM, ZMODEM, etc.).
> > These are compatible with their PC equivalents and most PC comm tools
> (such
> > as PCPlus). The trick is getting the program into the Osborne in the
> first
> > place. That's where you may have to do a little programming - after you
> > download the program to your PC, then hack a little routine with DDT on
> the
> > Osborne to accept KERMIT or whatever over to an Osborne disk.
>