15-Feb-81 23:25:00,566;000000000000
Date: Sunday, 15 February 1981  23:25-MST
From: Bob Clements <CLEMENTS at BBNA>
Sender: CLEMENTS at BBNA
To:   Info-CPM at Mit-MC
Subject: DDT vs IRQ on trap 7

I have a hardware configuration which uses IM1 of a Z80, the mode
where all the interrupts trap to location $38.  If I put that
software on my CPM system to debug it, I will have a conflict
between DDT, which uses RST 7 for breakpoints, and the hardware
which will use RST 7 for all the interrupts.  Has anyone doped out
how to get DDT to use a different RST number for its breakpoints?
/Rcc
16-Feb-81 11:19:00,1003;000000000000
Date: Monday, 16 February 1981  11:19-MST
From: PHOTOG at MIT-MC (Robert E. Spivack)
Sender: ___024 at MIT-MC
To:   INFO-MICRO at MIT-MC, INFO-CPM at MIT-MC, PHOTOG at MIT-MC,
      RAIDER at MIT-MC

---Z8000 FOR THE S-100AT LAST YEAR'S WEST COAST COMPUTER FAIRE ITHACA (NOTE THE A, IT IS
NOT ITHICA FOR YOU NON-EASTERNERS) INTERSYSTEMS HAD ON DISPLAY A Z8000 BOARD FOR THE S-100.  IT WAS FULL IEE-100 AND COULD BE RUN AS A BUS SLAVE
WITH A Z80.  THE IDEA WAS YOU WROTE YOUR CODE ON THE Z80 USING A CROSS ASSEMBLER, THEN SWITCHED BUS MASTERS TO THE Z8000 TO RUN IT.  OBVIOULSY
IT IS FOR DEVELOPING MORE SOPHISTICATED Z8000 LANGUAGES.  I
THINK THE BOARD IS BEING SOLD AND YOU CAN GET A HOLD OF IT NOW.
ALSO, THEIR PASCAL/Z COMPILER IS WRITTEN IN PASCAL ITSELF
AND I BELIEVE THEY ARE BUSILY PORTING IT OVER TO THE Z8000
(THAT IS ABOUT THE ONLY REASON I CAN SEE FOR PERHAPS USING
IT, I FIAND THE PASCAL/MT COMPILER TO BE FAR SUPERIOR EVEN THOUGH
IT GENERATES MOSTLY 8080 AND NOT Z80 CODE).
16-Feb-81 13:15:00,805;000000000000
Date: Monday, 16 February 1981  13:15-MST
From: Jorge Phillips <JP at SU-AI>
To:   info-northstar at MIT-MC, info-cpm at MIT-MC

CP/M, C and N*

My apologies in advance to those of you who recieve this
message twice.

I am interested in running C on a 64K quad DD N* under CP/M.
I have surveyed the market for C compilers and there seem to
be only two alternatives: BDS C, and Whitesmith's C.  I am
interested in hearing what impressions do people have of
both compilers.  My understanding is that W.  C.  is
incredibly complete but has the problems of cost and size
(i.e. it is unclear it can really run on a micro), and that
BDS C may not be good for doing serious system programming.
Are there any other compilers/alternatives I am unaware of?

Thanks for your comments.

	-Jorge
17-Feb-81 00:11:00,891;000000000000
Date: 16 Feb 1981 at 2311-PST
From: Walt at Rand-Unix
To:   JP at Su-Ai
cc:   info-cpm at Mit-Mc

In response to your inquiry about C on CP/M:

C/80, my extension of small-c, is now available on 8" single density CP/M
disk.  If you find BDS C inadequate for system work, you may not like C/80,
since it does not have structures.  It does have statics, initialization
of globals, and the runtime profile feature (which may need a few lines
of code to hook into your clock, if you have one).  It generates 8080
assembly code and comes with a compatible absolute assembler.  I don't
know enough about N*s to know if there are media or system compatibility
problems, but it does run on most vanilla 8" CP/M systems.  It's about 1/3
the price of BDS C.  Address inquiries to The Software Toolworks, 14478
Glorietta Drive, Sherman Oaks, CA 91423. (213) 986-4885

-Walt Bilofsky
17-Feb-81 00:27:00,368;000000000000
Date: Tuesday, 17 February 1981  00:27-MST
From: POURNE at MIT-MC (Jerry E. Pournelle)
To:   INFO-CPM at MIT-MC

