3-Mar-81 22:18:00,948;000000000000
Date: Tuesday, 3 March 1981 22:18-MST
From: PLK at MIT-MC (Paul L. Kelley)
To: INFO-CPM at MIT-MC
Subject: New Remote System
This is to announce a new Remote CP/M system.
The telephone number is: (617) 862-0781
The system will be up from 7PM until 7AM weekdays and 24
hours weekends. The exception will be when I am working on
the system.
The system is intended primarily for SuperBrain users but
others are welcome. There are files for transfer and there
will be a MINICBBS and hardware information on the SuperBrain.
The SuperBrain is poorly documented and this system should
allow users of this micro to exchange information and solve
problems.
The operating software is BYE. This is a program written by
Ward Christensen (WLC at MC), Keith Petersen (W8SDZ at MC)
and others.
If you use the system and have problems or comments please
let me know on MC.
P. L. Kelley (PLK at MC)
4-Mar-81 01:58:00,410;000000000000
Date: Wednesday, 4 March 1981 01:58-MST
From: DAN at MIT-ML
To: info-CPM at MIT-MC
Subject: MBASIC 4.x versus MBASIC 5.x
What are the enhancements to MBASIC release 5.x which are not present
in release 4.51?? Are there any bugs in 4.51 that were corrected in
5.x, or was this new release just to add more features? While I don't
hack BASIC frequently, I was wondering about this... Thanx - Dan
4-Mar-81 20:16:00,1438;000000000000
Date: Wednesday, 4 March 1981 20:16-MST
From: Frank J. Wancho <FJW at MIT-MC>
To: INFO-CPM at MIT-MC, INFO-MTN at MIT-MC
Subject: New MTN (version 2.1) now available
A new MicroTELNET (MTN) Version 2.1 is now available. The HEX files
are rather large and have been broken into three HEXn files each.
(They are also available in the original form as one HEX file each.)
They may be reconstructed using the technique described below.
Also available, upon request, is a 4300H-based version for those of
you using systems requiring that as the starting address of their
TPA...
The doc file is MC:CPM;MTN21 DOC which is mainly a "what's new"
document.
To merge the HEXn files into the required files:
DDT MTN21-1.HEX
IMTN21-2.HEX
R
IMTN21-3.HEX
R
^C
SAVE 57 MTN21.COM
Similarly for MTNMSGS.OVR. (SAVE 70 MTNMSGS.OVR)
Again, bug reports and/or feature requests to BUG-MTN@MIT-MC.
--Frank
8-Mar-81 01:16:00,958;000000000000
Date: Sunday, 8 March 1981 01:16-MST
From: CENT at MIT-ML
To: info-cpm at MIT-MC
Subject: lost mail
i found this msg in the depths of ml's lost msgs files. the mailing
list is on MC, not ML.
----------
COMSAT@MIT-ML 02/19/81 00:04:07 Re: Msg of Thursday, 19 February 1981 00:04-EST
To: NET-ORIGIN at MIT-ML
A copy of your message is being returned, because:
"INFO-CPM" at MIT-ML is an unknown recipient.
Message not sent.
Failed message follows:
-------
Date: 19 Feb 1981 (Thursday) 0005-EDT
From: PLATTS at WHARTON-10 (Steve Platt)
Subject: BDS C
To: jp at SU-AI
cc: info-cpm at MIT-ML
I've seen it in use -- a friend had implemented a portion of a robot
arm controller in it. It looks like it works well -- it's an inspiration
towards my learning the language... operation seems smooth and clean...
he seems to have no major complaints. From his reaction, and from reading
the documentation, I'd recommend it highly.
9-Mar-81 04:20:00,634;000000000000
Date: Monday, 9 March 1981 04:20-MST
From: EB at MIT-AI
To: INFO-CPM at MIT-MC
I have a MACLISP program that implements a slightly modified
(i.e. 7-bit) version of the MODEM/XMODEM protocol and has been
successfully used to transfer files from an H89 to and from ITS
at 300 baud.
If anyone is interested in using this program, contact me.
Currently it is not documented anywhere. It has provisions
for keeping a log file so you can tell what it thought was wrong
with the transmission, and has flags to control things such as
whether 7-bit or 8-bit protocol is in use (though AI, at least,
can only talk 7 bits).
14-Mar-81 01:24:00,1710;000000000000
Date: Saturday, 14 March 1981 01:24-MST
From: LEOR at MIT-MC
To: info-cpm at MIT-AI
Subject: Running submit files from disks other than A:
For a long time, I have been frustrated by "accidentally" submitting a
submit file while being logged in to a disk other than A:, and having
a magical "$$$.SUB" appear instead of having my submit file processed.
Having gotten my hard disk up, and being forced to leave my system on
floppies and use the hard disk as C: and D:, I found myself really missing
the ability to do submits...
<interlude>
As a first solution to the problem, I tried going to A: and writing a submit
file that started with:
c:
just to see if it would take it. Yes! It did let me log in to C: as the
first thing in a submit file, but I still had to go to A: to submit it.
Could there possibly be a way to do a submit on C: without ever leaving C: ?
--- YES !! ---
If you ddt or sid submit.com, you'll notice that the fcb area for the temp-
orary file that submit.com creates ($$$.SUB) has its first byte set to 00...
that means that the $$$.SUB file will always be written to the currently
logged disk, EVEN THOUGH IT HAS NO MEANING UNLESS IT IS WRITTEN TO A: (smart
move, Digital Research...another of many!) SOOOO...my simple solution was
to change that 00 leading byte of the fcb to 01...this causes $$$.SUB to
always be written to A:, no matter which disk the submit is submitted from.
Now I can be on C: and do a submit as easily as if I were on A:.
I hope this helps some of you out there who've been frustrated by the same
problem. Incidentally, the location to patch in the 2.2 SUBMIT.COM program
is: 05BB hex (change from 00h to 01h)
later,
-leor
16-Mar-81 02:00:00,577;000000000000
Date: Monday, 16 March 1981 02:00-MST
From: Frank J. Wancho <FJW at MIT-MC>
To: Wmartin at OFFICE-3
cc: INFO-CPM at MIT-MC, HUMAN-NETS at MIT-AI
Subject: Dial-up number lists for BBSs
The lists have been merged and checked out as best as possible and now
live in MC:CPM;BBSNOS BYNAME and MC:CPM;BBSNOS BYAREA with the second
list a duplicate of the first except sorted by phone number.
Note that there is also another list specifically detailing Remote
CP/M systems in MC:CPM;R/CPM NOS.
Both lists are updated periodically, as the need arises.
--Frank
16-Mar-81 02:36:00,806;000000000000
Date: Monday, 16 March 1981 02:36-MST
From: W8SDZ at MIT-MC (Keith B. Petersen)
To: INFO-CPM at MIT-MC
Subject: Bad sector lockout program
MC:CPM;FINDBD ASM is the source code for the latest version of
"FINDBAD", a program which runs under CP/M 1.4 or 2.x. It
attempts to read all sectors on your disk (non-destructive
test) and builds a table of group numbers to allocate to a
dummy file so that CP/M will not attempt to use those areas
of your disk. It's great for "validating" new disks. Sure
saves the grief of later finding out that there are a few bad
sectors on your disk and getting a BDOS ERROR message when you
end that two-hour edit session! This program was originally
published in "Interface Age", but has undergone many significant
improvements since its publication.
16-Mar-81 02:39:00,442;000000000000
Date: Monday, 16 March 1981 02:39-MST
From: W8SDZ at MIT-MC (Keith B. Petersen)
To: INFO-CPM at MIT-MC
Subject: CP/M drivers for console and list
If your console and/or list drives are too big to fit into the
system tracks, you may find MC:CPM;DVRPAT ASM of interest. It is
a .COM file that patches alternate console and/or list drives into
high memory AFTER CP/M is booted. The patch remains intact until
the next cold boot.
16-Mar-81 08:09:00,445;000000000000
Date: Monday, 16 March 1981 08:09-MST
From: JSWAIN at BBND
To: info-micro at MIT-MC, info-cpm at MIT-MC
cc: jswain at BBND
Subject: RPG compiler
Does any-one know of a RPG compiler that runs on the 8080/Z80
CPU under CP/M. Is so, I would be interested in the name of the company
that offers it and if any-one has had any expirience with it, their
comments.
Replys can be directed to JSWAIN@BBND.
Thanks all.
John Swain
17-Mar-81 23:16:00,680;000000000000
Date: Tuesday, 17 March 1981 23:16-MST
From: Kenneth McDowell at MIT-AI
Sender: BIGMAC at MIT-AI
To: INFO-CPM at MIT-AI, INFO-MICRO at MIT-AI, JSWAIN at BBND
cc: BIGMAC at MIT-AI
Cromemco markets an RPG compiler that is said to be IBM-compatible. However,
I am not certain whether it runs under plain cp/m or not but, it does run
under their CDOS which is a CP/m derivative. (it also runs under their UNIX
look-a-like, CROMIX.) They're located in Mountain View, CA. but, I don't
have their address or any idea what the price is. Just out of curiosity,
what were you plannin' to use such a dinosaur for, anyway?
Ken McDowell
(BigMac at Mit-AI)
20-Mar-81 08:48:00,1379;000000000000
Date: Friday, 20 March 1981 08:48-MST
From: Bob Clements <CLEMENTS at BBNA>
Sender: CLEMENTS at BBNA
To: Info-CPM at MC
cc: Clements at BBNA
Subject: Kludgey patch in case of panic
I just had the problem of reading files under 1.4 CPM which
had been written under 2.x CPM into a NON-ZERO user
area. My CPM didn't find the files -- said "NOT FOUND".
I'm sure someone else has solved this problem too, but just for
the record, here's a quickee patch.
Addresses are for a 16K CPM (starts at 2900). Modify for your
size of system.
LOC OLD NEW
3690 E5 00
369C C1 7E
369D 0A E6
369E 96 80
3708 E5 00
Then restart CPM in such a way that it doesn't re-boot itself and
overwrite your patch, such as Go to 2903.
Put the disk with the non-0 user area in the drive and type DIR *.FOO .
You should see all the files, even if not named .FOO . Then type
ERA *.FOO . This will make all the files be in user area 0, NOT make
them erased. Then re-boot your CPM to get all those kludgey patches
out of there, and do a DIR to make sure you won. [You did do all
the above on a COPY of the disk, didn't you?]
FYI, the patches at 36xx make the CPM lookup routine see all files
that aren't deleted, regardless of file name. The patch at 3708 makes
the delete routine put "user 0 undeleted" into the FCB instead of
"blank disk, deleted (E5)".
/Rcc
23-Mar-81 01:56:00,419;000000000000
Date: Monday, 23 March 1981 01:56-MST
From: PHOTOG at MIT-MC (Robert E. Spivack)
To: INFO-CPM at MIT-MC, CLEMENTS at BBNA
IN RE TO THE PATCH GIVEN FOR READING CPM 1.4 NON-USER 0 DISCS
I FIND IT A LOT EASIER TO JUST USE THE CP/M OR SIG/M USER GROUP
PROGRAM DU-V74 TO PATCH THE DIRECTORY ENTRY FROM THE NON-ZERO
USER NUMBER TO A ZERO. JUST BE SURE TO PATCH ALL
FCBS'S IF THE FILE HAS MORE THAN ONE EXTENT!
24-Mar-81 02:56:00,333;000000000000
Date: Tuesday, 24 March 1981 02:56-MST
From: W8SDZ at MIT-MC (Keith B. Petersen)
To: INFO-CPM at MIT-MC
Subject: New Remote CP/M number list
The file CPM;RCP/M NOS which lists telephone number of
Remote CP/M systems has been updated as of today.
The extraneous comments on the end of the earlier file have been
removed.
24-Mar-81 23:00:00,2005;000000000000
Date: Tuesday, 24 March 1981 23:00-MST
From: DAN at MIT-ML
To: info-cpm at MIT-AI, info-micro at MIT-AI
Subject: Speedup patch for Morrow Designs Disk Jockey 2D Board
While looking through my Disk Jockey 2D manual, I discovered an interesting
"feature" in the FIRMB software which is a disadvantage to those who have
fast (3 ms track-to-track) single-sided disk drives. In the "PREP" routine
(around 0E254H or so in the standard FIRMB software; it depends on the
FIRMB version that you have) is the code:
.
.
.
LDA DSTAT ;get the double
ANI DSIDE ;-sided flag
STA DSFLAG ;save for status
RAR ;shift for
RAR ;3/6 ms step
RAR ;-rate constant
ADI SKCMD ;do a
.
.
.
This code checks to see if a single sided or double sided disk is being
used by isolating b3 of the DSTAT flag byte. If b3 is "1", then the disk
is single-sided. This is shifted over to b0, and is added to the Seek
Command value (18H) to form the final 3 millisecond Track-to-Track (TTT)
Seek Command of 18H, or the 6 ms TTT Seek Command of 19H.
Unfortunately, if you are using single-sided 3 ms TTT drives (such as
the Remex drives that Morrow supplies), you don't get the advantage of
the speedier seek time because the above software assumes that all single
sided drives (e.g. older Shugarts) can't hack 3 ms TTT.
If you have 3 ms TTT drives, you can modify your FIRBM software to
use a 3 ms TTT time by replacing the three "RAR" instructions with:
XRA A ;always use
NOP ;3 ms track-
NOP ;to-track time
Of course, this will require a new EPROM to be burned. Be careful, as
the EPROM on the DJ2D board has INVERTED data (i.e. logical TRUE = 0,
logical FALSE = 1).
After making this patch, I did some disk-intensive benchmarks so see if
this improved performance. Depending on what I did (Z80 assembly, Pascal
compilation, etc.), I got between 5% to 17% speed improvement, which is not
bad for changing three bytes of code.
- Dan
24-Mar-81 23:16:00,727;000000000000
Date: Tuesday, 24 March 1981 23:16-MST
From: DAN at MIT-ML
To: info-micro at MIT-AI, info-cpm at MIT-MC
Subject: Which FORTH?
A simple question with many answers... Of all the FORTHs around, which
are the good ones, and which are the ones best to stay away from. My
indecision is due to the fact that
1. There are many versions available
2. The cost for a FORTH package varies from downright cheap to absurdly
expensive
I am looking for a CP/M version with all the goodies (interpreter,
compiler, decompiler, etc) which supports either the fig-FORTH or
FORTH-79 "standard" (??). ROMmabe code and some sort of file handling
(via CP/M) would be highly desirable.
Any suggestions?
- Dan
25-Mar-81 02:21:00,768;000000000000
Date: Wednesday, 25 March 1981 02:21-MST
From: W8SDZ at MIT-MC (Keith B. Petersen)
To: INFO-CPM at MIT-MC
Subject: Special version of filter program
If you have been using a program to save incoming ASCII text
from your modem, you have probably noticed that some computers
or TIPS may send "orphan" line feeds (that is, line feeds without
a carriage return immediately preceeding). Most editors that
run under CP/M will not properly handle files of this type. I have
just written a new utility program (based on FILTER.ASM) which
corrects any file with this problem. In fact, it will take files
which contain only carriage returns (and no line feeds) and change
them to normal CRLF CP/M end-of-line format. See MC:CPM;FILTEX ASM
and FILTEX HEX.
25-Mar-81 04:45:00,790;000000000000
Date: Wednesday, 25 March 1981 04:45-MST
From: PHOTOG at MIT-MC (Robert E. Spivack)
To: INFO-CPM at MIT-MC, FJW at MIT-MC, W8SDZ at MIT-MC, WLC at MIT-MC,
DWS at LLL-MFE
HELP! A WHILE AGO SOMEONE MENTIONED THEY FIXED CP/M TO WORK
BETTER BY IMPLMENTING A REAL 'DISC CACHE' NOT THE PSEUDO-ONES
WHICH ARE JUST BLOCK BUFFERS. COULD THIS PERSON ELABORATE, AND
OR IS THE S'WARE PUBLIC DOMAIFN? RECENTLY, ITHACA INTERSYSTEMS
IS SELLING A CACHE BIOS THAT USES 64 RAM JUST FOR DISC BUFFER.
THEY USED THE IEEE EXTENDED ADDRESS LINE MEMGORY TO STORE DATA IN
MOVING IT TO THE NORMAL 64K ADDRESS SPACE IN 128 CHUNKS FOR CP/M.
IS THIS CLOSE TO THE SAME THING? (IT REQUIRES A DMA BOARD THAT
CAN DMA INTO ANY OF THE 24BIT ADDRESS SPACE TO KEEP MOVES TO
A REASONABLE MINIMUM)
26-Mar-81 00:02:00,162;000000000000
Date: Thursday, 26 March 1981 00:02-MST
From: RGF at MIT-MC (Ronald G. Fowler)
To: INFO-CPM at MIT-MC
