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 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 files are: MC:CPM;MTN21 HEX 321 recs, 41053 bytes, CRC= 76E1. MTN21.COM file CRC= D958 MC:CPM;MTN21 HEX1 107 recs, 13680 bytes, CRC= 9D68. MC:CPM;MTN21 HEX2 107 recs, 13680 bytes, CRC= E0AD. MC:CPM;MTN21 HEX3 107 recs, 13693 bytes, CRC= 325F. MC:CPM;MTNMSG HEX 394 recs, 50413 bytes, CRC= 4B47. MTNMSGS.OVR file CRC= BBC1 MC:CPM;MTNMSG HEX1 132 recs, 16830 bytes, CRC= 15D4. MC:CPM;MTNMSG HEX2 132 recs, 16830 bytes, CRC= 219C. MC:CPM;MTNMSG HEX3 131 recs, 16753 bytes, CRC= FEE6. 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... 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 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 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 please put me on your mailing list. thank you