Serial file transfer under CP/M-80 and CP/M-86
Rich Beaudry
I have a CompuPro S-100 CP/M box, with a dual CPU board, so it can run
CP/M-86, or CP/M-80. I have many, many 8" floppies with lots of good
software that I would like to preserve. I have made duplicates of
many of the diskettes, onto fresh 8" media, but I'm still paranoid
about losing this stuff...
The end goal is to transfer the files to an IBM PC, and burn them onto
a CD-ROM. Then, of course, I'd like to reverse the transfer, to see
if the files remain intact. I will need to transfer both binary and
ASCII files.
Does anyone have a decent communications program **that runs natively
under CP/M** (and the same for CP/M-86), with the following features:
- Can configure the hardware port it talks to (I have an Interfacer 4
board, and ideally I'd like to be able to tell the comm program the
port address for one of the serial ports)
- Can do direct serial connection to another computer (i.e., no modem
required)
- Can transfer files in XMODEM or YMODEM protocol
- On 8" floppy media (I only have 8" drives connected to this box --
can be single or double sided, and single or double density)
I can give details about the CompuPro system if necessary...
If anyone has a comm program that will do this, I will gladly send 8"
media for you to make copies, and I will gladly cover costs of
photocopying the manual and sending the manual/disks to me. As an
alternative, if you send me originals, I will make copies myself, and
send the originals back ASAP.
Thanks!
Rich B.
nos...@nouce.bellatlantic.net
wrote:
>Does anyone have a decent communications program **that runs natively
>under CP/M** (and the same for CP/M-86), with the following features:
snippage...
Rich,
I suggest Modem7 or the derivitives as that will talk to Procom or any
of the stanard PC modem programs.
Now the caveats..
Most modem programs for CP/M have to be customized due to no standard
for what port, lack of interrupt driven IO and sometimes slow IO.
This means that faster than 4800 on some systems is hard to do and the
best of the pack usually top out at 19.2k due to Z80/4mhz limits or
worse the serial device doesnt do faster. Fortunately the 2651
running at 16x clock will do 62k baud but the system feeding it
(likely) the 8085 at 10/12mhz will be hard pressed to do 38.4 without
fancy programming (and keep up with protocal).
One solution is to use a program that was called UP and DOWN that did
a binary transfer at high speeds (relative to the ports used) and was
relatively short (under 300bytes). I hand enered it and assembled it
with ASM and DDT. If you can find them those are simple but very
effective. I've used this for CP/M to CP/M transfers at 19.2 (and
faster) effectively. The gotcha is you also have to write a dos
version of same to match it at the other end.
There may be simple programs to do Xmodem TX as a simple
transient program and that is a simple task to do. Suggestion here
would eb to check the archives out on the net for any in source form
and enter/patch them for your use.
Allison
Jeff Jonas
>>under CP/M** (and the same for CP/M-86), with the following features:
>snippage...
>Rich,
>I suggest Modem7 or the derivitives as that will talk to Procom or any
>of the stanard PC modem programs.
Oy, time to tickle my brain cells ... it was 1991
when I transferred all my files from the Z80 CP/M system to the PC.
I remember using a null modem wire between them
(a fiber optic link to be precise since it was room to room)
and getting rather high speeds: 9600 or better.
On the CP/M side, I was fortunate enough to have a ready-to-run
terminal-emulator program with X-modem batch protocol
else I'd have to travese the maze of programs (Kermit, etc)
and all the system-dependent modules.
On the DOS side, I ran good old Procomm. The trick was finding that
Procomm's "modem7" protocol matched the CP/M terminal program's "XMODEM batch"
(I think, or was it Ymodem) to allow batch file transfers.
>Now the caveats..
>Most modem programs for CP/M have to be customized due to no standard
>for what port, lack of interrupt driven IO and sometimes slow IO.
I guess that explains why the "standard" open source ones
had so many modules, and even the one included with my system
had hard-coded portions.
--
Jeffrey Jonas
jeffj@panix(dot)com
The original Dr. JCL and Mr .hide
Jim Bianchi
>Hello all,
>I have a CompuPro S-100 CP/M box, with a dual CPU board, so it can run
>CP/M-86, or CP/M-80. I have many, many 8" floppies with lots of good
>software that I would like to preserve. I have made duplicates of
>many of the diskettes, onto fresh 8" media, but I'm still paranoid
>about losing this stuff...
>The end goal is to transfer the files to an IBM PC, and burn them onto
>a CD-ROM. Then, of course, I'd like to reverse the transfer, to see
>if the files remain intact. I will need to transfer both binary and
>ASCII files.
Smiple. Get (and set up) a copy of IMP245 (which I b'lieve was the
last version Irv Hoff wrote before he died) on the CP/M box, run a null
modem cable between a serial port on the CP/M system and a serial port of
the PC, get a copy of {COMMO} v5.5 or above for the PC (it used to be avail
from most BBSs -- it's prob free for the download from PC oriented archive
sites), log to the disc/user area on the CP/M-80 box, log to a suitable dir
on the PC, invoke "send *.*" on the CP/M box and stand well back.
>Does anyone have a decent communications program **that runs natively
>under CP/M** (and the same for CP/M-86), with the following features:
With the (necessary) caveat that it MUST have a system specific
insert added, IMP245.COM was about the best thing going for CP/M-80. It
could easily do what you want -- transfer files at high speed using YMODEM
("If it's batch, it's YMODEM" according to Chuck Forsberg, the author) to
the serial port. (For instance, a transfer could be initiated by logging to
the appropriate user area on the CP/M-80 system and saying "send *.*"). Go
to one of the CP/M archive sites and search for IMP.COM. There should also
be a large CP/M library of the system spefic inserts, and you could likely
find the one for your system -- or one close enough that you could modify it
to match the specs of your system.
Like the rest of the CP/M comm pgms, however, IMP suffered from the
"chicken or egg?" problem: given that there was no common disc format, the
only way to get a copy was to download it somehow, which presupposed the
existance of a comm pgm already, and if you had one already, why do you need
to download one?
I never got into CP/M-86, so I've no hard info on comm pgms for it.
I suspect there were versions of Irv Hoffs IMP (Improved Modem Program) that
were for CP/M-86. I simply don't know. However, if you have a decent CP/M-80
comm pgm and if your CP/M-80 system can read the CP/M-86 floppies (they do
not have to be executable), you can transfer them. ASCII or binary. As far
as the transfer protocol can see or cares, it's all bits. And as they say,
"Bits are bits." <grin>
Null-modem file transfers typically can use the highest baud rate
which the slowest serial port is capable. I've done *.* YMODEM/null-modem
transfers at 19.2kbps, and whoa!
On a system that uses MS-DOS (or DR-DOS) the only comm pgm worthy of
the name is {COMMO}. It's shareware (or it was -- I believe Fred Brucker,
the author, has released it into the public domain), it was really easy to
install and configure, and it could do ZMODEM without an external protocol
driver (plus it had support for using an external protocol such as GSZ or
HSLINK if desired). Setting it up to do such a transfer (in either direction)
would be extremely simple. It could also do straight XMODEM, 1k XMODEM, and
YMODEM if you wanted. COMMOxx.ZIP was the archive name, it had really
comprehensive documentation, it was NOT crippled in any way, and had a
built-in macro that could be used for installation/setup if needed.
--
ji...@sonic.net
Eclectic Garbanzo BBS, (707) 539-1279
"My parents just came back from a planet where the dominant lifeform
had no bilateral symmetry, and all I got was this stupid F-Shirt."
dwight elvey
Hi Rich
I typically transfer binaries from my PC to my CPM machine
with a simple serial program. I then use the SAVE command to
put them into files or a simple disk program ( vary hardware
dependent ) to transfer the first two tracks.
I usually am only interested in text files going the other
way so TYPE on the CPM and a simple serial to file program
is all I otherwise use.
These are not really complicated to do ( other than my direct
disk write ). If you want to write something and need some help,
I can get you going.
Dwight
Lee Hart
> Like the rest of the CP/M comm pgms, however, IMP suffered from
> the "chicken or egg?" problem: given that there was no common disc
> format, the only way to get a copy was to download it somehow,
> which presupposed the existance of a comm pgm already, and if you
> had one already, why do you need to download one?
The answer is that CP/M, all by itself, can transfer programs serially
between machines.
CP/M normally implements four peripheral devices:
CON: the console
RDR: the "reader" (serial input)
PUN: the "punch" (serial output)
LST: the "list" device (printer)
The RDR: and PUN: devices are usually your serial port. The PIP program
can send or receive data directly from these devices. For example,
PIP CON:=B:FILENAME.DOC
will read the file FILENAME.DOC from the B: disk, and send it to the
console. CTRL-S and CTRL-Q respectively will stop and start the console
display.
So, to send a file to the serial port named PUN: you can use
PIP PUN:=B:FILENAME.DOC,EOF:
The PC (or whatever system is on the other end of the serial cable)
should be there and ready to receive the data. PIP does not normally
send the final CTRL-Z (end of file character) but you can force one to
be sent by adding that ,EOF: to the end of the command. The PC can close
the file and save it to disk when it receives the final CTRL-Z.
Likewise, for a CP/M system to receive a serial file, you'd use
PIP B:FILENAME.DOC=RDR:
Note that the sending device (a PC or whatever) needs to include a final
CTRL-Z to signify the end of the file. PIP will wait forever for it.
Until it comes, PIP will keep loading the received serial data into
memory. When the CTRL-Z comes, PIP then writes the data to disk and
closes the file.
Also note that if the file is too big to all fit in memory, PIP will
pause, write what it has so far to disk, and then go back for more
serial data. If the BIOS has not implemented hardware handshaking on
that serial port, the PC sending the data won't know it needs to stop
and wait, and data will be lost. You usually use this method for sending
small enough files that this is not a problem. If it is too big, break
the file into pieces (PIP can do this, too).
COM files might have an embedded CTRL-Z, which would be interpreted by
PIP as a false end-of-file. The easiest solution is to send them as HEX
files (which also include checksums for error detection. If you don't
have the HEX version of a COM file, you can make it with UNLOAD.COM.
The other tricky way to transfer files to/from a PC is to connect the PC
as the console for the CP/M computer. Then use PROCOMM or any other
modem program on the PC. You'll have your CP/M prompt on the PC screen,
and can just use TYPE B:FILENAME.DOC to grab any CP/M text files, and
use the modem programs capture and save features to save it to disk. For
COM files, convert them to HEX files first as mentioned.
Once on the PC, you can run CP/M with any of the popular emulators. Run
LOAD to re-convert any HEX files you transferred back into COM files
(often with a different extent so DOS won't mistake them for x86 code).
The above methods are useful because they ALWAYS work. Usually, the
first programs you transfer are some modem programs. They will require
configuration, but once working, they are smoother and easier to use.
--
Lee A. Hart Ring the bells that still can ring
814 8th Ave. N. Forget your perfect offering
Sartell, MN 56377 USA There is a crack in everything
leeahart_at_earthlink.net That's how the light gets in - Leonard Cohen
Steve Dubrovich
> The answer is that CP/M, all by itself, can transfer programs serially
> between machines.
>
8-bits, no parity, 1 stop bit, same baud rate - 1200, for example. On
the PC side, mode.com can do this, and also you can redirect input to
a file, with say, com1: > test.txt [Hmm, is that the correct form?]
Initiate the receiving side first then the sender.
On the cp/m side, perhaps you have a program for the port card, to set
the serial parameters??
> CP/M normally implements four peripheral devices:
>
> CON: the console
> RDR: the "reader" (serial input)
> PUN: the "punch" (serial output)
> LST: the "list" device (printer)
>
> The RDR: and PUN: devices are usually your serial port. The PIP program
> can send or receive data directly from these devices. For example,
>
> PIP CON:=B:FILENAME.DOC
>
> will read the file FILENAME.DOC from the B: disk, and send it to the
> console. CTRL-S and CTRL-Q respectively will stop and start the console
> display.
>
Verify that you are not dropping characters in a text file transfer.
Jim Bianchi
>Jim Bianchi wrote
>> Like the rest of the CP/M comm pgms, however, IMP suffered from
>> the "chicken or egg?" problem: given that there was no common disc
>> format, the only way to get a copy was to download it somehow,
>> which presupposed the existance of a comm pgm already, and if you
>> had one already, why do you need to download one?
>
>The answer is that CP/M, all by itself, can transfer programs serially
>between machines.
Bet me it could. Else why all the work that was done to create
MODEM7, which was a very short program in assy language that could be
manually typed in and run through ASM to produce a .COM file capable of
dloading one other program -- a proper communication program?
Hey, sure it SOUNDS like you should be able to do it, but just
PIPing stuff out (or in) one of the serial ports simply will not work.
nos...@nouce.bellatlantic.net
wrote:
>The RDR: and PUN: devices are usually your serial port. The PIP program
>can send or receive data directly from these devices. For example,
>
>PIP CON:=B:FILENAME.DOC
Thats nice and totally useless for binary. What happens if the
recieveing system cant keep up... splat!
>Also note that if the file is too big to all fit in memory, PIP will
>pause, write what it has so far to disk, and then go back for more
>serial data. If the BIOS has not implemented hardware handshaking on
>that serial port, the PC sending the data won't know it needs to stop
>and wait, and data will be lost. You usually use this method for sending
>small enough files that this is not a problem. If it is too big, break
>the file into pieces (PIP can do this, too).
You really need software handshaking. and it rare that it's implemted
in either case.
>have the HEX version of a COM file, you can make it with UNLOAD.COM.
And you have to get unload on the system...
You really want a minimal xmodem program to recieve a more maximal
program for error free file transfer.
Allison
Fred J. Scipione
>
> > Like the rest of the CP/M comm pgms, however, IMP suffered from
> > the "chicken or egg?" problem: given that there was no common disc
> > format, the only way to get a copy was to download it somehow,
> > which presupposed the existance of a comm pgm already, and if you
> > had one already, why do you need to download one?
>
> The answer is that CP/M, all by itself, can transfer programs serially
> between machines.
Just in case it helps any newbies: For CP/M, the most detailed and
complete material for bootstrapping a communications program
that I have found is in the Kermit archive at Columbia University.
It includes a mini-booter for DDT entry, HEX images, etc.
Richard Steven Walz
Jim Bianchi <ji...@sonic.net> wrote:
>On Thu, 05 Sep 2002 03:41:44 GMT, Lee Hart <leea...@earthlink.net> wrote:
>>Jim Bianchi wrote
>>> Like the rest of the CP/M comm pgms, however, IMP suffered from
>>> the "chicken or egg?" problem: given that there was no common disc
>>> format, the only way to get a copy was to download it somehow,
>>> which presupposed the existance of a comm pgm already, and if you
>>> had one already, why do you need to download one?
>>
>>The answer is that CP/M, all by itself, can transfer programs serially
>>between machines.
>
> Bet me it could. Else why all the work that was done to create
>MODEM7, which was a very short program in assy language that could be
>manually typed in and run through ASM to produce a .COM file capable of
>dloading one other program -- a proper communication program?
>
> Hey, sure it SOUNDS like you should be able to do it, but just
>PIPing stuff out (or in) one of the serial ports simply will not work.
>--
>ji...@sonic.net
Yes, it will, I have transferred a copy of MODEM7 from UNLOAD.COM in hex
to an Apple II+ with a Z-80 card because it didn't have a modem proggy,
and it works, but I had to do it in four pieces and re-concatenate it
and use LOAD.COM on it to make the .COM file. It does NOT like binary,
and it does NOT like pieces bigger than 8K!! So for THAT implementation
of a BIOS those seem to be the caveats. I can see WHY Irv Hoff and Ward
Christenson wrote the modem programs. Without them it's a pain in the ASS!
-Steve
--
-Steve Walz rst...@armory.com ftp://ftp.armory.com/pub/user/rstevew
Electronics Site!! 1000's of Files and Dirs!! With Schematics Galore!!
http://www.armory.com/~rstevew or http://www.armory.com/~rstevew/Public
dwight elvey
Hi
He's not sending these over a phone modem. An simple serial
program will work. We are not talking rocket science here.
I've transfered a large number of file down to my CPM machine
without a single bit being lost. Such programs only take
about 20 bytes of assembly code.
Dwight
Lee Hart
> Hey, sure it SOUNDS like you should be able to do it, but just
> PIPing stuff out (or in) one of the serial ports simply will not
> work.
I'm sorry, but it *does* indeed work. I have done it many times, on many
different computers. It's the way I always got the first modem program
and any other software I want to use transferred to a new system.
Steve Dubrovich wrote:
> But I think the rs-232 ports need to be configured alike first.
Yes, of course. Most CP/M computers came with some program to set the
serial port characteristics.
Likewise, you need a cable between the two computers with the right
connectors on each end, and the right pinouts DTE vs. DCE). This alone
can be a challenge.
> Verify that you are not dropping characters in a text file transfer.
It's possible, but rare. PIP seems to be slower at sending than
receiving characters. If it does happen, you can set the baud rates
lower (I've never had to go below 4800 baud).
Allison wrote:
>> PIP CON:=B:FILENAME.DOC
> That's nice and totally useless for binary. What happens if the
> recieveing system cant keep up... splat!
> And you have to get unload on the system...
That was for text files. Farther down the article, I did say to use
UNLOAD.COM to convert COM files into HEX and then send them. HEX files
have built-in error checking. And, it's pretty simple to use CRCK.COM to
check files for errors.
To get UNLOAD on the system, you unload unload. Then send UNLOAD.HEX to
the target system, and LOAD it! :-)
Steve Walz wrote:
> I can see WHY Irv Hoff and Ward Christenson wrote the modem programs.
> Without them it's a pain in the a**!
So very true! I never said the PIP method was easy. But it works. You
just use it to get a proper modem program transferred, and then do all
further transfers with it.
Ruud Baltissen
> Such programs only take about 20 bytes of assembly code.
Sourcecode, please?
--
___
/ __|__
/ / |_/ Groetjes, Ruud
\ \__|_\
\___| http://Ruud.C64.org
bud
Speaking of PIP, that's one CP/M utility that could have benefited from
an optional menu interface, such as other CP/M utilities had.
salaam,
dowcom
--
http://community.webtv.net/dowcom/DOWCOMSAMSTRADGUIDE
DOShead Credo:
a) Try it! It might work.
b) GOTO a).
Ross Simpson
>
> Speaking of PIP, that's one CP/M utility that could have benefited
from
> an optional menu interface, such as other CP/M utilities had.
Hi Bud,
Wasn't the 8bit version of PIP like that? I suppose it wasn't.
My only grudge about PIP was the lack of a help assistance, but as
stated once before this was written when machines had less memory
which I can understand.
Now that I understand PIP a bit more now I can do more advanced things
with it (such as copying files between directorys) which is good.
You may want to check out Sweep (I think they call it), which gives a
menu interface, help & can pretty much copy just like PIP would only
in a menu interface, if you haven't checked it already.
Regards,
Ross.
Axel Berger
^^^^^^
Have you tried sueing your parents?
>Thats nice and totally useless for binary. What happens if the
>recieveing system cant keep up... splat!
Well, standardized rates do go down to 50 baud IIRC and if PIP is all
you have it is a nice beginning - that XMODEM or whatever has to get to
the second machine somehow.
--
Tschö wa
Axel
bud
Hi Ross:
Group: comp.os.cpm Date: Mon, Sep 9, 2002, 8:18am (CDT+15) From:
rosssimpson@my_spammers_address.com.au (Ross Simpson)
script:
>You may want to check out Sweep (I
>think they call it), which gives a menu
>interface, help & can pretty much copy
>just like PIP would only in a menu
>interface, if you haven't checked it
>already.
Thanks Ross. I'll check it out.
Lee Hart
> My only grudge about PIP was the lack of a help assistance, but as
> stated once before this was written when machines had less memory
> which I can understand.
It is easy to add help to the CP/M-80 version of PIP without increasing
its size. Many, many, many years ago I patched my versions so if I just
type PIP <return> (i.e. with no command tail) it displays:
A>PIP
syntax: PIP dest=source1[options],source2[options],etc.
option: Lowercase Delete past n Start@text^Z Pn=page@n lines
Uppercase Number lines Quit@text^Z Echo to console
Formfeed out Verify copy Zero 8th bit Tn=expand Tab=n
spaces
*
The "*" is the usual PIP prompt; you can then type any PIP command line,
or just a <return> to exit as usual. No extra memory is needed, and no
features of PIP are lost.
The little program to do this fits in the 256-byte "hole" left in PIP
for user device drivers. Here is the beginning of the PIP program with
my patch installed:
0100 JMP 0107h ; jump to our help patch
0103 RET ; (same as stock PIP)
0104 NOP ; (same as stock PIP)
0105 NOP ; (same as stock PIP)
0106 RET ; (same as stock PIP)
0107 LDA 80h ; help patch
010A ORA A ; see if there is a command tail
010B JNZ 04CEh ; if yes, go to PIP
010E LXI D,0119h ; else point to help message
0111 MVI C,9 ; call BDOS print string function
0113 CALL 5
0116 JMP 04CEh ; then go to PIP
0119 DB 'syntax:' ; help message...
...
0200 DB 0Dh,0Ah,24h ; ...ending in "$"
Your help message can be any ASCII string, starting at 0119 and ending
at or before 0200 with a carriage return, line feed, and "$". 0203 is
the start of the Digital Research copyright message. My help message is
actually a couple characters longer, so it overlapped the first two
characters of the copyright notice (COpyright...). It still works; you
can replace the whole message if you like.
Ross Simpson
> Ross Simpson wrote:
> > My only grudge about PIP was the lack of a help assistance, but as
> > stated once before this was written when machines had less memory
> > which I can understand.
>
> It is easy to add help to the CP/M-80 version of PIP without
increasing
> its size. Many, many, many years ago I patched my versions so if I
just
> type PIP <return> (i.e. with no command tail) it displays:
That sounds handy to have Lee, unfortunately I'm mostly using the
16bit version of CP/M. Maybe I could translate this for the 16Bit
version of PIP. The size maybe slightly different (perhaps bigger) So
the addresses for the patch would change.
Regards,
Ross.
Freek Heite
>> That sounds handy to have Lee, unfortunately I'm mostly using the
>> 16bit version of CP/M. Maybe I could translate this for the 16Bit
>> version of PIP. The size maybe slightly different (perhaps bigger) So
>> the addresses for the patch would change.
I'm afraid that PIP in CP/M-86 does not provide space for user patches, like PIP
in CP/M-80 does.
Freek.
Richard Plinston
>
> That sounds handy to have Lee, unfortunately I'm mostly using the
> 16bit version of CP/M.
I thought that all versions of CP/M-86 had the HELP command so that
"HELP PIP" would tell you what you needed to know. If it doesn't then
it is easy enough to write a simple help page for your own needs.
In 1982 Paul Allen (BG's partner in MS) gave a talk about the 'next
release of MS-DOS', 1.25 was just released. One of its 'features' would
be a help facility. It took another 10 years before MS-DOS had one in
version 5.
Ross Simpson
Hi Richard,
> > That sounds handy to have Lee, unfortunately I'm mostly using the
> > 16bit version of CP/M.
>
> I thought that all versions of CP/M-86 had the HELP command so that
> "HELP PIP" would tell you what you needed to know. If it doesn't
then
> it is easy enough to write a simple help page for your own needs.
My copy of CP/M-86 didn't come with a 'help.cmd' file. :-(
However I think I've got a copy of one somewhere, I'll just have to
dig it up & copy it over to CP/M-86.
> In 1982 Paul Allen (BG's partner in MS) gave a talk about the 'next
> release of MS-DOS', 1.25 was just released. One of its 'features'
would
> be a help facility. It took another 10 years before MS-DOS had one
in
> version 5.
Does PC-DOS 5 pre-date M$-DOS 5? My copy of PC-DOS 5 definitely has
it.
Regards,
Ross.
Michael J. Mahon
>"Richard Plinston" <rip...@Azonic.co.nz> wrote in message...
>
<snip>
>My copy of CP/M-86 didn't come with a 'help.cmd' file. :-(
>
>However I think I've got a copy of one somewhere, I'll just have to
>dig it up & copy it over to CP/M-86.
>
>> In 1982 Paul Allen (BG's partner in MS) gave a talk about the 'next
>> release of MS-DOS', 1.25 was just released. One of its 'features'
>would
>> be a help facility. It took another 10 years before MS-DOS had one
>in
>> version 5.
>
>Does PC-DOS 5 pre-date M$-DOS 5? My copy of PC-DOS 5 definitely has
>it.
I remember HELP in CP/M 2.2. It was pretty simple--like a TYPE of the
file <parameter>.HLP with "MORE" pagination.
With this simple scheme, it is trivial to add additional .HLP files as
needed, and to distribute them with new commands.
-michael
Check out 8-bit Apple sound that will amaze you on my
Home page: http://members.aol.com/MJMahon/
Ross Simpson
> >Does PC-DOS 5 pre-date M$-DOS 5? My copy of PC-DOS 5 definitely has
> >it.
>
> I remember HELP in CP/M 2.2. It was pretty simple--like a TYPE of
the
> file <parameter>.HLP with "MORE" pagination.
Oops! Sorry about the off-topics. I forgot for a second where I was.
:-)
> With this simple scheme, it is trivial to add additional .HLP files
as
> needed, and to distribute them with new commands.
Back to CP/M, I think my copy of CP/M 2.2 which came with my Amstrad
computer had a help system (although I'm not totally sure). The CP/M
Plus (v3) definitely did which was quite a flash affair (which was
also slightly tricky to use). :-)
Regards,
Ross.
bud
Hi Ross:
Group: comp.os.cpm Date: Tue, Sep 17, 2002, 3:14pm (CDT+15) From:
rosssimpson@my_spammers_address.com.au (Ross Simpson)
script:
>Oops! Sorry about the off-topics. I
>forgot for a second where I was.
>:-)
My (factory) copy of CP/M-86 V1.1 came on two 160K SS/DD disks. One had
the system, the other had HELP. HTH.
Ross Simpson
Hi Bud,
> >Oops! Sorry about the off-topics. I
> >forgot for a second where I was.
> >:-)
> My (factory) copy of CP/M-86 V1.1 came on two 160K SS/DD disks. One
had
> the system, the other had HELP. HTH.
Ah Okay. The version which I downloaded of the website I think just
had the files necessary to setup & get CP/M-86 v1.1 running. I've
downloaded a couple of different versions of the same OS which should
have the HELP files in.
Thanks.
Ross.