[4503] (19 lines) Network_Server 01/10/85  1215.8 mst Thu cpm
Subject:  ZCPR-like File Search
Date:  Thursday, 10 January 1985 08:55 mst
From:  STANLEY at USC-ECLB
To:  info-cpm at AMSAA
cc:  stanley at USC-ECLB

I am running ZCPR (version 1) on a Heath H89.  I seem to remember
reading or seeing recently a scheme whereby the file search was
extended to include files of the *.OVR and *.MSG type, so that if
you were to be logged onto Drive C: and issued the command SC
(with SC being on A:), the SC program would know where to find
its overlays.  As it is, of course, ZCPR finds SC which then
errors out because it cannot find its overlay files.  Can anyone
help me locate the "fix" I think I saw?

Please reply directly to me (stanley at eclb), and I will
summarize for the net.  Thanks in advance.

                                ...Dick Stanley

---[4503]---


[4508] (81 lines) Network_Server 01/11/85  0253.4 mst Fri cpm
Subject:  iLISP (SCHEME dialect) interpreter for CP/M
Date:  Tuesday, 8 January 1985 10:33 mst
From:  Ken Dickey <kend%dadlaa.uucp at BRL-TGR>
To:  info-cpm at AMSAA
Newsgroups:  net.micro.cpm,net.lang.lisp
Xref:  godot net.micro.cpm:1618 net.lang.lisp:121

iLISP is a lexically scoped lisp based on the SCHEME dialect
of Lisp which runs on Z80 CP/M 2.X

I have been going through some of the exercises from Abelson &
Sussmans' STRUCTURE AND INTERPRETATION OF COMPUTER PROGRAMS (MIT
Press '85)--which is an excellent book--and having a lot of fun
doing so.  For $55, this is a really fun system for playing with
objects, packages, constraint systems, etc.  There are some
differences in this dialect and that described in Struct &
Interp, but I have yet to come across something I couldn't do
in a clean and obvious way.

Synopsis:
  Just like the big boys: read and run time macros, optimized
tail recursion (does not burn stack space; no [ugly] PROG or GO
needed), error handling and toploop fully user controlled, init
(startup) file, assembler interface, CATCH, floating point math,
CP/M access, assembler interface, list editor, TRACEing, BREAK,
user control of error handling, ramdom access function library
system (most convenient!), pretty printing functions, readable
reference manual (165 pg, + 60 pg intro for non-lispers), terminal
configuration options, full control of string and cons space
allocation, etc, etc.  Aside from this it is jus' plain fun to
use (this is NOT a paid ad, really)!.   Warning: the intro for
beginners is much too formal.  The Struct & Interp is a much
better introduction for new lispers, who may need some hand-
holding in any case.  Unfortunately, no vectors or compilation.

general prims:
+ - * / ABS ADD1 ARCTAN COSINE FIX FLOAT MINUS REM SINE SUB1 SQRT
APPEND CAR CARS CDR CDRS CONS COPY DREVERSE LAST LENGTH LIST
MEMB MEMBER NCONC NTH REPLACA REPLACD REPLACAD TCONC GETPL GETPROP
LISTGET LISTPUT LISTREM PUTPROP REMPROP SETPL ALPHAORDER NCHARS
PACK SET UNPACK UNSET ATOM EQ EQUAL LISTP LITATOM MACROP NULL
NUMNBERP PROPP VALUEP ZEROP = >= <= > <

i/o and special prims:
CLEARBUF DIRIO FILLBUF INB INPUT PEEKC READ READP READC READLINE
SYNTAB SYNTAX CS CURSOR LINELENGTH MARGIN OUTB OUTPUT POSITION
PRIN1 PRIN2 PRINTLEVEL PRINT OUTB SPACES TAB CLOSE DISK DSKRES
FILEDIR GFD IOBYTE OPEN OPENP SFP ARGCNT ASCII BYTE CHAR ERR
EVAL DEFEXP DESCRIBE EXIT FREE FULL LOAD MEMORY PROG1 RECLAIM
RESET MAP TERPRI TYPE UNSETF

also has a number of macros and special forms (MAP functions,
PROGN, DEFINE, SETQ, SELECTQ, COND, LET, LETSYS, etc) and a
bunch of utility functions (string handling, statistics, Eliza,
etc).  There is more, but I'm tired of typing and you get the idea.

