1-Mar-84 09:34:21-MST,1524;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 1 Mar 84 09:34:15-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 1 Mar 84 11:12 EST Received: From Mit-Mc.ARPA by BRL via smtp; 1 Mar 84 10:39 EST Date: 1 March 1984 09:25-EST From: Allan D. Plehn Subject: Need tech data for WECo 300/1200 Dataphone modem To: INFO-CPM@mit-mc, INFO-MICRO@mit-mc cc: PLEHN@mit-mc A friend of mine has acquired some 300/1200 baud modems built by Western Electric. I have been trying to help interface the modem to his personal computer. I can't even figure out where to connect the telephone line. The modem is 2 inches high by 6 wide by 11 deep. It has 5 push-push type switches on the front and a number of indicators behind the red plastic faceplate. It says "Dataphone 300/1200" on the front faceplate plus the Bell symbol. On a label on the bottom, it says "Data Set 212A, AR Options" and has a chart showing internal DIP switch settings for various options. Another label says: "4702 Data Mounting P/O Data Set 212A OR AR Type Series 1 81 MG 02" There are two 25-pin data connectors on the rear, one male and one female. I cannot see any place to connect the phone line anywhere, inside or out. If anyone could furnish the necessary interfacing information I would certainly be indebted. I am hoping that I can talk my friend into giving me one of these modems so I am especially anxious to be helpful. PLEHN%MIT-MC 1-Mar-84 10:30:23-MST,1515;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 1 Mar 84 10:30:15-MST Received: From Brl-Vgr.ARPA by AMSAA via smtp; 1 Mar 84 12:07 EST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 1 Mar 84 11:52 EST Date: Thu, 1 Mar 84 11:22:42 EST From: Thomas C. Minor (IBD) To: info-apple@brl-vgr cc: info-cpm@brl-vgr, tminor@brl Subject: Z80 Plus Board by Applied Engineering Does anybody out there know anything about the Z-80 Plus board from Applied Engineering in Dallas Texas? I want to use it in an Apple IIe that now has a Grappler+ hooked up to an Epson FX80 printer. My IIe also has the single Apple disk controller board and the extended-memory 80 column card from Apple. Future plans include a modem card or a serial I/O card hooked up to an external modem. What's the catch? This card sounds so good, but it's really cheap at $140. It claims to be compatible with Microsoft CPM disks. Will it boot directly from the Microsoft Softcard operating system? Does CPM come with the Z80 Plus? Will it handle CPM 3.0? Are there any known problems with other boards, such as serials, modems, disk emulators, etc? Does it really run Wordstar, dBase II, etc, as the ads claim? It just sounds too good to be true. What's the story? Any help, soon, would be appreciated. -Tom Minor 301-278-6176 1-Mar-84 16:13:17-MST,1483;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 1 Mar 84 16:13:09-MST Received: From Brl-Vgr.ARPA by AMSAA via smtp; 1 Mar 84 17:56 EST Received: From Usc-Eclc.ARPA by BRL-VGR via smtp; 1 Mar 84 17:52 EST Date: 1 Mar 1984 1447-PST From: Chris Subject: Re: Z80 Plus Board by Applied Engineering To: tminor@BRL.ARPA, info-apple@BRL-VGR.ARPA cc: info-cpm@BRL-VGR.ARPA, nancy@USC-ECLC.ARPA Phone: (213) 743-5520 Office: PHE-220 In-Reply-To: Your message of 1-Mar-84 1155-PST I can't talk to the question you posed directly, however I just had a bout with a the ALS Z-card that may be worth considering. The Z-card ($129) was purchased mail-order so that I could run wordstar and do some work for downline loading to another z-80 computer. I also had Microsoft's Ramcard. To make a long story short, the z-card came with cpm and several utilities. Most of the utilities didnt bomb, but didnt work either. The 60K system generation utility failed to produce a bootable CPM system. After a long delay and several long distance phone calls to the mail-order firm, ALS finally got back to us saying that there was a "timing problem between the z-card and microsoft's ramcard." After two iterations of this, I gave up and got microsoft's cpm and card which was up and running a 60k system in 15 minutes. Cheapness doesnt always pay off - either in time or money. Chris. ------- 1-Mar-84 18:55:34-MST,867;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 1 Mar 84 18:55:31-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 1 Mar 84 20:33 EST Received: From Mit-Mc.ARPA by BRL via smtp; 1 Mar 84 20:05 EST Date: 1 March 1984 20:26-EST From: Allan D. Plehn Subject: m7lib.com-doesn't seem to work. To: W8SDZ@mit-mc cc: INFO-CPM@mit-mc, PLEHN@mit-mc I tried to change the phone directory in mdm724.com using m7lib.com. m7lib finds and displays the directory in the mdm724 program and then asks if it looks all right. No matter what I answer to this question (yes, no, hange, etc.) I get the message: ++PHONE LIBRARY NOT FOUND++ [Exiting Program] and then it returns me to CP/M. What am I doing wrong (besides following the instructions in the m7lib.doc file)? Al Plehn 2-Mar-84 08:23:55-MST,2013;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 2 Mar 84 08:23:37-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 2 Mar 84 2:46 EST Date: Fri, 2 Mar 84 2:22:20 EST From: Rick Conn To: info-cpm@brl Subject: ZCPR3 Status For those of you who are interested, I'll probably be sending out a status report on the development of the ZCPR3 System sometime over the next few days. The system is coming along quite nicely, with the ZCPR3 Command Processor running without error and the three supporting libraries, SYSLIB 3, VLIB, and Z3LIB, almost complete. I expect all of the ZCPR3 utilities to come up very quickly after I polish off Z3LIB, which is still under major development. I'll be giving two talks over the next two months on the topic of ZCPR3 if you are interested in attending. The first talk is later today at the SIG/M meeting. The talk will be given in the Health Building at Union County College, Scotch Plains, NJ, starting around 8PM tonight (Friday, Mar 2). The second talk will be given at the Trenton Computer Festival on Saturday, April 14. It is currently scheduled for 11:00 AM. Details on the room will be available in the Festival program. I'm hoping to include a live demonstration during this talk, but there are no guarantees at this time. Sometime during later March or early April, I'll be bringing a ZCPR3 system designed for remote access online on a limited-time basis for those who are interested in spending some money on a phone call and trying out ZCPR3 in real-time and exploring what it can do. More details on this when the system comes up. I'm still not willing to pinpoint a date for the release of ZCPR3, but I strongly suspect that it will go out sometime in the next three months. Will let you know when it happens. Rick 2-Mar-84 08:24:08-MST,1131;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 2 Mar 84 08:23:56-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 2 Mar 84 6:10 EST Received: From Sri-Sprm.ARPA by BRL via smtp; 2 Mar 84 5:44 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 2 Mar 84 2:53-PST Date: 28 Feb 84 11:53:03-PST (Tue) To: info-cpm@brl From: decvax!linus!utzoo!utcsstat!ian@ucb-vax Subject: CP/M RBBS4 Edit 21 source available Article-I.D.: utcsstat.1750 I have the sources for edit 4.21 of the C-language RBBS4, a CP/M-based bulletin board system. Compiles with version 1.5 or later of BDS C. It is huge - 111,111 bytes. I think this makes it too big to post, or to mail to large numbers of people. If you want the software, send me *mail* (do NOT post your reply to the net or to "notesfiles", but use MAIL to reply). Once I have an estimate of how many people want it on USENET, I will figure out how best to distribute it. Arpa/Milnet users can get it directly from simtel20. Ian F. Darwin utcsstat!ian -- Ian F. Darwin, Toronto uucp: utcsstat!ian 2-Mar-84 08:24:51-MST,630;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 2 Mar 84 08:24:35-MST Received: From Brl-Vgr.ARPA by AMSAA via smtp; 2 Mar 84 6:45 EST Received: From Mit-Mc.ARPA by BRL-VGR via smtp; 2 Mar 84 6:35 EST Date: 2 March 1984 06:35-EST From: Jerry E. Pournelle Subject: Z80 Plus Board by Applied Engineering To: Pace@usc-eclc cc: nancy@usc-eclc, tminor@brl, info-apple@brl-vgr, info-cpm@brl-vgr In-reply-to: Msg of 1 Mar 1984 1447-PST from Chris ALS I don't now, but Applicard works and the people who make it are good guys. JEP 2-Mar-84 08:25:18-MST,1505;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 2 Mar 84 08:24:41-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 2 Mar 84 6:31 EST Received: From Sri-Sprm.ARPA by BRL via smtp; 2 Mar 84 6:09 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 2 Mar 84 3:09-PST Date: 28 Feb 84 14:35:07-PST (Tue) To: info-cpm@brl From: decvax!linus!philabs!mcvax!dutesta!sp@ucb-vax Subject: WordStar and Daisy M-50, help needed Article-I.D.: dutesta.210 Is there anyone who has installed a Daisy M-50 daisy wheel printer in WordStar (version 3.0). I know the Daisy M-45 has to be installed as either a Diablo 1610/1620 or as a Qume sprint 5 printer. A M-50 however doesn't work well than. I first installed it as a Sprint 5 printer and found that every second line got printed backwards. This was resolved by putting a .bp off in the file (is there an instalation option to do this?). Than I found out that as long as WordStar didn't fill the lines everything went fine. As soon as WordStar started to fill lines (and micro justify them) printing went wrong. It prints about one line (unreadable) and than the printer starts to flash its RST light indicating wrong control code's. Installing it as any other daisy wheel does not solve the problems. Is there anyone who has a clue as to wat might be wrong ? Please mail to the following addres: -- Arrie v.d.Vliet, Delft Univ. of Tech. ..!{decvax,philabs}!dutesta!sp 2-Mar-84 08:25:34-MST,2773;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 2 Mar 84 08:25:05-MST Received: From Brl-Vgr.ARPA by AMSAA via smtp; 2 Mar 84 7:09 EST Received: From Mit-Mc.ARPA by BRL-VGR via smtp; 2 Mar 84 7:02 EST Date: 2 March 1984 07:03-EST From: Jerry E. Pournelle Subject: Kaypro BIOS list bug To: w8sdz@brl cc: Info-Cpm@brl-vgr In-reply-to: Msg of Thu 19 Jan 84 9:45:29 EST from Keith Petersen Tyler Sperry, editor of ProFiles, was over this afternoon delivering the 1984 model Kaypro IV. Have you sent your information to Profiles? If not, please do, and you can mention my name if you want to be certain of getting attention although in fact they will read it about the same without. Good information; they'd probably change th ROM if they knew. Jerry Pournelle Tyler Sperry ProFiles 533 Stevens Ave Solana Beach CA 92075 619-481-4353 Date: Thu, 19 Jan 84 9:45:29 EST From: Keith Petersen To: Info-Cpm at brl-vgr Re: Kaypro BIOS list bug The following is forwarded from CompuServe, courtesy Irv Hoff. --- #: 74332 Sec. 1 - General Sb: #Kaypro Mystery Solved 18-Jan-84 01:54:26 Fm: JACK CRENSHAW 72325,1327 To: All Some time ago I reported a problem with the MDM711/Kaypro/Epson combina- tion, in that the ^P print buffer dropped characters. Periodically, the subject has come up again, with Irv Hoff and Pete Holsberg trying hardest to help me solve the problem. I finally got around to looking at the Kaypro BIOS, and as Pete suspected, there's a bug. The offending piece of code is in the ROM, and goes: LISTST: IN 1CH ;GET SYSTEM PORT BIT 3,A ;TEST PRINTER READY BIT RZ ;THIS IS THE BUG MVI A, 0FFH ;ELSE RETURN FF RET Note that if the bit 3 is zero, the routine returns garbage in A. The garbage is whatever is in port 1CH, which includes output as well as input bits. However, the zero FLAG is set properly, which is why BIOS function 4 (LIST) works OK. Ironically, if the programmer had used the usual ANI insruction instead of the Z-80 fancy bit test, he would have saved two bytes as well as get the right response. The bug is in the ROM, so can't be easily fixed. The patch is easy, though - Change the jump vector in the BIOS to: JMP PATCH and add: PATCH: CALL 0FB65H ;call old bios entry RNZ ;OK unless its zero XRA A ;else clear A RET ;that's all, folks - Jack Crenshaw 2-Mar-84 08:25:38-MST,802;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 2 Mar 84 08:25:32-MST Date: Fri, 2 Mar 84 9:07:21 EST From: Dave Towson (info-cpm) To: info-cpm@amsaa Subject: [Mike Donegan: Re: Z80 Plus Board by Applied Engineering] ----- Forwarded message # 1: Received: From rice-gateway.ARPA by AMSAA via smtp; 1 Mar 84 18:54 EST Received: from invader by RICE (AA19334); Thu, 1 Mar 84 17:51:52 cst From: Mike Donegan Received: by invader (AA04725); 1 Mar 84 12:55:31 PST (Thu) Date: 1 Mar 84 12:55:31 PST (Thu) Subject: Re: Z80 Plus Board by Applied Engineering To: info-cpm-request@AMSAA.ARPA Message-Id: <8403012055.AA04725@invader> The catch is no CP/M. mkd ----- End of forwarded messages 2-Mar-84 13:53:00-MST,745;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 2 Mar 84 13:52:56-MST Received: From Brl-Vgr.ARPA by AMSAA via smtp; 2 Mar 84 15:34 EST Received: From Rutgers.ARPA by BRL-VGR via smtp; 2 Mar 84 14:00 EST Received: from RU-BLUE.ARPA by RUTGERS.ARPA with PUP; 2 Mar 84 13:27:30 EST Date: 2 Mar 84 13:18:59 EST From: FRIEDMAN@RU-BLUE.ARPA Subject: Apple Z80 board To: info-cpm@BRL-VGR.ARPA cc: info-apple@BRL-VGR.ARPA The Applicards will not run the Microsoft Softcard version of Mbasic. It will, however run the standard CPM version. This is probably due to the separate memory on the AppliCard. -Gadi ------- 2-Mar-84 18:43:05-MST,938;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 2 Mar 84 18:43:01-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 2 Mar 84 20:22 EST Received: From Simtel20.ARPA by BRL via smtp; 2 Mar 84 19:59 EST Date: 2 Mar 1984 18:16 MST (Fri) Message-ID: From: "Frank J. Wancho" To: decvax!linus!utzoo!utcsstat!ian@ucb-vax Cc: INFO-CPM@brl Subject: CP/M RBBS4 In-reply-to: Msg of 28 Feb 1984 12:53-MST from decvax!linus!utzoo!utcsstat!ian at ucb-vax I *know* that those of you who follow the development history of certain programs may not like to see this pattern continued, but... if you can wait a couple of days, I'll have RBBS 4.1 Edit 00 (or 01) ready for release. This version has two significant changes or enhancements, and a couple of bugs fixed. So, standby... it should be ready Monday... --Frank 5-Mar-84 09:10:20-MST,1007;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 5 Mar 84 09:10:10-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 3 Mar 84 5:26 EST Received: From Mit-Mc.ARPA by BRL via smtp; 3 Mar 84 5:21 EST Date: 3 March 1984 02:23-EST From: Jerry E. Pournelle Subject: new Kaypro IV To: INFO-CPM@mit-mc Apologies to those on info-mac also. Kaypro IV 1984 model now available. Neat. 4 mhz z-80, built-in modem, nice screen, character set from the 10 (clean and nice), 2 serial and one centronics ports. Still no 8" disk connector (but there's an after market source) for that as well as for an external video connector). Usual ton of software: Perfect everything, WordStar, Microsoft Basic, CBASIC, SBASIC (compiled structured; not bad if a bit obscure syntax at times; true local variables, etc.) Chang Labs spreadsheet. Costs more than the older IV, but in my judgment worth it. Good beginning writer's machine. 5-Mar-84 09:10:51-MST,1192;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 5 Mar 84 09:10:29-MST Received: From Mit-Mc.ARPA by AMSAA via smtp; 3 Mar 84 19:42 EST Date: 3 March 1984 19:43-EST From: Keith Petersen Subject: Why MDM724.HEX doesn't match one you made with ASM To: CENT.MBECK%mit-oz@AMSAA.ARPA cc: Info-Cpm@amsaa In-reply-to: Msg of Sat 3 Mar 84 13:35:54-EST from Mark Becker The MDM724.HEX file on SIMTEL20 and MIT-MC was generated with UNLOAD.COM from MDM724.COM which was "loaded" with MLOAD14.COM. Reasons: The hex file produced by ASM (or most any other CP/M assembler) is full of "holes" where "DS" statements occur in the source code. When you use DR's LOAD.COM to make a .COM file from this, you get "garbage" from memory in these areas and the result is that the CRC of the .COM file will not match the distributed version of the .COM file which was made with MLOAD14 (MLOAD14 puts all zeros into DS areas). So, to assure that everyone would have the same .COM file as the one on SIMTEL20 and MIT-MC, I uploaded the UNLOADed one, not the one from the assembler. --Keith 5-Mar-84 09:11:01-MST,1032;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 5 Mar 84 09:10:48-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 4 Mar 84 3:03 EST Received: From Sri-Sprm.ARPA by BRL via smtp; 4 Mar 84 2:57 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 3 Mar 84 23:55-PST Date: 29 Feb 84 20:37:46-PST (Wed) To: info-cpm@brl From: luria@ucb-vax Subject: Re: Kaypro, Perfect Writer, and superscripting problem Article-I.D.: ucbvax.224 In-Reply-To: Article <210@dutesta.UUCP> Perfect Printer skips a line when using superscripts. This looks pretty bad even when I am double spacing, but is unusable when single spacing. I'd rather not have to use brackets. My printer an Epson Rx-80 allows for superscripting, and they also have a condensed mode which would allow me to have half size footnotes. However, the Perfect Writer Installation Disk, does not give me any options as to how I can change the character codes for superscripting. Any suggestions? 5-Mar-84 09:11:19-MST,1003;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 5 Mar 84 09:11:14-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 4 Mar 84 4:09 EST Received: From Sri-Sprm.ARPA by BRL via smtp; 4 Mar 84 4:01 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 4 Mar 84 0:56-PST Date: 29 Feb 84 16:26:03-PST (Wed) To: info-cpm@brl From: ihnp4!houxm!hogpc!pegasus!lzmi!rob@ucb-vax Subject: looking for programs written in CBASIC Article-I.D.: lzmi.189 [this space available] I have just gotten the CBASIC compiler for my micro, and am looking for source, or pointers to source, for any public-domain CBASIC programs that might be available. I will accept pointers to source programs written for the CBASIC interpreter, as the conversion from one to the other is trivial. I will also take pointers to any BBS that may contain what I am after. Please reply directly by mail, or call at (201)576-2711. Thanks in advance.......Rob Coben 5-Mar-84 09:11:51-MST,3385;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 5 Mar 84 09:11:35-MST Received: From Usc-Isid.ARPA by AMSAA via smtp; 4 Mar 84 12:24 EST Date: 3 Mar 1984 23:09-PST Sender: ABN.ISCAMS@usc-isid Subject: MDM724 From: ABN.ISCAMS@usc-isid To: INFO-CPM@amsaa Cc: W8SDZ@mit-mc Message-ID: <[USC-ISID] 3-Mar-84 23:09:26.ABN.ISCAMS> NetLandians, MDM724, as downloaded in .ASM form from SIMTEL20 MICRO:, works perfectly. (I expected no less!) I used the old original overlay for my Morrow Decision I (not the easiest computer to interface with port I/O), and it meshed right in. (Good idea, that constancy with the same overlays.) I added one wee little thing for you people trying to work via micro and MDM7xx through a TAC. As you know, the TAC has an Intercept Character (mine uses the @ sign), and it WILL choke up during normal uploads unless special precau- tions are taken (change the intercept sign to something unused, turn it OFF!, etc.). I got a simpler fix, and it takes about a couple dozen bytes. At the two parts in MDM where it gets ready to send a character out as part of a file upload (T mode and S mode), simply check the character to be sent. If it's your intercept character...send it twice! I'll be pushing up a more thorough patch in a couple of days that'll add a toggle to your MDM menu, so you can turn the character on and off, or change as needed. (Don't want to be sending two @'s to your local CBBS!) Exact locations for the simple quick-fix are: SEND80C:..... SENDCH1: PUSH D CALL SPEED POP D MOV A,M CPI EOFCHAR RZ ***Here's where to put the little patch: CPI '@' ;is it the Intercept Char? CZ MODOUT ;yup, let the MODOUT segment do its thing. ...and fall right through to the rest of the stuff. The only thing cut out is SPEED, but you shouldn't need that just to reach to the TAC. That takes care of a Terminal T mode send; now for the error-trapping send (S)... Way down, find... MONOUT: .... NOMONOUT:POP PSW ;doing this 'cause the char involved is in A PUSH PSW *** Here's where we put the TAC Trap... CPI '@' ;is it the Intercept char? JNZ SENDW ;nope, skip this mess TRAP: CALL SENDRDY ;we have to check for modem ready too. JNZ TRAP ;we're in effect duplicating all in SENDW since we POP PSW ;can't call SENDW to do the work for us. PUSH PSW ;gotta put it back where SENDW expects to POP it. CALL OUT$MODDATP ;send the @ out the first time... ;...and fall through to SENDW: CALL SENDRDY ;...send it the second time. JNZ SENDW POP PSW JMP OUT$MODDATP Here's an actual demo -- I fired it right up into XED on my host through my TAC here at Ft Bragg. Engaged F I S (flow control in the TAC so it'll XON/XOFF MDM724 immediately and not overflow the TAC keyboard buffer). As you can see, the @'s made it just fine. Watching it on the screen as it uploaded, I could see 2, 4, 6, and 8 @'s upload. This is to test out the World Famous Toad Hall TAC Trap newly installed in MDM724.COM. @ one at @@ two ats @@@ three ats @@@@ four ats Sorry for overflowing your mailboxes, but sure do work good! Regards, David Kirschbaum Toad Hall 5-Mar-84 09:12:08-MST,557;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 5 Mar 84 09:11:56-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 4 Mar 84 22:40 EST Date: Sun, 4 Mar 84 22:36:56 EST From: Richard G Turner To: info-cpm@brl Subject: BYE3 on the KAYPRO II I finally got BYE319 running on my KAYPRO II. The problem turned out to be the cable that I was given with the system for my modem. Seems that it didn't have all the right connections. Overlooking the obvious... rick 5-Mar-84 11:25:47-MST,978;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 5 Mar 84 11:25:41-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 5 Mar 84 13:12 EST Received: From Parc-Maxc.ARPA by BRL via smtp; 5 Mar 84 12:57 EST Date: Mon, 5 Mar 84 09:38 PST From: Eldridge.es@PARC-MAXC.ARPA Subject: L80 patches To: info-cpm@brl.ARPA cc: es820ug^.es@PARC-MAXC.ARPA Reply-To: Eldridge.es@PARC-MAXC.ARPA I sent this message once befor and got no response, so I'll try again. I am using Link-80 3.44 09-Dec-81. It appears that L80 does a disk reset and relogs the disk every time it accesses a new REL file. This becomes very time consuming when you have a hard disk with a large directory since it must regenerate the allocation map every time it resets the disk. Is there a patch to modify this behavior? It seems that all the disk relogging is unnecessary and could be patched out. George (Eldridge.es@PARC-MAXC.ARPA) 5-Mar-84 16:07:50-MST,967;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 5 Mar 84 16:07:42-MST Received: From Brl-Vgr.ARPA by AMSAA via smtp; 5 Mar 84 17:57 EST Received: From Rand-Unix.ARPA by BRL-VGR via smtp; 5 Mar 84 17:48 EST Date: Monday, 5 Mar 1984 14:44-PST To: Jerry E. Pournelle Cc: w8sdz@brl, Info-Cpm@brl-vgr Subject: Re: Kaypro BIOS list bug In-reply-to: Your message of 2 March 1984 07:03-EST. From: Bridger_Mitchell The Kaypro 4-84 (new model with built-in modem and clock) uses different boot-rom code from both the Kaypro II and old Kaypro 4. Each had a somewhat different bug in handling the bios list-status function. We (Plu*Perfect Systems) recently wrote the foreign-language versions of the bios for this machine for Kaypro and corrected the boot-rom. The change is supposed to go into the domestic machines too, but I can't verify that. --bridger mitchell 6-Mar-84 08:15:07-MST,1289;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 6 Mar 84 08:14:48-MST Received: From Sumex-Aim.ARPA by AMSAA via smtp; 5 Mar 84 20:45 EST Received: from ISL by SUMEX-AIM with Pup; Mon 5 Mar 84 17:44:33-PST Date: Monday, 5 Mar 1984 17:45-PST To: info-cpm@amsaa Subject: Alignment of disk drives with DDD (Dysan Diagnostic Disk) From: meier%isl@AMSAA.ARPA X I am trying to use DDD version 1.1 and Dysan Diagnostic Disk to align a pair of Shugart 800 disk drives with a Disk Jockey 2D Controller. I think that I have set the constants in DDD appropriately and I have been able to adjust the disks so that they pass the DDD tests, but there has been no noticeable improvement in the performance. I have been unsuccessful thus far, but I suspect that the major problem is that I don't understand the readings that I am getting from DDD. In particular, what are reasonable readings when doing the centering test. The current symptoms are that I get a BAD SECTOR error about once every 12 hours with single density and with double density, the surface of the disk inside the about track 10 is all BAD SECTORS. I would appreciate any help or suggestions that anyone is willing to offer. Bob (isl!meier@shasta) 6-Mar-84 08:15:14-MST,943;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 6 Mar 84 08:15:08-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 5 Mar 84 22:28 EST Received: From Stl-Host1.ARPA by BRL via smtp; 5 Mar 84 22:26 EST Date: 5 Mar 1984 21:28 CST (Mon) Message-ID: From: WANCHO@stl-host1 To: INFO-CPM@brl Subject: RBBS 4.1 Edit 00 The subject file has now been released and is available on the SIMTEL20 in MICRO:RBBS4100.LBR, and temporarily in MC:FJW;RBBS41 00LBR. The individual files will be available in the SIMTEL20 directory sometime Tuesday. Other places include the SENECA RCP/M at 915-598-1668 in E0:, and LAZARUS RCP/M at 915-544-1432 in H0:. There are two significant new features, a couple of new options, and several obscure and not so obscure bugs finally fixed. This ought to hold for a while (I hope). --Frank 6-Mar-84 08:15:42-MST,1789;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 6 Mar 84 08:15:18-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 5 Mar 84 22:41 EST Received: From Csnet-Relay.ARPA by BRL via smtp; 5 Mar 84 22:37 EST Received: by csnet-relay via xumass-cs; 5 Mar 84 19:54 EST Date: Mon, 5 Mar 84 14:16 EST From: Bruce Hawkins To: info-cpm%brl.arpa@csnet-relay.arpa Subject: Bugs in Turbo Pascal I am generally pleased with Turbo Pascal, especially its fast compilation, but I have found two compiler bugs, both of which had easy work arounds. The first is that it wold not accept the declaration of a particular text file variable until I moved it to a non-standard place ahead of the TYPE declarations (which is a legal extension to Turbo Pascal). It accepts other similar declarations in other programs, so the exact cause of the bug is unknown. (It would not accept it when simply moved to a different place among the VAR declarations--I did not try all possible such places!) The second cost me a lot of time finding. Don't: Type Junk = record ... Name : Array [1..3] of Char; ... End; Var Iron : Junk; . . . Iron.Name := 'met'; Iron.Name containis random garbage. The work-around is: Type as above . . var temp : Array [1..3] of char; . . temp := 'met'; Iron.Name := temp; Iron.Name is now 'met' as was intended. I don't have time to go poking around in Jenkins and Wirth to be sure what is legal, but if the code isn't legal, the compiler should give a syntax error message instead of being silent as the grave. From the Rainbow of Bruce Hawkins bhawkins.umass-cs@csnet-relay 6-Mar-84 08:16:23-MST,880;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 6 Mar 84 08:16:19-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 6 Mar 84 1:42 EST Received: From Mit-Mc.ARPA by BRL via smtp; 6 Mar 84 1:32 EST Date: 6 March 1984 01:33-EST From: Jerry E. Pournelle Subject: Bugs in Turbo Pascal To: bhawkins%umass-cs.csnet@csnet-cic cc: info-cpm@brl In-reply-to: Msg of Mon 5 Mar 84 14:16 EST from Bruce Hawkins 1. I would appreciate hard copy of any Turbo Pascal bugs (send to me C/O BYTE, POB 372, Hancock NH 03449); 2. Phillippe Kahn of Borland seems extraordinarily eager to fix any problems with his system; if you inform him of bugs, he may well get fixed before release. 3. In bug repors, please specify whether z-80 or 8088 version... thanks 6-Mar-84 08:17:16-MST,1310;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 6 Mar 84 08:17:07-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 6 Mar 84 7:08 EST Received: From Brl-Bmd.ARPA by BRL via smtp; 6 Mar 84 7:01 EST Date: Tue, 6 Mar 84 6:53:30 EST From: Charlie Strom (NYU) To: Jerry E. Pournelle cc: INFO-CPM@brl Subject: Re: Bugs in Turbo Pascal You might want to point out to Mr. Kahn that there is a serious bug in his advertising - nowhere does it indicate that his 8 bit Turbo Pascal is written in Z80 code rather than 8080. It would certainly be a logical assumption that if unspecified, it is indeed 8080, since it is advertised to run under CP/M-80. Another foolishness that irks me (unrelated to the above issue) is that it seems to be getting more and more difficult to determine exactly what machine an advertised package is targeted to. This seems particularly rampant among the vendors of Apple software. The implicit assumption that the target machine is clearly the only machine worth writing software for is ridiculous. How difficult would it be to specify in a single sentence what micro the software is designed for, as well as operating system, ram, and I/O requirements? 6-Mar-84 16:16:57-MST,1301;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 6 Mar 84 16:16:53-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 6 Mar 84 17:50 EST Received: From Cisl-Service-Multics.ARPA by BRL via smtp; 6 Mar 84 17:38 EST Received: from HIS-PHOENIX-MULTICS.ARPA by CISL-SERVICE-MULTICS.ARPA dial; 06-Mar-1984 17:33:59-est Date: Tue, 6 Mar 84 15:30 MST From: Brzozowski%his-phoenix-multics.arpa@BRL.ARPA Subject: How long does it take to get Turbo Pascal? To: info-cpm@BRL.ARPA Message-ID: <840306223016.817827@HIS-PHOENIX-MULTICS.ARPA> Hearing all the excitement about Turbo Pascal, I ordered a copy for MS-DOS, over 3 weeks ago and still not have received it. I realize that is still a short time for most companies, but I have heard of people getting it in less than a week! All of these people ordered it for an 8-bitter, so I am not sure wether I have just ordered the version that is in demand, or my order got lost. Has anyone out there got the MS-DOS version and how long did it take to get it? (It feels funny to hear the ranting and raving of people who ordered the package long after I did) Thanks Much! Gary Brz... (Brzozowski.RPMtnd%pco at cisl) 6-Mar-84 17:26:34-MST,1690;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 6 Mar 84 17:26:28-MST Received: From Parc-Maxc.ARPA by AMSAA via smtp; 6 Mar 84 19:00 EST Date: Tue, 6 Mar 84 14:58 PST From: MMOON.ES@PARC-MAXC.ARPA Subject: Re: Alignment of disk drives with DDD (Dysan Diagnostic Disk) In-reply-to: "meier%isl@AMSAA.ARPA's message of Mon, 5 Mar 84 17:45 PST" To: meier%isl@AMSAA.ARPA cc: info-cpm@amsaa.ARPA You certain that an alignment problem exists? Do the drives perform the same warm as they do cold? Morrow's data seperator on my controller  like most designs of two to three years ago-- uses a digital phase detector which is temperature dependent to a very high degree. This information comes from the close analysis of a friend doing circuit design for Western Digital. Also, which DJ2D are you running? The memory mapped version, the I/O mapped version *without* DMA, or the I/O version *with* DMA. Many of the non-DMA, I/O mapped controllers had layout errors on the board which were corrected via cut & jumper; my own had, I believe, six jumpers, but one pair of cuts had been left out. They turned out to be the triggers to the one-shots controlling the write-gate window for write pre-comp. Failure to make those cuts eventually cost me the 1791 controller. (Note that this board was purchased as-is with my full knowledge that design problems could exist. Very few if any of these were, to my understanding, sold without such information provided. Morrow enjoys my high regard.) My friend from Western Digital found the missing cuts & things seem to have settled down considerably. MMoon.es 6-Mar-84 17:51:57-MST,3295;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 6 Mar 84 17:51:49-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 6 Mar 84 19:34 EST Received: From Parc-Maxc.ARPA by BRL via smtp; 6 Mar 84 19:31 EST Date: Tue, 6 Mar 84 16:07 PST From: MMOON.ES@PARC-MAXC.ARPA Subject: Re: Bugs & related flames In-reply-to: "strom@brl-bmd.ARPA's message of Tue, 6 Mar 84 6:53:30 EST" To: Charlie Strom (NYU) cc: Jerry E. Pournelle , INFO-CPM@brl.ARPA Borland's got some surprising company with their product description problem. Read on. Flame #1: I have been trying to get information on what CCP/M is and is not, what it takes to port the same, & what a couple of particular ports are and do. DRI has not, after no fewer than four requests, responded with so much as advertising copy, let alone literature useful to an integrator. I can't buy their manuals anymore, so how am I supposed to evaluate the product's usefulness to me? Other vendors supply reasonable product information (sometimes gratis), what's the lever that works on DRI? Flame #2: Octagon Systems advertises what appears to be the most viable alternative to bank-breaking investments in Compupro equipment since the invention of the dual processor. Wonderful published specs. Can I get a demo from Priority One, who offers Ocatgon stuff? "Nope, no demo system available." Can I buy the manual advertised in their catalog. "Nope, all out." Can I get definitive literature from Octagon (i. e., a written commitment on what their system is/is not, etc., or failing that, at least a complete description of capabilities). "Yes, sir. We'll send it out today." That was three weeks ago & it ain't here yet, after the second request. I have had good dealings with Priority One, and must assume they're in the same fix. I conclude (sic) that either Octagon products are mythical as the unicorn, the best thing since sliced bread & therefore sell faster than made, or so full of bugs they're not really in production, despite the glossy advertising. Anybody on this net know these guys? Last Flame: We have all heard Good Things about Gifford & their software for Compupro stuff. I tried calling the L. A. Gifford number for literature on their software & got lots of soft sell, a long converstion on "my needs", and no literature. What have they really done to/for MP/M-86 (if I could find out what it is in the first place)? What is the party line on what is required to run their port of the same? What are the options? My advice, if you live in L. A., is don't ask unless you have lotsa dollars to find out. If their is a common thread in any of the above, it is that many companies out there on the edge look flaky. Octagon, Giiford, & DRI may all have cases of oversupply-of-demand, but all at once, and for four (count 'em) months? They may indeed have competent products produced by good people, but from the point of view of a little-guy end user, who could tell? Anybody out there got a fomula  magic or otherwise  for making the determination? I have to live with expensive decisions on these guys for a long time. MMoon.es@parc-maxc.apra 6-Mar-84 18:37:42-MST,885;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 6 Mar 84 18:37:38-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 6 Mar 84 20:09 EST Received: From Sumex-Aim.ARPA by BRL via smtp; 6 Mar 84 20:06 EST Date: Tue 6 Mar 84 17:06:20-PST From: Leslie Zatz Subject: MACINTOSH To: info-cpm@BRL.ARPA Does anyone have any perceptions of the MACINTOSH they are interested in sharing? I am particularly interested in: 1. Will it be able to take a hard disk? Via the serial port or the second floppy port? If serial, will it be ffast enough? 2. Only 128k main memory. Can virtual memory be used thru seriaal port and will that work for DBMS's? Some systems require minimum of 500 K. 3. How good is MACWRITE? 4. If you don't want to draw pictures, is MACPAINT of any value? ------- 6-Mar-84 19:06:55-MST,1139;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 6 Mar 84 19:06:51-MST Received: From Sumex-Aim.ARPA by AMSAA via smtp; 6 Mar 84 20:49 EST Date: Tue 6 Mar 84 17:48:57-PST From: Sam Hahn Subject: Really big files To: info-cpm@AMSAA.ARPA cc: POURNE@MIT-MC.ARPA, shahn@SUMEX-AIM.ARPA, info-micro@BRL-VGR.ARPA HELP! I've got a file that's about 400kbytes big. Problem is that I've got to port it from my SDSystems hidensity disk format to a Compupro disk. Can't transport it in SSSD. What do people suggest? I've tried a PD Huffman-code PACK and UNPACK combination, but there's a bug in UNPACK, and it won't reconstruct the file correctly. Later this week, I'm going to try a program which renames each extent, and then after PIPing it to a couple of SSSD didks, rename the extents back into one file, and hope that doesn't clobber too much. Are there problems with this approach (eg. file header crc's?) that I'm not seeing? Does anyone else have suggestions? Has anyone had this same problem before? Thanks, sam hahn ------- 6-Mar-84 19:13:19-MST,1141;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 6 Mar 84 19:13:14-MST Received: From Sumex-Aim.ARPA by AMSAA via smtp; 6 Mar 84 20:50 EST Received: from ISL by SUMEX-AIM with Pup; Tue 6 Mar 84 17:49:27-PST Date: Tuesday, 6 Mar 1984 17:50-PST To: info-cpm@amsaa Subject: Disk Alignment From: meier%isl@AMSAA.ARPA X I am placing this message on the net instead of direct in the event that is of public interest. MMoon.es, Thank you for responding. I am not certain that the problem is one of alignment, this was my best guess at the problem. In response to your questions: o The performance is not noticably dependent on whether the drives are warm or cold o The DJ2D board is memory mapped and is engaged by subroutine calls to an onboard prom (E000-FFFF) The major factor affecting performance is whether single density or double density is being used. There are far fewer bad sectors at single density than at double density. Unfortunately, the CP/M with the DJ2D will not fit on the first two tracks in single density. Bob (isl!meier@shasta) 6-Mar-84 22:11:16-MST,1409;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 6 Mar 84 22:11:11-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 6 Mar 84 23:50 EST Received: From Mit-Mc.ARPA by BRL via smtp; 6 Mar 84 23:41 EST Date: 6 March 1984 23:41-EST From: Jerry E. Pournelle Subject: Bugs & related flames To: MMOON.ES@parc-maxc cc: INFO-CPM@brl, strom@brl-bmd In-reply-to: Msg of Tue 6 Mar 84 16:07 PST from MMOON.ES at PARC-MAXC.ARPA DRI Concurrent exists for PC, and is pretty damned good. I think probably wave of the future. About Octogon I know nothing. Gifford MP/M is said to work; Jim Hudson is using it. I am using CP/M 8/16 because it is faster and I have Tony Pietsch's new TMX Bios for it. 8/16 with Compupro hard disk is just plain GREAT, if you're willing to put up with some of CP/M's quirks. Alas, some of these are quirks I am not used to because Tony used to trap them in the BIOS and you can't do that in 8/16. However, Compupro has bouth the source to CP/M and is contemplating doing a few nice things to the Command Processor to make it a little friendlier; but that's a Real Soon Now project, and I have no clues as to when it will be available, or even that they won't shelve it for another project; I expect to have Concurrent running on my big system Real Soon Now. It runs on the IBM PC fine. 6-Mar-84 22:24:38-MST,877;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 6 Mar 84 22:24:34-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 7 Mar 84 0:01 EST Received: From Mit-Mc.ARPA by BRL via smtp; 6 Mar 84 23:51 EST Date: 6 Mar 84 23:50:41 EST From: Liz Subject: Do you know of a c that....? To: INFO-IBMPC@USC-ISIB.ARPA, INFO-CPM@MIT-MC.ARPA, INFO-MICRO@BRL-VGR.ARPA, INFO-UNIX@BRL.ARPA We here at Smaug are in need of a C for the IBM-PC that will link with assembler routines. It also should be close to the standard, have enumerated types, and have all possible libraries (numerical stuff is not real necessary). Actually we are looking for the moon on a silver platter. Oh yes...also fast and efficient. Please reply directly to me sommers@Rutgers or Smaug@Rutgers ------- 7-Mar-84 10:45:06-MST,742;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 7 Mar 84 10:44:52-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 7 Mar 84 2:38 EST Received: From Mit-Mc.ARPA by BRL via smtp; 7 Mar 84 2:30 EST Date: 6 March 1984 23:47-EST From: Jerry E. Pournelle Subject: How long does it take to get Turbo Pascal? To: Brzozowski%his-phoenix-multics.arpa@brl cc: info-cpm@brl In-reply-to: Msg of Tue 6 Mar 84 15:30 MST from Brzozowski%his-phoenix-multics.arpa at BRL.ARPA I suspect they delayed shipping your order so that they could include the update version which they are sdaid to be putting out this week. That's assuming your order got through the US Snails. 7-Mar-84 10:45:12-MST,815;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 7 Mar 84 10:45:02-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 7 Mar 84 8:15 EST Date: Wed, 7 Mar 84 8:05:40 EST From: Keith Petersen To: MMOON.ES@parc-maxc.arpa cc: Info-Cpm@amsaa Subject: How to get DR books - an alternative Intel has apparently become an OEM for DR CP/M software. They support CP/M on their development systems and many of the manuals can be purchased at your local Intel rep. I bought the M80/L80 and BASIC-80 compiler manuals from the Detroit Intel rep for a client who wanted to evaluate those packages. The books have an Intel cover and Intel order number, but are identical to the ones supplied by DR with those packages. --Keith 7-Mar-84 10:45:15-MST,1249;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 7 Mar 84 10:45:05-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 7 Mar 84 7:15 EST Received: From Brl-Bmd.ARPA by BRL via smtp; 7 Mar 84 7:08 EST Date: Wed, 7 Mar 84 6:59:42 EST From: Charlie Strom (NYU) To: MMOON.ES@parc-maxc.arpa cc: INFO-CPM@brl Subject: Re: Bugs & related flames I can address your problems with Gifford. I suggest that you call the San Leandro main office number. My dealings with them since I purchased a large system in the early summer have been excellent. They are indeed suffering from growing pains, but I have a high regard for them and their technical capabilities and their heart is in the right place. Bear in mind that as hackers, we are not likely to get the inside dope from Giffoed when it comes to explaining the innards of MP/M-816. This company is not dedicated to serving hackers, rather their expertise lies in dealing with less technical people who want to get the job done and are not interested in the inner workings of the operating system. I wish this were different, but I certainly see their point and can respect their position. 7-Mar-84 10:45:19-MST,628;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 7 Mar 84 10:45:11-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 7 Mar 84 8:51 EST Date: Wed, 7 Mar 84 8:12:03 EST From: Keith Petersen To: MMOON.ES@parc-maxc.arpa cc: Info-Cpm@amsaa Subject: Alternative source for manuals Correction to my previous message. Please substitute Microsoft for DR. It's possible that Intel also offers books for the DR software since they do support CP/M on their development systems. It's certainly worth a call to your local rep. to find out. 7-Mar-84 10:45:23-MST,1039;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 7 Mar 84 10:45:17-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 7 Mar 84 8:52 EST Date: Wed, 7 Mar 84 8:21:53 EST From: Keith Petersen To: Sam Hahn cc: Info-Cpm@amsaa Subject: Re: Really big files You mentioned a bug in "UNPACK". Are you talking about SQUEEZE and UNSQUEEZE (Richard Greenlaw's PD CP/M-80 programs)? If so, the problem is in SQ.COM if you have a version before 1.5. The problem was that the SQueezer overflowed the 16-bit counter used during the packing process. This happened only occasionally and with only certain types of files. The latest versions for SQ and USQ are SQ-17.COM and USQ-20.COM. They're available via FTP from SIMTEL20 in the MICRO: directory, or if you cannot FTP you can get them from many RCPM systems, including my own Royal Oak (MI) system at 313-759-6569 (they're on the B: drive there). --Keith 7-Mar-84 10:45:39-MST,746;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 7 Mar 84 10:45:24-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 7 Mar 84 8:54 EST Date: Wed, 7 Mar 84 8:27:21 EST From: Keith Petersen To: meier%isl@amsaa.arpa cc: Info-Cpm@amsaa Subject: DJ2D disk alignment If your problem is important enough to warrent spending money on a phone call, I'd suggest that you talk to Dave Hardy at CDP, Inc. in Dearborn, Mi. They've been using the DJ2D commercially as an OEM for many years and they also operate a floppy disk drive repair service. You can reach Dave Hardy Monday through Friday from Noon to about 8 p.m. (e.s.t.) at 313-846-1055. --Keith 7-Mar-84 13:08:13-MST,989;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 7 Mar 84 13:08:09-MST Received: From Simtel20.ARPA by AMSAA via smtp; 7 Mar 84 14:46 EST Date: Wed 7 Mar 84 12:46:29-MST From: Keith Petersen Subject: Using MDM727 with Cromemco CDOS To: Info-Cpm@AMSAA.ARPA Date: Wed, 7 Mar 84 From: Keith Petersen, W8SDZ To: All Subject: Using MDM727 with Cromemco CDOS CDOS users: Get M7CD-1.ASM, the overlay for Cromemco systems. After you overlay MDM727.COM using DEBUG, patch the following locations to NOPs (binary zeros): 2E4C, 2E4D, 2E4E, 2E4F. This will disable the CP/M disk stat call function 1Fh which is not implemented in the current version of CDOS. The MDM727 DIR function will then work, but will show 0k left on the disk. That's livable, and certainly better than before when CDOS gave an error message and jumped out of MDM727 to return to the system. --Keith ------- 7-Mar-84 14:22:44-MST,1377;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 7 Mar 84 14:22:39-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 7 Mar 84 15:44 EST Received: From Mit-Mc.ARPA by BRL via smtp; 7 Mar 84 15:33 EST Received: from ucbarpa.ARPA by UCB-VAX.ARPA (4.22/4.25) id AA08028; Wed, 7 Mar 84 01:00:41 pst Received: by ucbarpa.ARPA (4.22/4.25) id AA18787; Wed, 7 Mar 84 01:01:58 pst Date: Wed, 7 Mar 84 01:01:58 pst From: David Allen Gewirtz Message-Id: <8403070901.AA18787@ucbarpa.ARPA> To: INFO-CPM@MIT-MC.ARPA, INFO-IBMPC@USC-ISIB.ARPA, INFO-MICRO@BRL-VGR.ARPA, INFO-UNIX@BRL.ARPA, SOMMERS@RUTGERS.ARPA Subject: Re: Do you know of a c that....? Mygosh..sorry about those of you who receive multiple copies of this... The Lattice/Microsoft compiler does lots of what you need, including linking with an assembler (but I'm not sure about enumerated types). You can also buy outside libraries from Blaise Computing and Greenlead Software that has lots of nice library functions...see PC Tech Journal.. Now, for your math goodies, here's a real out of this world reference for you...A local bulletin board system has a whole lot of mathematics subroutines (arcsine and other mean, nasty, and ugly things)..It is in the SF Bay area at 415-864-1418..and the rest is up to you. 7-Mar-84 19:44:29-MST,4755;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 7 Mar 84 19:44:16-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 7 Mar 84 21:20 EST Received: From Mit-Mc.ARPA by BRL via smtp; 7 Mar 84 21:20 EST Received: from RU-BLUE.ARPA by RUTGERS.ARPA with PUP; 7 Mar 84 21:18:04 EST Date: 7 Mar 84 18:10:41 EST From: Seymour Subject: Octagon Hardware To: info-cpm@MIT-MC.ARPA cc: stillman@RU-BLUE.ARPA, joseph@RU-BLUE.ARPA On the reality and availability of Octagon hardware: We in the Rutgers Microcomputer Lab had been looking for a big hard disk system for one of our bulletin board RCP/M computers for many moons. We too were attracted by the glossy advertisements from Octagon promising a complete 16Mb hard disk subsystem with BIOS for a reasonable price. My first call to Octagon got me copies of the technical manuals for everything they make! I only asked about the hard disk subsystem for a Z80 but I got specs on their 8/16 dual processor board and assembly listings for both their 8080 and 8088 BIOS'. They were friendly and helpful on the phone and were at CP/M 83 (a big trade show) with some of their equipment. After consulting with the person who wrote their BIOS to make sure it would suit our purpose, we ordered one. The Octagon Hard disk subsystem arrived in a reasonable time but showed signs of being an early product. The packaging was not great. There were no physical assembly instructions; I had to call them to find out which cable went where and which orientation was right for the plugs. There was documentation on how to install the software and after we had followed it to the letter three or four times without success, I called Octagon again. They were helpful but were unable to solve the problem over the phone. The gentleman who wrote their BIOS asked me to send back to whole thing and include a listing of our original floppy BIOS (to which his was supposed to attach but didn't). We sent the whole kit and kaboodle back to Octagon and waited. About a week later (rather reasonable turnaround actually) I got a DHL courier express package with the whole subsystem in it. It seems our BIOS does things a little differently than Octagon had assumed (don't they all) and their attach BIOS would not work. They had >rewritten< their BIOS for us and would we please test it and tell them how it went. I for one was surprised and pleased when we hooked it all back up and it WORKED! We had been playing with it for so long without luck the first time that we were just dying to see that little "In-use" LED light up. Some more extended playing with the system exposed another problem, files would disappear from the hard disk or would fail to PIP properly. Octagon suggested reformatting the disk and trying again. Formatting the disk revealed several areas of the disk that would not format correctly. We suspected a bad disk until we tried formatting the disk when the system was cold. It seemed to format OK cold but if the system had been on for a while, it failed. Octagon customer support thought it was probably a failing heat-sensitive component on the hard disk controller board (a reasonable assumption). They express-shipped us one the next day. After trying the new board and getting identical results, another call to Octagon got us a new drive unit, again shipped overnight at no charge to us. Exchanging the drive has fixed the last problem and we are now revelling in the speeds of Wordstar and Mince on hard disk. The whole system has been running for about a week now with no new problems and we are very satisfied with it. It is small, it is fast and it works. Overall, I got these impressions of Octagon: 1) Yes, its a rather new product. But, it definitely exists. They said on the phone that they had about 25 of them successfully running in Z80 systems. 2) They are a young company that has not reached the point of user unfriendliness we hear about DRI or Micropro. They are willing to help and to spend their time and effort to get things solved. I could expect no better. I personally would rather deal with a smaller company even if it did make mistakes occasionally, than with a monster like IBM or DEC. (which by the way have also been rumored to have made mistakes). 3) Anytime we had a problem, they acted responsibly and quickly to attempt to solve it and, although we did have an unusual number of them in installing this system, I am generally pleased by the company and the product. Seymour Joseph System Programmer / Microcomputers Rutgers University ------- 7-Mar-84 22:59:08-MST,476;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 7 Mar 84 22:59:03-MST Received: From Hi-Multics.ARPA by AMSAA via smtp; 8 Mar 84 0:40 EST Date: 7 March 1984 23:38 cst From: Eaton.HFED@hi-multics Subject: champion accounting system To: info-cpm@amsaa Does anyone have any words of wisdom concerining the "CHAMPION accounting system (dBASE runtime) and it's associated modules? Jesse (still cold - still here) 7-Mar-84 22:59:49-MST,776;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 7 Mar 84 22:59:46-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 8 Mar 84 0:40 EST Received: From Mit-Mc.ARPA by BRL via smtp; 8 Mar 84 0:31 EST Date: Thu, 8 Mar 1984 00:30 EST Message-ID: From: ANDY%MIT-OZ@MIT-MC.ARPA To: info-cpm@BRL.ARPA Subject: Old Kaypro disk fix I have one of the first Kaypros ever produced. The one with the vertical drives and brightness control on the front panel. It has this nasty habit. The motor for drive A is always on. It apparently doesn't hurt the floppy since head only comes down during an actual access, but is still bothers me. Does anyone know how to fix this? -Andy 7-Mar-84 23:00:25-MST,3041;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 7 Mar 84 23:00:16-MST Received: From Hi-Multics.ARPA by AMSAA via smtp; 8 Mar 84 0:34 EST Date: 7 March 1984 23:32 cst From: Eaton.HFED@hi-multics Subject: troubleshooting To: info-cpm@amsaa Reading through Seymour Joseph's experience with his new Octagon Hard Disk and controller prompted me to offer this tidbit of info to techies and non- techies alike. I personally have an unreasonable fear of sending my S100 boards back for repair. This especially holds true for temperature sensitive problems. If you are experiencing intermittent problems there are a few things you can try before packin' it up an' sendin' it off to who knows where for who knows how long. If you suspect heat is the problem take a hair dryer and fit the hose (please don't use a floor model) with a small diameter plastic tube using tape or whatever. Let your board cool down. Then systematically direct the heat from the hair dryer to each individual chip on the board. You can actually heat them to the point that they are too hot to touch and they should still purr without incident. If there is a bad chip on the board that's thermal sensitive you'll find it. Incidently, heat is not the only way that chips (or transistors) will fail. Cold can also be the cause of failure. At present I am using a pressurized can of freon (tape cleaner) to cool circuits. It runs down the board and gives you the impression that it will fry every living circuit on your board, but it is non conductive and does no harm. A better alternative would be to purchase a product called "circuit cooler" which will actually put frost on your precious electronic gizmos but again, no harm should be done. Please "DON'T USE COLD WATER OR ANY THING THAT MIGHT BE CONDUCTIVE." If in doubt don't use it. One last thing that you might try is tapping on each chip or banging on the edge of the board to check for poor mechanical connections, solder balls and bad chip seating in sockets. Don't use instruments made of metal for the "tap test" as a poorly placed strike could put you out of business for certain. If you wish, you may purchase commercial products at your local electronics supply house to make it all a bit more professional. I have a heater specifi- cally design to heat electronic components. And if your board(s) are burried deep inside a mainframe then it might also pay to purchase a board extender. Be careful with these because you now have no protection from inserting the board backwards in the extender. You don't need technical know-how to perform any of the above. If you localize the problem then a component is what it costs (probably cheaper than shipping your board off "UPS Blue") and your board never leaves your side. I get queasy (or is it withdrawal) when I'm without mine. Happy troubleshooting. Jesse Eaton (Mpls - where March comes in like a lion and goes out like a lion) 7-Mar-84 23:43:35-MST,1443;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 7 Mar 84 23:43:28-MST Received: From Simtel20.ARPA by AMSAA via smtp; 8 Mar 84 1:13 EST Date: Wed 7 Mar 84 23:13:15-MST From: Keith Petersen Subject: QK12 bug fix To: INFO-CPM@AMSAA.ARPA The following bug fix for Quikkey version 1.2 was obtained from a file on CompuServe. I assume it's from the author of the program. --- There is a minor bug in QK12.ASM, of interest only to those who employ USER sections. When you are done setting up the initiating and terminating keys, QK12 returns you to current drive, user 0 rather than current drive, current user. The fix is quite simple: there are three lines preceding the label "rwccp:", as shown: lda cusrdrv ani 0fh mov c,a rwccp: jmp ? The "0fh" should be changed to "0ffh" to preserve both current drive and current user. You can also patch the COM file by using DU. Find the first allocation block of QK12.COM and G to there. Then, =<0F> will point you at the op code for "mov c,a". This was byte 64 on my system, and byte 63 is the offender. Do a CH63,FF;W;X and you're in business without having to reassemble the ASM file. Please let me know if yoy run into a problem caused by this fix; I admit that I did not research it thoroughly. However, I've implemented it and have had no problems. ------- 8-Mar-84 00:00:31-MST,1184;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 8 Mar 84 00:00:20-MST Received: From Hi-Multics.ARPA by AMSAA via smtp; 8 Mar 84 1:42 EST Date: 8 March 1984 00:41 cst From: Eaton.HFED@AMSAA.ARPA Subject: re: disk editor for cpm/1791 DUU and DU2 (with more features) are indeed excellent disk editors. There is however one slight problem when dealing with disks with bad sectors. My BIOS and I assume most BIOS' trap errors and will not return the data to DUU or DU2 if one is detected. This leaves the contents of the previous read in DUU's buffer. I wrote quick and dirty DDT routines to turn off error detection while attemting to repair bad sectors and then reenable error detection when I'm done. NEVER! "That's NEVER EVER try fixing a bad track by doing: read.. write.. increment.. loop. Fix those nasty little sectors one at a time "manually". I completeletely destroyed a directory by doing the afforementioned "never ever". The error handling/reporting by those programs "should" abort loops and return error messages to the user. Jesse (who knows more than one way to destroy a disk) 8-Mar-84 07:21:10-MST,1537;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 8 Mar 84 07:21:05-MST Received: From Brl-Voc.ARPA by AMSAA via smtp; 8 Mar 84 8:53 EST Date: Thu, 8 Mar 84 8:47:56 EST From: "Ferd Brundick (VLD/LTTB)" To: info-micro@amsaa, info-cpm@amsaa cc: Meself Subject: Turbo Pascal delays Hi, I called Borland yesterday to find out what had happened to my copy of Turbo Pascal. It had been several weeks since I ordered it over the phone (using the advertised 800 number), and I hadn't been billed on my latest Visa statement. The woman at the 800 number told me to call Customer Support (I don't have their number on me right now) and the woman there was VERY helpful and friendly. She checked the records for the day that I originally placed my order and said that she couldn't find my order. She told me the usual story: they are swamped with orders, they send them out every day, and the people who take the orders have been losing them (I was apparently not the first). I then placed a new order with her and she assured me that I will receive it within 2 weeks. The point of this story is: if you ordered Turbo Pascal and haven't received it yet, try giving Customer Support a call. dsw, fferd Fred S. Brundick USABRL, APG, MD. 8-Mar-84 07:43:24-MST,1131;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 8 Mar 84 07:43:20-MST Received: From Usc-Eclb.ARPA by AMSAA via smtp; 8 Mar 84 8:59 EST Date: 8 Mar 1984 05:58-PST Sender: STANLEY@usc-eclb Subject: MODEM Hiccups From: STANLEY@usc-eclb To: info-cpm@amsaa Cc: stanley@usc-eclb Message-ID: <[USC-ECLB] 8-Mar-84 05:58:30.STANLEY> In trying to move some files from the ECLB TOPS-20 system, I have encountered two problems: 1. Persistent aborts after 60-100 records (but always at the same record) in CRC mode 2. Consistent abort for "Bad Header" at record 255 in checksum mode (which suggests to me that modem is not rolling over beyond 0FFH). On the receiving end, have been using an Osborne 1 running MDM791, and an H-89 using MODEM901, both at 300 baud. Problem occurs in same place on both. Files were being sent with binary output set on TOPS-20. Has anyone else encountered this? I didn't until two days ago; has anything changed? ...Dick 8-Mar-84 13:52:34-MST,1142;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 8 Mar 84 13:52:28-MST Received: From Brl-Vgr.ARPA by AMSAA via smtp; 8 Mar 84 15:25 EST Received: From Ut-Ngp.ARPA by BRL-VGR via smtp; 8 Mar 84 15:19 EST Date: Thu, 8 Mar 84 14:20:37 cst From: vomlehn@ut-ngp.ARPA Posted-Date: Thu, 8 Mar 84 14:20:37 cst Message-Id: <8403082020.AA22150@ut-ngp.ARPA> Received: by ut-ngp.ARPA (4.22/3.14) id AA22150; Thu, 8 Mar 84 14:20:37 cst To: info-cpm@brl-vgr.ARPA Subject: Using cold-in-a-can products to isolate faults You should be careful when using one of those cold-in-a-can products to isolate heat-sensitive chips. Apparently someone took a look at these things and discovered that suddenly cooling down a hot chip can cause it to fail. This is not entirely suprising when you consider what happens when you put a hot glass jar into cold water; it cracks. I don't know if this person came up with actual figures for these cold- induced failures, but if you notice your board fails in a different way after cooling down a chip it may be that you now have TWO defective chips. 8-Mar-84 14:03:20-MST,793;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 8 Mar 84 14:03:15-MST Received: From Sumex-Aim.ARPA by AMSAA via smtp; 8 Mar 84 15:36 EST Received: from ISL by SUMEX-AIM with Pup; Thu 8 Mar 84 10:49:02-PST Date: Thursday, 8 Mar 1984 10:50-PST To: info-cpm@amsaa Subject: re: disk editor for cpm/1791 In-reply-to: Your message of 8 March 1984 00:41 cst. From: meier%isl@AMSAA.ARPA Jesse, DUU and DU2 are probably what I can use. How can I get a copy of them? My BIOS also traps bad sector errors, but at least it would prevent me from losing all the information on a disk. It would allow me to mark the sectors as bad in the directory. (and thus prevent cp/m from trying to use them) Bob (shasta!isl!meier@amsaa.arpa) 8-Mar-84 15:40:07-MST,1651;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 8 Mar 84 15:40:01-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 8 Mar 84 17:23 EST Received: From Mit-Mc.ARPA by BRL via smtp; 8 Mar 84 17:12 EST Date: 8-Mar-84 17:12:20-EST From: jalbers@bnl Subject: ATTEN: Osborne computer users (All others, pls. skip To: info-cpm@mit-mc ATTENTION users of Osborne computers. The Capital Osborne Users Group (CapOUG) is seeking other Osborne users groups across the country. If you are a member of such a group, please send the name of the president, along with an address and phone number. We are also looking for contacts via the net (USENET or ARPA/MILNET) between groups across the country. If you can be such a contact or know of someone who can, please send me mail. All that would be envolved is sending and recieving summaries of meetings, parts of newsletters, and acting as an interface between your group and the other groups 'subscribing' to this 'mailing list'. At this point, it is not certain wheather communication would be through a mail 'reflector', or via a 'digest', however the latter is most likely. In return for your service, the CapOUG will exchange our software library, which consists of over 120 SD disketts, and articles from our newsletter. The 'interface' would be asked to offer the like to the other members of the list. Even if you don't belong to a group, this would be a great way to find the group in your area. Jon Albersg ARPA jalbers@BNL (UUCP)...!ihnp4!harpo!floyd!cmc12!philabs!sbcs!bnl!jalbers 8-Mar-84 16:12:07-MST,1073;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 8 Mar 84 16:11:59-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 8 Mar 84 17:50 EST Received: From Ucb-Vax.ARPA by BRL via smtp; 8 Mar 84 17:43 EST Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.22/4.25) id AA03363; Thu, 8 Mar 84 14:42:14 pst Received: from ucbpopuli.CC.Berkeley.ARPA by ucbjade.CC.Berkeley.ARPA (4.14.noSUID/4.14.2) id AA18137; Thu, 8 Mar 84 14:36:55 pst Received: by ucbpopuli.CC.Berkeley.ARPA (4.14/4.14) id AA08575; Thu, 8 Mar 84 14:42:41 pst Message-Id: <8403082242.AA08575@ucbpopuli.CC.Berkeley.ARPA> Date: 8 March 84 14:42-PST From: KJBSF%SLACVM.BITNET@berkeley To: INFO-CPM@brl Subject: BITNET mail follows Date: 8 March 1984, 14:41:03 PST From: KJBSF at SLACVM To: INFO-CPM at BRL.ARPA Subject: Kermit and Apple Kermit-80 on my Apple aborts a file transmission every time I try after 60 packets have been sent. I can't figure out what the problem could be. Any suggestions? 8-Mar-84 16:35:39-MST,2046;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 8 Mar 84 16:35:30-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 8 Mar 84 18:14 EST Received: From Parc-Maxc.ARPA by BRL via smtp; 8 Mar 84 18:07 EST Date: Thu, 8 Mar 84 12:33 PST From: Eldridge.es@PARC-MAXC.ARPA Subject: L80 patch to avoid disk reset To: info-cpm@brl.ARPA cc: es820ug^.es@PARC-MAXC.ARPA, 820Interest^.wbst@PARC-MAXC.ARPA, PARC820^.pa@PARC-MAXC.ARPA Reply-To: Eldridge.es@PARC-MAXC.ARPA The linker "L80.COM" from Microsoft behaves in way that can be annoying. L80 does a disk reset and relogs the disk every time it accesses a new .REL file. This was done so that .REL files from several disks could be linked simply by inserting the proper disk before entering the name of the .REL file. All the relogging avoided the dreaded BDOS ERROR: R/O that comes from indiscriminately swapping disks. If you never swap disks, then this behavior just increases the link time. This relogging becomes very time consuming when you have a hard disk with a large directory since CP/M must regenerate the allocation map every time it resets the disk. The following patch will eliminate the unnecessary relogging. This patch is for Link-80 3.44 09-Dec-81. A>REN L80.BAK=L80.COM A>DDT L80.BAK DDT VERS 2.2 NEXT PC 2B00 0100 -L2CC 02CC MVI C,19 02CE CALL 0005 02D1 PUSH PSW 02D2 MVI C,0D 02D4 CALL 0005 02D7 POP PSW 02D8 MOV E,A 02D9 MVI C,0E 02DB CALL 0005 02DE XRA A -A2CE 02CE JMP 02DE 02D1 . -S395 0395 20 31 0396 20 . -^C A>SAVE 42 L80.COM The patch causes a jump around the disk relogging calls. The version number is also changed to 3.441. If you have been linking files on a hard disk you will be pleased by the marked increase in speed. I have not had any problems linking files using the patched version of L80. Remember that you cannot swap disks while you are running the modified version of L80. George (Eldridge.es@PARC-MAXC.ARPA) 8-Mar-84 23:40:21-MST,1376;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 8 Mar 84 23:40:15-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 9 Mar 84 1:23 EST Received: From Csnet-Cic.ARPA by BRL via smtp; 9 Mar 84 1:19 EST Date: 08 Mar 84 22:13:22 PST (Thu) From: Michal Young Return-Path: Subject: Re: Old Kaypro disk fix Received: from UCI-750a by csnet-cic.ARPA ; 9 Mar 84 01:15:22 EST (Fri) To: ANDY%MIT-OZ%mit-mc@csnet-relay Cc: info-cpm%brl@csnet-relay, young%Uci-750a@csnet1 In-Reply-To: Your message of Thu, 8 Mar 1984 00:30 EST. The problem may not be hardware. My Kaypro used to run the drive motors until a character was read or written to console, I don't remember which. For instance Perfect Writer would start them spinning when it swapped and they would stay on till I typed something. Then last spring or so our user group got an updated CP/M and-- voila-- the drives turned off after use. So-- find someone with a newer Kaypro, and have them format/sysgen a disk for you. (Have them copy the whole CP/M disk-- some of the utilities have improved a bunch.) Maybe it will work, maybe not, but it's worth a try. (If you don't find someone handier, contact me and I'll mail you a disk). --Michal Young 9-Mar-84 01:57:37-MST,1460;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 9 Mar 84 01:57:32-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 9 Mar 84 3:30 EST Received: From Sri-Sprm.ARPA by BRL via smtp; 9 Mar 84 3:21 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 9 Mar 84 0:09-PST Date: 5 Mar 84 13:28:26-PST (Mon) To: info-cpm@brl From: sri-unix!hplabs!hao!seismo!harpo!ulysses!burl!clyde!akgua!mcnc!ncsu!ikonas!bitmap%ucbtopaz.cc.berkeley.arpa@BRL.ARPA Subject: UMODEM for 4.1bsd? Article-I.D.: ucbtopaz.409 Relay-Version:version B 2.10.1 6/24/83; site ncsu.UUCP Posting-Version:version B 2.10.1 6/24/83 v7 ucbtopaz-1.5; site ucbtopaz.CC.Berkeley.ARPA Path:ncsu!mcnc!akgua!clyde!floyd!harpo!decvax!ucbvax!ucbtopaz!bitmap Message-ID:<409@ucbtopaz.CC.Berkeley.ARPA> Date:Mon, 5-Mar-84 16:28:26 EST Organization:Univ. of Calif., Berkeley CA USA I'm trying to locate copies of the program UMODEM (a Unix-based communication program designed to facilitate the transfer of files between Unix and CP/M systems via MODEM7) that will run under 4.1bsd. Ideally, I'd like to obtain copies for both VAX 11/780s and PDP 11/70s, but I'd happily settle for a program that would work on one or the other machine. I would be grateful for any information you can provide on the subject. John Hevelin ucbvax!cgr@ucbpopuli 9-Mar-84 02:44:36-MST,3894;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 9 Mar 84 02:44:26-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 9 Mar 84 4:17 EST Received: From Csnet-Relay.ARPA by BRL via smtp; 9 Mar 84 4:14 EST Received: by csnet-relay via uvapob; 9 Mar 84 4:01 EST Date: 7 Mar 1984 06:22:04-EST From: erh%virginia.csnet@csnet-relay.arpa To: info-cpm%brl.arpa@csnet-relay.arpa Subject: RE: Octagon's 8/16 CPU board [] I had exactly same experience with Digital Research and Octagon. After waiting for several weeks for Octagon's literature, I finally managed to talk to a person in their tech department. (My questions were: is the 8" DD disk format IBM (i.e. CompuPro) compatible? -- Yes. Will the CPU's work with 4Mhz static memory mapped board? -- Maybe.) Mike Lucas from Priority 1 said they had Octagon's board running in a CompuPro system and it did fine. Priority had sold several to large companies in LA area and had no complaints. I then ordered one from Priority 1 (in mid February). It is supposed to be shipped around March 10. Presumably, I am taking a risk. But I was surprised and very disappointed by CompuPro's decision to obsolete their Z-80 CPU by introducing a dual CPU board running 8080 only. I considered getting their new Z80 slave CPU but was told that delivery will not start until summer (also, the price is about $1000). For those haven't heard about Octagon's 8/16 CPU board, here are a few specs (as advertised): -- dual CPU's (8088 at 8MHz and NSC-800 at 4MHz. NSC chip is upward compatible with Z80 at the machine language level.) -- FDC on board, up to 4 5" or 8" drives in any combination. -- two software controlled serial ports on board <= 19000 bps -- monitor in PROM, fixed freq timer interrupt, etc. The current Priority 1 price is $795. For another $695 they will sell you 128K of CompuPro's fast RAM, and that is ALL you need to run Octagon's system (CP/M-86 will run with 64K). If it works as advertised, it is a steal. I will likely have more to say when I get the board. ----- Mail saved at Wed Mar 7 06:19:12 1984 To: info-cpm@BRL.ARPA Subject: Re: Octagon 8/16 CPU for S-100 [] I had exactly same experience with Digital Research and Octagon. After waiting for several weeks for Octagon's literature, I finally managed to talk to a person in their tech department. (My questions were: is the 8" DD disk format IBM (i.e. CompuPro) compatible? -- Yes. Will the CPU's work with 4Mhz static memory mapped board? -- Maybe.) Mike Lucas from Priority 1 said they had Octagon's board running in a CompuPro system and it did fine. Priority had sold several to large companies in LA area and had no complaints. I then ordered one from Priority 1 (in mid February). It is supposed to be shipped around March 10. Presumably, I am taking a risk. But I was surprised and very disappointed by CompuPro's decision to obsolete their Z-80 CPU by introducing a dual CPU board running 8080 only. I considered getting their new Z80 slave CPU but was told that delivery will not start until summer (also, the price is about $1000). For those haven't heard about Octagon's 8/16 CPU board, here are a few specs (as advertised): -- dual CPU's (8088 at 8MHz and NSC-800 at 4MHz. NSC chip is upward compatible with Z80 at the machine language level.) -- FDC on board, up to 4 5" or 8" drives in any combination. -- two software controlled serial ports on board <= 19000 bps -- monitor in PROM, fixed freq timer interrupt, etc. The current Priority 1 price is $795. For another $695 they will sell you 128K of CompuPro's fast RAM, and that is ALL you need to run Octagon's system (CP/M-86 will run with 64K). If it works as advertised, it is a steal. I will likely have more to say when I get the board. 9-Mar-84 03:09:57-MST,1563;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 9 Mar 84 03:09:52-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 9 Mar 84 4:51 EST Received: From Sri-Sprm.ARPA by BRL via smtp; 9 Mar 84 4:46 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 9 Mar 84 1:25-PST Date: 2 Mar 84 7:02:47-PST (Fri) To: info-cpm@brl From: decvax!ittvax!dcdwest!sdcsvax!sdccsu3!brian@ucb-vax Subject: Re: Uc.c Article-I.D.: sdccsu3.1613 In-Reply-To: Article <16907@sri-arpa.UUCP> x We had exactly the same problem with uc.c on 4.1 - what you have to do to fix it is change the fstat procedure name to something else - for example, myfstat, as it is overlaying the system fstat in the io library, and the first printf in the program is causing infinite recursion until you blow the stack. Be aware that the uc.c program will fail as soon as you go to 4.2 - it uses alarm() to time out reads, and the entire signal handling mechanism has changed in 4.2 in this respect, so you'll have to rewrite all the sections of code that depend on that. Look into the 'select' system call in your 4.2 manuals. A few days ago I posted 'xmodem' - a sort of umodem program updated for 4.2 BSD. You'll find a working example of the select call and timeout as it would be used in uc in that program. Or you could add crcs to xmodem - I intended to but ran out of time. -- -Brian Kantor, UC San Diego Kantor@Nosc ihnp4 \ decvax \ dcdwest ----- sdcsvax ----- brian ittvax / ucbvax/ 9-Mar-84 03:12:44-MST,1031;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 9 Mar 84 03:12:40-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 9 Mar 84 4:50 EST Received: From Sri-Sprm.ARPA by BRL via smtp; 9 Mar 84 4:46 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 9 Mar 84 1:26-PST Date: 2 Mar 84 19:58:02-PST (Fri) To: info-cpm@brl From: hplabs!hao!seismo!ut-sally!ut-ngp!garey@ucb-vax Subject: re:Kaypro, Perfect Writer, and superscripting problem Article-I.D.: ut-ngp.345 Look at the PW manual page A-37, under 'pad super and subscripts'. If your printer can microfeed, you can set this to no. Look at the config- uration for your printer with PFCONFIG.COM and see what its set at. Also look in your printer manual and make sure it can microfeed. I hope this helps, Jim Garey garey@ut-ngp.ARPA {ihnp4,seismo,ctvax}!ut-sally!ut-ngp!garey P.S. I can't seem to send mail out thru usenet so I can't reply except thru postnews or ARPA mail. 9-Mar-84 04:56:35-MST,1750;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 9 Mar 84 04:56:30-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 9 Mar 84 6:36 EST Received: From Sri-Sprm.ARPA by BRL via smtp; 9 Mar 84 6:33 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 9 Mar 84 3:26-PST Date: 3 Mar 84 17:18:43-PST (Sat) To: info-cpm@brl From: decvax!linus!philabs!sbcs!bnl!jalbers@ucb-vax Subject: Atten:Osborne users Article-I.D.: bnl.363 ATTENTION users of Osborne computers. The Capital Osborne Users Group (CapOUG) is seeking other Osborne users groups across the country. If you are a member of such a group, please send the name of the president, along with an address and phone number. We are also looking for contacts via the net (USENET or ARPA/MILNET) between groups across the country. If you can be such a contact or know of someone who can, please send me mail. All that would be envolved is sending and recieving summaries of meetings, parts of newsletters, and acting as an interface between your group and the other groups 'subscribing' to this 'mailing list'. At this point, it is not certain wheather communication would be through a mail 'reflector', or via a 'digest', however the latter is most likely. In return for your service, the CapOUG will exchange our software library, which consists of over 120 SD disketts, and articles from our newsletter. The 'interface' would be asked to offer the like to the other members of the list. Even if you don't belong to a group, this would be a great way to find the group in your area. Jon Albersg ARPA jalbers@BNL (UUCP)...!ihnp4!harpo!floyd!cmc12!philabs!sbcs!bnl!jalbers 9-Mar-84 08:29:26-MST,989;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 9 Mar 84 08:29:22-MST Received: From Usc-Isid.ARPA by AMSAA via smtp; 9 Mar 84 10:05 EST Date: 9 Mar 1984 06:45-PST Sender: ABN.ISCAMS@usc-isid Subject: re: disk editor for cpm/1791 From: ABN.ISCAMS@usc-isid To: meier%isl@amsaa Cc: info-cpm@amsaa Message-ID: <[USC-ISID] 9-Mar-84 06:45:47.ABN.ISCAMS> In-Reply-To: The message of Thursday, 8 Mar 1984 10:50-PST from meier%isl@AMSAA.ARPA DUU and DU are at SIMTEL20 via anonymous FTP (I think DUU is in the SIGM files somewhere, and DU under disk utilities). FINDBAD, which is supposed to find and lock out bad sectors (by storing them in a file called BAD or something like that) is also out there -- however I find it does not catch all the errors, since I can run FINDBAD and still get BDOS errors. Donno why. If you need help FTPing from SIMTEL20, yell. Regards, David Kirschbaum Toad Hall (ABN.ISCAMS@USC-ISID) 9-Mar-84 11:58:27-MST,1265;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 9 Mar 84 11:58:21-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 9 Mar 84 13:36 EST Received: From Mit-Mc.ARPA by BRL via smtp; 9 Mar 84 13:30 EST Received: by csnet-relay via xumass-cs; 9 Mar 84 12:29 EST Date: Fri, 9 Mar 84 09:09 EST From: Robert (LISPer DM)Heller To: Info-CPM%mit-mc.arpa@csnet-relay.arpa Subject: Looking For A BASIC Interpreter For The 68K I am looking for a good BASIC interpreter for the 68000 processor. I want somthing which runs under CP/M-68K or standalone. It should be fairly compatable with Microsoft BASIC. Microsoft BASIC is the BASIC which is the basis of the BASIC-IN-ROM in most of the "little" machines: Apple I&II, Atari, Commodore, TI, TRS-80, etc. It does not have to be super fast - I will be using for educational purposes running little student programs. I have a SAGE II w/ two 5.25" DSQD disks (640Kbytes eash), with both the UCSD p-System and CP/M-68K O/S's. The BASIC compiler that comes with UCSD p-System is very non-compatable and a pain to use. I want something better. Robert Heller Heller%UMass-CS@CSNet-Relay 9-Mar-84 12:32:29-MST,674;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 9 Mar 84 12:32:25-MST Received: From Simtel20.ARPA by AMSAA via smtp; 9 Mar 84 14:03 EST Date: 9 Mar 1984 12:01 MST (Fri) Message-ID: From: "Frank J. Wancho" To: ABN.ISCAMS@usc-isid Cc: meier%isl@amsaa, INFO-CPM@amsaa Subject: FINDBAD In-reply-to: Msg of 9 Mar 1984 07:45-MST from ABN.ISCAMS at usc-isid As pointed out elsewhere, it is probably NOT a good idea to do READ/WRITE cycles on a disk with active data. Thus, FINDBAD only READs each sector and cannot detect and flag WRITE errors. --Frank 9-Mar-84 13:05:06-MST,1688;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 9 Mar 84 13:05:00-MST Date: Fri, 9 Mar 84 14:27:06 EST From: Dave Towson (info-cpm) To: info-cpm@amsaa Subject: [garey: Re: Old Kaypro disk fix] Presumably, this was sent to me rather than to the whole list by mistake. Dave ----- Forwarded message # 1: Received: From Ut-Ngp.ARPA by AMSAA via smtp; 8 Mar 84 22:03 EST Date: Thu, 8 Mar 84 21:04:54 cst From: garey@ut-ngp.ARPA Posted-Date: Thu, 8 Mar 84 21:04:54 cst Message-Id: <8403090304.AA27550@ut-ngp.ARPA> Received: by ut-ngp.ARPA (4.22/3.14) id AA27550; Thu, 8 Mar 84 21:04:54 cst To: info-cpm-request@AMSAA.ARPA Subject: Re: Old Kaypro disk fix Has this always been the case? In my Kaypro (one of the first horizontal drive models the light is on if the drive is selected, whether or not the drive is running, but the motor shuts off after a certain time with no further access. If this motor running at all times is new, you could call up the dealer and see if it can be fixed cheap, otherwise Kaypro will sell you a whole new board for $120. If the A motor running all the time is inherent in your old model Kaypro, it could be solved with a more up to date BIOS or a commercial replacement such as KayKey, which allows you to set when the drive motor shuts off. Call up Kaypro and ask. I've found them to be very responsive. Within Perfect Writer the motor runs after the last access for ever if you don't hit a key, but that doesn't sound like your problem. Maybe some more technical people can give more specific ----- End of forwarded messages 9-Mar-84 16:43:37-MST,2116;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 9 Mar 84 16:43:30-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 9 Mar 84 18:18 EST Received: From Ucb-Vax.ARPA by BRL via smtp; 9 Mar 84 18:04 EST Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.22/4.25) id AA23981; Fri, 9 Mar 84 12:41:07 pst Received: from ucbopal.CC.Berkeley.ARPA by ucbjade.CC.Berkeley.ARPA (4.14.noSUID/4.14.3) id AA09357; Fri, 9 Mar 84 12:35:56 pst Received: by ucbopal.CC.Berkeley.ARPA (4.14/4.14) id AA14701; Fri, 9 Mar 84 12:25:01 pst Date: Fri, 9 Mar 84 12:25:01 pst From: William C. Wells Message-Id: <8403092025.AA14701@ucbopal.CC.Berkeley.ARPA> To: cgr%ucbpopuli.CC@berkeley Subject: Re: UMODEM for BSD 4.1 Cc: info-cpm@brl.ARPA In reply to: Date: 5 Mar 84 13:28:26-PST (Mon) To: info-cpm@brl From: sri-unix!hplabs!hao!seismo!harpo!ulysses!burl!clyde !akgua!mcnc!ncsu!ikonas!bitmap@ucbtopaz.cc. Subject: UMODEM for 4.1bsd? Article-I.D.: ucbtopaz.409 Organization:Univ. of Calif., Berkeley CA USA I'm trying to locate copies of the program UMODEM (a Unix-based communication program designed to facilitate the transfer of files between Unix and CP/M systems via MODEM7) that will run under 4.1bsd. Ideally, I'd like to obtain copies for both VAX 11/780s and PDP 11/70s, but I'd happily settle for a program that would work on one or the other machine. I would be grateful for any information you can provide on the subject. John Hevelin ucbvax!cgr@ucbpopuli John, The MODEM communcation programs are periodically copied down from the SIMTEL20 MICRO Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 9 Mar 84 16:46:42-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 9 Mar 84 18:18 EST Received: From Simtel20.ARPA by BRL via smtp; 9 Mar 84 18:12 EST Date: 9 Mar 1984 13:12 MST (Fri) Message-ID: From: "Frank J. Wancho" To: INFO-CPM@brl, INFO-IBMPC@usc-isib Cc: INFO-MICRO@brl, INFO-UNIX@brl Subject: 24-hr Access to SIMTEL20 The SIMTEL20 has now been up for over 50 continuous hours after the infamous shunt-trip circuit breaker was installed and acid-tested (twice) earlier in the week, and the Air Conditioner load balanced so that it doesn't shutdown. We expect to remain up continuously except for scheduled PM every other Wednesday morning. The SIMTEL20 holds the online repository for the entire SIG/M and CPMUG volumes of public domain disks. We also actively maintain a separate collection of current CP/M public domain software originally started on MIT-MC. There is also a fledgling collection of UNIX/C public domain software from Rick Conn, with the DARCOM ToolChest to be added momentarily. We also expect to be uploading the current set of 42 PC-BLUE volumes next week, and the latest releases from SIG/M as they become available. The major directories of interest are: MICRO: The constantly updated CP/M collection from MC See MICRO:CPM.DIRLST for a short list of the subdirectory name to substitute for the *. MICRO: The SIG/M collection, where nnn = 000 to 145. We are expecting 146 to 165 RSN. MICRO: The CPMUG collection, where nnn = 001 to 054, and 078 to 090 (055 to 077 are duplicates of various SIG/M volumes). MICRO: UNIX/C utilities from Rick Conn, including UC and MENU to name two. MICRO:The DARCOM ToolChest (available later today). MICRO: The SIG/M and NYACC PC-BLUE collection, where nnn = 001 to 042 (available later next week). Each major directory also contains a file of the form, MICRO:dir.CRCLST, which lists the contents of each of the subdirectories in alphanumeric order along with the size, filetype, and CRC value. Filetype may be either ASCII or COM. If COM, then it is an ITS Binary file. ALL of the files in MICRO:, MICRO:, and (soon) MICRO:, and the obviously binary files in MICRO: are stored in ITS Binary format to preserve published or documented CRC values. --Frank 9-Mar-84 22:13:53-MST,968;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 9 Mar 84 22:13:48-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 9 Mar 84 23:49 EST Received: From Csnet-Cic.ARPA by BRL via smtp; 9 Mar 84 23:48 EST Date: 09 Mar 84 20:44:48 PST (Fri) From: Michal Young Return-Path: Subject: Re: Kaypro, Perfect Writer, and superscripting problem Received: from UCI-750a by csnet-cic.ARPA ; 9 Mar 84 23:45:55 EST (Fri) To: hplabs!hao!seismo!ut-sally!ut-ngp!garey%ucb-vax@csnet-relay Cc: info-cpm%brl@csnet-relay, young%Uci-750a@csnet1 In-Reply-To: Your message of 2 Mar 84 19:58:02-PST (Fri). In my copy of PFCONFIG, if I say my printer can microfeed I get asked which of the supported printers I own-- I cannot specify the sequence of codes needed to microfeed my printer, so I have to tell it my printer is dumber than it really is. Has Perfect fixed this? 10-Mar-84 04:52:43-MST,1315;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 10 Mar 84 04:52:38-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 10 Mar 84 6:24 EST Received: From Dca-Ems.ARPA by BRL via smtp; 10 Mar 84 6:17 EST Date: 10 Mar 1984 5:50:34 EST (Saturday) From: Maj Bower (HQ USEUCOM) Subject: UFDC-1 disk controller To: info-cpm@brl I am sending this to the net since my cry for help went that-a-way. The UFDC-1 controller (mine purchased from Compu/time) DOES work with the Siemens FDD-221-5 80 track double-sided drive. The problem in my system came from relying on the controller documentation when writing a customized BIOS. BE ADVISED...Bit 5 of the control byte to the controller should be a zero for side zero...NOT a one for side zero as listed in the documentation. With the correct bit inserted, the board is FANTASTIC! The board is now configured with: Drive A - Tabor 3.25" - SS/DD - 12 mS steps - 384K Drive B - Siemens FDD-221-5 - DS/DD - 6 mS steps - 784K Drive C - Siemens FDD-100-8D - SS/DD - 6 mS steps - 636K With only a jumper change and drive swap, Drive B can change to a Shugart SA-400 SS/DD - 20 mS steps - 160K. A great controller board...if only the documentation were correct. Hal 10-Mar-84 12:12:37-MST,2445;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 10 Mar 84 12:12:29-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 10 Mar 84 13:49 EST Received: From Mit-Mc.ARPA by BRL via smtp; 10 Mar 84 13:41 EST Date: 10 March 1984 13:41-EST From: Charlie Strom Subject: BDOS 37 clarification To: INFO-CPM@brl cc: CSTROM@mit-mc I received a clarification of the infamous BDOS 37 bug in CP/M 2.2 by way of Compuserve's CP/M Interest Group. Following is the straight poop (or so I am told)... Fm: Jim Rosenberg 71515,124 To: All Several months ago I left a message here about the bug in BDOS function 37. I see Jerry Pournelle is sounding off about it in this month's BYTE, and he's got his facts all mixed up. For those who missed my earlier message, here's the story as I know it. There is definitely a bug in BDOS 37, which will get you into deep trouble if you don't know about it, but if you use it carefully it seems to be perfectly safe. The problem comes when function 37 is used to reset the current default disk. Function 37 seems to do nothing but reset the correct bits in the login vector. Evidently BDOS simply assumes that the current default disk CAN'T fail to be logged in, and when that happens it gets extremely confused. (Don't try to debug the results if you value your sanity! I've seen open calls on a completely different disk report a file doesn't exist even when it does, and the allocation map of the FCB is filled in by the open call!!) My experience is that function 37 is perfectly safe if you aren't resetting the current disk. (I've only used it to reset one drive at a time.) The algorithm to reset an individual drive with the least pain is: (1) do BDOS 25 to get the current disk. If that isn't the drive you are resetting go ahead and use BDOS 37. (2) Otherwise, get the login vector (BDOS 24) and see if some drive other than what you want to reset is logged in. If so, select that drive, use BDOS 37, then select back to whatever drive had been current. (3) Only if neither of these obtains do you need to use BDOS 13. If anyone finds this doesn't work please let me know. I've used this algorithm in a piece of software of which I've sold hundreds all over the world and it seems to work. -Best, Jim P.S. This is 2.2!! Don't know if it also applies to CP/M-86. 10-Mar-84 16:19:57-MST,2564;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 10 Mar 84 16:19:50-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 10 Mar 84 18:02 EST Received: From Mit-Mc.ARPA by BRL via smtp; 10 Mar 84 17:52 EST Date: 10 March 1984 17:51-EST From: Eric Stork Subject: Function 37 To: CSTROM@mit-mc, info-cpm@brl Charlie Strom: , Thanks for the 3/10/84 net-msg on BDOS Function 37. A couple of months ago there was a lot of net traffic on this subject. That triggered me to do some investigation. Here is what learned, in part from thoughtful messages from FJW, W8SDZ, and some others, and in part from my own hacking: , * FJW provided the key by pointing out that Function 37 (F-37) does NOT reset the disk to which [DE] points, but rather disables the write-protect that normally prevents a write if the disk map on the disk does not match the disk map in memory. , * That leads to the logical conclusion that when one uses F-37, one must ALSO assure that the disk map in memory matches the actual disk. , * Through experimentation (switching disks and looking at the disk map in memory, which one can do using DDT or SID, and BDOS F-27) I found that every time a did a SEARCH FOR FIRST file (BDOS F-17) the disk map was reset. , * My conclusion (and I'd welcome criticism!) is that F-37 can be safely used to reset a specific disk so long as it is followed by a F-17 operation. Of course, any file on the disk being removed has to be closed first, to save the data. , * The disasters described by some seem to happen when one does a file write (or delete) after F-37 and a disk switch BUT before a disk map reset with F-17. , * Of course, that leaves the question of why use F-37 at all? I don't if I don't have to -- I'm old enough to have become a devout coward who avoids needless risks. But there are times when F-13 will not do the job. Sometimes F-13 does undesirable things to the program you're in -- then there is not other way if a disk switch is needed. Or is there? , * Hope this helps. I'd welcome further analytical discussion. I agree that Pournelle's current BYTE advice, though helpful in warning people, should have gone further than just say "don't do it". , Eric. 10-Mar-84 17:28:06-MST,508;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 10 Mar 84 17:28:03-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 10 Mar 84 19:13 EST Received: From Sri-Sprm.ARPA by BRL via smtp; 10 Mar 84 19:07 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 10 Mar 84 4:09-PST Date: 8 Mar 84 9:23:18-PST (Thu) To: info-cpm@brl From: hplabs!hao!seismo!rlgvax!plunkett@ucb-vax Subject: Turbo Pascal: Any bad news? Article-I.D.: rlgvax.1786 10-Mar-84 22:40:42-MST,1418;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 10 Mar 84 22:40:38-MST Received: From Brl-Vgr.ARPA by AMSAA via smtp; 11 Mar 84 0:24 EST Received: From Mit-Mc.ARPA by BRL-VGR via smtp; 11 Mar 84 0:19 EST Date: Sun, 11 Mar 1984 00:17 EST Message-ID: From: STRAZ%MIT-OZ@MIT-MC.ARPA To: info-cpm@BRL-VGR.ARPA Subject: getting files I recently got a Kaypro, and I need a terminal emulator for it. Someone kindly pointed me to the files in SIMTEL20: micro: cpm.dirlst cpmug.crclst sigm.crclst I found some promising-looking files in micro: with names like KPROTERM.TXT and KAYMODEM.DOC, but upon reading them here at MIT (fetched via FTP on my DEC 20) I found gibberish, not human-legible text. I've tried transferring files with names like FOO.TXT and FOO.DOC using ASCII, 8-BIT, and 36-BIT transfer modes, but I keep losing. So I have three questions: 1) Is there a bootstrap program I can type into my Kaypro to make loading serious files easier? 2) Is there something I'm doing wrong with fetching stuff from SIMTEL20? 3) Can anyone recommend a terminal emulator program for Kaypros? (the free ADM3 that comes with Kaypros is too stupid. I'd prefer emulation of a VT52, Ann Arbor, Heath or other smarter terminal.) 11-Mar-84 00:55:12-MST,1435;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 11 Mar 84 00:55:08-MST Date: Sun, 11 Mar 84 2:38:16 EST From: Dave Towson (info-cpm) To: info-cpm@amsaa Subject: [graham: MACRO-80 patch(es) ??] Please note: Mail addressed to info-cpm-request should deal only with the operation of the list (additions, deletions, problems, etc.). General queries should be addressed to info-cpm. ----- Forwarded message # 1: Received: From Ucb-Vax.ARPA by AMSAA via smtp; 10 Mar 84 18:28 EST Received: by UCB-VAX.ARPA (4.22/4.25) id AA07380; Sat, 10 Mar 84 15:27:54 pst Date: Sat, 10 Mar 84 15:27:54 pst From: allegra!parsec!graham@Berkeley Message-Id: <8403102327.AA07380@UCB-VAX.ARPA> To: info-cpm-request@AMSAA.ARPA Mailed: Sat Mar 10 12:30:30 1984 Subject: MACRO-80 patch(es) ?? Cc: I have been told that the MACRO-80 sold by Heath is Microsoft's CP/M macro assembler, but that it will run only on Heath systems. I have also been told that there is a public domain patch which will permit it to run on any CP/M system. If there is such a patch, I would like to have a copy of it. If the rest of the MACRO-80 system (i.e. the linker, etc.) also requires similar patches, I would like copoes of those too. Marv Graham; ConVex Computer Corp. {allegra,ihnp4,uiucdcs,ctvax}!parsec!graham ----- End of forwarded messages 11-Mar-84 14:03:37-MST,739;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 11 Mar 84 14:03:33-MST Received: From Mitre.ARPA by AMSAA via smtp; 11 Mar 84 15:37 EST Date: 10 Mar 1984 15:25:57 EST (Saturday) From: Jeffrey Edelheit Subject: Fujitsu Micro 16 To: info-cpm@amsaa Cc: edelheit@mitre I am considering buying a Fujitsu Micro16. I can get a really good price on one, but haven't heard much about them other that it has an 8086, runs CP/M-86; MS-DOS; emulates straight CP/M (somehow it makes the 8086 act like a Z-80) and will soon offer a 68K and offer UNIX system V. Can anyone out there give me some feed-back on it? Thanks. Jeff Edelheit (Edelheit at mitre) 11-Mar-84 19:38:09-MST,2033;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 11 Mar 84 19:38:02-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 11 Mar 84 21:20 EST Received: From Rutgers.ARPA by BRL via smtp; 11 Mar 84 21:13 EST Received: from RU-BLUE.ARPA by RUTGERS.ARPA with PUP; 11 Mar 84 21:11:20 EST Date: 11 Mar 84 21:11:52 EST From: Seymour Subject: Vector 3 CP/M 2.22h CCP patching To: info-cpm@BRL.ARPA I have been working for some time on installing a RBBS based RCP/M system on a Vector 3 system. I have installed XMODEM and BYE and RBBS and am just about ready to bring the whole thing up. I am having one last annoying problem though. I usually install ZCPR on the systems I use as RCP/Ms, to allow searching back to A0> mostly. This makes use of the system much more straightforward. I don't like DUPUSR and this allows me to keep just one copy of the system software online in A0: and have it accessed from any drive or user#. We have succesfully installed ZCPR in several other systems and have never had a problem like this. If anyone out there knows anything that might help, please send me mail. Here's the problem: We install ZCPR and SYSGEN a disk with it. We cold boot and everything works fine. All the ZCPR commands work and the prompt has changed from A: to A0: as it should. The system searches back to A0: as advertised. BUT, on the first cold boot (after a ^C or program exit) the system tries to reload the CCP and crashes with a message that looks like this: -SYSTEM ERROR As an alternative we got a patch that just implements the search back to A0: instead of the full ZCPR and tried to install it. We got the exact same behavior from this patch. Any Ideas? What is so magic about the Vector CCP? I have called Vector several dozen times and they have proved to be much less than useful. I am stumped and turn to you, the DARPA CP/M wizards to give me a helping hand. Seymour ------- 11-Mar-84 19:44:31-MST,991;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 11 Mar 84 19:44:24-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 11 Mar 84 21:20 EST Received: From Sri-Sprm.ARPA by BRL via smtp; 11 Mar 84 21:19 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 11 Mar 84 18:08-PST Date: 8 Mar 84 8:15:53-PST (Thu) To: info-cpm@brl From: harpo!ulysses!burl!clyde!akgua!mcnc!unc-c!dya@ucb-vax Subject: Re: Need tech data for WECo 300/1200 Dataphone modem Article-I.D.: unc-c.1270 References: sri-arpa.17044 Probably (looking at the front of the modem) pins 9 and 8 on the RIGHT HAND 25 pin connector (facing the back) are the local loop (telephone line). In addition, you will need a switch connected from 5 to 25 which engages the modem after you have accessed the remote modem (originate mode); or enables answer mode. The other one is usual RS232 David "Last of the Analog" Anthony (urp!dya) 11-Mar-84 20:03:23-MST,1289;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 11 Mar 84 20:03:18-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 11 Mar 84 21:43 EST Received: From Bnl.ARPA by BRL via smtp; 11 Mar 84 21:42 EST Date: 11-Mar-84 21:42:40-EST From: jalbers@bnl Subject: CPM 3.0 (+) RCP/M info/help wanted To: info-cpm@brl I am interested in putting up an RCP/M on an Osborne Executive which runs CP/M 3.0. I have been working with some people on getting BYE working, but, in the all holy wisdom of OCC, which seems to be spread liberally on all their products, it seems that the SIO chip is implemented in some off-the-wall way, and BYE just won't work. Now it seems to me that a much simpler program could be written to take the place of BYE. Most of what it would have to do is manage the USR Password modem (SMODEM 1200 act-alike). Since the port could be configured to be AUXIN:/AUXOUT:, most of the IO is taken care of, and protection can be done very nicely within CP/M 3. Can anyone who has some working knowledge of the innards of CP/M 3 give me some pointers as to writing such a program? Jon jalbers@bnl 12-Mar-84 00:03:15-MST,4139;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 12 Mar 84 00:02:57-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 12 Mar 84 1:34 EST Received: From Mit-Mc.ARPA by BRL via smtp; 12 Mar 84 1:33 EST Date: 12 March 1984 01:32-EST From: Robert L. Plouffe Subject: MDM716-727 BUG FIX To: INFO-MODEM7@mit-mc, INFO-CPM@mit-mc MDM716 through MDM727 has a problem in the new robustness of the protocol when receiving binary files (.COM, .AQM, e47}c) from a host on ARPANET/MILNET using a compatible modem protocol such as MMODEM on ITS. ASCII file down loading is OK but binary files abort the transfer if a Control-D is received when searching for SOH. Since Control-D is the EOT character, things end abruptly. So far as I know, this problem does not occur when transferring binary files between two micros over a direct phone line connection. However, the following change will fix things in all cases. Bob Plouffe REPLACE THE CODE AT "RCVRECD:" WITH THE FOLLOWING: ;*********************************************************************** ; ; RECEIVE A RECORD FROM SENDING STATION ; ;*********************************************************************** ; ; If CRC is in effect, there is a 10-second timeout to the first SOH. ; It then tries six more times to let the sender know the system is ; capable of receiving a 'CRC' check. At the end of that time a NAK is ; sent which tells the sender to use CHECKSUM checking instead of CRC. ; This allows automatic compatability with systems implementing CRC - ; (Cyclic Redundancy Checking). The search for SOH will cycle through ; one record interval and ignore noise or characters sent by the remote ; for any purpose (such as progress reporting). So extraneous char- ; acters that are sometimes sent by remote-end protocol will be gobbled ; up until the first SOH. EOT is tested only as the first returned ; character after each sector. ; SRCHSOH EQU 160 ;number of times to loop search for SOH ; RCVRECD: MVI A,1 STA ERRCT ;initialize error count MVI B,10 ;10 seconds ; RCVSQ: LXI D,SRCHSOH ;initialize the loop CALL RECV JC RCVSTOT ;time out if 1rst char not rcvd in 10 secs. MOV C,A ;hold it for awhile CPI EOT ;see if end of transmission STC ;set carry RZ ;return with carry set ; SOHLUP: MVI A,0FFH STA CHRFLG STA TIMFLG MOV A,E ;get search count down value CPI SRCHSOH ;see if it is first returned character MOV A,C ;get the first character JZ NORECV ;skip RECV routine if it is first char MVI B,1 CALL RECV ;get another character in sequence MOV B,A ;store it JNC TSTSOH ;go see if SOH is char received ; NORECV: MOV B,A XRA A ;else set to value that will force timeout STA CHRFLG ; TSTSOH: MOV A,B ;get the character CPI SOH ;see if it is SOH PUSH PSW XRA A STA TIMFLG ;restore this flag POP PSW JZ RCVSOH ;got SOH so get the rest of info ;(sector number and its complement) MOV A,D ORA E ;see if counted down to zero DCX D JNZ SOHLUP ;go around again if not LDA CHRFLG ;see if time out needs to be forced ORA A JZ RCVSTOT ;go do time out and count them LDA QFLG ORA A JZ RCVSERR ; **************** Add the line indicated below at routine RCVSER1: RCVSER1:CALL SEND ;..the 'NAK' or 'CRC' request LDA ERRCT ;abort if we have reached error limit INR A STA ERRCT ;store for next time CPI ERRLIM ;see if at limit yet MVI B,1 ; <<-------------------ADD THIS LINE JC RCVSQ ;if not, keep going LDA ACKNAK ;see if ACKNAK is set ORA A JNZ ABORT ;if 'YES', abort JMP CKQUIT ;if 'NO' check for continued use ; ADD THE FOLLOWING AT THE PROLOG TO THE FILE: ; 03/12/84 Changed routine at RCVRECD so that downloading of binary ; MDM727A files works OK on packet switched networks and host- ; cooperating protocols such as MMODEM on ITS machines. ; This change simply moved the test for EOT outside the ; SOH loop. ; -Bob Plouffe ; T tThis file will also be in AR100:FJW;MDM7XX BUGFIX at MIT-MC. 12-Mar-84 00:29:50-MST,1222;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 12 Mar 84 00:29:46-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 12 Mar 84 2:07 EST Received: From Mit-Mc.ARPA by BRL via smtp; 12 Mar 84 2:02 EST Date: 12 March 1984 02:03-EST From: Jerry E. Pournelle Subject: Function 37 To: STORK@mit-mc cc: CSTROM@mit-mc, info-cpm@brl In-reply-to: Msg of 10 Mar 1984 17:51-EST from Eric Stork godalmighty dam. i gather that anything short of perfection is to be avoided; that if one cannot explain what's happening in a hurricane you shouldn't warn anyone that it is coming. your analysis is insteresting, but I do not know how to "change" a hard disk, and I can assure you that fn 37 has managed to write garbage all over the directory in two different hard disk systems. by your logic I should not warn anyone about that since I don't know why it does that. i followed the discussion with some interest; reseting the write vector seems to be the REAL name of the fn 37. I hadn't known that when I wrote my piece; indeed, i put the note about 37 on the net at the same time that I turned in the article. holy catfish 12-Mar-84 00:30:18-MST,1269;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 12 Mar 84 00:30:14-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 12 Mar 84 2:08 EST Received: From Usc-Isid.ARPA by BRL via smtp; 12 Mar 84 2:05 EST Date: 11 Mar 1984 20:17-PST Sender: ABN.ISCAMS@usc-isid Subject: Re: Vector 3 CP/M 2.22h CCP patching From: ABN.ISCAMS@usc-isid To: JOSEPH@ru-blue Cc: info-cpm@brl Message-ID: <[USC-ISID]11-Mar-84 20:17:14.ABN.ISCAMS> In-Reply-To: The message of 11 Mar 84 21:11:52 EST from Seymour Guys, I know from nuttin about Vector 3s and not much more about the software you're implementing... but I DO have a system looking to Default disk Same User Area (e.g., from B3 to A3) first, and then to Default disk User Area 0. Works for everything but overlays! Grabbed it from two different files, a somewhat documented explanation and source code can be found (much to my surprise and pleasure) in my article TOADBIOS.DOC now residing in all its glory at SIMTEL20 MICRO:TOADBIOS.DOC.1, available via ANONYMOUS FTP. (And more glory to the original patch authors!) Hope it can be of use. Regards, and good luck. David Kirschbaum Toad Hall (ABN.ISCAMS@USC-ISID) 12-Mar-84 01:08:19-MST,580;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 12 Mar 84 01:08:16-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 12 Mar 84 2:44 EST Received: From Sumex-Aim.ARPA by BRL via smtp; 12 Mar 84 2:42 EST Received: from ISL by SUMEX-AIM with Pup; Sun 11 Mar 84 23:41:23-PST Date: Sunday, 11 Mar 1984 23:42-PST To: info-cpm@brl Subject: turbo pascal bug Reply-to: kevinw@su-dsn From: Kevin W. Rudd Sender: kevinw%isl@BRL.ARPA 1 div 0 --> -1 1. / 0. --> run time error oh well, half of it works! 12-Mar-84 09:22:39-MST,701;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 12 Mar 84 09:22:35-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 12 Mar 84 11:04 EST Received: From Office-2.ARPA by BRL via smtp; 12 Mar 84 11:01 EST Date: 12-Mar-84 07:57 PST From: ACB.TYM@office-2 Subject: US Micro Sales To: info-cpm@brl Message-ID: <[OFFICE-2]TYM-ACB-4A3P3> Does anyone know (I feel I am the only one who doesn't know) what happened to US Micro Sales (WEST)? They took my money (three month's ago) but their phone no longer works. US Micro Sales (EAST) says WEST is a separate operation that shares AD space. Oh, that I had sent my money EAST instead! 12-Mar-84 15:47:23-MST,2688;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 12 Mar 84 15:47:14-MST Received: From Csnet2.ARPA by AMSAA via smtp; 12 Mar 84 17:23 EST Date: 12 Mar 1984 12:44:41-PST (Monday) From: Rene moore Return-Path: Subject: Response to Champion query To: info-cpm@amsaa.arpa Via: IBM-SJ; 12 Mar 84 14:01-PST In response to the query for information on the CHAMPION accounting system, based on dBASE runtime package. I have had occasion to evaluate a number of accounting packages over the past few years. With all of these I was struck with the varying degree of user- UNfriendliness, opacity of the documentation, difficulty of setup, and (for 2-floppy systems) the necessity of continually swapping disks. EXCEPT for CHAMPION. I recently visited Tianjin University, in Peoples Republic of China, to lecture on "Desktop Computing for Small Businesses". For this trip, Champion Software (then Data Base Research) supplied me with a full copy of their system . My experience while preparing for the trip, as well as during the lectures/demos was uniformly positive. The system fits on a SINGLE DSDD disk (we used a Kaypro-4), with all data on the second disk. The installation is smooth and well documented. We never encountered a single bug or unexplained behavior. Help is available at any time with references back to the (large) manual. For dealers they supply a "demo setup" procedure which is an excellent introduction to the system. (probably a user can get this by asking.) The price is a bit steep ($2500, I think), but you can get a full money refund in 30 days. (They protect themselves by having the system lock up at 200 transactions unless you input a password, which you only can get by signing a release of your rights to a refund.) I have not tried it on large masses of data, so I cannot attest to its per- formance under those conditions. It is installed on a hard disk and seems to work like a charm (Kaypro-10). The data structures are obscure/encrypted, but these would not usually be accessed by the typical user. For the advanced dBASE user who wants to twiddle the data, or custom-design reports, They will sell you the file structure info for $200. All in all, I reccommend this system unconditionally. By the way, there was a recent issue of Interface Age which compared a whole bunch of integrated bookkeeping systems, on a feature-by-feature basis. Well worth examining if you are considering spending this kind of money. Rene Moore President, THE CALCULATING LADY 12-Mar-84 17:19:20-MST,542;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 12 Mar 84 17:19:14-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 12 Mar 84 18:58 EST Received: From Usc-Eclb.ARPA by BRL via smtp; 12 Mar 84 18:55 EST Date: 12 Mar 1984 1551-PST From: Dick Subject: PD Network software? To: info-cpm@BRL.ARPA Some time ago, I read that there was a PD version of some networking software ala the now dead CP/NET, or something like it. Any more word about this? ------- 12-Mar-84 19:06:36-MST,961;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 12 Mar 84 19:06:31-MST Received: From Sumex-Aim.ARPA by AMSAA via smtp; 12 Mar 84 20:50 EST Received: from ISL by SUMEX-AIM with Pup; Mon 12 Mar 84 17:02:07-PST Date: Monday, 12 Mar 1984 17:03-PST To: info-cpm@amsaa Cc: info-micro@brl Subject: Disk Controller Recommendations? From: meier%isl@AMSAA.ARPA Thanks in advance, In the near future, I will be purchasing a disk controller card for a 4 MHz CP/M system with two 8" double density floppy disk drives. I would very much appreciate any comments that anyone has on particular brands and features. I'm especially interested in any comments concerning the Versafloppy II. I will corellate and post on the net, the results of this survey. Since access to my computer is not available from many sites, please send your responses to the net. Thank you, Bob Meier (isl!meier@shasta) 12-Mar-84 21:08:59-MST,848;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 12 Mar 84 21:08:55-MST Received: From Mit-Mc.ARPA by AMSAA via smtp; 12 Mar 84 22:48 EST Date: Mon 12 Mar 84 22:49:31-EST From: Mark Becker Subject: Bugs in Turbo Pascal - lets get the story straight To: info-cpm@AMSAA.ARPA A suggestion when reporting bugs in Borland International's Pascal to a quasi-public net like info-cpm: *** Please tell us which version you're using! *** (Z-80 or 8088) There have been three bug reports recently to the net, two dealing with character arrays and the third with a 1/0 vs 1.0/0.0 math problem. Uh, maybe I'm doing something wrong but the only bug I've able to verify in my copy (for the Z-80) is the 'frac' problem. Mark ------- 12-Mar-84 21:31:52-MST,532;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 12 Mar 84 21:31:48-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 12 Mar 84 23:13 EST Received: From Mit-Mc.ARPA by BRL via smtp; 12 Mar 84 23:05 EST Date: 12 March 1984 23:03-EST From: Robert L. Plouffe Subject: mdm7xx bugfix To: INFO-MODEM7@mit-mc, INFO-CPM@mit-mc The file for fixing mdm716-727 at AR100:FJW;MDM7XX BUGFIX on MIT-MC has been changed to reflect final improvement for the fix. 13-Mar-84 11:04:42-MST,1891;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 13 Mar 84 11:04:35-MST Received: From Sumex-Aim.ARPA by AMSAA via smtp; 13 Mar 84 12:36 EST Date: Tue 13 Mar 84 09:30:14-PST From: Sam Hahn Subject: Re: Disk Controller Recommendations? To: meier%isl@AMSAA.ARPA cc: info-cpm@AMSAA.ARPA, info-micro@BRL.ARPA, SHahn@SUMEX-AIM.ARPA In-Reply-To: Message from "meier%isl@AMSAA.ARPA" of Mon 12 Mar 84 18:08:20-PST I ran a similar system for 2+ years. I give unqualified recommendations on SD Systems boards for reliability and functionality. They have never ever given me so much as a glitch, even when I've moved from place to place. HOWEVER! There are a few things to think about. The VfyII I got in Dec '81 was part of their SBC-200,ExpIII,etc board set, which does not strictly conform to 696 standards. That's one problem (though I could run any number of boards I wanted to run with little problem, including SSM I/O, Heuristics Speechlab, MD MultI/O, a QT clock, and more). The new boards that SD is advertising DOES conform to 696, however, so that's a step in the right direction. Another problem is that the formats understood by the VfyII and supported by SD Systems are not widely used. Practically the only way I could move files from my SD higher density disks onto my new Compupro system was to do a copy from the orig's to SSSD 8", and then read that standard format. A pain for 100+ disks, not to mention what you have to go through if you have more. These two problems are the only reservations I have about the VFYII, and their impact on your application is not for me to decide. Suffice to say that if I hadn't made the move to Compupro, I'd have little to complain about: deviations from 696 haven't affected me at all. -- sam hahn [shahn@sumex] ------- 13-Mar-84 12:27:28-MST,835;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 13 Mar 84 12:27:24-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 13 Mar 84 14:02 EST Received: From Parc-Maxc.ARPA by BRL via smtp; 13 Mar 84 13:50 EST Date: Tue, 13 Mar 84 10:41 PST From: MMOON.ES@PARC-MAXC.ARPA Subject: Re: Function 37 In-reply-to: "POURNE@mit-mc.ARPA's message of 12 Mar 84 02:03 EST" To: Jerry E. Pournelle cc: STORK@mit-mc.ARPA, CSTROM@mit-mc.ARPA, info-cpm@brl.ARPA When all else fails, give 'em hell, Jerry. I for one would rather have to investigate a completely bogus warning five times than have to rely on blind faith. If the net doesn't want to know  but I suspect most on the net do  in the future please copy me, thank you very much. MMoon.es 13-Mar-84 21:03:31-MST,883;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 13 Mar 84 21:03:27-MST Received: From Hi-Multics.ARPA by AMSAA via smtp; 13 Mar 84 22:44 EST Date: 9 March 1984 09:02 cst From: Cargo.PD@hi-multics Subject: SA 850 Config or DJ2D To: info-cpm@amsaa I have a Shugart Associates 850 drive which I am trying to connect to a Morrow Designs Dick Jockey 2D (double density) controller (memory mapped version). The 850 has many plugs and straps possible, and mine came from a salvage depot with nothing plugged. Does anybody out there know the canonical way to select the options? I tried the ones the 850 manual said were plugged at the factory, but the drive wouldn't select. The drive was asserting ready however, so that much at least was working. Any help would be appreciated. ...David Cargo (Cargo -at HI-Multics) 13-Mar-84 21:07:48-MST,1190;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 13 Mar 84 21:07:43-MST Received: From Hi-Multics.ARPA by AMSAA via smtp; 13 Mar 84 22:50 EST Date: 11 March 1984 18:11 mst From: Bill Vaughan Subject: Re: Query to Multics people. To: David Ragozin cc: info-cpm@amsaa, uw-beaver!towson@amsaa In-Reply-To: Message of 27 February 1984 23:16 mst from David Ragozin Date: 27 Feb 84 22:00:22 PST (Mon) From: David Ragozin Subject: Re: Query to Multics people. Some time ago someone posted the following suggestion for FTP'ing ITS format files to get rid of thepadding bits in each 36-bit word: >quote (> is the FTP prompt) type "l 8" Entering these two lines seems to set things up properly on the UNIX system I work on, even though FTP does not have the TENEX mode (type?). There is still the need to eliminate the first 4 bytes using ITCVT (or using dd on a UNIX system). Hope this helps. David Ragozin - entropy!rag@uw-beaver sorry - I tried it and it doesn't work Bill 13-Mar-84 21:58:44-MST,1596;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 13 Mar 84 21:58:34-MST Received: From Brl-Vgr.ARPA by AMSAA via smtp; 13 Mar 84 23:37 EST Received: From Hi-Multics.ARPA by BRL-VGR via smtp; 13 Mar 84 20:22 EST Date: 12 March 1984 19:29 mst From: VaughanW.REFLECS@hi-multics Subject: Re: A good deal on Shugart model 800 8-inch drives. To: David Towson cc: info-cpm@brl-vgr, info-micro@brl-vgr In-Reply-To: Message of 19 January 1984 20:14 mst from David Towson happy to hear that Selectronics still exists -- when I was at Drexel in the early 60's it was a favorite hangout of some of us radio amateurs. The people who ran it seemed to have no idea of the market value of the stuff they had, but they knew to the penny what they had paid for it - and eventually they would be able to make a profit, I guess, if they held whatever it was long enough. The stuff they sold was always good or you could take it back (unheard of among Philly surplus dealers at the time) and the prices were often fabulous. Once a friend and I bought a whole gang of computer circuit boards from them because we needed the power transistors for a project. When done strippilng them we cut all the little daughter boards off them, went down to Arch St. (Philly's Radio Row, soon to be a victim of urban renewal) and sold the daughter boards to another dealer -- got the power transistors for free and made a net profit! It's nice to know they are still doing the same stuff after 20 years. Bill (ex-WA2WCO) 14-Mar-84 22:00:40-MST,927;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 14 Mar 84 22:00:36-MST Received: From Usc-Isid.ARPA by AMSAA via smtp; 14 Mar 84 23:44 EST Date: 14 Mar 1984 12:56-PST Sender: ABN.ISCAMS@usc-isid Subject: Re: SA 850 Config or DJ2D From: ABN.ISCAMS@usc-isid To: Cargo.PD@hi-multics Cc: info-cpm@amsaa Message-ID: <[USC-ISID]14-Mar-84 12:56:27.ABN.ISCAMS> In-Reply-To: The message of 9 March 1984 09:02 cst from Cargo.PD@hi-multics Hang in there, David -- I'll get home, dig out the DJDD manual, and send you all I can. (If anyone else on the net needs/wants this, yell - the full response won't be inflicted in the net in general.) So..give me a day or two. (Incidentally, David, I'll include the PROM numbers off mine. If different from yours, there MAY be incompatibilities. Donno... Regards, David Kirschbaum Toad Hall (ABN.ISCAMS@USC-ISID) 15-Mar-84 02:07:20-MST,1322;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 15 Mar 84 02:07:15-MST Received: From Hi-Multics.ARPA by AMSAA via smtp; 15 Mar 84 3:48 EST Date: 15 March 1984 02:46 cst From: Eaton.HFED@hi-multics Subject: Champion questions To: info-cpm@amsaa I