home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
CP/M
/
CPM_CDROM.iso
/
simtel
/
archives
/
cpm
/
8705-1.txt
< prev
next >
Wrap
Text File
|
1993-02-12
|
117KB
|
2,769 lines
1-May-87 10:31:31-MDT,1438;000000000000
Return-Path: <D-ROGERS@EDWARDS-2060.ARPA>
Received: from EDWARDS-2060.ARPA by SIMTEL20.ARPA with TCP; Fri, 1 May 87 10:31:15 MDT
Date: Fri 1 May 87 09:30:01-PDT
From: D-ROGERS@EDWARDS-2060.ARPA
Subject: z280 inquiry
To: info-cpm@SIMTEL20.ARPA
Message-ID: <12298928131.19.D-ROGERS@EDWARDS-2060.ARPA>
>>Date: 29 Apr 87 19:35:17 GMT
>>From: mcvax!enea!tut!pl@seismo.css.gov (Pertti Lehtinen)
>>Subject: Z280
>> .... When I was reading article, I start to wonder,
>> would there be any use for this kind of product,
>> or is this or last strike of Z80-empire.
>> Any opinions?
---------------
I would suspect that the Z280 has a real chance only if it gets
around some of the idiocies of the 8086 family, that make programming a
pain, while still being able to run old Z80 code without an emulator or
a Z80 option card.
Another *BIG* question is: memory manangement for HOW MUCH
memory? If it won't allow direct access to at least 4Mb, what good is
it? Right now, my next system looks to be a 68000 running CP/M-68K.
It may not run Z80 code, but i won't run short of memory any time soon.
Come to think of it maybe Tandy has a good idea in their model 6000; it
has both a 68000 and a Z80, although it isn't clear from the description
whether the user has access to the 8 bit processor or if it is a
dedicated i/o device.
[standard disclaimers and trademark acknowledgments apply.]
der
-------
2-May-87 13:31:18-MDT,888;000000000000
Return-Path: <lesh@BRL.ARPA>
Received: from BRL-SMOKE.ARPA by SIMTEL20.ARPA with TCP; Sat, 2 May 87 13:31:12 MDT
Date: Thu, 30 Apr 87 15:23:45 EDT
From: Steve Lesh (ISC | howard) <lesh@BRL.ARPA>
To: info-cpm@simtel20.arpa, info-apple@BRL.ARPA
Subject: configuring pcpi sftvideo
Message-ID: <8704301523.aa06678@SMOKE.BRL.ARPA>
Fiddling around with trying to get the gs "mouse" characters out of
inverse video text displays, I realized that I really don't understand how to
use "configsv".
What is the difference between the software screen cursor control se-
quences and the hardware cursor control sequences? When would you change the
software vs hardware sequences? (I was trying to embed the gs control charac-
ter to turn off the "mouse" characters in the "home cursor, clear screen" se-
quence.)
Thanks in advance.
Steven Lesh
2-May-87 17:53:38-MDT,1677;000000000000
Return-Path: <@wiscvm.wisc.edu:WCSCKCU@CARLETON.BITNET>
Received: from wiscvm.wisc.edu by SIMTEL20.ARPA with TCP; Sat, 2 May 87 17:53:13 MDT
Received: from CARLETON.BITNET by wiscvm.wisc.edu ; Sat, 02 May 87 18:52:18 CDT
Received: from WCSCKCU by CARLETON.BITNET on 02 May 87 19:07:09 EDT
Date: 02 May 87 18:18:00 EDT
From: Marc Grondin <WCSCKCU%CARLETON.BITNET@wiscvm.wisc.edu>
To: <nfo-Apple@BRL.ARPA>,
<LESH@BRL.ARPA>,
<INFO-CPM@SIMTEL20.ARPA>
Subject: Re: PCPI soft video config
When you run programs in CP/M, like Turbo, Bawsic, Sweep, etc, they
want to do screen positioning and clearing, this is the SOFTWARE
section of the configuration.
The hardware configuration is the part that the card wants. In
your case it is an Apple //e configuration. If you were using a
Videx 80 column card, then you would be configuring your hardware
section for this card.
Your idea of putting in the "Turn mouse text off" sequence into the
screen refresh would be placed in the Hardware section. Personally
I beleive that you are going the wrong route. I suggest that you
find another person with a PCPI that has a different version of the
drivers and try them, that is how I (Yes, I did have your mouse text
trouble) solved my problem. Now I have everything working great on
my PCPI, and I'm sure once you solve the problem, that when running
on a GS you will be so fast that keeping up will be fun.
If you have any comments about how the PCPI runs with the GS, please
tell me, I'm interested in a GS and I can't give up my CP/M...
Marc Grondin (8->) <Marc_Grondin@CARLETON.BITNET>, <CKCU@CARLETON.BITNET>
2-May-87 18:41:04-MDT,1520;000000000000
Return-Path: <marwood@dmc-crc.arpa>
Received: from dmc-crc.arpa by SIMTEL20.ARPA with TCP; Sat, 2 May 87 18:40:54 MDT
Received: by dmc-crc.arpa; (4.12/4.7)
id AA08487; Sat, 2 May 87 20:39:15 edt
Date: Sat, 2 May 87 20:39:15 edt
From: marwood@dmc-crc.arpa (G. J. Marwood)
Message-Id: <8705030039.AA08487@dmc-crc.arpa>
To: info-apple@BRL.ARPA, info-cpm@simtel20.arpa, lesh@BRL.ARPA
Subject: Re: configuring pcpi sftvideo
Regarding the difference between the terminal hardware definitions and terminal
software definitions for PCPI SFTVIDEO, you can consider these two things to be
"interface" definitions. The hardware definitions tell SFTVIDEO how to
communicate with your 80-column card (or whatever) using the control- or ESCape
sequences which are typically used to invoke various card functions, e.g. clear
screen; goto x,y etc. These definitions should be found in the manual for the
terminal (80-col etc) card. The software definitions are the code sequences,
typically ESCape sequences, which are used to communicate between your software
and SFTVIDEO. You will see examples of this for example in the terminal
installation INSTALL/WINSTALL programs for Wordstar. Basically, this allows
you to connect completely different terminal control functions in you
software to those in your hardware.
I hope this helps
Gordon Marwood
P.S. I know nothing about the mouse characters as I don't use a ][e.
3-May-87 07:43:42-MDT,1195;000000000000
Return-Path: <info-cpm-request@simtel20.arpa>
Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Sun, 3 May 87 07:43:29 MDT
Received: by ucbvax.Berkeley.EDU (5.57/1.25)
id AA23932; Sun, 3 May 87 06:20:56 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 1 May 87 22:07:51 GMT
From: pyramid!amdahl!cerebus!fai!wjvax!jeffs@decwrl.dec.com (Jeffery Siou)
Organization: Watkins Johnson Co., San Jose Ca. USA
Subject: CP/M for Model IV
Message-Id: <889@wjvax.wjvax.UUCP>
Sender: info-cpm-request@simtel20.arpa
To: info-cpm@simtel20.arpa
I presently own a Radio Shack Model 4. I'm looking for CP/M for it.
Is anyone familiar with Motezuma Micro's CP/M that sells for $169. Is it the
best available? Is there any other CP/M for my model 4. I was told to stay
away from Radio Shack's version of CP/M(I think it's called CP/M Plus).
Comments? Also what about this CP/M called Rose's CP/M that sells for $69.
Is the Montezuma Micro version worth the extra $100. Advice and comments
greatly appreciated.
Thanks in advance.
3-May-87 07:44:06-MDT,1707;000000000000
Return-Path: <info-cpm-request@simtel20.arpa>
Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Sun, 3 May 87 07:43:56 MDT
Received: by ucbvax.Berkeley.EDU (5.57/1.25)
id AA23949; Sun, 3 May 87 06:21:22 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 1 May 87 22:13:48 GMT
From: pyramid!amdahl!cerebus!fai!wjvax!jeffs@decwrl.dec.com (Jeffery Siou)
Organization: Watkins Johnson Co., San Jose Ca. USA
Subject: CP/M for Model 4
Message-Id: <890@wjvax.wjvax.UUCP>
Sender: info-cpm-request@simtel20.arpa
To: info-cpm@simtel20.arpa
This is a reposting of a previously submitted article but in the last posting
I left off my location(.signature).
Thanks..
I presently own a Radio Shack Model 4. I'm looking for CP/M for it.
Is anyone familiar with Motezuma Micro's CP/M that sells for $169. Is it the
best available? Is there any other CP/M for my model 4. I was told to stay
away from Radio Shack's version of CP/M(I think it's called CP/M Plus).
Comments? Also what about this CP/M called Rose's CP/M that sells for $69.
Is the Montezuma Micro version worth the extra $100. Advice and comments
greatly appreciated.
Thanks in advance.
Military Intelligence is a contradiction in terms.
Groucho Marx
--------
jeffery siou
...!{ ucbvax!decwrl!qubix, mordor!turtlevax, ihnp4!pesnta}!wjvax!jeffs
the above opinion's expressed are solely those of mine and is not at
all that of wj's or in any way related to wj's(they don't have one).
--
3-May-87 07:44:37-MDT,1430;000000000000
Return-Path: <info-cpm-request@simtel20.arpa>
Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Sun, 3 May 87 07:44:28 MDT
Received: by ucbvax.Berkeley.EDU (5.57/1.25)
id AA24084; Sun, 3 May 87 06:36:14 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 1 May 87 14:21:15 GMT
From: nbires!ico!isis!ross@ucbvax.Berkeley.EDU (Ross McConnell)
Organization: University of Denver, Math/CS
Subject: Re: nroff for MS-DOS or CP/M machines.
Message-Id: <1791@isis.UUCP>
Sender: info-cpm-request@simtel20.arpa
To: info-cpm@simtel20.arpa
>>Anyone know of a nroff clone for MS-DOS or CP/M machines?
>>I have a friend who has access to both of these machines and would
>>like to use nroff. Public domain would be nice.
>Elan Software makes an excelent WWB product, including
>ditroff and some drivers. Don't have the paper address,
>but their net machine is ihnp4!chinet!steinmetz!elan.
Doctor Dobb's Journal has Alan Holub's "nr" available for $29.95. I've just
received it, and haven't had a chance to really test it, but it seems like
a reasonable implementation of nroff. It comes with a version of the "ms"
macros, but again I haven't extensively tested them. For more details, see the
last three months issues of DDJ. By the way, "nr" is for MS-DOS machines.
3-May-87 10:26:52-MDT,13892;000000000000
Mail-From: KPETERSEN created at 3-May-87 10:26:42
Date: Sun, 3 May 1987 10:26 MDT
Message-ID: <KPETERSEN.12299451807.BABYL@SIMTEL20.ARPA>
Sender: KPETERSEN@SIMTEL20.ARPA
From: Keith Petersen <W8SDZ@SIMTEL20.ARPA>
To: Info-Cpm@SIMTEL20.ARPA
Subject: Programming the Intel 8251a USART (long)
I don't usually post entire files to the Info-Cpm mailing list but I
have had so many requests for this information that it seems
appropriate.
I did NOT write this document. It was uploaded to my RCP/M system.
--Keith Petersen
Arpa: W8SDZ@SIMTEL20.ARPA
Uucp: {bellcore,decwrl,harvard,lll-crg,ucbvax,uw-beaver}!simtel20.arpa!w8sdz
GEnie Mail: W8SDZ
RCP/M Royal Oak: 313-759-6569 (300, 1200, 2400 bps)
--cut-here--INTE8251.ART--cut-here--
[ KAY*FOG RBBS | INTE8251.ART | published 05/30/85 | 379 lines 13k ]
INTEL8251: Programming the Intel 8251A USART
by: Ed Greenberg
Kay*Fog
CompuServe: 76703,1070
MCIMAIL: EDG
Preface
=======
This document was inspired by my collection of Intel data books.
Of the three databooks, only one contains the following
information. Most microcomputer users do not have this
information in their computer manuals and do not have access to
the Intel manuals. Murphy's law also states that the hobbyist
will not have the required manuals at midnight on Saturday when
he is busily trying to debug his communications program.
[Press ENTER key for more]
Introduction
============
In order to communicate via a serial port, a computer is equipped
with a device called a Universal Asynchronous Receiver/Transmitter
or UART. This device converts a byte (written to an output port)
to a series of bits sent one at a time (serially) from a
communications port. It also scans the input line on the serial
port and, detecting the beginning and end of each character,
assembles incoming characters and presents them on an input port.
Other names for this part are SIO's (serial input/output) or
Communications adapters and USARTS (Universal Synchronous/
Asynchronous Receiver/Transmitters).
This document deals with one common part - the Intel I8251a
USART. That usart is used in the North Star Horizon, the Morrow
Micro Decision, and other common computers. This discussion deals
with the 8251A only in asynchronous mode. It is the mode used
when communicating with a printer, a modem, a terminal and
usually, another microcomputer.
Using your USART
================
In order to use a communications port with a usart, one must
first initialize it. By doing so, one sets parameters that tells
the USART how to do it's job. One defines the parity, the number
of stop and data bits, and the divisor (if any) to be applied to
the incoming clock signal.
After the USART is initialized, one can read and write characters
on the data port of the usart. One can also check the status of
the usart on the status port.
Things to know before you start
===============================
Before you can write code for your usart, you must know the port
locations on which the usart appears. There are two ports,
called the DATA port and the STATUS port. Commands are written
to the status port, and the condition of the port is read from
it. Actual characters are written to and read from the data
port. A good place to find the port numbers is a published I/O
MAP in your manual. Another place is in a program listing of the
BIOS or a communications program. You will see something like
this:
STATUS EQU 80H
DATA EQU 81H
or the like. Sometimes, the word MODEM is worked into the label
(e.g. MODDATP for MODem DATa Port.) Be certain that you find the
correct set of ports in the case where your computer has more
than one usart.
A Note About Interrupts
=======================
Some computers use the facility called interrupts to signal the
processor that a character is ready. In this case, it is
important for the amateur programmer to avoid messing up the
interrupt structure of the machine. You should not read or write
your USART directly when it's interrupt is enabled. Doing so may
cause spurious interrupts of the processor. The result is that
nothing will work. Determining whether your computer uses
interrupts on the communications line is beyond the scope of this
document.
Initializing the usart
======================
The following code fragment is taken from the MEX overlay for the
Morrow Micro Decision. MEX is written and copyrighted by Robert
Fowler. The comments are my own.
INITMOD: ...
...
MVI A,087H ;Take the usart out of
OUT MODCTL1 ; the condition for
OUT MODCTL1 ; setting the mode (*)
MVI A,40H ;Put it back into that
OUT MODCTL1 ; condition. This resets
; just about everything for
; new commands.
INITMOD1: MVI A,4EH ;This is the MODE BYTE (*)
OUT MODCTL1 ;Send it to the control/status port
MVI A,37H ;This is the COMMAND BYTE (*)
OUT MODCTL1 ;Send it to the control/status port
IN PORT ;Clear out the DATA port
RET ;Return
(*) See the definition below
Input and Output of Characters
==============================
Below are sample routines for input and output of characters on
the 8080 (or Z80) using an 8251A.
;Input character routine. Character is returned in A.
INPUT: IN STATUS ;Get the status of the usart
ANI 2 ;turn off all bits but RxR (**)
JZ INPUT ;go back and check again because
; there is no character ready
IN DATA ;There is a character ready,
; so go get it.
;OPTIONAL STEP
ANI 7FH ;Remove the high bit
RET ;Go back to the caller
;Output character routine. Character is provided in C.
OUTPUT: IN STATUS ;Get the status of the usart
ANI 1 ;turn off all bits but TxR (**)
JZ OUTPUT ;Go back and check again because
; the USART isn't ready for another
; character.
MOV A,C ;The USART is ready, so get the
; character in A for output
OUT DATA ;Now output it and...
RET ;Return to the caller.
(**) See the definition of the Status byte below
The remainder of this document is concerned with defining the
actual bytes sent to (and received from) the usart.
-----------------------------------------------------------------
Format of the Mode Byte
=======================
7 6 5 4 3 2 1 0
+----+----+----+----+----+----+----+----+
|s(2)|s(1)| ep |pen |l(2)|l(1)|b(2)|b(1)|
+----+----+----+----+----+----+----+----+
Content of the Mode byte
========================
s(2) and s(1) - the stop bit indicators:
----------------------------------------
s(2) s(1) meaning
---- ---- -------
0 0 Invalid
0 1 1 stop bit
1 0 1.5 stop bits
1 1 2 stop bits
ep - the parity bit
--------------------
ep meaning
-- -------
0 Odd parity is generated and checked
1 Even parity is generated and checked
Note: this bit is only active when pen is set
to 1.
pen - the parity enable bit
---------------------------
pen meaning
--- -------
0 parity disabled
1 parity enabled
l(2) and l(1) - the word length bits
------------------------------------
l(2) l(1) meaning
---- ---- -------
0 0 5 bits
0 1 6 bits
1 0 7 bits
1 1 8 bits
Note: For ASCII, we usually use only 7 or 8 bits.
Hams and TTY/TDD (for the deaf) use 5 bits. The only
thing that 6 bits is used for is a colloquialism for
seventy five cents.
b(2) and b(1) - the baud rate divisor bits
------------------------------------
b(2) b(1) meaning
---- ---- -------
0 0 synchronous
0 1 1x
1 0 16x
1 1 64x
Note: This should be left alone. Whatever
your system comes equipped for... that's it.
Format of the Command Byte
==========================
7 6 5 4 3 2 1 0
+----+----+----+----+----+----+----+----+
|EH |IR |RTS |ER |SBRK|RxE |DTR |TxEN|
+----+----+----+----+----+----+----+----+
Content of the Command Byte
===========================
EH - the Enter Hunt Mode bit
----------------------------
This bit has no effect in async mode!
IR - Internal Reset
-------------------
1 Returns 8251A to Mode Instruction format.
RTS - Request to Send
---------------------
1 will force RTS high on the RS-232 connector.
Note: This assumes that the designer hooked all
the signals up on the PC board. This is not
necessarily true.
On some computers, where the port is wired backwards,
this will control CTS rather than RTS.
ER - Error Reset
----------------
1 Will reset error flags in the status word
(PE OE and FE will be reset.) See the definition
of the status word below.
SBRK - Send a break
-------------------
1 Will send a break
Note: Usually, one sends a command with this bit set
and then, after a delay that equals the length of a
break, one sends another command that does not have
the break bit on.
RxE - Receive Enable
--------------------
1 will enable the receiver. If you are going to disable
the receiver for any reason, you should have a data book
in front of you and know what you're doing. This bit
should almost always be on for any command you send.
DTR - Data Terminal Ready
-------------------------
1 will turn on Data Terminal Ready at the RS-232 connector.
Note: This assumes that the designer hooked all
the signals up on the PC board. This is not
necessarily true.
On some computers, where the port is wired backwards,
this will control DSR rather than DTR.
TxE - Transmitter Enable
------------------------
1 will enable the transmitter. If you are going to disable
the transmitter for any reason, you should have a data book
in front of you and know what you're doing. This bit should
almost always be on for any command you send.
Format of the Status Byte
=========================
7 6 5 4 3 2 1 0
+----+----+----+----+----+----+----+----+
|DSR |SDET|RE |OE |PE |TxE |RxR |TxR |
+----+----+----+----+----+----+----+----+
Content of the Status Byte
==========================
DSR - Data Set Ready
--------------------
1 Indicates that DSR is low! That's right, Low!
Note that this bit may be (a) not wired at all or (b)
wired to DTR or some other pin on the RS-232 connector.
The only way to tell for sure is to look at a schematic.
SDET - SYNC Detect/ BREAK Detect
--------------------------------
(In the Intel documentation this is called SYNDET, not SDET.)
In async mode, this bit "will go high whenever an all zero word
of the programmed length (including start bit, data bit, parity
bit and *one* stop bit) is received." (***) In other words, when
the other end sends *you* a break.
This bit stays high until a reset command is issued.
FE - Framing Error
------------------
This bit is set when "A valid stop bit is not detected at the end of
every character."
This bit stays high until a reset command is issued.
OE - Overrun Error
------------------
This bit is set when a character has been pending on the USART buffer
and another character comes in before the first one has been read.
The first character is lost and this bit is set to alert the CPU to
the problem.
This bit stays high until a reset command is issued.
PE - Parity Error
-----------------
This bit is set when a parity error is detected.
This bit stays high until a reset command is issued.
TxEMPTY - Transmit Buffer Empty
-------------------------------
"When the 8251A has no characters to transmit, the TxEMPTY ...
[bit will be set to 1.] ... " (***)
RxRDY - Receiver Ready
----------------------
"This ... [bit set to 1] ... indicates that the 8251A contains
a character that is ready to be input to the CPU." (***)
This is the usual bit to test to see if a character is available.
Usually one sees ANI 2 (on 8080) when this bit is tested.
TxRDY - Transmitter Ready
-------------------------
"This ... [bit set to a 1] ... signals the CPU that the transmitter
is ready to accept a data character."
This is the usual bit to test to see if a character may be sent.
Usually one sees ANI 1 (on 8080) when this bit is tested.
----------------------- End of INTE8251.ART Text -----------------------
3-May-87 13:26:33-MDT,1276;000000000000
Return-Path: <@wiscvm.wisc.edu:MSRS003@ECNCDC.BITNET>
Received: from wiscvm.wisc.edu by SIMTEL20.ARPA with TCP; Sun, 3 May 87 13:26:13 MDT
Received: from ECNCDC.BITNET by wiscvm.wisc.edu ; Sun, 03 May 87 14:25:09 CDT
From: Scott McBurney <MSRS003%ECNCDC.BITNET@wiscvm.wisc.edu>
Subject: CPM FOR Model 4
To: JEFFERY SIOU <PYRAMID!AMDAHL!CEREBUS!FAI!WJVAX!JEFFS@decwrl>
Montezum Micro's CP/M is the best for the Model 4. For your money you
get an excellent implementation of CP/M with facilities to read disks
of many other CP/M formats. Rose's CPM is actually Montezuma's old version
which was somewhat limited. Radio Shack's CP/M plus is nice, but you can
not read any other CP/M formats with it, and it doesn't have all the nice
features of Montezuma's.
Scott McBurney
Western Illinois University
--------------
BITNET: MSRS003@ECNCDC.BITNET
Internet: MSRS003%ECNCDC.BITNET@WISCVM.WISC.EDU
GEnie: S.MCBURNEY
-----------------------------------------------------------------
Disclaimer: Any opinions expressed herein could be the
random babblings of an idiot.
-----------------------------------------------------------------
3-May-87 16:46:49-MDT,2530;000000000000
Return-Path: <info-cpm-request@simtel20.arpa>
Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Sun, 3 May 87 16:46:40 MDT
Received: by ucbvax.Berkeley.EDU (5.57/1.25)
id AA00160; Sun, 3 May 87 15:41:17 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 2 May 87 13:31:33 GMT
From: ptsfa!nonvon!apn@ames.arpa (root)
Organization: NONVON Systems Computer Research Group
Subject: Re: z280 inquiry
Message-Id: <114@nonvon.UUCP>
References: <12298928131.19.D-ROGERS@EDWARDS-2060.ARPA>
Sender: info-cpm-request@simtel20.arpa
To: info-cpm@simtel20.arpa
in article <12298928131.19.D-ROGERS@EDWARDS-2060.ARPA>, D-ROGERS@EDWARDS-2060.ARPA says:
>
>>>Date: 29 Apr 87 19:35:17 GMT
>>>From: mcvax!enea!tut!pl@seismo.css.gov (Pertti Lehtinen)
>>>Subject: Z280
>
>>> .... When I was reading article, I start to wonder,
>>> would there be any use for this kind of product,
>>> or is this or last strike of Z80-empire.
>
>>> Any opinions?
> ---------------
> I would suspect that the Z280 has a real chance only if it gets
> around some of the idiocies of the 8086 family, that make programming a
> pain, while still being able to run old Z80 code without an emulator or
> a Z80 option card.
> Another *BIG* question is: memory manangement for HOW MUCH
> memory? If it won't allow direct access to at least 4Mb, what good is
> it? Right now, my next system looks to be a 68000 running CP/M-68K.
> It may not run Z80 code, but i won't run short of memory any time soon.
> Come to think of it maybe Tandy has a good idea in their model 6000; it
> has both a 68000 and a Z80, although it isn't clear from the description
> whether the user has access to the 8 bit processor or if it is a
> dedicated i/o device.
>
> [standard disclaimers and trademark acknowledgments apply.]
> der
>
> -------
no..... the user did not have much access to the z80 processor
when on the 68k. It was a dedicated i/o processor, and tandy does not
give out ( or make available) any info on how to access it.
-alex p novickis
--
UUCP: {ihnp4,ames,qantel,sun,seismo,amdahl,lll-crg,pyramid}!ptsfa!nonvon!apn
{* Only those who attempt the absurd ... will achieve the impossible *}
{* I think... I think it's in my basement... Let me go upstairs and check. *}
{* -escher *}
3-May-87 19:13:53-MDT,2362;000000000000
Return-Path: <info-cpm-request@simtel20.arpa>
Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Sun, 3 May 87 19:13:36 MDT
Received: by ucbvax.Berkeley.EDU (5.57/1.25)
id AA01723; Sun, 3 May 87 18:00:40 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 4 May 87 00:46:02 GMT
From: umnd-cs!ub.D.UMN.EDU!rhealey@ucbvax.Berkeley.EDU (Rob Healey)
Organization: U. of Minnesota, Duluth - Computing Services
Subject: Re: CP/M for Model IV
Message-Id: <581@umnd-cs.D.UMN.EDU>
References: <889@wjvax.wjvax.UUCP>
Sender: info-cpm-request@simtel20.arpa
To: info-cpm@simtel20.arpa
In article <889@wjvax.wjvax.UUCP> jeffs@wjvax.UUCP (Jeffery Siou) writes:
>I presently own a Radio Shack Model 4. I'm looking for CP/M for it.
>Is anyone familiar with Motezuma Micro's CP/M that sells for $169. Is it the
>best available? Is there any other CP/M for my model 4. I was told to stay
>away from Radio Shack's version of CP/M(I think it's called CP/M Plus).
>Comments? Also what about this CP/M called Rose's CP/M that sells for $69.
>Is the Montezuma Micro version worth the extra $100. Advice and comments
>greatly appreciated.
>
I own a Model 4, gate array version i.e. newest, with 2 DS DD
40 track drives. I have Monte's CP/M and it IS THE CP/M for model 4's
BAR NONE. Rose's CP/M is a very old, very striped down, version
of Monte's CP/M, the extra $100.00 you pay for Monte's current version
gives you some excellent utilitys plus the ability to automatically use
the top 64K in a 128K machine as a RAM disk. I felt the $169.00 is worth
it because the current version allows alot of flexibility with disk
drives and peripherals. You would be a fool to even contemplate Tandy's
CP/M, it is a piece of SH*T plain and simple. Your choice is whether
you want a newer or VERY older version of Monte's CP/M. I think the $100
bucks you spend on the newest version would save you alot of grief down
the road. By the way, simtel20 has a huge PD library, almost 98% of the
CP/M programs I've grabbed off of simtel20 have worked first shot on
the Model 4 using Monte's CP/M, version 2.31.
Hope this helps,
-Rob Healey
rhealey@ub.d.umn.edu
4-May-87 19:47:27-MDT,1047;000000000000
Return-Path: <info-cpm-request@simtel20.arpa>
Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Mon, 4 May 87 19:47:09 MDT
Received: by ucbvax.Berkeley.EDU (5.57/1.25)
id AA24993; Mon, 4 May 87 18:38:30 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 4 May 87 18:40:20 GMT
From: hal9000!root@RUTGERS.EDU
Subject: Re: nroff for MS-DOS or CP/M machines.
Message-Id: <1128@hal9000.UUCP>
Sender: info-cpm-request@simtel20.arpa
To: info-cpm@simtel20.arpa
In article <330@cblpf.ATT.COM>, dar@cblpf.ATT.COM (David Roth) writes:
> Anyone know of a nroff clone for MS-DOS or CP/M machines?
Look in the last few issues of "Dr Dobb's Journal". There was a series
articles detailing an nroff imitator for (I think) MSDOS. Program is
available from the publisher at some low price (I don't remember, since
I wasn't interested, but I would guess ~$50). Includes source code, I
think.
6-May-87 12:07:14-MDT,1605;000000000000
Return-Path: <info-cpm-request@simtel20.arpa>
Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Wed, 6 May 87 12:07:07 MDT
Received: by ucbvax.Berkeley.EDU (5.57/1.25)
id AA25775; Wed, 6 May 87 10:49:34 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 6 May 87 15:33:08 GMT
From: beta!dzzr@hc.dspo.gov (Douglas J Roberts)
Organization: Los Alamos Natl Lab, Los Alamos, N.M.
Subject: A problem with my parallel output port (HELP, please)
Message-Id: <5116@beta.UUCP>
Sender: info-cpm-request@simtel20.arpa
To: info-cpm@simtel20.arpa
I recently stuck an external modem on my old Northstar, using the
second of its two serial ports. I then constructed a parallel cable,
removed the serial interface card from the Epson MX-80, and modified
my LifeBoat Associates CP/M 2.21 using MOVCPM and SYSGEN to tell
the system that the printer was now on the parallel output port.
What reached the printer was (seemingly) bit-shifted garbage. The
handshaking worked fine, but I suspect that the printer driver in my
CPM is fouled.
I then wrote a little 8080 test code to send characters to the
parallel output port, and it worked fine. I would like to modify
my USER.ASM file to include a parallel port driver that I know
works, but I don't know how to patch the user stuff into CPM after
I'm done.
Can anyone out there in NETLAND help? (Keith, are you listening?)
Thanks in advance for all the good help....
--Doug Roberts
6-May-87 17:57:10-MDT,985;000000000000
Return-Path: <UUCP@ncsuvx.ncsu.edu>
Received: from ncsuvx.ncsu.edu by SIMTEL20.ARPA with TCP; Wed, 6 May 87 17:56:37 MDT
Received: by ncsuvx.ncsu.edu (5.54/2 4/27/87)
id AA08959; Wed, 6 May 87 19:56:26 EDT
Posted-Date: Wed, 6 May 87 19:49:18 EDT
Received: by ncspm.ncsu.edu (4.12/smail2.2/03-06-87)
id AA03595; 6 May 87 19:49:27 EDT (Wed)
From: kevin@ncspm.ncsu.edu (Kevin D. Bond)
Message-Id: <8705062349.AA03595@ncspm.ncsu.edu>
To: info-cpm@simtel20.arpa
Date: Wed, 6 May 87 19:49:18 EDT
Subject: Osborne Screen
X-Mailer: Elm [version 1.5b]
Could someone please tell me if and/or how to change the osborne to
display more than 40 columns when using an external monitor.
I am posting this for a friend, I know very little about the osborne.
-kevin
--
-------------------------------------------------------------------
Kevin D. Bond uucp: ...!mcnc!ncsuvx!ncspm!kevin
Domain: kevin@ncspm.ncsu.edu internet: kevin%ncspm@ncsuvx.ncsu.edu
6-May-87 23:40:25-MDT,2911;000000000000
Return-Path: <info-cpm-request@simtel20.arpa>
Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Wed, 6 May 87 23:40:07 MDT
Received: by ucbvax.Berkeley.EDU (5.57/1.25)
id AA08247; Wed, 6 May 87 20:46:17 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 5 May 87 19:41:40 GMT
From: ihnp4!homxb!houxm!whuts!whuxm!davew@ucbvax.Berkeley.EDU (WONNACOTT)
Organization: AT&T Bell Laboratories
Subject: configuring CP/M with ddsysgen
Message-Id: <533@whuxm.UUCP>
Sender: info-cpm-request@simtel20.arpa
To: info-cpm@simtel20.arpa
I've got an ATR8000 CP/M system, and I'm having trouble adding new drives.
I'm not sure how much of the following is true on other CP/M 2.2 systems,
and how much is specific to my machine.
The ATR8000 can use several types of drives, single or double sided, 5 1/4
or 8 inch, all at once. The manual instructs you to patch CP/M with
the "ddsysgen" program to configure it for the drives you install.
ddsysgen is a variant of "sysgen" for double density, which has an option
called "generate custom CP/M". I got a new disk drive a while back, set
the drive number on it, and plugged it in... so far, so good.
So I tried to patch CP/M with "ddsysgen". I read in the system tracks,
and then selected the option to customize CP/M. It requested the file
"SYSTEM.SWP", (SWP, INC. makes the machine). According to the manual,
this file contains the symbolic names of all the parameters you might need
to change. I was then prompted for names of locations within CP/M, and
I was shown the contents to each location, and allowed to change it.
The problem came when I looked at some of the parameters, like "ONEDSK"
(which makes the system use only one drive), or "RATEB" (which controls
the step rate of drive B), or the parameter which controls the number of
tracks on a drive (I've forgotten the name). Some of the values there
didn't seem to agree with what the manual said should be there. And
when I changed them, strange things happened. They happened even when I
took the new drive off the system, but not when I went back to my backup
copy of CP/M.
It sounds a bit like I've got a bad copy of "SYSTEM.SWP", and I was just
trashing random parts of the OS when I changed things. What I want to
know is:
1) Has anyone out there had any similar problems, and what did you do?
2) What might be the problem, other than a bad system file?
3) What can I do about it? I've done some hacking of disassembled code
on micros before, and I'd rather not do it again.
HELP!
--
David Wonnacott "They said Van Gogh was crazy, didn't they?"
whuxm!davew or rz3bb!davew
AT&T Corporate Education
The above opinions are not necessarily those of AT&T, or of anyone else anywhere
7-May-87 12:18:07-MDT,1293;000000000000
Return-Path: <Ghenis.pasa@Xerox.COM>
Received: from Xerox.COM by SIMTEL20.ARPA with TCP; Thu, 7 May 87 12:17:54 MDT
Received: from PinotNoir.ms by ArpaGateway.ms ; 07 MAY 87 11:17:37 PDT
Date: 7 May 87 11:14 PDT
From: Ghenis.pasa@Xerox.COM
Subject: Re: Osborne Screen
In-reply-to: kevin@ncspm.ncsu.edu (Kevin D. Bond)'s message of Wed, 6
May 87 19:49:18 EDT
To: kevin@ncspm.ncsu.edu
cc: info-cpm@simtel20.arpa
Message-ID: <870507-111737-1205@Xerox>
> Could someone please tell me if and/or how to change the osborne to
> display more than 40 columns when using an external monitor.
The "stock" Osborne displays up to 52 columns. There is a program called
SETUP provided with the Osborne on the Utility disk which will change
the number of columns you get before line-wrapping. A few public domain
programs perform the same function.
HOWEVER... for more than 52 columns your text will go off the edge on
BOTH the internal and external monitors. The only way around this is to
get a HARDWARE VIDEO UPGRADE, like the one from Nuevo Electronics. I
don't know what it costs now, but it's probably close to the market
value of the Osborne itself. I faced the same dilemma and chose to keep
my O-1 at 52 columns.
-- Pablo Ghenis, OKOK (Osborne Komputer Owners' Klub)
7-May-87 22:03:52-MDT,1794;000000000000
Mail-From: KPETERSEN created at 7-May-87 22:03:38
Date: 6 May 87 23:49 -0800
Message-ID: <KPETERSEN.12300627259.BABYL@SIMTEL20.ARPA>
Sender: Ken Wallewein <kenw%noah.arc.cdn%ubc.csnet@RELAY.CS.NET>
From: Ken Wallewein <kenw%noah.arc.cdn%ubc.csnet@RELAY.CS.NET>
To: info-cpm-request@SIMTEL20.ARPA
Subject: A problem with my parallel output port (HELP, please)
ReSent-From: KPETERSEN@SIMTEL20.ARPA
ReSent-To: Info-Cpm
ReSent-Date: Thu 7 May 1987 22:03-MDT
Patching the stuff in is (should be) trivial. It's a matter of reassembling
your BIOS with the appropriate device handler stuff included. Since you appear
to know 8080 assembler and how to handle a parallel port, the rest should be
easy. I ASSUME you have the BIOS source. Without it you're stuck.
At the very beginnning of BIOS are a bunch of CALL instructions. These are
the standard BIOS entry points for all the things the BIOS does. I don't have
my books here, so I can't tell you exactly which one it is. Your listing
should have it commented/labeled as LSTOUT or some such. The character to
be printed will be expected in a register, probably C. Your LSTOUT routine
should wait until the printer's not busy, send the character, and return.
I don't think return status is important here.
As I said, you really need your BIOS listing. Read the existing code to
see what it does, following the path from the entry point at the top. It also
helps to have access to a CP/M Internals book. One of the best (I can't
remember the title) was written by Donald Cortesi of Dr. Dobb's Journal.
All you really need are the BIOS entry point and register-handling conventions.
You MIGHT want to worry about the USTAT byte for device redirection (via STAT),
but I never bother with that. Good luck.
/kenw
8-May-87 09:15:30-MDT,1225;000000000000
Return-Path: <@wiscvm.wisc.edu:BOBW@USU.BITNET>
Received: from wiscvm.wisc.edu by SIMTEL20.ARPA with TCP; Fri, 8 May 87 09:14:46 MDT
Received: from USU.BITNET by wiscvm.wisc.edu ; Fri, 08 May 87 09:47:13 CDT
Date: Fri, 8 May 87 08:06 MST
From: <BOBW%USU.BITNET@wiscvm.wisc.edu> (BOB WOOD WA7MXZ)
Subject: North Star Parallel Port Patching
To: info-CPM@simtel20.arpa
X-Original-To: info-CPM@simtel20.arpa
Re: North Star Parallel Port.
ACCORDING TO MY LIFEBOAT MANUAL, THERE IS A PARALLEL PRINTER DRIVER ALREADY
INCLUDED IN THEIR CPM THAT WORKS FINE (I TRIED IT). YOU'LL HAVE TO FIND WHERE
THE PROPER OFFSETS ARE FOR YOUR INSTALLATION OF CPM. These addresses are the
distribution offsets.
right now HLIST points to a jump to the serial port:
5A09 C3525A HLIST JMP HOROUT1 ; Right Serial Port
my address is FA09 for 56K CPM.
the address for HOROUT1 is 5A5D. To get the parallel to work you point to
error in above line... HOROUT1 is at 5A52 (FA52) HOROUT2 (parallel) is at
5A5D (FA5D). All I did was patch location FA0A to 5D and then ran:
A>SAVEUSER
Saveuser is the Lifeboat user area patch program.
This works for the Horizon, I hope you don't have an Advantage.
Bob Wood
8-May-87 09:59:52-MDT,1591;000000000000
Return-Path: <kenw%noah.arc.cdn%ubc.csnet@RELAY.CS.NET>
Received: from RELAY.CS.NET by SIMTEL20.ARPA with TCP; Fri, 8 May 87 09:59:22 MDT
Received: from relay2.cs.net by RELAY.CS.NET id ac15332; 8 May 87 11:52 EDT
Received: from ubc by RELAY.CS.NET id ad05895; 8 May 87 11:46 EDT
Received: by ubc.csnet id AA10521; Fri, 8 May 87 08:20:57 pdt
Date: 8 May 87 0:20 -0800
From: Ken Wallewein <kenw%noah.arc.cdn%ubc.csnet@RELAY.CS.NET>
To: info-cpm-request@SIMTEL20.ARPA
MMDF-Warning: Parse error in original version of preceding line at RELAY.CS.NET
Cc: info-cpm@SIMTEL20.ARPA
MMDF-Warning: Parse error in original version of preceding line at RELAY.CS.NET
In-Reply-To: <533@whuxm.UUCP>
Message-Id: <110*kenw@noah.arc.cdn>
Subject: configuring CP/M with ddsysgen
What you probably have is a previously customized version of your SYSTEM.SWP
file. If an entry doesn't need to be changed to add your disk drive, don't
change it. Some of them MAY be worth tinkering with, but it helps if you know
what they're for. And, of course, only make minimum changes between tests.
Whether your drive is physically connected or not will probably make no
difference whatsoever to your use of the rest of the machine.
Question: If you use ddsysgen (I have one of those, too, but it's nothing
like yours) without making any changes, is the result useable?
I presume you don't have the source for your BIOS: my sympathies. If you
decide to disassemble it, I recommend RESOURCE, ZESOURCE, or DASM, and you'll
need to read the instructions :-).
Good luck.
/kenw
8-May-87 13:26:54-MDT,1561;000000000000
Return-Path: <@wiscvm.wisc.edu:RMALOUF@SBCCMAIL.BITNET>
Received: from wiscvm.wisc.edu by SIMTEL20.ARPA with TCP; Fri, 8 May 87 13:26:19 MDT
Received: from SBCCMAIL.BITNET by wiscvm.wisc.edu ; Fri, 08 May 87 14:24:10 CDT
Date: Fri, 8 May 87 15:22 EDT
From: <RMALOUF%SBCCMAIL.BITNET@wiscvm.wisc.edu> (Rob Malouf)
Subject: Osborne Screen
To: info-cpm@simtel20.arpa
X-Original-To: info-cpm@simtel20.arpa
> Could someone please tell me if and/or how to change the osborne to
> display more than 40 columns when using an external monitor.
Even with an upgrade (at least the OCC factory upgrade), the Osborne external
monitor attached to the "MONITOR" port will not display 80/132 columns without
an extra doo-dad. Only the composite RCA jack outputs 80/132 column video.
The adaptor, which I received from OCC with my newly upgraded tan case Osborne,
seems to convert the composite output to whatever the Osborne monitor uses and
adds the power lines.
BTW, doe anybody know why removing the little dummy plug from the "MONITOR"
jack with the power on fries its innards? The manual warns about that, and
once I accidentally did it, and sure enough, the video subsystem died. How
come?
Rob Malouf
Marine Sciences Research Center
State University of New York
Stony Brook, NY 11794-5000
RMALOUF@SBCCMAIL.BITNET
9-May-87 11:46:24-MDT,1838;000000000000
Mail-From: KPETERSEN created at 9-May-87 11:46:07
Date: Sat, 9 May 1987 11:46 MDT
Message-ID: <KPETERSEN.12301039127.BABYL@SIMTEL20.ARPA>
Sender: KPETERSEN@SIMTEL20.ARPA
From: Keith Petersen <W8SDZ@SIMTEL20.ARPA>
To: INFO-HZ100@RADC-TOPS20.ARPA, INFO-IBMPC@C.ISI.EDU
Cc: Info-Cpm@SIMTEL20.ARPA, Info-Micro@BRL.ARPA
Subject: Copyright status of ARC, LZW, and COMPRESS programs questioned
After announcing the availability of a recent update of SEA's ARC
program, I received the following message which raises serious doubts
as to the validity of the copyrights of SEA, Phil Katz, and Vernon
Berg's ARC programs and well as other LZW-type compression programs
and the status of the popular Unix "compress" program.
--Keith Petersen
Arpa: W8SDZ@SIMTEL20.ARPA
Uucp: {bellcore,decwrl,harvard,lll-crg,ucbvax,uw-beaver}!simtel20.arpa!w8sdz
GEnie Mail: W8SDZ
--forwarded message--
To: Keith Petersen <W8SDZ@SIMTEL20.ARPA>
Re: Message for the authors of ARC
I don't know how to get in touch with the authors of ARC (I didn't see
any addresses in INFO-IBMPC), but since you seem to be posting information
about new versions, etc., I thought that you might be able to forward the
following mail to them.
1) The correct spelling of the name is Ziv. So you should call it
Lempel-Ziv (or Ziv-Lempel because that was the order of the author's
names in the original paper) encoding.
2) The original Ziv-Lempel method is patented (#4,464,650 -- Willard
Eastman, Abraham Lempel, Jacob Ziv, Martin Cohen) assigned to Sperry
Univac (now Unisys). Since the Welch modifications are to this
method, I would think that some sort of license agreement from Unisys
would be necessary (this is really only a practical problem for
commercial customers). Does such an agreement exist?
--end forwarded message--
11-May-87 23:39:03-MDT,2919;000000000000
Return-Path: <info-cpm-request@simtel20.arpa>
Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Mon, 11 May 87 23:38:49 MDT
Received: by ucbvax.Berkeley.EDU (5.57/1.25)
id AA26761; Mon, 11 May 87 22:37:36 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 11 May 87 22:04:51 GMT
From: cbmvax!fred@RUTGERS.EDU (Fred Bowen)
Organization: Commodore Technology, West Chester, PA
Subject: Re: 6DEC vs. 8DEC - CP/M
Message-Id: <1862@cbmvax.cbmvax.cbm.UUCP>
References: <358@cup.portal.com>
Sender: info-cpm-request@simtel20.arpa
To: info-cpm@simtel20.arpa
> I have heard numerous accounts as to the nature of the 8DEC version of CP/M
> for the C-128. I'm interested in learning if this version is indeed
> available and being shipped with current equipment, and exactly what it
> achieves in the way of bug-fixes.
The following explanation comes from Alex Orgil, CBM Canada, where the 'bug'
was found (I was busy with other stuff at the time):
-----------------------------------------------------------------------------
As I recall, the difference was simply that the final line feed was not being
sent to the printer to clear the buffer, thus your last line didn't get
printed until you tried to print something else. This may have only occurred
wiht the MPS1000 printers though. The change was a single byte (or possibly
a string) in the BIOS. The fixed version was labelled DEC 8 by Von, and
later found its way into production. The NEWSYS.COM program for updating
the system was not changed (but was posted in public domain on Compuserve).
For Canada we made a special version of NEWSYS to reflect the change which
was made available through our [Canada] Parts department. But to make this
different, I also changed the date to read dec 8 (tricky hey?) so that we
could be sure of what they are using.
-----------------------------------------------------------------------------
Ergo, (love that word!) for most users there is no real difference between
the two versions. I have asked Alex to send me the patches he made to
NEWSYS.COM, and will post them for those people who can't bear not having
the absolute latest BIOS, whether they have an MPS-1000 or not.
I am putting the wraps on a new version which supports the 3.5" 1581 drive
which should be showing up on shelves "any day now." Those of you who are
still reading may want to wait until the "1581" version is available before
you bother patching your 06DEC85 version.
I know better than to ask if there are any other CP/M bugs worth fixing...
--
--
--
Fred Bowen uucp: {ihnp4|seismo|caip}!cbmvax!fred
arpa: cbmvax!fred@seismo.css.GOV
tele: 215 431-9100
Commodore Electronics, Ltd., 1200 Wilson Drive, West Chester, PA, 19380
12-May-87 03:38:33-MDT,1145;000000000000
Return-Path: <info-cpm-request@simtel20.arpa>
Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Tue, 12 May 87 03:38:22 MDT
Received: by ucbvax.Berkeley.EDU (5.57/1.25)
id AA00293; Tue, 12 May 87 02:34:50 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 11 May 87 18:29:49 GMT
From: jade!lapis.berkeley.edu!oster@ucbvax.Berkeley.EDU (David Phillip Oster)
Organization: University of California, Berkeley
Subject: Using a KayPro 4-e Internal Modem?
Message-Id: <3531@jade.BERKELEY.EDU>
Sender: info-cpm-request@simtel20.arpa
To: info-cpm@simtel20.arpa
I am trying to use a KayPro 4-e, with an internal modem that takes a phone
cable and directly connects to the phone system. Does anyone out there
know:
1.) Is this machine, by any chance, equipped with a 1200/300 baud modem or
is it just 300 baud?
2.) Do you have to run some command, or set some switch, or type something
to the supplied terminal software to use the internal modem rather than an
external serial port?
12-May-87 19:12:45-MDT,1223;000000000000
Return-Path: <info-cpm-request@simtel20.arpa>
Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Tue, 12 May 87 19:12:31 MDT
Received: by ucbvax.Berkeley.EDU (5.57/1.25)
id AA15237; Tue, 12 May 87 17:55:48 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 12 May 87 17:58:32 GMT
From: ptsfa!nonvon!root@ames.arpa (root)
Organization: NONVON Systems Computer Research Group
Subject: WANTED: MEX overlay, generic
Message-Id: <309@nonvon.UUCP>
Sender: info-cpm-request@simtel20.arpa
To: info-cpm@simtel20.arpa
I would to get a copy of the "generic" or any for that matter,
overlays for MEX ( modem executive ). I have the PD version, and
not the latest. Could someone that has a copy please mail me
a note.
Thanks,
Alex P Novickis
UUCP: {ihnp4,ames,qantel,sun,seismo,amdahl,lll-crg,pyramid}!ptsfa!nonvon!apn
{* Only those who attempt the absurd ... will achieve the impossible *}
{* I think... I think it's in my basement... Let me go upstairs and check. *}
{* -escher *}
13-May-87 22:03:05-MDT,4848;000000000000
Mail-From: KPETERSEN created at 13-May-87 22:02:29
Date: Monday, 11 May 1987 21:56-MDT
Message-ID: <KPETERSEN.12302199905.BABYL@SIMTEL20.ARPA>
Sender: "James A. Woods" <jaw%aurora.uucp@BRL.ARPA>
From: "James A. Woods" <jaw%aurora.uucp@BRL.ARPA>
To: info-micro@BRL-VGR.ARPA
Subject: Copyright status of ARC, LZW, and COMPRESS programs questioned
ReSent-From: KPETERSEN@SIMTEL20.ARPA
ReSent-To: Info-Cpm at SIMTEL20.ARPA
ReSent-Date: Wed 13 May 1987 22:02-MDT
# "Don't compress that dwarf -- hand me the pliers!" -- after Firesign Theatre
> 2) The original Ziv-Lempel method is patented (#4,464,650 -- Willard
> Eastman, Abraham Lempel, Jacob Ziv, Martin Cohen) assigned to Sperry
> Univac (now Unisys). Since the Welch modifications are to this
> method, I would think that some sort of license agreement from Unisys
> would be necessary (this is really only a practical problem for
> commercial customers). Does such an agreement exist?
>
Professor Lempel once telephoned me to praise the existence of a
public domain implementation of the LZ algorithm. Though I can take credit
only for the encoder hashing method currently used in 'compress', as well
as its "block-adaptive" table reset strategy (we remain indebted to Spencer
Thomas of the Univ. of Utah who gave USENET the basic framework), I'll
repeat here a comment relayed to me after a Lempel lecture at HP Labs.
The story goes like this: apparently the Welch paper came to the
light of day only after Sperry Research Labs was disbanded, this occurring
long before the Burroughs acquisition. Supposedly, discoveries revert
to the general public when a lab ceases to exist. Note this is *not*
the same as the situation engendered by the recent asset transfer from GE
to SRI of the RCA David Sarnoff Labs.
In any event, the Welch implementation (Computer, vol. 17, #6, 1984)
only claimed that the presented "hardware" string table creation and access
method was "Sperry proprietary". Details of any software-based code/index
storage scheme in existence at Sperry were deliberately left fuzzy in the paper.
Since patents cover only "apparatus", no one is making claims for
any of the algorithmic variants of LZ, of which there are many (see below).
As for the copyright status of 'compress', Thomas and I (who both work at
public institutions) have signed (meaningless?) waivers not only to UCB
for the 4.3 distribution, but to Hewlett Packard for inclusion in their
own Unix release. The latter is most ironic, since HP retained Lempel
as a consultant for a year on sabbatical leave from Technion in Israel,
where he was chairman of the computer science department.
ARC is another matter, of which I know little. It is fine by me
if someone sells a value-added 'compress' (you'd pay for the packaging
and "support"). Other companies sell the Unix LZ as part of a product
(the Talaris 'troff' software includes compressed fonts this way). Now
I hear that Dan Robinson of Telebit (our friendly neighborhood 18 kbps
modem supplier) has valiantly jammed compression into the modem ROM,
adding a few tricks of his own, no doubt. Speaking again only for myself,
it doesn't matter even if raw unadorned 'compress' were sold for a megabuck --
word would get around very quickly that it's available free from other
sources.
LZ algorithms are not the be-all-end-all of data compression techniques.
They don't particularly work well (unmodified), for digital sound processing
or color picture reduction, for example. Many variants employ equally many
time-space tradeoffs, with software implementations using data structures
ranging from binary trees, to "trie forests", to hash coding, to a direct
sparse array access exercise (for multi-megabyte machines) I posted to
USENET back in 1984/5. Software work continuing at the Univ. of Calgary
should be mentioned, where Tim Bell claims a 5-10% rate improvement (for
ASCII-only input, alas), and unfortunately using an encoder which runs
a hefty order-of-magnitude slower, limiting application. (See his IEEE Trans.
Comm. paper of Dec. 1986, which oddly sidesteps direct comparisons with
'compress'). Also, many ad hoc and not-so-ad hoc methods have been offered
to squeeze data, including the very involved Markov schemes of Cleary
and Witten, and the nouveau self-adaptive splay-tree amortization
algorithms of Bentley and Tarjan.
I could go on, but close by indicating that though optimal data
compression in general is unsolvable in the Turing sense, and though
many problem subclasses are NP-complete, the beautifully simple, linear,
and general method of Ziv and Lempel is hard to improve upon, and certainly
affords many approaches not subject to legal intervention.
-- James A. Woods (ames!jaw)
13-May-87 22:10:57-MDT,1080;000000000000
Return-Path: <info-cpm-request@simtel20.arpa>
Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Wed, 13 May 87 22:10:33 MDT
Received: by ucbvax.Berkeley.EDU (5.57/1.25)
id AA13838; Wed, 13 May 87 20:58:35 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 13 May 87 17:11:02 GMT
From: decvax!dartvax!stevel@ucbvax.Berkeley.EDU (Steve Ligett)
Organization: Dartmouth College, Hanover, NH
Subject: For sale: Morrow MD1
Message-Id: <6198@dartvax.UUCP>
Sender: info-cpm-request@simtel20.arpa
To: info-cpm@simtel20.arpa
I (for Dartmouth) have a single drive Micro Decision for sale.
It's been in a warehouse since '84, and I don't know much about
it, except I believe it works. It has a lot of documentation,
and a few disks.
Is it worth $100? Make an offer!
My phone number is 603 646-3189.
--
Steve Ligett stevel@dartmouth.edu or
(astrovax cornell decvax harvard ihnp4 linus true)!dartvax!stevel
14-May-87 22:01:00-MDT,775;000000000000
Return-Path: <@wiscvm.wisc.edu:V125KJG8@UBVMS.BITNET>
Received: from wiscvm.wisc.edu by SIMTEL20.ARPA with TCP; Thu, 14 May 87 22:00:46 MDT
Received: from UBVMS.BITNET by wiscvm.wisc.edu ; Thu, 14 May 87 23:00:10 CDT
Date: Thu, 14 May 87 23:58 EDT
From: <V125KJG8%UBVMS.BITNET@wiscvm.wisc.edu>
Subject: Bank Switching Z-System on the HD64180
To: info-cpm@simtel20.arpa
X-Original-To: cpm, V125KJG8
Can anybody out there figure out a way to effectively bank switch the BDOS
and BIOS portion of Z-System into bank 1 (or any other bank) of the HD64180
so I can push the TPA size over my cramped 49K? Any hints or helps out there
would be appreciated.
--Curtis R. Anderson
State University of New York at Buffalo
V125KJG8@UBVMS.BITNET
15-May-87 05:55:44-MDT,703;000000000000
Mail-From: RCONN created at 15-May-87 05:55:40
Date: Fri, 15 May 87 05:55:40 MDT
From: Rick Conn <RCONN@SIMTEL20.ARPA>
Subject: Re: Bank Switching Z-System on the HD64180
To: V125KJG8%UBVMS.BITNET@WISCVM.WISC.EDU
cc: info-cpm@SIMTEL20.ARPA
In-Reply-To: Message from "<V125KJG8%UBVMS.BITNET@wiscvm.wisc.edu>" of Thu, 14 May 87 22:13:45 MDT
Message-ID: <12302548203.9.RCONN@SIMTEL20.ARPA>
Hello, Curtis,
Echelon is working the bank switching problem, last I heard.
Perhaps you should contact them to see how they are coming. It really
isn't an easy problem at all, especially with environment descriptor and
message buffer access being required for Z System operation.
Rick
-------
15-May-87 11:00:04-MDT,1301;000000000000
Return-Path: <D-ROGERS@EDWARDS-2060.ARPA>
Received: from EDWARDS-2060.ARPA by SIMTEL20.ARPA with TCP; Fri, 15 May 87 10:59:38 MDT
Date: Fri 15 May 87 09:59:21-PDT
From: D-ROGERS@EDWARDS-2060.ARPA
Subject: HD64180 PAGING
To: info-cpm@SIMTEL20.ARPA
Message-ID: <12302603487.15.D-ROGERS@EDWARDS-2060.ARPA>
>14-May-87 21:24:45-PDT,870;000000000001
>From: <V125KJG8%UBVMS.BITNET@wiscvm.wisc.edu>
>Subject: Bank Switching Z-System on the HD64180
>
>Can anybody out there figure out a way to effectively bank switch the BDOS
>and BIOS portion of Z-System into bank 1 (or any other bank) of the HD64180
>so I can push the TPA size over my cramped 49K? Any hints or helps out there
>would be appreciated.
>
> --Curtis R. Anderson
> State University of New York at Buffalo
I suspect you will have to work out a jump_over arrangement, the
way PDP11 macro programmers have to avoid the I/O page. I don't have an
HD64180 but the data sheets i received from Hitachi seem to indicate that
the paging is accomplished similarly to the PDP's Page Descriptor Reg's.
A possible alternative would be to put the BDOS & BIOS in the last
page and write the page switching into the jump chain - more difficult to
impliment, but maybe easier to use over the long run. [dale]
-------
15-May-87 11:38:07-MDT,1122;000000000000
Return-Path: <bridger@rand-unix.ARPA>
Received: from rand-unix.arpa by SIMTEL20.ARPA with TCP; Fri, 15 May 87 11:37:55 MDT
Received: by rand-unix.arpa; Fri, 15 May 87 10:00:15 PDT
Message-Id: <8705151700.AA17129@rand-unix.arpa>
To: "Curtis R. Anderson" <V125KJG8%UBVMS.BITNET@wiscvm.wisc.edu>
Cc: info-cpm@simtel20.arpa
Subj: larger tpa & bank-switched OS for HD64180
Date: Fri, 15 May 87 09:59:56 PDT
From: bridger@rand-unix.ARPA
Good news and bad news:
A new OS for -180 systems is under development. It will support ZCPR33
plus some major new features, including larger tpa and bank memory management.
Meanwhile, if you are running an SB180 or SB180FX, Malcolm Kemp's
almost-released XBIOS will have most of the bios banked, disk cache,
and other features. It's a worthwhile intermediate solution.
Finally, you can increase TPA in a "full" Z-System by assembling it
without allocating space for IOP and/or RCP buffers. Many users
make little or no use of the IOP.
However, the ZRDOS (all versions) as it stands cannot be bank-switched.
It, like CP/M 2.2, uses 3.5K of tpa.
--bridger
15-May-87 13:41:58-MDT,1210;000000000000
Return-Path: <info-cpm-request@simtel20.arpa>
Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Fri, 15 May 87 13:41:46 MDT
Received: by ucbvax.Berkeley.EDU (5.57/1.25)
id AA29387; Fri, 15 May 87 12:25:18 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 9 May 87 22:04:08 GMT
From: ken@cs.rochester.edu (Ken Yap)
Organization: U of Rochester, CS Dept, Rochester, NY
Subject: Re: Copyright status of ARC, LZW, and COMPRESS programs questioned
Message-Id: <27622@rochester.ARPA>
References: <KPETERSEN.12301039127.BABYL@SIMTEL20.ARPA>
Sender: info-cpm-request@simtel20.arpa
To: info-cpm@simtel20.arpa
I thought the L-Z compression algorithm was published in a journal for
all to see. Furthermore, I may be wrong, but it is my understanding
that one cannot patent algorithms (being "laws of nature"), although
one can patent realizations of an algorithm. So if I read the journal
article and went off and wrote a C program based on the algorithm I'd
have no problems.
Disclaimer: I may be talking rubbish. Anybody know better?
Ken
15-May-87 15:28:55-MDT,754;000000000000
Return-Path: <mead%hamal.usc.edu@usc-oberon.arpa>
Received: from oberon.USC.EDU by SIMTEL20.ARPA with TCP; Fri, 15 May 87 15:28:47 MDT
Received: by oberon.USC.EDU (5.51/5.5) id AA03018;
Fri, 15 May 87 14:15:23 PDT
Received: by hamal.usc.edu (3.2/SMI-3.0DEV3)
id AA20328; Fri, 15 May 87 14:15:14 PDT
Date: Fri 15 May 87 14:15:10-PDT
From: Dick <MEAD%hamal@oberon.USC.EDU>
Subject: NOAH (what's its Stat?)
To: info-cpm@SIMTEL20.ARPA
Message-Id: <SUN-MM(195)+TOPSLIB(124) 15-May-87 14:15:10.hamal>
Desires: "gag me with a Valley girl" (ohmigod!)
Is there any word on NOAH, the CP/M-80 version of ARC (plus a bunch, I hope)??
Is there a beta-tester reading this that can comment? Is NOAH dead?
Dick <Mead@hamal.usc.edu>
-------
16-May-87 01:25:46-MDT,1428;000000000000
Return-Path: <info-cpm-request@simtel20.arpa>
Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Sat, 16 May 87 01:25:37 MDT
Received: by ucbvax.Berkeley.EDU (5.57/1.25)
id AA11663; Fri, 15 May 87 22:39:41 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 15 May 87 11:29:27 GMT
From: ptsfa!nonvon!apn@ames.arpa (root)
Organization: NONVON Systems Computer Research Group
Subject: Re: Bank Switching Z-System on the HD64180
Message-Id: <315@nonvon.UUCP>
References: <8705150402.AA10559@ucbvax.Berkeley.EDU>
Sender: info-cpm-request@simtel20.arpa
To: info-cpm@simtel20.arpa
in article <8705150402.AA10559@ucbvax.Berkeley.EDU>, V125KJG8@UBVMS.BITNET says:
>
> Can anybody out there figure out a way to effectively bank switch the BDOS
> and BIOS portion of Z-System into bank 1 (or any other bank) of the HD64180
> so I can push the TPA size over my cramped 49K? Any hints or helps out there
> would be appreciated.
>
> --Curtis R. Anderson
> State University of New York at Buffalo
>
> V125KJG8@UBVMS.BITNET
That's easy.... throw away Z-(whatever) and get CP/M 3.1 At least there you have
a 63k tpa. Disk I/O is faster.... LRU buffering is active, hashing on
hard disk directories.....
Alex P Novickis
Fulcrum Computer Products
16-May-87 03:42:12-MDT,987;000000000000
Return-Path: <info-cpm-request@simtel20.arpa>
Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Sat, 16 May 87 03:42:03 MDT
Received: by ucbvax.Berkeley.EDU (5.57/1.25)
id AA15290; Sat, 16 May 87 02:38:02 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 15 May 87 20:33:04 GMT
From: sargas.usc.edu!tli@OBERON.USC.EDU (Tony Li)
Organization: University of Southern California, Los Angeles
Subject: Looking for author of ZM.
Message-Id: <2162@sargas.usc.edu>
Sender: info-cpm-request@simtel20.arpa
To: info-cpm@simtel20.arpa
I looking for Roger Donnais (sp?), the author of the ZM z80-assembler.
Does anyone know how to get in touch with him?
;-)
--
Tony Li - USC University Computing Services "Fene mele kiki bobo"
Uucp: oberon!tli -- Joe Isuzu
Bitnet: tli@uscvaxq, tli@ramoth
Internet: tli@sargas.usc.edu
17-May-87 09:20:38-MDT,1187;000000000000
Return-Path: <@wiscvm.wisc.edu:V125KJG8@UBVMS.BITNET>
Received: from wiscvm.wisc.edu by SIMTEL20.ARPA with TCP; Sun, 17 May 87 09:20:25 MDT
Received: from UBVMS.BITNET by wiscvm.wisc.edu ; Sat, 16 May 87 13:44:17 CDT
Date: Sat, 16 May 87 12:20 EDT
From: <V125KJG8%UBVMS.BITNET@wiscvm.wisc.edu>
Subject: Re: Copyright status of ARC, LZW,
To: INFO-CPM@SIMTEL20.ARPA
X-Original-To: KEN@CS.ROCHESTER.EDU,CPM, V125KJG8
>I thought the L-Z compression algorithm was published in a journal for
>all to see. Furthermore, I may be wrong, but it is my understanding
>that one cannot patent algorithms (being "laws of nature"), although
>one can patent realizations of an algorithm. So if I read the journal
>article and went off and wrote a C program based on the algorithm I'd
>have no problems.
>
>Disclaimer: I may be talking rubbish. Anybody know better?
Considering that I have a copy of CRUNCH v 2.3 that I received as public
domain from a local bulletin board, I don't think you will have any problems.
I have also seen an UNARC algorithm coded into a VAX FORTRAN algorithm (received
from SIMTEL20). That is the best I can provide...
--Curtis
19-May-87 01:12:31-MDT,955;000000000000
Return-Path: <info-cpm-request@simtel20.arpa>
Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Tue, 19 May 87 01:12:19 MDT
Received: by ucbvax.Berkeley.EDU (5.57/1.25)
id AA28507; Mon, 18 May 87 23:53:07 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 18 May 87 16:19:41 GMT
From: tikal!slovax!flak@beaver.cs.washington.edu (Dan Flak)
Organization: R & D Associates., Tacoma, WA
Subject: Help wanted Xerox 820-II Disk Drive
Message-Id: <430@slovax.UUCP>
Sender: info-cpm-request@simtel20.arpa
To: info-cpm@simtel20.arpa
I am looking for information on hard disks for a Xerox 820-II.
What is available? Were can I get it? etc.
--
{psivax,ism780}!logico!slovax!flak : {hplsla,uw-beaver}!tikal!slovax!flak
Dan Flak-R & D Associates,3625 Perkins Lane SW,Tacoma,Wa 98466,206-581-1322
19-May-87 02:12:08-MDT,975;000000000000
Return-Path: <info-cpm-request@simtel20.arpa>
Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Tue, 19 May 87 02:11:55 MDT
Received: by ucbvax.Berkeley.EDU (5.57/1.25)
id AA28570; Mon, 18 May 87 23:55:12 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 18 May 87 16:24:18 GMT
From: tikal!slovax!flak@beaver.cs.washington.edu (Dan Flak)
Organization: R & D Associates., Tacoma, WA
Subject: Control Data 10 MB disk packs for sale
Message-Id: <431@slovax.UUCP>
Sender: info-cpm-request@simtel20.arpa
To: info-cpm@simtel20.arpa
I have approximately 35 Control Data 10 MB disk packs for sale at
$30 each (discount for the whole batch) + shipping cost.
--
{psivax,ism780}!logico!slovax!flak : {hplsla,uw-beaver}!tikal!slovax!flak
Dan Flak-R & D Associates,3625 Perkins Lane SW,Tacoma,Wa 98466,206-581-1322
19-May-87 18:21:49-MDT,1321;000000000000
Return-Path: <info-cpm-request@simtel20.arpa>
Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Tue, 19 May 87 18:21:37 MDT
Received: by ucbvax.Berkeley.EDU (5.57/1.25)
id AA16108; Tue, 19 May 87 15:34:59 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 19 May 87 16:39:10 GMT
From: geowhiz!schultz@rsch.wisc.edu (Don Schultz)
Organization: UW Madison, Geology Dept.
Subject: Uncrunching Simtel archive files
Message-Id: <552@geowhiz.UUCP>
Sender: info-cpm-request@simtel20.arpa
To: info-cpm@simtel20.arpa
Around April of this year, I requested some files from the Simtel
archives in "squeezed" form. The files I received were first crunched,
then squeezed, and finally uuencoded. After uudecoding and unsqueezing,
I tried to use the "uncrunch" program from the CP/M starter kit but the
program tells me that I require a newer program revision.
My uncrunch routine is the Z80 version for CP/M 2.2. Does anyone know
how I may obtain the correct version of the LZW expansion program ? Has
anyone else had this problem ? If it helps any, the first two bytes of
the crunched programs are 76H and FEH.
Any help would be appreciated.
19-May-87 21:49:38-MDT,927;000000000000
Return-Path: <info-cpm-request@simtel20.arpa>
Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Tue, 19 May 87 21:49:30 MDT
Received: by ucbvax.Berkeley.EDU (5.57/1.25)
id AA16728; Tue, 19 May 87 16:00:34 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 16 May 87 15:44:34 GMT
From: beta!dzzr@NYU.ARPA (Douglas J Roberts)
Organization: Los Alamos Natl Lab, Los Alamos, N.M.
Subject: Query: How best to install ZCPR3?
Message-Id: <5363@beta.UUCP>
Sender: info-cpm-request@simtel20.arpa
To: info-cpm@simtel20.arpa
I would like to install ZCPR3 on my NorthStar Horizon-II. I have
found the ZCPR3 stuff on SIMTEL20, but I would greatly
appreciate if someone who has done it before could outline
an installation proceedure.
Thanks in advance, Doug Roberts.
19-May-87 21:50:08-MDT,2374;000000000000
Return-Path: <info-cpm-request@simtel20.arpa>
Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Tue, 19 May 87 21:49:54 MDT
Received: by ucbvax.Berkeley.EDU (5.57/1.25)
id AA16843; Tue, 19 May 87 16:05:10 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 19 May 87 15:57:11 GMT
From: phoenix!pguhatha@princeton.edu (Puragra Guhathakurta)
Organization: Princeton Univ. Computing and Information Technology
Subject: Kaypro - ZCPR3 - TurboROM - BGii
Message-Id: <313@phoenix.PRINCETON.EDU>
Sender: info-cpm-request@simtel20.arpa
To: info-cpm@simtel20.arpa
Recently I installed Plu*Perfect's backgrounder on my Kaypro 4/84,
it runs with a 1Mb Advent RAM disk with Turbo ROM.
A few nasty ZCPR problems suddenly disappeared while doing this:
- the search path has a ROOT on the ramdisk (C0:), but on C1: and
up, I never was able to make ZCPR find the extended command
processor (the path was $0 A0 C0, using minimal search).
I think it was able to do so, using A0 C0, i.e. disabling the
B: drive when logged in there.
Anyone having an explanation?
- I think programs like VFILER let me log into various named directories
without password questioning, in BGii this suddenly worked.
(I did have the wheel byte set of course)
I think most of my problems arose after installing the Turbo ROM
(I used a ZCPR installation on the Advent Turbo BIOS from SIMTEL20,
it uses a un-familiar assembler for me, so no easy hacking).
A problem I haven't solved yet is DUMP (obtained through ZRDOS 1.x)
which set the computer to a halt after the file has been dumped.
This was OK before the Turbo ROM.
Apart from some of these minor problems, I am very pleased with the
RAM disk, the new ROm, and especially the Backgrounder.
Does anyone have a similar computer system, or had similar problems
and was able to solve them.
Now that ZCPR3.3 is shipping (Z-NEWS 707) some of these problems
may be over?
I heard that ZCPR3.3 supports a new kind of .COM executables, which
can run anywhere in memory. Nice for error handlerrs, history shells
and the like!
Peter Teuben
Institute for Advanced Study
School of Natural Sciences
Princeton, NJ 08540
E-mail: TEUBEN@IASSNS.BITNET
20-May-87 09:18:21-MDT,810;000000000000
Return-Path: <Dusel.Wbst@Xerox.COM>
Received: from Xerox.COM by SIMTEL20.ARPA with TCP; Wed, 20 May 87 09:17:50 MDT
Received: from Aurora.ms by ArpaGateway.ms ; 20 MAY 87 07:24:10 PDT
From: Dusel.Wbst@Xerox.COM
Date: 20 May 87 10:26:13 EDT
Subject: Re: Help wanted Xerox 820-II Disk Drive
In-reply-to: info-cpm-request@simtel20.arpa's message of 18 May 87
16:19:41 GMT, <430@slovax.UUCP>
To: info-cpm-request@simtel20.arpa
cc: info-cpm@simtel20.arpa
Message-ID: <870520-072410-1679@Xerox>
Give a call to Emerald Microware, 503-641-0347
They have drives for both 820-I and 820-II, spare parts etc.
In addition the Xerox surplus store in Texas (Open to the general public)
has 820-II rigid drive systems etc. in stock. Call them at 214-420-2999
They stock boards software systems etc.
Pete
20-May-87 10:06:09-MDT,1403;000000000000
Return-Path: <@wiscvm.wisc.edu:V125KJG8@UBVMS.BITNET>
Received: from wiscvm.wisc.edu by SIMTEL20.ARPA with TCP; Wed, 20 May 87 10:05:56 MDT
Received: from UBVMS.BITNET by wiscvm.wisc.edu ; Wed, 20 May 87 11:02:44 CDT
Date: Wed, 20 May 87 12:00 EDT
From: <V125KJG8%UBVMS.BITNET@wiscvm.wisc.edu>
Subject: On Uncrunching SIMTEL20 Files
To: INFO-CPM@SIMTEL20.ARPA
X-Original-To: edu%"geowhiz!schultz@rsch.wisc.edu",cpm, V125KJG8
> Around April of this year, I requested some files from the Simtel
>archives in "squeezed" form. The files I received were first crunched,
>then squeezed, and finally uuencoded. After uudecoding and unsqueezing,
>I tried to use the "uncrunch" program from the CP/M starter kit but the
>program tells me that I require a newer program revision.
> My uncrunch routine is the Z80 version for CP/M 2.2. Does anyone know
>how I may obtain the correct version of the LZW expansion program ? Has
>anyone else had this problem ? If it helps any, the first two bytes of
>the crunched programs are 76H and FEH.
Is the UNCR.COM in use Uncrunch v 2.3 by Steve Greenburg? If not, I can send
you a copy. It might be possible that SIMTEL20 is not crunching correctly.
I'm running short on time, or else I'd attach a copy of CRUNCH23.LBR in Intel
hex form for you to MLOAD or LOAD...
(don't have UUENCODE running on this VAX yet!)
--Curtis
20-May-87 11:53:24-MDT,2398;000000000000
Return-Path: <bridger@rand-unix.ARPA>
Received: from rand-unix.arpa by SIMTEL20.ARPA with TCP; Wed, 20 May 87 11:53:10 MDT
Received: by rand-unix.arpa; Wed, 20 May 87 10:32:41 PDT
Date: Wed, 20 May 87 10:32:41 PDT
From: Bridger Mitchell <bridger@rand-unix.ARPA>
Message-Id: <8705201732.AA09258@rand-unix.arpa>
To: phoenix!pguhatha@princeton.edu (Puragra Guhathakurta)
Cc: info-cpm@simtel20.arpa, sage@ll.arpa
Re: Kaypro - ZCPR3 - TurboROM - BGii
In reply to your: 19 May 87 15:57:11 GMT
Date: Wed, 20 May 87 10:32:35 PDT
From: bridger@rand-unix.arpa
Peter Teuben--
Some of your command-processor-related problems may be due to using
tools (such as VFILER) that are designed to be run under ZCPR3 on a
system with an earlier command processor (the original ZCPR). At
least some of the Z-System tools assume (without checking) that they
are running in such an environment. When run on a standard cp/m 2.2
system, for example, some features will not function correctly.
The TurboROM (by Plu*Perfect Systems & Advent) for Kaypros ('83, '84, 10)
is shipped with the original ZCPR ("ZCPR1"), the public-domain
replacement for Digital Research's CCP developed by several veterans
of this info-cpm list.
The copyright for ZCPR3 is assigned to Echelon Inc. and copies
can be obtained from them or one of the Z-NODE BBS's. If you
have a copy of it, or another command processor, you can replace
ZCPR1 in your TurboROM system, as outlined in the manual.
BackGrounder ii (a copyrighted product from Plu*Perfect Systems)
incorporates a command processor that supports ZCPR3.3 functionality.
So, when you began using BGii, the tools such as VFILER were able to
operate as expected.
The new ZCPR3.3 has been developed by Jay Sage, with numerous
contributions from Z-System users. It will be available from Echelon
and Z-NODES. One new feature is a "type-2 environment" COM file that
is loaded to and executed at an environment-specified address
(e.g. 8000 hex). This permits extended command processors, error
handlers and other Z-system shells to leave the lower TPA unchanged
from the previous program. The "GO" command will therefore work for
all but very large programs, even after a shell has been re-invoked.
BGii (v 1.13) supports this and other ZCPR3.3 features. I expect
Jay will soon post further info about the 3.3 version.
--bridger
20-May-87 21:24:10-MDT,577;000000000000
Return-Path: <mknox@ngp.utexas.edu>
Received: from ngp.utexas.edu by SIMTEL20.ARPA with TCP; Wed, 20 May 87 21:23:56 MDT
Date: Wed, 20 May 87 22:10:48 CDT
From: mknox@ngp.utexas.edu (Margaret H. Knox)
Posted-Date: Wed, 20 May 87 22:10:48 CDT
Message-Id: <8705210310.AA14141@ngp.utexas.edu>
Received: by ngp.utexas.edu (5.51/5.51)
id AA14141; Wed, 20 May 87 22:10:48 CDT
To: info-cpm@simtel20.arpa,
pyramid!amdahl!cerebus!fai!wjvax!jeffs@decwrl.dec.com
Subject: Re: CP/M for Model IV
Go with the Montezuma version. They did a VERY good job on this one.
21-May-87 10:51:59-MDT,479;000000000000
Mail-From: RCONN created at 21-May-87 10:51:48
Date: Thu, 21 May 87 10:51:46 MDT
From: Rick Conn <RCONN@SIMTEL20.ARPA>
Subject: Re: Query: How best to install ZCPR3?
To: beta!dzzr@NYU.ARPA
cc: info-cpm@SIMTEL20.ARPA
In-Reply-To: <5363@beta.UUCP>
Message-ID: <12304174972.16.RCONN@SIMTEL20.ARPA>
There is a ZCPR3 Installation Handbook in PD:<ZSYS.DOC> (I think .DOC) on
SIMTEL20. There is also the book "ZCPR3: The Manual", which is quite detailed.
Rick
-------
22-May-87 01:31:38-MDT,716;000000000000
Return-Path: <@wiscvm.wisc.edu:V125KJG8@UBVMS.BITNET>
Received: from wiscvm.wisc.edu by SIMTEL20.ARPA with TCP; Fri, 22 May 87 01:31:14 MDT
Received: from UBVMS.BITNET by wiscvm.wisc.edu ; Thu, 21 May 87 22:39:44 CDT
Date: Thu, 21 May 87 23:19 EDT
From: <V125KJG8%UBVMS.BITNET@wiscvm.wisc.edu>
Subject: Z-Team Membership Count
To: INFO-CPM@SIMTEL20.ARPA
X-Original-To: bridger,cpm, V125KJG8
Besides you and Jay Sage, how many others in the Z-Team are on Internet/UUCP
(Z-News 705)?
I'd love to get into the Z-Team, but the policy at my university and of BITNET
will prevent me from that kind of commercial activity. I can test PD stuff,
and offer suggestions, though...
--Curtis
23-May-87 11:43:49-MDT,1063;000000000000
Return-Path: <info-cpm-request@simtel20.arpa>
Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Sat, 23 May 87 11:43:41 MDT
Received: by ucbvax.Berkeley.EDU (5.57/1.25)
id AA12881; Sat, 23 May 87 08:38:30 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 22 May 87 16:02:00 GMT
From: uxc.cso.uiuc.edu!uicsl!klieb@a.cs.uiuc.edu
Subject: Re: Help wanted Xerox 820-II Disk Drive
Message-Id: <363900003@uicsl>
References: <430@slovax.UUCP>
Sender: info-cpm-request@simtel20.arpa
To: info-cpm@simtel20.arpa
This month's issue of computer shopper has an ad from BCE in Washington,
DC that lists an 820-II WITH HARD DISK for $299!!! Includes everything:
Wordstar, 10MB hard disk, 8" DSDD floppy, keyboard, display, etc. Look for
the ads that have the full-page red borders near the back. Apparently, BCE
bought out Xerox's remaining stock. Have fun!
Kurt Liebezeit
...!ihnp4!uiucuxc!uicsl!klieb
24-May-87 11:57:09-MDT,11627;000000000000
Return-Path: <w8sdz@BRL.ARPA>
Received: from BRL-SMOKE.ARPA by SIMTEL20.ARPA with TCP; Sun, 24 May 87 11:56:37 MDT
Date: Sun, 24 May 87 13:19:40 EDT
From: "Keith B. Petersen" (WSMR|towson) <w8sdz@BRL.ARPA>
To: Info-Cpm@SIMTEL20.arpa
Subject: FOG standards defined
Message-ID: <8705241319.aa25078@SMOKE.BRL.ARPA>
From F.O.G., the First Osborne Group, we receive the following set of
standards. There are some inaccuracies in this file and my next
message will be a response to them.
Keith Petersen
Arpa: W8SDZ@SIMTEL20.ARPA
Uucp: {bellcore,decwrl,harvard,lll-crg,ucbvax,uw-beaver}!simtel20.arpa!w8sdz
GEnie Mail: W8SDZ
RCP/M Royal Oak: 313-759-6569 - 300, 1200, 2400 (V.22bis) or 9600 (USR HST)
--cut-here--STANDARD.FOG--cut-here--
Report from FOG
Solution for a Major Problem
by Gale Rhoades
In recent weeks, the FOG office staff has been trying to sort through a
variety of submissions. Some have been uploaded to FOG #6 (or #1) and
some have arrived on disk. The problems we've encountered surpass my
ability to describe.
We have files which have been sQueezed, crunched, ARChived or LiBRaried
and we have files which apparently have gone through a combination of
compression programs.
We have filenames with characters which are reserved under MS-DOS and
filenames with characters which are reserved under CP/M. (Reserved
characters are those which the operating system will not permit you to
use when naming a file.) We have CP/M files on MS-DOS formatted disks
and MS-DOS files on CP/M formatted disks. And we have the most horren-
dous assortment of combinations. How some of it was accomplished is
totally beyond me!
Enough is enough. Jack and I are spending hours trying to get at some
of these files and we just do not have the time to continue doing this.
Well, at least not if you want to continue to see the FOG publications,
new library releases and all the other services which are provided by
the FOG staff.
We have therefore developed some guidelines for submitting material to
the FOG libraries and publications. Exceptions will be considered but
please check with us in advance. We are willing to listen to suggestions
for modifications to these guidelines but only if they are presented in
an organized and well-considered manner. As a secondary goal, I would
hope that FOG can facilitate the standardization of filenames and com-
pression programs.
Additionally, these guidelines are subject to revision as the authors of
industry-standard utilities develop the tools which will eliminate some
of the specific problems outlined below.
The Guidelines
It would be very foolish to perpetuate the argument that CP/M and MS-DOS
are separate and distinct. Far too many users find themselves switching
between MS-DOS and CP/M machines. Some have one machine at work and the
other at home. Others have both sitting side-by-side.
Legal Filenames: Filenames may contain only the characters listed below:
! (exclamation mark)
# (pound, number, or hash symbol)
% (percent)
& (ampersand)
' (apostrophe)
( (open or left parenthesis)
) (close or right parenthesis)
- (hyphen, dash, or minus)
@ (at symbol)
0 through 9
A through Z (upper case only!)
^ (caret or circumflex)
` (back quote)
{ (open or left brace or curly bracket)
} (close or right brace or curly bracket)
~ (tilde)
It is true that both MS-DOS and CP/M permit filenames to include char-
acters other than those listed above. This list includes only those
haracters which we have found to be generally acceptable to both opera-
ting systems. Note that a few of these characters are partially reserved
through common usage.
For example, "Q" as the second letter of a file extension indicates that
the file has been sQueezed. NEVER use it otherwise. "Z" as the second
letter of a file extension indicates that the file has been crunched.
Again, NEVER use it unless the file has indeed been crunched.
The characters are listed in ascending ASCII order. The first nine often
are used to place files at the head of a sorted directory because they
have ASCII values less than that of a "0" or an "A".
Utility Programs: These are the programs which compress files (to con-
serve disk space) or which collect several files under a single filename.
1. SQueezed files (those with a "Q" as the second letter of a file ex-
tension) must be compatible with Dave Rand's NewSWeeP (version 2.07
in CP/M or 1.018 in MS-DOS, both of which use Richard Greenlaw's SQ
algorithm). I have yet to see a correctly named file which will not
unsQueeze with NSWP. SQueezed files generally save approximately
30-35%.
Text files which are of use to both CP/M and MS-DOS users should only be
sQueezed.
2. LiBRaried files (those with the extension .LBR) are a collection of
several related files. Often libraries include files which have been
sQueezed. This combination is both acceptable and desirable as a
savings of 10-50% is realized.
Additionally, there are fully debugged utilities which will allow one-
step viewing and extraction from .LBR files and these files are equally
usable on either MS-DOS or CP/M systems. Generally these files are
created on CP/M systems.
3. ARChived files (those with the extension of either .ARC or .ARK) are
files which contain related files. ARC is particularly nice because
it is possible, in a single step, to both condense and collect. Cur-
rently ARC files are created reliably only on MS-DOS systems but the
contents can be extracted with ease on either a CP/M or MS-DOS system.
The established standard is to use .ARC as the extension when the file
contains programs and related files specific to MS-DOS systems. Most
MS-DOS shareware and public domain software is distributed (on the Remote
Systems) in .ARC files. Files w ith the extension .ARK are specific to
CP/M systems. ARC512 is the standard which FOG is supporting.
Things to Avoid: These are the things which have caused major problems,
especially lately.
1. ALL crunch programs. These programs are changing dramatically nearly
every week. In most cases, files which were crunched by a later ver-
sion cannot be extracted by an earlier version.
Files which contain a "Z" as the second character in the extension will
be discarded until (unless) the various authors can agree on some stan-
dards and build RELIABLE and easy-to-use programs which allow a CP/M
user to extract a file crunched on an MS-DOS system, an MS-DOS user to
extract a file crunched on a CP/M system AND both CP/M and MS-DOS users
to create compatible crunched files.
2. Please DO NOT mix compression algorithms except to sQueeze a file and
then include it in a LiBRary file.
3. ARC files created by programs not compatible with ARC512 will be dis-
carded.
4. Files which were named using illegal characters (those not listed un-
der Legal Filenames above) will be discarded.
5. Never sQueeze or crunch a .LBR or .ARC file!
6. Never sQueeze or crunch a file which will later be included in an ARC
file.
7. NEVER rename a file before submitting it to this office! You may re-
name any file or program for your own use but please do not distribute
it to others except under the filename assigned by the author. This is
particularly important with public domain software.
8. Please do not sQueeze, LiBRary, or ARChive a file and then rename the
file. If you want to rename a file you created, please do so before
using your favorite utility. Renamed files cause serious problems
when we are extracting several files on the same disk.
Submissions
It is amazing how many submissions (both for the libraries and the
publications) arrive with nothing to identify the sender, the disk
format, the intent of the sender, etc.
Each disk submitted should have a label to tell us:
1. The name and address (and membership number) of the sender.
2. The format of the disk.
3. If text files are included, what word processor was used. If it is
possible, we would prefer that the files be submitted in WordStar or
standard ASCII format.
4. If it is not a submission, please include a cover letter so we know
WHY it was sent.
5. If it is a submission, what would you like back? Volunteers do most
of the copying to overwrite the disks before they are returned to the
senders. Normally the volunteers are not able to look up your address
and we do not have records of the library disks you already have or
the disk formats you can read.
6. If possible, include a file with the CRC values so that we can check
for damage to the files if we encounter problems.
7. Keep the filename unique. Please do not use FOGHORN, FOGLIGHT, FOG,
LETTER, or similar filenames.
Files uploaded to FOG #6 or #1 should:
1. Include sender's name, address, and membership number. If you are
uploading a textfile, place this information at the beginning of the
file. If you are uploading a library submission, include this infor-
mation in a "README" file.
2. If more than a single file is being uploaded, please collect all re-
lated files in either a LiBRary or ARChive file. Be sure the "README"
file is included. SQueeze text files before adding them to a LiBRary
file; do NOT sQueeze them before using ARChive.
3. If possible, include a file with the CRC values of each member.
4. Keep the filename unique. Please do not use FOGHORN, FOGLIGHT, FOG,
LETTER, or similar filenames.
Submissions for the FOG Publications
Lately, we have been receiving a large number of lengthy letters and
articles by mail. This is great except for one small problem - these
letters are not in computer-readable form.
Therefore, we wonder if authors realized that, in order to publish the
submission, we have to first retype these otherwise excellent submis-
sions? We have reluctantly begun returning such letters with the request
that they be returned on disk.
Remember folks, we will return your disk overwritten with a disk from the
library -- just tell us which disk you'd like to have.
Effective immediately, we will be unable to rekey a submission which is
longer than two paragraphs.
If you have artwork which accompanies the submission, please continue
sending that as hardcopy. Just insert it into the disk mailer.
Please include your name and address at the start of each article. It
is much faster to delete a couple extra lines than to search for the
information.
Please omit (or delete) ALL print control codes, regardless of what you
think we can read or use. We are experimenting with a variety of "desk-
top publishing" software packages and print control codes can make a file
nearly useless. If you want to assist us, include a hardcopy of the
formatted file. Please avoid indents, tabs, and other offsets. Keep all
the margin flush left and use blank lines for separation. Start and end
non-printing comments with a tilde ( ~ ).
Submissions are always needed for the FOG publications and, of course,
greatly appreciated. To all the authors and others responsible for such
submissions, our sincerest thanks for your efforts and support.
- Gale Rhoades
--cut-here--
24-May-87 11:57:36-MDT,11646;000000000000
Return-Path: <w8sdz@BRL.ARPA>
Received: from BRL-SMOKE.ARPA by SIMTEL20.ARPA with TCP; Sun, 24 May 87 11:57:10 MDT
Date: Sun, 24 May 87 13:35:13 EDT
From: "Keith B. Petersen" (WSMR|towson) <w8sdz@BRL.ARPA>
To: Info-Cpm@SIMTEL20.arpa
Subject: FOG standards - CRUNCH author replies
Message-ID: <8705241335.aa25218@SMOKE.BRL.ARPA>
F.O.G., the First Osborne Group, recently released a file called
STANDARDS.FOG which detailed certain requirements for submitting
files to FOG. In the file below, the author of CRUNCH responds
to inaccuracies in the FOG document. I fully agree with the
rebuttle enclosed below. Many of the files available from my
RCP/M and SIMTEL20 are crunched. There have been no problems
and the savings in storage and download time are quite impressive.
Keith Petersen
Arpa: W8SDZ@SIMTEL20.ARPA
Uucp: {bellcore,decwrl,harvard,lll-crg,ucbvax,uw-beaver}!simtel20.arpa!w8sdz
GEnie: W8SDZ
RCP/M Royal Oak: 313-759-6569 - 300, 1200, 2400 (V.22bis), 9600 (USR HST)
--cut-here--RESPONSE.FOG--cut-here--
RESPONSE.FOG
Steven Greenberg, 10 May 1987
This is in response to a file being circulated, STANDARD.FOG, issued
by Gale Rhoades and the FOG office staff. While I understand the need
for the document and the intent of it, I feel that certain sections
disseminate information which is misdirected, misleading, or just
plain technically incorrect. If you are not familiar with the docu-
ment, it is a series of guidelines which must be used if one is to
consider making a submissions to FOG [Ref. #2].
Since the inception of CRUNCH, I have witnessed a wide variety of
reactions, from very positive to quite negative. Reasons for "opposi-
tion" to CRUNCH have ranged from plain closed-mindedness to some very
real questions the of "standards" and intersystem compatibility.
Standards are very important, and they don't change overnight. Each
system or person has a right to decide what is or isn't "standard",
and, based on that, form appropriate guidelines. CRUNCH has gone from
a relatively unknown compression format to quite a popular one. While
it is now arguably a standard of some kind, the final decision on that
question is of course left to the user.
I don't really care if FOG condones or condemns CRUNCH. It was writ-
ten for my own interest and for the many others who find it useful
(though I did make $15 on it- an unsolicited contribution from
England!). I am not in the habit of getting involved in these contro-
versies, such as the recent PRACSA discussions concerning the "sanc-
tioning" of crunched files (see Ref #1 below). I am responding now,
however, specifically to this FOG document, because it makes several
points which I find offensively inaccurate.
Quote from STANDARD.FOG:
| "Things to Avoid: These are the things which have caused major
| problems, especially lately."
|
| "1. ALL crunch programs. These programs are changing dramatically
| nearly every week. In most cases, files which were crunched by a
| later version cannot be extracted by an earlier version."
There have only been two crunched file formats in all of history,
namely "1" and "2". If there still are any type "1" files floating
around, they would be uncrunched by any v2 program with absolutely no
problem. The standard current version of CRUNCH, (v2.3), was released
with full source code in November of '86. The statements above not-
withstanding, there have been no additional releases (or known bugs)
in the twenty-five or so weeks since, nor has v2 format changed since
it was first introduced some 36 weeks ago. There have been quite a
number of support releases from other authors (see partial listing be-
low), and all work with the same v2 format originally introduced in
early September, 1986.
1
STANDARD.FOG continues:
| "Files which contain a "Z" as the second character in the exten-
| sion will be discarded until (unless) the various authors can
| agree on some standards and build RELIABLE and easy-to-use prog-
| rams which allow a CP/M user to extract a file crunched on an MS-
| DOS system, an MS-DOS user to extract a file crunched on a CP/M
| system AND both CP/M and MS-DOS users to create compatible
| crunched files."
Discarded indeed! (watch your .AZM files!)
Ironically, I feel it appropriate to congratulate the various authors
of CRUNCH / UNCR type programs, as well as various TYPE and other
utilities which support the crunched file format. Each of these pro-
grammers have conscientiously followed the existing format. We have
thus evolved a system where all these programs ARE in fact compatible-
I have no explanation for the statements made in the above paragraph
concerning "agree[ment]" and "RELIABILITY" (emphasis theirs.. why?).
Using UNCR or equiv., CP/M users CAN extract files made on any system
which could create them. MS-DOS users CAN reliably extract crunched
files created on CP/M systems (see Ref #1 below). Of course CP/M
users CAN create them, in a multitude of ways. At this moment, MS/DOS
users cannot CREATE a crunched file, but then again neither can CP/M
users create an ARC file right now. These inabilities are temporary
and of secondary importance; the paramount issue is that everyone be
able to reliably access the information contained in compressed files.
Consider the following list, which contains as many programs as I
could think of offhand which directly deal with the crunched file
format. ALL ARE COMPATIBLE.
Program OS Function Author(s) Notes
======= ==== ======== ========== =====
CRUNCH23 CP/M Crunch, Uncr, Docs Steven Greenberg w/ Z-80 source
FCRNCH11 CP/M CR, UCR, many xtras Charles Falconer w/ 8080 source
TYPELZ2x CP/M TYPE facility Steve G./Others Frm LBR's, etc.
LTxx CP/M TYPE & extras Charles Falconer Can extract to dsk
TYPEQZxx CP/M TYPE w/ wildcards John Hastwell-Batton Recognizes ASCII
TXxx CP/M another TYPER Harris Landsberg Strange language
UNCR231 ['C'] UNCR only, portable Frank Prindle Compilations below
UNCR232 MS/DOS Compiled ver of abv Prindle/ Hansen See Ref. #1
UNCR-DOS MS/DOS Compiled ver of abv Prindle/ Greenberg Similar to above
JETFIND CP/M 2 Advanced string srch Bridger Mitchell $Commercial Prgm
TRSCRNCH TRS For New TRSDOS 80 Jon Saxton / Others From Australia
UNCRNCHR MAC New, runs on MACS Prindle/Beard New for MAC
CR23D CP/M Datestamper support Bridger Mitchell In Beta Test
Additional related programs are now being worked on in Canada,
England, and elsewhere.
===============================================================================
2
Another excerpt from STANDARD.FOG:
| "I have yet to see a correctly named file which will not unsQueeze
| with NSWP."
Well I, for one, have a number of them. On 23 Feb. '85, Paul J.
Homchick wrote a proposed standard explaining how and why files
squeezed by some MS-DOS programs were incompatible, along with his
proposed solution. Here is an excerpt from P. Homchick's SQDATE.DOC,
referring to MS-DOS squeezers with names SQ2 and ZSQ:
"Although SQ2 added time and date stamping, it did so at the ex-
pense of downwards compatibility. A file squeezed with the time
and date mode of SQ2 could ONLY be unsqueezed with the companion
unsqueezer USQ2 (or ZUSQ). Thus the advantage of standardization
was lost. No file squeezed with SQ2 could be unsqueezed with the
older standard programs or moved to CP/M or UNIX systems. Clear-
ly, SQ2 created a number of unfortunate consequences along with
its time and date stamping."
----------------------------------------------------------------------
An aside, not related to file compression: The list of "approved
filename characters" includes four characters specifically NOT allowed
by DRI for CP/M 3.0, namely "(", ")", "-" and "!". The exclamation
mark, in particular, is an odd inclusion insofar as it is virtually
impossible to create or work with a filename containing that character
in CP/M 3.
======================================================================
APPENDIX: "Ref #1"
Here is "Ref #1" mentioned several times above. These are messages
left on the PRACSA board, sort of a culmination of a previously on-
going debate. I include them here for general reference and especial-
ly for the author(s) of STANDARD.FOG.
-----
Area: MS-DOS
Msg # 179 04/10/87 11:08 PDT
Subj: UNCRunching via MS-DOS
From: Irv Hoff
To: All
The following list is the result of an extensive test that John Allen
did with his MS-DOS computer using the uncrunch program UNCR232.EXE.
All the xxxx.?Z? files were downloaded from a CP/M-80 RCPM system.
John says they all uncrunched fine, without loss of any information.
MS-DOS owners can user the UNCR232.EXE program without hesitation for
files crunched on CP/M-80 equipment using CRUNCH.
3
BEFORE:
------
-BYE5KMD NZW 7-13-86 NZW 415BBS TZT BBS-USA TZT
BGIIFACT TZT FIFTH TZT TRAGEDY TZT ULTRA TZT
USR9600 TZT AJCBR LZT AJVAC LZT NOVBEST LZT
OCTBEST LZT PDFT0487 LZT RCPM0387 LZT ZNODES40 LZT
ZNODES41 LZT CREDIT DZC OZBYE510 DZC SNOOPY87 CZL
VICTORY FZC WRITE IZ EXCHANGE PZP UP2DATE PZP
AFTER:
-----
-BYE5KMD NEW 7-13-86 NEW 415BBS TXT BBS-USA TXT
BGIIFACT TXT FIFTH TXT TRAGEDY TXT ULTRA INF
USR9600 TXT AJCBR LST AJVAC LST NOVBEST LST
OCTBEST LST PDFT0487 LST RCPM0387 LST ZNODES40 LST
ZNODES41 LST CREDIT DOC OZBYE510 DOC SNOOPY87 CAL
VICTORY FCC WRITE IN EXCHANGE PCP UP2DATE PCP
These files came from B0: of the PRACSA RCPM and were uncrunched using
UNCR232.EXE on a MS-DOS computer by John Allen of the PRACSA standards
committee. All parts of the files were normal and in the proper
place. These files ranged from rather short to pretty long. They
were more than adequate to establish the fact that UNCR232.EXE is
doing its job correctly.
UNCR232.EXE should be in the library of any MS-DOS user that frequents
RCPM systems that might have crunched files with xxxx.?Z? extents. It
is available on G0: of the PRACSA RCPM.
-----
Area: PRACSA
Msg # 219 04/13/87 22:39 PDT
Subj: crunch
From: Al Mehr
To: All
I capitulate. The "uncruncher" for DOS seems 100%. As I don't support
MAC or APPLE stuff on my board, do not know what they will do, but I
now agree, CRUNCH is certainly an acceptable alternative. I withdraw
all my objections for using crunch files on the PRACSA BBS.
Al Mehr SERVU
----------------------------------------------------------------------
Ref #2: The actual document, STANDARD.FOG, a file uploaded by Gale
Rhoades, is available on the PRACSA RCP/M as "STANDARD.FZG".
----------------------------------------------------------------------
4
--cut-here--
25-May-87 13:44:26-MDT,1655;000000000000
Return-Path: <info-cpm-request@simtel20.arpa>
Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Mon, 25 May 87 13:44:12 MDT
Received: by ucbvax.Berkeley.EDU (5.57/1.25)
id AA11072; Mon, 25 May 87 12:38:16 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 25 May 87 16:23:41 GMT
From: amdahl!dlb!dana!rap@ames.arpa (Rob Peck)
Organization: Dana Computer, Inc., Sunnyvale, CA
Subject: Re: Help wanted Xerox 820-II Disk Drive
Message-Id: <171@dana.UUCP>
References: <430@slovax.UUCP>, <363900003@uicsl>
Sender: info-cpm-request@simtel20.arpa
To: info-cpm@simtel20.arpa
In article <363900003@uicsl>, klieb@uicsl.UUCP writes:
>
> This month's issue of computer shopper has an ad from BCE in Washington,
> DC that lists an 820-II WITH HARD DISK for $299!!! Includes everything:
> Wordstar, 10MB hard disk, 8" DSDD floppy, keyboard, display, etc. Look for
> the ads that have the full-page red borders near the back. Apparently, BCE
> bought out Xerox's remaining stock. Have fun!
>
> Kurt Liebezeit
> ...!ihnp4!uiucuxc!uicsl!klieb
What the ad says is $299 for the 820-II (with software).
It also goes on to say that the enclosure with the 8-inch disk and
10 Meg hard disk is AVAILABLE (almost, but not quite specifies $CALL).
BUT $CALL is what ya gotta do! (I haven't done so yet, but if it was
$299 for the whole ball o wax, I'm sure that by the time I called
they'da been outa stock.) Good Luck - if I missed a bargain,
C'est La Vie.
Rob Peck hplabs!dana!rap
26-May-87 08:22:39-MDT,1721;000000000000
Return-Path: <@wiscvm.wisc.edu:U448020@HNYKUN11.BITNET>
Received: from wiscvm.wisc.edu by SIMTEL20.ARPA with TCP; Tue, 26 May 87 08:21:57 MDT
Received: from HNYKUN11.BITNET by wiscvm.wisc.edu ; Tue, 26 May 87 09:19:32 CDT
Date: Tue, 26 May 87 16:17:21 MET
To: INFO-CPM@SIMTEL20.ARPA
From: U448020%HNYKUN11.BITNET@wiscvm.wisc.edu
Subject: GSX-80 device drivers
Does anyone know of the existence of GSX-80 device drivers??????
I own a -self build- CP/M 3.0 computer, built after the CT-80 design of the
German magazine C'T (COMPUTER TECHNIK). The computer is used in combination
with a graphic terminal emulating Tektronics 4010 with a resolution of
768*560 pixels. The terminal is built after the GRIP design from the same
magazine.
As I have experienced it is quite a hard job to develop a complete GSX
device-driver. Until now I haven't got any further than drawing simple
solid lines with my self-written driver.
So my questions are:
- Are sources available of any 'SKELETAL GIOS' (as they are named by
Digital Research) for GSX-80 screen drivers, preferably for
vector-devices like the Tektronics 4010. I have found out that on
SIMTEL20 something alike is available for GSX-86.
or even better:
- are there any 'ready to use' device-drivers available for
Tektronics-type devices (possibly with source, for adapting some
of the differences with the real Tektronics)
Until now the only information i have found are the files concerning
GSX-86 on SIMTEL20 and disassembly of drivers from Amstrad/Schneider
computers.
Who can give me some help ??????
Waling Tiersma
U448020 @ HNYKUN11 on BITNET
26-May-87 10:39:31-MDT,878;000000000000
Return-Path: <@wiscvm.wisc.edu:U448020@HNYKUN11.BITNET>
Received: from wiscvm.wisc.edu by SIMTEL20.ARPA with TCP; Tue, 26 May 87 10:39:23 MDT
Received: from HNYKUN11.BITNET by wiscvm.wisc.edu ; Tue, 26 May 87 10:34:49 CDT
Date: Tue, 26 May 87 16:59:13 MET
To: INFO-CPM@SIMTEL20.ARPA
From: U448020%HNYKUN11.BITNET@wiscvm.wisc.edu
Subject: GSX-80 metafile driver
Date: 26 May 1987, 16:54:11 MET
From: Waling Tiersma 080-561368 / 080-516 U448020 at HNYKUN11
To: INFO-CPM at SIMTEL20
In addition of questions I have asked earlier this day about availability
of GSX-80 device-drivers.
- Does any GSX-metafile driver exist for GSX-80 ?????
(this could enable us to exchange graphic data with Atari-ST users
and ms-dos GEM user and maybe others)
Waling Tiersma
U448020 at HNYKUN11 on BITNET
-0-0-0-0-0-0-0-0-0-0-
26-May-87 18:11:34-MDT,1156;000000000000
Return-Path: <info-cpm-request@simtel20.arpa>
Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Tue, 26 May 87 18:11:17 MDT
Received: by ucbvax.Berkeley.EDU (5.57/1.25)
id AA04117; Tue, 26 May 87 16:41:56 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 26 May 87 20:15:13 GMT
From: phoenix!pguhatha@princeton.edu (Puragra Guhathakurta)
Organization: Princeton Univ. Computing and Information Technology
Subject: NULU - bug
Message-Id: <340@phoenix.PRINCETON.EDU>
Sender: info-cpm-request@simtel20.arpa
To: info-cpm@simtel20.arpa
I found out (the hard way) that the unsqueeze option in NULU
(V1.52 or 1.51) does not work for large files. On my system
allocation blocks are 2k, and for files larger than 32k
(more than 1 extent) it seems that the Q options doesn't
do its job properly.
Did you fellow NULU users know this?
Is there a new version out, or is there an alternative?
Peter Teuben
Institute for Advanced Study,
Princeton, NJ 08540
e-mail also: TEUBEN@IASSNS.BITNET
27-May-87 09:56:42-MDT,799;000000000000
Return-Path: <@wiscvm.wisc.edu:UZR50D@DBNRHRZ1.BITNET>
Received: from wiscvm.wisc.edu by SIMTEL20.ARPA with TCP; Wed, 27 May 87 09:56:22 MDT
Received: from DBNRHRZ1.BITNET by wiscvm.wisc.edu ; Wed, 27 May 87 10:53:30 CDT
Date: Wed, 27 May 87 17:53:01 MEZ
To: INFO-CPM@SIMTEL20.ARPA
From: UZR50D%DBNRHRZ1.BITNET@wiscvm.wisc.edu
Subject: Faster uudecode ?
Hi,
All those peoples who get files from the SIMTEL20 - Archive know,
that one must very often use the uudecode utility, to get the right
format of the files. But this program is very slow (because it is
written in Pascal). Is there anybody who has a faster version of
UUDECODE and / or UUENCODE for a CP/M - machine ???
The most efficient language might be Z80 - Assembler for this purpose.
Thanks in advance Ralf Schukey
27-May-87 13:45:18-MDT,1566;000000000000
Return-Path: <info-cpm-request@simtel20.arpa>
Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Wed, 27 May 87 13:44:50 MDT
Received: by ucbvax.Berkeley.EDU (5.57/1.25)
id AA23672; Wed, 27 May 87 12:39:11 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 27 May 87 16:53:51 GMT
From: beta!dzzr@nyu.arpa (Douglas J Roberts)
Organization: Los Alamos Natl Lab, Los Alamos, N.M.
Subject: Fix to a bug in Lifeboat CP/M 2.2 printer driver
Message-Id: <5644@beta.UUCP>
Sender: info-cpm-request@simtel20.arpa
To: info-cpm@simtel20.arpa
Since I've been pestering this group recently for help, I thought
that I'd share the solution now that I've found it.
The parallel port driver was sending garbage to my printer, so
after I located the problem I modified the Horizon user area and patched
it in. For those of you interested, here is the offending code and the
fix.
COUT2:
;Parallel port output.
IN 6 ;Motherboard status
ANI 1
JZ COUT2
MVI A,20H ;Reset PO flag
OUT 6 ;Output char
MOV A,C ;Load accumulator
TIN1:
ORI 80H ;Set strove false <-- REMOVE THIS LINE!!!
OUT 0 ;and send character
XRI 80H ;Toggle strobe
OUT 0 ;Output
XRI 80H ;and toggle again
OUT 0
ANI 7FH ;Mask to ASCII
RET
The indicated line was setting the high bit on each character,
effectively putting my Epson MX-80 into graphics mode.
Thanks again for all the help!
--Doug
27-May-87 14:29:55-MDT,758;000000000000
Return-Path: <@wiscvm.wisc.edu:YSEGUIN@UNCAEDU.BITNET>
Received: from wiscvm.wisc.edu by SIMTEL20.ARPA with TCP; Wed, 27 May 87 14:29:13 MDT
Received: from UNCAEDU.BITNET by wiscvm.wisc.edu ; Wed, 27 May 87 14:13:51 CDT
Date: Wed, 27 May 87 13:07 MDT
From: <YSEGUIN%UNCAEDU.BITNET@wiscvm.wisc.edu>
Subject: looking for help!
To: info-cpm@simtel20.arpa
X-Original-To: info-cpm@simtel20.arpa, YSEGUIN
I am a new user of this list and would
like to see if anyone could help me whit the
following problem.
I am using an hp-125 micro compytercomputer with voice since I am
visually handicapped. I am loo looking for a copy of kermit that would run
on the hp-125.
Can anyone help!
Thank in advance.
Yves Seguin
YSEGUIN@UNCAEDU
27-May-87 22:43:50-MDT,1056;000000000000
Return-Path: <info-cpm-request@simtel20.arpa>
Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Wed, 27 May 87 22:43:19 MDT
Received: by ucbvax.Berkeley.EDU (5.57/1.25)
id AA05941; Wed, 27 May 87 21:18:17 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 28 May 87 03:32:56 GMT
From: beta!dzzr@nyu.arpa (Douglas J Roberts)
Organization: Los Alamos Natl Lab, Los Alamos, N.M.
Subject: MDM700 - Can't toggle printer?
Message-Id: <5678@beta.UUCP>
Sender: info-cpm-request@simtel20.arpa
To: info-cpm@simtel20.arpa
OK, all you Modem700 users, any ideas why I can't toggle my printer "on"
while in terminal mode? I'm running Lifeboat Associates CP/M 2.2 on a
Northstar Horizon with the printer on the parallel port.
The printer works fine under CP/M, but CTL-P in MDM-700's terminal mode
has no effect.
Suggestions/ideas will greatly appreciated.
--Doug Roberts
dzzr@lanl.gov
30-May-87 00:16:47-MDT,1509;000000000000
Return-Path: <@SRI-NIC.ARPA:info-cpm-request@simtel20.arpa>
Received: from SRI-NIC.ARPA by SIMTEL20.ARPA with TCP; Sat, 30 May 87 00:16:11 MDT
Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Fri 29 May 87 18:54:28-PDT
Received: by ucbvax.Berkeley.EDU (5.57/1.25)
id AA05665; Fri, 29 May 87 18:36:52 PDT
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 29 May 87 18:31:40 GMT
From: amdahl!dlb!dana!rap@ames.arpa (Rob Peck)
Organization: Dana Computer, Inc., Sunnyvale, CA
Subject: Re: Faster uudecode ?
Message-Id: <175@dana.UUCP>
References: <8705271556.AA19256@ucbvax.Berkeley.EDU>
Sender: info-cpm-request@simtel20.arpa
To: info-cpm@simtel20.arpa
In article <8705271556.AA19256@ucbvax.Berkeley.EDU>, UZR50D@DBNRHRZ1.BITNET writes:
> ..... Is there anybody who has a faster version of
> UUDECODE and / or UUENCODE for a CP/M - machine ???
> Thanks in advance Ralf Schukey
On April 9, a version of uue* was posted in comp.sources.amiga.
Written in C, it might well be adaptable, and perhaps faster
than the pascal you now have.
The message ID was <3848@j.cc.purdue.edu>
The sender was "doc@j.cc.purdue.edu (Craig Norborg)"
The org. was: Purdue University Computing Center
(just in case you can't access an older message)
I'd have emailed direct, but my mailer doesnt seem to
understand BITNET addresses.
Rob Peck.
31-May-87 12:01:10-MDT,1357;000000000000
Mail-From: KPETERSEN created at 31-May-87 12:01:00
Date: Sun, 31 May 1987 12:00 MDT
Message-ID: <KPETERSEN.12306809005.BABYL@SIMTEL20.ARPA>
Sender: KPETERSEN@SIMTEL20.ARPA
From: Keith Petersen <W8SDZ@SIMTEL20.ARPA>
To: Info-Cpm@SIMTEL20.ARPA
Subject: ZCPR 3.3 now available from SIMTEL20
The long-awaited ZCPR version 3.3 is now available from SIMTEL20.
Here is the current CRC list for that directory. Get ZCPR33.FOR for
descriptions of some of the files.
Filename Type Bytes CRC
Directory PD:<CPM.ZCPR33>
PCPITRAP.RZP.1 BINARY 1280 E1E1H
SAVE04.LBR.1 BINARY 11008 1527H
SHOW11-C.LBR.1 BINARY 44800 13ADH
SLTRAP.LBR.1 BINARY 6784 51A4H
SUB33-A.LBR.1 BINARY 15488 AF35H
XSUBZ.LBR.1 BINARY 9600 6696H
Z33ERR07.LBR.1 BINARY 14464 5A39H
Z33LIB02.LBR.1 BINARY 6656 3260H
Z33UPD.DZC.1 BINARY 7936 60CAH
Z33UTIL.LBR.1 BINARY 27136 A19BH
ZCPR33.FOR.1 ASCII 2353 F15CH
ZCPR33.LBR.1 BINARY 78976 E7E6H <--this is it!
These files are also available on my RCP/M (now offers 9600 bps USR
HST mode and MNP error correction) and on GEnie's CP/M RoundTable.
--Keith Petersen
Arpa: W8SDZ@SIMTEL20.ARPA
Uucp: {bellcore,decwrl,harvard,lll-crg,ucbvax,uw-beaver}!simtel20.arpa!w8sdz
GEnie: W8SDZ
RCP/M Royal Oak: 313-759-6569 - 300, 1200, 2400 (V.22bis) or 9600 (USR HST)
31-May-87 17:34:15-MDT,650;000000000000
Return-Path: <CENT.MBECK%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU>
Received: from OZ.AI.MIT.EDU (MC.LCS.MIT.EDU.#Internet) by SIMTEL20.ARPA with TCP; Sun, 31 May 87 17:34:08 MDT
Date: Sun 31 May 87 19:31:51-EDT
From: "Mark Becker" <Cent.Mbeck%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
Subject: Bug in C/80 V 3.1 printf()
To: Info-CPM@SIMTEL20.ARPA
Message-ID: <12306869243.42.CENT.MBECK@OZ.AI.MIT.EDU>
Hello -
I just found that:
#include "printf.h"
main()
{
printf("%%%d%%", 10);
}
prints "%10" and not "%10%" .
Before I start figuring out whats happening from the source code,
has anyone already corrected this?
Regards,
Mark
-------