As functions are full-fledged data objects, they can be assigned
to, allowing you to do things like generalize "+" to lists, eg:
(SETQ OLD-ADD +)    ; expects 2 args
(DEFINE + ARGS (MAP ID ARGS OLD-ADD 0))
(UNSET 'OLD-ADD)
will now allow (+ 4 3 6) =>13 instead of an error (2 args expected)
and (+ ) =>0.

Oh, yes:
COMPUTING INSIGHTS
PO BOX 4033
Madison, Wisconsin 53711
($49.95 + $5 ship)

Lithp ith lithening!
-Ken Dickey
---------------------------------------------------
UUCP:           HOST!tektronix!dadla!kend
   Where HOST is any one of:
          masscomp,decvax,allegra,uf-cgrl,mit-eddie,mit-ems,
          uoregon,psu-cs,orstcs,zehntel,ucbcad,ucbvax,purdue,
          uw-beaver,reed, ogcvax,ihnp4,tekred,minn-ua,cbosg

CSnet: kend%dadla@tektronix
ARPAnet: kend%dadla%t BJgame

[4513] (21 lines) Network_Server 01/11/85  1057.2 mst Fri cpm
Subject:  Re: ZCPR Start?
Date:  Friday, 11 January 1985 07:25 mst
From:  Rick Conn <RCONN at SIMTEL20>
To:  jshaver at APG-3
cc:  info-cpm at AMSAA, RCONN at SIMTEL20

There are several info sources on ZCPR3:

          Z3USER.SI -- a user's perspective of the concepts of the system
          Z3INS*.SI -- installation manual
          Z3NEWS.*  -- newsletters about questions, changes, etc
          magazines -- articles have appeared in Computer Language,
                                        Dr Dobbs, User's Guide, and others, and
                                        an article is due to come out in Byte in
                                        the next few months

The first three references are files stored in the MICRO:<CPM.ZCPR3>
directory on SIMTEL20.  Finally, a book on ZCPR3 is due to come out later
this month or next month.

                    Rick
-------
---[4513]---

[4521] (24 lines) Network_Server 01/12/85  0259.6 mst Sat cpm
Subject:  TURBO Pascal
Date:  Friday, 11 January 1985 12:16 mst
From:  bang!crash!bwebster at NOSC
To:  bang!info-cpm at AMSAA
cc:  bang!lee.sailer at CMU-CS-C
Mmdf-Warning:  Parse error in preceeding line at AMSAA.ARPA

>  As long as discussion has turned to Pascal, someone tell me this:
>         How does the *&$#%@ thing work ?!?!?!?
>  Is it true the P Kahn is from the 14th dimension?

When I first saw a TURBO Pascal ad (about a year ago), I figured it had to
be some sort of scam or at least gross deception.  I phoned and asked for a
review copy (I was writing a Pascal column for IBM Softalk at the time),
ready to rip it to shreds when it arrived.  Instead, I wrote such a glowing
(if slightly incredulous) review that Borland quotes me in their ads.  I've
asked Philippe Kahn about it on a number of occasions, and he just tells me
that it's a "simple recursive-descent compiler" and "I'm surprised that
nobody else has come out with one."  I still think it's magic.
                                                            ..bruce..
                                                  Bruce Webster, Contr. Ed., BYTE
                                                  bang!crash!bwebster@nosc
                                                  {ihnp4 | sdcsvax!bang}!crash!bwebster


---[4521]---

[4522] (11 lines) Network_Server 01/12/85  1502.4 mst Sat cpm
Subject:  Re: mex comm. utility (cpm)
Date:  Saturday, 12 January 1985 11:57 mst
From:  NBaheti.es at XEROX
To:  Blackwell <mdb%aicchi.uucp at BRL-TGR>
cc:  info-cpm at AMSAA

Try setting the filter off (STAT FILTER OFF) when you load Mex.
With it on all control characters except lf,cr,bs will be blocked
out.

Arun Baheti <NBaheti.es@Xerox>
"Life is hard; then you die."
---[4522]---

[4524] (20 lines) Network_Server 01/13/85  0305.4 mst Sun cpm
Subject:  Re: Prometheus ProModem 1200
Date:  Friday, 11 January 1985 08:28 mst
From:  Chuck McManis <cem%intelca.uucp at BRL-TGR>
To:  info-cpm at AMSAA
Newsgroups:  net.micro.cpm

>I have had a ProModem for about a year, and have noticed that some of
>the things that are mentioned in the manual are not true. For
>instance, if the line is busy the manual says that the modem should
>detect the busy signal, hang up and try again. This does not happen.
 As the manual mentions, this requires that the switch on the bottom
 be set to enable this activity and that it will retry every 30 seconds.
 I have found both of these statements to be true. I have a modem
 program (MEX) that will do redial so I disable this "feature"

--Chuck
--

[4525] (13 lines) Network_Server 01/13/85  0305.4 mst Sun cpm
Subject:  Re: Unix for CP/M 2.1 or > on a z80
Date:  Sunday, 13 January 1985 00:00 mst
From:  Sam Hahn <Samuel at SU-SCORE>
To:  mikec%reed.uucp at BRL-TGR
cc:  info-cpm at AMSAA

New Generation Systems.  Reston Virginia. 703-471-5598
Or try ConIX, from Computer Helper Industries, inc.  212-652-1786

I run cp/m-3.0 and -816 OS's, so I haven't gotten either of these.
There are others, but these two come easily to mind.

                                        -- sam hahn [samuel@score]
-------
---[4525]---

[4528] (37 lines) Network_Server 01/13/85  0305.4 mst Sun cpm
Subject:  POW2 public domain formatter
Date:  Saturday, 12 January 1985 17:15 mst
From:  Tim Maroney <tim at CMU-CS-K>
To:  info-cpm at AMSAA
Newsgroups:  net.micro.cpm

I recently snarfed the POW2 text formatter from SIMTEL20.  It works fairly
well overall, but it has a few deficiencies.  Among these are the lack of
various fonts support (you can overstrike a whole line, and underline
centered text -- whoopee), the treatment of centering as a special command
rather than as a justification mode, the lack of variable-space total
justification for printers that support it, the lack of a file inclusion
command, the lack of three-part titles, and blank lines not causing a
paragraph break.

I have fixed one of these by adding font support.  The command FT,number
switches to the font given by the number, in a table of font handling
routine addresses.  The font handling routines output a single character in
the routine's font, and they are printer specific (non-portable).  However,
so far I have only added this for left justification, the only mode I use;
any font changes will result in bad font-character associations in right or
total justify mode, and will have no effect in unformatted text (which I'm
not really sure is a very bad thing).  I would not want to release such a
program, but I am also not heavily motivated to fix it in a way I will never
use.  So does anyone else want to add this?  If you are serious about it,
and have a weekend to spare, let me know and I'll send you a copy.

Perhaps a number of us could work together on adding the other useful
features I mentioned as well.  POW has the potential to be a very powerful
tool; it seems no one has ever gotten around to making it one.
-=-
Tim Maroney, Carnegie-Mellon University Computation Center
ARPA:     Tim.Maroney@CMU-CS-K          uucp:     seismo!cmu-cs-k!tim
CompuServe:         74176,1360          audio:    shout "Hey, Tim!"

"Remember all ye that existence is pure joy; that all the sorrows are
but as shadows; they pass & are done; but there is that which remains."
Liber AL, II:9.
---[4528]---

[4529] (31 lines) Network_Server 01/13/85  0305.4 mst Sun cpm
Subject:  Screen Editor
Date:  Saturday, 12 January 1985 21:05 mst
From:  Tim Maroney <tim at CMU-CS-K>
To:  info-cpm at AMSAA
Newsgroups:  net.micro.cpm

Some weeks ago, I snarfed the public domain screen editor from SIMTEL20.  It
was nicely done, but a three-mode editor was totally unacceptable to my
emacs-configured fingers.  I've hacked away at it heavily, adding many
features and completely replacing the user interface with an emacs-like one
(although it is not emacs-like otherwise -- no multiple windows, no
extension language, no marking yet).

The major extension that still needs to be done is extending it to arbitrary
file sizes.  I have worked out a scheme for doing this, but I was wondering
whether anyone else has already done it, with the new buffer module being in
the public domain.  If so, it would sure save a lot of time.

If not, then I have a question for you CP/M wizards.  Is there any portable
way to make a file shrink?  That is, to free sectors from the end of it that
were formerly in use?  If so, how?  I have not examined the CP/M file system
heavily, although I have hacked other parts of BIOS, so if there is a way it
shouldn't be over my head.  I need this because I don't want my temporary
files to be stuck at their maximum length.
-=-
Tim Maroney, Carnegie-Mellon University Computation Center
ARPA:     Tim.Maroney@CMU-CS-K          uucp:     seismo!cmu-cs-k!tim
CompuServe:         74176,1360          audio:    shout "Hey, Tim!"

"Remember all ye that existence is pure joy; that all the sorrows are
but as shadows; they pass & are done; but there is that which remains."
Liber AL, II:9.
---[4529]---

[4531] (13 lines) Network_Server 01/13/85  0305.4 mst Sun cpm
Subject:  Re: TURBO Pascal
Date:  Friday, 11 January 1985 15:03 mst
From:  Jim Gillogly <jim%randvax.uucp at BRL-TGR>
To:  info-cpm at AMSAA
Newsgroups:  net.micro.cpm

----------
After discovering how wonderful Turbo Pascal is (IBM PC), I called Borland
and asked about Turbo C.  The girl on the order desk said that they had
been told that it's being worked on and they expect it this coming summer.
--
          Jim Gillogly
          {decvax, vortex}!randvax!jim
          jim@rand-unix.arpa
---[4531]---

[4532] (14 lines) Network_Server 01/13/85  1107.4 mst Sun cpm
Subject:  EMACS and the Osborne
Date:  Sunday, 13 January 1985 10:40 mst
From:  Lee.Sailer at CMU-CS-C
To:  info-cpm at AMSAA

Some time ago I elicited help with getting EMACS to work on an Osborne
over 1200 Baud lines (which I did), and to work in a usable way (which I
did not).

I promised to report back; this is it.  I never got it where I could stand
it.  To much screen repainting was the main problem, plus some cases
where EMACS and my screen got too confused about who was where.

If you figure it out, let me know.
-------
---[4532]---

[4533] (33 lines) Network_Server 01/13/85  1508.5 mst Sun cpm
Subject:  Turbo
Date:  Sunday, 13 January 1985 10:36 mst
From:  Lee.Sailer at CMU-CS-C
To:  info-cpm at AMSAA

So far, except for Kahn's assurance that it is really simple, it seems that
nobody is willing to admit that they know how it works.  Here is a new, simpler
question:

          1.  Is anybody out there trying to figure out how Turbo "does it"?

          2.  Is anybody debating what it could do better, so that version x
              will be even spiffier?

Here are a few of my own (somehat trivial) wishes.
  - A stand-alone version of the editor/run-time system.  TRUE FACT.  I use
    Turbo as my editor when writing in C.  ("Why?" is a lng story.)

 - A utility that will strip out totally unused parts of .COM files.
   if, for example, Turbo loads all the trig functions into every .COM
   file, could a utility dtect that they were never used, and squeeze them
   out?

 - Turbo's random number generator is not so hot.  In particular, it cannot
   be started from a particular seed.  Patches?

 - Could Turbo be patched to add a "true" complex type, and thereby save us
   all from those letters in BYTE that say "Real men use FORTRAN!"

Of Course!  First, someone (not me, sorry, I don't even know assembler) will
have to figure out how Turbo is possible, period.

thanks for listening
-------
---[4533]---

[4534] (40 lines) Network_Server 01/13/85  1909.5 mst Sun cpm
Subject:  CP/M Standards
Date:  Sunday, 13 January 1985 10:57 mst
From:  Lee.Sailer at CMU-CS-C
To:  info-cpm at AMSAA

Lastbutnotleast, I wish to send up a trial balloon, and see if anybody salutes
it...

People seem to keep asking, or even just claiming, that CP/M is dead.
I think it is dead the way FORTRAN died about 15 years ago, that is, it now
lives in so many forms, and is "evolving" so much that it will probably never
disappear.  Notice that after years and years of fooling around, the FORTRAN
folk finally got up a "standard", first 66, then 77, and now so-called 8x.

Is anyone doing this for CP/M???

I know of at least ZCPRn, TURBO-DOS, RCPM, the UNIX-like "addons", and a lot
of different little utiliies for time-stamping, making USER 0 files public,
incremental backup, and so on.

Let's call DR's plain version "level 0".  For me, User numbers are nearly
useless in level 0.  How would it be best to fix that, and could we
standardize it, make PIP, ED, STAT, etc. understand it, and call it
level 1?  Could we standardize on a subset of the good features in EX, SUPERSUB,
etc, and add those to level 1?

and so on.

In short, CP/M has a lot of good features, and some bad ones.
 People add enhancements   ***** SNAFU courtesy of Datapac *****
 DATA LOST TOWARD TERMINAL  5
...

[4545] (13 lines) Network_Server 01/14/85  0311.5 mst Mon cpm
Subject:  Unix for CP/M 2.1 or > on a z80
Sender:  KPETERSEN at SIMTEL20
Date:  Monday, 14 January 1985 01:29 mst
From:  Keith Petersen <W8SDZ at SIMTEL20>
To:  Info-Cpm at AMSAA

Michael Cooper <mikec%reed.uucp@BRL-TGR.ARPA> asks for a program that
will give Unix-like features for CP/M 2.1 or > on a z80.

ZCPR3 will give you many of the features of Unix.  It's a CCP
replacement for CP/M 2.2.  It's available from many RCPMs around the
country and from SIG/M.

--Keith
---[4545]---

[4546] (59 lines) Network_Server 01/14/85  0712.6 mst Mon cpm
Subject:  Re: .REL Format
Date:  Monday, 31 December 1984 15:39 mst
From:  mpackard%uok.uucp at BRL-TGR
To:  info-cpm at AMSAA
Newsgroups:  net.micro.cpm

[]

This is the format for .REL files:

These files are bit-streams rather than byte-streams.

----------------------------------------------------------------------
| 1 | XX | XXXX | XX XXXXXXXXXXXXXXXX | XXX+CHARACTERS OF SYMBOL NAME|
----------------------------------------------------------------------
  ^   ^     ^            ^                        ^
  |   |     |            |                        |
Always 1    |            |                        |
      |     |          A Field                  B Field
      |     |                             Chars are 8 Bit ASCII
     00 - special link (see below)
     01 - program relative
     10 - data relative
     11 - common relative
            |
            |
Control Field:

The following special link items have a B field only

 0 - Entry Symbol (name for search)
 1 - Select COMMON block
 2 - Program name
 3 - Request library search
 4 - Reserved

The following special link items have both an A field and B field

 5 - Define COMMON size
 6 - Chain  external (A is head of address chain,  B is name  of
     external
 7 - Define entry point (A is address B is name)
 8 - External offset. Used for JMP and CALL to externals

The following special link items have an A field only

 9 - External  + offset.  The A value will be added to  the  two
     bytes  starting at the current location counter  immediately
     before execution.
10 - Define the size of the Data area. (A is the size)
11 - Set the loading location counter to A
12 - Chain address.  A is the head of chain,  replace all entries
     in  chain with current location counter.  The last entry  in
     the chain has an address field of absolute zero.
13 - Define program size
14 - End of program (forces to byte boundary)

The following special link item has neither an A nor a B field

15 - End File
---[4546]---

[4547] (17 lines) Network_Server 01/14/85  0712.6 mst Mon cpm
Subject:  XMDM-102.ASM Bug?
Date:  Monday, 31 December 1984 15:20 mst
From:  mpackard%uok.uucp at BRL-TGR
To:  info-cpm at AMSAA
Newsgroups:  net.micro.cpm

[]

I've been writing on an xmodem protocal in 'C' (to make it more
portable for me) and have been using XMDM-102.ASM as the referance.
I've looked at other 'C' programs already written but most of them
make an error in the protocal or are as obese as the assembler code.
That is they send a 16 bit record number, rather than the proper 8 bits.
I suspect that they were never tested.  Also while looking at the code
I noticed a bug in the WRBLOCK routine at WRERR.
It says MVI C,CAN, and should say MVI A,CAN.  I don't know if anyone in
this group keeps track of reports, but thought I might pass it on.
uok!mpackard
---[4547]---

[4548] (75 lines) Network_Server 01/14/85  0712.6 mst Mon cpm
Subject:  Info on Z800 microprocessor
Sender:  KPETERSEN at SIMTEL20
Date:  Monday, 14 January 1985 05:20 mst
From:  Keith Petersen <W8SDZ at SIMTEL20>
To:  Info-Micro at BRL-VGR, Info-Cpm at AMSAA

Z800.DOC relayed from the RCPM circuit...
--cut here--

Zilog Z800 microprocessor chip quick description.

Hello folks out there in techie land,

I just got in a new Zilog catalog and found the technical specs
for  the Z800 chip.  I thought some out there might be interested
in a quick review of what seems to be a very nice chip.  Here  we
go...

The  Z800 family will be offered in 4 packages,  their  abilities
are:

1. address 512K bytes of memory on an eight bit data bus,
2. address 512K bytes of memory on a sixteen bit data bus,
3. address 16M  bytes of memory on an eight bit data bus,
4. address 16M  bytes of memory on a sixteen bit data bus.

Packages one and two are 40 pin, and 3 and 4 are 64 pin.

The chip is Z80 object code compatible

There is a 256 byte on chip memory that is configurable to cache
or normal RAM.

The Z800 also has 4 DMA channels, 4 counter/timers, a dynamic RAM
refresh generator,  a clock osc., a memory management unit, and a
UART directly on the chip. (only the 64 pin version can access all
features).

The  chip will support what Zilog calls Nibble mode addressing of
chips, for faster accessing of RAM (I think Intel calls it Ripple
mode, I could be wrong).

The bus interface could be handy for those of us who want to  use
the  Z800 at the targeted 10MHz of the first chips Zilog will put
out, (25 Mhz later) even if we can only afford chips that can run
at  four  or  five  MHz.  There is a timing control register that
tells  the  CPU  that  Bus operations will be clocked at the same
speed  as  the  CPU,  or  1/2 of the speed,  or 1/4 of the speed.
There are also high and low  memory  wait state insertion bits if
memory of mixed speeds is to be used.

There is an on chip single step mode.

There are 9 addressing modes:
1. Register,
2. Immediate,
3. Register Indirect,
4. Direct Address,
5. Index,
6. Short Index,
7. Relative,
8. Stack Pointer Relative,    *
9. Base Index                 *
  * indicates new to Z800 (from Z80)

Looks to me like a super chip... can't wait 'till someone comes out with
an add on board for my Kaypro 10 (hint's to those out there who are
capable...)

Delivery according to the latest Echelon ZCPR3 Newsletter will start in
April 1985. Wait and salivate...


                                                  Dave Olsen
                                                    1-8-85

---[4548]---

[4549] (8 lines) Network_Server 01/14/85  0712.6 mst Mon cpm
Subject:  Re: Turbo Pascal: Did I hear right?
Date:  Monday, 14 January 1985 06:19 mst
From:  Lowans.Henr at XEROX
To:  Phil Lapsley <phil%ucbeast at UCB-VAX>
cc:  info-cpm at AMSAA

Yes you heard right, I have Turbo for my NEC APC which runs CP/M-86 (8086).
                                                                                                    Paul

---[4549]---

[4550] (22 lines) Network_Server 01/14/85  1114.6 mst Mon cpm
Subject:  DbaseII errors
Date:  Monday, 14 January 1985 09:39 mst
From:  Jack H. Smith <jhsmith at CRDC>
To:  info-cpm at AMSAA

          Hello fellow hackers;


          Is anyone out there familiar enough with dbaseII to explain the
          "TOO MANY FILES OPEN" error message.... I've written a few menu-
          driven packages, and they all work well, except for the inter-
          mittent error of too many files being open...
          I'm aware of the fact that if the USE command is issued without an
          argument, all open files should be closed, but even this tactic
          doesn't seem to work.
          Is anyone aware of a different approach to this problem, or has
          anyone found a way around it?
          Please send your responses to me at CRDC, and I'll forward the
          solution to the net, if there is one.

          Thanks,
          JACK H. SMITH

---[4550]---

[4551] (9 lines) Network_Server 01/14/85  1514.9 mst Mon cpm
Subject:  Re: Turbo Pascal: Did I hear right?
Date:  Monday, 14 January 1985 11:07 mst
From:  MMoon.es at XEROX
To:  Phil Lapsley <phil%ucbeast at UCB-VAX>
cc:  info-cpm at AMSAA

Defintely available for CP/M-86; I got mine just after Xmas & had it up
& running in half an hour (reading the manuals).
                    MMoon.es@xerox.arpa

---[4551]---

[4556] (23 lines) Network_Server 01/15/85  0718.4 mst Tue cpm
Subject:  Re: Turbo Pascal: Did I hear right?
Date:  Tuesday, 15 January 1985 06:43 mst
From:  Kushall.henr at XEROX
To:  Phil Lapsley <phil%ucbeast at UCB-VAX>
cc:  info-cpm at AMSAA

YES YES YES!

Turbo Pascal is available for the following 4 operating systems:

CP/M 80 {8080,Z80}
CP/86     {8088/8086}
MS DOS  {8088-8086}
PS DOS   {8088/8086}

I'am using the CP/M-86 version on a DEC Rainbow 100
Limits under CPM/86
Source file block limit := 64K bytes if >64K use {$I file}
Code segment limit := 64K if>64 K required use overlays or chaining
Data segment limit := 64K
Heap stack limit determined by avail mem, no apparant limit
The compiler editor requires 33K of RAM

Ed
---[4556]---

[4557] (11 lines) Network_Server 01/15/85  1128.5 mst Tue cpm
Subject:  Re: DbaseII errors
Date:  Tuesday, 15 January 1985 08:33 mst
From:  pencin.dlos at XEROX
To:  Jack H. Smith <jhsmith at CRDC>
cc:  info-cpm at AMSAA

Check your code to determine if you are properly 'RETURNING' from your
sub-menu or command modules.Dbase keeps a STACK of 'DO's that must be
popped by issuing a return. If this stack overflows you will get the TOO
MANY FILES OPEN error. Make sure you always return to your MAIN MENU via
a RETURN and not a direct call to that menu.

---[4557]---

[4558] (9 lines) Network_Server 01/15/85  1128.5 mst Tue cpm
Subject:  SQ/USQ algorithm description wanted
Date:  Tuesday, 15 January 1985 08:15 mst
From:  Walt Lamia <LAMIA at DEC-MARLBORO>

I need an English-like description of the algorithms used in SQ and
USQ.  I know that they are derived from Knuth, but I was hoping
someone who had actually done a code implementation had written
something down.

%Walt
---[4558]---

[4560] (16 lines) Network_Server 01/15/85  1529.2 mst Tue cpm
Subject:  XREF250.LBR
Date:  Tuesday, 15 January 1985 12:23 mst
From:  B.Eiben LCG Ext 617-467-4431 <EIBEN at DEC-MARLBORO>

XREF250.LBR a "blessed" XREF.  It now marks symbol-definitions (a'la
the "real" XREF's) - and allows to get a XREF ONLY - since most
editors allow to "see" line-numbers.  I rearranged the code - took the
comments from the M80 source - and dropped it - it was neither
remarkably faster nor does everybody have M80 (otherwise he has CREF80
too).  Changes documented in source.

It is now available from Simtel20 as:

Filename                      Type       Bytes     CRC

Directory MICRO:<CPM.ASMUTL>
XREF250.LBR.1                           COM        34304  563FH
---[4560]---

[4561] (13 lines) Network_Server 01/15/85  1529.2 mst Tue cpm
Subject:  Perfect Writer
Date:  Tuesday, 15 January 1985 13:44 mst
From:  Pawka <PAWKA at NOSC-TECR>
Reply-To:  PAWKA at NOSC-TECR
To:  INFO-CPM at AMSAA

          I have a problem with perfect writer that I thought someone out
there in CPMland might be able to help me with. It works fine for small
files, but when I try to edit one that is 180KB, it seems to go into a
loop swapping. I tried increasing the size of the swap file to 248K and
making the delay count for swapping the max (2000), no help! Any ideas?
                                                  Mike
                                                  PAWKA@NOSC-TECR.ARPA
------
---[4561]---

[4562] (17 lines) Network_Server 01/15/85  1929.6 mst Tue cpm
Subject:  MACASM QUESTION ON THE Z80 LIB
Date:  Tuesday, 15 January 1985 16:30 mst
From:  ABN.COSCOM-CE at USC-ISID
To:  INFO-CPM at AMSAA
cc:  ABN.COSCOM-CE at USC-ISID

I have a copy of the modem overlay for use with the ATR8000 microcomputer.
          One of the lines in the asm code is MACLIB Z80.  When I run
          MACASM there is an error wihch says that I do not have Z80.LIB.
          Can someone tell me where I get Z80.LIB?  Is there some way I
          can assemble this system on TOPS 20 and not have to assemble on
          the micro?  Should I be using something other than MACASM?


Kevin Rappold
1LT(P) GS
1st COSCOM
<abn.coscom-ce>@usc-isid.arpa
---[4562]---

[4563] (10 lines) Network_Server 01/15/85  1929.6 mst Tue cpm
Subject:  Perfect Writer
Date:  Tuesday, 15 January 1985 17:48 mst
From:  Herb Lin <LIN at MIT-MC>
To:  PAWKA at NOSC-TECR, info-cpm at AMSAA
cc:  LIN at MIT-MC

I think your "swapping loop" is just a question of waiting long enough
on initial entry to the file.  I thought I had that problem too,
because I lost patience.  I routinely edit files of 240 KB now, with a
swap file of 256KB.

---[4563]---

[4564] (9 lines) Network_Server 01/15/85  1929.6 mst Tue cpm
Subject:  Re: Perfect Writer
Date:  Tuesday, 15 January 1985 18:05 mst
From:  Jim Forrest <JFORREST at SIMTEL20>
To:  PAWKA at NOSC-TECR
cc:  INFO-CPM at AMSAA, JFORREST at SIMTEL20

I have a 252k swap file with perfect writer and it works perfectly. I had
to use a swap building program to make it work, though.
Jim
-------
---[4564]---

Re:

    I have a copy of the modem overlay for use with the ATR8000
    microcomputer.  One of the lines in the asm code is MACLIB Z80.
    When I run MACASM there is an error wihch says that I do not have
    Z80.LIB.  Can someone tell me where I get Z80.LIB?  Is there some
    way I an assemble this system on TOPS 20 and not have to assemble
    on the micro?  Should I be using something other than MACASM?

You should be using the Digital Research MAC assembler (MAC.COM).
Z80.LIB is available from SIMTEL20 as:

Filename                Type     Bytes   CRC

Directory MICRO:<CPM.MACLIB>
Z80-V3.LIB.1            ASCII    13070  B7EEH   <---this is it
Z80EXT.LIB.1            ASCII     2825  3AD0H   <---this one is
                                                for the Z80
                                                undocumented op codes


Rename Z80-V3.LIB to Z80.LIB before using.  It must be on the default
drive unless you give MAC.COM a directive to look for it elsewhere.

--Keith
---[4565]---

[4566] (8 lines) Network_Server 01/15/85  2330.5 mst Tue cpm
Subject:  re: UNIX for cpm
Date:  Tuesday, 15 January 1985 19:58 mst
From:  Chan at HI-MULTICS
To:  mikec%reed.uucp at BRL-TGR
cc:  info-cpm at AMSAA

Try the Carousel Tool Kit by Carousel Tool Kit Inc., 609 kearnet Street,
El Cerrito, CA 94530 (415) 528-1300.  BYTE has an article about 1 or 1
and 1/2 yrs ago.
---[4566]---

[4567] (24 lines) Network_Server 01/16/85  0331.3 mst Wed cpm
Subject:  Need program to read/write MS-DOS format in Pascal
Date:  Tuesday, 15 January 1985 10:14 mst
From:  David Roth <pur-ee!isrnix!pugsly%decvax.uucp at BRL-BMD>

Does anyone know of a public domain program to help read/write MS-DOS
format (written in Pascal of course), on non-IBM-PC type machines?  We
have a need to do this on just about any kind of micro with a 5 1/4
disk drive.  Apples, Osborne, Kaypro,etc...  The reason for Pascal is
that at least that much or it would be portable and the low level
stuff could be done just for that machine.  (Sort of like xmodem7 is
patched.)  Thanks in advance.

Oh, I have run across a program on a local R-CP/M system here called
RDMSDOS.C which claims to work on CP/M systems..  But I am in the
process of contacting the author before excepting it as Public Domain.
I will let you know if it is or not.

                                        David Roth
          ...decvax!pur-ee!isrnix!pugsly
                                        Indianapolis,IN
                              US Mail:
                                        COMMANDER USA Soldier Support Center
                                        ATSG-DTU-S
                                        Attn: Mr. David Roth
                                        Ft. Harrison,IN 46216-5590
---[4567]---

[4568] (84 lines) Network_Server 01/16/85  0331.4 mst Wed cpm
Subject:  LU310 - new version of CP/M (LBR) library program
Sender:  KPETERSEN at SIMTEL20
Date:  Tuesday, 15 January 1985 23:39 mst
From:  Keith Petersen <W8SDZ at SIMTEL20>
To:  Info-Cpm at AMSAA

LU310 is now available from SIMTEL20:

Filename                      Type       Bytes     CRC

Directory MICRO:<CPM.CPMLIB>
LU310.LBR.1                             COM        44544  81EFH

Here is the update info from the author:

File: LU310.UPD               72 lines            Date: 85-01-01
From: Gary P. Novosielski
To:   All LU Users
Subj: New LU version 3.10

Version 3.10 of the Library Utility is being released today.  It has
been tested under CP/M80 v2.2 and is expected to run properly under
CP/M+ as well.

Here is a short description of the changes from version 3.00 to 3.10.
Please use it until the revised document file, LU310.DOC is available,
which should be real soon now.

1.  Bug Fix in -Reorg to another drive.  Under 3.00 if you had reorgan-
    ized FOO.LBR from A: to B:, and there was _already_ a FOO.LBR on B:,
    LU would not have properly erased the old file, causing duplicate
    file names.  Yuchh.  I found this one by accident, rather than from
    a bug report, so I guess no one has ever been bitten by this one.
    Anyhow, it's fixed now.

2.  Change in reorganization logic.  If reorganization is done from one
    user/drive to another, the old copy of the library will no longer be
    deleted.  This gives some backup protection from Old Man Murphy.  The
    old copy will still be erased when reorganization is done within a
    single user/drive.

3.  I've hacked the directed I/O code to allow the -U operator to be used
    even if directed I/O (<input and >log) files are open.  This should
    make directed I/O more useable.  Leor's original DIO would lose track
    of the DIO files when the default drive was changed, so -U had been
    locked out in v3.00

4.  In response to user requests, a default library name will no longer
    be opened automatically when operands are being read from the console
    (stdin).  Instead, an error message will be issued saying that no
    library is open.  The default library LIBRARY.LBR will still be used
    if operands are being read from command line arguments, and no -O
    (open) is done.

5.  New operator -H (Help).  In response to user requests, a brief one-
    screen summary of operators, and the operands they expect, is now
    displayed by typing -H.  It is by no means an online user manual,
    just a memory jogger.  I knew it was time for this when I started to
    forget the commands myself!  Must be getting old.

6.  Version 3.10 still does not support the date/time stamping features
    defined in the new standard (LUDEF5) but now conforms to that stand-
    ard as a non-supporting program.  It preserves pre-existing stamps
    when appropriate, and will zero out any stamps which are made incor-
    rect by changes to the files or directory.    Pad counts, as defined
    in the standard, are tolerated, but not used, as they have no mean-
    ing under a CP/M-only environment.

7.  In bumming the extra space for the help code (the program is still
    under 20k on disk) I cleaned and tightened some of the logic, which
    may cause some cosmetic differences.  You may notice, for example,
    that the last operator used will show up in the prompt even if it
    was -L, -R, or -C, which take no operands.    There is no functional
    difference, though; operands will still be ignored by these opera-
    tors.

For bug reports, questions, etc., please contact me via:

Phone (voice):                (201)935-4087                 Eves and weekends.
Compuserve:                   70160,120           GO PCS-47 or GO EMA-1
MCI Mail:           GNOVOSIELSKI
WUI Telex:                    650-195-2395                  6501952395 MCI

Regards,
Gary Novosielski
---[4568]---

[4569] (8 lines) Network_Server 01/16/85  0732.9 mst Wed cpm
Subject:  Re: DbaseII errors
Date:  Wednesday, 16 January 1985 06:09 mst
From:  Lowans.Henr at XEROX
To:  Jack H. Smith <jhsmith at CRDC>
cc:  info-cpm at AMSAA

"TOO MANY FILES OPEN" occurs when more than 16 Command files are opened at once

Paul

---[4569]---

[4570] (239 lines) Network_Server 01/16/85  0733.0 mst Wed cpm
Subject:  XLISP news (~10K char).
Date:  Wednesday, 16 January 1985 06:38 mst
From:  David Towson <towson at AMSAA> (SECAD)
To:  info-cpm at AMSAA

Fellow CP/Mers - As several people have recently expressed interest in XLISP
by David Betz, here is some XLISP news passed along to me by my colleague,
Brint Cooper:
--------------------------------------------------------------------------
From seismo!harvard!godot!mit-eddie!genrad!decvax!ittvax!sii!drd
Article 89 of net.lang.lisp:


I am posting this for David Betz who
does not have a direct news connection.
==========================================================================

XLISP USERS

This document briefly describes my version 1.2 of XLISP.  It has nothing
in common with the previously released version 1.2 other than that it is
a descendant of my original version 1.1.  It will be available shortly from
the PC-SIG, SIG/M and PC-BLUE user groups.  It will be distributed in
source form with machine readable documentation.  Please don't ask to have
the sources distributed on usenet.  The entire distribution is over 200K
bytes!

          David Betz
          ...!decvax!sii!has70!betz

==========================================================================



          XLISP: An Experimental Object Oriented Language

                            Version 1.2

                          October 11, 1984


                                 by
                             David Betz
                         114 Davenport Ave.
                       Manchester, NH  03103

                       (603) 625-4691 (home)
                       (603) 623-3330 (work)


    XLISP is an experimental programming language combining some
    of  the  features  of LISP with an object oriented extension
    capability.  It was  implemented  to  allow  experimentation
    with  object oriented programming on small computers.  There
    are currently implementations running on  the  PDP-11  under
    RSX-11,  RT-11, and UNIX V7, on the VAX-11 under VAX/VMS and
    Berkeley VAX/UNIX, on the Z-80 under CP/M-80, on  the  Z8000
    under UNIX V7, and on the 8088/8086 under CP/M-86 or MS-DOS.
    A version is currently being developed for the  68000  under
    CP/M-68K.   It  is  completely  written  in  the programming
    language 'C'  and  is  easily  extended  with  user  written
    built-in  functions  and classes.  It is available in source
    form free of charge to  non-commercial  users.   Prospective
    commercial users should contact the author for permission to
    use XLISP.

    Version 1.2 of XLISP differs from  version  1.1  in  several
    ways.   It  supports  many  more Lisp functions.  Also, many
    version 1.1  functions  have  been  renamed  and/or  changed
    slightly  to follow traditional Lisp usage.  One of the most
    frequently reported problems in version  1.1  resulted  from
    many  functions being named after their equivilent functions
    in the C language.  This turned  out  to  be  confusing  for
    people who were trying to learn XLISP using traditional LISP
    texts as references.  Version 1.2 renames these functions to
    be compatible with more traditional dialects of LISP.

    A recommended text for learning LISP programming is the book
    "LISP"  by Winston and Horn and published by Addison Wesley.
    The first edition of this book is based on MacLisp  and  the
    second  edition is based on Common Lisp.  Future versions of
    XLISP will migrate towards compatiblility with Common Lisp.
<form-feed>
                                                          Page 2


    XLISP version 1.2 functions:

    Evaluator functions

    (eval <expr>)  EVALUATE AN XLISP EXPRESSION
    (apply <fun> <args>)  APPLY A FUNCTION TO A LIST OF ARGUMENTS
    (funcall <fun> <arg>...)  CALL A FUNCTION WITH ARGUMENTS
    (quote <expr>)  RETURN AN EXPRESSION UNEVALUATED

    Symbol functions

    (set <sym> <expr>)  SET THE VALUE OF A SYMBOL
    (setq <sym> <expr>)  SET THE VALUE OF A SYMBOL
    (defun <sym> <fargs> <expr>...)  DEFINE A FUNCTION WITH EVALUATED ARGS
    (ndefun <sym> <fargs> <expr>...)  DEFINE A FUNCTION WITH UNEVALUATED ARGS
    (gensym <tag>)  GENERATE A SYMBOL
    (intern <sym>)  INTERN A SYMBOL ON THE OBLIST
    (get <sym> <prop>)  GET THE VALUE OF A PROPERTY
    (putprop <sym> <value> <prop>)  PUT A PROPERTY ONTO A PROPERTY LIST
    (remprop <prop> <sym>)  REMOVE A PROPERTY

    List functions

    (car <expr>)  RETURN THE CAR OF A LIST NODE
    (cdr <expr>)  RETURN THE CDR OF A LIST NODE
    (caar <expr>) == (car (car <expr>))
    (cadr <expr>) == (car (cdr <expr>))
    (cdar <expr>) == (cdr (car <expr>))
    (cddr <expr>) == (cdr (cdr <expr>))
    (cons <expr1> <expr2>)  CONSTRUCT A NEW LIST NODE
    (list <expr>...)  CREATE A LIST OF VALUES
    (append <expr>...)  APPEND LISTS
    (reverse <expr>)  REVERSE A LIST
    (last <list>)  RETURN THE LAST LIST NODE OF A LIST
    (member <expr> <list>)  FIND AN EXPRESSION IN A LIST
    (memq <expr> <list>)  FIND AN EXPRESSION IN A LIST
    (assoc <expr> <alist>)  FIND AN EXPRESSION IN AN ASSOCIATION LIST
    (assq <expr> <alist>)  FIND AN EXPRESSION IN AN ASSOCIATION LIST
    (length <expr>)  FIND THE LENGTH OF A LIST
    (nth <n> <list>)  RETURN THE NTH ELEMENT OF A LIST
    (nthcdr <n> <list>)  RETURN THE NTH CDR OF A LIST
    (mapcar <fcn> <list1>...<listn>)  APPLY FUNCTION TO SUCCESSIVE CARS
    (maplist <fcn> <list1>...<listn>)  APPLY FUNCTION TO SUCCESSIVE CDRS
    (subst <to> <from> <expr>)  SUBSTITUTE ONE EXPRESSION FOR ANOTHER
    (sublis <alist> <expr>)  SUBSTITUTE USING AN ASSOCIATION LIST

    Destructive list functions

    (rplaca <list> <expr>)  REPLACE THE CAR OF A LIST NODE
    (rplacd <list> <expr>)  REPLACE THE CDR OF A LIST NODE
    (nconc <list>...)  DESTRUCTIVELY CONCATENATE LISTS
    (delete <expr> <list>)  DELETE OCCURANCES OF AN EXPRESSION FROM A LIST
    (delq <expr> <list>)  DELETE OCCURANCES OF AN EXPRESSION FROM A LIST

<form-feed>
                                                          Page 3

    Predicate functions

    (atom <expr>)  IS THIS AN ATOM?
    (symbolp <expr>)  IS THIS A SYMBOL?
    (numberp <expr>)  IS THIS A NUMBER?
    (null <expr>)  IS THIS AN EMPTY LIST?
    (not <expr>)  IS THIS FALSE?
    (listp <expr>)  IS THIS A LIST?
    (consp <expr>)  IS THIS A NON-EMPTY LIST?
    (boundp <sym>)  IS THIS A BOUND SYMBOL?
    (eq <expr1> <expr2>)  ARE THE EXPRESSIONS IDENTICAL?
    (equal <expr1> <expr2>)  ARE THE EXPRESSIONS EQUAL?

    Control functions

    (cond <pair>...)  EVALUATE CONDITIONALLY
    (let (<binding>...) <expr>...)  BIND SYMBOLS AND EVALUATE EXPRESSIONS
    (and <expr>...)  THE LOGICAL AND OF A LIST OF EXPRESSIONS
    (or <expr>...)  THE LOGICAL OR OF A LIST OF EXPRESSIONS
    (if <texpr> <expr1> [<expr2>])  EXECUTE EXPRESSIONS CONDITIONALLY
    (progn <expr>...)  EXECUTE EXPRESSIONS SEQUENTIALLY
    (while <texpr> <expr>...)  ITERATE WHILE AN EXPRESSION IS TRUE
    (repeat <iexpr> <expr>...)  ITERATE USING A REPEAT COUNT

    Arithmetic functions

    (+ <expr>...)  ADD A LIST OF NUMBERS
    (- <expr>...)  SUBTRACT A LIST OF NUMBERS
    (* <expr>...)  MULTIPLY A LIST OF NUMBERS
    (/ <expr>...)  DIVIDE A LIST OF NUMBERS
    (1+ <expr>)  ADD ONE TO A NUMBER
    (1- <expr>)  SUBTRACT ONE FROM A NUMBER
    (rem <expr>...)  REMAINDER OF A LIST OF NUMBERS
    (minus <expr>)  NEGATE A NUMBER
    (min <expr>...)  THE SMALLEST OF A LIST OF NUMBERS
    (max <expr>...)  THE LARGEST OF A LIST OF NUMBERS
    (abs <expr>)  THE ABSOLUTE VALUE OF A NUMBER

    Bitwise boolean functions

    (& <expr>...)  THE BITWISE AND OF A LIST OF NUMBERS
    (| <expr...)  THE BITWISE OR OF A LIST OF NUMBERS
    (~ <expr>)  THE BITWISE NOT OF A NUMBER

    Relational functions

    (< <e1> <e2>)  TEST FOR LESS THAN
    (<= <e1> <e2>)  TEST FOR LESS THAN OR EQUAL TO
    (= <e1> <e2>)  TEST FOR EQUAL TO
    (/= <e1> <e2>)  TEST FOR NOT EQUAL TO
    (>= <e1> <e2>)  TEST FOR GREATER THAN OR EQUAL TO
    (> <e1> <e2>)  TEST FOR GREATER THAN
<form-feed>
                                                          Page 4

    String functions

    (strcat <expr>...)  CONCATENATE STRINGS
    (strlen <expr>)  COMPUTE THE LENGTH OF A STRING
    (substr <expr> <sexpr> [<lexpr>]) EXTRACT A SUBSTRING
    (ascii <expr>)  NUMERIC VALUE OF CHARACTER
    (chr <expr>)  CHARACTER EQUIVALENT OF ASCII VALUE
    (atoi <expr>)  CONVERT AN ASCII STRING TO AN INTEGER
    (itoa <expr>)  CONVERT AN INTEGER TO AN ASCII STRING

    I/O functions

    (read [<source> [<eof>]])  READ AN XLISP EXPRESSION
    (print <expr> [<sink>])  PRINT A LIST OF VALUES ON A NEW LINE
    (prin1 <expr> [<sink>])  PRINT A LIST OF VALUES
    (princ <expr> [<sink>])  PRINT A LIST OF VALUES WITHOUT QUOTING
    (terpri [<sink>])  TERMINATE THE CURRENT PRINT LINE
    (flatsize <expr>)  LENGTH OF PRINTED REPRESENTATION USING PRIN1
    (flatc <expr>)  LENGTH OF PRINTED REPRESENTATION USING PRINC
    (explode <expr>)  CHARACTERS IN PRINTED REPRESENTATION USING PRIN1
    (explodec <expr>)  CHARACTERS IN PRINTED REPRESENTATION USING PRINC
    (maknam <list>)  BUILD AN UNINTERNED SYMBOL FROM A LIST OF CHARACTERS
    (implode <list>)  BUILD AN INTERNED SYMBOL FROM A LIST OF CHARACTERS
    (openi <fname>)  OPEN AN INPUT FILE
    (openo <fname>)  OPEN AN OUTPUT FILE
    (close <fp>)  CLOSE A FILE
    (tyi [<source>])  GET A CHARACTER FROM A FILE OR STREAM
    (tyipeek [<source>])  PEEK AT THE NEXT CHARACTER FROM A FILE OR STREAM
    (tyo <ch> [<sink>])  PUT A CHARACTER TO A FILE OR STREAM
    (readline [<source>])  READ A LINE FROM A FILE OR STREAM

    System functions

    (load <fname>)  LOAD AN XLISP SOURCE FILE
    (gc)  FORCE GARBAGE COLLECTION
    (expand <num>)  EXPAND MEMORY BY ADDING SEGMENTS
    (alloc <num>)  CHANGE NUMBER OF NODES TO ALLOCATE IN EACH SEGMENT
    (mem)  SHOW MEMORY ALLOCATION STATISTICS
    (type <expr>)  RETURNS THE TYPE OF THE EXPRESSION
    (exit)  EXIT XLISP


---[4570]---

[4573] (17 lines) Network_Server 01/16/85  1133.9 mst Wed cpm
Subject:  Beware Perfect Writer Version II
Date:  Wednesday, 16 January 1985 09:21 mst
From:  Boebert at HI-MULTICS
To:  info-cpm at AMSAA

Be advised:  Perfect Writer Version II does NOT run on CP/M, is NOT
based on Mince/Emacs, and will NOT work on an Apple ][+.  It is a
MacWrite clonette for the //c and //e, with pull-down windows and lots
of klutz.  Thorn/EMI, the record company who pretends to be in the
software business, is dropping all distribution and support for the
"real" Perfect Writer.  Sic Transit Mince?  I sure hope not.

A friend of mine discovered this to his great dismay when he ordered
Perfect Writer and got the "improved" version.  Now he wants to know
where he can get something close to Mince/Scribble (the basis for the
original PW) and so do I.  Any clues out there in netland?

Earl (Boebert @ HI-Multics)
---[4573]---

[4574] (22 lines) Network_Server 01/16/85  1534.8 mst Wed cpm
Subject:  dbaseII
Date:  Wednesday, 16 January 1985 11:14 mst
From:  Jack H. Smith <jhsmith at CRDC>
To:  info-cpm at AMSAA

          O.K.; so I didn't really make myself clear regarding the
          answer to my question about the 'Too many files open' error
          with dbaseII......

          The problem was that I was looping back to the menu by issueing
          a DO command when I should've been using a RETURN command.

          I guess after looping around with DO's, the dbaseII package
          was opening another file each time I looped until it thought
          I'd opened Too Many files...

          I haven't tried this solution as yet, (I haven't had time),
          but it sure sounds reasonable....

          Thanks for keeping me on my toes guys...

          Jack H. Smith

---[4574]---

[4575] (19 lines) Network_Server 01/16/85  1534.8 mst Wed cpm
Subject:  Updated XREF250.LBR
Date:  Wednesday, 16 January 1985 09:23 mst
From:  B.Eiben LCG Ext 617-467-4431 <EIBEN at DEC-MARLBORO>

I hate to do it to everybody - and I didn't bump the version-nr either.
But using it - I came to hate my laziness in "flagging" references - so
I changed from ">> number" to "[number]" to make it easier on my "red
eyes"... since "visibility" is obviously dependent on terminal (or
printer) both LEADIN ( [ ) and TRAIL ( ] ) are EQUATES up front in the
source. NOT a change in functionality - so I left it at 2.50 (yeah and
I shuffled the source AGAIN to have main-code -> subs -> data ->
"once-only code" consistency (again only for the "next guy" improving
XREF).

The new XREF250.LBR is now available from SIMTEL20 as:

Filename                      Type       Bytes     CRC

Directory MICRO:<CPM.ASMUTL>
XREF250.LBR.2                           COM        32128  66A8H
---[4575]---

[4576] (16 lines) Network_Server 01/16/85  1534.8 mst Wed cpm
Subject:  PATCH17+
Date:  Wednesday, 16 January 1985 11:35 mst
From:  Steve Noland <NOLAND at USC-ISI>
To:  kpetersen at SIMTEL20

Please watch out for the file PATCH17+.lbr.  IT has appeared on
several west coast boards as of yesterday.  It has several serious
bugs in it, and a friend and I are in the process of helping the
author to clean it up.  The last version that really worked was 1.6.
Please remove any copies of any version of Patch 1.7 from the net.
The next (hopefully beta-tested) version will be 1.8, and will not be
released until it is relatively bomb- proofed.  This program has such
potential and such a nice user interface that we don't want to see it
ruined by premature release and thereby attracting an unearned bad
reputation.  Thanks for your cooperation.

Regards, Steve Noland
---[4576]---

[4577] (30 lines) Network_Server 01/16/85  1534.8 mst Wed cpm
Subject:  Revised quick-reference list to Simtel20 CP/M directories
Sender:  KPETERSEN at SIMTEL20
Date:  Wednesday, 16 January 1985 13:20 mst
From:  Keith Petersen <W8SDZ at SIMTEL20>
To:  Info-Cpm at AMSAA

Quick reference list to SIMTEL20's MICRO:<CPM.x> directories
as of Jan. 16, 1985 (where 'x' is one of the names below):

22RSX         CPM3          GENASM        MODEM903      SUBMIT
6502          CPM86         GENCOM        MSOFT         SYSLIB
AMETHYST      CPMLIB        GENDOC        NEWS          SYSLIB3
APPLE         CPR86         HAMMING       NSTAR         SYSUTL
ASMUTL        CUG           HAMRADIO      OSBORN        T20-SQUSQ
ATARI         DBASEII       HDUTL         PACKET        TERM
AZTEC-C       DEBUG         HEATH         PASCAL        TOPS-20
BASIC         DIRUTL        HELP          PCDOS         TRS-80
BDOS          DISASM        HEX           PILOT80       TURBODOS
BDSC-1        DISKPLOT      IBM-PC        PLOT33        TXTUTL
BDSC-2        DSKBUF        INSIDCPM      PPSPEL        V2CMAC
BDSC-3        DSKUTL        KAYPRO        PUBKEY        VAXVMS
BDSC-4        EDITC80       LIST          PUBPATCH      VOICE
BSTAM         EDITOR        MACLIB        RBBS          WSTAR
BYE3          EPSON         MATH          RBBS4         XCCP
C80           EZCPR         MEMTEST       RCPM          YAM
CATLOG        FAST2         MEX           SMALLC2       Z3LIBS
CB80          FIDO          MICNET        SORT          ZCPR
CBIOS         FILCPY        MISC          SPELL         ZCPR2
CCP           FILUTL        MODEM         SQU-PORT      ZCPR3
COBOL         FORTH         MODEM2        SQUSQ
COMMODORE     FORTH-83      MODEM7        STARTER-KIT
---[4577]---


[4583] (20 lines) Network_Server 01/16/85  1935.5 mst Wed cpm
Subject:  Microsoft Linker L80 Question
Date:  Monday, 14 January 1985 12:37 mst
From:  D.DUBOSKY <ddd%hou2h.uucp at BRL-TGR>
To:  info-cpm at AMSAA
Newsgroups:  net.micro.cpm

Is anyone else having difficulty with Microsoft's Linker L80 when using
the search mode, that is, with a /s at the end of the file to be searched?
I am presently trying to use the linker with the C library of SmallC v2.1.
If I link the entire library with the compiled program, the resulting code
works just fine, but of course, I end up with a rather large program.  When
using the search mode, I get error messages that indicate that the linker
has not found certain modules of code.  What is a little confusing is that
the modules that it is trying to link are not required by the compiled code
but are definitely present in the library.

Any suggestions would be appreciated.
Thanks for any replies.

                                                  Dan Dubosky
                                                  hou2h!ddd
---[4583]---


[4585] (13 lines) Network_Server 01/16/85  1935.5 mst Wed cpm
Subject:  Z3NEWS.103
Date:  Wednesday, 16 January 1985 18:58 mst
From:  Rick Conn <RCONN at SIMTEL20>
To:  info-cpm at AMSAA

The latest ZCPR3 newsletter, Z3NEWS.103, is now in MICRO:<CPM.ZCPR3>.
As usual, lots of topics.  Of note are topics on new versions of some
of the tools and a support service provided by Echelon.  Many other items
of note also, depending on your interests.

Enjoy!

          Rick
-------
---[4585]---


[4587] (32 lines) Network_Server 01/16/85  2336.6 mst Wed cpm
Subject:  Re: Unix for CP/M 2.1 or > on a z80
Date:  Tuesday, 15 January 1985 10:43 mst
From:  Chuck McManis <cem%intelca.uucp at BRL-TGR>
To:  info-cpm at AMSAA
Newsgroups:  net.micro.cpm

I saw microshell once, and was impressed by the similarity of the
user interface with UNIX's. It implemented pipes by redirecting
I/O through a temporary disk file and seemed to work fairly well
until you needed to change the disk with the pipe file on it. This
of course wouldn't be a problem on a hard disk. If I might make a
suggestion, look into the ZCPR3 package on Simtel20 or your local
computer BBS. It implements a rather large part of the Unix user
interface, adds TERMCAP capabilities, a nice shell package with
variables and parameter substitution similar to csh and some
limited flow control. (If-Then-Else) But no CASE WHILE and UNTIL.
Still some pretty involved shell scripts are possible. It
does not offer I/O redirection or pipes, however the company
handling bug reports and distribution of a self installing version
,Echelon inc., have hinted strongly that their new version of the
BDOS will do just that. The best part is that if you can find a
local BBS that has it you can get it FREE by just downloading it.
That includes copies of a zillion utilities. It does make the
CP/M user interface usable, but you will need a Z80 to take full
advantage of it.

--Chuck

--
                                            - - - D I S C L A I M E R - - -
{ihnp4,fortune}!dual\                     All opinions expressed herein are my
        {qantel,idi}-> !intelca!cem       own and not those of my employer, my
 {ucbvax,hao}!hplabs/                     friends, or my avocado plant. :-}
---[4587]---

[4588] (19 lines) Network_Server 01/16/85  2336.6 mst Wed cpm
Subject:  Re: POW2 public domain formatter
Date:  Tuesday, 15 January 1985 11:11 mst
From:  Chuck McManis <cem%intelca.uucp at BRL-TGR>
To:  info-cpm at AMSAA
Newsgroups:  net.micro.cpm

Tim, Have you looked into the ROFF4 formatter? It has all of the features
you mentioned plus some. It is on Simtel20 if you want to snarf a copy,
also available on your local BBS (Consult RCPM-057.LST for details,
not available in all areas, not sold in stores) It has the nice feature
of being able to define ones own font (assuming your printer can do
bit mapped graphics) and is quite flexible.

--Chuck

--
                                            - - - D I S C L A I M E R - - -
{ihnp4,fortune}!dual\                     All opinions expressed herein are my
        {qantel,idi}-> !intelca!cem       own and not those of my employer, my
 {ucbvax,hao}!hplabs/                     friends, or my avocado plant. :-}
