home *** CD-ROM | disk | FTP | other *** search
/ CP/M / CPM_CDROM.iso / simtel / archives / cpm / 8705-1.txt < prev    next >
Text File  |  1993-02-12  |  117KB  |  2,769 lines

  1.  1-May-87 10:31:31-MDT,1438;000000000000
  2. Return-Path: <D-ROGERS@EDWARDS-2060.ARPA>
  3. Received: from EDWARDS-2060.ARPA by SIMTEL20.ARPA with TCP; Fri, 1 May 87 10:31:15 MDT
  4. Date: Fri 1 May 87 09:30:01-PDT
  5. From: D-ROGERS@EDWARDS-2060.ARPA
  6. Subject: z280 inquiry
  7. To: info-cpm@SIMTEL20.ARPA
  8. Message-ID: <12298928131.19.D-ROGERS@EDWARDS-2060.ARPA>
  9.  
  10. >>Date: 29 Apr 87 19:35:17 GMT
  11. >>From: mcvax!enea!tut!pl@seismo.css.gov  (Pertti Lehtinen)
  12. >>Subject: Z280
  13.  
  14. >> ....    When I was reading article, I start to wonder,
  15. >>    would there be any use for this kind of product,
  16. >>    or is this or last strike of Z80-empire.
  17.  
  18. >>    Any opinions?
  19. ---------------
  20.     I would suspect that the Z280 has a real chance only if it gets
  21. around some of the idiocies of the 8086 family, that make programming a
  22. pain, while still being able to run old Z80 code without an emulator or
  23. a Z80 option card.
  24.     Another *BIG* question is: memory manangement for HOW MUCH 
  25. memory?  If it won't allow direct access to at least 4Mb, what good is
  26. it?  Right now, my next system looks to be a 68000 running CP/M-68K.
  27. It may not run Z80 code, but i won't run short of memory any time soon.
  28. Come to think of it maybe Tandy has a good idea in their model 6000; it
  29. has both a 68000 and a Z80, although it isn't clear from the description
  30. whether the user has access to the 8 bit processor or if it is a
  31. dedicated i/o device.
  32.  
  33.    [standard disclaimers and trademark acknowledgments apply.]
  34. der
  35.  
  36. -------
  37.  2-May-87 13:31:18-MDT,888;000000000000
  38. Return-Path: <lesh@BRL.ARPA>
  39. Received: from BRL-SMOKE.ARPA by SIMTEL20.ARPA with TCP; Sat, 2 May 87 13:31:12 MDT
  40. Date:     Thu, 30 Apr 87 15:23:45 EDT
  41. From:     Steve Lesh (ISC | howard) <lesh@BRL.ARPA>
  42. To:       info-cpm@simtel20.arpa, info-apple@BRL.ARPA
  43. Subject:  configuring pcpi sftvideo
  44. Message-ID:  <8704301523.aa06678@SMOKE.BRL.ARPA>
  45.  
  46.     Fiddling around with trying to get the gs "mouse" characters out of
  47. inverse video text displays, I realized that I really don't understand how to
  48. use "configsv".  
  49.  
  50.     What is the difference between the software screen cursor control se-
  51. quences and the hardware cursor control sequences?  When would you change the
  52. software vs hardware sequences?  (I was trying to embed the gs control charac-
  53. ter to turn off the "mouse" characters in the "home cursor, clear screen" se-
  54. quence.)
  55.  
  56.     Thanks in advance.
  57.  
  58.  
  59.  
  60.                     Steven Lesh
  61.  2-May-87 17:53:38-MDT,1677;000000000000
  62. Return-Path: <@wiscvm.wisc.edu:WCSCKCU@CARLETON.BITNET>
  63. Received: from wiscvm.wisc.edu by SIMTEL20.ARPA with TCP; Sat, 2 May 87 17:53:13 MDT
  64. Received: from CARLETON.BITNET by wiscvm.wisc.edu ; Sat, 02 May 87 18:52:18 CDT
  65. Received: from WCSCKCU by CARLETON.BITNET on 02 May 87 19:07:09 EDT
  66. Date:     02 May 87 18:18:00 EDT
  67. From:     Marc Grondin <WCSCKCU%CARLETON.BITNET@wiscvm.wisc.edu>
  68. To:       <nfo-Apple@BRL.ARPA>,
  69.           <LESH@BRL.ARPA>,
  70.           <INFO-CPM@SIMTEL20.ARPA>
  71. Subject:  Re: PCPI soft video config
  72.  
  73. When you run programs in CP/M, like Turbo, Bawsic, Sweep, etc, they
  74. want to do screen positioning and clearing, this is the SOFTWARE
  75. section of the configuration.
  76.  
  77. The hardware configuration is the part that the card wants.  In
  78. your case it is an Apple //e configuration.  If you were using a
  79. Videx 80 column card, then you would be configuring your hardware
  80. section for this card.
  81.  
  82. Your idea of putting in the "Turn mouse text off" sequence into the
  83. screen refresh would be placed in the Hardware section.  Personally
  84. I beleive that you are going the wrong route.  I suggest that you
  85. find another person with a PCPI that has a different version of the
  86. drivers and try them, that is how I (Yes, I did have your mouse text
  87. trouble) solved my problem.  Now I have everything working great on
  88. my PCPI, and I'm sure once you solve the problem, that when running
  89. on a GS you will be so fast that keeping up will be fun.
  90.  
  91. If you have any comments about how the PCPI runs with the GS, please
  92. tell me, I'm interested in a GS and I can't give up my CP/M...
  93.  
  94.  
  95. Marc Grondin (8->) <Marc_Grondin@CARLETON.BITNET>, <CKCU@CARLETON.BITNET>
  96.  2-May-87 18:41:04-MDT,1520;000000000000
  97. Return-Path: <marwood@dmc-crc.arpa>
  98. Received: from dmc-crc.arpa by SIMTEL20.ARPA with TCP; Sat, 2 May 87 18:40:54 MDT
  99. Received: by dmc-crc.arpa; (4.12/4.7)
  100.         id AA08487; Sat, 2 May 87 20:39:15 edt
  101. Date: Sat, 2 May 87 20:39:15 edt
  102. From: marwood@dmc-crc.arpa (G. J. Marwood)
  103. Message-Id: <8705030039.AA08487@dmc-crc.arpa>
  104. To: info-apple@BRL.ARPA, info-cpm@simtel20.arpa, lesh@BRL.ARPA
  105. Subject: Re:  configuring pcpi sftvideo
  106.  
  107. Regarding the difference between the terminal hardware definitions and terminal
  108. software definitions for PCPI SFTVIDEO, you can consider these two things to be
  109. "interface" definitions.  The hardware definitions tell SFTVIDEO how to 
  110. communicate with your 80-column card (or whatever) using the control- or ESCape
  111. sequences which are typically used to invoke various card functions, e.g. clear
  112. screen; goto x,y etc.  These definitions should be found in the manual for the 
  113. terminal (80-col etc) card.  The software definitions are the code sequences,
  114. typically ESCape sequences, which are used to communicate between your software
  115. and SFTVIDEO.  You will see examples of this for example in the terminal   
  116. installation INSTALL/WINSTALL programs for Wordstar.  Basically, this allows 
  117. you to connect completely different terminal control functions in you 
  118. software to those in your hardware.
  119.                                I hope this helps
  120.                                          Gordon Marwood
  121. P.S. I know nothing about the mouse characters as I don't use a ][e.
  122.  3-May-87 07:43:42-MDT,1195;000000000000
  123. Return-Path: <info-cpm-request@simtel20.arpa>
  124. Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Sun, 3 May 87 07:43:29 MDT
  125. Received: by ucbvax.Berkeley.EDU (5.57/1.25)
  126.     id AA23932; Sun, 3 May 87 06:20:56 PDT
  127. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  128.     for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa)
  129.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  130. Date: 1 May 87 22:07:51 GMT
  131. From: pyramid!amdahl!cerebus!fai!wjvax!jeffs@decwrl.dec.com  (Jeffery Siou)
  132. Organization: Watkins Johnson Co., San Jose Ca. USA
  133. Subject: CP/M for Model IV
  134. Message-Id: <889@wjvax.wjvax.UUCP>
  135. Sender: info-cpm-request@simtel20.arpa
  136. To: info-cpm@simtel20.arpa
  137.  
  138.  
  139.  
  140.  
  141.  
  142. I presently own a Radio Shack Model 4. I'm looking for CP/M for it.
  143. Is anyone familiar with Motezuma Micro's CP/M that sells for $169. Is it the
  144. best available? Is there any other CP/M for my model 4. I was told to stay
  145. away from Radio Shack's version of CP/M(I think it's called CP/M Plus).
  146. Comments? Also what about this CP/M called Rose's CP/M that sells for $69.
  147. Is the Montezuma Micro version worth the extra $100. Advice and comments
  148. greatly appreciated.
  149.  
  150.  
  151. Thanks in advance.
  152.  3-May-87 07:44:06-MDT,1707;000000000000
  153. Return-Path: <info-cpm-request@simtel20.arpa>
  154. Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Sun, 3 May 87 07:43:56 MDT
  155. Received: by ucbvax.Berkeley.EDU (5.57/1.25)
  156.     id AA23949; Sun, 3 May 87 06:21:22 PDT
  157. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  158.     for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa)
  159.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  160. Date: 1 May 87 22:13:48 GMT
  161. From: pyramid!amdahl!cerebus!fai!wjvax!jeffs@decwrl.dec.com  (Jeffery Siou)
  162. Organization: Watkins Johnson Co., San Jose Ca. USA
  163. Subject: CP/M for Model 4
  164. Message-Id: <890@wjvax.wjvax.UUCP>
  165. Sender: info-cpm-request@simtel20.arpa
  166. To: info-cpm@simtel20.arpa
  167.  
  168.  
  169. This is a reposting of a previously submitted article but in the last posting
  170. I left off my location(.signature).
  171.  
  172. Thanks..
  173.  
  174.  
  175.  
  176.  
  177. I presently own a Radio Shack Model 4. I'm looking for CP/M for it.
  178. Is anyone familiar with Motezuma Micro's CP/M that sells for $169. Is it the
  179. best available? Is there any other CP/M for my model 4. I was told to stay
  180. away from Radio Shack's version of CP/M(I think it's called CP/M Plus).
  181. Comments? Also what about this CP/M called Rose's CP/M that sells for $69.
  182. Is the Montezuma Micro version worth the extra $100. Advice and comments
  183. greatly appreciated.
  184.  
  185.  
  186. Thanks in advance.
  187.  
  188.  
  189.  
  190.  
  191.  
  192.             Military Intelligence is a contradiction in terms.
  193.  
  194.                                               Groucho Marx
  195. --------
  196. jeffery siou
  197. ...!{ ucbvax!decwrl!qubix, mordor!turtlevax, ihnp4!pesnta}!wjvax!jeffs
  198.  
  199. the above opinion's expressed are solely those of mine and is not at
  200. all that of wj's or in any way related to wj's(they don't have one).
  201.  
  202. --
  203.     
  204.  3-May-87 07:44:37-MDT,1430;000000000000
  205. Return-Path: <info-cpm-request@simtel20.arpa>
  206. Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Sun, 3 May 87 07:44:28 MDT
  207. Received: by ucbvax.Berkeley.EDU (5.57/1.25)
  208.     id AA24084; Sun, 3 May 87 06:36:14 PDT
  209. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  210.     for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa)
  211.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  212. Date: 1 May 87 14:21:15 GMT
  213. From: nbires!ico!isis!ross@ucbvax.Berkeley.EDU  (Ross McConnell)
  214. Organization: University of Denver, Math/CS
  215. Subject: Re: nroff for MS-DOS or CP/M machines.
  216. Message-Id: <1791@isis.UUCP>
  217. Sender: info-cpm-request@simtel20.arpa
  218. To: info-cpm@simtel20.arpa
  219.  
  220. >>Anyone know of a nroff clone for MS-DOS or CP/M machines?
  221. >>I have a friend who has access to both of these machines and would
  222. >>like to use nroff. Public domain would be nice.
  223. >Elan Software makes an excelent WWB product, including
  224. >ditroff and some drivers. Don't have the paper address,
  225. >but their net machine is ihnp4!chinet!steinmetz!elan.
  226.  
  227. Doctor Dobb's Journal has Alan Holub's  "nr" available for $29.95. I've just
  228. received it, and haven't had a chance to really test it, but it seems like
  229. a reasonable implementation of nroff. It comes with a version of the "ms"
  230. macros, but again I haven't extensively tested them. For more details, see the
  231. last three months issues of DDJ. By the way, "nr" is for MS-DOS machines.
  232.  3-May-87 10:26:52-MDT,13892;000000000000
  233. Mail-From: KPETERSEN created at  3-May-87 10:26:42
  234. Date: Sun, 3 May 1987  10:26 MDT
  235. Message-ID: <KPETERSEN.12299451807.BABYL@SIMTEL20.ARPA>
  236. Sender: KPETERSEN@SIMTEL20.ARPA
  237. From: Keith Petersen <W8SDZ@SIMTEL20.ARPA>
  238. To:   Info-Cpm@SIMTEL20.ARPA
  239. Subject: Programming the Intel 8251a USART (long)
  240.  
  241. I don't usually post entire files to the Info-Cpm mailing list but I
  242. have had so many requests for this information that it seems
  243. appropriate.
  244.  
  245. I did NOT write this document.  It was uploaded to my RCP/M system.
  246.  
  247. --Keith Petersen
  248. Arpa: W8SDZ@SIMTEL20.ARPA
  249. Uucp: {bellcore,decwrl,harvard,lll-crg,ucbvax,uw-beaver}!simtel20.arpa!w8sdz
  250. GEnie Mail: W8SDZ
  251. RCP/M Royal Oak: 313-759-6569 (300, 1200, 2400 bps)
  252.  
  253. --cut-here--INTE8251.ART--cut-here--
  254. [ KAY*FOG RBBS | INTE8251.ART | published 05/30/85 | 379 lines  13k ]
  255.  
  256. INTEL8251:  Programming the Intel 8251A USART
  257.        by:  Ed Greenberg
  258.             Kay*Fog
  259.             CompuServe:    76703,1070
  260.             MCIMAIL:       EDG
  261.  
  262. Preface
  263. =======
  264.  
  265. This document was inspired by my collection of Intel data books.
  266. Of the three databooks, only one contains the following
  267. information.  Most microcomputer users do not have this
  268. information in their computer manuals and do not have access to
  269. the Intel manuals.  Murphy's law also states that the hobbyist
  270. will not have the required manuals at midnight on Saturday when
  271. he is busily trying to debug his communications program.
  272. [Press ENTER key for more]
  273.  
  274.  
  275. Introduction
  276. ============
  277.  
  278. In order to communicate via a serial port, a computer is equipped
  279. with a device called a Universal Asynchronous Receiver/Transmitter
  280. or UART.  This device converts a byte (written to an output port)
  281. to a series of bits sent one at a time (serially) from a
  282. communications port.  It also scans the input line on the serial
  283. port and, detecting the beginning and end of each character,
  284. assembles incoming characters and presents them on an input port.
  285.  
  286. Other names for this part are SIO's (serial input/output) or
  287. Communications adapters and USARTS (Universal Synchronous/
  288. Asynchronous Receiver/Transmitters).
  289.  
  290. This document deals with one common part - the Intel I8251a
  291. USART. That usart is used in the North Star Horizon, the Morrow
  292. Micro Decision, and other common computers.  This discussion deals
  293. with the 8251A only in asynchronous mode.  It is the mode used
  294. when communicating with a printer, a modem, a terminal and
  295. usually, another microcomputer.
  296.  
  297.  
  298. Using your USART
  299. ================
  300.  
  301. In order to use a communications port with a usart, one must
  302. first initialize it.  By doing so, one sets parameters that tells
  303. the USART how to do it's job.  One defines the parity, the number
  304. of stop and data bits, and the divisor (if any) to be applied to
  305. the incoming clock signal.
  306.  
  307. After the USART is initialized, one can read and write characters
  308. on the data port of the usart. One can also check the status of
  309. the usart on the status port.
  310.  
  311. Things to know before you start
  312. ===============================
  313.  
  314. Before you can write code for your usart, you must know the port
  315. locations on which the usart appears.  There are two ports,
  316. called the DATA port and the STATUS port.  Commands are written
  317. to the status port, and the condition of the port is read from
  318. it.  Actual characters are written to and read from the data
  319.  
  320. port.  A good place to find the port numbers is a published I/O
  321. MAP in your manual.  Another place is in a program listing of the
  322. BIOS or a communications program.  You will see something like
  323. this:
  324.  
  325. STATUS    EQU       80H
  326. DATA      EQU       81H
  327.  
  328. or the like.  Sometimes, the word MODEM is worked into the label
  329. (e.g. MODDATP for MODem DATa Port.)  Be certain that you find the
  330. correct set of ports in the case where your computer has more
  331. than one usart.
  332.  
  333. A Note About Interrupts
  334. =======================
  335.  
  336. Some computers use the facility called interrupts to signal the
  337. processor that a character is ready.  In this case, it is
  338. important for the amateur programmer to avoid messing up the
  339. interrupt structure of the machine.  You should not read or write
  340. your USART directly when it's interrupt is enabled.  Doing so may
  341. cause spurious interrupts of the processor.  The result is that
  342.  
  343. nothing will work.  Determining whether your computer uses
  344. interrupts on the communications line is beyond the scope of this
  345. document.
  346.  
  347. Initializing the usart
  348. ======================
  349.  
  350. The following code fragment is taken from the MEX overlay for the
  351. Morrow Micro Decision.  MEX is written and copyrighted by Robert
  352. Fowler.  The comments are my own.
  353.  
  354. INITMOD:  ...
  355.           ...
  356.           MVI   A,087H          ;Take the usart out of
  357.           OUT   MODCTL1         ; the condition for
  358.           OUT   MODCTL1         ;  setting the mode (*)
  359.           MVI   A,40H           ;Put it back into that
  360.           OUT   MODCTL1         ; condition.  This resets
  361.                                 ;  just about everything for
  362.                                 ;   new commands.
  363. INITMOD1: MVI   A,4EH           ;This is the MODE BYTE (*)
  364.           OUT   MODCTL1         ;Send it to the  control/status port
  365.  
  366.           MVI   A,37H           ;This is the COMMAND BYTE (*)
  367.           OUT   MODCTL1         ;Send it to the control/status port
  368.           IN    PORT            ;Clear out the DATA port
  369.  
  370.           RET                   ;Return
  371.  
  372. (*)  See the definition below
  373.  
  374. Input and Output of Characters
  375. ==============================
  376.  
  377. Below are sample routines for input and output of characters on
  378. the 8080 (or Z80) using an 8251A.
  379.  
  380. ;Input character routine.  Character is returned in A.
  381. INPUT:    IN   STATUS         ;Get the status of the usart
  382.           ANI  2              ;turn off all bits but RxR (**)
  383.           JZ   INPUT          ;go back and check again because
  384.                               ; there is no character ready
  385.           IN   DATA           ;There is a character ready,
  386.                               ; so go get it.
  387. ;OPTIONAL STEP
  388.  
  389.           ANI  7FH            ;Remove the high bit
  390.  
  391.           RET                 ;Go back to the caller
  392.  
  393. ;Output character routine.  Character is provided in C.
  394. OUTPUT:   IN   STATUS         ;Get the status of the usart
  395.           ANI  1              ;turn off all bits but TxR (**)
  396.           JZ   OUTPUT         ;Go back and check again because
  397.                               ; the USART isn't ready for another
  398.                               ;  character.
  399.           MOV  A,C            ;The USART is ready, so get the
  400.                               ; character in A for output
  401.           OUT  DATA           ;Now output it and...
  402.           RET                 ;Return to the caller.
  403.  
  404. (**)  See the definition of the Status byte below
  405.  
  406. The remainder of this document is concerned with defining the
  407. actual bytes sent to (and received from) the usart.
  408.  
  409. -----------------------------------------------------------------
  410.  
  411.  
  412. Format of the Mode Byte
  413. =======================
  414.  
  415.   7    6    5    4    3    2    1    0
  416. +----+----+----+----+----+----+----+----+
  417. |s(2)|s(1)| ep |pen |l(2)|l(1)|b(2)|b(1)|
  418. +----+----+----+----+----+----+----+----+
  419.  
  420. Content of the Mode byte
  421. ========================
  422.  
  423. s(2) and s(1) - the stop bit indicators:
  424. ----------------------------------------
  425.  
  426.         s(2)    s(1)    meaning
  427.         ----    ----    -------
  428.          0       0      Invalid
  429.          0       1      1 stop bit
  430.          1       0      1.5 stop bits
  431.          1       1      2 stop bits
  432.  
  433. ep - the parity bit
  434.  
  435. --------------------
  436.  
  437.         ep              meaning
  438.         --              -------
  439.          0              Odd parity is generated and checked
  440.          1              Even parity is generated and checked
  441.  
  442.                 Note: this bit is only active when pen is set
  443.                 to 1.
  444.  
  445. pen - the parity enable bit
  446. ---------------------------
  447.  
  448.         pen             meaning
  449.         ---             -------
  450.          0              parity disabled
  451.          1              parity enabled
  452.  
  453. l(2) and l(1) - the word length bits
  454. ------------------------------------
  455.  
  456.         l(2)    l(1)    meaning
  457.  
  458.         ----    ----    -------
  459.          0       0      5 bits
  460.          0       1      6 bits
  461.          1       0      7 bits
  462.          1       1      8 bits
  463.  
  464.                 Note:  For ASCII, we usually use only 7 or 8 bits.
  465.                 Hams and TTY/TDD (for the deaf) use 5 bits.  The only
  466.                 thing that 6 bits is used for is a colloquialism for
  467.                 seventy five cents.
  468.  
  469. b(2) and b(1) - the baud rate divisor bits
  470. ------------------------------------
  471.  
  472.         b(2)    b(1)    meaning
  473.         ----    ----    -------
  474.          0       0      synchronous
  475.          0       1      1x
  476.          1       0      16x
  477.          1       1      64x
  478.  
  479.                 Note:  This should be left alone.  Whatever
  480.  
  481.                 your system comes equipped for... that's it.
  482.  
  483. Format of the Command Byte
  484. ==========================
  485.  
  486.   7    6    5    4    3    2    1    0
  487. +----+----+----+----+----+----+----+----+
  488. |EH  |IR  |RTS |ER  |SBRK|RxE |DTR |TxEN|
  489. +----+----+----+----+----+----+----+----+
  490.  
  491. Content of the Command Byte
  492. ===========================
  493.  
  494. EH - the Enter Hunt Mode bit
  495. ----------------------------
  496.  
  497. This bit has no effect in async mode!
  498.  
  499. IR - Internal Reset
  500. -------------------
  501.  
  502.         1 Returns 8251A to Mode Instruction format.
  503.  
  504.  
  505. RTS - Request to Send
  506. ---------------------
  507.  
  508.         1 will force RTS high on the RS-232 connector.
  509.  
  510.         Note:  This assumes that the designer hooked all
  511.         the signals up on the PC board.  This is not
  512.         necessarily true.
  513.  
  514.         On some computers, where the port is wired backwards,
  515.         this will control CTS rather than RTS.
  516.  
  517. ER - Error Reset
  518. ----------------
  519.  
  520.         1 Will reset error flags in the status word
  521.         (PE OE and FE will be reset.)  See the definition
  522.         of the status word below.
  523.  
  524. SBRK - Send a break
  525. -------------------
  526.  
  527.  
  528.         1 Will send a break
  529.  
  530.         Note: Usually, one sends a command with this bit set
  531.         and then, after a delay that equals the length of a
  532.         break, one sends another command that does not have
  533.         the break bit on.
  534.  
  535. RxE - Receive Enable
  536. --------------------
  537.  
  538.         1 will enable the receiver.  If you are going to disable
  539.         the receiver for any reason, you should have a data book
  540.         in front of you and know what you're doing.  This bit
  541.         should almost always be on for any command you send.
  542.  
  543. DTR - Data Terminal Ready
  544. -------------------------
  545.  
  546.         1 will turn on Data Terminal Ready at the RS-232 connector.
  547.  
  548.         Note:  This assumes that the designer hooked all
  549.  
  550.         the signals up on the PC board.  This is not
  551.         necessarily true.
  552.  
  553.         On some computers, where the port is wired backwards,
  554.         this will control DSR rather than DTR.
  555.  
  556. TxE - Transmitter Enable
  557. ------------------------
  558.  
  559.         1 will enable the transmitter.  If you are going to disable
  560.         the transmitter for any reason, you should have a data book
  561.         in front of you and know what you're doing.  This bit should
  562.         almost always be on for any command you send.
  563.  
  564. Format of the Status Byte
  565. =========================
  566.  
  567.   7    6    5    4    3    2    1    0
  568. +----+----+----+----+----+----+----+----+
  569. |DSR |SDET|RE  |OE  |PE  |TxE |RxR |TxR |
  570. +----+----+----+----+----+----+----+----+
  571.  
  572.  
  573. Content of the Status Byte
  574. ==========================
  575.  
  576. DSR - Data Set Ready
  577. --------------------
  578.  
  579.         1 Indicates that DSR is low!  That's right, Low!
  580.  
  581.         Note that this bit may be (a) not wired at all or (b)
  582.         wired to DTR or some other pin on the RS-232 connector.
  583.         The only way to tell for sure is to look at a schematic.
  584.  
  585. SDET - SYNC Detect/ BREAK Detect
  586. --------------------------------
  587. (In the Intel documentation this is called SYNDET, not SDET.)
  588.  
  589. In async mode, this bit "will go high whenever an all zero word
  590. of the programmed length (including start bit, data bit, parity
  591. bit and *one* stop bit) is received." (***)  In other words, when
  592. the other end sends *you* a break.
  593.  
  594. This bit stays high until a reset command is issued.
  595.  
  596.  
  597. FE - Framing Error
  598. ------------------
  599.  
  600. This bit is set when "A valid stop bit is not detected at the end of
  601. every character."
  602.  
  603. This bit stays high until a reset command is issued.
  604.  
  605. OE - Overrun Error
  606. ------------------
  607.  
  608. This bit is set when a character has been pending on the USART buffer
  609. and another character comes in before the first one has been read.
  610. The first character is lost and this bit is set to alert the CPU to
  611. the problem.
  612.  
  613. This bit stays high until a reset command is issued.
  614.  
  615. PE - Parity Error
  616. -----------------
  617.  
  618.  
  619. This bit is set when a parity error is detected.
  620.  
  621. This bit stays high until a reset command is issued.
  622.  
  623. TxEMPTY - Transmit Buffer Empty
  624. -------------------------------
  625.  
  626. "When the 8251A has no characters to transmit, the TxEMPTY ...
  627. [bit will be set to 1.]  ... " (***)
  628.  
  629. RxRDY - Receiver Ready
  630. ----------------------
  631.  
  632. "This ... [bit set to 1] ... indicates that the 8251A contains
  633. a character that is ready to be input to the CPU." (***)
  634.  
  635. This is the usual bit to test to see if a character is available.
  636. Usually one sees ANI 2 (on 8080) when this bit is tested.
  637.  
  638. TxRDY - Transmitter Ready
  639. -------------------------
  640.  
  641.  
  642. "This ... [bit set to a 1] ... signals the CPU that the transmitter
  643. is ready to accept a data character."
  644.  
  645. This is the usual bit to test to see if a character may be sent.
  646. Usually one sees ANI 1 (on 8080) when this bit is tested.
  647.  
  648. ----------------------- End of INTE8251.ART Text -----------------------
  649.  3-May-87 13:26:33-MDT,1276;000000000000
  650. Return-Path: <@wiscvm.wisc.edu:MSRS003@ECNCDC.BITNET>
  651. Received: from wiscvm.wisc.edu by SIMTEL20.ARPA with TCP; Sun, 3 May 87 13:26:13 MDT
  652. Received: from ECNCDC.BITNET by wiscvm.wisc.edu ; Sun, 03 May 87 14:25:09 CDT
  653. From: Scott McBurney <MSRS003%ECNCDC.BITNET@wiscvm.wisc.edu>
  654. Subject:  CPM FOR Model 4
  655. To: JEFFERY SIOU <PYRAMID!AMDAHL!CEREBUS!FAI!WJVAX!JEFFS@decwrl>
  656.  
  657. Montezum Micro's CP/M is the best for the Model 4.  For your money you
  658. get an excellent implementation of CP/M with facilities to read disks
  659. of many other CP/M formats.  Rose's CPM is actually Montezuma's old version
  660. which was somewhat limited.  Radio Shack's CP/M plus is nice, but you can
  661. not read any other CP/M formats with it, and it doesn't have all the nice
  662. features of Montezuma's.
  663.              Scott McBurney
  664.                   Western Illinois University
  665.              --------------
  666.                   BITNET:   MSRS003@ECNCDC.BITNET
  667.                 Internet:   MSRS003%ECNCDC.BITNET@WISCVM.WISC.EDU
  668.                    GEnie:   S.MCBURNEY
  669. -----------------------------------------------------------------
  670.    Disclaimer:   Any opinions expressed herein could be the
  671.         random babblings of an idiot.
  672. -----------------------------------------------------------------
  673.  
  674.  
  675.  
  676.  3-May-87 16:46:49-MDT,2530;000000000000
  677. Return-Path: <info-cpm-request@simtel20.arpa>
  678. Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Sun, 3 May 87 16:46:40 MDT
  679. Received: by ucbvax.Berkeley.EDU (5.57/1.25)
  680.     id AA00160; Sun, 3 May 87 15:41:17 PDT
  681. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  682.     for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa)
  683.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  684. Date: 2 May 87 13:31:33 GMT
  685. From: ptsfa!nonvon!apn@ames.arpa  (root)
  686. Organization: NONVON Systems Computer Research Group
  687. Subject: Re: z280 inquiry
  688. Message-Id: <114@nonvon.UUCP>
  689. References: <12298928131.19.D-ROGERS@EDWARDS-2060.ARPA>
  690. Sender: info-cpm-request@simtel20.arpa
  691. To: info-cpm@simtel20.arpa
  692.  
  693. in article <12298928131.19.D-ROGERS@EDWARDS-2060.ARPA>, D-ROGERS@EDWARDS-2060.ARPA says:
  694. >>>Date: 29 Apr 87 19:35:17 GMT
  695. >>>From: mcvax!enea!tut!pl@seismo.css.gov  (Pertti Lehtinen)
  696. >>>Subject: Z280
  697. >>> ....    When I was reading article, I start to wonder,
  698. >>>    would there be any use for this kind of product,
  699. >>>    or is this or last strike of Z80-empire.
  700. >>>    Any opinions?
  701. > ---------------
  702. >     I would suspect that the Z280 has a real chance only if it gets
  703. > around some of the idiocies of the 8086 family, that make programming a
  704. > pain, while still being able to run old Z80 code without an emulator or
  705. > a Z80 option card.
  706. >     Another *BIG* question is: memory manangement for HOW MUCH 
  707. > memory?  If it won't allow direct access to at least 4Mb, what good is
  708. > it?  Right now, my next system looks to be a 68000 running CP/M-68K.
  709. > It may not run Z80 code, but i won't run short of memory any time soon.
  710. > Come to think of it maybe Tandy has a good idea in their model 6000; it
  711. > has both a 68000 and a Z80, although it isn't clear from the description
  712. > whether the user has access to the 8 bit processor or if it is a
  713. > dedicated i/o device.
  714. >    [standard disclaimers and trademark acknowledgments apply.]
  715. > der
  716. > -------
  717.  
  718.  
  719.     no..... the user did not have much access to the z80 processor 
  720. when on the 68k. It was a dedicated i/o processor, and tandy does not
  721. give out ( or make available) any info on how to access it.
  722.     
  723. -alex p novickis
  724.  
  725. -- 
  726. UUCP: {ihnp4,ames,qantel,sun,seismo,amdahl,lll-crg,pyramid}!ptsfa!nonvon!apn
  727.  
  728. {* Only those who attempt the absurd   ...   will achieve the impossible   *}
  729. {* I think... I think it's in my basement... Let me go upstairs and check. *}
  730. {*                                                      -escher            *}
  731.  3-May-87 19:13:53-MDT,2362;000000000000
  732. Return-Path: <info-cpm-request@simtel20.arpa>
  733. Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Sun, 3 May 87 19:13:36 MDT
  734. Received: by ucbvax.Berkeley.EDU (5.57/1.25)
  735.     id AA01723; Sun, 3 May 87 18:00:40 PDT
  736. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  737.     for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa)
  738.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  739. Date: 4 May 87 00:46:02 GMT
  740. From: umnd-cs!ub.D.UMN.EDU!rhealey@ucbvax.Berkeley.EDU  (Rob Healey)
  741. Organization: U. of Minnesota, Duluth - Computing Services
  742. Subject: Re: CP/M for Model IV
  743. Message-Id: <581@umnd-cs.D.UMN.EDU>
  744. References: <889@wjvax.wjvax.UUCP>
  745. Sender: info-cpm-request@simtel20.arpa
  746. To: info-cpm@simtel20.arpa
  747.  
  748. In article <889@wjvax.wjvax.UUCP> jeffs@wjvax.UUCP (Jeffery Siou) writes:
  749. >I presently own a Radio Shack Model 4. I'm looking for CP/M for it.
  750. >Is anyone familiar with Motezuma Micro's CP/M that sells for $169. Is it the
  751. >best available? Is there any other CP/M for my model 4. I was told to stay
  752. >away from Radio Shack's version of CP/M(I think it's called CP/M Plus).
  753. >Comments? Also what about this CP/M called Rose's CP/M that sells for $69.
  754. >Is the Montezuma Micro version worth the extra $100. Advice and comments
  755. >greatly appreciated.
  756. >
  757.  
  758.     I own a Model 4, gate array version i.e. newest, with 2 DS DD
  759.    40 track drives. I have Monte's CP/M and it IS THE CP/M for model 4's
  760.    BAR NONE. Rose's CP/M is a very old, very striped down, version
  761.    of Monte's CP/M, the extra $100.00 you pay for Monte's current version
  762.    gives you some excellent utilitys plus the ability to automatically use
  763.    the top 64K in a 128K machine as a RAM disk. I felt the $169.00 is worth
  764.    it because the current version allows alot of flexibility with disk
  765.    drives and peripherals. You would be a fool to even contemplate Tandy's
  766.    CP/M, it is a piece of SH*T plain and simple. Your choice is whether
  767.    you want a newer or VERY older version of Monte's CP/M. I think the $100
  768.    bucks you spend on the newest version would save you alot of grief down
  769.    the road. By the way, simtel20 has a huge PD library, almost 98% of the
  770.    CP/M programs I've grabbed off of simtel20 have worked first shot on
  771.    the Model 4 using Monte's CP/M, version 2.31. 
  772.  
  773.         Hope this helps,
  774.  
  775.         -Rob Healey
  776.         rhealey@ub.d.umn.edu
  777.  4-May-87 19:47:27-MDT,1047;000000000000
  778. Return-Path: <info-cpm-request@simtel20.arpa>
  779. Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Mon, 4 May 87 19:47:09 MDT
  780. Received: by ucbvax.Berkeley.EDU (5.57/1.25)
  781.     id AA24993; Mon, 4 May 87 18:38:30 PDT
  782. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  783.     for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa)
  784.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  785. Date: 4 May 87 18:40:20 GMT
  786. From: hal9000!root@RUTGERS.EDU
  787. Subject: Re: nroff for MS-DOS or CP/M machines.
  788. Message-Id: <1128@hal9000.UUCP>
  789. Sender: info-cpm-request@simtel20.arpa
  790. To: info-cpm@simtel20.arpa
  791.  
  792. In article <330@cblpf.ATT.COM>, dar@cblpf.ATT.COM (David Roth) writes:
  793. > Anyone know of a nroff clone for MS-DOS or CP/M machines?
  794.  
  795. Look in the last few issues of "Dr Dobb's Journal".  There was a series
  796. articles detailing an nroff imitator for (I think) MSDOS.  Program is
  797. available from the publisher at some low price (I don't remember, since
  798. I wasn't interested, but I would guess ~$50).  Includes source code, I
  799. think.
  800.  6-May-87 12:07:14-MDT,1605;000000000000
  801. Return-Path: <info-cpm-request@simtel20.arpa>
  802. Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Wed, 6 May 87 12:07:07 MDT
  803. Received: by ucbvax.Berkeley.EDU (5.57/1.25)
  804.     id AA25775; Wed, 6 May 87 10:49:34 PDT
  805. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  806.     for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa)
  807.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  808. Date: 6 May 87 15:33:08 GMT
  809. From: beta!dzzr@hc.dspo.gov  (Douglas J Roberts)
  810. Organization: Los Alamos Natl Lab, Los Alamos, N.M.
  811. Subject: A problem with my parallel output port (HELP, please)
  812. Message-Id: <5116@beta.UUCP>
  813. Sender: info-cpm-request@simtel20.arpa
  814. To: info-cpm@simtel20.arpa
  815.  
  816. I recently stuck an external modem on my old Northstar, using the
  817. second of its two serial ports. I then constructed a parallel cable,
  818. removed the serial interface card from the Epson MX-80, and modified
  819. my LifeBoat Associates CP/M 2.21 using MOVCPM and SYSGEN to tell
  820. the system that the printer was now on the parallel output port.
  821.  
  822. What reached the printer was (seemingly) bit-shifted garbage. The
  823. handshaking worked fine, but I suspect that the printer driver in my
  824. CPM is fouled.
  825.  
  826. I then wrote a little 8080 test code to send characters to the
  827. parallel output port, and it worked fine. I would like to modify
  828. my USER.ASM file to include a parallel port driver that I know
  829. works, but I don't know how to patch the user stuff into CPM after 
  830. I'm done.
  831.  
  832. Can anyone out there in NETLAND help? (Keith, are you listening?)
  833.  
  834. Thanks in advance for all the good help....
  835.  
  836. --Doug Roberts
  837.  
  838.  6-May-87 17:57:10-MDT,985;000000000000
  839. Return-Path: <UUCP@ncsuvx.ncsu.edu>
  840. Received: from ncsuvx.ncsu.edu by SIMTEL20.ARPA with TCP; Wed, 6 May 87 17:56:37 MDT
  841. Received: by ncsuvx.ncsu.edu (5.54/2 4/27/87)
  842.     id AA08959; Wed, 6 May 87 19:56:26 EDT
  843. Posted-Date: Wed, 6 May 87 19:49:18 EDT
  844. Received: by ncspm.ncsu.edu (4.12/smail2.2/03-06-87)
  845.     id AA03595; 6 May 87 19:49:27 EDT (Wed)
  846. From: kevin@ncspm.ncsu.edu (Kevin D. Bond)
  847. Message-Id: <8705062349.AA03595@ncspm.ncsu.edu>
  848. To: info-cpm@simtel20.arpa
  849. Date: Wed, 6 May 87 19:49:18 EDT
  850. Subject: Osborne Screen
  851. X-Mailer: Elm [version 1.5b]
  852.  
  853. Could someone please tell me if and/or how to change the osborne to
  854. display more than 40 columns when using an external monitor.
  855.  
  856. I am posting this for a friend, I know very little about the osborne.
  857.  
  858. -kevin
  859. --
  860. -------------------------------------------------------------------
  861. Kevin D. Bond                 uucp:     ...!mcnc!ncsuvx!ncspm!kevin
  862. Domain:    kevin@ncspm.ncsu.edu  internet: kevin%ncspm@ncsuvx.ncsu.edu
  863.  6-May-87 23:40:25-MDT,2911;000000000000
  864. Return-Path: <info-cpm-request@simtel20.arpa>
  865. Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Wed, 6 May 87 23:40:07 MDT
  866. Received: by ucbvax.Berkeley.EDU (5.57/1.25)
  867.     id AA08247; Wed, 6 May 87 20:46:17 PDT
  868. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  869.     for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa)
  870.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  871. Date: 5 May 87 19:41:40 GMT
  872. From: ihnp4!homxb!houxm!whuts!whuxm!davew@ucbvax.Berkeley.EDU  (WONNACOTT)
  873. Organization: AT&T Bell Laboratories
  874. Subject: configuring CP/M with ddsysgen
  875. Message-Id: <533@whuxm.UUCP>
  876. Sender: info-cpm-request@simtel20.arpa
  877. To: info-cpm@simtel20.arpa
  878.  
  879. I've got an ATR8000 CP/M system, and I'm having trouble adding new drives.
  880. I'm not sure how much of the following is true on other CP/M 2.2 systems,
  881. and how much is specific to my machine.
  882.  
  883. The ATR8000 can use several types of drives, single or double sided, 5 1/4
  884. or 8 inch, all at once.  The manual instructs you to patch CP/M with
  885. the "ddsysgen" program to configure it for the drives you install.
  886. ddsysgen is a variant of "sysgen" for double density, which has an option
  887. called "generate custom CP/M".  I got a new disk drive a while back, set
  888. the drive number on it, and plugged it in... so far, so good.
  889.  
  890. So I tried to patch CP/M with "ddsysgen".  I read in the system tracks,
  891. and then selected the option to customize CP/M.  It requested the file
  892. "SYSTEM.SWP", (SWP, INC. makes the machine).  According to the manual,
  893. this file contains the symbolic names of all the parameters you might need
  894. to change.  I was then prompted for names of locations within CP/M, and
  895. I was shown the contents to each location, and allowed to change it.
  896.  
  897. The problem came when I looked at some of the parameters, like "ONEDSK"
  898. (which makes the system use only one drive), or "RATEB" (which controls
  899. the step rate of drive B), or the parameter which controls the number of
  900. tracks on a drive (I've forgotten the name).  Some of the values there
  901. didn't seem to agree with what the manual said should be there.  And
  902. when I changed them, strange things happened.  They happened even when I
  903. took the new drive off the system, but not when I went back to my backup
  904. copy of CP/M.
  905.  
  906. It sounds a bit like I've got a bad copy of "SYSTEM.SWP", and I was just
  907. trashing random parts of the OS when I changed things.  What I want to
  908. know is: 
  909.  
  910. 1) Has anyone out there had any similar problems, and what did you do?
  911.  
  912. 2) What might be the problem, other than a bad system file?
  913.  
  914. 3) What can I do about it?  I've done some hacking of disassembled code
  915. on micros before, and I'd rather not do it again.
  916.  
  917. HELP!
  918.  
  919. -- 
  920. David Wonnacott            "They said Van Gogh was crazy, didn't they?"
  921. whuxm!davew  or  rz3bb!davew
  922. AT&T Corporate Education
  923. The above opinions are not necessarily those of AT&T, or of anyone else anywhere
  924.  7-May-87 12:18:07-MDT,1293;000000000000
  925. Return-Path: <Ghenis.pasa@Xerox.COM>
  926. Received: from Xerox.COM by SIMTEL20.ARPA with TCP; Thu, 7 May 87 12:17:54 MDT
  927. Received: from PinotNoir.ms by ArpaGateway.ms ; 07 MAY 87 11:17:37 PDT
  928. Date: 7 May 87 11:14 PDT
  929. From: Ghenis.pasa@Xerox.COM
  930. Subject: Re: Osborne Screen
  931. In-reply-to: kevin@ncspm.ncsu.edu (Kevin D. Bond)'s message of Wed, 6
  932.  May 87 19:49:18 EDT
  933. To: kevin@ncspm.ncsu.edu
  934. cc: info-cpm@simtel20.arpa
  935. Message-ID: <870507-111737-1205@Xerox>
  936.  
  937. > Could someone please tell me if and/or how to change the osborne to
  938. > display more than 40 columns when using an external monitor.
  939.  
  940. The "stock" Osborne displays up to 52 columns. There is a program called
  941. SETUP provided with the Osborne on the Utility disk which will change
  942. the number of columns you get before line-wrapping. A few public domain
  943. programs perform the same function.
  944.  
  945. HOWEVER... for more than 52 columns your text will go off the edge on
  946. BOTH the internal and external monitors. The only way around this is to
  947. get a HARDWARE VIDEO UPGRADE, like the one from Nuevo Electronics. I
  948. don't know what it costs now, but it's probably close to the market
  949. value of the Osborne itself. I faced the same dilemma and chose to keep
  950. my O-1 at 52 columns.
  951.  
  952. -- Pablo Ghenis, OKOK (Osborne Komputer Owners' Klub)
  953.  7-May-87 22:03:52-MDT,1794;000000000000
  954. Mail-From: KPETERSEN created at  7-May-87 22:03:38
  955. Date: 6  May 87 23:49 -0800
  956. Message-ID: <KPETERSEN.12300627259.BABYL@SIMTEL20.ARPA>
  957. Sender: Ken Wallewein <kenw%noah.arc.cdn%ubc.csnet@RELAY.CS.NET>
  958. From: Ken Wallewein <kenw%noah.arc.cdn%ubc.csnet@RELAY.CS.NET>
  959. To: info-cpm-request@SIMTEL20.ARPA
  960. Subject:   A problem with my parallel output port (HELP, please)
  961. ReSent-From: KPETERSEN@SIMTEL20.ARPA
  962. ReSent-To: Info-Cpm
  963. ReSent-Date: Thu 7 May 1987 22:03-MDT
  964.  
  965.   Patching the stuff in is (should be) trivial. It's a matter of reassembling 
  966. your BIOS with the appropriate device handler stuff included. Since you appear
  967. to know 8080 assembler and how to handle a parallel port, the rest should be
  968. easy. I ASSUME you have the BIOS source. Without it you're stuck.
  969.   At the very beginnning of BIOS are a bunch of CALL instructions. These are
  970. the standard BIOS entry points for all the things the BIOS does. I don't have
  971. my books here, so I can't tell you exactly which one it is. Your listing 
  972. should have it commented/labeled as LSTOUT or some such. The character to
  973. be printed will be expected in a register, probably C. Your LSTOUT routine
  974. should wait until the printer's not busy, send the character, and return.
  975. I don't think return status is important here.
  976.   As I said, you really need your BIOS listing. Read the existing code to
  977. see what it does, following the path from the entry point at the top. It also
  978. helps to have access to a CP/M Internals book. One of the best (I can't 
  979. remember the title) was written by Donald Cortesi of Dr. Dobb's Journal.
  980. All you really need are the BIOS entry point and register-handling conventions.
  981. You MIGHT want to worry about the USTAT byte for device redirection (via STAT),
  982. but I never bother with that. Good luck.
  983. /kenw
  984.  8-May-87 09:15:30-MDT,1225;000000000000
  985. Return-Path: <@wiscvm.wisc.edu:BOBW@USU.BITNET>
  986. Received: from wiscvm.wisc.edu by SIMTEL20.ARPA with TCP; Fri, 8 May 87 09:14:46 MDT
  987. Received: from USU.BITNET by wiscvm.wisc.edu ; Fri, 08 May 87 09:47:13 CDT
  988. Date:     Fri, 8 May 87 08:06 MST
  989. From:     <BOBW%USU.BITNET@wiscvm.wisc.edu> (BOB WOOD WA7MXZ)
  990. Subject:  North Star Parallel Port Patching
  991. To:       info-CPM@simtel20.arpa
  992. X-Original-To:  info-CPM@simtel20.arpa
  993.  
  994. Re: North Star Parallel Port.
  995.  
  996. ACCORDING TO MY LIFEBOAT MANUAL, THERE IS A PARALLEL PRINTER DRIVER ALREADY
  997. INCLUDED IN THEIR CPM THAT WORKS FINE (I TRIED IT). YOU'LL HAVE TO FIND WHERE
  998. THE PROPER OFFSETS ARE FOR YOUR INSTALLATION OF CPM. These addresses are the
  999. distribution offsets.
  1000. right now HLIST points to a jump to the serial port:
  1001. 5A09 C3525A     HLIST  JMP    HOROUT1    ; Right Serial Port
  1002. my address is FA09 for 56K CPM.
  1003. the address for HOROUT1 is 5A5D. To get the parallel to work you point to
  1004. error in above line... HOROUT1 is at 5A52 (FA52) HOROUT2 (parallel) is at
  1005. 5A5D (FA5D). All I did was patch location FA0A to 5D and then ran:
  1006. A>SAVEUSER
  1007. Saveuser is the Lifeboat user area patch program.
  1008. This works for the Horizon, I hope you don't have an Advantage.
  1009. Bob Wood
  1010.  8-May-87 09:59:52-MDT,1591;000000000000
  1011. Return-Path: <kenw%noah.arc.cdn%ubc.csnet@RELAY.CS.NET>
  1012. Received: from RELAY.CS.NET by SIMTEL20.ARPA with TCP; Fri, 8 May 87 09:59:22 MDT
  1013. Received: from relay2.cs.net by RELAY.CS.NET id ac15332; 8 May 87 11:52 EDT
  1014. Received: from ubc by RELAY.CS.NET id ad05895; 8 May 87 11:46 EDT
  1015. Received: by ubc.csnet id AA10521; Fri, 8 May 87 08:20:57 pdt
  1016. Date: 8  May 87  0:20 -0800
  1017. From: Ken Wallewein <kenw%noah.arc.cdn%ubc.csnet@RELAY.CS.NET>
  1018. To: info-cpm-request@SIMTEL20.ARPA
  1019. MMDF-Warning:  Parse error in original version of preceding line at RELAY.CS.NET
  1020. Cc: info-cpm@SIMTEL20.ARPA
  1021. MMDF-Warning:  Parse error in original version of preceding line at RELAY.CS.NET
  1022. In-Reply-To: <533@whuxm.UUCP>
  1023. Message-Id: <110*kenw@noah.arc.cdn>
  1024. Subject: configuring CP/M with ddsysgen
  1025.  
  1026.   What you probably have is a previously customized version of your SYSTEM.SWP
  1027. file. If an entry doesn't need to be changed to add your disk drive, don't
  1028. change it. Some of them MAY be worth tinkering with, but it helps if you know
  1029. what they're for. And, of course, only make minimum changes between tests. 
  1030.  
  1031.   Whether your drive is physically connected or not will probably make no
  1032. difference whatsoever to your use of the rest of the machine.
  1033.  
  1034.   Question: If you use ddsysgen (I have one of those, too, but it's nothing
  1035. like yours) without making any changes, is the result useable? 
  1036.  
  1037.   I presume you don't have the source for your BIOS: my sympathies. If you
  1038. decide to disassemble it, I recommend RESOURCE, ZESOURCE, or DASM, and you'll
  1039. need to read the instructions :-).
  1040.  
  1041. Good luck.
  1042. /kenw
  1043.  
  1044.  8-May-87 13:26:54-MDT,1561;000000000000
  1045. Return-Path: <@wiscvm.wisc.edu:RMALOUF@SBCCMAIL.BITNET>
  1046. Received: from wiscvm.wisc.edu by SIMTEL20.ARPA with TCP; Fri, 8 May 87 13:26:19 MDT
  1047. Received: from SBCCMAIL.BITNET by wiscvm.wisc.edu ; Fri, 08 May 87 14:24:10 CDT
  1048. Date:     Fri, 8 May 87 15:22 EDT
  1049. From:     <RMALOUF%SBCCMAIL.BITNET@wiscvm.wisc.edu> (Rob Malouf)
  1050. Subject:  Osborne Screen
  1051. To:       info-cpm@simtel20.arpa
  1052. X-Original-To:  info-cpm@simtel20.arpa
  1053.  
  1054.  
  1055. > Could someone please tell me if and/or how to change the osborne to
  1056. > display more than 40 columns when using an external monitor.
  1057.  
  1058. Even with an upgrade (at least the OCC factory upgrade), the Osborne external
  1059. monitor attached to the "MONITOR" port will not display 80/132 columns without
  1060. an extra doo-dad.  Only the composite RCA jack outputs 80/132 column video.
  1061.  
  1062. The adaptor, which I received from OCC with my newly upgraded tan case Osborne,
  1063. seems to convert the composite output to whatever the Osborne monitor uses and
  1064. adds the power lines.
  1065.  
  1066. BTW, doe anybody know why removing the little dummy plug from the "MONITOR"
  1067. jack with the power on fries its innards?  The manual warns about that, and
  1068. once I accidentally did it, and sure enough, the video subsystem died.  How
  1069. come?
  1070.  
  1071.  
  1072.                                         Rob Malouf
  1073.                                         Marine Sciences Research Center
  1074.                                         State University of New York
  1075.                                         Stony Brook, NY  11794-5000
  1076.                                         RMALOUF@SBCCMAIL.BITNET
  1077.  9-May-87 11:46:24-MDT,1838;000000000000
  1078. Mail-From: KPETERSEN created at  9-May-87 11:46:07
  1079. Date: Sat, 9 May 1987  11:46 MDT
  1080. Message-ID: <KPETERSEN.12301039127.BABYL@SIMTEL20.ARPA>
  1081. Sender: KPETERSEN@SIMTEL20.ARPA
  1082. From: Keith Petersen <W8SDZ@SIMTEL20.ARPA>
  1083. To:   INFO-HZ100@RADC-TOPS20.ARPA, INFO-IBMPC@C.ISI.EDU
  1084. Cc:   Info-Cpm@SIMTEL20.ARPA, Info-Micro@BRL.ARPA
  1085. Subject: Copyright status of ARC, LZW, and COMPRESS programs questioned
  1086.  
  1087. After announcing the availability of a recent update of SEA's ARC
  1088. program, I received the following message which raises serious doubts
  1089. as to the validity of the copyrights of SEA, Phil Katz, and Vernon
  1090. Berg's ARC programs and well as other LZW-type compression programs
  1091. and the status of the popular Unix "compress" program.
  1092.  
  1093. --Keith Petersen
  1094. Arpa: W8SDZ@SIMTEL20.ARPA
  1095. Uucp: {bellcore,decwrl,harvard,lll-crg,ucbvax,uw-beaver}!simtel20.arpa!w8sdz
  1096. GEnie Mail: W8SDZ
  1097.  
  1098. --forwarded message--
  1099. To: Keith Petersen <W8SDZ@SIMTEL20.ARPA>
  1100. Re: Message for the authors of ARC
  1101.  
  1102. I don't know how to get in touch with the authors of ARC (I didn't see
  1103. any addresses in INFO-IBMPC), but since you seem to be posting information
  1104. about new versions, etc., I thought that you might be able to forward the
  1105. following mail to them.
  1106.  
  1107. 1) The correct spelling of the name is Ziv.  So you should call it
  1108. Lempel-Ziv (or Ziv-Lempel because that was the order of the author's
  1109. names in the original paper) encoding.
  1110.  
  1111. 2) The original Ziv-Lempel method is patented (#4,464,650 -- Willard
  1112. Eastman, Abraham Lempel, Jacob Ziv, Martin Cohen) assigned to Sperry
  1113. Univac (now Unisys).  Since the Welch modifications are to this
  1114. method, I would think that some sort of license agreement from Unisys
  1115. would be necessary (this is really only a practical problem for
  1116. commercial customers).  Does such an agreement exist?
  1117.  
  1118. --end forwarded message--
  1119. 11-May-87 23:39:03-MDT,2919;000000000000
  1120. Return-Path: <info-cpm-request@simtel20.arpa>
  1121. Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Mon, 11 May 87 23:38:49 MDT
  1122. Received: by ucbvax.Berkeley.EDU (5.57/1.25)
  1123.     id AA26761; Mon, 11 May 87 22:37:36 PDT
  1124. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  1125.     for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa)
  1126.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  1127. Date: 11 May 87 22:04:51 GMT
  1128. From: cbmvax!fred@RUTGERS.EDU  (Fred Bowen)
  1129. Organization: Commodore Technology, West Chester, PA
  1130. Subject: Re: 6DEC vs. 8DEC - CP/M
  1131. Message-Id: <1862@cbmvax.cbmvax.cbm.UUCP>
  1132. References: <358@cup.portal.com>
  1133. Sender: info-cpm-request@simtel20.arpa
  1134. To: info-cpm@simtel20.arpa
  1135.  
  1136. > I have heard numerous accounts as to the nature of the 8DEC version of CP/M
  1137. > for the C-128.  I'm interested in learning if this version is indeed
  1138. > available and being shipped with current equipment, and exactly what it
  1139. > achieves in the way of bug-fixes.
  1140.  
  1141. The following explanation comes from Alex Orgil, CBM Canada, where the 'bug'
  1142. was found (I was busy with other stuff at the time):
  1143.  
  1144. -----------------------------------------------------------------------------
  1145. As I recall, the difference was simply that the final line feed was not being
  1146. sent to the printer to clear the buffer, thus your last line didn't get
  1147. printed until you tried to print something else. This may have only occurred
  1148. wiht the MPS1000 printers though. The change was a single byte (or possibly
  1149. a string) in the BIOS. The fixed version was labelled DEC 8 by Von, and 
  1150. later found its way into production. The NEWSYS.COM program for updating
  1151. the system was not changed (but was posted in public domain on Compuserve).
  1152. For Canada we made a special version of NEWSYS to reflect the change which
  1153. was made available through our [Canada] Parts department. But to make this
  1154. different, I also changed the date to read dec 8 (tricky hey?) so that we
  1155. could be sure of what they are using.
  1156. -----------------------------------------------------------------------------
  1157.  
  1158. Ergo, (love that word!) for most users there is no real difference between
  1159. the two versions.  I have asked Alex to send me the patches he made to
  1160. NEWSYS.COM, and will post them for those people who can't bear not having
  1161. the absolute latest BIOS, whether they have an MPS-1000 or not.
  1162.  
  1163. I am putting the wraps on a new version which supports the 3.5" 1581 drive
  1164. which should be showing up on shelves "any day now."   Those of you who are
  1165. still reading may want to wait until the "1581" version is available before
  1166. you bother patching your 06DEC85 version.
  1167.  
  1168. I know better than to ask if there are any other CP/M bugs worth fixing...
  1169. --
  1170. --
  1171. -- 
  1172. Fred Bowen            uucp:    {ihnp4|seismo|caip}!cbmvax!fred
  1173.                 arpa:    cbmvax!fred@seismo.css.GOV
  1174.                 tele:    215 431-9100
  1175.  
  1176. Commodore Electronics, Ltd.,  1200 Wilson Drive,  West Chester,  PA,  19380
  1177. 12-May-87 03:38:33-MDT,1145;000000000000
  1178. Return-Path: <info-cpm-request@simtel20.arpa>
  1179. Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Tue, 12 May 87 03:38:22 MDT
  1180. Received: by ucbvax.Berkeley.EDU (5.57/1.25)
  1181.     id AA00293; Tue, 12 May 87 02:34:50 PDT
  1182. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  1183.     for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa)
  1184.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  1185. Date: 11 May 87 18:29:49 GMT
  1186. From: jade!lapis.berkeley.edu!oster@ucbvax.Berkeley.EDU  (David Phillip Oster)
  1187. Organization: University of California, Berkeley
  1188. Subject: Using a KayPro 4-e Internal Modem?
  1189. Message-Id: <3531@jade.BERKELEY.EDU>
  1190. Sender: info-cpm-request@simtel20.arpa
  1191. To: info-cpm@simtel20.arpa
  1192.  
  1193. I am trying to use a KayPro 4-e, with an internal modem that takes a phone
  1194. cable and directly connects to the phone system. Does anyone out there
  1195. know:
  1196. 1.) Is this machine, by any chance, equipped with a 1200/300 baud modem or
  1197. is it just 300 baud?
  1198. 2.) Do you have to run some command, or set some switch, or type something
  1199. to the supplied terminal software to use the internal modem rather than an
  1200. external serial port?
  1201. 12-May-87 19:12:45-MDT,1223;000000000000
  1202. Return-Path: <info-cpm-request@simtel20.arpa>
  1203. Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Tue, 12 May 87 19:12:31 MDT
  1204. Received: by ucbvax.Berkeley.EDU (5.57/1.25)
  1205.     id AA15237; Tue, 12 May 87 17:55:48 PDT
  1206. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  1207.     for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa)
  1208.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  1209. Date: 12 May 87 17:58:32 GMT
  1210. From: ptsfa!nonvon!root@ames.arpa  (root)
  1211. Organization: NONVON Systems Computer Research Group
  1212. Subject: WANTED: MEX overlay, generic
  1213. Message-Id: <309@nonvon.UUCP>
  1214. Sender: info-cpm-request@simtel20.arpa
  1215. To: info-cpm@simtel20.arpa
  1216.  
  1217. I would to get a copy of the "generic" or any for that matter,
  1218. overlays for MEX ( modem executive ). I have the PD version, and
  1219. not the latest. Could someone that has a copy please  mail me 
  1220. a note.
  1221.  
  1222. Thanks,
  1223. Alex P Novickis
  1224.  
  1225.  
  1226. UUCP: {ihnp4,ames,qantel,sun,seismo,amdahl,lll-crg,pyramid}!ptsfa!nonvon!apn
  1227.  
  1228. {* Only those who attempt the absurd   ...   will achieve the impossible   *}
  1229. {* I think... I think it's in my basement... Let me go upstairs and check. *}
  1230. {*                                                      -escher            *}
  1231. 13-May-87 22:03:05-MDT,4848;000000000000
  1232. Mail-From: KPETERSEN created at 13-May-87 22:02:29
  1233. Date: Monday, 11 May 1987  21:56-MDT
  1234. Message-ID: <KPETERSEN.12302199905.BABYL@SIMTEL20.ARPA>
  1235. Sender: "James A. Woods" <jaw%aurora.uucp@BRL.ARPA>
  1236. From: "James A. Woods" <jaw%aurora.uucp@BRL.ARPA>
  1237. To: info-micro@BRL-VGR.ARPA
  1238. Subject:   Copyright status of ARC, LZW, and COMPRESS programs questioned
  1239. ReSent-From: KPETERSEN@SIMTEL20.ARPA
  1240. ReSent-To: Info-Cpm at SIMTEL20.ARPA
  1241. ReSent-Date: Wed 13 May 1987 22:02-MDT
  1242.  
  1243. # "Don't compress that dwarf -- hand me the pliers!" -- after Firesign Theatre
  1244.  
  1245. > 2) The original Ziv-Lempel method is patented (#4,464,650 -- Willard
  1246. > Eastman, Abraham Lempel, Jacob Ziv, Martin Cohen) assigned to Sperry
  1247. > Univac (now Unisys).  Since the Welch modifications are to this
  1248. > method, I would think that some sort of license agreement from Unisys
  1249. > would be necessary (this is really only a practical problem for
  1250. > commercial customers).  Does such an agreement exist?
  1251.      Professor Lempel once telephoned me to praise the existence of a
  1252. public domain implementation of the LZ algorithm.  Though I can take credit
  1253. only for the encoder hashing method currently used in 'compress', as well
  1254. as its "block-adaptive" table reset strategy (we remain indebted to Spencer
  1255. Thomas of the Univ. of Utah who gave USENET the basic framework), I'll
  1256. repeat here a comment relayed to me after a Lempel lecture at HP Labs.
  1257.  
  1258.      The story goes like this:  apparently the Welch paper came to the
  1259. light of day only after Sperry Research Labs was disbanded, this occurring
  1260. long before the Burroughs acquisition.  Supposedly, discoveries revert
  1261. to the general public when a lab ceases to exist.  Note this is *not*
  1262. the same as the situation engendered by the recent asset transfer from GE
  1263. to SRI of the RCA David Sarnoff Labs.
  1264.  
  1265.      In any event, the Welch implementation (Computer, vol. 17, #6, 1984)
  1266. only claimed that the presented "hardware" string table creation and access
  1267. method was "Sperry proprietary".  Details of any software-based code/index
  1268. storage scheme in existence at Sperry were deliberately left fuzzy in the paper.
  1269.  
  1270.      Since patents cover only "apparatus", no one is making claims for
  1271. any of the algorithmic variants of LZ, of which there are many (see below).
  1272. As for the copyright status of 'compress', Thomas and I (who both work at
  1273. public institutions) have signed (meaningless?) waivers not only to UCB
  1274. for the 4.3 distribution, but to Hewlett Packard for inclusion in their
  1275. own Unix release.  The latter is most ironic, since HP retained Lempel
  1276. as a consultant for a year on sabbatical leave from Technion in Israel,
  1277. where he was chairman of the computer science department.
  1278.  
  1279.      ARC is another matter, of which I know little.  It is fine by me
  1280. if someone sells a value-added 'compress' (you'd pay for the packaging
  1281. and "support").  Other companies sell the Unix LZ as part of a product
  1282. (the Talaris 'troff' software includes compressed fonts this way).  Now
  1283. I hear that Dan Robinson of Telebit (our friendly neighborhood 18 kbps
  1284. modem supplier) has valiantly jammed compression into the modem ROM,
  1285. adding a few tricks of his own, no doubt.  Speaking again only for myself,
  1286. it doesn't matter even if raw unadorned 'compress' were sold for a megabuck --
  1287. word would get around very quickly that it's available free from other
  1288. sources.
  1289.  
  1290.      LZ algorithms are not the be-all-end-all of data compression techniques.
  1291. They don't particularly work well (unmodified), for digital sound processing
  1292. or color picture reduction, for example.  Many variants employ equally many
  1293. time-space tradeoffs, with software implementations using data structures
  1294. ranging from binary trees, to "trie forests", to hash coding, to a direct
  1295. sparse array access exercise (for multi-megabyte machines) I posted to
  1296. USENET back in 1984/5.  Software work continuing at the Univ. of Calgary
  1297. should be mentioned, where Tim Bell claims a 5-10% rate improvement (for
  1298. ASCII-only input, alas), and unfortunately using an encoder which runs
  1299. a hefty order-of-magnitude slower, limiting application.  (See his IEEE Trans.
  1300. Comm. paper of Dec. 1986, which oddly sidesteps direct comparisons with
  1301. 'compress').  Also, many ad hoc and not-so-ad hoc methods have been offered
  1302. to squeeze data, including the very involved Markov schemes of Cleary
  1303. and Witten, and the nouveau self-adaptive splay-tree amortization 
  1304. algorithms of Bentley and Tarjan.
  1305.  
  1306.      I could go on, but close by indicating that though optimal data
  1307. compression in general is unsolvable in the Turing sense, and though
  1308. many problem subclasses are NP-complete, the beautifully simple, linear,
  1309. and general method of Ziv and Lempel is hard to improve upon, and certainly
  1310. affords many approaches not subject to legal intervention.
  1311.  
  1312.      -- James A. Woods (ames!jaw)
  1313. 13-May-87 22:10:57-MDT,1080;000000000000
  1314. Return-Path: <info-cpm-request@simtel20.arpa>
  1315. Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Wed, 13 May 87 22:10:33 MDT
  1316. Received: by ucbvax.Berkeley.EDU (5.57/1.25)
  1317.     id AA13838; Wed, 13 May 87 20:58:35 PDT
  1318. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  1319.     for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa)
  1320.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  1321. Date: 13 May 87 17:11:02 GMT
  1322. From: decvax!dartvax!stevel@ucbvax.Berkeley.EDU  (Steve Ligett)
  1323. Organization: Dartmouth College, Hanover, NH
  1324. Subject: For sale: Morrow MD1
  1325. Message-Id: <6198@dartvax.UUCP>
  1326. Sender: info-cpm-request@simtel20.arpa
  1327. To: info-cpm@simtel20.arpa
  1328.  
  1329. I (for Dartmouth) have a single drive Micro Decision for sale.
  1330. It's been in a warehouse since '84, and I don't know much about
  1331. it, except I believe it works.  It has a lot of documentation,
  1332. and a few disks.
  1333.  
  1334. Is it worth $100?  Make an offer!
  1335.  
  1336. My phone number is 603 646-3189.
  1337. -- 
  1338.      Steve Ligett  stevel@dartmouth.edu  or
  1339. (astrovax cornell decvax harvard ihnp4 linus true)!dartvax!stevel
  1340. 14-May-87 22:01:00-MDT,775;000000000000
  1341. Return-Path: <@wiscvm.wisc.edu:V125KJG8@UBVMS.BITNET>
  1342. Received: from wiscvm.wisc.edu by SIMTEL20.ARPA with TCP; Thu, 14 May 87 22:00:46 MDT
  1343. Received: from UBVMS.BITNET by wiscvm.wisc.edu ; Thu, 14 May 87 23:00:10 CDT
  1344. Date:     Thu, 14 May 87 23:58 EDT
  1345. From:     <V125KJG8%UBVMS.BITNET@wiscvm.wisc.edu>
  1346. Subject:  Bank Switching Z-System on the HD64180
  1347. To:       info-cpm@simtel20.arpa
  1348. X-Original-To:  cpm, V125KJG8
  1349.  
  1350. Can anybody out there figure out a way to effectively bank switch the BDOS
  1351. and BIOS portion of Z-System into bank 1 (or any other bank) of the HD64180
  1352. so I can push the TPA size over my cramped 49K?  Any hints or helps out there
  1353. would be appreciated.
  1354.  
  1355.   --Curtis R. Anderson
  1356.   State University of New York at Buffalo
  1357.  
  1358.   V125KJG8@UBVMS.BITNET
  1359. 15-May-87 05:55:44-MDT,703;000000000000
  1360. Mail-From: RCONN created at 15-May-87 05:55:40
  1361. Date: Fri, 15 May 87 05:55:40 MDT
  1362. From: Rick Conn <RCONN@SIMTEL20.ARPA>
  1363. Subject: Re: Bank Switching Z-System on the HD64180
  1364. To: V125KJG8%UBVMS.BITNET@WISCVM.WISC.EDU
  1365. cc: info-cpm@SIMTEL20.ARPA
  1366. In-Reply-To: Message from "<V125KJG8%UBVMS.BITNET@wiscvm.wisc.edu>" of Thu, 14 May 87 22:13:45 MDT
  1367. Message-ID: <12302548203.9.RCONN@SIMTEL20.ARPA>
  1368.  
  1369. Hello, Curtis,
  1370.     Echelon is working the bank switching problem, last I heard.
  1371. Perhaps you should contact them to see how they are coming.  It really
  1372. isn't an easy problem at all, especially with environment descriptor and
  1373. message buffer access being required for Z System operation.
  1374.  
  1375.         Rick
  1376. -------
  1377. 15-May-87 11:00:04-MDT,1301;000000000000
  1378. Return-Path: <D-ROGERS@EDWARDS-2060.ARPA>
  1379. Received: from EDWARDS-2060.ARPA by SIMTEL20.ARPA with TCP; Fri, 15 May 87 10:59:38 MDT
  1380. Date: Fri 15 May 87 09:59:21-PDT
  1381. From: D-ROGERS@EDWARDS-2060.ARPA
  1382. Subject: HD64180 PAGING
  1383. To: info-cpm@SIMTEL20.ARPA
  1384. Message-ID: <12302603487.15.D-ROGERS@EDWARDS-2060.ARPA>
  1385.  
  1386. >14-May-87 21:24:45-PDT,870;000000000001
  1387. >From:     <V125KJG8%UBVMS.BITNET@wiscvm.wisc.edu>
  1388. >Subject:  Bank Switching Z-System on the HD64180
  1389. >
  1390. >Can anybody out there figure out a way to effectively bank switch the BDOS
  1391. >and BIOS portion of Z-System into bank 1 (or any other bank) of the HD64180
  1392. >so I can push the TPA size over my cramped 49K?  Any hints or helps out there
  1393. >would be appreciated.
  1394. >
  1395. >  --Curtis R. Anderson
  1396. >  State University of New York at Buffalo
  1397.  
  1398.     I suspect you will have to work out a jump_over arrangement, the
  1399. way PDP11 macro programmers have to avoid the I/O page.  I don't have an
  1400. HD64180 but the data sheets i received from Hitachi seem to indicate that
  1401. the paging is accomplished similarly to the PDP's Page Descriptor Reg's.
  1402.     A possible alternative would be to put the BDOS & BIOS in the last
  1403. page and write the page switching into the jump chain - more difficult to
  1404. impliment, but maybe easier to use over the long run.        [dale]
  1405.  
  1406. -------
  1407. 15-May-87 11:38:07-MDT,1122;000000000000
  1408. Return-Path: <bridger@rand-unix.ARPA>
  1409. Received: from rand-unix.arpa by SIMTEL20.ARPA with TCP; Fri, 15 May 87 11:37:55 MDT
  1410. Received: by rand-unix.arpa; Fri, 15 May 87 10:00:15 PDT
  1411. Message-Id: <8705151700.AA17129@rand-unix.arpa>
  1412. To: "Curtis R. Anderson" <V125KJG8%UBVMS.BITNET@wiscvm.wisc.edu>
  1413. Cc: info-cpm@simtel20.arpa
  1414. Subj: larger tpa & bank-switched OS for HD64180
  1415. Date: Fri, 15 May 87 09:59:56 PDT
  1416. From: bridger@rand-unix.ARPA
  1417.  
  1418. Good news and bad news:
  1419.  
  1420. A new OS for -180 systems is under development.  It will support ZCPR33
  1421. plus some major new features, including larger tpa and bank memory management.
  1422.  
  1423. Meanwhile, if you are running an SB180 or SB180FX, Malcolm Kemp's
  1424. almost-released XBIOS will have most of the bios banked, disk cache,
  1425. and other features.  It's a worthwhile intermediate solution.
  1426.  
  1427. Finally, you can increase TPA in a "full" Z-System by assembling it
  1428. without allocating space for IOP and/or RCP buffers.  Many users
  1429. make little or no use of the IOP.
  1430.  
  1431. However, the ZRDOS (all versions) as it stands cannot be bank-switched.
  1432. It, like CP/M 2.2, uses 3.5K of tpa.
  1433.  
  1434. --bridger
  1435. 15-May-87 13:41:58-MDT,1210;000000000000
  1436. Return-Path: <info-cpm-request@simtel20.arpa>
  1437. Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Fri, 15 May 87 13:41:46 MDT
  1438. Received: by ucbvax.Berkeley.EDU (5.57/1.25)
  1439.     id AA29387; Fri, 15 May 87 12:25:18 PDT
  1440. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  1441.     for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa)
  1442.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  1443. Date: 9 May 87 22:04:08 GMT
  1444. From: ken@cs.rochester.edu  (Ken Yap)
  1445. Organization: U of Rochester, CS Dept, Rochester, NY
  1446. Subject: Re: Copyright status of ARC, LZW, and COMPRESS programs questioned
  1447. Message-Id: <27622@rochester.ARPA>
  1448. References: <KPETERSEN.12301039127.BABYL@SIMTEL20.ARPA>
  1449. Sender: info-cpm-request@simtel20.arpa
  1450. To: info-cpm@simtel20.arpa
  1451.  
  1452. I thought the L-Z compression algorithm was published in a journal for
  1453. all to see.  Furthermore, I may be wrong, but it is my understanding
  1454. that one cannot patent algorithms (being "laws of nature"), although
  1455. one can patent realizations of an algorithm. So if I read the journal
  1456. article and went off and wrote a C program based on the algorithm I'd
  1457. have no problems.
  1458.  
  1459. Disclaimer: I may be talking rubbish.  Anybody know better?
  1460.  
  1461.     Ken
  1462. 15-May-87 15:28:55-MDT,754;000000000000
  1463. Return-Path: <mead%hamal.usc.edu@usc-oberon.arpa>
  1464. Received: from oberon.USC.EDU by SIMTEL20.ARPA with TCP; Fri, 15 May 87 15:28:47 MDT
  1465. Received: by oberon.USC.EDU (5.51/5.5) id AA03018; 
  1466.     Fri, 15 May 87 14:15:23 PDT
  1467. Received: by hamal.usc.edu (3.2/SMI-3.0DEV3)
  1468.     id AA20328; Fri, 15 May 87 14:15:14 PDT
  1469. Date: Fri 15 May 87 14:15:10-PDT
  1470. From: Dick <MEAD%hamal@oberon.USC.EDU>
  1471. Subject: NOAH (what's its Stat?)
  1472. To: info-cpm@SIMTEL20.ARPA
  1473. Message-Id: <SUN-MM(195)+TOPSLIB(124) 15-May-87 14:15:10.hamal>
  1474. Desires: "gag me with a Valley girl"    (ohmigod!)
  1475.  
  1476.  
  1477. Is there any word on NOAH, the CP/M-80 version of ARC (plus a bunch, I hope)??
  1478. Is there a beta-tester reading this that can comment? Is NOAH dead?
  1479.  
  1480. Dick <Mead@hamal.usc.edu>
  1481.  
  1482. -------
  1483. 16-May-87 01:25:46-MDT,1428;000000000000
  1484. Return-Path: <info-cpm-request@simtel20.arpa>
  1485. Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Sat, 16 May 87 01:25:37 MDT
  1486. Received: by ucbvax.Berkeley.EDU (5.57/1.25)
  1487.     id AA11663; Fri, 15 May 87 22:39:41 PDT
  1488. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  1489.     for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa)
  1490.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  1491. Date: 15 May 87 11:29:27 GMT
  1492. From: ptsfa!nonvon!apn@ames.arpa  (root)
  1493. Organization: NONVON Systems Computer Research Group
  1494. Subject: Re: Bank Switching Z-System on the HD64180
  1495. Message-Id: <315@nonvon.UUCP>
  1496. References: <8705150402.AA10559@ucbvax.Berkeley.EDU>
  1497. Sender: info-cpm-request@simtel20.arpa
  1498. To: info-cpm@simtel20.arpa
  1499.  
  1500. in article <8705150402.AA10559@ucbvax.Berkeley.EDU>, V125KJG8@UBVMS.BITNET says:
  1501. > Can anybody out there figure out a way to effectively bank switch the BDOS
  1502. > and BIOS portion of Z-System into bank 1 (or any other bank) of the HD64180
  1503. > so I can push the TPA size over my cramped 49K?  Any hints or helps out there
  1504. > would be appreciated.
  1505. >   --Curtis R. Anderson
  1506. >   State University of New York at Buffalo
  1507. >   V125KJG8@UBVMS.BITNET
  1508.  
  1509.  
  1510. That's easy.... throw away Z-(whatever) and get CP/M 3.1 At least there you have
  1511. a 63k tpa.   Disk I/O is faster.... LRU buffering is active, hashing on
  1512. hard disk directories.....
  1513.  
  1514.  
  1515. Alex P Novickis
  1516. Fulcrum Computer Products
  1517. 16-May-87 03:42:12-MDT,987;000000000000
  1518. Return-Path: <info-cpm-request@simtel20.arpa>
  1519. Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Sat, 16 May 87 03:42:03 MDT
  1520. Received: by ucbvax.Berkeley.EDU (5.57/1.25)
  1521.     id AA15290; Sat, 16 May 87 02:38:02 PDT
  1522. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  1523.     for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa)
  1524.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  1525. Date: 15 May 87 20:33:04 GMT
  1526. From: sargas.usc.edu!tli@OBERON.USC.EDU  (Tony Li)
  1527. Organization: University of Southern California, Los Angeles
  1528. Subject: Looking for author of ZM.
  1529. Message-Id: <2162@sargas.usc.edu>
  1530. Sender: info-cpm-request@simtel20.arpa
  1531. To: info-cpm@simtel20.arpa
  1532.  
  1533. I looking for Roger Donnais (sp?), the author of the ZM z80-assembler.
  1534. Does anyone know how to get in touch with him?
  1535.  
  1536. ;-)
  1537. -- 
  1538. Tony Li - USC University Computing Services    "Fene mele kiki bobo"
  1539. Uucp: oberon!tli                        -- Joe Isuzu
  1540. Bitnet: tli@uscvaxq, tli@ramoth
  1541. Internet: tli@sargas.usc.edu
  1542. 17-May-87 09:20:38-MDT,1187;000000000000
  1543. Return-Path: <@wiscvm.wisc.edu:V125KJG8@UBVMS.BITNET>
  1544. Received: from wiscvm.wisc.edu by SIMTEL20.ARPA with TCP; Sun, 17 May 87 09:20:25 MDT
  1545. Received: from UBVMS.BITNET by wiscvm.wisc.edu ; Sat, 16 May 87 13:44:17 CDT
  1546. Date:     Sat, 16 May 87 12:20 EDT
  1547. From:     <V125KJG8%UBVMS.BITNET@wiscvm.wisc.edu>
  1548. Subject:  Re: Copyright status of ARC, LZW,
  1549. To:       INFO-CPM@SIMTEL20.ARPA
  1550. X-Original-To:  KEN@CS.ROCHESTER.EDU,CPM, V125KJG8
  1551.  
  1552. >I thought the L-Z compression algorithm was published in a journal for
  1553. >all to see.  Furthermore, I may be wrong, but it is my understanding
  1554. >that one cannot patent algorithms (being "laws of nature"), although
  1555. >one can patent realizations of an algorithm. So if I read the journal
  1556. >article and went off and wrote a C program based on the algorithm I'd
  1557. >have no problems.
  1558. >
  1559. >Disclaimer: I may be talking rubbish.  Anybody know better?
  1560.  
  1561. Considering that I have a copy of CRUNCH v 2.3 that I received as public
  1562. domain from a local bulletin board, I don't think you will have any problems.
  1563. I have also seen an UNARC algorithm coded into a VAX FORTRAN algorithm (received
  1564. from SIMTEL20).  That is the best I can provide...
  1565.  
  1566.   --Curtis
  1567. 19-May-87 01:12:31-MDT,955;000000000000
  1568. Return-Path: <info-cpm-request@simtel20.arpa>
  1569. Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Tue, 19 May 87 01:12:19 MDT
  1570. Received: by ucbvax.Berkeley.EDU (5.57/1.25)
  1571.     id AA28507; Mon, 18 May 87 23:53:07 PDT
  1572. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  1573.     for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa)
  1574.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  1575. Date: 18 May 87 16:19:41 GMT
  1576. From: tikal!slovax!flak@beaver.cs.washington.edu  (Dan Flak)
  1577. Organization: R & D Associates., Tacoma, WA
  1578. Subject: Help wanted Xerox 820-II Disk Drive
  1579. Message-Id: <430@slovax.UUCP>
  1580. Sender: info-cpm-request@simtel20.arpa
  1581. To: info-cpm@simtel20.arpa
  1582.  
  1583. I am looking for information on hard disks for a Xerox 820-II.
  1584. What is available? Were can I get it? etc.
  1585. -- 
  1586. {psivax,ism780}!logico!slovax!flak  :  {hplsla,uw-beaver}!tikal!slovax!flak
  1587. Dan Flak-R & D Associates,3625 Perkins Lane SW,Tacoma,Wa 98466,206-581-1322
  1588. 19-May-87 02:12:08-MDT,975;000000000000
  1589. Return-Path: <info-cpm-request@simtel20.arpa>
  1590. Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Tue, 19 May 87 02:11:55 MDT
  1591. Received: by ucbvax.Berkeley.EDU (5.57/1.25)
  1592.     id AA28570; Mon, 18 May 87 23:55:12 PDT
  1593. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  1594.     for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa)
  1595.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  1596. Date: 18 May 87 16:24:18 GMT
  1597. From: tikal!slovax!flak@beaver.cs.washington.edu  (Dan Flak)
  1598. Organization: R & D Associates., Tacoma, WA
  1599. Subject: Control Data 10 MB disk packs for sale
  1600. Message-Id: <431@slovax.UUCP>
  1601. Sender: info-cpm-request@simtel20.arpa
  1602. To: info-cpm@simtel20.arpa
  1603.  
  1604. I have approximately 35 Control Data 10 MB disk packs for sale at
  1605. $30 each (discount for the whole batch) + shipping cost.
  1606. -- 
  1607. {psivax,ism780}!logico!slovax!flak  :  {hplsla,uw-beaver}!tikal!slovax!flak
  1608. Dan Flak-R & D Associates,3625 Perkins Lane SW,Tacoma,Wa 98466,206-581-1322
  1609. 19-May-87 18:21:49-MDT,1321;000000000000
  1610. Return-Path: <info-cpm-request@simtel20.arpa>
  1611. Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Tue, 19 May 87 18:21:37 MDT
  1612. Received: by ucbvax.Berkeley.EDU (5.57/1.25)
  1613.     id AA16108; Tue, 19 May 87 15:34:59 PDT
  1614. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  1615.     for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa)
  1616.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  1617. Date: 19 May 87 16:39:10 GMT
  1618. From: geowhiz!schultz@rsch.wisc.edu  (Don Schultz)
  1619. Organization: UW Madison, Geology Dept.
  1620. Subject: Uncrunching Simtel archive files
  1621. Message-Id: <552@geowhiz.UUCP>
  1622. Sender: info-cpm-request@simtel20.arpa
  1623. To: info-cpm@simtel20.arpa
  1624.  
  1625.  
  1626.   Around April of this year, I requested some files from the Simtel
  1627. archives in "squeezed" form.  The files I received were first crunched,
  1628. then squeezed, and finally uuencoded.  After uudecoding and unsqueezing,
  1629. I tried to use the "uncrunch" program from the CP/M starter kit but the
  1630. program tells me that I require a newer program revision.
  1631.   My uncrunch routine is the Z80 version for CP/M 2.2.  Does anyone know
  1632. how I may obtain the correct version of the LZW expansion program ?  Has
  1633. anyone else had this problem ? If it helps any, the first two bytes of
  1634. the crunched programs are 76H and FEH.
  1635.  
  1636.                     Any help would be appreciated.
  1637. 19-May-87 21:49:38-MDT,927;000000000000
  1638. Return-Path: <info-cpm-request@simtel20.arpa>
  1639. Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Tue, 19 May 87 21:49:30 MDT
  1640. Received: by ucbvax.Berkeley.EDU (5.57/1.25)
  1641.     id AA16728; Tue, 19 May 87 16:00:34 PDT
  1642. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  1643.     for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa)
  1644.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  1645. Date: 16 May 87 15:44:34 GMT
  1646. From: beta!dzzr@NYU.ARPA  (Douglas J Roberts)
  1647. Organization: Los Alamos Natl Lab, Los Alamos, N.M.
  1648. Subject: Query: How best to install ZCPR3?
  1649. Message-Id: <5363@beta.UUCP>
  1650. Sender: info-cpm-request@simtel20.arpa
  1651. To: info-cpm@simtel20.arpa
  1652.  
  1653.  
  1654. I would like to install ZCPR3 on my NorthStar Horizon-II. I have
  1655. found the ZCPR3 stuff on SIMTEL20, but I would greatly
  1656. appreciate if someone who has done it before could outline
  1657. an installation proceedure.
  1658.  
  1659. Thanks in advance, Doug Roberts.
  1660. 19-May-87 21:50:08-MDT,2374;000000000000
  1661. Return-Path: <info-cpm-request@simtel20.arpa>
  1662. Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Tue, 19 May 87 21:49:54 MDT
  1663. Received: by ucbvax.Berkeley.EDU (5.57/1.25)
  1664.     id AA16843; Tue, 19 May 87 16:05:10 PDT
  1665. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  1666.     for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa)
  1667.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  1668. Date: 19 May 87 15:57:11 GMT
  1669. From: phoenix!pguhatha@princeton.edu  (Puragra Guhathakurta)
  1670. Organization: Princeton Univ. Computing and Information Technology
  1671. Subject: Kaypro - ZCPR3 - TurboROM - BGii
  1672. Message-Id: <313@phoenix.PRINCETON.EDU>
  1673. Sender: info-cpm-request@simtel20.arpa
  1674. To: info-cpm@simtel20.arpa
  1675.  
  1676. Recently I installed Plu*Perfect's backgrounder on my Kaypro 4/84, 
  1677. it runs with a 1Mb Advent RAM disk with Turbo ROM.
  1678. A few nasty ZCPR problems suddenly disappeared while doing this:
  1679. - the search path has a ROOT on the ramdisk (C0:), but on C1: and
  1680.   up, I never was able to make ZCPR find the extended command
  1681.   processor (the path was $0 A0 C0, using minimal search).
  1682.   I think it was able to do so, using A0 C0, i.e. disabling the
  1683.   B: drive when logged in there. 
  1684.  
  1685.   Anyone having an explanation?
  1686.  
  1687. - I think programs like VFILER let me log into various named directories
  1688.   without password questioning, in BGii this suddenly worked.
  1689.   (I did have the wheel byte set of course)
  1690.  
  1691. I think most of my problems arose after installing the Turbo ROM
  1692. (I used a ZCPR installation on the Advent Turbo BIOS from SIMTEL20,
  1693. it uses a un-familiar assembler for me, so no easy hacking).
  1694. A problem I haven't solved yet is DUMP (obtained through ZRDOS 1.x)
  1695. which set the computer to a halt after the file has been dumped.
  1696. This was OK before the Turbo ROM.
  1697.  
  1698. Apart from some of these minor problems, I am very pleased with the 
  1699. RAM disk, the new ROm, and especially the Backgrounder. 
  1700.  
  1701. Does anyone have a similar computer system, or had similar problems
  1702. and was able to solve them.
  1703.  
  1704. Now that ZCPR3.3 is shipping (Z-NEWS 707) some of these problems
  1705. may be over?
  1706. I heard that ZCPR3.3 supports a new kind of .COM executables, which
  1707. can run anywhere in memory. Nice for error handlerrs, history shells
  1708. and the like!
  1709.  
  1710. Peter Teuben
  1711. Institute for Advanced Study
  1712. School of Natural Sciences
  1713. Princeton, NJ 08540
  1714. E-mail: TEUBEN@IASSNS.BITNET
  1715. 20-May-87 09:18:21-MDT,810;000000000000
  1716. Return-Path: <Dusel.Wbst@Xerox.COM>
  1717. Received: from Xerox.COM by SIMTEL20.ARPA with TCP; Wed, 20 May 87 09:17:50 MDT
  1718. Received: from Aurora.ms by ArpaGateway.ms ; 20 MAY 87 07:24:10 PDT
  1719. From: Dusel.Wbst@Xerox.COM
  1720. Date: 20 May 87 10:26:13 EDT
  1721. Subject: Re: Help wanted Xerox 820-II Disk Drive
  1722. In-reply-to: info-cpm-request@simtel20.arpa's message of 18 May 87
  1723.  16:19:41 GMT, <430@slovax.UUCP>
  1724. To: info-cpm-request@simtel20.arpa
  1725. cc: info-cpm@simtel20.arpa
  1726. Message-ID: <870520-072410-1679@Xerox>
  1727.  
  1728. Give a call to Emerald Microware, 503-641-0347
  1729. They have drives for both 820-I and 820-II, spare parts etc.
  1730. In addition the Xerox surplus store in Texas (Open to the general public)
  1731. has 820-II rigid drive systems etc. in stock. Call them at 214-420-2999
  1732. They stock boards software systems etc.
  1733.  
  1734. Pete
  1735. 20-May-87 10:06:09-MDT,1403;000000000000
  1736. Return-Path: <@wiscvm.wisc.edu:V125KJG8@UBVMS.BITNET>
  1737. Received: from wiscvm.wisc.edu by SIMTEL20.ARPA with TCP; Wed, 20 May 87 10:05:56 MDT
  1738. Received: from UBVMS.BITNET by wiscvm.wisc.edu ; Wed, 20 May 87 11:02:44 CDT
  1739. Date:     Wed, 20 May 87 12:00 EDT
  1740. From:     <V125KJG8%UBVMS.BITNET@wiscvm.wisc.edu>
  1741. Subject:  On Uncrunching SIMTEL20 Files
  1742. To:       INFO-CPM@SIMTEL20.ARPA
  1743. X-Original-To:  edu%"geowhiz!schultz@rsch.wisc.edu",cpm, V125KJG8
  1744.  
  1745. >  Around April of this year, I requested some files from the Simtel
  1746. >archives in "squeezed" form.  The files I received were first crunched,
  1747. >then squeezed, and finally uuencoded.  After uudecoding and unsqueezing,
  1748. >I tried to use the "uncrunch" program from the CP/M starter kit but the
  1749. >program tells me that I require a newer program revision.
  1750. >  My uncrunch routine is the Z80 version for CP/M 2.2.  Does anyone know
  1751. >how I may obtain the correct version of the LZW expansion program ?  Has
  1752. >anyone else had this problem ? If it helps any, the first two bytes of
  1753. >the crunched programs are 76H and FEH.
  1754.  
  1755. Is the UNCR.COM in use Uncrunch v 2.3 by Steve Greenburg?  If not, I can send
  1756. you a copy.  It might be possible that SIMTEL20 is not crunching correctly.
  1757. I'm running short on time, or else I'd attach a copy of CRUNCH23.LBR in Intel
  1758. hex form for you to MLOAD or LOAD...
  1759. (don't have UUENCODE running on this VAX yet!)
  1760.   --Curtis
  1761. 20-May-87 11:53:24-MDT,2398;000000000000
  1762. Return-Path: <bridger@rand-unix.ARPA>
  1763. Received: from rand-unix.arpa by SIMTEL20.ARPA with TCP; Wed, 20 May 87 11:53:10 MDT
  1764. Received: by rand-unix.arpa; Wed, 20 May 87 10:32:41 PDT
  1765. Date: Wed, 20 May 87 10:32:41 PDT
  1766. From: Bridger Mitchell <bridger@rand-unix.ARPA>
  1767. Message-Id: <8705201732.AA09258@rand-unix.arpa>
  1768. To: phoenix!pguhatha@princeton.edu (Puragra Guhathakurta)
  1769. Cc: info-cpm@simtel20.arpa, sage@ll.arpa
  1770. Re: Kaypro - ZCPR3 - TurboROM - BGii
  1771.  
  1772. In reply to your: 19 May 87 15:57:11 GMT
  1773. Date: Wed, 20 May 87 10:32:35 PDT
  1774. From: bridger@rand-unix.arpa
  1775.  
  1776. Peter Teuben--
  1777.  
  1778. Some of your command-processor-related problems may be due to using
  1779. tools (such as VFILER) that are designed to be run under ZCPR3 on a
  1780. system with an earlier command processor (the original ZCPR).  At
  1781. least some of the Z-System tools assume (without checking) that they
  1782. are running in such an environment.  When run on a standard cp/m 2.2
  1783. system, for example, some features will not function correctly.
  1784.  
  1785. The TurboROM (by Plu*Perfect Systems & Advent) for Kaypros ('83, '84, 10)
  1786. is shipped with the original ZCPR ("ZCPR1"), the public-domain
  1787. replacement for Digital Research's CCP developed by several veterans
  1788. of this info-cpm list.
  1789.  
  1790. The copyright for ZCPR3 is assigned to Echelon Inc. and copies
  1791. can be obtained from them or one of the Z-NODE BBS's.  If you
  1792. have a copy of it, or another command processor, you can replace
  1793. ZCPR1 in your TurboROM system, as outlined in the manual.
  1794.  
  1795. BackGrounder ii (a copyrighted product from Plu*Perfect Systems)
  1796. incorporates a command processor that supports ZCPR3.3 functionality.
  1797. So, when you began using BGii, the tools such as VFILER were able to
  1798. operate as expected.
  1799.  
  1800. The new ZCPR3.3 has been developed by Jay Sage, with numerous
  1801. contributions from Z-System users.  It will be available from Echelon
  1802. and Z-NODES.  One new feature is a "type-2 environment" COM file that
  1803. is loaded to and executed at an environment-specified address
  1804. (e.g. 8000 hex).  This permits extended command processors, error
  1805. handlers and other Z-system shells to leave the lower TPA unchanged
  1806. from the previous program.  The "GO" command will therefore work for
  1807. all but very large programs, even after a shell has been re-invoked.
  1808.  
  1809. BGii (v 1.13) supports this and other ZCPR3.3 features.  I expect
  1810. Jay will soon post further info about the 3.3 version.
  1811.  
  1812. --bridger
  1813. 20-May-87 21:24:10-MDT,577;000000000000
  1814. Return-Path: <mknox@ngp.utexas.edu>
  1815. Received: from ngp.utexas.edu by SIMTEL20.ARPA with TCP; Wed, 20 May 87 21:23:56 MDT
  1816. Date: Wed, 20 May 87 22:10:48 CDT
  1817. From: mknox@ngp.utexas.edu (Margaret H. Knox)
  1818. Posted-Date: Wed, 20 May 87 22:10:48 CDT
  1819. Message-Id: <8705210310.AA14141@ngp.utexas.edu>
  1820. Received: by ngp.utexas.edu (5.51/5.51)
  1821.     id AA14141; Wed, 20 May 87 22:10:48 CDT
  1822. To: info-cpm@simtel20.arpa,
  1823.         pyramid!amdahl!cerebus!fai!wjvax!jeffs@decwrl.dec.com
  1824. Subject: Re:  CP/M for Model IV
  1825.  
  1826. Go with the Montezuma version.  They did a VERY good job on this one.
  1827. 21-May-87 10:51:59-MDT,479;000000000000
  1828. Mail-From: RCONN created at 21-May-87 10:51:48
  1829. Date: Thu, 21 May 87 10:51:46 MDT
  1830. From: Rick Conn <RCONN@SIMTEL20.ARPA>
  1831. Subject: Re: Query: How best to install ZCPR3?
  1832. To: beta!dzzr@NYU.ARPA
  1833. cc: info-cpm@SIMTEL20.ARPA
  1834. In-Reply-To: <5363@beta.UUCP>
  1835. Message-ID: <12304174972.16.RCONN@SIMTEL20.ARPA>
  1836.  
  1837. There is a ZCPR3 Installation Handbook in PD:<ZSYS.DOC> (I think .DOC) on
  1838. SIMTEL20.  There is also the book "ZCPR3: The Manual", which is quite detailed.
  1839.  
  1840.     Rick
  1841. -------
  1842. 22-May-87 01:31:38-MDT,716;000000000000
  1843. Return-Path: <@wiscvm.wisc.edu:V125KJG8@UBVMS.BITNET>
  1844. Received: from wiscvm.wisc.edu by SIMTEL20.ARPA with TCP; Fri, 22 May 87 01:31:14 MDT
  1845. Received: from UBVMS.BITNET by wiscvm.wisc.edu ; Thu, 21 May 87 22:39:44 CDT
  1846. Date:     Thu, 21 May 87 23:19 EDT
  1847. From:     <V125KJG8%UBVMS.BITNET@wiscvm.wisc.edu>
  1848. Subject:  Z-Team Membership Count
  1849. To:       INFO-CPM@SIMTEL20.ARPA
  1850. X-Original-To:  bridger,cpm, V125KJG8
  1851.  
  1852. Besides you and Jay Sage, how many others in the Z-Team are on Internet/UUCP
  1853. (Z-News 705)?
  1854.  
  1855. I'd love to get into the Z-Team, but the policy at my university and of BITNET
  1856. will prevent me from that kind of commercial activity.  I can test PD stuff,
  1857. and offer suggestions, though...
  1858.   --Curtis
  1859. 23-May-87 11:43:49-MDT,1063;000000000000
  1860. Return-Path: <info-cpm-request@simtel20.arpa>
  1861. Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Sat, 23 May 87 11:43:41 MDT
  1862. Received: by ucbvax.Berkeley.EDU (5.57/1.25)
  1863.     id AA12881; Sat, 23 May 87 08:38:30 PDT
  1864. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  1865.     for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa)
  1866.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  1867. Date: 22 May 87 16:02:00 GMT
  1868. From: uxc.cso.uiuc.edu!uicsl!klieb@a.cs.uiuc.edu
  1869. Subject: Re: Help wanted Xerox 820-II Disk Drive
  1870. Message-Id: <363900003@uicsl>
  1871. References: <430@slovax.UUCP>
  1872. Sender: info-cpm-request@simtel20.arpa
  1873. To: info-cpm@simtel20.arpa
  1874.  
  1875.  
  1876. This month's issue of computer shopper has an ad from BCE in Washington,
  1877. DC that lists an 820-II WITH HARD DISK for $299!!! Includes everything:
  1878. Wordstar, 10MB hard disk, 8" DSDD floppy, keyboard, display, etc. Look for
  1879. the ads that have the full-page red borders near the back. Apparently, BCE
  1880. bought out Xerox's remaining stock. Have fun!
  1881.  
  1882. Kurt Liebezeit
  1883. ...!ihnp4!uiucuxc!uicsl!klieb
  1884. 24-May-87 11:57:09-MDT,11627;000000000000
  1885. Return-Path: <w8sdz@BRL.ARPA>
  1886. Received: from BRL-SMOKE.ARPA by SIMTEL20.ARPA with TCP; Sun, 24 May 87 11:56:37 MDT
  1887. Date:     Sun, 24 May 87 13:19:40 EDT
  1888. From:     "Keith B. Petersen" (WSMR|towson) <w8sdz@BRL.ARPA>
  1889. To:       Info-Cpm@SIMTEL20.arpa
  1890. Subject:  FOG standards defined
  1891. Message-ID:  <8705241319.aa25078@SMOKE.BRL.ARPA>
  1892.  
  1893. From F.O.G., the First Osborne Group, we receive the following set of
  1894. standards.  There are some inaccuracies in this file and my next
  1895. message will be a response to them.
  1896.  
  1897. Keith Petersen
  1898. Arpa: W8SDZ@SIMTEL20.ARPA
  1899. Uucp: {bellcore,decwrl,harvard,lll-crg,ucbvax,uw-beaver}!simtel20.arpa!w8sdz
  1900. GEnie Mail: W8SDZ
  1901. RCP/M Royal Oak: 313-759-6569 - 300, 1200, 2400 (V.22bis) or 9600 (USR HST)
  1902.  
  1903. --cut-here--STANDARD.FOG--cut-here--
  1904. Report from FOG
  1905. Solution for a Major Problem
  1906. by Gale Rhoades
  1907.  
  1908. In recent weeks, the FOG office staff has been trying to sort through a
  1909. variety of submissions.  Some have been uploaded to FOG #6 (or #1) and
  1910. some have arrived on disk.  The problems we've encountered surpass my
  1911. ability to describe.
  1912.  
  1913. We have files which have been sQueezed, crunched, ARChived or LiBRaried
  1914. and we have files which apparently have gone through a combination of
  1915. compression programs.
  1916.  
  1917. We have filenames with characters which are reserved under MS-DOS and
  1918. filenames with characters which are reserved under CP/M.  (Reserved
  1919. characters are those which the operating system will not permit you to
  1920. use when naming a file.)  We have CP/M files on MS-DOS formatted disks
  1921. and MS-DOS files on CP/M formatted disks.  And we have the most horren-
  1922. dous assortment of combinations.  How some of it was accomplished is
  1923. totally beyond me!
  1924.  
  1925. Enough is enough.  Jack and I are spending hours trying to get at some
  1926. of these files and we just do not have the time to continue doing this.
  1927. Well, at least not if you want to continue to see the FOG publications,
  1928. new library releases and all the other services which are provided by
  1929. the FOG staff.
  1930.  
  1931. We have therefore developed some guidelines for submitting material to
  1932. the FOG libraries and publications.  Exceptions will be considered but
  1933. please check with us in advance.  We are willing to listen to suggestions
  1934. for modifications to these guidelines but only if they are presented in
  1935. an organized and well-considered manner.  As a secondary goal, I would
  1936. hope that FOG can facilitate the standardization of filenames and com-
  1937. pression programs.
  1938.  
  1939. Additionally, these guidelines are subject to revision as the authors of
  1940. industry-standard utilities develop the tools which will eliminate some
  1941. of the specific problems outlined below.
  1942.  
  1943.  
  1944.  
  1945.                         The Guidelines
  1946.  
  1947. It would be very foolish to perpetuate the argument that CP/M and MS-DOS
  1948. are separate and distinct.  Far too many users find themselves switching
  1949. between MS-DOS and CP/M machines.  Some have one machine at work and the
  1950. other at home.  Others have both sitting side-by-side.
  1951.  
  1952. Legal Filenames:  Filenames may contain only the characters listed below:
  1953.  
  1954.      !  (exclamation mark)
  1955.      #  (pound, number, or hash symbol)
  1956.      %  (percent)
  1957.      &  (ampersand)
  1958.      '  (apostrophe)
  1959.      (  (open or left parenthesis)
  1960.      )  (close or right parenthesis)
  1961.      -  (hyphen, dash, or minus)
  1962.      @  (at symbol)
  1963.      0  through  9
  1964.      A  through  Z  (upper case only!)
  1965.      ^  (caret or circumflex)
  1966.      `  (back quote)
  1967.      {  (open or left brace or curly bracket)
  1968.      }  (close or right brace or curly bracket)
  1969.      ~  (tilde)
  1970.  
  1971. It is true that both MS-DOS and CP/M permit filenames to include char-
  1972. acters other than those listed above.  This list includes only those
  1973. haracters which we have found to be generally acceptable to both opera-
  1974. ting systems.  Note that a few of these characters are partially reserved
  1975. through common usage.
  1976.  
  1977. For example, "Q" as the second letter of a file extension indicates that
  1978. the file has been sQueezed.  NEVER use it otherwise. "Z" as the second
  1979. letter of a file extension indicates that the file has been crunched.
  1980. Again, NEVER use it unless the file has indeed been crunched.
  1981.  
  1982. The characters are listed in ascending ASCII order. The first nine often
  1983. are used to place files at the head of a sorted directory because they
  1984. have ASCII values less than that of a "0" or an "A".
  1985.  
  1986. Utility Programs:  These are the programs which compress files (to con-
  1987. serve disk space) or which collect several files under a single filename.
  1988.  
  1989. 1. SQueezed files (those with a "Q" as the second letter of a file ex-
  1990.    tension) must be compatible with Dave Rand's NewSWeeP (version 2.07
  1991.    in CP/M or 1.018 in MS-DOS, both of which use Richard Greenlaw's SQ
  1992.    algorithm).  I have yet to see a correctly named file which will not
  1993.    unsQueeze with NSWP.  SQueezed files generally save approximately
  1994.    30-35%.
  1995.  
  1996. Text files which are of use to both CP/M and MS-DOS users should only be
  1997. sQueezed.
  1998.  
  1999. 2. LiBRaried files (those with the extension .LBR) are a collection of
  2000.    several related files.  Often libraries include files which have been
  2001.    sQueezed.  This combination is both acceptable and desirable as a
  2002.    savings of 10-50% is realized.
  2003.  
  2004. Additionally, there are fully debugged utilities which will allow one-
  2005. step viewing and extraction from .LBR files and these files are equally
  2006. usable on either MS-DOS or CP/M systems.  Generally these files are
  2007. created on CP/M systems.
  2008.  
  2009. 3. ARChived files (those with the extension of either .ARC or .ARK) are
  2010.    files which contain related files.  ARC is particularly nice because
  2011.    it is possible, in a single step, to both condense and collect.  Cur-
  2012.    rently ARC files are created reliably only on MS-DOS systems but the
  2013.    contents can be extracted with ease on either a CP/M or MS-DOS system.
  2014.  
  2015. The established standard is to use .ARC as the extension when the file
  2016. contains programs and related files specific to MS-DOS systems.  Most
  2017. MS-DOS shareware and public domain software is distributed (on the Remote
  2018. Systems) in .ARC files.  Files w ith the extension .ARK are specific to
  2019. CP/M systems.  ARC512 is the standard which FOG is supporting.
  2020.  
  2021.  
  2022. Things to Avoid:  These are the things which have caused major problems,
  2023. especially lately.
  2024.  
  2025. 1. ALL crunch programs. These programs are changing dramatically nearly
  2026.    every week.  In most cases, files which were crunched by a later ver-
  2027.    sion cannot be extracted by an earlier version.
  2028.  
  2029. Files which contain a "Z" as the second character in the extension will
  2030. be discarded until (unless) the various authors can agree on some stan-
  2031. dards and build RELIABLE and easy-to-use programs which allow a CP/M
  2032. user to extract a file crunched on an MS-DOS system, an MS-DOS user to
  2033. extract a file crunched on a CP/M system AND both CP/M and MS-DOS users
  2034. to create compatible crunched files.
  2035.  
  2036. 2. Please DO NOT mix compression algorithms except to sQueeze a file and
  2037.    then include it in a LiBRary file.
  2038.  
  2039. 3. ARC files created by programs not compatible with ARC512 will be dis-
  2040.    carded.
  2041.  
  2042. 4. Files which were named using illegal characters (those not listed un-
  2043.    der Legal Filenames above) will be discarded.
  2044.  
  2045. 5. Never sQueeze or crunch a .LBR or .ARC file!
  2046.  
  2047. 6. Never sQueeze or crunch a file which will later be included in an ARC
  2048.    file.
  2049.  
  2050. 7. NEVER rename a file before submitting it to this office!  You may re-
  2051.    name any file or program for your own use but please do not distribute
  2052.    it to others except under the filename assigned by the author. This is
  2053.    particularly important with public domain software.
  2054.  
  2055. 8. Please do not sQueeze, LiBRary, or ARChive a file and then rename the
  2056.    file.  If you want to rename a file you created, please do so before
  2057.    using your favorite utility.  Renamed files cause serious problems
  2058.    when we are extracting several files on the same disk.
  2059.  
  2060.  
  2061.                            Submissions
  2062.  
  2063. It is amazing how many submissions (both for the libraries and the
  2064. publications) arrive with nothing to identify the sender, the disk
  2065. format, the intent of the sender, etc.
  2066.  
  2067. Each disk submitted should have a label to tell us:
  2068.  
  2069. 1. The name and address (and membership number) of the sender.
  2070.  
  2071. 2. The format of the disk.
  2072.  
  2073. 3. If text files are included, what word processor was used.  If it is
  2074.    possible, we would prefer that the files be submitted in WordStar or
  2075.    standard ASCII format.
  2076.  
  2077. 4. If it is not a submission, please include a cover letter so we know
  2078.    WHY it was sent.
  2079.  
  2080. 5. If it is a submission, what would you like back?  Volunteers do most
  2081.    of the copying to overwrite the disks before they are returned to the
  2082.    senders.  Normally the volunteers are not able to look up your address
  2083.    and we do not have records of the library disks you already have or
  2084.    the disk formats you can read.
  2085.  
  2086. 6. If possible, include a file with the CRC values so that we can check
  2087.    for damage to the files if we encounter problems.
  2088.  
  2089. 7. Keep the filename unique. Please do not use FOGHORN, FOGLIGHT, FOG,
  2090.    LETTER, or similar filenames.
  2091.  
  2092.  
  2093. Files uploaded to FOG #6 or #1 should:
  2094.  
  2095. 1. Include sender's name, address, and membership number.  If you are
  2096.    uploading a textfile, place this information at the beginning of the
  2097.    file.  If you are uploading a library submission, include this infor-
  2098.    mation in a "README" file.
  2099.  
  2100. 2. If more than a single file is being uploaded, please collect all re-
  2101.    lated files in either a LiBRary or ARChive file.  Be sure the "README"
  2102.    file is included.  SQueeze text files before adding them to a LiBRary
  2103.    file; do NOT sQueeze them before using ARChive.
  2104.  
  2105. 3. If possible, include a file with the CRC values of each member.
  2106.  
  2107. 4. Keep the filename unique.  Please do not use FOGHORN, FOGLIGHT, FOG,
  2108.    LETTER, or similar filenames.
  2109.  
  2110.  
  2111.               Submissions for the FOG Publications
  2112.  
  2113. Lately, we have been receiving a large number of lengthy letters and
  2114. articles by mail.  This is great except for one small problem - these
  2115. letters are not in computer-readable form.
  2116.  
  2117. Therefore, we wonder if authors realized that, in order to publish the
  2118. submission, we have to first retype these otherwise excellent submis-
  2119. sions?  We have reluctantly begun returning such letters with the request
  2120. that they be returned on disk.
  2121.  
  2122. Remember folks, we will return your disk overwritten with a disk from the
  2123. library -- just tell us which disk you'd like to have.
  2124.  
  2125. Effective immediately, we will be unable to rekey a submission which is
  2126. longer than two paragraphs.
  2127.  
  2128. If you have artwork which accompanies the submission, please continue
  2129. sending that as hardcopy.  Just insert it into the disk mailer.
  2130.  
  2131. Please include your name and address at the start of each article.  It
  2132. is much faster to delete a couple extra lines than to search for the
  2133. information.
  2134.  
  2135. Please omit (or delete) ALL print control codes, regardless of what you
  2136. think we can read or use.  We are experimenting with a variety of "desk-
  2137. top publishing" software packages and print control codes can make a file
  2138. nearly useless.  If you want to assist us, include a hardcopy of the
  2139. formatted file.  Please avoid indents, tabs, and other offsets.  Keep all
  2140. the margin flush left and use blank lines for separation.  Start and end
  2141. non-printing comments with a tilde ( ~ ).
  2142.  
  2143. Submissions are always needed for the FOG publications and, of course,
  2144. greatly appreciated.  To all the authors and others responsible for such
  2145. submissions, our sincerest thanks for your efforts and support.
  2146.  
  2147.                     - Gale Rhoades
  2148.  
  2149.  
  2150.  
  2151. --cut-here--
  2152. 24-May-87 11:57:36-MDT,11646;000000000000
  2153. Return-Path: <w8sdz@BRL.ARPA>
  2154. Received: from BRL-SMOKE.ARPA by SIMTEL20.ARPA with TCP; Sun, 24 May 87 11:57:10 MDT
  2155. Date:     Sun, 24 May 87 13:35:13 EDT
  2156. From:     "Keith B. Petersen" (WSMR|towson) <w8sdz@BRL.ARPA>
  2157. To:       Info-Cpm@SIMTEL20.arpa
  2158. Subject:  FOG standards - CRUNCH author replies
  2159. Message-ID:  <8705241335.aa25218@SMOKE.BRL.ARPA>
  2160.  
  2161. F.O.G., the First Osborne Group, recently released a file called
  2162. STANDARDS.FOG which detailed certain requirements for submitting
  2163. files to FOG.  In the file below, the author of CRUNCH responds
  2164. to inaccuracies in the FOG document.  I fully agree with the
  2165. rebuttle enclosed below.  Many of the files available from my
  2166. RCP/M and SIMTEL20 are crunched.  There have been no problems
  2167. and the savings in storage and download time are quite impressive.
  2168.  
  2169. Keith Petersen
  2170. Arpa: W8SDZ@SIMTEL20.ARPA
  2171. Uucp: {bellcore,decwrl,harvard,lll-crg,ucbvax,uw-beaver}!simtel20.arpa!w8sdz
  2172. GEnie: W8SDZ
  2173. RCP/M Royal Oak: 313-759-6569 - 300, 1200, 2400 (V.22bis), 9600 (USR HST)
  2174.  
  2175. --cut-here--RESPONSE.FOG--cut-here--
  2176.  
  2177. RESPONSE.FOG
  2178. Steven Greenberg, 10 May 1987
  2179.  
  2180. This  is in response to a file being circulated, STANDARD.FOG,  issued
  2181. by Gale Rhoades and the FOG office staff.  While I understand the need
  2182. for  the document and the intent of it, I feel that  certain  sections
  2183. disseminate  information  which is misdirected,  misleading,  or  just
  2184. plain  technically incorrect.  If you are not familiar with the  docu-
  2185. ment,  it  is a series of guidelines which must be used if one  is  to
  2186. consider making a submissions to FOG  [Ref. #2].
  2187.  
  2188. Since  the  inception of CRUNCH, I have witnessed a  wide  variety  of
  2189. reactions, from very positive to quite negative.  Reasons for "opposi-
  2190. tion" to CRUNCH have ranged from plain closed-mindedness to some  very
  2191. real  questions  the  of "standards"  and  intersystem  compatibility.
  2192. Standards  are very important, and they don't change overnight.   Each
  2193. system  or person has a right to decide what is or  isn't  "standard",
  2194. and, based on that, form appropriate guidelines.  CRUNCH has gone from
  2195. a relatively unknown compression format to quite a popular one.  While
  2196. it is now arguably a standard of some kind, the final decision on that
  2197. question is of course left to the user.
  2198.  
  2199. I don't really care if FOG condones or condemns CRUNCH.  It was  writ-
  2200. ten  for  my own interest and for the many others who find  it  useful
  2201. (though  I  did  make  $15 on it-  an  unsolicited  contribution  from
  2202. England!).  I am not in the habit of getting involved in these contro-
  2203. versies,  such as the recent PRACSA discussions concerning the  "sanc-
  2204. tioning"  of crunched files (see Ref #1 below).  I am responding  now,
  2205. however,  specifically to this FOG document, because it makes  several
  2206. points which I find offensively inaccurate.
  2207.  
  2208. Quote from STANDARD.FOG:
  2209.  
  2210. |   "Things  to Avoid:  These are the things which have  caused  major
  2211. |   problems, especially lately."
  2212. |
  2213. |   "1. ALL crunch programs.  These programs are changing dramatically
  2214. |   nearly every week.  In most cases, files which were crunched by  a
  2215. |   later version cannot be extracted by an earlier version."
  2216.  
  2217. There  have  only been two crunched file formats in  all  of  history,
  2218. namely  "1" and "2".  If there still are any type "1"  files  floating
  2219. around, they would be uncrunched by any v2 program with absolutely  no
  2220. problem.  The standard current version of CRUNCH, (v2.3), was released
  2221. with  full source code in November of '86.  The statements above  not-
  2222. withstanding,  there have been no additional releases (or known  bugs)
  2223. in the twenty-five or so weeks since, nor has v2 format changed  since
  2224. it  was first introduced some 36 weeks ago.  There have been  quite  a
  2225. number of support releases from other authors (see partial listing be-
  2226. low),  and all work with the same v2 format originally  introduced  in
  2227. early September, 1986.
  2228.  
  2229.  
  2230.  
  2231.                                   1
  2232.  
  2233.  
  2234.  
  2235. STANDARD.FOG continues:
  2236.  
  2237. |   "Files  which contain a "Z" as the second character in the  exten-
  2238. |   sion  will  be discarded until (unless) the  various  authors  can
  2239. |   agree  on some standards and build RELIABLE and easy-to-use  prog-
  2240. |   rams which allow a CP/M user to extract a file crunched on an  MS-
  2241. |   DOS  system, an MS-DOS user to extract a file crunched on  a  CP/M
  2242. |   system  AND  both  CP/M  and MS-DOS  users  to  create  compatible
  2243. |   crunched files."
  2244.  
  2245. Discarded indeed! (watch your .AZM files!)
  2246.  
  2247. Ironically, I feel it appropriate to congratulate the various  authors
  2248. of  CRUNCH  / UNCR type programs, as well as various  TYPE  and  other
  2249. utilities  which support the crunched file format.  Each of these pro-
  2250. grammers  have conscientiously followed the existing format.  We  have
  2251. thus evolved a system where all these programs ARE in fact compatible-
  2252. I  have no explanation for the statements made in the above  paragraph
  2253. concerning "agree[ment]" and "RELIABILITY" (emphasis theirs.. why?).
  2254.  
  2255. Using UNCR or equiv., CP/M users CAN extract files made on any  system
  2256. which  could create them.  MS-DOS users CAN reliably extract  crunched
  2257. files  created  on CP/M systems (see Ref #1 below).   Of  course  CP/M
  2258. users CAN create them, in a multitude of ways.  At this moment, MS/DOS
  2259. users  cannot CREATE a crunched file, but then again neither can  CP/M
  2260. users  create an ARC file right now.  These inabilities are  temporary
  2261. and  of secondary importance; the paramount issue is that everyone  be
  2262. able to reliably access the information contained in compressed files.
  2263.  
  2264. Consider  the  following list, which contains as many  programs  as  I
  2265. could  think  of offhand which directly deal with  the  crunched  file
  2266. format.  ALL ARE COMPATIBLE.
  2267.  
  2268.  
  2269. Program    OS     Function              Author(s)            Notes
  2270. =======   ====    ========              ==========           =====
  2271. CRUNCH23  CP/M    Crunch, Uncr, Docs    Steven Greenberg     w/ Z-80 source
  2272. FCRNCH11  CP/M    CR, UCR, many xtras   Charles Falconer     w/ 8080 source
  2273. TYPELZ2x  CP/M    TYPE facility         Steve G./Others      Frm LBR's, etc.
  2274. LTxx      CP/M    TYPE & extras         Charles Falconer     Can extract to dsk
  2275. TYPEQZxx  CP/M    TYPE w/ wildcards     John Hastwell-Batton Recognizes ASCII
  2276. TXxx      CP/M    another TYPER         Harris Landsberg     Strange language
  2277. UNCR231   ['C']   UNCR only, portable   Frank Prindle        Compilations below
  2278. UNCR232   MS/DOS  Compiled ver of abv   Prindle/ Hansen      See  Ref. #1
  2279. UNCR-DOS  MS/DOS  Compiled ver of abv   Prindle/ Greenberg   Similar to above
  2280. JETFIND   CP/M 2  Advanced string srch  Bridger Mitchell     $Commercial Prgm
  2281. TRSCRNCH  TRS     For New TRSDOS 80     Jon Saxton / Others  From Australia
  2282. UNCRNCHR  MAC     New, runs on MACS     Prindle/Beard        New for MAC
  2283. CR23D     CP/M    Datestamper support   Bridger Mitchell     In Beta Test
  2284.  
  2285. Additional related programs are now being worked on in Canada,
  2286. England, and elsewhere.
  2287.  
  2288. ===============================================================================
  2289.  
  2290.  
  2291.                                   2
  2292.  
  2293.  
  2294.  
  2295. Another excerpt from STANDARD.FOG:
  2296.  
  2297. |   "I have yet to see a correctly named file which will not unsQueeze
  2298. |   with NSWP."
  2299.  
  2300. Well  I,  for one,  have a number of them.  On 23 Feb.  '85,  Paul  J.
  2301. Homchick  wrote  a  proposed standard explaining  how  and  why  files
  2302. squeezed  by  some MS-DOS programs were incompatible, along  with  his
  2303. proposed  solution. Here is an excerpt from P. Homchick's  SQDATE.DOC,
  2304. referring to MS-DOS squeezers with names SQ2 and ZSQ:
  2305.  
  2306.     "Although  SQ2 added time and date stamping, it did so at the  ex-
  2307.     pense  of downwards compatibility.  A file squeezed with the  time
  2308.     and  date mode of SQ2 could ONLY be unsqueezed with the  companion
  2309.     unsqueezer USQ2 (or ZUSQ).  Thus the advantage of  standardization
  2310.     was lost.  No file squeezed with SQ2 could be unsqueezed with  the
  2311.     older standard programs or moved to CP/M or UNIX systems.   Clear-
  2312.     ly,  SQ2 created a number of unfortunate consequences  along  with
  2313.     its time and date stamping."
  2314.  
  2315. ----------------------------------------------------------------------
  2316.  
  2317. An  aside,  not related to file compression:  The  list  of  "approved
  2318. filename characters" includes four characters specifically NOT allowed
  2319. by  DRI for CP/M 3.0, namely "(", ")", "-" and "!".   The  exclamation
  2320. mark,  in particular, is an odd inclusion insofar as it  is  virtually
  2321. impossible to create or work with a filename containing that character
  2322. in CP/M 3.
  2323.  
  2324. ======================================================================
  2325.  
  2326.                           APPENDIX: "Ref #1"
  2327.  
  2328. Here  is "Ref #1" mentioned several times above.  These  are  messages
  2329. left  on the PRACSA board, sort of a culmination of a  previously  on-
  2330. going debate.  I include them here for general reference and especial-
  2331. ly for the author(s) of STANDARD.FOG.
  2332.  
  2333. -----
  2334. Area: MS-DOS
  2335. Msg # 179 04/10/87 11:08 PDT
  2336. Subj: UNCRunching via MS-DOS
  2337. From: Irv Hoff
  2338. To:   All
  2339.  
  2340. The following list is the result of an extensive test that John  Allen
  2341. did  with his MS-DOS computer using the uncrunch program  UNCR232.EXE.
  2342. All  the  xxxx.?Z? files were downloaded from a CP/M-80  RCPM  system.
  2343. John  says they all uncrunched fine, without loss of any  information.
  2344. MS-DOS owners can user the UNCR232.EXE program without hesitation  for
  2345. files crunched on CP/M-80 equipment using CRUNCH.
  2346.  
  2347.  
  2348.                                   3
  2349.  
  2350.  
  2351.  
  2352.  BEFORE:
  2353.  ------
  2354.  -BYE5KMD NZW    7-13-86  NZW    415BBS   TZT    BBS-USA  TZT
  2355.  BGIIFACT TZT    FIFTH    TZT    TRAGEDY  TZT    ULTRA    TZT
  2356.  USR9600  TZT    AJCBR    LZT    AJVAC    LZT    NOVBEST  LZT
  2357.  OCTBEST  LZT    PDFT0487 LZT    RCPM0387 LZT    ZNODES40 LZT
  2358.  ZNODES41 LZT    CREDIT   DZC    OZBYE510 DZC    SNOOPY87 CZL
  2359.  VICTORY  FZC    WRITE    IZ     EXCHANGE PZP    UP2DATE  PZP
  2360.  
  2361.  AFTER:
  2362.  -----
  2363.  -BYE5KMD NEW    7-13-86  NEW    415BBS   TXT    BBS-USA  TXT
  2364.  BGIIFACT TXT    FIFTH    TXT    TRAGEDY  TXT    ULTRA    INF
  2365.  USR9600  TXT    AJCBR    LST    AJVAC    LST    NOVBEST  LST
  2366.  OCTBEST  LST    PDFT0487 LST    RCPM0387 LST    ZNODES40 LST
  2367.  ZNODES41 LST    CREDIT   DOC    OZBYE510 DOC    SNOOPY87 CAL
  2368.  VICTORY  FCC    WRITE    IN     EXCHANGE PCP    UP2DATE  PCP
  2369.  
  2370. These files came from B0: of the PRACSA RCPM and were uncrunched using
  2371. UNCR232.EXE on a MS-DOS computer by John Allen of the PRACSA standards
  2372. committee.   All  parts  of the files were normal and  in  the  proper
  2373. place.   These  files ranged from rather short to pretty  long.   They
  2374. were  more  than adequate to establish the fact  that  UNCR232.EXE  is
  2375. doing its job correctly.
  2376.  
  2377. UNCR232.EXE should be in the library of any MS-DOS user that frequents
  2378. RCPM systems that might have crunched files with xxxx.?Z? extents.  It
  2379. is available on G0: of the PRACSA RCPM.
  2380.  
  2381. -----
  2382. Area: PRACSA
  2383. Msg # 219 04/13/87 22:39 PDT
  2384. Subj: crunch
  2385. From: Al Mehr
  2386. To:   All
  2387.  
  2388. I capitulate.  The "uncruncher" for DOS seems 100%. As I don't support
  2389. MAC  or APPLE stuff on my board, do not know what they will do, but  I
  2390. now  agree, CRUNCH is certainly an acceptable alternative. I  withdraw
  2391. all my objections for using crunch files on the PRACSA BBS.
  2392.  
  2393.    Al Mehr     SERVU
  2394.  
  2395. ----------------------------------------------------------------------
  2396. Ref #2:   The actual document,  STANDARD.FOG,  a file uploaded by Gale
  2397. Rhoades, is available on the PRACSA RCP/M as "STANDARD.FZG".
  2398. ----------------------------------------------------------------------
  2399.  
  2400.  
  2401.  
  2402.  
  2403.                                   4
  2404. --cut-here--
  2405. 25-May-87 13:44:26-MDT,1655;000000000000
  2406. Return-Path: <info-cpm-request@simtel20.arpa>
  2407. Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Mon, 25 May 87 13:44:12 MDT
  2408. Received: by ucbvax.Berkeley.EDU (5.57/1.25)
  2409.     id AA11072; Mon, 25 May 87 12:38:16 PDT
  2410. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  2411.     for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa)
  2412.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  2413. Date: 25 May 87 16:23:41 GMT
  2414. From: amdahl!dlb!dana!rap@ames.arpa  (Rob Peck)
  2415. Organization: Dana Computer, Inc., Sunnyvale, CA
  2416. Subject: Re: Help wanted Xerox 820-II Disk Drive
  2417. Message-Id: <171@dana.UUCP>
  2418. References: <430@slovax.UUCP>, <363900003@uicsl>
  2419. Sender: info-cpm-request@simtel20.arpa
  2420. To: info-cpm@simtel20.arpa
  2421.  
  2422. In article <363900003@uicsl>, klieb@uicsl.UUCP writes:
  2423. > This month's issue of computer shopper has an ad from BCE in Washington,
  2424. > DC that lists an 820-II WITH HARD DISK for $299!!! Includes everything:
  2425. > Wordstar, 10MB hard disk, 8" DSDD floppy, keyboard, display, etc. Look for
  2426. > the ads that have the full-page red borders near the back. Apparently, BCE
  2427. > bought out Xerox's remaining stock. Have fun!
  2428. > Kurt Liebezeit
  2429. > ...!ihnp4!uiucuxc!uicsl!klieb
  2430.  
  2431. What the ad says is $299 for the 820-II (with software).
  2432.  
  2433. It also goes on to say that the enclosure with the 8-inch disk and
  2434. 10 Meg hard disk is AVAILABLE (almost, but not quite specifies $CALL).
  2435.  
  2436. BUT $CALL is what ya gotta do!  (I haven't done so yet, but if it was
  2437. $299 for the whole ball o wax, I'm sure that by the time I called
  2438. they'da been outa stock.)   Good Luck - if I missed a bargain, 
  2439. C'est La Vie.
  2440.  
  2441.  
  2442. Rob Peck    hplabs!dana!rap
  2443. 26-May-87 08:22:39-MDT,1721;000000000000
  2444. Return-Path: <@wiscvm.wisc.edu:U448020@HNYKUN11.BITNET>
  2445. Received: from wiscvm.wisc.edu by SIMTEL20.ARPA with TCP; Tue, 26 May 87 08:21:57 MDT
  2446. Received: from HNYKUN11.BITNET by wiscvm.wisc.edu ; Tue, 26 May 87 09:19:32 CDT
  2447. Date: Tue, 26 May 87 16:17:21 MET
  2448. To: INFO-CPM@SIMTEL20.ARPA
  2449. From: U448020%HNYKUN11.BITNET@wiscvm.wisc.edu
  2450. Subject: GSX-80 device drivers
  2451.  
  2452.  
  2453. Does anyone know of the existence of GSX-80 device drivers??????
  2454.  
  2455. I own a -self build- CP/M 3.0 computer, built after the CT-80 design of the
  2456. German magazine C'T (COMPUTER TECHNIK). The computer is used in combination
  2457. with a graphic terminal emulating Tektronics 4010 with a resolution of
  2458. 768*560 pixels. The terminal is built after the GRIP design from the same
  2459. magazine.
  2460. As I have experienced it is quite a hard job to develop a complete GSX
  2461. device-driver. Until now I haven't got any further than drawing simple
  2462. solid lines with my self-written driver.
  2463. So my questions are:
  2464.  
  2465.    - Are sources available of any 'SKELETAL GIOS' (as they are named by
  2466.      Digital Research) for GSX-80 screen drivers, preferably for
  2467.      vector-devices like the Tektronics 4010. I have found out that on
  2468.      SIMTEL20 something alike is available for GSX-86.
  2469.  
  2470. or even better:
  2471.    - are there any 'ready to use' device-drivers available for
  2472.      Tektronics-type devices (possibly with source, for adapting some
  2473.      of the differences with the real Tektronics)
  2474.  
  2475. Until now the only information i have found are the files concerning
  2476. GSX-86 on SIMTEL20 and disassembly of drivers from Amstrad/Schneider
  2477. computers.
  2478.  
  2479.       Who can give me some help ??????
  2480.  
  2481.                       Waling Tiersma
  2482.                       U448020 @ HNYKUN11 on BITNET
  2483. 26-May-87 10:39:31-MDT,878;000000000000
  2484. Return-Path: <@wiscvm.wisc.edu:U448020@HNYKUN11.BITNET>
  2485. Received: from wiscvm.wisc.edu by SIMTEL20.ARPA with TCP; Tue, 26 May 87 10:39:23 MDT
  2486. Received: from HNYKUN11.BITNET by wiscvm.wisc.edu ; Tue, 26 May 87 10:34:49 CDT
  2487. Date: Tue, 26 May 87 16:59:13 MET
  2488. To: INFO-CPM@SIMTEL20.ARPA
  2489. From: U448020%HNYKUN11.BITNET@wiscvm.wisc.edu
  2490. Subject: GSX-80 metafile driver
  2491.  
  2492. Date: 26 May 1987, 16:54:11 MET
  2493. From: Waling Tiersma            080-561368 / 080-516 U448020  at HNYKUN11
  2494. To:   INFO-CPM at SIMTEL20
  2495.  
  2496. In addition of questions I have asked earlier this day about availability
  2497. of GSX-80 device-drivers.
  2498.  
  2499.    - Does any GSX-metafile driver exist for GSX-80 ?????
  2500.     (this could enable us to exchange graphic data with Atari-ST users
  2501.      and ms-dos GEM user and maybe others)
  2502.  
  2503. Waling Tiersma
  2504.                   U448020 at HNYKUN11 on BITNET
  2505.  
  2506. -0-0-0-0-0-0-0-0-0-0-
  2507. 26-May-87 18:11:34-MDT,1156;000000000000
  2508. Return-Path: <info-cpm-request@simtel20.arpa>
  2509. Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Tue, 26 May 87 18:11:17 MDT
  2510. Received: by ucbvax.Berkeley.EDU (5.57/1.25)
  2511.     id AA04117; Tue, 26 May 87 16:41:56 PDT
  2512. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  2513.     for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa)
  2514.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  2515. Date: 26 May 87 20:15:13 GMT
  2516. From: phoenix!pguhatha@princeton.edu  (Puragra Guhathakurta)
  2517. Organization: Princeton Univ. Computing and Information Technology
  2518. Subject: NULU - bug
  2519. Message-Id: <340@phoenix.PRINCETON.EDU>
  2520. Sender: info-cpm-request@simtel20.arpa
  2521. To: info-cpm@simtel20.arpa
  2522.  
  2523.  
  2524. I found out (the hard way) that the unsqueeze option in NULU
  2525. (V1.52 or 1.51) does not work for large files. On my system
  2526. allocation blocks are 2k, and for files larger than 32k
  2527. (more than 1 extent) it seems that the Q options doesn't
  2528. do its job properly.
  2529. Did you fellow NULU users know this?
  2530. Is there a new version out, or is there an alternative?
  2531.  
  2532. Peter Teuben
  2533. Institute for Advanced Study,
  2534. Princeton, NJ 08540
  2535. e-mail also: TEUBEN@IASSNS.BITNET
  2536. 27-May-87 09:56:42-MDT,799;000000000000
  2537. Return-Path: <@wiscvm.wisc.edu:UZR50D@DBNRHRZ1.BITNET>
  2538. Received: from wiscvm.wisc.edu by SIMTEL20.ARPA with TCP; Wed, 27 May 87 09:56:22 MDT
  2539. Received: from DBNRHRZ1.BITNET by wiscvm.wisc.edu ; Wed, 27 May 87 10:53:30 CDT
  2540. Date: Wed, 27 May 87 17:53:01 MEZ
  2541. To: INFO-CPM@SIMTEL20.ARPA
  2542. From: UZR50D%DBNRHRZ1.BITNET@wiscvm.wisc.edu
  2543. Subject: Faster uudecode ?
  2544.  
  2545. Hi,
  2546.  
  2547. All those peoples who get files from the SIMTEL20 - Archive know,
  2548. that one must very often use the uudecode utility, to get the right
  2549. format of the files. But this program is very slow (because it is
  2550. written in Pascal). Is there anybody who has a faster version of
  2551. UUDECODE and / or UUENCODE for a CP/M - machine ???
  2552. The most efficient language might be Z80 - Assembler for this purpose.
  2553.  
  2554. Thanks in advance  Ralf Schukey
  2555. 27-May-87 13:45:18-MDT,1566;000000000000
  2556. Return-Path: <info-cpm-request@simtel20.arpa>
  2557. Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Wed, 27 May 87 13:44:50 MDT
  2558. Received: by ucbvax.Berkeley.EDU (5.57/1.25)
  2559.     id AA23672; Wed, 27 May 87 12:39:11 PDT
  2560. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  2561.     for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa)
  2562.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  2563. Date: 27 May 87 16:53:51 GMT
  2564. From: beta!dzzr@nyu.arpa  (Douglas J Roberts)
  2565. Organization: Los Alamos Natl Lab, Los Alamos, N.M.
  2566. Subject: Fix to a bug in Lifeboat CP/M 2.2 printer driver
  2567. Message-Id: <5644@beta.UUCP>
  2568. Sender: info-cpm-request@simtel20.arpa
  2569. To: info-cpm@simtel20.arpa
  2570.  
  2571.  
  2572. Since I've been pestering this group recently for help, I thought
  2573. that I'd share the solution now that I've found it.
  2574.  
  2575. The parallel port driver was sending garbage to my printer, so
  2576. after I located the problem I modified the Horizon user area and patched
  2577. it in. For those of you interested, here is the offending code and the
  2578. fix.
  2579.  
  2580.  
  2581. COUT2:
  2582.     ;Parallel port output.
  2583.     IN    6        ;Motherboard status
  2584.     ANI    1
  2585.     JZ    COUT2    
  2586.     MVI    A,20H        ;Reset PO flag
  2587.     OUT    6        ;Output char
  2588.     MOV    A,C          ;Load accumulator
  2589. TIN1:
  2590.     ORI    80H        ;Set strove false <-- REMOVE THIS LINE!!!
  2591.     OUT    0        ;and send character
  2592.     XRI    80H        ;Toggle strobe
  2593.     OUT    0        ;Output
  2594.     XRI    80H        ;and toggle again
  2595.     OUT    0
  2596.     ANI    7FH        ;Mask to ASCII
  2597.     RET
  2598.  
  2599. The indicated line was setting the high bit on each character,
  2600. effectively putting my Epson MX-80 into graphics mode.
  2601.  
  2602. Thanks again for all the help!
  2603.  
  2604. --Doug
  2605. 27-May-87 14:29:55-MDT,758;000000000000
  2606. Return-Path: <@wiscvm.wisc.edu:YSEGUIN@UNCAEDU.BITNET>
  2607. Received: from wiscvm.wisc.edu by SIMTEL20.ARPA with TCP; Wed, 27 May 87 14:29:13 MDT
  2608. Received: from UNCAEDU.BITNET by wiscvm.wisc.edu ; Wed, 27 May 87 14:13:51 CDT
  2609. Date:     Wed, 27 May 87 13:07 MDT
  2610. From:     <YSEGUIN%UNCAEDU.BITNET@wiscvm.wisc.edu>
  2611. Subject:  looking for help!
  2612. To:       info-cpm@simtel20.arpa
  2613. X-Original-To:  info-cpm@simtel20.arpa, YSEGUIN
  2614.  
  2615. I am a new user of this list and would
  2616. like to see if anyone could help me whit the
  2617. following problem.
  2618. I am using an hp-125 micro compytercomputer with voice since I am
  2619. visually handicapped.  I am loo looking for a copy of kermit that would run
  2620. on the hp-125.
  2621. Can anyone help!
  2622. Thank in advance.
  2623. Yves Seguin
  2624. YSEGUIN@UNCAEDU
  2625. 27-May-87 22:43:50-MDT,1056;000000000000
  2626. Return-Path: <info-cpm-request@simtel20.arpa>
  2627. Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Wed, 27 May 87 22:43:19 MDT
  2628. Received: by ucbvax.Berkeley.EDU (5.57/1.25)
  2629.     id AA05941; Wed, 27 May 87 21:18:17 PDT
  2630. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  2631.     for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa)
  2632.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  2633. Date: 28 May 87 03:32:56 GMT
  2634. From: beta!dzzr@nyu.arpa  (Douglas J Roberts)
  2635. Organization: Los Alamos Natl Lab, Los Alamos, N.M.
  2636. Subject: MDM700 - Can't toggle printer?
  2637. Message-Id: <5678@beta.UUCP>
  2638. Sender: info-cpm-request@simtel20.arpa
  2639. To: info-cpm@simtel20.arpa
  2640.  
  2641.  
  2642. OK, all you Modem700 users, any ideas why I can't toggle my printer "on"
  2643. while in terminal mode? I'm running Lifeboat Associates CP/M 2.2 on a
  2644. Northstar Horizon with the printer on the parallel port.
  2645.  
  2646. The printer works fine under CP/M, but CTL-P in MDM-700's terminal mode
  2647. has no effect.
  2648.  
  2649. Suggestions/ideas will greatly appreciated.
  2650.  
  2651. --Doug Roberts
  2652.   dzzr@lanl.gov
  2653.     
  2654. 30-May-87 00:16:47-MDT,1509;000000000000
  2655. Return-Path: <@SRI-NIC.ARPA:info-cpm-request@simtel20.arpa>
  2656. Received: from SRI-NIC.ARPA by SIMTEL20.ARPA with TCP; Sat, 30 May 87 00:16:11 MDT
  2657. Received: from ucbvax.Berkeley.EDU by SRI-NIC.ARPA with TCP; Fri 29 May 87 18:54:28-PDT
  2658. Received: by ucbvax.Berkeley.EDU (5.57/1.25)
  2659.     id AA05665; Fri, 29 May 87 18:36:52 PDT
  2660. Received: from USENET by ucbvax.Berkeley.EDU with netnews
  2661.     for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa)
  2662.     (contact usenet@ucbvax.Berkeley.EDU if you have questions)
  2663. Date: 29 May 87 18:31:40 GMT
  2664. From: amdahl!dlb!dana!rap@ames.arpa  (Rob Peck)
  2665. Organization: Dana Computer, Inc., Sunnyvale, CA
  2666. Subject: Re: Faster uudecode ?
  2667. Message-Id: <175@dana.UUCP>
  2668. References: <8705271556.AA19256@ucbvax.Berkeley.EDU>
  2669. Sender: info-cpm-request@simtel20.arpa
  2670. To: info-cpm@simtel20.arpa
  2671.  
  2672. In article <8705271556.AA19256@ucbvax.Berkeley.EDU>, UZR50D@DBNRHRZ1.BITNET writes:
  2673. > ..... Is there anybody who has a faster version of
  2674. > UUDECODE and / or UUENCODE for a CP/M - machine ???
  2675. > Thanks in advance  Ralf Schukey
  2676.  
  2677. On April 9, a version of uue* was posted in comp.sources.amiga.
  2678. Written in C, it might well be adaptable, and perhaps faster
  2679. than the pascal you now have.
  2680.  
  2681. The message ID was <3848@j.cc.purdue.edu>
  2682.  
  2683. The sender was "doc@j.cc.purdue.edu (Craig Norborg)"
  2684.  
  2685. The org. was: Purdue University Computing Center
  2686.  
  2687. (just in case you can't access an older message)
  2688.  
  2689. I'd have emailed direct, but my mailer doesnt seem to 
  2690. understand BITNET addresses.
  2691.  
  2692. Rob Peck.
  2693. 31-May-87 12:01:10-MDT,1357;000000000000
  2694. Mail-From: KPETERSEN created at 31-May-87 12:01:00
  2695. Date: Sun, 31 May 1987  12:00 MDT
  2696. Message-ID: <KPETERSEN.12306809005.BABYL@SIMTEL20.ARPA>
  2697. Sender: KPETERSEN@SIMTEL20.ARPA
  2698. From: Keith Petersen <W8SDZ@SIMTEL20.ARPA>
  2699. To:   Info-Cpm@SIMTEL20.ARPA
  2700. Subject: ZCPR 3.3 now available from SIMTEL20
  2701.  
  2702. The long-awaited ZCPR version 3.3 is now available from SIMTEL20.
  2703.  
  2704. Here is the current CRC list for that directory.  Get ZCPR33.FOR for
  2705. descriptions of some of the files.
  2706.  
  2707. Filename            Type     Bytes     CRC
  2708.  
  2709. Directory PD:<CPM.ZCPR33>
  2710. PCPITRAP.RZP.1            BINARY      1280  E1E1H
  2711. SAVE04.LBR.1            BINARY     11008  1527H
  2712. SHOW11-C.LBR.1            BINARY     44800  13ADH
  2713. SLTRAP.LBR.1            BINARY      6784  51A4H
  2714. SUB33-A.LBR.1            BINARY     15488  AF35H
  2715. XSUBZ.LBR.1            BINARY      9600  6696H
  2716. Z33ERR07.LBR.1            BINARY     14464  5A39H
  2717. Z33LIB02.LBR.1            BINARY      6656  3260H
  2718. Z33UPD.DZC.1            BINARY      7936  60CAH
  2719. Z33UTIL.LBR.1            BINARY     27136  A19BH
  2720. ZCPR33.FOR.1            ASCII      2353  F15CH
  2721. ZCPR33.LBR.1            BINARY     78976  E7E6H <--this is it!
  2722.  
  2723. These files are also available on my RCP/M (now offers 9600 bps USR
  2724. HST mode and MNP error correction) and on GEnie's CP/M RoundTable.
  2725.  
  2726. --Keith Petersen
  2727. Arpa: W8SDZ@SIMTEL20.ARPA
  2728. Uucp: {bellcore,decwrl,harvard,lll-crg,ucbvax,uw-beaver}!simtel20.arpa!w8sdz
  2729. GEnie: W8SDZ
  2730. RCP/M Royal Oak: 313-759-6569 - 300, 1200, 2400 (V.22bis) or 9600 (USR HST)
  2731. 31-May-87 17:34:15-MDT,650;000000000000
  2732. Return-Path: <CENT.MBECK%OZ.AI.MIT.EDU@MC.LCS.MIT.EDU>
  2733. Received: from OZ.AI.MIT.EDU (MC.LCS.MIT.EDU.#Internet) by SIMTEL20.ARPA with TCP; Sun, 31 May 87 17:34:08 MDT
  2734. Date: Sun 31 May 87 19:31:51-EDT
  2735. From: "Mark Becker" <Cent.Mbeck%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
  2736. Subject: Bug in C/80 V 3.1 printf()
  2737. To: Info-CPM@SIMTEL20.ARPA
  2738. Message-ID: <12306869243.42.CENT.MBECK@OZ.AI.MIT.EDU>
  2739.  
  2740. Hello -
  2741.  
  2742. I just found that:
  2743.  
  2744. #include "printf.h"
  2745. main() 
  2746. {
  2747.     printf("%%%d%%", 10);
  2748. }
  2749.  
  2750. prints "%10" and not "%10%" .
  2751.  
  2752.      Before I start figuring out whats happening from the source code,
  2753. has anyone already corrected this?
  2754.  
  2755. Regards,
  2756. Mark
  2757. -------
  2758.