Help?  At risk of showing how little I know: is there a download
that works on the net through a TIP?  I have had CBF write a
routine that seems to work but havn'e timplemented it yet; is
there something that works that I don't know about? Thanks
17-Feb-81 19:29:00,1483;000000000000
Date: Tuesday, 17 February 1981  19:29-MST
From: AFITGORDON at BBNB
To:   JP at SU-AI
cc:   [Conn]: at BBNB, info-cpm at MIT-MC
Subject: C Compilers Under CP/M

        IN  RESPONSE  to  the  request  for  information  concerning C
compilers for the CP/M OS, I have had some experience with BDS  C.   I
really  enjoy using it.  It is not a full C, but it is a good language
for systems programming under CP/M.   It  generates  relocatable  code
which  may  then  be linked with a library to produce a COM file.  You
can create and customize libraries as required or desired.  In the way
of  drawbacks,  it does NOT support floating point or predefinition of
string variables well.

        I   am  one  of  the  programmers  for  Supersoft,  and  in  a
conversation with the owner this evening, he said  that  Supersoft  is
coming  out  with  their  own  C  compiler.  It compiles into assembly
language and can then be assembled into a COM file.  He estimates  the
initial  cost  to  be  $175  for  8080  version and $500-600 for Z8000
version.   He  also  claims  that  it  is  superior  to   BDS   C   in
implementation,  and  I  am  planning  to  buy  a  copy to try it.  If
desired, I'll review it to INFO-CPM.  He also mentioned Whitesmith's C
and claimed that there were many bugs.

        For what it's worth, those are my opinions.  I  like  and  use
BDS C and feel it is a good buy for $110.

                                        Rick Conn
18-Feb-81 00:28:00,784;000000000000
Date: Wednesday, 18 February 1981  00:28-MST
From: PHOTOG at MIT-MC (Robert E. Spivack)
To:   WLC at MIT-MC, W8SDZ at MIT-MC, FJW at MIT-MC, RAIDER at MIT-MC,
      CHUCKG at MIT-MC, INFO-CPM at MIT-MC

TO WARD ET. AL.  I JUST RECEIVED THE ISSUE OF LIFELINES THAT
CONTAINS MODEM7.  I AM VERY DISAPPOINTED THAT YOU WOULD LET
SOMEON CARVE UP (HACK TO DEATH) YOUR WONDERFUL MODEM PROGRAM
AND PUT IT BACK IN THE CP/MUG PIPLINE.  JUST FOR STARTERS, THIS
GUY REMOVED ALL YOUR COMMENTS AND EVEN THE TABS THAT LINE UP
THE ASSEMBLER SOURCE (IF HE DID NOT LIKE TABS, HE COULD HAVE
PUT BACK SPACES.)
THAT REALLY TURNS IT INTO A CRYPTIC PROGRAM FOR THOSE THAT DO
NOT HAVE THE ORIGINAL!   I AM CURIOUS WHY THIS MASSACRE
OF A GOOD PIECE OF SOFTWARE WAS ALLOWED ON THE CP/MUG DISCS!!
21-Feb-81 16:52:00,196;000000000000
Date: Saturday, 21 February 1981  16:52-MST
From: LIN at MIT-AI
To:   INFO-CPM at MIT-AI

i'm trying to get on the info-cpm list.  is this where
to do it?  i've also tried info-cpm-request.
22-Feb-81 12:43:00,1255;000000000000
Date: Sunday, 22 February 1981  12:43-MST
From: PHOTOG at MIT-MC (Robert E. Spivack)
Sender: ___076 at MIT-MC
To:   WLC at MIT-MC, INFO-CPM at MIT-MC

WARD AND I HAVE BEEN HAVING A DISCUSSION ABOUT THE WAY THE MODEM
PROGRAM WAS HACKED TO DEATH.  I WOULD LIKE TO SHARE SOME OF MY
COMMENTS ABOUT MODIFYING PUBLIC DOMAIFN SOFTWARE AND THEN
RE-DISTRIBUTING IT.
1.  I AGREE WITH WARD, THE ORIGINAL AUTHOR IS THE 'OWNER' AS 
    AS SUCH, HAS CERTAIN PRIVILEGES BEYOND ANYONE ELSE WHO MUCKS
    WITH THE PROGRAM.   THE AUTHOR SHOULD BE THE ONLY ONE TO RELEASE UPDATED VERSIONS, HOWEVER, ANYONE CAN SUBMIT UPDATES TO HIM FOR REVIEW.
    THE UPDATES SHOULD INCLUDE THE ORIGINAL PROGRAM UNCHANGED
    EXCEPT WHERE NEW FEATURES OR FIXES HAVE BEEN ADDED.  THE 
    UPDATE SHOUL BE A READ-TO-GO PROGRAM, SO IF THE AUTOHOR LIKES IT,
    HE CAN PUT THE NEW VERSION INTO THE PIPLEINE WITH VERY LITTLE
       EFFORT.   THIS IS THE KEY, EVEN IF LOTS OF CHANGES ARE MADE, THE
    AUTHOR IS NOT SADDLE WITH A LOT OF HOUSEKEEPING WORK JUST TO