---[4588]---

[4589] (27 lines) Network_Server 01/16/85  2336.6 mst Wed cpm
Subject:  Public Domain Archives
Date:  Tuesday, 15 January 1985 13:21 mst
From:  Chuck McManis <cem%intelca.uucp at BRL-TGR>
To:  info-cpm at AMSAA
Newsgroups:  net.micro,net.micro.cpm

With all the hoopla about the various pros and cons of .5 Gbyte optical
disks, I thought it might be quite feasible to put the entire Simtel-20
archives on such a disk, in such a way that it would be easy to update.
There would be lots of room left over, and if they could be manufactured
cheaply enough maybe a series a archives could be established around the
country. I would certainly be willing to interface one of the Optimem or
equivalent drives to a CP/M system (I am aware of the logistics of such
an undertaking, with the restraints CP/M puts on file systems) and then
providing a place to put it where it could be called up and searched.
Does this sound like a reasonable undertaking ? It would be nice if we
could get Shugart to donate a drive and some disks for the publicity but
even paying for it outright is not enitirely impossible. Does anyone
know of the single unit evaluation drives cost? Also, Frank or Keith,
could one of you give an update on how much space the MICRO: archives
are using ?

--Chuck
--
                                            - - - D I S C L A I M E R - - -
{ihnp4,fortune}!dual\                     All opinions expressed herein are my
        {qantel,idi}-> !intelca!cem       own and not those of my employer, my
 {ucbvax,hao}!hplabs/                     friends, or my avocado plant. :-}
---[4589]---

[4590] (15 lines) Network_Server 01/16/85  2336.6 mst Wed cpm
Subject:  New ZCPR3 Files
Date:  Wednesday, 16 January 1985 21:08 mst
From:  Rick Conn <RCONN at SIMTEL20>
To:  info-cpm at AMSAA

The following files have been updated in MICRO:<CPM.ZCPR3>

          CLEANDIR.COM and CLEANDIR.MAC
          DIR.COM and DIR.MAC
          MCOPY.COM and MCOPY.MAC
          Z3INS.COM and Z3INS.MAC

Z3INS.DOC has been added.  Z3NEWS.103 speaks briefly of these new files.

          Rick
-------
---[4590]---

[4591] (19 lines) Network_Server 01/16/85  2336.6 mst Wed cpm
Subject:  Re: Public Domain Archives
Date:  Wednesday, 16 January 1985 21:17 mst
From:  Rick Conn <RCONN at SIMTEL20>
To:  cem%intelca.uucp at BRL-TGR
cc:  info-cpm at AMSAA, RCONN at SIMTEL20

Chuck,

Interesting you should bring this up.  The very large capacity disks is
exactly what Echelon has been addressing recently.  ZRDOS2, Echelon's
BDOS replacement which combines with ZCPR3, addresses 512 M bytes directly.
Other features, such as no need for a ^C any more and an extended READLN
function (fct 10) are also present.  Interacting with ZCPR3, named dirs
over a 512M space become especially useful.  I haven't brought up ZRDOS2 yet,
but it is sitting on my shelf waiting for installation.

          Rick

PS See the recent newsletters from Echelon in MICRO:<CPM.ZCPR3>Z3NEWS.10?.
-------
---[4591]---

[4592] (22 lines) Network_Server 01/16/85  2336.6 mst Wed cpm
Subject:  More new ZCPR3 Files
Date:  Wednesday, 16 January 1985 22:43 mst
From:  Rick Conn <RCONN at SIMTEL20>
To:  info-cpm at AMSAA

The directory MICRO:<CPM.Z3NEW> (a new directory on SIMTEL20) contains
the following Z3 files:

          LRUNZ3.ASM          - a version of LRUNZ for Z3
          Z3BYE.DOC - notes on using Z3 with RCP/M applications
          Z3HELPR4.EI         - a list of people volunteering to help others
                                with installing and in answering questions
                                about Z3; note that certain people specialize, such
                                as for the Osborne, Apple, Morrow, etc
          Z3EMX.LBR - using Z3 with EMX
          ZBYE.MAC  - a version of BYE for Z3 use

These will probably be moved into <CPM.ZCPR3> at a later date.

Enjoy!

          Rick
-------
---[4592]---


[4595] (15 lines) Network_Server 01/17/85  1139.9 mst Thu cpm
Subject:  Re: Unix for CP/M 2.1 or > on a z80
Date:  Thursday, 17 January 1985 08:13 mst
From:  ross m. greenberg <greenber%acf4.uucp at BRL-TGR>
To:  info-cpm at AMSAA
Newsgroups:  net.micro.cpm

<>

The only problem with ZCPR (to me) is the amount of disk that you need
to get all the utilities up and operational.  Having a KAYPRO-II with
2 180K drives, I'd have no room left on the disk for anything after
loading all the nifty ZCPR utilities.


------------------------------------------------------
Ross M. Greenberg  @ NYU   ----> { allegra,ihnp4 }!cmcl2!acf4!greenber  <----
---[4595]---

[4597] (51 lines) Network_Server 01/17/85  2129.4 mst Thu cpm
Subject:  re: need a break key
Date:  Wednesday, 16 January 1985 10:47 mst
From:  jeff <jeff%abnji.uucp at BRL-TGR>
To:  info-cpm at AMSAA
Newsgroups:  net.micro.cpm

[I'm new to USENET,so please be kind]

          Causing a BREAK without a break key is tricky since BREAK is not
a character but a line condition.  An active RS232 line (transmit or
receive data) is normally in the MARKING state (quiescent state)
(binary 1, voltage between -3 and -25 volts).  When a character is sent,
the line sends a start bit (goes SPACE, binary 0, voltage between +3 and
+25 volts), then the data bits (and parity if enabled), then a stop
bit (back to MARKING).

          A framing error is caused when the end bit isn't received
when it is expected, usually suggesting mismatched speeds.

          A break condition is when the line is put in the SPACE state
for the time it takes to transmit a character (including start and
stop bits) and thus cannot be confused with a character transmission.
Some serial communication chips will detect the start and end of
a break (since it may last a looooong time) and interrupt on both.
Others just give a framing error with 00h data.

          The UNIX Administrator's Manual under TERMIO(7) under IGNBRK
states that a break condition is a framing error with data 00h.  Non-null
data causing a framing error is considered a framing error.

          A break key causes the line to go spacing for about 1.1 to 2x
a character time length (usually a long time - around 200 milliseconds).

          Your trick of going to a slower speed may work if the software
treats framing error as a break (regardless if the data is 00h or not).
If they are treated differently, then you must transmit a NULL
character, usually control @.  This will be undistinguishable from a
break to all but the fussiest of receivers.  This also points out
that a framing error on a null character will be misinterpreted
as a break.

          I trust this definitively answers your question.  Ask anything
more technical and I will refer to the EIA Standard for RS-232-C
"Interface Between Data Terminal Equipment and Data Communication
Equipment Employing Serial Binary Data Interchange". So there!

                              +-----------------------------------------------+
                              |  Jeff 'oh my gawd - it's one of THOSE!' Skot    |
                              |     at beautiful downtown Somerset NJ           |
                              |               AT&T Info Systems                           |
                              |                   ..!abnji!jeff                           |
                              +-----------------------------------------------+
---[4597]---

[4598] (11 lines) Network_Server 01/17/85  2129.4 mst Thu cpm
Subject:  Re: Unix for CP/M 2.1 or > on a z80
Date:  Thursday, 17 January 1985 21:01 mst
From:  Rick Conn <RCONN at SIMTEL20>
To:  greenber%acf4.uucp at BRL-TGR
cc:  info-cpm at AMSAA, RCONN at SIMTEL20

You're quite right about ZCPR3 on 180K disks.  Some of the Echelon
newsletters talk about this, and one gives a breakdown of the disk overhead.
There is some discussion about reducing this overhead by being selective about
the features; overhead can drop to as little as 60K for some applications.
But if you want everything, there is a price to pay.
-------
---[4598]---

[4601] (10 lines) Network_Server 01/18/85  1332.9 mst Fri cpm
Subject:  Re: Unix for CP/M 2.1 or > on a z80
Date:  Friday, 18 January 1985 11:09 mst
From:  Bicer.ES at XEROX
To:  ross m. greenberg <greenber%acf4.uucp at BRL-TGR>
cc:  info-cpm at AMSAA

Try MicroShell. I've had it for almost three years, and it it one of the
most invaluable pieces of software I have. It works like a charm, and
you'll never know that it is there (apart from ~10k less RAM).

          Jack Bicer
---[4601]---

[4606] (35 lines) Network_Server 01/18/85  2134.4 mst Fri cpm
Subject:  macrotech board update...
Date:  Friday, 18 January 1985 17:20 mst
From:  Herb Lin <LIN at MIT-MC>
To:  info-cpm at AMSAA
cc:  LIN at MIT-MC

I have bought a Macrotech MI-286 from Gifford Computer Systems, whose
problems I described in a previous note.  Their recommended cure was
to upgrade my hard disk controller board from a Morrow HDCA-4 to a
Compupro Disk2.  However, a conversation with the techs at Macrotech
resulted in confusing information: Macrotech tells me that the problem
is most likely in the Compupro RAM 16 boards that I am using; these
are alleged to have a wrong pull-up resistor in R1.  They said that
the fix would be to put the correct resistor there, and all would be
well.  They also said that other Compupro memory boards did not have
the same problem, and that they knew of people with Morrow controllers
running Macrotech boards without difficulty.

I tried something else, with their concurrence.  I replaced my 4 RAM
16 boards with a RAM 22 board, and tried running the Macrotech board
with that configuration.  Here I had a very strange experience -- the
system worked fine in the morning, but then I shut it down.  In the
afternoon, I powered up again, and found that the system no longer
worked.  Closer investigation revealed that my hard disk directory had
been trashed in a very subtle way, and Gifford says that their other
customers with Morrow controllers and Macrotech boards have reported
similar trashing problems.

I have decided to take Gifford's solution, since they were
generous in offering me some trade-in value for my Morrow controller,
*and* assuring me of refund if their solution did not work.

More as it develops.

herb lin

---[4606]---

[4607] (10 lines) Network_Server 01/18/85  2134.4 mst Fri cpm
Subject:  Re: Turbo Pascal: Did I hear right?
Date:  Thursday, 17 January 1985 18:32 mst
From:  Paul Hyder <hyder%mako.uucp at BRL-TGR>
To:  info-cpm at AMSAA
Newsgroups:  net.micro.cpm

   My CP/M version works just fine.
   There do seem to be some interesting problems with stack
   frames in procedures that call procedures but it could be
   my machine.
          Paul Hyder  {...tektronix!tekecs!hyder}
---[4607]---

[4608] (27 lines) Network_Server 01/18/85  2134.4 mst Fri cpm
Subject:  Re: Microsoft Linker L80 Question
Date:  Thursday, 17 January 1985 20:37 mst
From:  Andrew Klossner <andrew%orca.uucp at BRL-TGR>
To:  info-cpm at AMSAA
Newsgroups:  net.micro.cpm

[]

          "Is anyone else having difficulty with Microsoft's Linker L80
          when using the search mode, that is, with a /s at the end of
          the file to be searched?"

There's a bug in L80.  When searching a library, it encounters a
module, and begins passing over the symbols to see if any are needed.
If it passes over a COMMON block, then comes to an symbol which is
needed, it gets a fatal system error in trying to back up to the
beginning of the module and begin loading.

This prevents inclusion of output from the Aztec C compiler in
libraries.  A work-around is to edit the assembly output from the
compiler and move all the common blocks to the end of the file.

I submitted a bug report to Microsoft two years ago, and received
acknowledgement, but to my knowledge they have never fixed this.
CP/M-80 is dead, don't you know ...

  -- Andrew Klossner   (decvax!tektronix!orca!andrew)       [UUCP]
                       (orca!andrew.tektronix@csnet-relay)  [ARPA]
---[4608]---

[4609] (99 lines) Network_Server 01/18/85  2134.4 mst Fri cpm
Subject:  Re: possible problems with large numbers of open files
Date:  Thursday, 17 January 1985 21:00 mst
From:  Andrew Klossner <andrew%orca.uucp at BRL-TGR>
To:  info-cpm at AMSAA
Newsgroups:  net.micro.cpm

All of this applies to CP/M-80 version 2.2.

Key to understanding disk file I/O in CP/M is the fact that all of the
information about an "open file" is contained in the FCB, which your
program allocates and controls.  To open a file, CP/M just fills in
your FCB with the directory information about the base segment, then
promptly forgets about the file.  When you read, it uses the FCB to
determine which record to get, calls the BIOS to read it, then updates
the FCB to point to the next record.  When you cross to a new segment,
CP/M goes to the directory and fills in the FCB with the new segment's
information.

On output, the directory is not updated until you do a CLOSE or WRITE
to a different segment.  That's why, if you CREATE a file, WRITE many
records to it, then kill your program, you often discover that you have
a zero length file; the WRITEs happened but the directory was never
updated to record them.  On the next warm boot, all the records that
were written are reclaimed as free space.

          "Does CP/M do strange things when many files are open and being
          written at once?  I have a program that does this (six files
          are being written at once, and are therefore open), and a
          variety of strange behaviours occur, such as the disk write
          sequential call seems to return errors (non-zero value in the A
          register) before the disk is actually full."

I regular open dozens of file for input and output, with no trouble.
Since CP/M doesn't record knowledge of open files, there's no problem
with any internal tables overflowing (there aren't any).  Perhaps the
fact that the directory updates are deferred is fooling you into
thinking that the disk isn't full when actually all the free records
have been used up.

          "Related question:  the documentation for this op (whatever the
          number is) says that a non-zero value is returned in the A
          register for a nonsuccessful write due to a full disk.  Can
          this happen for other reasons than a full disk?  Examples would
          be some flavor of write error, etc."

A write will also fail if it's attempting to create a new segment and
the directory is full.

          "When deleting a file, what if anything besides the file name
          (the first 12 bytes, giving the drive, name, and extension)
          should be initialized, and to what value?  Which should not
          be?"

Of the first 16 bytes, set the last four to zero.  Actually I always go
belts-and-suspenders and zero all the rest of the FCB, but it shouldn't
be necessary.

          "When opening a file for reading, same questions.  Does not
          closing a file after reading it, either partially or totally,
          cause any problems?"

Just the opposite.  You should take pains NOT to do a CLOSE of a file
that was used only for reading.  This is because all a CLOSE does is
copy the FCB back out to the directory.  If you haven't modified the
file, this is an unnecessary disk access, and will prevent your program
from running when the file or the disk is read-only.

          "What is the best procedure for temporarily closing a file so
          it can be read from disk in a different FCB, and then reopening
          it later for writing, at the spot I left off when closing it?
          I. e. I flush the memory buffers for the six files I mentioned
          above, close the files, and use a different FCB for reading
          them.  When I read it, I open the file, but never close it.  To
          reopen the file, I save the number of the last record, open the
          proper extent of the file, and restore the last record number
          (base+32)."

If you're absolutely sure that you're not going to write (or otherwise
modify) the file while it's temporarily closed, it suffices to do a
CLOSE and keep the FCB, then resume WRITING with the FCB later.  This
is because CLOSE doesn't cause the file to no longer be OPEN in the
usual sense; all CLOSE really does is update the directory.  In fact,
if you have a transaction processing program which adds records to an
open file, it should CLOSE the file whenever it knows that it will be
idle for awhile (waiting for another line of terminal input), to make
sure that the entire file will be there if the system crashes or
someone removes the floppy.

          "To initialize an FCB for creating a file or deleting it, I set
          the following to zero: bytes 12 through 15, and byte 32 (offset
          from the base of the FCB).  Is this the right thing to do?
          Should I do this much?"

This should be enough.  But it can't hurt to zero the whole thing, just
in case.  I admit to what may be superstition here, but I keep finding
the "undefined" or "reserved for future use" bits in the FCB turn out
to be used.

  -- Andrew Klossner   (decvax!tektronix!orca!andrew)       [UUCP]
                       (orca!andrew.tektronix@csnet-relay)  [ARPA]
---[4609]---

[4610] (45 lines) Network_Server 01/19/85  0135.7 mst Sat cpm
Subject:  Hard Disk Problems
Date:  Friday, 18 January 1985 21:41 mst
From:  Phil Lapsley <phil%ucbeast at UCB-VAX>
To:  info-cpm at AMSAA

     I recently purchased a CompuPro Disk 3 hard disk controller
to go with my CP/M-816 system.  For the hard disk, I found a bargain
for a Rotating Memory Systems RMS 513 10 MB drive for $250 at a swap
meet.  The drive's characteristics are 216 cylilinders, 6 heads (i.e.,
tracks) per cylinder, 9 sectors per track, 1K per sector.  Naturally,
this is all ST506 compatible.

     Not that I really want to bore you with all this; no, what I need
is help getting the thing to work.  I have had the controller card
checked out at CompuPro, and it works.  I have had the RMS 513 drive
tested, and it performs "flawlessly", according to the third party
who tested it.

     So, what's the problem?  Well, I set up DPB's and DPH's, and
the following would happen.  The system would come up alright.
Attempting to write to the hard disk with "pip" and the verify option
would produce "foo.$$$: verify error."  Attempting to write to the
hard disk with "pip" and no verify would successfully create the
file, but attempting to run the file would crash the system.
When I would bring the system back up, there would be eight or
nine (!) entries of "foo.com" (or whatever file I tried to transfer)
in the directory of the hard disk.

     Now, it could very well be that I screwed up my DPB's and
DPH's.  But, it's my understanding that *any* ST506 compatible drive
can be run as an ST506.  It would just use 153 cylinders instead of
216, and 4 heads instead of 6.  CompuPro supplies a bios entry
for a ST506.  Naturally (?), attempting to use the ST506 bios entry
produces exactly the same results.

     I am at wit's end.  I have had both the drive and the controller
tested, and they each work separately.  Running a format/verify/data test
from the CompuPro disk 3 controller works fine.  But trying to run
the drive under CP/M bombs.  Any hard disk wizards out there who
could be of help?  Please reply directly to me, as I am no longer on
the alias (I had myself removed right before I needed it!)  I'll
summarize any general info I receive to the net.  Thanks very much.

                                                            Phil Lapsley
                                                            (phil@Berkeley.ARPA)
                                                            (...!ucbvax!phil)
---[4610]---

[4611] (26 lines) Network_Server 01/19/85  0536.6 mst Sat cpm
Subject:  Large number of simultaneously open files
Date:  Saturday, 19 January 1985 01:31 mst
From:  Ron Fowler <RFOWLER at SIMTEL20>
To:  info-cpm at BRL