KEEP UP WITH WHAT EVERYONE IS DOING TO THE PROGRAM.
22.    UNAUTHORIZED VERSIONS (I..E UNILATERAL UPDATES SHOULD BE REMGOVED
  FROM OFFICIAL PIPLELINES SUCH AS THE CP/MUG AND SIG/M USER GROUP
    LIBRARY DISCS.
22-Feb-81 17:26:00,515;000000000000
Date: Sunday, 22 February 1981  17:26-MST
From: SSteinberg.SoftArts at MIT-Multics (SAS  at SAI-Prime)
Sender: COMSAT.SoftArts at MIT-Multics
To:   info-cpm at MIT-MC
Subject: BDS C and systems programming
SAI-TO: info-cpm at mit-mc, cc:SAS:sent.po

Everyone at Mark of the Unicorn agrees, BDS C is worthless for
systems programming but you can write really neat editors in it
although something like EMACS isn't a system program.  They
will sell you an almost EMACS and a BDS C at a rather good
price.
23-Feb-81 15:54:00,786;000000000000
Date: Monday, 23 February 1981  15:54-MST
From: Lauren at UCLA-SECURITY (Lauren Weinstein)
To:   INFO-CPM at MC
Subject: BDS C and programming

Wait a sec, here.  What are we calling "systems programming"?  If
you are actually talking about programming an OS in C, I will agree
that NONE of the available C compilers for 8080/Z80 are reasonable.
But this is because the 8080/Z80 is not reasonable.

For ANY sort of applications programming though, including all sorts
of system utilities, I find BDS C more than adequate in all cases,
and extremely helpful.  This goes from editors to text processors to
disk copy utilities to bizarre realtime applications.  It's the cheapest
C compiler you can get with full structure ability and super-fast
compilation.

--Lauren--
23-Feb-81 23:08:00,652;000000000000
Date: Monday, 23 February 1981  23:08-MST
From: GYRO at MIT-AI
To:   INFO-CPM at MIT-AI
Subject: BDS C for systems programming

SSteinberg shouldn't toss around "everyone at Mark of the Unicorn agrees"
-- he only talked to one of us.  I second Lauren's clarification of
his remarks: it depends on what you mean by "systems" programs.  BDS C
is very useful for a lot of low-level hackery that is certainly in the
grey area between systems and applications.  You couldn't write a BIOS
in it, but you certainly could write something of the level of a BDOS.
The result would be large and slow, compared to assembly code, but
what do you want?
23-Feb-81 23:13:00,303;000000000000
Date: Monday, 23 February 1981  23:13-MST
From: GYRO at MIT-AI
To:   INFO-CPM at MIT-AI
Subject: BDOS22 PATCH

Has anybody tried to install this patch in Pickles & Trout CP/M 2.2
for the TRS-80 Model II?  They've done some funny things and I can't
see how to get around them.

-- Scott Layson
25-Feb-81 05:57:00,539;000000000000
Date: Wednesday, 25 February 1981  05:57-MST
From: SSteinberg.SoftArts at MIT-Multics (SAS  at SAI-Prime)
Sender: COMSAT.SoftArts at MIT-Multics
To:   info-cpm at MIT-MC
Subject: BDS C
SAI-TO: info-cpm at mit-mc, cc:SAS:sent.po

One minor drawback of BDS C is that the linker assumes that
each outward call from a module requires a word (2 bytes)
through which to indirect.  This cost them almost 3K in MINCE.
They have a version of the linker available (write them or read
their literature) which eliminates this requirement.
25-Feb-81 10:20:00,1716;000000000000
Date: Wednesday, 25 February 1981  10:20-MST
From: JSWAIN at BBND
To:   info-cpm at MIT-MC
Subject: Serious F80 bug in Rev. 3.4

	This message is to report a very serious bug in the FORTRAN 80
Compiler  Rev. 3.4 written by Microsoft that causes the buffer allocation
routines to eat up it's own data storage and code areas as it
allocates buffers for any disc output that it does.  If you open files
for data manipulation, you will allocate the buffer areas down on top
of data and variable storage areas.

	This is because of improper handling of the variable $MEMRY
in the module that handles buffer and FCB allocation during program
operation.

	The bug, though quite serious, is easy to remedy as the module
that has the bug in it is given to you on the disc as one of the .MAC
files.  

	The program to be repaired is "DSKDRV.MAC".

	The bug is in the section on page 1-9 of the
assembly listing in the "ALCBUF:" routine.  If you assemble the code
with the /C switch to give you a cross-referenced listing, the error is
on line # 418.  The code is   LXI	D,FCBLEN.  It should be
changed to  LXI	H,FCBLEN.  This will cause the allocation
routine to use the correct value for top of memory calculations.

	After you assemble the change into a .REL file, it will
be necessary to update the file FORLIB.REL to put the module into
use.

	Use the following command line to fix it up.

LIBcr
TESTLIB=FORLIB<..ARGTRN>,DSKDRV,FORLIB<LPTDRV..>
/E
Compile a program, and then link it using as the last step.
TESTLIB/S/E to use the test library instead of FORLIB.

If it works, the rename FORLIB.REL to FORLIB.BAK and TESTLIB.REL
to FORLIB.REL

	Good luck
	John W. Swain   BBND
26-Feb-81 22:03:00,429;000000000000
Date: 26 Feb 1981 at 2303-CST
From: mknox at UTEXAS-11
To:   info-cpm at mit-mc
Subject: FD765/ Intel 8272 Floppy Dsk Controller

I am looking for the source code for any CP/M BIOS built around the
NEC FD765 (or equivalent Intel 8272) floppy disk controller chip.
In specific, I am interested in the seeing how others solved the
blocking/deblocking and the auto-density and auto-sector-size
problems.  Any suggestions?
27-Feb-81 04:56:00,165;000000000000
Date: Friday, 27 February 1981  04:56-MST
From: DAN at MIT-ML
To:   info-cpm at MIT-MC
Subject: mailing list

Please put me on the mailing list    thanks, Dan
28-Feb-81 02:23:00,2304;000000000000
Date: Saturday, 28 February 1981  02:23-MST
From: Frank J. Wancho <FJW at MIT-MC>
To:   INFO-CPM at MIT-MC, INFO-MTN at MIT-MC
Subject: MicroTELNET (MTN) Version 1.3

(Please excuse any duplicate of this message that some of you may
receive.)

Dear MTN Users,

I am removing the MTN files from MC:CPM; and will "shortly" (whatever
*that* means) upload a significantly newer version with MANY new
features and ALOT of bugs fixed.  Release of this new version will be
what I consider premature, but only in the sense that I haven't been
able to install and check out ALL the features that everybody has
asked to be included.  Since some of you have received a pre-release
version of MTN 2.0 in various stages of development, the new release
will be called MTN 2.1 to bring you back in sync.

I must add that the reason for doing this was prompted by a rather
embarrassing discovery of a piece of code that has been in the program
from its beginnings which was lifted from another modem program and
seemed to work.  In tracking down a bug near that code, I found that
what I had assumed to be correct was not.  THIS ONLY APPLIES TO USERS
OF MTN 2.0 AND BELOW WHO HAVE A D.C. HAYES MODEM.  THE PMMI CODE IS
CORRECT, EXCEPT THAT IT DOES NOT HANG UP THE PHONE WITH THE TERMINATE
COMMAND.

So, rather than leave this faulty code around for even more
unsuspecting people to pick up and not let me know they have it (so as
to be on the mailing list for upgrade announcements), I am removing it
from further circulation.

My sincere apologies for any inconvenience this may have caused you.

--Frank


[For those of you interested in what the bug was that got me upset:

For some reason, the original author of this section of code decided
to turn on the transmit enable signal BEFORE dialing the number,
rather than AFTER receiving the carrier detect signal from the remote
modem.  What lead me to check this out was that I was trying to speed
up the dialing back to specs and could not find out why another
auto-dialing modem program I had was successful in completing calls,
while my version, using the same timing was not.  I also discovered,
in the same section of code, that the modem setup was not correct
either.  Thus the withdrawal announcement.

--fjw