Andy Klossner mentioned that you should take pains NOT to close a file open
only for read because

          1) It's not necessary
          2) Causes an unnecessary disk access

I must take exception to this; first, it's good programming practice to
close all open files, regardless of their read/write status.  But more im-
portantly, multi-user operating systems (such as MP/M and TurboDOS) that allow
filesharing must keep a record in memory for each file; these systems release
this memory when a file is closed.  Programs that open a large number of files
without closing them (CRCK.COM is a good example of this) tend to cause the
file lock space to be exhausted.  This is an especially severe problem with
MP/M, where lock space is a fixed number of files (TurboDOS uses all avail-
able memory).

Closing a file open for read does NOT cause an unnecessary directory access
under CP/M 2.2; CP/M keeps a flag in the FCB that is set when a write oc-
curs (bit 7 of the S2 byte, for those who are interested ... 0=written); if
the file hasn't been written to, CP/M returns a successful close result,
but inhibits any disk update.           --Ron Fowler
-------
---[4611]---

[4612] (62 lines) Network_Server 01/19/85  0536.6 mst Sat cpm
Subject:  Kaypro escape sequences list
Sender:  KPETERSEN at SIMTEL20
Date:  Saturday, 19 January 1985 04:31 mst
From:  Keith Petersen <W8SDZ at SIMTEL20>
To:  Wiedemann at RADC-MULTICS
cc:  Info-Cpm at AMSAA

Here's the info you wanted on the Kaypro escape sequences.
--Keith
--cut here--
KAYPRO II VIDEO SOFTWARE DRIVER.

The KAYPRO II video section was designed to imitate the control sequences of a
Lear-Siegler ADM-3A terminal.  For most commercial software, this means you
can "install" or customize the display characteristics by choosing the ADM=3A
from the menu.  For custom software or those instances where there is no
choice of "ADM-3A" on the menu, the following information may help.

The following is a list of the KPRO II  "Terminal" attributes and control
sequences.

Cursor Control -
----------------
        Cursor left (bs) .............  08h     08
        Cursor right .................  0Ch     12
        Cursor down (lf) .............  0Ah     10
        Cursor up ....................  0Bh     12
        Home cursor ..................  1Eh     30
        Clear screen & home cursor ...  1Ah     26
        Carriage return ..............  0Dh     13

Cursor Positioning -
--------------------

        Escape Sequence (ESC+"=") ....  1Bh,3Dh   27,61
        Cursor Rows ..................  0-23
        Cursor Columns ...............  0-79
        Positioning Sequence:

            In MBASIC ...

              PRINT chr$(27)+"="+chr$(20+row)+chr$(20+col);


Line Insert/Delete -
--------------------

        Line Insert (ESC+"E") ........  1Bh,45h   27,69
        Line Delete (ESC+"R") ........  1Bh,52h   27,82

Clear to End of Screen/Line -
-----------------------------

        Clear EOL (Ctl-X) ............  18h     24
        Clear EOS (Ctl-W) ............  17h     23

Set Greek or ASCII -
--------------------

        Set ASCII (ESC+"A") ..........  1Bh,41h   27,65
        Set Greek (ESC+"G") ..........  1Bh,47h   27,71
        After Setting Greek, lower case letters will print as
        the Greek Alphabet.
---[4612]---

[4613] (17 lines) Network_Server 01/19/85  0937.4 mst Sat cpm
Subject:  Re: CP/M Standards
Date:  Thursday, 17 January 1985 11:28 mst
From:  Chuck McManis <cem%intelca.uucp at BRL-TGR>
To:  info-cpm at AMSAA
Newsgroups:  net.micro.cpm

Splendid Idea! I would be willing to help in anyway I could. (I'm great
at supervising, just ask my wife :-) ) I would like to see if we could
get D.R. to help in this too. Would certainly make it easier on those
of us still writing original software for it.

--Chuck

--
                                            - - - D I S C L A I M E R - - -
{ihnp4,fortune}!dual\                     All opinions expressed herein are my
        {qantel,idi}-> !intelca!cem       own and not those of my employer, my
 {ucbvax,hao}!hplabs/                     friends, or my avocado plant. :-}
---[4613]---

[4614] (9 lines) Network_Server 01/19/85  1338.4 mst Sat cpm
Subject:  File sizes from Turbo
Date:  Saturday, 19 January 1985 12:02 mst
From:  Douglas Good <CMP.DOUG at UTEXAS-20>
To:  info-cpm at AMSAA

Does anyone know an easy way to get file sizes in Kilobytes using TurboPascal?
If it would help I have a Kaypro computer.

                    --Doug Good
-------
---[4614]---


[4618] (27 lines) Network_Server 01/19/85  2140.4 mst Sat cpm
Subject:  Beware LOCK.LBR timebomb
Sender:  KPETERSEN at SIMTEL20
Date:  Saturday, 19 January 1985 17:24 mst
From:  Keith Petersen <W8SDZ at SIMTEL20>
To:  Info-Cpm at AMSAA

BEWARE!!!  A program called LOCK, which has been recently uploaded
to some RCPMs, apparently has the potential of making .COM files
unusable.  This is another example of what can happen when we support
programs which are released without source code.
--Keith (Co-Sysop RCPM Royal Oak)

Msg posted on 01/17/85 from DAN PATT to SYSOP/ALL about LOCK.LBR

I downloaded the LOCK.LBR and without checking very carefully used the
LOCK.COM.  I tried to use lockout.com as the unlock.com file.
Surprize, it isn't that file.  Do you know where I can get a copy of
both unlock.com and mkey.com?  Or how to recover my locked file?  Last
time I'll use a new program on a needed file. Thanks

Msg posted on 01/18/85 from BILL CROCKER to DAN PATT about LOCK.LBR

Dan, you're not alone.  One of our club (D:KUG) members also locked a
file and can't un-lock it.  If your file is not proprietary, up-load
it to this system and leave me a message as to which drive and what
file name.  I will then down-load it and get with one of by friends
who is a CP/M wizzard and see if he can un-lock it.
     Good luck,   Bill Crocker
---[4618]---

[4620] (33 lines) Network_Server 01/20/85  0141.3 mst Sun cpm
Subject:  help needed in installation of small-c and sq/usq
Date:  Wednesday, 16 January 1985 14:53 mst
From:  R. MEIER <rmeier at SU-STAR>
Reply-To:  R. MEIER <rmeier at SU-STAR>
To:  info-cpm <info-cpm at AMSAA>


Valentina,
          Recently, I have been trying to bring up smallc, from simtel20
micro:<cpm.smallc2>, without success on an Apple ][+.  Is there anyone
who could lend assistance on getting smallc2 installed?
          I have also been unable to bring up sq, usq, or lu.  I have access
to a VAX/VMS running Eunice (a Unix-like os), on which I have been able
to bring up xsq, xusq, and lar from micro:<unix.cpm>.  The files in
smallc1.lbr, smallc2.lbr, and smc-asm.lbr have been successfully separated.
On the Apple ][+ I have three 5.25" disks (128K), asm, and kermit 3.9.
          The problems that I have been encountering include the following:
                    o stdiol.h file is missing
                    o make.sub file is missing
                    o #asm operative is flagged even though it is nested in
                              #ifdef's which are unsatisfied.  (I can solve
                              this by commenting out that section. */
                    o zzor(), zzand() and other functions are undefined.
                    o The file contains several pointer/int operations that
                              create "illegal lhs of expression" errors in
                              addition to "illegal op/pointer combination"
                              warnings.
          Please send any suggestions to info-cpm or to rmeier@star.
                                                  Thank you,
                                                  Bob

"All the World is an S-expression."  (requoted from James Chalker)
"(print (setf (cdr Universe) Universe (car Universe) Eternity)"  (God)
------
---[4620]---

[4621] (36 lines) Network_Server 01/20/85  0943.3 mst Sun cpm
Subject:  Re: possible problems with large numbers of open files
Date:  Saturday, 19 January 1985 20:00 mst
From:  oacb2 <oacb2%ut-ngp.uucp at BRL-TGR>
To:  info-cpm at AMSAA
Newsgroups:  net.micro.cpm

> Just the opposite.  You should take pains NOT to do a CLOSE of a file
> that was used only for reading.  This is because all a CLOSE does is
> copy the FCB back out to the directory.  If you haven't modified the
> file, this is an unnecessary disk access, and will prevent your program
> from running when the file or the disk is read-only.

The BDOS (CP/M 2.2 and, I assume, CP/M Plus) is smart enough to not rewrite
the FCB if it's not been changed.  Not closing input files is just asking
for trouble if you ever upgrade to a multiuser or multiprocessor system.

> If you're absolutely sure that you're not going to write (or otherwise
> modify) the file while it's temporarily closed, it suffices to do a
> CLOSE and keep the FCB, then resume WRITING with the FCB later.  This
> is because CLOSE doesn't cause the file to no longer be OPEN in the
> usual sense; all CLOSE really does is update the directory.  In fact,
> if you have a transaction processing program which adds records to an
> open file, it should CLOSE the file whenever it knows that it will be
> idle for awhile (waiting for another line of terminal input), to make
> sure that the entire file will be there if the system crashes or
> someone removes the floppy.

Again, this may cause trouble if you upgrade to a multiuser or multiprocessor
system.

I strongly recommand that all files be closed after processing and that
I/O never be done to a "closed" FCB.  Closing an input file causes negligible
overhead.  Opening a closed file does require some overhead, but I think it's
worth it.
--

          Mike Rubenstein, OACB, UT Medical Branch, Galveston TX 77550
---[4621]---

[4622] (20 lines) Network_Server 01/20/85  0943.4 mst Sun cpm
Subject:  umodem for System V available
Date:  Thursday, 17 January 1985 20:37 mst
From:  Geoff Kuenning <geoff%desint.uucp at BRL-TGR>
To:  info-cpm at AMSAA
Newsgroups:  net.micro,net.micro.cpm
Xref:  sdcrdcf net.micro:3613 net.micro.cpm:1694

I posted this to net.wanted.sources a few days ago, but forgot these two
groups.  To all of you who are seeing it twice, my humble apologies.

I have a copy of UMODEM that will run on System V.  It's not the latest
version around, but it works quite well.  If you are interested in a copy,
send me mail and I will either post it or mail it to you, depending on the
level of interest.

          Geoff Kuenning
          ...!ihnp4!trwrb!desint!geoff
--

          Geoff Kuenning
          ...!ihnp4!trwrb!desint!geoff
---[4622]---

[4625] (15 lines) Network_Server 01/20/85  1344.4 mst Sun cpm
Subject:  What is Simtel20
Date:  Friday, 18 January 1985 09:10 mst
From:  Mark D. Falleroni <mdf%trwrba.uucp at BRL-TGR>
To:  info-cpm at AMSAA
Newsgroups:  net.micro.cpm

I'm relatively new to cpm and to this news network, so please excuse
my ignorance.  Would some kind sympathetic soul explain to me what is
SIMTEL20??  From the cpm news that I've been reading, I suspect that it
is a large BBS?  If it is, how can I access it.
Thanks in advance for any help given.

  Mark Falleroni
  TRW
  Ogden,Ut
  (mdf)
---[4625]---

[4626] (18 lines) Network_Server 01/20/85  1344.4 mst Sun cpm
Subject:  Re: More new ZCPR3 Files
Date:  Friday, 18 January 1985 13:21 mst
From:  Chuck McManis <cem%intelca.uucp at BRL-TGR>
To:  info-cpm at AMSAA
Newsgroups:  net.micro.cpm

Rick,

    Do you think it would be possible to make a "standard" ZCPR3 bank
select interface? It would really be nice If I could swap out some
of Z3 environments when I wasn't using them. It would also give me
back enough TPA to keep Mince from thrashing the disk.

--Chuck
--
                                            - - - D I S C L A I M E R - - -
{ihnp4,fortune}!dual\                     All opinions expressed herein are my
        {qantel,idi}-> !intelca!cem       own and not those of my employer, my
 {ucbvax,hao}!hplabs/                     friends, or my avocado plant. :-}
---[4626]---

[4627] (42 lines) Network_Server 01/20/85  1344.4 mst Sun cpm
Subject:  Size of ZCPR3 on disk
Date:  Friday, 18 January 1985 13:43 mst
From:  Chuck McManis <cem%intelca.uucp at BRL-TGR>
To:  info-cpm at AMSAA
Newsgroups:  net.micro.cpm

Actually, you can get a lot of benefit from just having Z3, the environments,
and a couple of utilities there. With the "standard" 1K overhead in
the BIOS plus the flow control package for really neat ZEX command files
All you need on your disk are LDR to load the environments, two environments
SYS.ENV, and SYS.FCP, IF.COM to handle IF's that the FCP can't and your
own DIR.COM. All told about 16K worth of stuff, and more if you replace
SUB with ZEX, no loss there. You get the benefits of multiple commands,
path searching, and a termcap for use when you are using some of the
other utilities. If you go over the list of utilities you will see a lot
of duplication in them, such as PAGE.COM and PRINT.COM, which are like
the resident commands TYPE and LIST. (more features but essentially the
same function) ERROR1,ERROR2,ERROR3,ERRORX are neat (you only need one
of the numbered error packages to handle errors and ERRORX to turn of
handling errors) If you use VMENU you don't need MENU, if you use
SWEEP you probably won't need MCOPY, and if you aren't debugging or
something you don't need DU3 or MU3. Assuming you are the only one
on the system you probably wouldn't need WHEEL so when it comes down
to it, you really can everything you NEED plus some others for less
30K and practically everything with 64K. Not to bad really, especially
if it means you can get rid of some of the programs you currently have
on the disk, like PIP.COM or DUMP.COM. The only thing you might want at
first but could later get rid of are the Help files for the utilities
you did have on line. I have a 180K  minifloppy that is nothing but help
(and it has space leftover) set aside as sort of a tutorial disk.
It really isn't as bad as you might think, the problem is all of
Ricks examples in the Documentation seem to have EVERYTHING loaded so
it looks like that is the Only way to have ZCPR3. This is definitely
not true.

--Chuck


--
                                            - - - D I S C L A I M E R - - -
{ihnp4,fortune}!dual\                     All opinions expressed herein are my
        {qantel,idi}-> !intelca!cem       own and not those of my employer, my
 {ucbvax,hao}!hplabs/                     friends, or my avocado plant. :-}
---[4627]---

[4628] (25 lines) Network_Server 01/20/85  1344.4 mst Sun cpm
Subject:  ZCPR3 Hacks
Date:  Friday, 18 January 1985 13:52 mst
From:  Chuck McManis <cem%intelca.uucp at BRL-TGR>
To:  info-cpm at AMSAA
Newsgroups:  net.micro.cpm

I made a couple of changes to the ZCPR3.ASM file to make using the wheel
byte a little easier. First I added a Wheel Prompt variable (WPRMPT)
so that when you were enabled ZCPR could change the '>' to something
else, being an old TOPS-20 fan I of course use '!'. Thus, when you are
NOT enabled, and your prompt was "A:SYS>" , when you set the wheel
byte it becomes "A:SYS!", real trivial stuff here. The second change
was to make it easier to use my own system when it was in the "secure"
mode. Basically, the password checking facility on directories is
defeated by having wheel enabled. Since I don't know how many others
  
will find these useful, currently the only copy of these changes,
(besides my own) is on the ZCPR3 BBS at (415) 489-9005, if there
is some interest I will send a copy to Simtel-20.

--Chuck

--
                                            - - - D I S C L A I M E R - - -
{ihnp4,fortune}!dual\                     All opinions expressed herein are my
        {qantel,idi}-> !intelca!cem       own and not those of my employer, my
 {ucbvax,hao}!hplabs/                     friends, or my avocado plant. :-}
---[4628]---

[4629] (20 lines) Network_Server 01/20/85  1344.4 mst Sun cpm
Subject:  ZCPR3 -- Where can I get it?
Date:  Thursday, 17 January 1985 13:27 mst
From:  Michael Cooper <mikec%reed.uucp at BRL-TGR>
To:  info-cpm at AMSAA
Newsgroups:  net.micro.cpm

After posting an article asking about Unix-like utilities for a z80 running
2.1 CP/M, I received several suggestions.  One was ZCPR3.  They all said I
could get it for free from many RCPM sites, but the last one around here
in Portland that I know about was Chuch Forsberg's.  It hasn't been around
for a while.  Anyone know of an RCPM site locally in the Portland area
with ZCPR3? How about the next closest site?
                                                  Michael Cooper

______________________________________________________________________________
{decvax, ucbvax, pur-ee, uw-beaver, masscomp, cbosg,
 mit-ems, psu-cs, uoregon, orstcs, ihnp4, uf-cgrl}!tektronix
                                                                  \
                                                                   +---!reed!mikec
{teneron, ogcvax, muddcs, cadic, oresoft, grpwre,     /
                       psu-cs, omen, isonvax, nsc-pdc}---+
---[4629]---

[4630] (8 lines) Network_Server 01/21/85  0147.3 mst Mon cpm
Subject:  Re: want `lu' utility under unix
Date:  Sunday, 20 January 1985 22:14 mst
From:  Rick Conn <RCONN at SIMTEL20>
To:  neil%sdcsvax.uucp at BRL-TGR
cc:  info-cpm at AMSAA, RCONN at SIMTEL20

Try LAR.C under MICRO:<UNIX.CPM>.  If it compiles for your particular
UNIX (and compiles correctly), it offers compatability with LU.
-------
---[4630]---

[4631] (23 lines) Network_Server 01/21/85  0147.3 mst Mon cpm
Subject:  Re: More new ZCPR3 Files
Date:  Sunday, 20 January 1985 23:11 mst
From:  Rick Conn <RCONN at SIMTEL20>
To:  cem%intelca.uucp at BRL-TGR
cc:  info-cpm at AMSAA, RCONN at SIMTEL20

Chuck,

          Re your request about adding bank select to ZCPR3, I feel that
bank select has to be implemented in the BDOS/ZRDOS rather than in Z3 itself,
altho ZCPR3 CP could use it.  We (ie, the Echelon effort) are not moving
in that direction, but rather in the direction of the Z800.  The Z800
offers a large memory address space, Z80 compatability, a higher speed,
and other nice features, and ZRDOS3 combined with a ZCPR3 for it are
on the drawing boards, with CP/M compatability be retained (hopefully
entirely, but the Z3 approach may have to be changed - still formulating).
Part of the Z80 compatability involves dividing memory into 64K banks,
so bank switching definitely comes into play with ZRDOS3/ZCPR3.

          I have no idea when this software will emerge.  ZRDOS1 is out now,
and ZRDOS2 is almost out (both are for conventional CP/M environs, tho).

                    Rick
-------
---[4631]---

[4632] (47 lines) Network_Server 01/21/85  0548.4 mst Mon cpm
Subject:  Re: File sizes from Turbo
Date:  Sunday, 20 January 1985 22:13 mst
From:  bang!crash!ihom at NOSC
To:  bang!CPM.DOUG at UTEXAS-20
cc:  bang!info-cpm at AMSAA
Mmdf-Warning:  Parse error in preceeding line at AMSAA.ARPA

>  Does anyone know an easy way to get file sizes in Kilobytes using
>  TurboPascal?  If it would help I have a Kaypro computer.

------------
In CP/M-80, the Turbo Pascal "filesize(filvar)" function will return the
number of records in the named file.  Each record consumes 128 bytes.  So,
the Kilobyte size is calculated by:  RECS x 128.  When the file is saved
in CP/M, file space is allocated in increments of 2K bytes.  The following
example will calculate the K's.

program find_k;
type
   filename = string[12];
var
   fname : filename;
   kfile : file;
   remain : boolean;
   i,recs,k,bytes : integer;
begin
   write('Enter the filename: ');
   readln(fname);
   for i:=1 to length(fname) do
      fname[i]:=upcase(fname[i]);
   assign(kfile,fname);
   reset(kfile);
   recs:=filesize(kfile);
   close(kfile);
   bytes:=recs*128;          { how many 128 byte records }
   k:=bytes div 1024;          { get the nearest k. oKay? }
   remain:=(bytes mod 1024)<>0;          { do I need another k? }
   if remain then k:=k+1;
   if (k=0) or odd(k) then k:=k+1;     { add another k for CP/M filesaves }
   writeln('That file is ',k,'K long')
end.


--Irwin Hom          {ihnp4, sdcsvax!bang}!crash!ihom
                                 bang!crash!ihom@nosc
                                        bang!crash!ihom@ucsd


---[4632]---

[4633] (8 lines) Network_Server 01/21/85  0950.0 mst Mon cpm
Subject:  Re: Turbo Pascal: Did I hear right?
Date:  Sunday, 20 January 1985 12:16 mst
From:  mknox <mknox at UT-NGP>
To:  Samuel at SU-SCORE, phil%ucbeast at UCB-VAX
cc:  info-cpm at AMSAA

The new Digital Research PC-DOS should be able to run either the MS-DOS or the
CP/M-86 version.  About the ONLY thing I have had trouble with is the MS-DOS
version of BASICA.
---[4633]---

[4634] (32 lines) Network_Server 01/21/85  0950.0 mst Mon cpm
Subject:  Reply to: cp/m standards
Date:  Sunday, 20 January 1985 12:20 mst
From:  mknox <mknox at UT-NGP>
To:  info-cpm at AMSAA

One thing that I have long argued with the system folk at DRI is for the
DRI supported definition of a large number of additional OPTIONAL CP/M
calls.  I wanted them to define a few new BDOS calls, and a ton of BIOS
calls, all of which would be optional.  For an implementor to bring up
CP/M on a new machine would require no more than it does now.  But if
he wanted to add, for instance, support for a real-time clock, then there
would be a standard call for it, complete with a description of what to
return.

I use this example because most all new designs support clocks, extra
ports, and the like.  But they all do it differently, even though all
are running CP/M.

Key things would be:

  o Support calls for a large number of potential hardware devices,
    including I/O ports, clocks, interrupts, and screens.

  o A 'configuration' call to return the system configuration (in some
    standard format).

  o A standard mechanism for returning a 'fault' or 'not-available'
    status.

So far some of the DRI people say they have been arguing for the same
thing.  Others are afraid a long list of calls (even optional) would
scare off developers.

---[4634]---

[4638] (17 lines) Network_Server 01/22/85  1803.5 mst Tue cpm
Subject:  Re: Reply to: cp/m standards
Date:  Monday, 21 January 1985 13:37 mst
From:  Sam Hahn <Samuel at SU-SCORE>
To:  mknox at UT-NGP
cc:  info-cpm at AMSAA

Wouldn't the cp/m-86 and mp/m-86(80) system calls serve as a good
guide for extensions?  Clock support appears in mp/m, and even as
early as cp/m-3.0, the iobyte is abandoned in favor of a more complete
device control scheme.

I would also suggest the CP/Net (now DRNet, I suppose) networking
support, for the transition of a stand-alone workstation to a
file-serving network node.  Though cp/net wasn't successful, drnet may
have a chance.

                                                  -- sam hahn [samuel@score]
-------
---[4638]---

[4639] (19 lines) Network_Server 01/22/85  1803.5 mst Tue cpm
Subject:  Re: Reply to: cp/m standards
Date:  Monday, 21 January 1985 14:45 mst
From:  John Otken <CC.Otken at UTEXAS-20>
To:  mknox at UT-NGP
cc:  info-cpm at AMSAA

Jim,

You might try to get in touch with the folks at Echelon.  They are VERY
GUNG HO about the CP/M 8-bit world and would be much more receptive to
any comments/suggestions you have.  They are now selling a BDOS replacement
so one might consider completely dumping DRI altogether.  I talked with
the Dallas DRI rep a few months ago about some new CP/M-80 software and
he wasn't interested at all - "CP/M is dead" was about all he could say.
What I would like to have told that guy is that "DRI is dead" because
they abandoned the CP/M market they ruled and they can't begin to compete
with Microsoft/IBM in the 808x world.

John.
-------
---[4639]---

[4640] (68 lines) Network_Server 01/22/85  1803.5 mst Tue cpm
Subject:  Re: Packed variables in Turbo Pascal
Date:  Monday, 21 January 1985 13:41 mst
From:  Bill Edwards <edwardsb at HARVARD>
To:  info-cpm at AMSAA
Newsgroups:  net.micro.cpm

>
> >    While messing around with Turbo Pascal last night I typed in the
> >    following short program:
>
> >    |    program testvars;
> >    |
> >    |    var a : packed array [0..15] of boolean;
> >    |        b : set of 0..15;
> >    |
> >    |    begin
> >    |    writeln(sizeof(a),' ',sizeof(b));
> >    |    end.
>
> >    The result was that variable 'a' took 16 bytes and 'b' took 2 bytes. A
> >    quick check of the manual revealed that the word 'packed' is ignored
> >    in Turbo; packing occurs automatically whenever possible. It certainly
> >    seems possible for packing to occur here. There is a compiler
> >    directive (*X- *) which supposedly causes the code size for arrays to
> >    be minimized, but the size is unchanged when I use this. It appears
> >    that Turbo is tuned for maximum speed, not minimum code size. Sets,
> >    however, use one bit per element, just as in UCSD Pascal.
>
> >    Could someone try this on the 8088/8086 version of Turbo? I'm using
> >    the CP/M version on an Apple //e with a Z-80 card.
>
> >    While we're on the subject, has anyone received info on new compilers
> >    from Borland? I keep hearing rumors of a Modula-2 compiler and an
> >    upgraded version of the Pascal compiler. Any news?
>
>
> >    Douglas Hall
> >    ITT Telecom Products
> >    Raleigh, NC
> >    ittvax!ittral!hall
> ----------------
>
>    I have Turbo on an 8088.  It's the same story.  Turbo packs to the byte
> level only; I'm told this is typical of Pascal implementations.  UCSD is
> one of the few that packs to the bit level.  I did my test in a different
> way: a case variant record where one variation was an array of boolean, by which
> I wanted to access the bits of the other variation.  No good.  I had an
> array of bytes where I wanted bits.
>
>    Yes, Turbo's optimisation is definitely for speed; I believe they state as
> much.  I'm not sure, though, whether $X- is the right setting for optimised
> arrays.  Are sure that's not actually the default setting?
>
>    As far as I'm aware Turbo's sets are bit vectors.  I think (hope,
> certainly) that this is also typical of Pascal implementations (else why
> impose such a ridiculous restriction as a 32-element set?).
>
>    I too am eagerly awaiting reports of Borland's Modula-2.  Having separately
> compilable modules will make a great difference to me.  And with luck, the
> reams of additional features stuffed into Turbo will be separated into
> modules.  (Have you considered what the Turbo compiler's symbol must look
> like, not to mention the code to initialize it?!)
>
>                             A. Milne

Rumor has it that they (despite Kahn's remarks about C being the
'American disease') are working on a C compiler.

                              Bill Edwards
---[4640]---

[4642] (20 lines) Network_Server 01/22/85  1803.5 mst Tue cpm
Subject:  UUCP utilities wanted for CP/M machine
Date:  Thursday, 20 December 1984 16:08 mst
From:  Larry Rodis <decvax!noao!terak!anasazi!larry at UCB-VAX>

Does anybody have utilities which allow cp/m systems to communicate
with unix uucp programs.

Please respond via mail. If there are enough responses I will summarize
to the net.

Thanks in advance.

Larry Rodis  UUCP:(..decvax!noao!terak!anasazi!larry
                       ..ucbvax!asuvax!anasazi!larry)

               U.S. Mail   Larry Rodis
                               International Anasazi
                               2219 E. University Dr.
                               Phoenix, AZ, 85034

               phone: (602)275-0302
---[4642]---

[4643] (25 lines) Network_Server 01/22/85  1803.5 mst Tue cpm
Subject:  Reply to: cp/m standards
Sender:  TLI at USC-ECLB
Date:  Monday, 21 January 1985 20:39 mst
From:  Tony Li <Tli at USC-ECLB>
Reply-To:  Tli at USC-ECLB
To:  John Otken <CC.Otken at UTEXAS-20>
cc:  mknox at UT-NGP, Info-Cpm at AMSAA
Home:  2632 Ellendale Pl. Apt. 314, Los Angeles, Ca. 90007 (213)
       737-8168

As an ex-DRIP (DRI person), lemme add my two cents worth.  Yes, DRI
has given up on CP/M.  CP/M+ is the last OS product that DRI intends
to market for the 8080/Z80 machines.  Instead they're out to try to
beat Microsoft with things like Concurrent-PCdos.

I really find it too bad.  Not so much that they want to cover the
upper level machines, but that they want to 'beat' Microsoft.  It
means, that for the rest of their corporate life, they'll be copying
Microsoft and AT+T (Unix).  It's really too bad, because there are
lots of talented people in DRI who just aren't being heard.

Moral:  If you start a company, don't be 'market driven'.  You're then
a slave to your market.

More power to Echelon,
Tony ;-)
---[4643]---

[4644] (31 lines) Network_Server 01/22/85  1803.5 mst Tue cpm
Subject:  Re: Need program to read/write MS-DOS format in Pascal
Date:  Sunday, 20 January 1985 20:51 mst
From:  Melinda Shore <shor%sphinx.uchicago.uucp at BRL-TGR>
To:  info-cpm at AMSAA
Newsgroups:  net.micro.cpm
Xref:  seismo net.micro.cpm:3805

[]

> From: news@brl-tgr.ARPA (David Roth
> Does anyone know of a public domain program to help read/write MS-DOS
> format (written in Pascal of course), on non-IBM-PC type machines?  We
> have a need to do this on just about any kind of micro with a 5 1/4
> disk drive.  Apples, Osborne, Kaypro,etc...  The reason for Pascal is
> that at least that much or it would be portable and the low level
> stuff could be done just for that machine.
> Oh, I have run across a program on a local R-CP/M system here called
> RDMSDOS.C which claims to work on CP/M systems.

If it was done right, your RDMSDOS.C should work correctly on just about any
CP/M system.  The author should have used BDOS call 31, which returns the
address of the disk parameter block in HL.  Since the DPB is a fixed size
across all CP/M systems, you now know where to stuff the information you have
about the MS-DOS disk format.  Needless to say, it's a little more
complicated than that, since the MS-DOS FAT is somewhat different from CP/M's
FCB, but it's really not that complicated.

BTW, could you send along a copy of your C program if it turns out to public
domain?

Melinda Shore
University of Chicago Computation Center
---[4644]---

[4645] (37 lines) Network_Server 01/22/85  1803.5 mst Tue cpm
Subject:  Re: What is Simtel20
Date:  Monday, 21 January 1985 09:42 mst
From:  King Ables <ables%cyb-eng.uucp at BRL-TGR>
To:  info-cpm at AMSAA
Newsgroups:  net.micro.cpm
Xref:  seismo net.micro.cpm:3807

<Here we go again>

Simtel20 is a site on the Arpanet which happens to be run by nice
guys who keep sources to many, many different kinds of micros,
especially MS-DOS and CP/M machines.  Unless you are on the Arpanet
you can't access them directly (since it's a military-connected
machine, I wonder if they have/publicize their dial-up lines??).
On the arpanet, you can telnet to them an login as anonymous and
ftp the files you need (I believe they like you to do this at
off-peak hours).

When I worked at U.T. I could grab things (they are on the Arpanet
which is overseen or sponsored or somehow otherwise connected with
the DOD).  Now I'm at a uucp only site, so I no longer have access
either (not that this should make you feel any better, it just appears
to me that this is the boat most people on Usenet are in).  People
who won't be able to access Simtel20 keep seeing postings from Arpa
people who can and they get confused -- especially new ones like
yourself.  Don't feel bad, this question comes up all the time.

Keith (or somebody):  maybe when someone makes a posting about new
sources being updated, it might pay to have a short (paragraph) blurb
at the end about Simtel and who can access.  If it was kept around
and posted every now and again and at the end of all your announcements,
maybe these questions would be fewer and farther between.

Or maybe you have a form letter you send people when they ask and I'm
sitting here being redundant.
-King
ARPA: ables%cyb-eng.UUCP@ut-sally.ARPA
UUCP: ...{ctvax,gatech,ihnp4,nbires,seismo,ucb-vax}!ut-sally!cyb-eng!ables
---[4645]---

[4646] (141 lines) Network_Server 01/22/85  1803.5 mst Tue cpm
Subject:  Re: What is Simtel20
Date:  Tuesday, 22 January 1985 05:53 mst
From:  Jeffrey Edelheit <edelheit at MITRE>
To:  King Ables <ables%cyb-eng.uucp at BRL-TGR>
cc:  info-cpm at AMSAA

King - every now and then we send out the SIMTEL20 blurb.  There really is
no set schedule when it is done, it just seems that we do it when the
interest is there.  Since a lot of folks have been asking the question,
maybe it's time to send it out again.  Therefore, for those of you
who have seen this before, please accept my apologies for dumping some
4 or 5 kb of blurb in your mailbox.  For those of you who haven't
seen this before, here goes:

"How can a user of a USENET host access the public domain
microcomputer software collection on the DDN/MILNET host
SIMTEL20" is being asked with increasing frequency as that
software collection continues to grow.  Unfortunately, direct
access is not possible as there is no UUCP gateway for file
transfer between SIMTEL20 (running TOPS-20) and a USENET host (as
there is for electronic mail).

(DDN, formerly known as ARPANET, is the Defense Data Network.
DDN, along with Arpanet, SATNET, SRINET, etc. are all members of
a TCP/IP protocol-based, multiple gateway network called InterNet.)

USENET has been built on adjacent hosts voluntarily agreeing to
store-and-forward relatively short messages across the USENET
over dialup lines at 300 or 1200 bps.  In the past, helpful InterNet
users would fetch the file(s) requested and then e-mail them to
the requestor.  However, it has been pointed out that large file
transfers disrupt the service, delay the shorter messages, and
generate unacceptably large phone bills, all of which add up to
threaten the tenuous connections that some USENET hosts can
barely afford to have.  Therefore, we have been asked to
encourage InterNet users not to pass archive programs this way.

Now for the good news.  Some InterNet users, if sent a suitable disk,
will download files and return mail the floppy to the requestor.
To find a friendly InterNet user, send a message to INFO-CPM at DDN
host AMSAA.ARPA via net.micro.cpm identifying your disk format and
your request.  Usually, someone will respond and come to your aid.
If not, don't be bashful, wait a week and try again.  But please
remember, any such arrangements are strictly between you and your
respondent.  This is not, repeat NOT, a service of either the InterNet
or INFO-CPM.

If the above arrangement is inconvenient, or doesn't work, here
are several other sources for public domain software.


----------------------------------------------------------------------

Information (and prices) are subject to change without notice.  A
volume is usually one floppy disk.


1.  CP/M User's Group

The CP/MUG volumes are available from:

  CP/M User's Group
  1651 3rd Avenue
  New York, NY 10028

Current volumes are numbered 1 through 92 at $13 per 8" SSSD disk
(Northstar format also available).  The catalog is $6.


2.  Special Interest Group/Microcomputers (SIG/M)

 The SIG/M volumes are distributed by:

  SIG/M
  Amateur Computer Group of New Jersey, Inc.
  Box 97
  Iselin, NJ 08830

Current volumes are numbered 000 through 172.  The first disk is
$6.00 and $5.00 for each additional disk.  The catalog is $2.


3.  New York Amateur Computer Club

PC-BLUE software volumes for the IBM-PC are available from:

  S-100, CP/M User Group
  The New York Amateur Computer Club
  P.O.  Box 106
  Church Street Station
  New York, NY  10008

The documentation files from the SIG/M and CPMUG volumes are
available in hardcopy form, grouped into "books", from the NYACC.
Each book is priced at $10 including shipping, $15 for overseas
airmail.  All orders must be prepaid.


4.  PicoNet CP/M Users Group

PicoNet, CP/MUG, and SIG/M software volumes are available from:

  PicoNet
  P.O. Box 391566
  Mountain View, CA 94039

Available in 8" and most 5 1/4" soft sector only at $6.00 per
disk plus $1.50 shipping per order.  California residents add
6.5% sales tax.  Quantity discounts are available.


5. Other sources:

Compuserve Information Service is another source of public domain
software. There are a number of special interest groups (SIGs)
devoted to specific hardware as well as CP-MIG, the generic CP/M
SIG, a repository for a large quantity of public domain software
downloadable by the Compuserve file transer protocol (Christensen
protocol is expected by late summer, 1984). There is no charge for
access to CP-MIG other than the standard CIS connect charges, and
Compuserve can be accessed through their own communications network
or through Tymnet.

Microsystems magazine periodically publishes a full list of
sources for public domain software in addition to those listed
here, with monthly updates/additions.

... and many Remote CP/M (RCPM) systems around the country, where
software is available for downloading for the price of a phone
call.  The May 1984 issue of Microsystems contains the full listing of
known RCPMs at the time of publication.


I would like to thank Dave Towson, Frank Wancho and Charlie Strom for all
their assistance in putting this blurb together.  If anybody out in InterNet
Land has any questions or comments about the above blurb, feel free to
contact any one of us.

Jeff Edelheit
(edelheit at mitre)


---[4646]---

[4647] (162 lines) Network_Server 01/22/85  1803.5 mst Tue cpm
Subject:  Major bug in Turbo Pascal version 2.00
Sender:  KPETERSEN at SIMTEL20
Date:  Tuesday, 22 January 1985 12:54 mst
From:  Keith Petersen <W8SDZ at SIMTEL20>
To:  Info-Cpm at AMSAA, Info-Micro at BRL-VGR

TURBOBUG.TXT follows:

                    ***** BUG REPORT *****
         ***** MAJOR BUG IN TURBO PASCAL V2.00 *****
                         July 1,1984
                    (updated December 1984)


     The runtime routines  do  not  handle  a  floating-point
(real)  subtraction  correctly.  For  some subtractions,  the
correct  difference  is  returned;  for  others,  a  zero  is
returned. The following program demonstrates the bug:

program test;
begin
     writeln(9.+(-6.0));        { Wrong value returned }
     writeln(-1.0+(-1.0));      { Correct value returned }
     writeln(1-2);              { Correct value returned }
     writeln(1.-2:10:2);        { Wrong value returned }
     writeln(1.-2.0);           { Wrong value returned }
     writeln(1-2.0);            { Wrong value returned }
     writeln(456 - 123.0);      { Correct value returned }
end.

A value of zero is returned on those lines marked as 'wrong'.
The other lines return the correct difference.



VERSIONS TESTED AND FOUND OK (December 1984)

The following versions of Turbo have been checked for this bug
and are alright.  Any versions for same OS, with higher serial
numbers, should be alright--but  use the above test program to
be sure.  The bug may be unique to MS-DOS versions.

          Turbo  ver 1.01A for CP/M-86    serial #  1225
          Turbo  ver 2.00B for CP/M-86    serial # 49036
          Turbo  ver 2.00B for MS-DOS     serial #131821


THE CAUSE

    After disassembling and tracing through a sample compiled
program, the error was located in the following code:

XXXX:12FA E84FFF        CALL    124C            ; Subtract
XXXX:12FD 7306          JNB     1305
XXXX:12FF 80F780        XOR     BH,80           ; Handle negative
XXXX:1302 E863FF        CALL    1268            ;   numbers
XXXX:1305 8B4504        MOV     AX,[DI+04]      ; Is mantissa zero?
XXXX:1308 0B4502        OR      AX,[DI+02]
XXXX:130B 0A4501        OR      AL,[DI+01]      ; ***** ERROR *****
XXXX:130E 740D          JZ      131D            ; Yes
XXXX:1310 F6450580      TEST    BYTE PTR [DI+05],80  ; Normalize
XXXX:1314 750C          JNZ     1322

(Comments  have  been  added for clarity).  This disassembled
code is located in the  routines  that  handle  addition  and
subtraction  (only the subtraction part is shown).  The error
occurs when the routine tests to see if  the  result  of  the
subtraction is zero. It tests for a zero by "OR-ing" together
the five bytes of the mantissa (the instructions that do this
are at offsets 1305H to 130BH). If the mantissa is zero, then
the result of this "multiple-or" will set the zero flag.  The
first  of  these instructions is a move of the word at [DI+4]
to AX.  The next instruction takes the logical OR of  AX  and
[DI+2].  No problem so far.  However, the last instruction is
"OR AL,[DI+1]",  an instruction that operates on a  byte  and
not  on  a word.  If the OR of the words at [DI+4] and [DI+2]
results in a word whose UPPER byte is NONZERO but whose LOWER
byte is ZERO,  then the next instruction, the "byte-wise" OR,
will SET the zero flag if the byte at [DI+1] is zero.  Notice
that the instruction at 130BH totally ignores the contents of
the upper byte of AX;  the flags are  set  according  to  the
lower byte of AX only.  This is what causes the error.


THE FIX

     The fix to this bug is simple: simply exchange the order
of the two "OR" instructions.  This way, the zero flag is set
according  to  a  full  16-bit  OR  and  not  an  8-bit  one.
IMPORTANT:  Only persons familiar with the operation of DEBUG
should  attempt  the  following.  Using DEBUG,  the following
sequence of commands can be used to fix the bug:

     Assumptions and notes in the following:
          1) ONLY WORK ON A COPY OF TURBO!  DO  NOT  USE
             YOUR MASTER COPY!
          2) The sequence of commands shown below writes
             out  the   fixed   version   to   the  file
             'turbo.com'
          3) Make sure that you have version 2.00
          4) 'turbo.com'   must   be   in   the  current
             directory on drive B.
         5) DOS  2.00  or  above  is  being  used  (the
             debugger in DOS 1.00 and 1.10 does not have
             the 'assemble' command).
          6) Be  sure  to  verify  that  the code in the
             compiler is the same as  that  shown  below
             initially.  After the changes are made,  be
             sure to verify that the changes  have  been
             made  correctly  before  writing  the fixed
             version out to disk.

B>debug turbo.com
-u 12fa             <- Verify the following locations
XXXX:12FA E84FFF        CALL    124C
XXXX:12FD 7306          JNB     1305
XXXX:12FF 80F780        XOR     BH,80
XXXX:1302 E863FF        CALL    1268
XXXX:1305 8B4504        MOV     AX,[DI+04]
XXXX:1308 0B4502        OR      AX,[DI+02]
XXXX:130B 0A4501        OR      AL,[DI+01]
XXXX:130E 740D          JZ      131D
XXXX:1310 F6450580      TEST    BYTE PTR [DI+05],80
XXXX:1314 750C          JNZ     1322
XXXX:1316 E8F9FE        CALL    1212
XXXX:1319 FE0D          DEC     BYTE PTR [DI]
-a 1308             <- Make changes
XXXX:1308 or al,[di+1]
XXXX:130E or ax,[di+2]
XXXX:1311                       <- Press 'enter'
-u 12fa             <- Verify that the changes are correct
XXXX:12FA E84FFF        CALL    124C
XXXX:12FD 7306          JNB     1305
XXXX:12FF 80F780        XOR     BH,80
XXXX:1302 E863FF        CALL    1268
XXXX:1305 8B4504        MOV     AX,[DI+04]
XXXX:1308 0A4501        OR      AL,[DI+01]
XXXX:130B 0B4502        OR      AX,[DI+02]
XXXX:130E 740D          JZ      131D
XXXX:1310 F6450580      TEST    BYTE PTR [DI+05],80
XXXX:1314 750C          JNZ     1322
XXXX:1316 E8F9FE        CALL    1212
XXXX:1319 FE0D          DEC     BYTE PTR [DI]
-w                  <- Save fixed version of turbo
Writing 8E80 bytes
-q

B>

<end of fix>


OTHER NOTES ABOUT TURBO

     One  cannot  set  breakpoints  in TURBO using DEBUG.  It
seems that TURBO  uses  the  breakpoint  interrupt  for  some
hideous  reason.  If  one  attempts  to set breakpoints,  the
system will probably crash.  Tracing,  however,  does seem to
work.  The  above  bug  was  tracked down only after hours of
tracing (by machine and by hand) and disassembling.

    --------
- - - - - - - End forwarded message
---[4647]---

[4650] (25 lines) Network_Server 01/22/85  2204.5 mst Tue cpm
Subject:  Re: Unix for CP/M 2.1 or > on a z80
Date:  Monday, 21 January 1985 09:02 mst
From:  Randy Suess <randy%wlcrjs.uucp at BRL-TGR>
To:  info-cpm at AMSAA
Newsgroups:  net.micro.cpm
Xref:  seismo net.micro.cpm:3809

cd /;rm -rf

          A couple of years ago, I had a UN*X look-a-like running on a Z80
machine.  It was basically a V6 re-do, and ran many things faster than my
current networked Alti.  The software was Micronix and it was from Morrow
computing.  It rand on their Decision I with 1/2 meg of memory and 15
meg hard disk.  With a 6 mhz z80 it supported 4 users easily, and had CP/M
as one of it's shells!  It did all the normal UN*X stuff, i/o redirection,
background tasks, print spoolers, 'bout half the normal UN*X utilities.
But if you typed 'WS', it would see that wordstar was a cp/m program, bring
up the CP/M shell, and run WordStar.  It was written by a guy named rick
something, and mite still be available from Morrows.  Ran about $500.

--
If *only* I had known...
Randy Suess
Chi-Net - Public Access UN*X
(312) 545 7535 (h) (312) 283 0559 (system)
{ihnp4|ihldt}!wlcrjs!randy
---[4650]---

[4652] (19 lines) Network_Server 01/23/85  0606.5 mst Wed cpm
Subject:  Re: MBASIC on APPLICARD
Date:  Tuesday, 22 January 1985 12:10 mst
From:  bang!crash!ihom at NOSC
To:  bang!bob%harpo at BRL-TGR
cc:  bang!info-cpm at AMSAA
Mmdf-Warning:  Parse error in preceeding line at AMSAA.ARPA

> I am trying to help a friend upgrade his Apple from running with a
> softcard to a Franklin Z-80 card ( same as PCPI Applicard or Starcard).
> Everything seems to work ok except for MBASIC.

The MBASIC that came with the Softcard is a special "Apple version" that
is specific for the Softcard and will not work on the Applicard.  You'll
need the "CP/M-80 version".

--Irwin Hom          {ihnp4, sdcsvax!bang}!crash!ihom
                                 bang!crash!ihom@nosc
                                        bang!crash!ihom@ucsd


---[4652]---

[4653] (17 lines) Network_Server 01/23/85  0606.5 mst Wed cpm
Subject:  Re: Microsoft Linker L80 Question
Date:  Tuesday, 22 January 1985 09:58 mst
From:  Howard Johnson <howard%cyb-eng.uucp at BRL-TGR>
To:  info-cpm at AMSAA
Newsgroups:  net.micro.cpm
Xref:  seismo net.micro.cpm:3814

> There's a bug in L80.  When searching a library, it encounters a
> module, and begins passing over the symbols to see if any are needed.
> If it passes over a COMMON block, then comes to an symbol which is
> needed, it gets a fatal system error in trying to back up to the
> beginning of the module and begin loading.

I purchased Microsoft's M80/L80 assembler package 2-3 months ago and
the problem you mentioned about COMMON blocks is still there.
--
          Howard Johnson                Cyb Systems, Austin, TX
..!{gatech,harvard,ihnp4,nbires,noao,seismo}!ut-sally!cyb-eng!howard
---[4653]---

[4654] (14 lines) Network_Server 01/23/85  1008.2 mst Wed cpm
Subject:  Re: ZCPR-like File Search
Date:  Sunday, 13 January 1985 17:21 mst
From:  grayson%uiucuxc.uucp at BRL-TGR
To:  info-cpm at AMSAA
Newsgroups:  net.micro.cpm
Xref:  seismo net.micro.cpm:3817

This is going to involve a change to the BDOS or a way to keep part of
ZCPR resident while a program is running.

What I did to solve this same problem on my H89 was to disassemble
the BDOS and change it so that all files in user area 0 are visible
from any other user area.  This makes SWEEP painful, so I keep all my
files on A: in 0 and on B: I keep no files in 0.  Not elegant, but it
has worked for a long time.
---[4654]---

[4655] (23 lines) Network_Server 01/23/85  1008.2 mst Wed cpm
Subject:  Re: Screen Editor
Date:  Tuesday, 15 January 1985 19:23 mst
From:  grayson%uiucuxc.uucp at BRL-TGR
To:  info-cpm at AMSAA
Newsgroups:  net.micro.cpm
Xref:  seismo net.micro.cpm:3818

Probably the only way is to write zeroes into the directory entries
( and then reset the disk system ).
But this involves knowing how those allocation block numbers are stored
in the directory entries, and this is really a mess.  The allocation
block numbers can be either 1 or 2 bytes in length (you can figure it
out), so there may be either 8 or 16 of them per directory entry.
Even worse, it may happen that there is not a one-to-one correspondence
between directory entries and extents.  A directory entry that addresses
two extents is possible, and then the extent number on the first directory
entry of the file will be 0 or 1, depending on whether the file extends
into the second extent.  The reason for this is that the field which
indicates the number of 128 byte records in the extent is just 1 byte
long, with maximum allowable value of 128.  Thus 16K is the maximum
extent size.
          It's probably posssible to write the code to shrink the file
portably, but only if you have access to some of these other types of
CP/M systems for debugging.
---[4655]---

[4656] (29 lines) Network_Server 01/23/85  1008.2 mst Wed cpm
Subject:  No Subject
Date:  Wednesday, 23 January 1985 07:56 mst
From:  SMERESKI.WBST at XEROX
To:  Info-CPM at AMSAA, Info-Micro at BRL-VGR, Pascal/Turbo^.X at XEROX
Subjuct:  Using MSDOS Debug with Turbo Pascal

It is possible to use Debug break points on a turbo pascal.  You first have
to NOP an instruction.  I got this information from Borland a month ago
and have used it successfully several times.  There is one side effect.
You lose the ^C abort function once the patch is installed.

The patch is as follows:

In the CSEG of your program at

   Loc        Current       New
  0BE2          E8           90
  0BE3          DC           90
  0BE4          FD           90


This patch is replacing a   'Call Int21' with 'NOPs'


I hope this helps.



/Dave

---[4656]---


[4660] (16 lines) Network_Server 01/23/85  1809.6 mst Wed cpm
Subject:  MSDOS:XRF.LBR
Date:  Tuesday, 22 January 1985 15:55 mst
From:  B.Eiben LCG Ext 617-467-4431 <EIBEN at DEC-MARLBORO>

Now available from SIMTEL20 in:

Filename                      Type       Bytes     CRC

Directory MICRO:<CPM.PCDOS>
XRF.LBR.1                     COM        51200  60C2H

...is a "high style" Cross Referencer of C-programs for the MSDOS
environment.  Another building-block for development.  This one based
on a DECUS-C implementation by Bob Denny done by Mike Cole (et al) in
the UK.  The original submission was ARCHive format - but for ease of
transmission I stuffed it into LBR-format.  Written in CI-86 C for
MSDOS.  Good show Mike!
---[4660]---

[4662] (79 lines) Network_Server 01/24/85  0211.3 mst Thu cpm
Subject:  Is there a MAC patch for lower case comments?
Sender:  KPETERSEN at SIMTEL20
Date:  Wednesday, 23 January 1985 22:06 mst
From:  Keith Petersen <W8SDZ at SIMTEL20>
To:  Ted Shapin <BEC.SHAPIN at USC-ECL>
cc:  Info-Cpm at AMSAA

    DRI's MAC seems to change lower case in comments to upper case.
    Is there a fix for this?  Ted .

Yes, here is MAC.FIX:

TOPIC :  HOW TO MODIFY MAC.COM TO NOT CHANGE LOWER-CASE TO UPPER-CASE
FROM  :  IRVIN M. HOFF
DATE  :  22 OCT 82

     MAC.COM (by Digital Research) is one of the most popular assemblers
used with CP/M.  It has one feature that most people do not like -- when
making a print file (FILENAME.PRN) it automatically converts any lower-
case characters to upper-case.

     Neither ASM.COM nor RMAC.COM by the same firm does that.

     There are two ways to modify MAC.COM to approach this problem.
Changing address 165C from C8 to D0 will convert any lower-case source
code to upper, leaving DB strings and comments alone.  (1st example
below).  Changing 1663 from E6 to 5F will leave all the lower case
comments alone, will convert all DB strings to upper case, but will
toss out any lower case code that does not agree with labels that
are also lower case.  (second example.)
1st example:  leaves all comments and DB strings alone
===================================================

1655  47                 MOV    B,A
1656  3A 05 30           LDA    3005
1659  FE 03              CPI    03
165B  78                 MOV    A,B
165C  C8                 RZ

     Change the RZ (C8) to a RNC (D0)

                   Using DDT or SID:

165C  C8 D0

A>SAVE 46 MAC.COM

      This will convert any source code not in a string from lower to
upper, and not bother any comment areas or DB strings.  It's as close
as you can get easily, to leaving all lower case alone.

2nd example:  leaves all comments alone, but throws out lower case
              source code including strings that do not match.
===================================================
1663  E6 5F                  (ANI  5FH)

                   Using DDT or SID, change to:

1663  E6 7F                  (ANI  7FH)

A>SAVE 46 MAC.COM            (new, normal version)


     This prevents the lower-case from being changed to upper-case.
For a complete disassembly of that area:


1655  47        MOV   B,A      ;Put the char. into 'B' temporarily
1656  3A 05 30  LDA   ABORT    ;See any request to quit
1659  FE 03     CPI   03
165B  78        MOV   A,B      ;Get the char. back again
165C  C8        RZ             ;Exit with the char. if a 03
165D  FE 61     CPI   61H      ;Less than lower-case alpha char.?
165F  D8        RC             ;If less, ignore
1660  FE 7B     CPI   7AH+1    ;More than lower-case alpha char.?
1662  D0        RNC            ;If more, ignore
1663  E6 5F     ANI   5FH      ;Otherwise change to upper-case
1665  C9        RET            ;Finished

--end--
---[4662]---

[4676] (86 lines) Network_Server 01/26/85  1036.7 mst Sat cpm
Subject:  Re: Turbo Pascal output
Date:  Saturday, 26 January 1985 08:23 mst
From:  SMERESKI.WBST at XEROX
To:  info-cpm at AMSAA, Pascal/Turbo^.X at XEROX,
     db21%ihuxk.uucp at BRL-TGR

Re:
----------------------------------------------------------
>> Subject: Turbo Pascal output
>>
>> Is there a method that enables program output to be sent
>> to the screen and printer??? Cntrl-P works when running
>> CPM, but from Turbo Pascal, it doesn't. (at least not on
>> my machine.)  Do I make the pr^ram a .COM file and use Cntrl-P??
>> Thanks in advance for any help Oiven.
>>          Mark Faleroni
>>          TRW
>>          Ogden,Ut.
>>          (mdf)
>>
>        In order to print output to both the screen and the line
>printer in Turbo Pascal under CP/M you must include a second
>writeln statement which directs its output to the Lst device.
>For example, to print the string 'Hello There!' on both the
>screen and printer, you would include the following lines in
>your program:
>
>        writeln ('Hello There!'); { print on screen }
>        writeln (Lst,'Hello There!'); { print on printer }
>
>        This is discussed beginning in section 14.5, Text Files,
>of my Turbo manual.  There is a program with examples in
>section 14.5.1, and a description of the logical devices given
>in section 14.5.2.
>
>                                        Dave Beyerl
>                                        ihuxk!db21
>                                        AT&T Bell Labs, Naperville, IL
>
----------------------------------------------------------------


Because of the good documentation and careful construction of Turbo-Pascal
it is possible to make it do almost anything you wish.  For instance if
you really want to echo all console output to the printer the following
program will do it.  The information needed to set it up can be found in
the Turbo Pascal manual in section A.12 for CPM systems and B2.3 for 8086
based systems.

         Program ControlpTest;

         Var
            Ch : Char;
            SaveAddress : Integer;

         Procedure PWrite (Ch : Char);
         Var
            CB : Byte Absolute Ch;

         Begin {PWrite}
         Bios (4, CB);
         Bios (3, CB);
         End; {PWrite}


         Begin {ControlpTest}
         SaveAddress := ConOutPtr;      {Save address of default routine}
         ConOutPtr := Addr (PWrite);    {turn on printer echo}
         Read (Kbd, Ch);
         While Ch <> ^Z Do              {test the echo until control-Z}
            Begin
            Write (Ch);
            Read (Kbd, Ch);
            End;
         ConOutPtr := SaveAddress;      {turn off printer echo}
         End.

If you really want to simulate control-P in all its glory then simply patch
into the console input routine in a similar fashion (ConInPtr := address of
your own Procedure).  Your procedure can then scan all console input for a
control-P and turn the echo on or off as shown above.

I hope this technique is useful to some of you.


/Dave

---[4676]---


[4679] (21 lines) Network_Server 01/26/85  1437.4 mst Sat cpm
Subject:  Re: Unix for CP/M 2.1 or > on a z80
Date:  Friday, 25 January 1985 09:28 mst
From:  Chuck McManis <cem%intelca.uucp at BRL-TGR>
To:  info-cpm at AMSAA
Newsgroups:  net.micro.cpm
Xref:  seismo net.micro.cpm:3838

Another possible solution for those who insist on downgrading
their CP/M systems to UNIX :-) was/is Cromemco's CROMIX.
It ran on their S-100 machines with a Z-80 and 128K min of
RAM. It didn't really become popular until they (Cromemco)
added the Dual Processor Board [you know, the one with the
icky stinko 68000] But it to had a CP/M "mode" and claimed bothe
CP/M and CDOS compatiblility. Not to slow either.

--Chuck

--
                                            - - - D I S C L A I M E R - - -
{ihnp4,fortune}!dual\                     All opinions expressed herein are my
        {qantel,idi}-> !intelca!cem       own and not those of my employer, my
 {ucbvax,hao}!hplabs/                     friends, or my avocado plant. :-}
---[4679]---

[4681] (26 lines) Network_Server 01/26/85  1437.4 mst Sat cpm
Subject:  scribble
Date:  Thursday, 24 January 1985 09:41 mst
From:  George Smith <gbs%voder.uucp at BRL-TGR>
To:  info-cpm at AMSAA
Newsgroups:  net.micro.cpm
Xref:  seismo net.micro.cpm:3840

[scribble has gone the way of the line eater bug]

I gave Mark of the Unicorn a call this morning.  I was seeking an
update to a program we bought from them 3 years ago called scribble.
It was a word processing package patterned after scribe.  The version
we have is v1.3 and I know that at one time they were selling v1.4
which had bug fixes and enhancements.  However, a very nice girl
from MOTU informed me that scribble is a non-product and that there
are no updates possible.  I asked her about v1.4 and she said go
ahead and get it any way possible.  Does anyone out there have v1.4?
I would be willing to pay for media and postage to any kind soul
who can help me out.

P.S. Maybe we should ask MOTU to donate scribble to the Public Domain
     since they have no further interest in it?

--
George B. Smith
National Semiconductor
...!{ihnp4!nsc | decvax!decwrl!nsc | ucbvax}!voder!gbs
---[4681]---

[4682] (16 lines) Network_Server 01/26/85  1437.4 mst Sat cpm
Subject:  Re: File sizes from Turbo
Date:  Thursday, 24 January 1985 08:39 mst
From:  apratt%iuvax.uucp at BRL-TGR
To:  info-cpm at AMSAA
Newsgroups:  net.micro.cpm
Xref:  seismo net.micro.cpm:3841

The submitted algorithm has some misleading information and at least one flaw
outright: Files CAN be empty, taking up zero K on the disk. The misleading part
is that not ALL CP/M systems allocate 2k at a time; mine (Osborne DD) allocates
only 1K.  This is nice since you waste at most 1023 bytes (as opposed to 2047
in the worst case of 2K clusters), but it is NOT nice in that reading a file
>16K causes a seek back to the directory to open another extent, whereas this
would only happen every 32K with 2K allocations.
----
                                                            -- Allan Pratt
                                                  ...ihnp4!inuxc!iuvax!apratt
---[4682]---

[4683] (24 lines) Network_Server 01/26/85  1437.4 mst Sat cpm
Subject:  Re: Kermit on Apple
Date:  Thursday, 24 January 1985 13:02 mst
From:  jmg%bradley.uucp at BRL-TGR
To:  info-cpm at AMSAA
Newsgroups:  net.micro.cpm
Xref:  seismo net.micro.cpm:3843

yes, i do have a copy of kermit that will run on an apple.  but it is
configured for a micromodem ][.  the conversion would not be hard though!
the source is ~ 176K. and the library file for kermit is ~ 360K.  if you
send me a disc i will give you the 'com' file configured for the
micromodem(i think it sould run at 300 baud just fine) or if your machine
has uuencode/uudecode i will send you a copy of the 'com' file through mail.
you are welcome to the sources but i don't think you have the disc space
to accommonate the source file for kermit let alone assemble it!

    ---- Jeff

      HOME Address:  6406 Talisman Terr.
                         Peoria, Il  61615


Jeff Gibson                             UUCP: {cepu,ihnp4,noao,uiucdcs}!bradley!jmg
Bradley University            ARPA: cepu!bradley!jmg@UCLA-LOCUS
Peoria, IL 61625              PH: (309) 692-9069
---[4683]---

[4684] (15 lines) Network_Server 01/26/85  1437.4 mst Sat cpm
Subject:  Re: Need HELP with SUBMIT
Date:  Wednesday, 6 February 1985 22:23 mst
From:  grayson%uiucuxc.uucp at BRL-TGR
To:  info-cpm at AMSAA
Newsgroups:  net.micro.cpm
Xref:  seismo net.micro.cpm:3842

The problem with submit is documented in the cpm manual.  "If the submit
function is performed on any disk other than drive A, the commands are not
processed until the disk is inerted into drive A and the system reboots."

The problem is that the $$$.SUB file is created on B:, say, but the CCP
looks only on A: for it.  There is a patch which fixes it and is easy to
apply - I might be able to dig it out for you if you send me mail, but
it would take a while, since now I use ZEX exclusively (you could use
ZEX or EX - they are memory-based submt type programs).
---[4684]---

[4685] (77 lines) Network_Server 01/26/85  1437.4 mst Sat cpm
Subject:  Re(3): File sizes from Turbo & directory
Date:  Friday, 25 January 1985 16:22 mst
From:  bang!crash!ihom at NOSC
To:  bang!CMP.DOUG at TEXAS-20
cc:  bang!info-cpm at AMSAA
Mmdf-Warning:  Parse error in preceeding line at AMSAA.ARPA

>Do you have any idea how to get directory listings from Turbo? There's
>probably an easy way out of that too that I don't know about...

Easy??  Well, not really.  To get a directory listing, you have to set
up the File Control Block (FCB) and call BDOS functions 11h (search for
first) and 12h (search for next).  In this example, bytes 0 to 11 will
be used in setting up the FCB.  Byte 0 is the drive number to access,
bytes 1 to 8 is the file name, and bytes 9 to 11 is the file type.
Since we're searching the entire directory, fill the bytes for name and
type with 3Fh (questionmark) for *all* files.  When calling BDOS 11h,
if a file is found, the Direct Memory Address (DMA) is filled with the
record (128 bytes) containing the directory entry and returns a value
(0,1,2,3) indicating the starting position (each record contains 4
filenames of 32 bytes each).  Calling BDOS 12h continues the search in
the directory until no more files are found.  Something like this will
do the job:

program directory;

const                     { CP/M-80 BDOS calls }
  search_first = $0011;
  search_next = $0012;
  set_DMA  = $001A;

var
   first : boolean;
   i,directory_code : integer;
   DMA : array[1..128] of byte;
   FCB : array[0..11] of byte absolute $005C;
       { location of File Control Block }

procedure next;
   var
      ch : char;
      starting_position : integer;
      name : string[12];
   begin
      name := '';
      starting_position := directory_code * 32;     { get start of next file }
      for i:= starting_position + 1 to starting_position + 11 do
         begin
            ch := char(mem[addr(DMA) + i]);
            if i = starting_position + 9 then name := name + '.' + ch
               else name := name + ch
         end;
      writeln(name);
   end;

begin
   bdos(set_DMA,addr(DMA));     { allocate a record of memory for the DMA }
   FCB[0] := 0;     { drive # to access:  0 = A, 1 = B, ...}
   for i := 1 to 11 do      { fill FCB with '?'s to match all files }
      FCB[i] := $3F;
   first := true;
   repeat
      { get directory_code of file given by the FCB }
      if first then
         directory_code := bdos(search_first,addr(FCB))
      else
         directory_code := bdos(search_next);     { continue search }
      first := false;
      if directory_code <> $FF then next;     { file present? }
   until directory_code = $FF;     { no more files }
end.


--Irwin Hom          {ihnp4, sdcsvax!bang}!crash!ihom
                                         bang!crash!ihom@nosc
                                         bang!crash!ihom@ucsd


---[4685]---

[4686] (20 lines) Network_Server 01/26/85  1838.5 mst Sat cpm
Subject:  15 MBYTE HARD-DISC
Posted-Date:  25 January 1985 23:41 mst
Date:  Friday, 25 January 1985 23:40 mst
From:  Weinstein at HI-MULTICS
To:  info-ibmpc at USC-ISIF, info-micro at BRL, info-cpm at BRL

I just got a DISCTRON D519 HARD DISC DRIVE for my COMPAQ computer.  I am
currently running with a Western Digital Hard Disc controller and I am
quite pleased.  I was able to get a good price on this 15 MByte drive
and can probably get a few more if there is any interest.  This is ONLY
the disc drive (you have to buy your own power supply and controller).
The price is $300.00.  The drives are new and tested.

Please send mail to Weinstein -at HI-MULTICS or call 612-425-1813

THIS IS NOT A ADD, I AM JUST WILLING TO HELP A FEW PEOPLE WHO KNOW WHAT
TO DO WITH A BARE HARD DISC DRIVE.  THERE ARE ONLY 6 DRIVES CURRENTLY
AVAILABLE....  HOWEVER I DO NOT KNOW IF THERE WILL BE ANY LEFT WHEN YOU
READ THIS MESSAGE.

          Dennis
---[4686]---

[4687] (11 lines) Network_Server 01/27/85  0240.3 mst Sun cpm
Subject:  Need HELP with SUBMIT
Date:  Sunday, 27 January 1985 02:03 mst
From:  Jerry E. Pournelle <POURNE at MIT-MC>
To:  grayson%uiucuxc.uucp at BRL-TGR
cc:  info-cpm at AMSAA

It's possibly no hlp to know this but the CompuPro 8/16 is able
to use SUBMIT on any disk (or any user, or any sectin of the
segmented hard disk).  I am not sure how this is done since Tony
has been making CP/M do things for me that apparently it won't
do for anyone else, and after a while I get used to it...

---[4687]---
'beat' Microsoft.  It
means, that for the rest of their corporate life, they'll be copying
Microsoft and AT+T (Unix).  It's really too bad, because there are
lots of talented people in DRI who just aren't being heard.

Moral:  If you start a company, don't be 'market driven'.  You're then
a slave to your market.

More power to Echelon,
Tony ;-)
---[4643]---

[4644] (31 lines) Network_Server 01/22/85  1803.5 mst Tue cpm
Subject:  Re: Need program to read/write MS-DOS format in Pascal
Date:  Sunday, 20 January 1985 20:51 mst
From:  Melinda Shore <shor%sphinx.uchicago.uucp at BRL-TGR>
To:  info-cpm at AMSAA
Newsgroups:  net.micro.cpm
Xref:  seismo net.micro.cpm:3805

[]

> From: news@brl-tgr.ARPA (David Roth
> Does anyone know of a public domain program to help read/write MS-DOS
> format (written in Pascal of course), on non-IBM-PC type machines?  We
> have a need to do this on just about any kind of micro with a 5 1/4
> disk drive.  Apples, Osborne, Kaypro,etc...  The reason for Pascal is
> that at least that much or it would be portable and the low level
> stuff could be done just for that machine.
> Oh, I have run across a program on a local R-CP/M system here called
> RDMSDOS.C which claims to work on CP/M systems.

If it was done right, your RDMSDOS.C should work correctly on just about any
CP/M system.  The author should have used BDOS call 31, which returns the
address of the disk parameter block in HL.  Since the DPB is a fixed size
across all CP/M systems, you now know where to stuff the information you have
about the MS-DOS disk format.  Needless to say, it's a little more
complicated than that, since the MS-DOS FAT is somewhat different from CP/M's
FCB, but it's really not that complicated.

BTW, could you send along a copy of your C program if it turns out to public
domain?

Melinda Shore
University of Chicago Computation Center
---[4644]---

[4645] (37 lines) Network_Server 01/22/85  1803.5 mst Tue cpm
Subject:  Re: What is Simtel20
Date:  Monday, 21 January 1985 09:42 mst
From:  King Ables <ables%cyb-eng.uucp at BRL-TGR>
To:  info-cpm at AMSAA
Newsgroups:  net.micro.cpm
Xref:  seismo net.micro.cpm:3807

<Here we go again>

Simtel20 is a site on the Arpanet which happens to be run by nice
guys who keep sources to many, many different kinds of micros,
especially MS-DOS and CP/M machines.  Unless you are on the Arpanet
you can't access them directly (since it's a military-connected
machine, I wonder if they have/publicize their dial-up lines??).
On the arpanet, you can telnet to them an login as anonymous and
ftp the files you need (I believe they like you to do this at
off-peak hours).

When I worked at U.T. I could grab things (they are on the Arpanet
which is overseen or sponsored or somehow otherwise connected with
the DOD).  Now I'm at a uucp only site, so I no longer have access
either (not that this should make you feel any better, it just appears
to me that this is the boat most people on Usenet are in).  People
who won't be able to access Simtel20 keep seeing postings from Arpa
people who can and they get confused -- especially new ones like
yourself.  Don't feel bad, this question comes up all the time.

Keith (or somebody):  maybe when someone makes a posting about new
sources being updated, it might pay to have a short (paragraph) blurb
at the end about Simtel and who can access.  If it was kept around
and posted every now and again and at the end of all your announcements,
maybe these questions would be fewer and farther between.

Or maybe you have a form letter you send people when they ask and I'm
sitting here being redundant.
-King
ARPA: ables%cyb-eng.UUCP@ut-sally.ARPA
UUCP: ...{ctvax,gatech,ihnp4,nbires,seismo,ucb-vax}!ut-sally!cyb-eng!ables
---[4645]---

[4646] (141 lines) Network_Server 01/22/85  1803.5 mst Tue cpm
Subject:  Re: What is Simtel20
Date:  Tuesday, 22 January 1985 05:53 mst
From:  Jeffrey Edelheit <edelheit at MITRE>
To:  King Ables <ables%cyb-eng.uucp at BRL-TGR>
cc:  info-cpm at AMSAA

King - every now and then we send out the SIMTEL20 blurb.  There really is
no set schedule when it is done, it just seems that we do it when the
interest is there.  Since a lot of folks have been asking the question,
maybe it's time to send it out again.  Therefore, for those of you
who have seen this before, please accept my apologies for dumping some
4 or 5 kb of blurb in your mailbox.  For those of you who haven't
seen this before, here goes:

"How can a user of a USENET host access the public domain
microcomputer software collection on the DDN/MILNET host
SIMTEL20" is being asked with increasing frequency as that
software collection continues to grow.  Unfortunately, direct
access is not possible as there is no UUCP gateway for file
transfer between SIMTEL20 (running TOPS-20) and a USENET host (as
there is for electronic mail).

(DDN, formerly known as ARPANET, is the Defense Data Network.
DDN, along with Arpanet, SATNET, SRINET, etc. are all members of
a TCP/IP protocol-based, multiple gateway network called InterNet.)

USENET has been built on adjacent hosts voluntarily agreeing to
store-and-forward relatively short messages across the USENET
over dialup lines at 300 or 1200 bps.  In the past, helpful InterNet
users would fetch the file(s) requested and then e-mail them to
the requestor.  However, it has been pointed out that large file
transfers disrupt the service, delay the shorter messages, and
generate unacceptably large phone bills, all of which add up to
threaten the tenuous connections that some USENET hosts can
barely afford to have.  Therefore, we have been asked to
encourage InterNet users not to pass archive programs this way.

Now for the good news.  Some InterNet users, if sent a suitable disk,
will download files and return mail the floppy to the requestor.
To find a friendly InterNet user, send a message to INFO-CPM at DDN
host AMSAA.ARPA via net.micro.cpm identifying your disk format and
your request.  Usually, someone will respond and come to your aid.
If not, don't be bashful, wait a week and try again.  But please
remember, any such arrangements are strictly between you and your
respondent.  This is not, repeat NOT, a service of either the InterNet
or INFO-CPM.

If the above arrangement is inconvenient, or doesn't work, here
are several other sources for public domain software.


----------------------------------------------------------------------

Information (and prices) are subject to change without notice.  A
volume is usually one floppy disk.


1.  CP/M User's Group

The CP/MUG volumes are available from:

  CP/M User's Group
  1651 3rd Avenue
  New York, NY 10028

Current volumes are numbered 1 through 92 at $13 per 8" SSSD disk
(Northstar format also available).  The catalog is $6.


2.  Special Interest Group/Microcomputers (SIG/M)

 The SIG/M volumes are distributed by:

  SIG/M
  Amateur Computer Group of New Jersey, Inc.
  Box 97
  Iselin, NJ 08830

Current volumes are numbered 000 through 172.  The first disk is
$6.00 and $5.00 for each additional disk.  The catalog is $2.


3.  New York Amateur Computer Club

PC-BLUE software volumes for the IBM-PC are available from:

  S-100, CP/M User Group
  The New York Amateur Computer Club
  P.O.  Box 106
  Church Street Station
  New York, NY  10008

The documentation files from the SIG/M and CPMUG volumes are
available in hardcopy form, grouped into "books", from the NYACC.
Each book is priced at $10 including shipping, $15 for overseas
airmail.  All orders must be prepaid.


4.  PicoNet CP/M Users Group

PicoNet, CP/MUG, and SIG/M software volumes are available from:

  PicoNet
  P.O. Box 391566
  Mountain View, CA 94039

Available in 8" and most 5 1/4" soft sector only at $6.00 per
disk plus $1.50 shipping per order.  California residents add
6.5% sales tax.  Quantity discounts are available.


5. Other sources:

Compuserve Information Service is another source of public domain
software. There are a number of special interest groups (SIGs)
devoted to specific hardware as well as CP-MIG, the generic CP/M
SIG, a repository for a large quantity of public domain software
downloadable by the Compuserve file transer protocol (Christensen
protocol is expected by late summer, 1984). There is no charge for
access to CP-MIG other than the standard CIS connect charges, and
Compuserve can be accessed through their own communications network
or through Tymnet.

Microsystems magazine periodically publishes a full list of
sources for public domain software in addition to those listed
here, with monthly updates/additions.

... and many Remote CP/M (RCPM) systems around the country, where
software is available for downloading for the price of a phone
call.  The May 1984 issue of Microsystems contains the full listing of
known RCPMs at the time of publication.


I would like to thank Dave Towson, Frank Wancho and Charlie Strom for all
their assistance in putting this blurb together.  If anybody out in InterNet
Land has any questions or comments about the above blurb, feel free to
contact any one of us.

Jeff Edelheit
(edelheit at mitre)


---[4646]---

[4647] (162 lines) Network_Server 01/22/85  1803.5 mst Tue cpm
Subject:  Major bug in Turbo Pascal version 2.00
Sender:  KPETERSEN at SIMTEL20
Date:  Tuesday, 22 January 1985 12:54 mst
From:  Keith Petersen <W8SDZ at SIMTEL20>
To:  Info-Cpm at AMSAA, Info-Micro at BRL-VGR

TURBOBUG.TXT follows:

                    ***** BUG REPORT *****
         ***** MAJOR BUG IN TURBO PASCAL V2.00 *****
                         July 1,1984
                    (updated December 1984)


     The runtime routines  do  not  handle  a  floating-point
(real)  subtraction  correctly.  For  some subtractions,  the
correct  difference  is  returned;  for  others,  a  zero  is
returned. The following program demonstrates the bug:

program test;
begin
     writeln(9.+(-6.0));        { Wrong value returned }
     writeln(-1.0+(-1.0));      { Correct value returned }
     writeln(1-2);              { Correct value returned }
     writeln(1.-2:10:2);        { Wrong value returned }
     writeln(1.-2.0);           { Wrong value returned }
     writeln(1-2.0);            { Wrong value returned }
     writeln(456 - 123.0);      { Correct value returned }
end.

A value of zero is returned on those lines marked as 'wrong'.
The other lines return the correct difference.



VERSIONS TESTED AND FOUND OK (December 1984)

The following versions of Turbo have been checked for this bug
and are alright.  Any versions for same OS, with higher serial
numbers, should be alright--but  use the above test program to
be sure.  The bug may be unique to MS-DOS versions.

          Turbo  ver 1.01A for CP/M-86    serial #  1225
          Turbo  ver 2.00B for CP/M-86    serial # 49036
          Turbo  ver 2.00B for MS-DOS     serial #131821


THE CAUSE

    After disassembling and tracing through a sample compiled
program, the error was located in the following code:

XXXX:12FA E84FFF        CALL    124C            ; Subtract
XXXX:12FD 7306          JNB     1305
XXXX:12FF 80F780        XOR     BH,80           ; Handle negative
XXXX:1302 E863FF        CALL    1268            ;   numbers
XXXX:1305 8B4504        MOV     AX,[DI+04]      ; Is mantissa zero?
XXXX:1308 0B4502        OR      AX,[DI+02]
XXXX:130B 0A4501        OR      AL,[DI+01]      ; ***** ERROR *****
XXXX:130E 740D          JZ      131D            ; Yes
XXXX:1310 F6450580      TEST    BYTE PTR [DI+05],80  ; Normal