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

  1.  1-Dec-86 07:27:11-MST,1172;000000000000
  2. Return-Path: <info-cpm-request@AMSAA.ARPA>
  3. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Mon 1 Dec 86 07:26:53-MST
  4. Received: from nadc.arpa by AMSAA.ARPA id a010006; 1 Dec 86 8:41 EST
  5. Date: 1 Dec 1986 08:38:41-EST
  6. From: prindle@nadc.ARPA
  7. To: alan@ariel.uucp, caip@nadc.ARPA, info-cpm@AMSAA.ARPA
  8. MMDF-Warning:  Parse error in preceding line at AMSAA.ARPA
  9. Subject: re: vi-like editor
  10.  
  11. Dr. Bruce Wampler's TVX editor (public domain) exists on SIMTEL20 in two forms:
  12. in PD:<CPM.C128>C128TVX2.LBR is an older version that is "vi-like" but does
  13. not have the same exact user interface as "vi", however, it is small enough to
  14. run on a CP/M 3.0 system (mine has 58K TPA).  On PD:<MSDOS.TVX-EDITOR> is a
  15. newer version with an interface which comes closer to emulating "vi", but may
  16. be too large to run on a 64K system once compiled (I'm not sure, never tried).
  17. There are conditional compilation sections to support CP/M.  The source lang-
  18. uage is "C".  The .COM file in C128TVX2.LBR is set up for an ADM31 terminal
  19. emulation - if you have any other terminal type, you will have to re-compile.
  20. Sincerely,
  21. Frank Prindle
  22. Prindle@NADC.arpa
  23.  1-Dec-86 23:44:58-MST,1446;000000000000
  24. Return-Path: <info-cpm-request@AMSAA.ARPA>
  25. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Mon 1 Dec 86 23:44:46-MST
  26. Received: from brl-smoke.arpa by AMSAA.ARPA id a001042; 2 Dec 86 1:03 EST
  27. Date:     Tue, 2 Dec 86 0:54:54 EST
  28. From:     Steve Lesh (ISC | howard) <lesh@BRL.ARPA>
  29. To:       info-c-request@BRL.ARPA
  30. cc:       info-cpm@BRL.ARPA
  31. Subject:  CP/M 80 C
  32.  
  33.     Thanks to all for responses to my query.
  34.  
  35.     I thought I'd pass on the results of phone conversations with two
  36. CP/M 80 C compiler vendors.
  37.  
  38. 1)    the latest release of Aztec C is 1.06d.  According to the vendor,
  39.     it is System V compatible with respect to all the pre-processor
  40.     directives (I didn't ask whether they had bit-fields yet).
  41.  
  42.     (The pre-processor stuff is important if you like Fred Fish's 
  43.     DBUG program posted on the network a little while ago.)
  44.  
  45. 2)    the latest release of the Eco-C compiler is 3.47.  They too men-
  46.     tioned support for System V pre-processor directives.  The person
  47.     I talked to would not guarentee that a "bug" I was told was in
  48.     their CP/M 80 C compiler had been fixed.  (He says that K&R say
  49.     that there is supposed to be a space between the function name and
  50.     the left paran.)
  51.     (or at least that there is some scripture somewhere which justifies
  52.     their not making a change)
  53.  
  54.     Thanks again for your replies.  We still have not made any commit-
  55. ments so any additional information will be appreciated.
  56.  2-Dec-86 09:32:23-MST,1496;000000000000
  57. Return-Path: <info-cpm-request@AMSAA.ARPA>
  58. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Tue 2 Dec 86 09:32:12-MST
  59. Received: from ucl-cs.arpa by AMSAA.ARPA id a011783; 2 Dec 86 10:15 EST
  60. Received: from pyr1.cs.ucl.ac.uk by mv1.Cs.Ucl.AC.UK   via Ethernet with SMTP
  61.            id aa02072; 2 Dec 86 14:46 WET
  62. Date:     Tue, 2 Dec 86 14:44:05 WET
  63. From:     Adrian Warman <adrian@cs.ucl.ac.uk>
  64. To:       info-cpm@AMSAA.ARPA
  65. Subject:  Draco Error File.
  66.  
  67. Hello.
  68.  
  69.     I successfully uploaded the DRACO system and example programs from
  70. SIMTEL20, and have had 100% success in getting the demo programs to compile
  71. and run.
  72.  
  73.     However, for some reason, whenever I try out any program which has
  74. any errors in - for example:
  75.  
  76. #util.g
  77.  
  78. proc nonrec main() void:
  79.  
  80. if x=1 then
  81.     writeln("Hi there.")
  82. fi
  83. corp
  84.  
  85.     ...then although the correct error (16) is flagged showing that "x" is
  86. unknown, the full error message does not appear, even though DRCERR.DAT is
  87. on the same (default) directory.
  88.  
  89.     I am using DRACO.COM rather than BIGDRACO.COM, 'cos my CP/M-plus system
  90. only has a 59K TPA, and BIGDRACO.COM needs 60K (apparently).
  91.  
  92.  
  93.     Does anyone have any suggestions as to what I am doing wrong?
  94.  
  95.         Thanks for any help.
  96.  
  97.     Adrian Warman
  98.     Dept. Computer Science
  99.     University College London
  100.     London, UK
  101.  
  102. (Not too sure what the e-mail address is - this is my first posting :-) -, but
  103. I think it is...)
  104.  
  105.     ARPA:adrian@ucl-cs.arpa
  106.     JANET:adrian@uk.ac.ucl.cs
  107.  3-Dec-86 01:52:54-MST,1209;000000000000
  108. Return-Path: <info-cpm-request@AMSAA.ARPA>
  109. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Wed 3 Dec 86 01:52:48-MST
  110. Received: from brl-adm.arpa by AMSAA.ARPA id a028568; 3 Dec 86 3:14 EST
  111. Received: from USENET by ADM.BRL.ARPA id aa15864; 3 Dec 86 3:13 EST
  112. From: "a.yorinks" <alan@ariel.uucp>
  113. Newsgroups: comp.os.cpm
  114. Subject: simtel20 access
  115. Message-ID: <1279@ariel.UUCP>
  116. Date: 2 Dec 86 16:06:04 GMT
  117. To:       info-cpm@AMSAA.ARPA
  118.  
  119. A few weeks ago, I was able to access simtel20. I received the INFO
  120. package and then received some catalogues.  I have asked simtel for
  121. some more catalogues and have received no reply.
  122.  
  123.  
  124. I received the following information. It is excerpted from an article
  125. on netnews:
  126.  
  127. >                        ....if you are sending a message through an
  128. >Internet host which is not using its Official Host Name, or does not
  129. >advertize one of the TCP services listed above, do not expect to see a
  130. >reply from us.
  131.  
  132. What I would like to know is, did I originally access simtel20 legally,
  133. and if so, can I still access it ? I communicate to simtel through ihnp4. Does
  134. this satisfy the above requirements?
  135.  
  136. Any help would be greatly appreciated.
  137.  4-Dec-86 13:39:02-MST,1099;000000000000
  138. Return-Path: <info-cpm-request@AMSAA.ARPA>
  139. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Thu 4 Dec 86 13:38:50-MST
  140. Received: from brl-adm.arpa by AMSAA.ARPA id a010559; 4 Dec 86 13:24 EST
  141. Received: from USENET by ADM.BRL.ARPA id aa10107; 4 Dec 86 13:20 EST
  142. From: "Joseph D. Loda" <joeloda@aicchi.uucp>
  143. Newsgroups: comp.os.cpm
  144. Subject: Looking for a backup utility
  145. Message-ID: <863@aicchi.UUCP>
  146. Date: 3 Dec 86 05:46:28 GMT
  147. To:       info-cpm@AMSAA.ARPA
  148.  
  149. Help!  I'm looking for a backup utility for my system (an Apple II+ with a 
  150. Sider 10 meg drive).   Most of the p/d utilities I have seen so far
  151. will not back up a file larger than a floppy; on an Apple system with 5.25
  152. drives that hold 126K, this is a problem.  The archive bit stuff would
  153. be nice, but right now I'd settle for something that backs up (and restores)
  154. files larger than a floppy.  Does this beast exist?
  155.  
  156. Thanks in advance for any help.
  157. -- 
  158. Joe Loda
  159. Analysts International (Chicago Branch)
  160.  
  161. Usenet:   ..!ihnp4!aicchi!joeloda
  162.    CIS:   75726,1641
  163.    BIX:   jloda
  164.  GEnie:   j.loda
  165.  4-Dec-86 14:43:19-MST,1146;000000000000
  166. Return-Path: <info-cpm-request@AMSAA.ARPA>
  167. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Thu 4 Dec 86 14:43:03-MST
  168. Received: from nadc.arpa by AMSAA.ARPA id a017027; 4 Dec 86 15:49 EST
  169. Date: 4 Dec 1986 15:42:42-EST
  170. From: prindle@nadc.ARPA
  171. To: info-cpm@AMSAA.ARPA
  172. Subject: UNIX equivalent for crunch 2.3
  173.  
  174. I am looking for a high level language (read that "C") implementation which
  175. uncompresses files compressed by the CP/M utility CRUNCH 2.3.  I've always
  176. been impressed by the many, many, implementations of SQ/USQ, all of which
  177. read and write the same format files.  Unfortunately, this is apparently not
  178. the case with this new generation of "Lempel-Zev" compression programs.
  179. Neither "COMPRESS" (from PD:<UNIX.FILE-MGMT>), nor "LZW" (from PD:<UNIX.CPM>),
  180. will decode this format; add to this the fact that "LZW" seems to be terminally
  181. broken when compiled under UNIX.  A solution to this problem is not obvious.
  182.  
  183. Alternatively, I would take a formal specification of the format of these
  184. "crunched" files and put together such a utility myself.
  185.  
  186. Thanks in advance,
  187. Frank Prindle
  188. Prindle@NADC.arpa
  189.  4-Dec-86 18:09:09-MST,793;000000000000
  190. Return-Path: <info-cpm-request@AMSAA.ARPA>
  191. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Thu 4 Dec 86 18:09:03-MST
  192. Received: from brl-adm.arpa by AMSAA.ARPA id a021823; 4 Dec 86 19:22 EST
  193. Received: from USENET by ADM.BRL.ARPA id aa15769; 4 Dec 86 19:17 EST
  194. From: GTI@psuvma.bitnet
  195. Newsgroups: comp.os.cpm
  196. Subject: Simtel20 Archives
  197. Message-ID: <8710GTI@PSUVMA>
  198. Date: 25 Nov 86 15:27:41 GMT
  199. Expires: 10 Dec 86 05:00:00 GMT
  200. Posted: Tue Nov 25 10:27:41 1986
  201. To:       info-cpm@AMSAA.ARPA
  202.  
  203. What are the commands to have the Simtel20 archives send me information,
  204. i.e. a Directory of what is contained in them.
  205.  
  206.                                    Leon Geesey
  207.                                      Student
  208.                                   Penn State Univ
  209.  4-Dec-86 22:50:02-MST,807;000000000000
  210. Return-Path: <info-cpm-request@AMSAA.ARPA>
  211. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Thu 4 Dec 86 22:49:57-MST
  212. Received: from wiscvm.arpa by AMSAA.ARPA id a022714; 5 Dec 86 0:14 EST
  213. Received: from (WILD)FREMBL51.BITNET by WISCVM.WISC.EDU on 12/04/86 at
  214.   08:33:58 CST
  215. Date:           Thu, 04 Dec 86 14:37:03 n
  216. To:  info-cpm@AMSAA.ARPA
  217. From:             David Wild <WILD%FREMBL51.BITNET@wiscvm.ARPA>
  218. Organisation:   European Molecular Biology Laboratory
  219. Postal-address:  c/o ILL, BP 156X, 38042 Grenoble Cedex, France
  220. Phone:          76-48-71-11 [switchboard]  76-48-72-75 [direct]
  221. Subject:        re: problems with Archive Server
  222.  
  223.  
  224. Since posting my previous message the "missing" replies from the Archive-Server
  225. have started to come through...sorry...
  226.  
  227. Dave
  228.  
  229.  4-Dec-86 23:45:07-MST,4526;000000000000
  230. Return-Path: <info-cpm-request@AMSAA.ARPA>
  231. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Thu 4 Dec 86 23:44:40-MST
  232. Received: from simtel20.arpa by AMSAA.ARPA id a022762; 5 Dec 86 0:40 EST
  233. Date: Thu, 4 Dec 1986  22:30 MST
  234. Message-ID: <KPETERSEN.12260272821.BABYL@SIMTEL20.ARPA>
  235. Sender: KPETERSEN@SIMTEL20.ARPA
  236. From: Keith Petersen <W8SDZ@SIMTEL20.ARPA>
  237. To:   prindle@NADC.ARPA
  238. Cc:   Info-Cpm@AMSAA.ARPA
  239. Subject: CRUNCH-UNCRUNCH abstract
  240.  
  241. The following is Steven Greenberg's ABSTRACT.TEC from CRUNCH23.LBR.
  242.  
  243.                        Technical Abstract
  244.  
  245. CRUNCH 1.x maintained a table representing up to 4096 strings  of
  246. varying lengths using the so called LZW algorithm, which has been
  247. described in the earlier documentation.  These strings were  ent-
  248. ered into a table in a manner where the strings content was  used
  249. to  determine the physical location (hashing), and that  location
  250. was used as the output code.  Hash "collisions" were resolved  by
  251. maintaining another 12 bits of data per entry which was a "link",
  252. or pointer to another entry.
  253.  
  254. In contrast, CRUNCH 2.x uses an "open-addressing, double hashing"
  255. method similar to that employed in the UNIX COMPRESS.  This meth-
  256. od  involves a table of length 5003, where only 4096 entries  are
  257. ever made, insuring the table never gets much more than about 80%
  258. full.  When a hash collision occurs, a secondary hash function is
  259. used to check a series of additional entries until an empty entry
  260. is  encountered.   This method creates a table filled  with  many
  261. criss-crossed "virtual" chains, without the use of a "link" entry
  262. in the table.
  263.  
  264. One reason this is important is that [without using any addition-
  265. al  memory] the 1 1/2 bytes which were previously allocated as  a
  266. link can now become the [output] code number.  This enables us to
  267. assign  code  numbers, which are kept right alongside  the  entry
  268. itself,  independently  of the entry's physical  location.   This
  269. allows  the codes to be assigned in order, permitting the use  of
  270. 9-bit  representations  until there are 512 codes in  the  table,
  271. after which 10 bit representations are output, etc.
  272.  
  273. The  variable bit length method has three ramifications.   It  is
  274. particularly  helpful when encoding very short files,  where  the
  275. table  never even fills up.  It also provides a fixed  additional
  276. savings  (not  insubstantial) even when the table does  fill  up.
  277. Thirdly,  it  reduces the overhead associated with  an  "adaptive
  278. reset"  to the point where it becomes a very viable  alternative.
  279. "Adaptive  reset" simply means throwing out the whole  table  and
  280. starting over.  This can be quite advantageous when used  proper-
  281. ly.  CRUNCH v2.x employs this provision, which was not  incorpor-
  282. ated in the V1.x algorithm.
  283.  
  284. "Code  reassignment" is an advancement I introduced with the  re-
  285. lease  of CRUNCH v2.0 based on original work.  It is not used  in
  286. COMPRESS,  any  MS-DOS ARC program, or [to the best of  my  know-
  287. ledge]  any other data compression utility  currently  available.
  288. There are many ways one might go about this (and at least as many
  289. possible pitfalls).  The algorithm I selected seemed to represent
  290. a good tradeoff between speed, memory used, and improved  perfor-
  291. mance, while maintaining "soundness of algorithm" (ie it works).
  292.  
  293.  
  294. Briefly,  it works as follows: Once the table fills up, the  code
  295. reassignment process begins. (At this same time, the  possibility
  296. of  adaptive reset is also enabled).  Whenever a new  code  would
  297. otherwise be made (if the table weren't full), the entries  along
  298. the  hash  chain  which  would normally  contain  the  entry  are
  299. scanned.  The first, if any, of those entries which was made  but
  300. never  subsequently referenced is bumped in favor of the new  en-
  301. try.   The uncruncher, which would not normally need  to  perform
  302. any  hash  type function, has an auxiliary  physical  to  logical
  303. translation table, where it simulates the hashing going on in the
  304. cruncher.   In this fashion it is able to exactly  reproduce  the
  305. reassignments made my the cruncher, which is essential.
  306.  
  307. ---
  308.  
  309. I  hope to write an article soon on "Recent Advancements in  Data
  310. Compression".  It would cover the recent history generally, along
  311. with a more detailed description of some of the algorithms, and a
  312. series of additional ideas for future enhancement.
  313.  
  314.                                               Steven Greenberg
  315.                                               16 November 1986
  316.  5-Dec-86 00:50:21-MST,1263;000000000000
  317. Return-Path: <info-cpm-request@AMSAA.ARPA>
  318. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Fri 5 Dec 86 00:50:12-MST
  319. Received: from wiscvm.arpa by AMSAA.ARPA id a022895; 5 Dec 86 2:21 EST
  320. Received: from (WILD)FREMBL51.BITNET by WISCVM.WISC.EDU on 12/03/86 at
  321.   12:23:33 CST
  322. Date:           Wed, 03 Dec 86 14:23:37 n
  323. To:  info-cpm@AMSAA.ARPA
  324. From:             David Wild <WILD%FREMBL51.BITNET@wiscvm.ARPA>
  325. Organisation:   European Molecular Biology Laboratory
  326. Postal-address:  c/o ILL, BP 156X, 38042 Grenoble Cedex, France
  327. Phone:          76-48-71-11 [switchboard]  76-48-72-75 [direct]
  328. Subject:        Re: Simtel20 access
  329.  
  330.  
  331. I've been getting files from the Archive-Server at SIMTEL20 since its
  332. inauguration without any problems, but now seem to have hit on one....
  333.  
  334. During the last ten days or so, I have sent off several requests (via the
  335. Bitnet-Arpanet gateway at WISCVM ) but have not had a single reply.
  336.  
  337. I understand that there is some congestion between Bitnet and Arpanet -
  338. is this the reason? Other stuff from Arpanet appears to be getting through,
  339. including my INFO-CPM mailings. Could anyone throw any light on what is
  340. happening? Have other Bitnet requestors encountered this problem recently?
  341.  
  342. David
  343.  
  344.  6-Dec-86 17:28:15-MST,4428;000000000000
  345. Return-Path: <info-cpm-request@AMSAA.ARPA>
  346. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Sat 6 Dec 86 17:28:03-MST
  347. Received: from brl-adm.arpa by AMSAA.ARPA id aa00141; 6 Dec 86 18:06 EST
  348. Received: from USENET by ADM.BRL.ARPA id aa05413; 6 Dec 86 5:59 EST
  349. From: Jon Mandrell <jon@amc.uucp>
  350. Newsgroups: comp.os.cpm
  351. Subject: Re: Interrupts on the N* Advantage
  352. Message-ID: <258@amc.UUCP>
  353. Date: 2 Dec 86 18:49:32 GMT
  354. To:       info-cpm@amsaa.arpa
  355.  
  356.  
  357. Sorry, I tried to mail this, but it got bounced.
  358.  
  359.  
  360. If the UART which you are using is a Z80 SIO or DART, then the interrupts
  361. are easy.  If you have something like and 8251, then things get a bit worse.
  362.  
  363. All of the following assumes that you have a Z80 device out there:
  364.  
  365.   The Z80 actually has 3 interrupt modes:
  366.   Mode 0:
  367.   A device toggles the INTR line, and the Z80 reads one byte off of the data
  368. bus and executes it.  This instruction is usually a RST, since these are one-
  369. byte CALLs (so they can be forced easily).  The RST instructions run you to
  370. one of 8 locations in low memory (0000, 0008, 0010, 0018, 0020, 0028, 0030,
  371. or 0038).  Actually, you can force any instruction onto the bus, but it doesn't
  372. really make sense to do a INC or whatever when an interrupt happens.
  373.  This is not the mode you would be using.
  374.  
  375.  Mode 1:
  376.  A device toggles the INTR line, and the Z80 branches to location 0038.  It
  377. pushes the current PC onto the stack, so that you can perform an RET and get
  378. back to your program.  This mode is rarely used.
  379.  
  380.  Mode 2:
  381.  Welcome to the real power of interrupts.  In this mode, the I register
  382. contains the top 8 bits of an address.  When a device toggles the INTR line,
  383. the Z80 acknowledges it, and then reads in one byte.  This is the bottom
  384. 8 bits of an address.
  385.  
  386.     ((I reg) * 256) + (byte read in)
  387.  
  388. The Z80 goes to the calculated address, and grabs the word there.  This is
  389. the address vector of the interrupt routine.  Perhaps an example would help.
  390.  
  391. Suppose you had the following code at location XX00 (any page boundary):
  392.  
  393.  
  394.  
  395. ; channel B of the SIO
  396.  
  397.     dw    chbtx        ; transmitter empty
  398.     dw    chbstat        ; external status change
  399.     dw    chbrx        ; receive char available
  400.     dw    chbspec        ; special receive condition
  401.  
  402. ; channel A of the SIO
  403.  
  404.     dw    chatx        ; transmitter empty
  405.     dw    chastat        ; external status change
  406.     dw    charx        ; receive char available
  407.     dw    chaspec        ; special receive condition
  408.  
  409.  
  410.  
  411. Then, if you perform the following code:
  412.  
  413.  
  414.  
  415.     ld    a,XX        ; the page number of the interrupt table
  416.     ld    i,a        ; setup the interrupt register
  417.  
  418.  
  419.  
  420. Any interrupt vectors that are placed on the bus will access the above
  421. table.  Still with me?
  422.  
  423. Now, you need to set the SIO up.  You might want to find a DART or SIO
  424. manual for this code to make sense, but here goes.  I use the OTIR to
  425. output a block of data to the same port.  You need to know the ports that
  426. the SIO resides at.
  427.  
  428.  
  429.  
  430.     ld    hl,table    ; the address of the table
  431.     ld    b,tlen        ; the length of the table
  432.     ld    c,SIO_PORT    ; the port address
  433.     otir
  434.  
  435.  
  436.  
  437. with a table that looks like this:
  438.  
  439.  
  440.  
  441. table:
  442.     db    0        ; junk.  Make sure we are at register 0
  443.     db    18h        ; reset the SIO
  444.     db    4        ; switch to register 4
  445.     db    44h        ; X16 clock, 1 stop, no parity
  446.     db    3        ; switch to register 3
  447.     db    0c1h        ; rx 8 bits, rx enable
  448.     db    5        ; switch to register 5
  449.     db    0eah        ; dtr, tx 8 bits, tx enable, RTS
  450.     db    1        ; register 1 (interrupt enable)
  451. ; set Y to 1 if you want a transmitter interrupt, or to 0 if you want to
  452. ; poll.  0 is probably the way you want to go.  Note that the value given
  453. ; below disables interrupts for special receive conditions, and for status
  454. ; changes (modem signals), so that the entries into the interrupt table above
  455. ; need not have them.
  456.     db    000110Y0b    ; rx int on all chars
  457. ; if this is channel B of the SIO which you are initializing, add the following
  458.     db    2        ; switch to register 2
  459.     db    0        ; vector value
  460. tlen    equ    $-table        ; calculate the length of the table
  461.  
  462.  
  463.  
  464. If you are not initializing channel B with the above code, you need to send
  465. a 2 and a 0 to channel B's control port also.
  466.  
  467. Well, that is the very basics.  Make sure your interrupt routines end with
  468. the RETI instruction, instead of a RET.  If you have any questions, send
  469. me some mail, or give me a call at (206) 882-5252.
  470.  
  471. -- 
  472. Jon Mandrell    (ihnp4!uw-beaver!tikal!amc!jon)
  473. Applied Microsystems Corp.
  474.  
  475. "flames >& /dev/null" - me
  476.  6-Dec-86 19:42:55-MST,8991;000000000000
  477. Return-Path: <info-cpm-request@AMSAA.ARPA>
  478. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Sat 6 Dec 86 19:42:26-MST
  479. Received: from simtel20.arpa by AMSAA.ARPA id a000651; 6 Dec 86 21:11 EST
  480. Date: Fri, 5 Dec 1986  20:00 MST
  481. Message-ID: <KPETERSEN.12260507734.BABYL@SIMTEL20.ARPA>
  482. Sender: KPETERSEN@SIMTEL20.ARPA
  483. From: Keith Petersen <W8SDZ@SIMTEL20.ARPA>
  484. To:   prindle@NADC.ARPA
  485. Cc:   Info-Cpm@AMSAA.ARPA
  486. Subject: Towards a UNIX equivalent for crunch 2.3
  487.  
  488. Here is another old DOC file from the original release of
  489. CRUNCH/UNCRUNCH, DETAILS.DOC.
  490.  
  491. --Keith
  492.  
  493. *****************************************************************
  494. *                                                               *
  495. *            LZW "Cruncher"   Data Compressor Utility           *
  496. *           LZW "Un-Cruncher" Data Decompressor Utility         *
  497. *                                                               *
  498. *                     Z-80 Only, CP/M 2.2+                      *
  499. *                         v1.0  3/30/86                         *
  500. *                                            -Steven Greenberg  *
  501. *****************************************************************
  502.  
  503.  
  504.      This  document  is intended to supplement  the  accompanying 
  505. ABSTRACT.DOC for those interested in some more technical details.
  506.  
  507.  
  508.      As  mentioned, the cruncher is based an Kent Williams'  imp-
  509. lementation  of the Lempel / Zev algorithm.  For  further  infor-
  510. mation on the algorithm itself, I refer you to his public  domain 
  511. file  LZW2COM.LBR which contains a description of  the  technique 
  512. and an actual implementation written in "C" source.
  513.  
  514.      In order to make a practical stand alone "cruncher" that was 
  515. easy  to use, especially for those already familiar with  squeez-
  516. ers, some header information had to be included in the  resulting 
  517. "crunched" file (eg. the filename of the original file, etc.).  I 
  518. have  defined  a header based on the time  tested  squeezed  file 
  519. format, with some necessary changes and a few additions.  The ad-
  520. ditions are mostly to insure that files crunched now will  always 
  521. be un-crunchable with future versions of the uncruncher, no  mat-
  522. ter what possible enhancements are made.  Those familiar with the 
  523. MS-DOS  ARC.xxx program have probably seen this idea  in  action.  
  524. More on this later.
  525.  
  526.      Another  slight problem with LZWCOM & LZWUNC had to do  with 
  527. the  question of termination.  When the input file was  exhausted 
  528. during  compression,  it was unlikely the output file  was  on  a 
  529. sector  boundary.   No matter what the rest of the  final  output 
  530. sector  was padded with ("1A"'s were used), the uncruncher  would 
  531. try  to uncrunch those bytes (since all data is conceivably  val-
  532. id).   This  resulted  in occasional  extra  sectors  of  garbage 
  533. following an otherwise properly decoded file.  While this did not 
  534. usually cause a problem, it was certainly not desirable.
  535.  
  536.      I have chosen to handle the termination problem the same way 
  537. it was handled with squeezed files;  by dedicating a unique  code 
  538. to  represent EOF (End Of Field).  By only allowing 4095  instead 
  539. of  4096 different codes (not a major shortcoming), code 000  can 
  540. become  a  dedicated EOF.  As soon as it is  encountered  on  the 
  541. input  file, the decoding process is known to be  complete.   For 
  542. those who are interested, the exact code put out by CRUNCH can be 
  543. duplicated by the "C" program LZWCOM if table entry zero "artifi-
  544. cially" flagged as "used" (before initializing the table).   That 
  545. insures  that the code will never come up, except  when  manually 
  546. inserted at the end of file.
  547.  
  548.      The other functional difference from LZWCOM involves  repeat 
  549. byte coding.  CRUNCH converts the "physical input stream" into  a 
  550. "logical  input  stream", which is then handed to  the  cruncher.  
  551. The conversion takes 3 or more contiguous occurrences of the same 
  552. byte  and encodes them as <byte> "90H" <count> where  "count"  is 
  553. the number of "additional" occurrences of <byte> (ie total occur-
  554. rences  -1).  90H itself is encoded as "90H" ,"00".  This  scheme 
  555. is identical to that used in standard squeezing.
  556.  
  557.      Crunching  requires  only one pass through the  input  file, 
  558. while  squeezing requires two.  While this is one of its  signif-
  559. icant  advantages, it does complicate the problem of including  a 
  560. checksum,  if  one is desired, in the header of the  result  file 
  561. (since  the value is not known until everything is done).  A  bad 
  562. solution is to close the finished output file, re-open it, insert 
  563. the checksum, and close it again.  A good solution is to put  the 
  564. checksum at the end of the output file right after the EOF.   And 
  565. that's  where  it is.  With all this in mind,  herein  follows  a 
  566. specification for the format of a crunched file.
  567.  
  568.           ---------------------------------------------
  569.  
  570.      ID  FIELD:  Bytes 0 and 1 are always 076H and 0FEH,  respec-
  571. tively.  This identifies the file as "crunched".
  572.  
  573.      FILENAME:  The  filename field starts at byte 2.   It  is  a 
  574. field  of variable length, terminated by a zero byte.  The  field 
  575. contains  the  filename as ASCII chars, including  an  ASCII  "." 
  576. immediately preceding the filename's extension.  Less than  eight 
  577. characters may precede the ".";  there is no necessity to pad the 
  578. filename with blanks.  Additional characters after the 3rd exten-
  579. sion character but before the zero byte specifically are  allowed 
  580. and  will be ignored by the current uncruncher.  This  allows  an 
  581. area of unlimited size for date stamping, or other  miscellaneous 
  582. information which a future cruncher or application program  might 
  583. want  to insert, for use or display by some uncrunching  program.  
  584. By  skipping over these bytes now, future  incompatibilities  are 
  585. eliminated.
  586.  
  587.      Following the zero byte are the following 4 bytes, in order:
  588.  
  589.      REFERENCE REVISION LEVEL:   1 byte  }
  590.      SIGNIFICANT REVISION LEVEL: 1 byte  } described later
  591.      ERROR DETECTION TYPE:       1 byte  }
  592.      SPARE:                      1 byte  }
  593.  
  594.      CRUNCHED  OUTPUT: After the SPARE byte, the actual  crunched 
  595. output finally begins.  The crunched output is a series of 12-bit 
  596. codes  in "natural" order.  (Every other 12-bit code starts on  a 
  597. byte  boundary and includes the 4 ms bits of the next byte.   The 
  598. "odd"  codes start in the middle of a byte and include the  whole 
  599. following byte as the remaining 8 ls bits).  A 12-bit code of 000 
  600. is  an EOF, as explained above.  If the EOF code itself  ends  in 
  601. the middle of a byte, an additional 4 bits of zero are padded  on 
  602. to get back on a byte boundary for the checksum. 
  603.  
  604.      CHECKSUM: The next two bytes are the 16-bit checksum,  least 
  605. significant  byte first.  The checksum is the modulo 2^16 sum  of 
  606. all  the bytes as input from the physical input stream, prior  to 
  607. repeat  byte encoding (or, in the case of uncrunching, as  output 
  608. to the physical output stream, after repeat byte decoding).
  609.  
  610.      REMAINDER  OF THE SECTOR: The remaining bytes in the  sector 
  611. following  the checksum are irrelevant.  CRUNCH fills  them  with 
  612. "1A"'s.
  613.  
  614.           ---------------------------------------------
  615.  
  616.      These are the four bytes not fully described above:
  617.  
  618.      "Reference  Revision Level":  The program/revision level  of 
  619. the  program that performed the crunch operation.  This  byte  is 
  620. put  in  for general reference only. The current  value  is  "10" 
  621. (hex).
  622.  
  623.      "Significant Revision Level":  If the value of this byte  in 
  624. a  crunched data file exceeds the value contained within the  un-
  625. crunching  program, the message "File requires newer revision  of 
  626. program" will be displayed.  If changes or enhancements are  ever 
  627. made to CRUNCH which are significant enough to actually output an 
  628. incompatible file, the information in this byte will allow a  new 
  629. revision  of UNCR to be compatible with all existing data  files, 
  630. old  or  new.  The error message gets displayed only  if  someone 
  631. tries to uncrunch a new file with an old uncruncher which doesn't 
  632. know about the "future" format yet. Current value is "10" (hex).
  633.  
  634.      "Error Detection Type": If this value is non-zero, the  cur-
  635. rent  uncruncher will not examine the checksum or give  an  error 
  636. associated  with  it.  This will permit a CRC type (or  no  error 
  637. checking) value to be used if circumstances warrant it. The  cur-
  638. rent  UNCR program is always checking for "illegal" codes,  which 
  639. are  ones which have not been defined by previous codes.  If  any 
  640. are  encountered,  the message "Invalid Crunched File"  is  disp-
  641. layed. This inherent self-checking probably precludes the  neces-
  642. sity of more advanced error checking.
  643.  
  644.      "Spare":  The SPARE byte is a spare byte.
  645.  
  646.                                              - Steven Greenberg
  647.                                                30 March 1986
  648.  6-Dec-86 19:48:08-MST,1313;000000000000
  649. Return-Path: <info-cpm-request@AMSAA.ARPA>
  650. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Sat 6 Dec 86 19:48:01-MST
  651. Received: from simtel20.arpa by AMSAA.ARPA id a000654; 6 Dec 86 21:14 EST
  652. Date: Fri, 5 Dec 1986  20:23 MST
  653. Message-ID: <KPETERSEN.12260511990.BABYL@SIMTEL20.ARPA>
  654. Sender: KPETERSEN@SIMTEL20.ARPA
  655. From: Keith Petersen <W8SDZ@SIMTEL20.ARPA>
  656. To:   prindle@NADC.ARPA
  657. Cc:   Info-Cpm@AMSAA.ARPA
  658. Subject: Towards a UNIX equivalent for crunch 2.3
  659.  
  660. The original LZWCOM program referred to in Steven Greenberg's
  661. description of his CRUNCH/UNCRUNCH program is available from
  662. SIMTEL20 as:
  663.  
  664. Filename            Type     Bytes     CRC
  665.  
  666. Directory PD:<CPM.SQUSQ>
  667. LZW.LBR.1            BINARY     50816  0D23H
  668.  
  669. This LBR contains the following files:
  670.  
  671.  COMMLZW.C
  672.  LZW.C
  673.  LZW.DQC
  674.  LZW.SUB
  675.  LZWCOM.COM
  676.  LZWUNC.C
  677.  LZWUNC.COM
  678.  
  679. Please remember that Greenberg has pointed out some shortcomings and
  680. problems with the original LZWCOM approach.  However, this should be a
  681. good starting place for making a Unix C version of Greenberg's
  682. enhanced cruncher.  The LZW.DOC file says that the C programs can be
  683. compiled on Unix and should be reasonably portable.
  684.  
  685. Please keep me posted on your progress.  I need a C version myself for
  686. use here on SIMTEL20 to maintain the crunched files.
  687.  
  688. --Keith
  689.  6-Dec-86 21:56:17-MST,1317;000000000000
  690. Return-Path: <info-cpm-request@AMSAA.ARPA>
  691. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Sat 6 Dec 86 21:56:05-MST
  692. Received: from brl-adm.arpa by AMSAA.ARPA id a000996; 6 Dec 86 23:38 EST
  693. Received: from USENET by ADM.BRL.ARPA id aa13452; 6 Dec 86 23:29 EST
  694. From: Jon Mandrell <jon@amc.uucp>
  695. Newsgroups: comp.os.cpm
  696. Subject: Re: CP/M 80 C
  697. Message-ID: <264@amc.UUCP>
  698. Date: 3 Dec 86 19:25:08 GMT
  699. To:       info-cpm@amsaa.arpa
  700.  
  701. In article <1211@brl-adm.ARPA> lesh@BRL.ARPA (ISC | howard) writes:
  702. >2)    the latest release of the Eco-C compiler is 3.47.  They too men-
  703. >    tioned support for System V pre-processor directives.  The person
  704. >    I talked to would not guarentee that a "bug" I was told was in
  705. >    their CP/M 80 C compiler had been fixed.  (He says that K&R say
  706. >    that there is supposed to be a space between the function name and
  707. >    the left paran.)
  708. >    (or at least that there is some scripture somewhere which justifies
  709. >    their not making a change)
  710.  
  711.   I think this is backwards.  I use ECO-C (version 3.10) and you can NOT place
  712. a space between the function call and the open paren.  K&R does NOT say that
  713. a space is valid, but they never say that it isn't.
  714. -- 
  715. Jon Mandrell    (ihnp4!uw-beaver!tikal!amc!jon)
  716. Applied Microsystems Corp.
  717.  
  718. "flames >& /dev/null" - me
  719.  7-Dec-86 13:44:09-MST,1386;000000000000
  720. Return-Path: <info-cpm-request@AMSAA.ARPA>
  721. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Sun 7 Dec 86 13:44:03-MST
  722. Received: from simtel20.arpa by AMSAA.ARPA id a000220; 7 Dec 86 15:10 EST
  723. Date: Sun, 7 Dec 1986  11:48 MST
  724. Message-ID: <KPETERSEN.12260942499.BABYL@SIMTEL20.ARPA>
  725. Sender: KPETERSEN@SIMTEL20.ARPA
  726. From: Keith Petersen <W8SDZ@SIMTEL20.ARPA>
  727. To:   Info-Cpm@AMSAA.ARPA
  728. Cc:   Info-Hams@SIMTEL20.ARPA
  729. Subject: CP/M ARC's renamed to ARKs
  730.  
  731. In response to a suggestion by Bob Freed <apollo!freed@EDDIE.MIT.EDU>
  732. the author of the CP/M UNARC program, I have renamed *.ARC to *.ARK in
  733. the SIMTEL20 CP/M program archives and on my RCP/M Royal Oak.  I will
  734. also be doing the same on the GEnie CP/M RoundTable.
  735.  
  736. Bob suggested that there would be less confusion about whether
  737. programs were for CP/M or MSDOS.  The file structure of ARCs and ARKs
  738. is identical and Bob's UNARC program will automatically deal with
  739. either filetype extension.
  740.  
  741. Bob is close to releasing his new CP/M ARC/ARK maker program NOAH (as
  742. in NOAH's ARK).  Questions about UNARC and NOAH should be directed to
  743. Bob at his new network address (welcome to the network Bob!).
  744.  
  745. --Keith Petersen
  746. Arpa: W8SDZ@SIMTEL20.ARPA
  747. Uucp: {bellcore,decwrl,harvard,lll-crg,ucbvax,uw-beaver}!simtel20.arpa!w8sdz
  748. GEnie Mail: W8SDZ
  749. RCP/M Royal Oak: 313-759-6569 (300, 1200, 2400 bps)
  750.  8-Dec-86 08:22:26-MST,1185;000000000000
  751. Return-Path: <info-cpm-request@AMSAA.ARPA>
  752. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Mon 8 Dec 86 08:22:17-MST
  753. Received: from wiscvm.arpa by AMSAA.ARPA id a007264; 8 Dec 86 9:35 EST
  754. Received: from (MAILER)RPICICGE.BITNET by WISCVM.WISC.EDU on 12/08/86
  755.   at 08:35:46 CST
  756. Received: by RPICICGE (Mailer X1.23) id 0563; Mon, 08 Dec 86 09:28:40
  757.   EST
  758. Date: Mon, 08 Dec 86 09:20:31 EST
  759. From:  "John S. Fisher" <FISHER%RPICICGE.BITNET@wiscvm.ARPA>
  760. To:  WILD%FREMBL51.BITNET@wiscvm.ARPA
  761. cc:  INFO-CPM@AMSAA.ARPA
  762. Subject: Re: Simtel20 access
  763. In-Reply-To:  WILD@FREMBL51 -- Wed, 03 Dec 86 14:23:37 n
  764.  
  765. I also have experienced a major problem getting ANYTHING from SIMTEL20
  766. lately.  I had entered requests every other day for about two weeks and
  767. received nothing.  On a hunch, I tried sending a hand-constructed request
  768. file, bypassing my mail system (even though it had always worked before).
  769. I received the archive file the next day.
  770.      Has something strange happened to the BITNET/ARPA gateway regarding
  771. mail from mailers, or perhaps has ARCHIVE-REQUEST support changed slightly
  772. so that my (formerly acceptable) RFC822 headers are rejected?
  773.  8-Dec-86 08:29:12-MST,1430;000000000000
  774. Return-Path: <info-cpm-request@AMSAA.ARPA>
  775. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Mon 8 Dec 86 08:28:56-MST
  776. Received: from apg-4.arpa by AMSAA.ARPA id a007696; 8 Dec 86 9:48 EST
  777. Date: Fri, 5 Dec 86 12:50:06 EST
  778. From: Gene Gall AMSTE-IMI 3708 <ggall@APG-4.ARPA>
  779. To: keller@BRL.ARPA, fwancho@SIMTEL20.ARPA
  780. Cc: ggall@APG-4.ARPA
  781. Subject: Site Licensing??
  782. Resent-From: Gene Gall AMSTE-IMI 3708 <ggall@APG-4.ARPA>
  783. Resent-To: INFO-CPM@AMSAA.ARPA, INFO-MICRO@BRL.ARPA, INFO-IBMPC@usc-isic.ARPA
  784. Resent-Date: Mon, 8 Dec 86  9:45:27 EST
  785.  
  786. Geroge/Frank,
  787.  
  788.      I have been tasked with providing a quick response to a query regarding
  789. site licensing of software.  I haven't been following this too closely of late.
  790. Would appreciate any off-the-top-of-your-head comments on current status.
  791.  
  792.      On my last look, most software vendors (despite enormous pressure from
  793. business users) were well-contented with status quo and reluctant to offer site
  794. licenses.  The few I read about seemed to be only token gestures
  795. (astronomically priced).  Has anything changed?
  796.  
  797. 1.  Any typical examples spring to mind (product, license cost, copy limit)?
  798.  
  799. 2.  Does one license generally provide for multiple formats (e.g., NorthStar,
  800. Apple, Z-100, Wyse PC, Z-248)?
  801.  
  802. 3.  Are patches or upgrades included or even provided for?
  803.  
  804.      Any quick thoughts would be appreciated.  Thanks.
  805.  
  806.                               Gene
  807.  8-Dec-86 10:22:58-MST,1024;000000000000
  808. Return-Path: <info-cpm-request@AMSAA.ARPA>
  809. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Mon 8 Dec 86 10:22:42-MST
  810. Received: from wiscvm.arpa by AMSAA.ARPA id a011296; 8 Dec 86 11:47 EST
  811. Received: from (PFENNIGE)CGEUGE51.BITNET by WISCVM.WISC.EDU on 12/08/86
  812.   at 10:49:00 CST
  813. Date: 8 DEC 86 16:59-N
  814. From:  PFENNIGER%CGEUGE51.BITNET@wiscvm.ARPA
  815. To:  INFO-CPM@AMSAA.ARPA
  816. Subj: bookshops ?
  817.  
  818. GREETINGS,
  819. This message is primarily intended for those people familiar with
  820.  the >Manhattan< area of New York. I will be passing thru NY in a few weeks
  821.  for a flying visit (less than 24 hours). I want to buy some reference books
  822.  etc on WORDSTAR, dBASE II ETC and computing books in general. Can anybody
  823. out there give me some recommendations as to where in Manhatten I should go
  824. to get the best selection etc, as I will not have the time to go roaming around
  825.  town looking for bookshops. Any advice on locations etc of bookshops would be
  826. appreciated......Brian Jarvis. Geneva Switzerland.
  827. 10-Dec-86 10:24:28-MST,682;000000000000
  828. Return-Path: <info-cpm-request@AMSAA.ARPA>
  829. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Wed 10 Dec 86 10:24:22-MST
  830. Received: from wiscvm.arpa by AMSAA.ARPA id a012881; 10 Dec 86 11:37 EST
  831. Received: from (UZR50D)DBNRHRZ1.BITNET by WISCVM.WISC.EDU on 12/10/86
  832.   at 10:34:41 CST
  833. Date: Wed, 10 Dec 86 14:55:02 MEZ
  834. To:  INFO-CPM@AMSAA.ARPA
  835. From:  UZR50D%DBNRHRZ1.BITNET@wiscvm.ARPA
  836. Subject: ADA Errata-files
  837.  
  838. Help !
  839.  
  840. I have got the ada description from the Simtel20 Archieve in
  841. <ADA.GENERAL>. But there seem to be specail text characters in
  842. Errata files. How can I manage them to get a readable file?
  843.  
  844. Please give me an answer.
  845.  
  846. So long Ralf
  847. 11-Dec-86 05:06:19-MST,547;000000000000
  848. Return-Path: <info-cpm-request@AMSAA.ARPA>
  849. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Thu 11 Dec 86 05:06:13-MST
  850. Received: from brl-adm.arpa by AMSAA.ARPA id a028831; 11 Dec 86 5:46 EST
  851. Received: from USENET by ADM.BRL.ARPA id aa17938; 11 Dec 86 5:40 EST
  852. From: root <root@pixel.uucp>
  853. Newsgroups: comp.os.cpm.ctl
  854. Subject: newgroup comp.os.cpm
  855. Message-ID: <98@pixel.UUCP>
  856. Date: 10 Dec 86 18:08:09 GMT
  857. Control: newgroup comp.os.cpm
  858. Posted: Wed Dec 10 13:08:09 1986
  859. To:       info-cpm@AMSAA.ARPA
  860.  
  861. comp.os.cpm
  862. 11-Dec-86 07:37:50-MST,691;000000000000
  863. Return-Path: <info-cpm-request@AMSAA.ARPA>
  864. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Thu 11 Dec 86 07:37:39-MST
  865. Received: from brl-adm.arpa by AMSAA.ARPA id a004092; 11 Dec 86 8:48 EST
  866. Received: from USENET by ADM.BRL.ARPA id aa21004; 11 Dec 86 8:44 EST
  867. From: Lee Olds <lee@voodoo.uucp>
  868. Newsgroups: comp.os.cpm
  869. Subject: kermit for Concurrent CP/M 86 request
  870. Message-ID: <207@voodoo.UUCP>
  871. Date: 8 Dec 86 23:49:05 GMT
  872. To:       info-cpm@AMSAA.ARPA
  873.  
  874. ********************
  875.  
  876. I am looking for a version of KERMIT for Concurrent CP/M 86.
  877.  
  878. Please respond via e-mail:
  879.  
  880.        ...uw-beaver!ssc-vax!voodoo!brutus!lee
  881.  
  882.          Thanks in advance.
  883.                Lee
  884. 11-Dec-86 15:35:31-MST,1073;000000000000
  885. Return-Path: <info-cpm-request@AMSAA.ARPA>
  886. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Thu 11 Dec 86 15:35:24-MST
  887. Received: from edwards-2060.arpa by AMSAA.ARPA id a019504; 11 Dec 86 16:17 EST
  888. Date: Thu 11 Dec 86 13:12:32-PST
  889. From: BUSSARD@EDWARDS-2060.ARPA
  890. Subject: RF Design Public Domain Software
  891. To: Info-hz-100@RADC-TOPS20.ARPA, info-cpm@AMSAA.ARPA, info-ibmpc@AMSAA.ARPA
  892. cc: bussard@EDWARDS-2060.ARPA
  893. Message-ID: <12262017258.13.BUSSARD@EDWARDS-2060.ARPA>
  894.  
  895. Help!! We are trying to get out some of the public domain RF Design software
  896. to people. Most of it is in IBM-PC format and easy to work with. Some of it
  897. is in two formats that we cannot work with, and we are looking for people that
  898. can copy these disks to IBM-PC format and or download them to the network and
  899. mail them to me to work with. Formats are:
  900.  
  901.         HP86/87 5.25" floppy
  902.         HP9800/9845 8" floppy
  903.  
  904. Please send mail direct to me or call:
  905.     Gerold Harrison
  906.     36 Irene Lane East
  907.     Plain View, NY   11803
  908.     (516) 822-1697
  909.  
  910. I am at Bussard@edwards-2060
  911. -------
  912. 11-Dec-86 18:33:56-MST,2113;000000000000
  913. Return-Path: <info-cpm-request@AMSAA.ARPA>
  914. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Thu 11 Dec 86 18:33:41-MST
  915. Received: from brl-adm.arpa by AMSAA.ARPA id a021043; 11 Dec 86 20:02 EST
  916. Received: from USENET by ADM.BRL.ARPA id aa13659; 11 Dec 86 19:54 EST
  917. From: kenny@uiucdcsb.ARPA
  918. Newsgroups: comp.os.cpm
  919. Subject: Re: bookshops ?
  920. Message-ID: <168200001@uiucdcsb>
  921. Date: 10 Dec 86 20:19:00 GMT
  922. Nf-ID: #R:brl-adm.ARPA:1347:uiucdcsb:168200001:000:1501
  923. Nf-From: uiucdcsb.cs.uiuc.edu!kenny    Dec 10 14:19:00 1986
  924. To:       info-cpm@AMSAA.ARPA
  925.  
  926.  
  927. Excuse me for posting to the net, but your BITNET address got trashed
  928. somewhere. 
  929.  
  930. /* Written 10:57 am  Dec  8, 1986 by PFENNIGER%CGEUGE@wiscvm.ARPA in uiucdcsb:comp.os.cpm */
  931. /* ---------- "bookshops ?" ---------- */
  932. GREETINGS,
  933. This message is primarily intended for those people familiar with
  934.  the >Manhattan< area of New York. I will be passing thru NY in a few weeks
  935.  for a flying visit (less than 24 hours). I want to buy some reference books
  936.  etc on WORDSTAR, dBASE II ETC and computing books in general. Can anybody
  937. out there give me some recommendations as to where in Manhatten I should go
  938. to get the best selection etc, as I will not have the time to go roaming around
  939.  town looking for bookshops. Any advice on locations etc of bookshops would be
  940. appreciated......Brian Jarvis. Geneva Switzerland.
  941. /* End of text from uiucdcsb:comp.os.cpm */
  942.  
  943. No question.  Barnes&Noble.  Fifth Avenue at around 18th Street (It's
  944. been a while... best to check the phone book first and get the exact
  945. address).  They pride themselves on being able to come up with
  946. virtually any textbook, including out-of-print ones.  I still use them
  947. as a last-resort source when other efforts to find a book have failed,
  948. even though I haven't lived in New York for years.
  949.  
  950. Kevin Kenny            UUCP: {ihnp4,pur-ee,convex}!uiucdcs!kenny
  951. Department of Computer Science    ARPA: kenny@B.CS.UIUC.EDU (kenny@UIUC.ARPA)
  952. University of Illinois        CSNET: kenny@UIUC.CSNET
  953. 1304 W. Springfield Ave.
  954. Urbana, Illinois, 61801        Voice: (217) 333-8740
  955. 11-Dec-86 19:19:01-MST,1126;000000000000
  956. Return-Path: <info-cpm-request@AMSAA.ARPA>
  957. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Thu 11 Dec 86 19:18:54-MST
  958. Received: from brl-adm.arpa by AMSAA.ARPA id a021091; 11 Dec 86 20:24 EST
  959. Received: from USENET by ADM.BRL.ARPA id aa13874; 11 Dec 86 20:16 EST
  960. From: konicek@uicsrd.csrd.uiuc.edu
  961. Newsgroups: comp.os.cpm
  962. Subject: Wanted: CP/M or Concurrent DOS
  963. Message-ID: <46500001@uicsrd>
  964. Date: 9 Dec 86 19:58:00 GMT
  965. Nf-ID: #N:uicsrd:46500001:000:523
  966. Nf-From: uicsrd.CSRD.UIUC.EDU!konicek    Dec  9 13:58:00 1986
  967. To:       info-cpm@AMSAA.ARPA
  968.  
  969.  
  970.  
  971.  
  972.  
  973.     I am trying to find a copy of CPM86 or Concurrent DOS. I just
  974. got a hold of an iSBC 12a board (8086 processor for the multibus)
  975. and need to get an OS up and running. I guess it doesn't need to be
  976. CP/M but I don't know of any other OS readily available.
  977.  
  978. I will *PAY* for it if I can find something.
  979.  
  980. Thanks in advance,
  981. Jeff Konicek
  982.  
  983. ATT: 217 244-0044
  984.  
  985.  
  986. P.S. Anybody ever get MSDOS running on a non-ibm 8086 machine
  987.     (Specifically, the multibus with ram, disk control, serial
  988.      I/O, and terminal (no graphics))
  989. 12-Dec-86 07:23:41-MST,13529;000000000000
  990. Return-Path: <info-cpm-request@AMSAA.ARPA>
  991. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Fri 12 Dec 86 07:23:06-MST
  992. Received: from simtel20.arpa by AMSAA.ARPA id a024713; 12 Dec 86 8:30 EST
  993. Date: Fri, 12 Dec 1986  06:28 MST
  994. Message-ID: <KPETERSEN.12262194847.BABYL@SIMTEL20.ARPA>
  995. Sender: KPETERSEN@SIMTEL20.ARPA
  996. From: Keith Petersen <W8SDZ@SIMTEL20.ARPA>
  997. To:   Info-Cpm@AMSAA.ARPA, Info-Micro@BRL.ARPA, Info-XMODEM@SIMTEL20.ARPA, 
  998.       Unix-Sources@BRL.ARPA, Telecom@mit-xx.ARPA
  999. Subject: Pending FCC ruling threat to modem users
  1000.  
  1001. The FCC is considering a ruling which may threaten low-cost modem
  1002. access to many on-line services, perhaps including Arpa/Milnet TACs
  1003. and Usenet Unix systems.  Here are the details from a copy of a file
  1004. just uploaded to my Remote CP/M system.
  1005.  
  1006. --Keith Petersen
  1007. Arpa: W8SDZ@SIMTEL20.ARPA
  1008. Uucp: {bellcore,decwrl,harvard,lll-crg,ucbvax,uw-beaver}!simtel20.arpa!w8sdz
  1009. GEnie Mail: W8SDZ
  1010. RCP/M Royal Oak: 313-759-6569 (300, 1200, 2400 bps)
  1011.  
  1012. --cut here--BADNEWS.PCP--cut here--
  1013.  
  1014. The FCC is considering reregulating the packet-switching networks like Telenet,
  1015. Tymnet, Compuserve, The Source and PC Pursuit.    This could result in additional
  1016. costs to the user.  This is excerpted from Infomat magazine which is available
  1017. for downloading.
  1018.  
  1019.  
  1020.  ====================================
  1021.  COMPUTER AND SOFTWARE NEWS -- PART 1
  1022.  ====================================
  1023.  
  1024.  by Tim Elmer
  1025.  
  1026.  ------------------------------------
  1027.  FREE LOCAL ACCESS TO PACKET
  1028.  SWITCHING NETWORKS MAY BE ELIMINATED
  1029.  ------------------------------------
  1030.  
  1031.  (BPS) -- The Federal Communications Commission (FCC) will vote on a proposal
  1032. to reregulate packet switching networks that, if approved, would eliminate
  1033. free local telephone access to those networks.
  1034.  
  1035.  "If this occurs, it might eventually double or triple the costs to those
  1036. using packet switching networks to access commercial on-line databases and
  1037. information services and triple or quadruple the costs to those using
  1038. Telenet's PC Pursuit," said Philip M. Walker, vice president and regulatory
  1039. counsel for Telenet Communications Corp.
  1040.  
  1041.  Predictably, the initiative to reregulate packet switching networks comes
  1042. primarily from the Bell Operating Companies (BOCs) and secondarily from AT&T.
  1043. These companies provide local telephone service to vast majority of telephone
  1044. customers throughout the U.S. and will benefit the most from FCC reregulation
  1045. of the packet switching networks.
  1046.  
  1047.  Under current FCC rules formulated in 1980 in the FCC's Second Computer
  1048. Inquiry, called Computer II, a distinction is made between "basic services"
  1049. and "enhanced services."
  1050.  
  1051.  "Basic services" are those that don't offer protocol conversion such as local
  1052. and long-distance voice telephone services.  "Enhanced services" are defined
  1053. in an open-ended fashion as computer-based services that are more than a
  1054. "basic service," in other words, services such as packet switching networks,
  1055. database and on-line type services, and remote computing services that offer
  1056. protocol conversion, according to Walker.
  1057.  
  1058.  Under the 1980 Computer II Inquiry, the FCC ruled that "basic services" would
  1059. continue to be regulated as they had always been.  However, the FCC also ruled
  1060. that "enhanced services" would be deregulated, which opened up the industry to
  1061. competition.  This resulted in numerous companies entering the packet
  1062. switching business, including BOCs, AT&T and at least a dozen others.  The
  1063. competition resulted in significant price reductions for packet switching
  1064. services.
  1065.  
  1066.  To prevent monopolization of the packet switching industry by the Big Boys
  1067. (the BOCs and AT&T), the FCC ruled that they had to keep separate accounting
  1068. figures for their "basic services" and for their "enhanced services," and that
  1069. they could not use revenues from their lucrative "basic services" to cross-
  1070. subsidize their "enhanced service" packet switching networks.
  1071.  
  1072.  The FCC also ruled that if the BOCs and AT&T used their "basic service"
  1073. telephone lines for packet switching services, then they must let their
  1074. competitors have access to those lines on the same basis, which would preserve
  1075. true competition in the industry.
  1076.  
  1077.  "Now, under the FCC's Computer Inquiry III, the FCC is asking, should we
  1078. redefine protocol conversion services as 'basic services' rather than enhanced
  1079. services?  Should we redefine all those companies as common carriers?  This
  1080. would, in effect, subject them not only to federal regulations but, even
  1081. worse, to state regulations," Walker said.
  1082.  
  1083.  The result would eliminate comparable interconnection requirements currently
  1084. imposed on BOCs and AT&T, allowing them to charge their packet switching
  1085. competitors local dial-in fees to access packet switching long-distance line
  1086. networks.
  1087.  
  1088.  It would also allow BOCs and AT&T to offer their own packet switching
  1089. services on a non-compensatory basis and, finally, allow them to cross-
  1090. subsidize those services with revenues from their much more lucrative voice
  1091. telephone service revenues.  In short, it would allow BOCs and AT&T to
  1092. monopolize the packet switching industry and probably drive out most
  1093. competitors.
  1094.  
  1095.  "In terms of cost impact," Walker said, "if we had to pay local access
  1096. charges, it would cost us about $3.60 an hour at the originating end, for
  1097. calls made by users to on-line databases and information services like
  1098. CompuServe and The Source.
  1099.  
  1100.  "And with PC Pursuit, for which we have out-dial modems, we would have to pay
  1101. not only 3.60 per hour access fees at the originating end but also $4.80 at
  1102. the terminating end, a total of about $8 or $9.  Obviously, to survive, we
  1103. would have to add those additional charges to our current fees and pass them
  1104. on to our consumers," Walker said.
  1105.  
  1106.  That would almost certainly spell the end of PC Pursuit, and it would likely
  1107. put out of business not only many independent packet switching networks but
  1108. also many on-line databases and information services.
  1109.  
  1110.  FCC approval of changes being considered in Computer III, Walker said, "would
  1111. really have a major impact on anyone using a packet switching service to
  1112. access online bulletin boards, databases, or information services aimed at the
  1113. residential user.  They are just going to get creamed if this happens."
  1114.  
  1115.  Walker said that is was not clear exactly when the FCC would vote on the
  1116. proposal, but that it would probably be the latter part of January or early
  1117. part of February, 1987.  "They are moving very fast on this," he said.
  1118.  
  1119.  For additional information, be sure to read Alan Bechtold's editorial in this
  1120. issue.
  1121.  
  1122.  ==========END>>>
  1123.  
  1124.  
  1125.  Copyright (C) 1986, by BBS PRESS SERVICE, INC.
  1126.  
  1127.  =================
  1128.  THE EDITOR SPEAKS
  1129.  =================
  1130.  
  1131.  "Low-Cost packet switching Service Threatened"
  1132.  
  1133.  by Alan R. Bechtold
  1134.  
  1135.  As described in our lead news story this issue, the FCC is now considering a
  1136. major change in the way packet switched phone services are defined.  This
  1137. change is likely to lead to the demise of many of these services, and to much
  1138. higher prices for the use of the few that will eventually remain in business.
  1139.  
  1140.  At the risk of over-simplification, I think I should first describe just what
  1141. a packet switched networking service is.  These are the services you use to
  1142. access online databases and commercial online services, such as CompuServe and
  1143. The Source, with just a local telephone call.  Once you call the local Telenet
  1144. or Tymnet number, for example, and a connection is made, you are then
  1145. connected with a computer that puts you in communication with the online
  1146. services with which you wish to communicate.
  1147.  
  1148.  This computer is handling a number of calls into the main system computer at
  1149. the same time.    It takes information you send and delivers it in "packets" to
  1150. the proper destination, picks up information from the online service computer
  1151. you called, and sends it, also in "packets," back to you.  All of this
  1152. communicating is done in these so-called "packets" because this allows the
  1153. network's computers to offer protocol conversion and handle several ongoing
  1154. communications sessions at the same time.
  1155.  
  1156.  FCC regulations allow AT&T and Bell Operating Companies (BOCs) to engage in
  1157. packet switching network operations, but they must also maintain completely
  1158. separate accounting of their voice and packet switching operations.  They must
  1159. also offer free local-calling access to their lines to any competitors engaged
  1160. in the packet switching service industry.
  1161.  
  1162.  The above regulations have allowed Telenet and Tymnet, among others, to
  1163. operate at a reasonable cost in a competitive atmosphere.  This is a case of
  1164. regulation of a business actually RESULTING in increased competition and lower
  1165. prices to consumers.
  1166.  
  1167.  As things stand now, you can call any local Telenet or Tymnet access number
  1168. and use these services to inexpensively access such online services as
  1169. CompuServe, The Source, Delphi, and countless others.  In addition, GTE's new
  1170. PC PURSUIT service now offers you access, through their Telenet packet
  1171. switching service, to literally hundreds of local bulletin boards in cities
  1172. all across the country--for a flat charge of $25 per month.
  1173.  
  1174.  But, the FCC is now being asked to REREGULATE this segment of the
  1175. communications industry, eliminating the FCC requirements that AT&T and BOCs
  1176. keep separate accounting records of their voice and packet switching services,
  1177. and eliminating the stipulation that the BOCs and AT&T must offer their
  1178. competitors in the packet switching business free access to their local
  1179. telephone connection lines.
  1180.  
  1181.  The idea is patently ridiculous.
  1182.  
  1183.  Mark Fowler, Chairman of the FCC, has been hailed by the press as a "fair-
  1184. market zealot."  The chances are very good that he views this proposed
  1185. reregulation as the magic road to increased competition and fairer pricing for
  1186. consumers.
  1187.  
  1188.  Unofficially, the word is out that the FCC advisory committee now considering
  1189. this matter is indeed leaning in favor of the proposed reregulation of the
  1190. packet switching industry.  If the committee recommends these changes, it's
  1191. likely that a majority of the five voting members on the Federal
  1192. Communications Commission will vote in favor of the changes.
  1193.  
  1194.  I have talked to sources within the industry who say it is the BOCs who are
  1195. pushing VERY HARD for this reregulation, because they want to get into the
  1196. packet switching service business in a big way, and they would like to rid
  1197. themselves of needless competition on their way to success.
  1198.  
  1199.  What's that?  RID themselves of competition?  But--the proposed reregulation
  1200. is supposed to FOSTER competition!  Why would a group of companies (BOCs)
  1201. hoping to eliminate their competition PUSH for this reregulation?  I hope the
  1202. answer to THAT question is entirely clear.
  1203.  
  1204.  Here we have an industry that is currently populated with plenty of
  1205. competition.  Prices are already reasonable.  Reregulation of the packet
  1206. switching service industry will IMMEDIATELY give giant corporations the upper
  1207. hand, and will allow them to cut off free access to their local access phone
  1208. lines to their competitors, namely Telenet and Tymnet and other similar
  1209. services that now offer you high-quality service, in a competitive
  1210. marketplace, at reasonable prices.
  1211.  
  1212.  The proposed reregulation, however, would force all packet switching services
  1213. to compete with the BOCs and AT&T, companies that would be able to use the
  1214. enormous profits they earn with their voice telephone services to cross-
  1215. subsidize their packet switching services and offer them on a non-compensatory
  1216. basis, at least until their competitors are eliminated.  When that happens,
  1217. they are then sure to jack up their fees to any level they want.
  1218.  
  1219.  It would also force their packet switching competitors to pay access fees for
  1220. connection to local phone lines.  The access fees alone could add as much as
  1221. $4.00 per hour to the fees packet switching companies would be forced to pass
  1222. on to their customers.    This will be added to your hourly connect-time charges
  1223. for accessing ALL online databases through these services.
  1224.  
  1225.  The proposed reregulation could very well spell the death of PC PURSUIT.
  1226. Because GTE also uses dial-out modems at the other end of their Telenet
  1227. connections for PC PURSUIT service, the company would be forced to pay an
  1228. hourly charge at BOTH ends of the phone line--totaling up to $8 or $9 per
  1229. hour.  These fees would have to be added to the flat $25 per month that GTE
  1230. now charges for access to PC-PURSUIT.  It would simply make the final cost to
  1231. PC-PURSUIT customers too high for the service to remain practical and
  1232. affordable.
  1233.  
  1234.  So--this is ONE TIME you MUST use your word processor to produce some letters
  1235. opposing this proposed reregulation!  Write to:
  1236.  
  1237.  Honorable Mark Fowler
  1238.  Chairman of the Federal Communications Commission
  1239.  Washington D.C. 20554
  1240.  
  1241.  Refer to Computer Inquiry III in your letters.  State clearly, in your own
  1242. words, that competitive packet switching services should not be reregulated or
  1243. subjected to carrier access charges, and then explain why not.    Tell Mr.
  1244. Fowler that reregulation of packet switching services will completely destroy
  1245. the existing fair market for these services, and eventually increase costs,
  1246. not DECREASE them.
  1247.  
  1248.  And hurry!  I have heard this matter will be going before the FCC for a vote
  1249. in the latter part of January or early part of February.  Time is running out.
  1250.  
  1251.  ==========END>>>
  1252. 12-Dec-86 09:27:50-MST,2051;000000000000
  1253. Return-Path: <info-cpm-request@AMSAA.ARPA>
  1254. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Fri 12 Dec 86 09:27:30-MST
  1255. Received: from brl-adm.arpa by AMSAA.ARPA id a029277; 12 Dec 86 10:39 EST
  1256. Received: from USENET by ADM.BRL.ARPA id aa24484; 12 Dec 86 10:31 EST
  1257. From: Mike Ciaraldi <ciaraldi@ROCHESTER.ARPA>
  1258. Newsgroups: comp.os.cpm
  1259. Subject: Terminal Emulator for VB3B
  1260. Message-ID: <23133@rochester.ARPA>
  1261. Date: 12 Dec 86 04:50:10 GMT
  1262. To:       info-cpm@AMSAA.ARPA
  1263.  
  1264. I know someone with an S-100 Z-80 CP/M system that includes
  1265. a Solid State Music VB3B video board.
  1266. This is a 24x80 character board driving a standard video monitor.
  1267. His BIOS has just a "glass tty" driver, i.e. it can send
  1268. characters tothe screen one after the other, and obey
  1269. CR and LF, but no other cursor positioning.
  1270.  
  1271. The only program he has that does full-screen stuff is Wordstar,
  1272. which has its own video board driver.
  1273.  
  1274. He has a modem on his system and a terminal emulation program
  1275. (MODEM7 or one of its derivatives).  Now he wants to be able
  1276. to call a host computer and do full-screen terminal emulation,
  1277. with some sort of cursor control so he can run screen editors
  1278. on the host instead of line editors.
  1279.  
  1280. Does anyone have a terminal emulation program I could have
  1281. (we might even pay for a commercial one) that emulates a
  1282. VT52, H19, VT100, ADM3 or anything else halfway intelligent,
  1283. using a VB3B without any CP/M BIOS support for cursor
  1284. positioning?
  1285.  
  1286. I have the version of KERMIT from Queen's University, written
  1287. in Turbo Pascal, that emulates a VT52.  Unfortunately, it
  1288. uses the Turbo Pascal screen-management functions.  These can be
  1289. easily patched to match any terminal, but won't work with a 
  1290. really dumb one; there has to be cursor positioning already
  1291. supported.
  1292.  
  1293. Thanks in advance for any help.
  1294.  
  1295. Mike Ciaraldi
  1296. seismo!rochester!ciaraldi
  1297.  
  1298. p.s. Why not add a driver to the BIOS?  The system is so
  1299. old it's not worth the time and trouble.  For $150
  1300. we could buy a used CRT terminal and avoid the whole problem.
  1301. 12-Dec-86 11:12:58-MST,1243;000000000000
  1302. Return-Path: <info-cpm-request@AMSAA.ARPA>
  1303. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Fri 12 Dec 86 11:12:51-MST
  1304. Received: from brl-adm.arpa by AMSAA.ARPA id a002821; 12 Dec 86 12:41 EST
  1305. Received: from USENET by ADM.BRL.ARPA id aa27129; 12 Dec 86 12:33 EST
  1306. From: "J.S.Jonas" <jeffj@sfsup.uucp>
  1307. Newsgroups: comp.os.cpm
  1308. Subject: Re: bookshops ?
  1309. Message-ID: <960@sfsup.UUCP>
  1310. Date: 12 Dec 86 01:47:58 GMT
  1311. To:       info-cpm@AMSAA.ARPA
  1312.  
  1313. > This message is primarily intended for those people familiar with
  1314. >  the >Manhattan< area of New York. I will be passing thru NY in a few weeks
  1315. >  town looking for bookshops. Any advice on locations etc of bookshops would be
  1316. > appreciated......Brian Jarvis. Geneva Switzerland.
  1317.  
  1318. Pardon the posting but a lot of my e-mail has been bounced back,
  1319. and I want this reply received on time to be useful.
  1320.  
  1321. Barnes and Noble has a good selection at their main store at
  1322. 17th street and 5th Avenue.  You don't have the time to browse the
  1323. Bargain Annex across the street.
  1324.  
  1325. I remember a good selection of computer books at Coliseum Books
  1326. at 57th Street and Broadway (I believe).  It's near the NY Coliseum.
  1327.  
  1328.     Jeffrey Jonas
  1329.     {ihnp4 | allegra | cbosgd} attunix ! jeffj
  1330. 13-Dec-86 19:04:09-MST,756;000000000000
  1331. Return-Path: <info-cpm-request@AMSAA.ARPA>
  1332. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Sat 13 Dec 86 19:04:03-MST
  1333. Received: from simtel20.arpa by AMSAA.ARPA id a000963; 13 Dec 86 20:42 EST
  1334. Date: Wednesday, 10 December 1986  06:47-MST
  1335. Message-ID: <KPETERSEN.12262590441.BABYL@SIMTEL20.ARPA>
  1336. From: Keith Petersen <W8SDZ@SIMTEL20.ARPA>
  1337. Sender: KPETERSEN@SIMTEL20.ARPA
  1338. To: Info-XMODEM@SIMTEL20.ARPA
  1339. Subject:   MEX overlay for Apple PCPI and Applecat II needed
  1340. ReSent-From: KPETERSEN@SIMTEL20.ARPA
  1341. ReSent-To: Info-Cpm@AMSAA.ARPA
  1342. ReSent-Date: Sat 13 Dec 1986 18:41-MST
  1343.  
  1344. I have received a request for an overlay for MEX for use with the
  1345. Apple PCPI card and Applecat II internal modem.  Does anyone have
  1346. this?
  1347.  
  1348. --Keith
  1349. 14-Dec-86 01:08:49-MST,1015;000000000000
  1350. Return-Path: <info-cpm-request@AMSAA.ARPA>
  1351. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Sun 14 Dec 86 01:08:43-MST
  1352. Received: from brl-adm.arpa by AMSAA.ARPA id a001472; 14 Dec 86 2:40 EST
  1353. Received: from USENET by ADM.BRL.ARPA id aa05679; 14 Dec 86 2:28 EST
  1354. From: Keith Brown <keithb@reed.uucp>
  1355. Newsgroups: comp.os.cpm
  1356. Subject: Wanted: Aztec C compiler for CP/M (I know: yuk!)
  1357. Message-ID: <4840@reed.UUCP>
  1358. Date: 13 Dec 86 07:27:34 GMT
  1359. Keywords: compiler C CP/M
  1360. To:       info-cpm@AMSAA.ARPA
  1361.  
  1362.  
  1363. Wanted/Needed:  A real legal copy of the Aztec C compiler for my
  1364. Epson QX-10 CP/M computer.  Must have the manual and all 'comes-withs'.
  1365.  
  1366. And, oh yes, I'm willin to pay for it, too.  Other 5.25" CP/M formats
  1367. would probably be acceptable.
  1368.  
  1369. I just figured that someone in the neighborhood had been down the CP/M
  1370. path back in the olden days before *nix and might have a copy around
  1371. they no longer were using.
  1372.  
  1373. -Keith (...tektronix!reed!keithb)
  1374. 503 635-5055 days/eves pst.
  1375. 16-Dec-86 02:18:15-MST,1719;000000000000
  1376. Return-Path: <info-cpm-request@AMSAA.ARPA>
  1377. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Tue 16 Dec 86 02:18:07-MST
  1378. Received: from brl-adm.arpa by AMSAA.ARPA id a002710; 16 Dec 86 3:43 EST
  1379. Received: from USENET by ADM.BRL.ARPA id aa00898; 16 Dec 86 3:30 EST
  1380. From: Mark Steven Jeghers <mark@cogent.uucp>
  1381. Newsgroups: comp.os.cpm
  1382. Subject: Re: Wanted: Aztec C compiler for CP/M (I know: yuk!)
  1383. Message-ID: <105@cogent.UUCP>
  1384. Date: 16 Dec 86 04:21:05 GMT
  1385. Keywords: compiler C CP/M
  1386. To:       info-cpm@AMSAA.ARPA
  1387.  
  1388. In article <4840@reed.UUCP> keithb@reed.UUCP (Keith Brown) writes:
  1389. >
  1390. >Wanted/Needed:  A real legal copy of the Aztec C compiler for my
  1391. >Epson QX-10 CP/M computer.  Must have the manual and all 'comes-withs'.
  1392. >And, oh yes, I'm willin to pay for it, too.  Other 5.25" CP/M formats
  1393. >would probably be acceptable.
  1394.  
  1395. I also need a good C compiler under CP/M.  I'm on a Kaypro.  Aztec C
  1396. would be dandy, but Software Toolworks C would be ok also.
  1397. -- 
  1398. +----------------------------------------------------------------------------+
  1399. |     Mark Steven Jeghers         ECHOMPGULP - process has eaten it          |
  1400. | cryptography, terrorist, DES, drugs, cipher, secret, decode, NSA, CIA, NRO |
  1401. |                                                                            |
  1402. |     {ihnp4,cbosgd,lll-lcc,lll-crg}|{dual,ptsfa}!cogent!mark                |
  1403. |                                                                            |
  1404. | Cogent Software Solutions can not be held responsible for anything said    |
  1405. | by the above person since they have no control over him in the first place |
  1406. +----------------------------------------------------------------------------+
  1407. 16-Dec-86 04:48:50-MST,1186;000000000000
  1408. Return-Path: <info-cpm-request@AMSAA.ARPA>
  1409. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Tue 16 Dec 86 04:48:43-MST
  1410. Received: from brl-adm.arpa by AMSAA.ARPA id a003218; 16 Dec 86 6:21 EST
  1411. Received: from USENET by ADM.BRL.ARPA id aa01830; 16 Dec 86 6:13 EST
  1412. From: Michael Kersenbrock <michaelk@copper.uucp>
  1413. Newsgroups: comp.os.cpm
  1414. Subject: Osborn (and others) screen movement commands wanted
  1415. Message-ID: <775@copper.UUCP>
  1416. Date: 16 Dec 86 02:42:03 GMT
  1417. To:       info-cpm@AMSAA.ARPA
  1418.  
  1419. Does any one have a list of screen-movement ( plus attribute setting, etc)
  1420. for an Osborn computer?  Or for any other one (other than ANSI/vt100 which
  1421. I have now)?  Kaypro maybe?
  1422.  
  1423. Every once in a while I run across a program that is either binary-only, or
  1424. mercilessly hardwired to some particular format (Osborn at the moment).
  1425.  
  1426. It seems like it might not be too hard to write a conversion RSX to do
  1427. translations, and be relatively universal as well.  If someone has an
  1428. osborn list and sends it to me, I'd appreciate it.  If there's interest,
  1429. I could post the results.
  1430.  
  1431. -- 
  1432.  
  1433. Mike Kersenbrock
  1434. Tektronix Computer Aided Software Engineering
  1435. Aloha, Oregon
  1436. 16-Dec-86 07:31:22-MST,3893;000000000000
  1437. Return-Path: <info-cpm-request@AMSAA.ARPA>
  1438. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Tue 16 Dec 86 07:31:00-MST
  1439. Received: from mit-mc.arpa by AMSAA.ARPA id a007736; 16 Dec 86 8:54 EST
  1440. Received: from MX.LCS.MIT.EDU (CHAOS 1440) by MC.LCS.MIT.EDU 16 Dec 86 08:53:23 EST
  1441. Date: Mon, 15 Dec 86 22:53:25 EST
  1442. From: "Keith F. Lynch" <KFL%MX.LCS.MIT.EDU@mit-mc.ARPA>
  1443. Subject: Re: Pending FCC ruling threat to modem users
  1444. To: W8SDZ@SIMTEL20.ARPA
  1445. cc: KFL%MX.LCS.MIT.EDU@mit-mc.ARPA, Telecom@mit-xx.ARPA, Info-Micro@BRL.ARPA, 
  1446.     Unix-Sources@BRL.ARPA, Info-XMODEM@SIMTEL20.ARPA, Info-Cpm@AMSAA.ARPA
  1447. Message-ID: <962235.861215.KFL@MX.LCS.MIT.EDU>
  1448.  
  1449.     From: Keith Petersen <W8SDZ@SIMTEL20.ARPA>
  1450.  
  1451.     ... Mark Fowler, Chairman of the FCC, has been hailed by the press as
  1452.     a "fair market zealot."  The chances are very good that he views this
  1453.     proposed reregulation as the magic road to increased competition and
  1454.     fairer pricing for consumers.
  1455.  
  1456.   In a free market, it would not matter to users whether this
  1457. legislation was passed or not.  The legislation does not COMPELL local
  1458. phone companies to charge four dollars or more per hour for a local
  1459. phone call to a long distance data service (e.g. PC PURSUIT) it merely
  1460. ALLOWS them to do so.
  1461.   Since it doesn't cost local phone companies any more to complete a
  1462. local call to such a service than it costs them to complete any other
  1463. local call, phone companies would not lose money by not adding this
  1464. charge.  And since any local phone company which chose NOT to charge
  1465. extra for such calls would get plenty of business from users who
  1466. formerly used any local phone company which DID decide to add the
  1467. extra charge, there would certainly be local phone companies which
  1468. choose not to add this charge.  This is how the free market works.
  1469.   HOWEVER, we unfortunately do NOT have a free market in local
  1470. telephone service.  Since each user has no choice which local phone
  1471. company to use, thanks to a pernicious government-mandated monopoly,
  1472. most local phone companies probably WILL add this charge if they are
  1473. allowed to.  They know they won't lose any customers to competing
  1474. firms, since there are no competing firms allowed.
  1475.   In an ideal world, this legislation would be a good thing.  Phone
  1476. companies like any other company should be allowed to charge whatever
  1477. they wish for their services, subject only to the constraints of the
  1478. marketplace.  But in the context of the captive marketplace, this
  1479. legislation would be a very bad thing.  If phone companies are given
  1480. a monopoly, their prices have to be regulated by the government, since
  1481. they are not regulated by the free market.  Without regulation, they
  1482. would be able to charge as much as they could without people abandoning
  1483. phone service for bicycle messengers or carrier pigeons.
  1484.   Phone service ought to cost the user just a few percent more than
  1485. the cost to the phone company of providing the service.  In a free
  1486. market, it would.  In a regulated mandated monopoly, it might (how
  1487. could anyone ever tell?).  But given an unregulated mandated monopoly,
  1488. i.e. the worst of both worlds, the local phone companies will sell
  1489. their services for slightly less than the cost to the user of doing
  1490. completely without phone service.
  1491.   If Mark Fowler is indeed an advocate of the free market system, this
  1492. is how it should be explained to him.
  1493.  
  1494.      Write to:
  1495.  
  1496.      Honorable Mark Fowler
  1497.      Chairman of the Federal Communications Commission
  1498.      Washington D.C. 20554
  1499.  
  1500.      Refer to Computer Inquiry III in your letters. ...
  1501.  
  1502.      And hurry!  I have heard this matter will be going before the FCC for a
  1503.      vote in the latter part of January or early part of February.  Time is
  1504.      running out.
  1505.  
  1506.   I completely agree.  Write today!
  1507.  
  1508.   Please reply to me, I am not on most of these lists.
  1509.                                 ...Keith
  1510.  
  1511. 16-Dec-86 09:36:18-MST,1423;000000000000
  1512. Return-Path: <info-cpm-request@AMSAA.ARPA>
  1513. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Tue 16 Dec 86 09:35:58-MST
  1514. Received: from xerox.arpa by AMSAA.ARPA id a014126; 16 Dec 86 11:03 EST
  1515. Received: from PinotNoir.ms by ArpaGateway.ms ; 16 DEC 86 07:59:34 PST
  1516. Date: 16 Dec 86 07:58 PST
  1517. From: Ghenis.pasa@xerox.ARPA
  1518. Subject: Re: C compiler requests
  1519. In-reply-to: Mark Steven Jeghers <mark@cogent.uucp>'s message of 16 Dec
  1520.  86 04:21:05 GMT
  1521. To: info-cpm@AMSAA.ARPA
  1522. Message-ID: <861216-075934-3894@Xerox>
  1523.  
  1524. >In article <4840@reed.UUCP> keithb@reed.UUCP (Keith Brown) writes:
  1525. >>
  1526. >>Wanted/Needed:  A real legal copy of the Aztec C compiler for my
  1527. >>Epson QX-10 CP/M computer.  Must have the manual and all
  1528. 'comes-withs'.
  1529. >> 
  1530. >>And, oh yes, I'm willin to pay for it, too.  Other 5.25" CP/M formats
  1531. >>would probably be acceptable.
  1532. >
  1533. >I also need a good C compiler under CP/M.  I'm on a Kaypro.  Aztec C
  1534. >would be dandy, but Software Toolworks C would be ok also.
  1535. >
  1536.  
  1537. So why don't you guys just go ahead and buy your compilers directly from
  1538. Aztec or Software Toolworks? They will be very happy to sell you a real
  1539. legal copy, and carry both QX-10 and Kaypro formats. Mix also has a C
  1540. compiler for just $39, with tons of documentation, a good deal for a
  1541. learning tool.
  1542.  
  1543. Remember that info-cpm isn't for classified ads (at least on the ARPANET
  1544. side).
  1545.  
  1546. Cheers!
  1547.  
  1548. -- Pablo Ghenis
  1549. 16-Dec-86 11:01:15-MST,1031;000000000000
  1550. Return-Path: <info-cpm-request@AMSAA.ARPA>
  1551. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Tue 16 Dec 86 11:01:09-MST
  1552. Received: from nadc.arpa by AMSAA.ARPA id a016591; 16 Dec 86 12:21 EST
  1553. Date: 16 Dec 1986 12:12:39-EST
  1554. From: prindle@nadc.ARPA
  1555. To: info-cpm@AMSAA.ARPA
  1556. Subject: re: Mix C compiler
  1557.  
  1558. > ... Mix also has a C compiler for just $39, with tons of documentation, a
  1559. > good deal for a learning tool.
  1560.  
  1561. That's about the size of it too - a learning tool.  Mix C for CP/M is a victim
  1562. of terminal neglect.  It does more things wrong than right.  While the MSDOS
  1563. version has undergone many revisions in the past year, the CP/M version
  1564. remains virtually untouched.  All sorts of problems with blanks, unexpected
  1565. reserved words, undocumented error codes, runtime anomalies, etc.  Forget
  1566. trying to port any non-trivial program to Mix C, you're wasting your time.
  1567.  
  1568. Frank Prindle
  1569. Prindle@NADC.arpa
  1570. PS. I'd be glad to sell my Mix C compiler/book to any sucker who'd give me $39
  1571.     for it:-}
  1572. 16-Dec-86 13:01:24-MST,2770;000000000000
  1573. Return-Path: <info-cpm-request@AMSAA.ARPA>
  1574. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Tue 16 Dec 86 13:01:12-MST
  1575. Received: from ge-crd.arpa by AMSAA.ARPA id a020303; 16 Dec 86 13:57 EST
  1576. Date: 16 Dec 86 13:54 EST
  1577. From: OCONNOR DENNIS MICHAEL <OCONNORDM@GE-CRD.ARPA>
  1578. Subject: Re: Re: Pending FCC ruling threat to modem users
  1579. To: Info-Cpm@AMSAA.ARPA
  1580.  
  1581. 
  1582. Date: 16-DEC-1986 13:30
  1583. Sender: OCONNORDM
  1584. Subject: Re: Re: Pending FCC ruling threat to modem users
  1585. To: Info-Micro@BRL.ARPA@SMTP, Unix-Sources@BRL.ARPA@SMTP, 
  1586. To: Info-XMODEM@simtel20.arpa@SMTP, Info-Cpm@amsaa.arpa@SMTP
  1587. --------
  1588. People have written lots on this new FCC rule change ( threat? threat?? ).
  1589. Lots of stirring propaganda about regulators who beleive in fairy
  1590. tales, monopolies that will screw you to the wall given the chance,
  1591. and legislated monopolies. Lots of misconceptions.
  1592.  
  1593. First: MODEM calls DO NOT cost the phone company the same amount as
  1594. other calls. They tend to be longer, and don't tolerate noise as well.
  1595. Anyone who knows ANYTHING about the phone system knows it can only handle
  1596. some fraction of the possible calls that might be happening at any one
  1597. time, and the longer the average phone call is, the more equipment
  1598. will be needed to meet this fraction. If the phone company always
  1599. charged for local service BY THE MINUTE, well, no problem, but
  1600. phone companies usually charge BY THE CALL or BY THE MONTH. So heavy
  1601. modem users are currently being SUBSIDIZED by the rest of the users.
  1602. Sounds like it MIGHT be UNFAIR. 
  1603.  
  1604. Second: the goverment does not "mandate" a "pernicous" monopoly, it
  1605. simply allows it. You or I can go out, get right-of-way on the
  1606. utility poles like the cable companies, and start our very own 
  1607. telephone system. The problem is you and I would lose big money trying
  1608. to compete with the phone system. And our users would be annoyed at
  1609. people next door using BELL being a long-distance call. But you can do it,
  1610. in fact, General Electric HAS done it, for both its local and long-distance
  1611. telephone needs ( known as DIALCOM ).
  1612.  
  1613. If ANYBODY needs something explained to him, it is probably NOT Mark Fowler.
  1614. Before people rush to pester him, why don't you all invite someone from
  1615. the Phone Companies to give THEIR SIDE. This rush to get half-informed 
  1616. people to rise up and make trouble is simply electronic rabble-rousing,
  1617. NOT what democracy thrives on : informed opinion from people who have
  1618. been exposed to ALL SIDES of an issue.
  1619.  
  1620. ( DISCLAIMER : I'm not neccesarily disagreeing with anyone, nor
  1621.   do these opinions represent anybody elses. I could even be wrong.
  1622.   But then again, so could you. 'Cause remember ...  No matter 
  1623.   where you go, There you are. )        Dennis O'Connor
  1624.  
  1625. --------
  1626.  
  1627. --------
  1628.  
  1629. 16-Dec-86 20:53:36-MST,1002;000000000000
  1630. Return-Path: <info-cpm-request@AMSAA.ARPA>
  1631. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Tue 16 Dec 86 20:53:22-MST
  1632. Received: from wiscvm.arpa by AMSAA.ARPA id a028925; 16 Dec 86 22:14 EST
  1633. Received: from (SINGPANG)HLERUL5.BITNET by WISCVM.WISC.EDU on 12/16/86
  1634.   at 21:11:56 CST
  1635. Date:     Wed, 17 Dec 86 00:09 N
  1636. From:        SINGPANG%HLERUL5.BITNET@wiscvm.ARPA
  1637. MMDF-Warning:  Parse error in preceding line at AMSAA.ARPA
  1638. Subject:  Xmodem for vax/vms
  1639. To:  info-cpm@AMSAA.ARPA
  1640. X-Original-To:  info-cpm@amsaa.arpa, SINGPANG
  1641.  
  1642. Hello all,
  1643. I am having some trouble with the xmodem.for which is in the archive
  1644. request in simtel20. Downloading text files is okay.
  1645. Binary files is a mess. The first 128 bytes are okay, but then xmodem.for puts
  1646. after every following 128 bytes 130 bytes of spaces or other junk; so I cant
  1647. download com files.
  1648. Does anybody have a fix for this or is there another version of xmodem for vax/v
  1649. ms
  1650.  
  1651. Regards,
  1652. Marc
  1653. BITNET: SINGPANG@HLERUL5
  1654. 16-Dec-86 21:52:31-MST,1174;000000000000
  1655. Return-Path: <info-cpm-request@AMSAA.ARPA>
  1656. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Tue 16 Dec 86 21:52:24-MST
  1657. Received: from brl-adm.arpa by AMSAA.ARPA id a029033; 16 Dec 86 23:14 EST
  1658. Received: from USENET by ADM.BRL.ARPA id aa03296; 16 Dec 86 23:09 EST
  1659. From: brian@prism.uucp
  1660. Newsgroups: comp.os.cpm
  1661. Subject: NEEDED:Northstar Serial Board
  1662. Message-ID: <408100001@prism>
  1663. Date: 16 Dec 86 16:00:00 GMT
  1664. Nf-ID: #N:prism:408100001:000:590
  1665. Nf-From: prism.UUCP!brian    Dec 16 11:00:00 1986
  1666. To:       info-cpm@AMSAA.ARPA
  1667.  
  1668.  
  1669. HELP! - Need serial interface for Northstar Advantage
  1670.  
  1671. I have a northstar advantage (cp/m machine with 2 floppies, cpm2.2, and
  1672. graphics all in a desktop package) which is mute.
  1673.  
  1674. I'd like to get the serial card for this machine.
  1675.  
  1676. I'll either pay $$$ or trade something for it.
  1677.  
  1678. thanks.
  1679.  
  1680. (617) 661-0777 work
  1681. (617) 298-6064 home
  1682.  
  1683. brian k. moran 
  1684.   
  1685.  
  1686. ----
  1687. Brian K. Moran  brian@mirror.TMC.COM    
  1688.                {mit-eddie, ihnp4!inmet, wjh12, cca, datacube}!mirror!brian
  1689. Mirror Systems    2067 Massachusetts Avenue  Cambridge, MA, 02140
  1690. Telephone:    617-661-0777 extension 141
  1691. (((((((( * ))))))))
  1692. ---
  1693. 16-Dec-86 23:59:56-MST,588;000000000000
  1694. Return-Path: <info-cpm-request@AMSAA.ARPA>
  1695. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Tue 16 Dec 86 23:59:49-MST
  1696. Received: from brl-adm.arpa by AMSAA.ARPA id a029371; 17 Dec 86 1:35 EST
  1697. Received: from USENET by ADM.BRL.ARPA id aa05357; 17 Dec 86 1:27 EST
  1698. From: Stephen Tihor <tihor@acf4.uucp>
  1699. Newsgroups: comp.os.cpm
  1700. Subject: Re: bookshops ?
  1701. Message-ID: <12560001@acf4.UUCP>
  1702. Date: 17 Dec 86 01:57:00 GMT
  1703. Posted: Tue Dec 16 20:57:00 1986
  1704. To:       info-cpm@AMSAA.ARPA
  1705.  
  1706. McGraw Hill Bookstore (6th near 46th) is my second choice after the 
  1707. big B&N.
  1708. 17-Dec-86 08:31:44-MST,783;000000000000
  1709. Return-Path: <info-cpm-request@AMSAA.ARPA>
  1710. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Wed 17 Dec 86 08:31:18-MST
  1711. Received: from apg-1.arpa by AMSAA.ARPA id a007888; 17 Dec 86 9:35 EST
  1712. Date: Wed, 17 Dec 86  9:27:32 EST
  1713. From: Robert Bloom AMSTE-TEI 3775 <rbloom@APG-1.ARPA>
  1714. Subject: NorthStar Adv Serial Board
  1715. To: info-cpm@AMSAA.ARPA
  1716. Cc: rbloom@APG-1.ARPA
  1717.  
  1718. (I wish arpa hosts could recognise the uucp paths ...)
  1719. NorthStar serial boards and lots of NorthStar knowledge can be found
  1720. at Fischer Computer Systems in Angwin, CA (707)965-2414.  I bought one
  1721. from Randy jFischer about 6 months ago.  So far we done about $7k of
  1722. business (which goes a long way in the 8-bit world now) with no
  1723. complaints.  "Just a satisfied customer."
  1724.  
  1725. Bob Bloom
  1726.  
  1727. 17-Dec-86 13:44:23-MST,681;000000000000
  1728. Return-Path: <info-cpm-request@AMSAA.ARPA>
  1729. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Wed 17 Dec 86 13:44:09-MST
  1730. Received: from brl-smoke.arpa by AMSAA.ARPA id a018967; 17 Dec 86 14:16 EST
  1731. Date:     Wed, 17 Dec 86 13:59:53 EST
  1732. From:     Steve Lesh (ISC | howard) <lesh@BRL.ARPA>
  1733. To:       info-apple@BRL.ARPA
  1734. cc:       info-cpm@AMSAA.ARPA
  1735. Subject:  boot from 3.5 Unidisk / applicard
  1736.  
  1737.     Does anyone know of a disk-driver from PCPI (or anybody else) that
  1738. permits booting from Apple's 3.5 Unidisk with the Apple II+ controller
  1739. card?
  1740.  
  1741.     I would also appreciate hearing from anyone  using the Applicard 
  1742. with the new  GS.
  1743.  
  1744.     Thanks in advance.
  1745. 17-Dec-86 16:31:10-MST,1104;000000000000
  1746. Return-Path: <info-cpm-request@AMSAA.ARPA>
  1747. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Wed 17 Dec 86 16:31:01-MST
  1748. Received: from brl-adm.arpa by AMSAA.ARPA id a025451; 17 Dec 86 17:56 EST
  1749. Received: from USENET by ADM.BRL.ARPA id aa13782; 17 Dec 86 17:50 EST
  1750. From: Dennis Flaherty <dennisf@marque.uucp>
  1751. Newsgroups: comp.os.cpm
  1752. Subject: A/D Data Acquisition
  1753. Message-ID: <32@marque.UUCP>
  1754. Date: 17 Dec 86 19:29:00 GMT
  1755. To:       info-cpm@AMSAA.ARPA
  1756.  
  1757. This one sounds awful, so anyone who can help us, 
  1758. please send email!
  1759.  
  1760. We have a 8086 Multibus system with a Burr-Brown
  1761. 31-channel A to D converter board, 8-inch 
  1762. floppies, and a hard drive running CP/M-86.
  1763. We need a program for data acquisition to capture
  1764. data from the A/D converter board to be saved
  1765. on either the floppies or the hard drive.
  1766. If anyone has such a program or knows how to
  1767. obtain one, please save us months of software
  1768. development and write back!
  1769.                                 Dennis Flaherty
  1770. usenet:  ihnp4(etc)!uwvax!uwmcsd1!marque!dennisf
  1771. internet:  marque!dennisf@csd1.milw.wisc.edu
  1772. 17-Dec-86 21:23:34-MST,1806;000000000000
  1773. Return-Path: <info-cpm-request@AMSAA.ARPA>
  1774. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Wed 17 Dec 86 21:23:13-MST
  1775. Received: from brl-adm.arpa by AMSAA.ARPA id a026033; 17 Dec 86 22:43 EST
  1776. Received: from USENET by ADM.BRL.ARPA id aa15780; 17 Dec 86 22:28 EST
  1777. From: Keith Brown <keithb@reed.uucp>
  1778. Newsgroups: comp.os.cpm
  1779. Subject: Re: C compiler requests
  1780. Message-ID: <4936@reed.UUCP>
  1781. Date: 17 Dec 86 19:30:27 GMT
  1782. To:       info-cpm@AMSAA.ARPA
  1783.  
  1784. In article <1560@brl-adm.ARPA> Ghenis.pasa@xerox.ARPA writes:
  1785.  
  1786. >>In article <4840@reed.UUCP> keithb@reed.UUCP (Keith Brown) writes:
  1787. >>
  1788. >>Wanted/Needed:  A real legal copy of the Aztec C compiler for
  1789. >>my Epson QX-10 CP/M computer.  Must have the manual and all
  1790. >>'comes-withs'.  [...]
  1791. >
  1792. >So why don't you guys ... buy your compilers directly from
  1793. >Aztec or Software Toolworks? They will ... sell you a real
  1794. >legal copy,... Mix also has a C compiler for just $39, with
  1795. >tons of documentation, a good deal for a learning tool.
  1796. >  [...] -- Pablo Ghenis
  1797.  
  1798. The reason I posted this to the net is that most of you reading this
  1799. are now developing under the *nix environment.  Many of you who may
  1800. have bought a 'real legal' copy of the Aztec C compiler no longer use
  1801. or need it.  I'm simply offering an oportunity for someone to re-coup
  1802. a little of their investment by selling a tool they no longer need.
  1803.  
  1804. As it turns out, I ran out of time and so have purchased my own copy
  1805. directly.  However, I've received requests from others to turn over
  1806. any 'extra' leads to them.
  1807.  
  1808. As for MIX C, I've also heard that it's worthless for serious work.
  1809. I have tried it, along with SuperSoft, Ecco, and BDS.  None are full
  1810. implementations of C (at least in the versions I've got).
  1811.  
  1812. -Keith Brown
  1813. ...!tektronix!reed!keithb
  1814. 18-Dec-86 02:49:30-MST,2076;000000000000
  1815. Return-Path: <info-cpm-request@AMSAA.ARPA>
  1816. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Thu 18 Dec 86 02:49:23-MST
  1817. Received: from brl-adm.arpa by AMSAA.ARPA id a026616; 18 Dec 86 4:12 EST
  1818. Received: from USENET by ADM.BRL.ARPA id aa17671; 18 Dec 86 4:06 EST
  1819. From: Mark Steven Jeghers <mark@cogent.uucp>
  1820. Newsgroups: comp.os.cpm
  1821. Subject: Re: C compiler requests
  1822. Message-ID: <109@cogent.UUCP>
  1823. Date: 18 Dec 86 07:07:09 GMT
  1824. To:       info-cpm@AMSAA.ARPA
  1825.  
  1826. In article <4936@reed.UUCP> keithb@reed.UUCP (Keith Brown) writes:
  1827. >In article <1560@brl-adm.ARPA> Ghenis.pasa@xerox.ARPA writes:
  1828. >>>In article <4840@reed.UUCP> keithb@reed.UUCP (Keith Brown) writes:
  1829. >>>
  1830. >>>Wanted/Needed:  A real legal copy of the Aztec C compiler for
  1831. >>>my Epson QX-10 CP/M computer.  Must have the manual and all
  1832. >>>'comes-withs'.  [...]
  1833. >>
  1834. >>So why don't you guys ... buy your compilers directly from
  1835. >>Aztec or Software Toolworks? They will ... sell you a real
  1836.            ^^^^^^^^^^^^^^^^^^
  1837. How is the C by Software Toolworks?  I understand it is about $50
  1838. for CP/M.
  1839.  
  1840. >As for MIX C, I've also heard that it's worthless for serious work.
  1841. >I have tried it, along with SuperSoft, Ecco, and BDS.  None are full
  1842. >implementations of C (at least in the versions I've got).
  1843.  
  1844. Is Software Toolworks C a full implementation (or close)?
  1845. -- 
  1846. +----------------------------------------------------------------------------+
  1847. |     Mark Steven Jeghers         ECHOMPGULP - process has eaten it          |
  1848. | cryptography, terrorist, DES, drugs, cipher, secret, decode, NSA, CIA, NRO |
  1849. |                                                                            |
  1850. |     {ihnp4,cbosgd,lll-lcc,lll-crg}|{dual,ptsfa}!cogent!mark                |
  1851. |                                                                            |
  1852. | Cogent Software Solutions can not be held responsible for anything said    |
  1853. | by the above person since they have no control over him in the first place |
  1854. +----------------------------------------------------------------------------+
  1855. 18-Dec-86 10:43:37-MST,1609;000000000000
  1856. Return-Path: <info-cpm-request@AMSAA.ARPA>
  1857. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Thu 18 Dec 86 10:43:03-MST
  1858. Received: from acc.arpa by AMSAA.ARPA id a007948; 18 Dec 86 12:04 EST
  1859. Date: 18 Dec 86 08:44:00 PST
  1860. From: shawn@ACC.ARPA
  1861. MMDF-Warning:  Parse error in preceding line at AMSAA.ARPA
  1862. Subject: re:A/D Data Aquisition
  1863. To: info-cpm <info-cpm@AMSAA.ARPA>
  1864. cc: shawn@acc.ARPA
  1865. Reply-To: shawn@ACC.ARPA
  1866. MMDF-Warning:  Parse error in preceding line at AMSAA.ARPA
  1867.  
  1868.  
  1869. Dennis;
  1870.     When I had to deal with one of the Intel Boards
  1871. about three years ago, I found that Intel supported (had)
  1872. a users group called Insight. It cost us about $200.00
  1873. to join for the year, but it was like a CP/M Users Group
  1874. (an example only) in that you had access to programs written,
  1875. and donated by others. If you donate programs, you get credit
  1876. toward those you wish to obtain. The only frusterating part
  1877. was that you had to join BEFORE you found out IF they had
  1878. what you needed. We took the chance, and got what we needed,
  1879. and it saved us a BUNCH of time, effort, and bucks.
  1880. I'm afraid that this info is three years old, we didn't
  1881. renew out membership, as the project was completed.
  1882. I'm afraid couldn't tell you how to get to them,
  1883. except possibly through an Intel Rep.
  1884. I hope this helps, I can't remember what all they had, I do
  1885. remember that it seemed extensive at the time, with all sorts
  1886. of off the wall programs for specific applications, and
  1887. quite a bit of general interest as well.
  1888.  
  1889.     Take Care
  1890.     Shawn Miner
  1891.     (Advanced Computer Communications)
  1892.     shawn@acc
  1893.  
  1894.  
  1895. ------
  1896. 18-Dec-86 17:08:37-MST,1551;000000000000
  1897. Return-Path: <info-cpm-request@AMSAA.ARPA>
  1898. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Thu 18 Dec 86 17:08:21-MST
  1899. Received: from wiscvm.arpa by AMSAA.ARPA id a019990; 18 Dec 86 18:42 EST
  1900. Received: from (SINGPANG)HLERUL5.BITNET by WISCVM.WISC.EDU on 12/18/86
  1901.   at 17:40:28 CST
  1902. Date:     Fri, 19 Dec 86 00:04 N
  1903. From:        SINGPANG%HLERUL5.BITNET@wiscvm.ARPA
  1904. MMDF-Warning:  Parse error in preceding line at AMSAA.ARPA
  1905. Subject:  problems with rsa lbr in sigm vol.202
  1906. To:  info-cpm@AMSAA.ARPA
  1907. X-Original-To:  info-cpm@amsaa.arpa, SINGPANG
  1908.  
  1909. Hello all,
  1910. thank you for all the messages concerning my query about xmodem for the vax.
  1911. I have received a copy and everything is doing fine (I think).
  1912. I have now another problem:
  1913. I have downloaded rsasetup.com. Unfortunately this program hangs up my micro
  1914. CRCK4.COM gives as checksum E608. Is this the right checksum??
  1915. If the author is listening: I would rather have the Turbo Pascal sources
  1916. because I think ther terminal package in Turbo Pascal is driving my micro
  1917. crazy. It does not know about the terminal implemented in rsasetup, rsacrypt
  1918. and rsaclear.
  1919.  
  1920. Can anyone tell me if this package (rsat12.lbr on sigm vol202) is working
  1921. properly on any micro or do I have to look for something else.
  1922.  
  1923. If you know of any other package concerning public key cryptography (or other
  1924. systems) please let me know.. I intend to use it for private messages in Fido
  1925. networks and Bitnet.
  1926. Regards:
  1927. Marc Chang
  1928.  
  1929. P.S. Any errors in my typing are due to bad line connection
  1930. 18-Dec-86 17:38:47-MST,1472;000000000000
  1931. Return-Path: <info-cpm-request@AMSAA.ARPA>
  1932. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Thu 18 Dec 86 17:38:24-MST
  1933. Received: from umd2.umd.edu by AMSAA.ARPA id a020048; 18 Dec 86 19:04 EST
  1934. Date: Thu, 18 Dec 86 18:34:40 EST
  1935. From: Manasseh Katz <MKATZ@umd2.umd.edu>
  1936. To: info-cpm@AMSAA.ARPA
  1937. Subject: VFILER for CPM-86
  1938. Message-ID: <M1986$041621.359000KATZM.MKATZ@UMD2.UMD.EDU>
  1939.  
  1940. I have downloaded VFILER for CPM-86 - FASTVF86.LBR on SIGM vol 229.
  1941. The LBR includes a doc file, a source (A86) file and an executable.
  1942. The program runs OK, but not perfectly since my terminal has some codes
  1943. different from a NEC APC.  The doc and source give easy directions for
  1944. customizing it, but it didn't work.  I then tried just reassembling the
  1945. original A86 file, following the directions, to see if that would work -
  1946. it doesn't.  I get BDOS errors with strange files and impossible disks
  1947. when I try to run it.  Has anyone tried using this file (on anything
  1948. other than an APC) ?  I am using ASM86 ver 1.1, under MPM-86 ver 2.13,
  1949. if that means anything to anyone.  I am using a WYSE 100 terminal, though
  1950. that doesn't matter since I get errors even before i try to customize
  1951. the program.  If noone has any idea what's wrong, does anyone have a similar
  1952. type of filer program for CPM-86 ?
  1953.                                    Manasseh Katz
  1954.                                    MKATZ@UMD2.UMD.EDU
  1955.                                    KATZM@UMDD.BITNET
  1956. 18-Dec-86 20:31:15-MST,1063;000000000000
  1957. Return-Path: <info-cpm-request@AMSAA.ARPA>
  1958. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Thu 18 Dec 86 20:31:06-MST
  1959. Received: from brl-adm.arpa by AMSAA.ARPA id a021250; 18 Dec 86 21:56 EST
  1960. Received: from USENET by ADM.BRL.ARPA id aa04951; 18 Dec 86 21:45 EST
  1961. From: Bill Hery <wjh@wayback.uucp>
  1962. Newsgroups: comp.os.cpm,rec.arts.books
  1963. Subject: Re: bookshops ?
  1964. Message-ID: <1013@wayback.UUCP>
  1965. Date: 18 Dec 86 15:47:36 GMT
  1966. To:       info-cpm@AMSAA.ARPA
  1967.  
  1968. > McGraw Hill Bookstore (6th near 46th) is my second choice after the 
  1969. > big B&N.
  1970.  
  1971. Another interesting place for advanced computer, math, physics, and
  1972. engineering books is Books Scientific, near Barnes and Nobles 18th st.
  1973. store at 18 E. 16th Street (just east of fifth Avenue).
  1974.  
  1975. They have a good selection of textbooks (undergrad and grad) and monographs;
  1976. I've found things there that B&N didn't stock.  They don't take credit cards,
  1977. but they did take a personal check from a NJ bank.  All this information is
  1978. as of about a year ago.
  1979.  
  1980. Bill Hery
  1981. ihnp4!bonnie!wjh
  1982. 19-Dec-86 17:51:32-MST,1249;000000000000
  1983. Return-Path: <info-cpm-request@AMSAA.ARPA>
  1984. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Fri 19 Dec 86 17:51:20-MST
  1985. Received: from brl-adm.arpa by AMSAA.ARPA id a002280; 19 Dec 86 19:21 EST
  1986. Received: from USENET by ADM.BRL.ARPA id aa03269; 19 Dec 86 19:08 EST
  1987. From: Praveen Kumar <phaedrus@eneevax.uucp>
  1988. Newsgroups: comp.os.cpm,rec.arts.books
  1989. Subject: Re: bookshops ?
  1990. Message-ID: <502@eneevax.UUCP>
  1991. Date: 19 Dec 86 15:16:32 GMT
  1992. To:       info-cpm@AMSAA.ARPA
  1993.  
  1994.  
  1995. >From: wjh@wayback.UUCP (Bill Hery)
  1996. >Another interesting place for advanced computer, math, physics, and
  1997. >engineering books is Books Scientific, near Barnes and Nobles 18th st.
  1998.  
  1999. I have been buying my textbooks and all my technical books from them
  2000. for over 3 years now.  They are a fantastic store.  They have almost
  2001. everything.  They also give you a ten percent discount and they also
  2002. only charge $1.50 for shipping (they ship UPS, BTW).
  2003.  
  2004. Their address and phone number:
  2005.  
  2006. Books Scientific
  2007. 18th E. 16th Street, 2nd Floor
  2008. New York NY 10003
  2009. 800-621-1220
  2010.  
  2011. Usual disclaimer...I have no connections to Books Scientific except as
  2012. a satisfied customer.
  2013. -- 
  2014.  
  2015. ARPA:    phaedrus@eneevax.umd.edu 
  2016. UUCP:    {seismo,allegra}!umcp-cs!eneevax!phaedrus
  2017. 19-Dec-86 22:12:25-MST,2732;000000000000
  2018. Return-Path: <info-cpm-request@AMSAA.ARPA>
  2019. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Fri 19 Dec 86 22:12:11-MST
  2020. Received: from simtel20.arpa by AMSAA.ARPA id a002680; 19 Dec 86 23:42 EST
  2021. Date: Friday, 19 December 1986  21:07-MST
  2022. Message-ID: <KPETERSEN.12264196126.BABYL@SIMTEL20.ARPA>
  2023. Sender: prindle@AMSAA.ARPA
  2024. MMDF-Warning:  Parse error in preceding line at AMSAA.ARPA
  2025. From: prindle@AMSAA.ARPA
  2026. MMDF-Warning:  Parse error in preceding line at AMSAA.ARPA
  2027. To: kpetersen@SIMTEL20.ARPA
  2028. Subject:   Uncrunching on UNIX etc. here at last
  2029. ReSent-From: KPETERSEN@SIMTEL20.ARPA
  2030. ReSent-To: Info-Cpm@AMSAA.ARPA
  2031. ReSent-Date: Fri 19 Dec 1986 21:41-MST
  2032.  
  2033. I've just transferred a copy of what I consider to be a first release
  2034. of UNCR.C to simtel20.
  2035.  
  2036. Filename            Type     Bytes     CRC
  2037.  
  2038. Directory PD:<UNIX.CPM>
  2039. UNCR231.C.1            ASCII     12651  0052H
  2040.  
  2041. It is portable enough to compile and execute ok on an 8-bit CP/M system,
  2042. though about 2.5 times slower than the real UNCR 2.3.  So it's major
  2043. application is uncrunching on the host (UNIX, VMS, TOPS-20 ...)
  2044. systems.  I've tested it through all it's major paths on a Sun-3, a
  2045. VAX-11/780, and the C-128 CP/M.  Here is an abstract:
  2046.  
  2047. UNCR231.C is a C language implementation of the LZW decompression
  2048. algorithm utilized by Steven Greenberg's Z-80 CP/M program UNCR
  2049. Version 2.3 (from PD:<CPM.SQUSQ>CRUNCH23.LBR).  This program will
  2050. decompress (uncrunch) any file written with CRUNCH 2.x, although it
  2051. will not work with files written by CRUNCH 1.x (an earlier algorithm).
  2052. The only requirements placed on the C compiler used are that it
  2053. support a long type of at least 4 bytes (actually 21 bits will do),
  2054. and that it will read and write files in binary (no newline or ^Z
  2055. translation) using getc()/putc() when the files have been opened with
  2056. mode "rb"/"wb".  This is absolutely the case for UNIX on 32 bit
  2057. machines, but may require some coaxing on other systems, particularly
  2058. CP/M and MSDOS compilers.  Note that UNCR231.C is not recommended for
  2059. use on z-80 CP/M systems, since the real thing is over twice as fast;
  2060. rather it is meant to fill the gap and allow these "crunched" files to
  2061. be recovered on more powerful systems where speed is not an issue.
  2062. Usage is just:
  2063.  
  2064. $ uncr <filename> [<another filename> ...]
  2065.  
  2066. If your shell or O.S. does wildcard expansion, by all means use that.
  2067. Files not in "crunched" format will be skipped.  The decompressed
  2068. files will have the names of the original CP/M files (in lower case if
  2069. that is significant on your system).  This program follows in the
  2070. footsteps of usq.c and lar.c in attempting to provide a portable
  2071. implentation of a popular algorithm.
  2072.  
  2073. Sincerely,
  2074. Frank Prindle
  2075. Prindle@NADC.arpa
  2076. 22-Dec-86 00:09:14-MST,1138;000000000000
  2077. Return-Path: <info-cpm-request@AMSAA.ARPA>
  2078. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Mon 22 Dec 86 00:08:49-MST
  2079. Received: from simtel20.arpa by AMSAA.ARPA id a008269; 22 Dec 86 1:32 EST
  2080. Date: Sun 21 Dec 86 23:26:11-MST
  2081. From: "Frank J. Wancho" <WANCHO@SIMTEL20.ARPA>
  2082. Subject: New SIG/M releases now available on SIMTEL20.ARPA
  2083. To: INFO-CPM@AMSAA.ARPA
  2084. Message-ID: <12264739487.6.WANCHO@SIMTEL20.ARPA>
  2085.  
  2086. Keith Petersen has just finished uploading the latest releases
  2087. of the SIG/M volumes 282 through 294, plus a new 000.  A new
  2088. master SIGM:SIGM.CRCLST will be available by Monday morning.
  2089.  
  2090. The SIG/M releases are made available as-is, with the usual
  2091. disclaimers.  We take no responsibility and perform no censor
  2092. role in providing these volumes.  In other words, use these
  2093. files and programs at your own risk, but let us know if there
  2094. are problems, such as missing or broken files, or mismatched
  2095. CRCs.  Complaints about functionality or lack thereof should
  2096. be directed to SIG/M, keeping in mind that they are strictly
  2097. a volunteer and definitely not-for-profit organization.
  2098.  
  2099. --Frank
  2100. -------
  2101. 22-Dec-86 08:00:50-MST,1378;000000000000
  2102. Return-Path: <info-cpm-request@AMSAA.ARPA>
  2103. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Mon 22 Dec 86 08:00:40-MST
  2104. Received: from decwrl.dec.com by AMSAA.ARPA id a013235; 22 Dec 86 9:30 EST
  2105. Received: from rhea.dec.com by decwrl.dec.com (5.54.3/4.7.34)
  2106.     id AA01941; Mon, 22 Dec 86 06:29:22 PST
  2107. Message-Id: <8612221429.AA01941@decwrl.dec.com>
  2108. Date: 22-Dec-1986 0839
  2109. From: NOW willya gimme some fightin' room? <binder%fizbin.DEC@decwrl.dec.com>
  2110. To: info-cpm@AMSAA.ARPA, infocpm%fizbin.DEC@decwrl.dec.com
  2111. Subject: Looking for a book on CP/M interfacing
  2112.  
  2113. I'd like to write an application program or two and am looking for a book that 
  2114. will provide concise and complete information on using CP/M system services 
  2115. (BIOS calls).  My MicroPro StarCard came with "The CP/M Primer," by Murtha and
  2116. Waite, but there's very little *really* useful info there.  For $2.00 I bought
  2117. a remaindered book called "A Practical Guide to CP/M" which isn't all that 
  2118. useful, either.  What I need is specific information on what the register
  2119. contents should be on entry and exit, where the byte count is returned on a
  2120. console read, what anomalous results can occur, etc. 
  2121.  
  2122. Thanks in advance,
  2123. Dick Binder   (The Stainless Steel Rat)
  2124.  
  2125. DEC Enet:    ASD::BINDER
  2126. UUCP:        { decvax, allegra, ucbvax... }!decwrl!asd.dec.com!binder
  2127. ARPA:        binder%asd.DEC@decwrl.ARPA
  2128. 22-Dec-86 13:05:21-MST,1492;000000000000
  2129. Return-Path: <info-cpm-request@AMSAA.ARPA>
  2130. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Mon 22 Dec 86 13:05:12-MST
  2131. Received: from seismo.css.gov by AMSAA.ARPA id a021157; 22 Dec 86 14:21 EST
  2132. Received: from scubed.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP 
  2133.     id AA05848; Mon, 22 Dec 86 14:20:49 EST
  2134. Received: by scubed (4.12/5.20b)
  2135.     id AA17492; Thu, 18 Dec 86 00:23:54 pst
  2136. Received: by sdcsvax.UCSD.EDU (5.57/4.42)
  2137.     id AA13913; Wed, 17 Dec 86 22:46:47 PST hops=0
  2138. Received: by sdchema.chem.ucsd.edu (5.44)
  2139.     id AA02255; Wed, 17 Dec 86 22:45:36 PST
  2140. Received: by crash.UUCP (5.9/UUCP-Project/rel-1.0/09-14-86)
  2141.     id AA05092; Wed, 17 Dec 86 21:56:34 PST
  2142. Message-Id: <8612180556.AA05092@crash.UUCP>
  2143. Date: Wed, 17 Dec 86 21:47:58 PST
  2144. From: Marc Wilson <scubed!sdcsvax!pnet01.UCSD.EDU!mwilson@seismo.css.gov>
  2145. To: crash!info-cpm@AMSAA.ARPA
  2146. Subject: VDO25 screen problems
  2147.  
  2148.      Does anyone out there have a solution to VDO's annoying beep?  I have
  2149. discovered that it's caused by an illegal cursor motion command being sent to
  2150. my terminal, but I haven't found a way to fix it.  Is there a fix, or do I
  2151. just have to live with it?
  2152.  
  2153.      In the same vein, WordStar 3.30 has the same problem.  Every time W* puts
  2154. up the "WAIT" message, the next control code output is invalid.
  2155.  
  2156.      The only solution I have found so far is to disable the speaker on my
  2157. terminal, but I'm not too enthusiastic about that.
  2158.  
  2159. --Marc Wilson
  2160. crash!pnet01!mwilson@nosc.ARPA
  2161. 22-Dec-86 14:30:58-MST,1494;000000000000
  2162. Return-Path: <info-cpm-request@AMSAA.ARPA>
  2163. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Mon 22 Dec 86 14:30:50-MST
  2164. Received: from seismo.css.gov by AMSAA.ARPA id a024739; 22 Dec 86 16:00 EST
  2165. Received: from scubed.UUCP by seismo.CSS.GOV (5.54/1.14) with UUCP 
  2166.     id AA08094; Mon, 22 Dec 86 16:00:11 EST
  2167. Received: by scubed (4.12/5.20b)
  2168.     id AA03153; Sat, 20 Dec 86 06:01:22 pst
  2169. Received: by sdcsvax.UCSD.EDU (5.57/4.42)
  2170.     id AA10610; Sat, 20 Dec 86 01:19:52 PST hops=0
  2171. Received: by sdchema.chem.ucsd.edu (5.44)
  2172.     id AA19815; Sat, 20 Dec 86 01:18:44 PST
  2173. Received: by crash.UUCP (5.9/UUCP-Project/rel-1.0/09-14-86)
  2174.     id AA16736; Sat, 20 Dec 86 00:36:39 PST
  2175. Message-Id: <8612200836.AA16736@crash.UUCP>
  2176. Date: Sat, 20 Dec 86 00:35:02 PST
  2177. From: Marc Wilson <scubed!sdcsvax!pnet01.UCSD.EDU!mwilson@seismo.css.gov>
  2178. To: crash!info-cpm@AMSAA.ARPA
  2179. Subject: VDO25 screen problems
  2180.  
  2181.      Does anyone out there have a solution to VDO's annoying beep?  I have
  2182. discovered that it's caused by an illegal cursor motion command being sent to
  2183. my terminal, but I haven't found a way to fix it.  Is there a fix, or do I
  2184. just have to live with it?
  2185.  
  2186.      In the same vein, WordStar 3.30 has the same problem.  Every time W* puts
  2187. up the "WAIT" message, the next control code output is invalid.
  2188.  
  2189.      The only solution I have found so far is to disable the speaker on my
  2190. terminal, but I'm not too enthusiastic about that.
  2191.  
  2192. --Marc Wilson
  2193. crash!pnet01!mwilson@nosc.ARPA
  2194.  
  2195. 23-Dec-86 06:44:53-MST,833;000000000000
  2196. Return-Path: <info-cpm-request@AMSAA.ARPA>
  2197. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Tue 23 Dec 86 06:44:46-MST
  2198. Received: from simtel20.arpa by AMSAA.ARPA id a028960; 23 Dec 86 8:18 EST
  2199. Date: Tue, 23 Dec 1986  06:17 MST
  2200. Message-ID: <KPETERSEN.12265076436.BABYL@SIMTEL20.ARPA>
  2201. Sender: KPETERSEN@SIMTEL20.ARPA
  2202. From: Keith Petersen <W8SDZ@SIMTEL20.ARPA>
  2203. To:   Info-Cpm@AMSAA.ARPA
  2204. Subject: Looking for a book on CP/M interfacing
  2205.  
  2206. > I'd like to write an application program or two and am looking for a
  2207. > book that will provide concise and complete information on using CP/M
  2208. > system services (BIOS calls).
  2209.  
  2210. Take a look at...
  2211.  
  2212. Filename            Type     Bytes     CRC
  2213.  
  2214. Directory PD:<CPM.CPMINFO>
  2215. EASYBDOS.LBR.1            BINARY     96256  9C5DH
  2216.  
  2217. It's a complete tutoral on the use of CP/M BDOS calls.
  2218.  
  2219. --Keith
  2220. 24-Dec-86 10:00:42-MST,1525;000000000000
  2221. Return-Path: <info-cpm-request@AMSAA.ARPA>
  2222. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Wed 24 Dec 86 10:00:21-MST
  2223. Received: from acc.arpa by AMSAA.ARPA id a003852; 24 Dec 86 11:24 EST
  2224. Date: 24 Dec 86 08:17:00 PST
  2225. From: shawn@ACC.ARPA
  2226. MMDF-Warning:  Parse error in preceding line at AMSAA.ARPA
  2227. Subject: help to filter text to printer
  2228. To: info-cpm <info-cpm@AMSAA.ARPA>
  2229. cc: shawn@ACC.ARPA
  2230. Reply-To: shawn@ACC.ARPA
  2231. MMDF-Warning:  Parse error in preceding line at AMSAA.ARPA
  2232.  
  2233. I'm aware of, and have seen Smart Key II in use.
  2234. I am very interested in its companion program,
  2235. Smart Print. I need a filter between the output
  2236. of a word processor, and a letter quality printer.
  2237. The problem is that I need to do foreign language
  2238. text processing such as the ' over another character,
  2239. the umlaut etc. This requires that the printer
  2240. strike, backspace, and strike again. Neat trick, except
  2241. that the word processor will count this as three
  2242. characters, and justify accordingly. I hope to find
  2243. a public domain 'filter' that will recognize an otherwise
  2244. unused chacachter such as ] or [ and substitute the
  2245. appropriate strike, backspace, strike sequence.
  2246. Anyone had to 'deal' with this problem?
  2247. And /or know of an existing program that will
  2248. filter the text for me? Any help will be much
  2249. apppreciated.
  2250.  
  2251.  
  2252.  
  2253.     Thanks in advance
  2254.     Shawn Miner
  2255.     (Advanced Computer Communications)
  2256.     (Santa Barbara, Ca.)
  2257.     shawn@acc.arpa
  2258.  
  2259. p.s. Happy Hollidays to all from sunny Southern California.
  2260.  
  2261. ------
  2262. 24-Dec-86 18:47:11-MST,865;000000000000
  2263. Return-Path: <info-cpm-request@AMSAA.ARPA>
  2264. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Wed 24 Dec 86 18:47:06-MST
  2265. Received: from simtel20.arpa by AMSAA.ARPA id a009180; 24 Dec 86 20:16 EST
  2266. Date: Wed, 24 Dec 1986  18:15 MST
  2267. Message-ID: <KPETERSEN.12265469349.BABYL@SIMTEL20.ARPA>
  2268. Sender: KPETERSEN@SIMTEL20.ARPA
  2269. From: Keith Petersen <W8SDZ@SIMTEL20.ARPA>
  2270. To:   SINGPANG%HLERUL5.BITNET@wiscvm.ARPA
  2271. Cc:   Info-Cpm@AMSAA.ARPA
  2272. Subject: problems with rsa lbr in sigm vol.202
  2273. In-reply-to: Msg of 18 Dec 1986  16:40-MST from SINGPANG%HLERUL5.BITNET at WISCVM.WISC.EDU
  2274.  
  2275. There is a newer version of RSA available in:
  2276.  
  2277. Filename            Type     Bytes     CRC
  2278.  
  2279. Directory PD:<CPM.PUBKEY>
  2280. RSA13-T.LBR.1            BINARY    104448  2ED5H
  2281.  
  2282. I believe there were some bug fixes and also there are quite a few
  2283. more support and demonstration files.
  2284.  
  2285. --Keith
  2286. 24-Dec-86 19:44:57-MST,7292;000000000000
  2287. Return-Path: <info-cpm-request@AMSAA.ARPA>
  2288. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Wed 24 Dec 86 19:44:34-MST
  2289. Date:     Wed, 24 Dec 86 21:24:49 EST
  2290. From:     Dave Towson (info-cpm-request) <cpmlist@AMSAA.ARPA>
  2291. To:       info-cpm@AMSAA.ARPA
  2292. Subject:  Useful new product for CP/M and some related operating systems:
  2293.  
  2294. Fellow CP/Mers - In keeping with my periodically announced policy (copy sent
  2295. upon request) of posting announcements of new commercial products that are of
  2296. general interest to the CP/M community, here is a description of a software
  2297. product from Plu*Perfect Systems that adds to CP/M the ability to switch back
  2298. and forth between two active tasks without losing the current status of
  2299. either. This feature is one that I have come to dearly love as a regular user
  2300. of the UNIX operating system.  Quite often, I find that while involved with
  2301. one task I need information from another.  For example, when answering
  2302. correspondence I frequently need to refer to the message to which I am
  2303. responding.  If I know from the start that I will need to do that, I use the
  2304. two-window mode of our message program; but if I find out too late, it is
  2305. extremely handy to be able to suspend the editor job and go back and read the
  2306. message.  Other scenarios are more likely for the CP/M environment, but the
  2307. one just given was the first to come to mind.  The new product, known as
  2308. "BackGrounder ii", also provides a print spooler and a number of additional
  2309. functions that appear to be quite useful.
  2310.  
  2311.      A demonstration version is available from the SIMTEL20 archives in file:
  2312.  
  2313.                PD:<CPM.BKGROUNDER>BGIIDEMO.LBR
  2314.  
  2315. It includes all BGii features, but is restricted to drive A: and lacks the
  2316. spooler and other utilities.  Patches for WordStar 3.0 and 3.3 that redraw the
  2317. screen in response to a control-backslash are also provided so that the user
  2318. can see the text he is editing after he returns to a suspended editor task.
  2319. However, these patches do not require the BackGrounder product, and appear to
  2320. be generally useful (I tried the one for WS 3.3, and it worked fine on a
  2321. TurboDOS computer without BGii).  The files in the demo library have been
  2322. compressed using the CRUNCH utility (which, by the way is rather impressive in
  2323. its ability to achieve compression factors in excess of two-to-one).  A copy
  2324. of the uncruncher is included in the library, but it did not operate properly
  2325. on the TurboDOS system on which I tried it.  Fortunately, the fix was
  2326. available from the archives:  File:
  2327.  
  2328.              PD:<CPM.SQUSQ>CRUNCH23.LBR
  2329.  
  2330. contains a complete CRUNCH package including the cruncher, uncruncher,
  2331. documentation and a note describing how to patch the cruncher and uncruncher
  2332. so that they will work correctly under TurboDOS.
  2333.  
  2334.      Before attempting to use the demonstration software, users are urged to
  2335. read the following files from the library:
  2336.  
  2337.         -CRUNCH.NOT for uncrunching instructions
  2338.         BGIIDEMO.DOC for summary of features and files
  2339.         DINSTALL.PRN for detailed installation steps
  2340.  
  2341.      The complete BGii system, with printed and indexed user's manual, can be
  2342. obtained from Plu*Perfect Systems, Box 1494, Idyllwild CA 92349.  The price
  2343. is:
  2344.              $75 + 6% in California + $3 shipping.
  2345.  
  2346. Other sources are listed in the documentation.
  2347.  
  2348.      The following information has been provided by the vendor, and I have no
  2349. personal experience with the product.  Additional information can be requested
  2350. from the author at the following address:
  2351.  
  2352.               bridger@rand-unix.arpa
  2353.  
  2354. Persons submitting such inquiries are invited to send copies of their corres-
  2355. pondence to info-cpm if the subject matter is of general interest.  Purely
  2356. personal matters should be discussed privately.
  2357.  
  2358.  
  2359.  
  2360. Dave Towson <info-cpm-request@amsaa.arpa>
  2361. info-cpm list maintainer
  2362.  
  2363. ------------------------------------------------------------------------------
  2364.  
  2365.  
  2366.                   BackGrounder ii
  2367.  
  2368.  
  2369.                    MAJOR FEATURES
  2370.  
  2371.  
  2372. TASK SWITCHING
  2373.  
  2374.       On user command, switch between two active programs, each with full
  2375. memory.
  2376.  
  2377.  
  2378. BACKGROUND COMMANDS
  2379.  
  2380.       Run built-in BackGrounder ii commands from within an active program,
  2381. as well as at CP/M prompt:
  2382.  
  2383.       bg     calc  cls   cut     date  dir    echo  era     feed  find  forms
  2384.       flip   go    get   help    jot   jump   keys  list    ndr   note  ocp
  2385.       paste  peek  poke  printr  ren   reset  save  screen  shift
  2386.       spool  swap  time  type    user  whl    whlq
  2387.  
  2388. Supports ZCPR3 syntax: DU:filename.typ, named-directory, multiple-command
  2389. line.
  2390.  
  2391.  
  2392. BACKGROUND LIST SPOOLING AND PRINTING
  2393.  
  2394.      Redirect list output to file.  Print files from a queue while running
  2395. programs.
  2396.  
  2397.  
  2398. CUT-AND-PASTE
  2399.  
  2400.      Transfer screen region to notepad, another program, or printer (requires
  2401. screendriver).
  2402.  
  2403.  
  2404. KEYBOARD MACROS
  2405.  
  2406.      Pre-defined, on-the-fly, and record-keystroke capability, both global
  2407. and program-specific.   Load and save macros within a program.
  2408.  
  2409.  
  2410. EXTENSIBLE COMMANDS
  2411.  
  2412.      Add customized, user-coded assembly-language foreground and background
  2413. commands.
  2414.  
  2415.  
  2416.                     REQUIREMENTS
  2417.  
  2418. NECESSARY
  2419.  
  2420.      Z80 or equivalent CPU, standard CP/M 2.2 BDOS, or ZRDOS v. 1.1, 1.2, 1.3,
  2421. or 1.7.
  2422.  
  2423.  
  2424. RECOMMENDED
  2425.  
  2426.      Ram-disk or hard-disk.
  2427.  
  2428.  
  2429. DESIRABLE
  2430.  
  2431.      Video-mapped memory, or terminal with transmit-character or transmit-
  2432. region function.
  2433.  
  2434.  
  2435. MEMORY AND DISK SPACE
  2436.  
  2437.      Standard system: 2.75K memory + 2K of CCP space.
  2438.  
  2439.      ZCPR3 system:    0.25K memory + 2K of CCP space, if RCP and IOP are
  2440.                       reclaimed.
  2441.  
  2442.      100K swap file.
  2443.  
  2444.  
  2445.                 COMPATIBILITY
  2446.  
  2447.      Runs all CP/M 2.2 programs that adhere to CP/M addressing standards,
  2448. subject to above memory limit.
  2449.  
  2450.      Supports all ZCPR3 external environment buffers, including task-specific
  2451. shells.
  2452.  
  2453.      Unspooling may drop keyboard characters if the BIOS lacks a type-ahead
  2454. buffer.
  2455.  
  2456.  
  2457.                  PERFORMANCE
  2458.  
  2459.      BGii uses a pre-allocated disk file as virtual memory for overlays and
  2460. task-switching buffers.  Ram-disks work best, and tuned hard-disks are also
  2461. effective.  On floppy-disk systems, BGii can be used well as an extended
  2462. command processor for one task; however, task-switching is too slow to be
  2463. used as a regular floppy feature.
  2464.  
  2465.      Representative 58-60K tpa swap times:
  2466.  
  2467.     SB180       6 Mhz    ram disk            < 1 sec
  2468.     Kaypro 10    4 Mhz    Advent ram disk            < 2 secs
  2469.     Kaypro 10    4 Mhz    Turborom, hard disk, 1K sectors      4 secs
  2470.     Kaypro  2    5 Mhz    Turborom, DSDD 1K floppy    ~20 secs
  2471.  
  2472.  
  2473.              SCREEN-RELATED FEATURES
  2474.  
  2475.      BGii uses optional terminal-specific screendrivers to save and restore
  2476. the working screen and to implement cut-and-paste, notepad, and screen-dump
  2477. commands.  Screendrivers are available for Kaypro '83, Kaypro '84, and
  2478. Heath/Zenith 19 computers/terminals.  ASM source code and documentation for
  2479. these drivers permits modification for other terminals that have a transmit-
  2480. character or transmit-region function.
  2481.  
  2482.      If no screendriver is installed, BGii can send a user-defined macro
  2483. to the running program to cause it to redraw the screen, if it has that
  2484. capability.  Patches to add this feature to WordStar v 3.0 and 3.3 are
  2485. included.
  2486.  
  2487. ------------------------------------------------------------------------------
  2488.  
  2489. 26-Dec-86 13:09:52-MST,1144;000000000000
  2490. Return-Path: <info-cpm-request@AMSAA.ARPA>
  2491. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Fri 26 Dec 86 13:09:45-MST
  2492. Received: from simtel20.arpa by AMSAA.ARPA id a014254; 26 Dec 86 14:36 EST
  2493. Date: Fri, 26 Dec 1986  12:34 MST
  2494. Message-ID: <KPETERSEN.12265931639.BABYL@SIMTEL20.ARPA>
  2495. Sender: KPETERSEN@SIMTEL20.ARPA
  2496. From: Keith Petersen <W8SDZ@SIMTEL20.ARPA>
  2497. To:   Info-Hams@SIMTEL20.ARPA
  2498. Cc:   Info-Cpm@AMSAA.ARPA, packet-radio@mit-eddie.ARPA
  2499. Subject: Need to contact Mike Mosko K3RL
  2500.  
  2501. In January 1984 Ed Mosko, K3RL, wrote a CP/M program called EDFILE.
  2502. It has since become very popular.
  2503.  
  2504. I'd like to contact Mike regarding some questions I have and to see if
  2505. there have been any updates since the original release.  I have his
  2506. address from the program documentation but no phone number was
  2507. included.  He lives in Coopersburg, PA.
  2508.  
  2509. Is Mike reachable on the net, or does anyone have his phone number?
  2510.  
  2511. 73,
  2512. --Keith Petersen
  2513. Arpa: W8SDZ@SIMTEL20.ARPA
  2514. Uucp: {bellcore,decwrl,harvard,lll-crg,ucbvax,uw-beaver}!simtel20.arpa!w8sdz
  2515. GEnie Mail: W8SDZ
  2516. RCP/M Royal Oak: 313-759-6569 (300, 1200, 2400 bps)
  2517. 27-Dec-86 10:50:42-MST,1466;000000000000
  2518. Return-Path: <info-cpm-request@AMSAA.ARPA>
  2519. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Sat 27 Dec 86 10:50:37-MST
  2520. Received: from brl-adm.arpa by AMSAA.ARPA id a019220; 27 Dec 86 12:19 EST
  2521. Received: from USENET by ADM.BRL.ARPA id aa17532; 27 Dec 86 12:08 EST
  2522. From: klieb@uicsl.uucp
  2523. Newsgroups: comp.os.cpm
  2524. Subject: Re: N*/Z80 Interrupt Drivers
  2525. Message-ID: <363900001@uicsl>
  2526. Date: 19 Dec 86 18:46:00 GMT
  2527. Nf-ID: #N:uicsl:363900001:000:892
  2528. Nf-From: uicsl.UUCP!klieb    Dec 19 12:46:00 1986
  2529. To:       info-cpm@AMSAA.ARPA
  2530.  
  2531.  
  2532. There is an excellent series of application notes regarding Z80 interrupts
  2533. and asynchronous communications in Zilog's "Microprocessor Applications
  2534. Reference Book, Volume 1." There are two in-depth articles on asynchronous
  2535. applications of the DART/SIO, as well as a good article on synchronous SIO
  2536. programming. In addition, there are several other articles that deal with
  2537. interrupt-driven use of the CTC, etc. Each article includes commented
  2538. assembly language code.
  2539.  
  2540. You should be able to obtain a copy of this book from Zilog Sales and
  2541. Technical Center, 10340 Bubb Road, Cupertino, CA 95014. Their phone number
  2542. is (408) 446-9848. These books were often given free of charge to designers
  2543. using the Z80, so perhaps Zilog will sell one for a nominal cost.
  2544.  
  2545.                                                Kurt Liebezeit
  2546.                                               ...!ihnp4!uiucdcs!uicsl!klieb
  2547. 27-Dec-86 12:43:05-MST,2362;000000000000
  2548. Return-Path: <info-cpm-request@AMSAA.ARPA>
  2549. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Sat 27 Dec 86 12:42:55-MST
  2550. Received: from simtel20.arpa by AMSAA.ARPA id a025421; 27 Dec 86 14:19 EST
  2551. Date: Sat, 27 Dec 1986  12:18 MST
  2552. Message-ID: <KPETERSEN.12266190737.BABYL@SIMTEL20.ARPA>
  2553. Sender: KPETERSEN@SIMTEL20.ARPA
  2554. From: Keith Petersen <W8SDZ@SIMTEL20.ARPA>
  2555. To:   Info-Cpm@AMSAA.ARPA
  2556. Subject: Quick reference list to SIMTEL20's CP/M directories
  2557.  
  2558. Quick reference list to SIMTEL20's PD:<CPM.x> directories
  2559. as of December 27, 1986 (where 'x' is one of the names below):
  2560.  
  2561. 22RSX         CBIOS         FILCPY        MEX           SCREENGEN
  2562. 6502          CCP           FILE-DOCS     MICNET        SMALLC21
  2563. AMETHYST      COBOL         FILUTL        MISC          SORT
  2564. APPLE         COMND         FINANCE       MODEM         SPELL
  2565. ARC-LBR       CPM3          FORTH-83      MODEM2        SPREADSHEET
  2566. ASMUTL        CPM68K        FORTRAN       MODEM7        SQUSQ
  2567. ATARI         CPM86         GENASM        MSOFT         STARTER-KIT
  2568. AZTEC-C       CPMINFO       GENCOM        NEWS          SUBMIT
  2569. BASIC         CPR86         GENDOC        NSTAR         SYSUTL
  2570. BBS           CUG           GENIE         NUBYE         TERM
  2571. BBSLISTS      DATABASE      GRAPHICS      OSBORN        TRS-80
  2572. BDOS          DBASEII       HAMMING       PACKET        TURBODOS
  2573. BDSC-1        DEBUG         HAMRADIO      PARASOL       TURBODOS-SIGI
  2574. BDSC-2        DIRUTL        HDUTL         PASCAL        TURBOPAS
  2575. BDSC-3        DISASM        HEATH         PBBS          TXTUTL
  2576. BDSC-4        DISKPLOT      HELP          PILOT80       VDOEDIT
  2577. BKGROUNDER    DRACO         HEX           PLOT33        VOICE
  2578. BSTAM         DSKBUF        IMP           PPSPEL        WSTAR
  2579. BYE3          DSKUTL        INSIDCPM      PROLOG        XCCP
  2580. BYE5          EDITC80       KAYPRO        PUBKEY        XLISP
  2581. C128          EDITOR        LIST          PUBPATCH      Z8EDEBUG
  2582. C64           EDUCATION     MACLIB        RBBS          ZCPR
  2583. C80           EMX           MATH          RBBS4         ZCPR2
  2584. CATLOG        EPSON         MBBS          RCPM          ZCPR3
  2585. CB80          FAST2         MEMTEST       ROS
  2586.  
  2587. PD:<CPM>CPM.CRCLST on SIMTEL20 (the file listing all the filenames,
  2588. sizes and CRCs of the PD:<CPM.xx> directories) has been updated as
  2589. of today.
  2590.  
  2591. --Keith
  2592. 28-Dec-86 11:26:37-MST,2684;000000000000
  2593. Return-Path: <info-cpm-request@AMSAA.ARPA>
  2594. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Sun 28 Dec 86 11:26:29-MST
  2595. Received: from decwrl.dec.com by AMSAA.ARPA id a015545; 28 Dec 86 12:58 EST
  2596. Received: from rhea.dec.com by decwrl.dec.com (5.54.3/4.7.34)
  2597.     id AA23694; Sun, 28 Dec 86 09:57:15 PST
  2598. Message-Id: <8612281757.AA23694@decwrl.dec.com>
  2599. Date: 28-Dec-1986 1237
  2600. From: Sold - but we have others <binder%fizbin.DEC@decwrl.dec.com>
  2601. To: info-cpm@AMSAA.ARPA, Shawn@ACC.ARPA, infocpm%fizbin.DEC@decwrl.dec.com
  2602. Subject: Re: Printer filter
  2603.  
  2604. Shawn Miner asks:
  2605.  
  2606. > ...I need a filter between the output of a word processor, and a letter
  2607. > quality printer.  The problem is that I need to do foreign language text
  2608. > processing such as the ' over another character, the umlaut etc.  This
  2609. > requires that the printer strike, backspace, and strike again.  Neat trick,
  2610. > except that the word processor will count this as three characters, and
  2611. > justify accordingly...Anyone had to 'deal' with this problem?  And /or know
  2612. > of an existing program that will filter the text for me?  Any help will be
  2613. > much apppreciated. 
  2614.  
  2615. I do what you're talking about frequently - probably on a daily basis.  A
  2616. simple filter may be a cheap way to deal with your problem, but it's a
  2617. band-aid, and it is guaranteed to get in your way more than it helps out. 
  2618. What you might think about instead is investing in a better word processor. 
  2619.  
  2620. A good word processor will *not* count a char-<BS>-char sequence as three 
  2621. characters and misjustify the output.  I use WordStar, and WS handles this
  2622. function quite well.  In the WS installation sequence, you can tell WS about 
  2623. your printer:
  2624.  
  2625. a.  Backspacing printer - able to backspace and overstrike the same character
  2626.  
  2627. b.  Non-backspacing printer - print the entire line and issue <CR> without
  2628.     accompanying <LF>, then restrike all overstruck character positions on
  2629.     the line
  2630.  
  2631. When editing, you enter the backspace command the same way regardless of how 
  2632. your printer is installed, and WS figures out how to print things.
  2633.  
  2634. WordStar is disgustingly cheap at present, at least in its IBM or Apple CP/M 
  2635. incarnations - something like $120 will get you WS Professional, which 
  2636. includes Spellstar, MailMerge, and StarIndex.  Sure, there are *nicer* WP 
  2637. packages available now, but WS is still about the most powerful one around.
  2638. If WS isn't to your liking, try some of the other good WPs, such as Paper 
  2639. Clip or WordPerfect.
  2640.  
  2641. Cheers,
  2642. Dick Binder   (The Stainless Steel Rat)
  2643.  
  2644. DEC Enet:    ASD::BINDER
  2645. UUCP:        { decvax, allegra, ucbvax... }!decwrl!asd.dec.com!binder
  2646. ARPA:        binder%asd.DEC@decwrl.ARPA
  2647. 28-Dec-86 13:45:42-MST,1741;000000000000
  2648. Return-Path: <info-cpm-request@AMSAA.ARPA>
  2649. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Sun 28 Dec 86 13:45:34-MST
  2650. Received: from simtel20.arpa by AMSAA.ARPA id a015707; 28 Dec 86 15:22 EST
  2651. Date: Sunday, 28 December 1986  10:28-MST
  2652. Message-ID: <KPETERSEN.12266464517.BABYL@SIMTEL20.ARPA>
  2653. Sender: Walt Lamia <LAMIA@dec-marlboro.ARPA>
  2654. From: Walt Lamia <LAMIA@dec-marlboro.ARPA>
  2655. To: w8sdz@SIMTEL20.ARPA
  2656. Subject:   Modified version of VMSSWEEP.FOR available
  2657. ReSent-From: KPETERSEN@SIMTEL20.ARPA
  2658. ReSent-To: Info-Cpm@AMSAA.ARPA, Info-Micro@BRL.ARPA
  2659. ReSent-Date: Sun 28 Dec 1986 13:22-MST
  2660.  
  2661. Now available from SIMTEL20...
  2662.  
  2663. Filename            Type     Bytes     CRC
  2664.  
  2665. Directory PD:<MISC.VAXVMS>
  2666. VMSSWEEP.FOR.28            ASCII     53386  ED78H
  2667.  
  2668. I have modified V2.7 of VMSSWEEP to extend the EXTRACT and VIEW
  2669. functions to process all of the members of library.  It does this by
  2670. accepting at the member number prompt a number greater than the
  2671. maximum number of members, and interpreting this as "all members".
  2672. The prompt indicates this option by suggesting "(9999 for all)".
  2673.  
  2674. It also fixes a problem in which unacceptable VMS file names were
  2675. generated if the member names had the 8th bit set.  I don't know how
  2676. such libraries got created in the first place, but this version strips
  2677. 8th bits off of the file names.
  2678.  
  2679. This version does NOT correctly handle members CRUNCHed with the
  2680. latest LZW algorithm, which typically have names of the form "*.?Z?".
  2681. VMSSWEEP will hang on these files.
  2682.  
  2683. Incidentally, V2.7 corrected the problem with some .ARC libraries
  2684. which caused older versions to report CRC errors.  This showed up in
  2685. the DRACO libraries.
  2686.  
  2687. I have taken the liberty of naming this version V2.8.
  2688.  
  2689. Walt Lamia
  2690. 28-Dec-86 18:32:50-MST,999;000000000000
  2691. Return-Path: <info-cpm-request@AMSAA.ARPA>
  2692. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Sun 28 Dec 86 18:32:42-MST
  2693. Received: from usc-isi.arpa by AMSAA.ARPA id a016108; 28 Dec 86 20:11 EST
  2694. Date: 28 Dec 1986 20:09:02 EST
  2695. Subject: Mail Order houses
  2696. From: Rex Buddenberg <BUDDENBERGRA@usc-isi.ARPA>
  2697. To: info-cpm@AMSAA.ARPA
  2698. cc: BUDDENBERGRA@usc-isi.ARPA
  2699.  
  2700. Since this seems to be a good place to grapevine along reputations...
  2701. I've dealt with JDR Microdevices over several years with uniformly good
  2702. service.  They advertise in the usual places (e.g.Byte).  
  2703.  
  2704. Just invested in a hard disc which arrived a week after order (coast to
  2705. coast and Christmas eve no less) and worked perfectly on installation.
  2706. When I phoned in the order, they found my name in the address database
  2707. (even though it had been almost a year since last order), updated
  2708. the address and got with the hardware.
  2709.  
  2710. Hardware house only -- no software to speak of.  
  2711. Satisfied customer.
  2712. -------
  2713. 29-Dec-86 05:43:33-MST,617;000000000000
  2714. Return-Path: <info-cpm-request@AMSAA.ARPA>
  2715. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Mon 29 Dec 86 05:43:28-MST
  2716. Received: from dockmaster.arpa by AMSAA.ARPA id a017202; 29 Dec 86 7:10 EST
  2717. Date:  Fri, 26 Dec 86 20:28 EST
  2718. From:  "Paul E. Woodie" <Woodie@DOCKMASTER.ARPA>
  2719. Subject:  Osborn screen movement commands
  2720. To:  info-cpm@AMSAA.ARPA
  2721. Message-ID:  <861227012856.123369@DOCKMASTER.ARPA>
  2722.  
  2723. Osborn(e) screen movement commands were designed to emulate the
  2724. Televideo 912/920 series of terminals.  I don't have info on other types
  2725. of pc's.
  2726.  
  2727. --Paul Woodie --(Woodie at dockmaster)
  2728. 29-Dec-86 07:12:53-MST,545;000000000000
  2729. Return-Path: <info-cpm-request@AMSAA.ARPA>
  2730. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Mon 29 Dec 86 07:12:44-MST
  2731. Received: from nadc.arpa by AMSAA.ARPA id a018697; 29 Dec 86 8:45 EST
  2732. Date: 29 Dec 1986 08:36:41-EST
  2733. From: halko@nadc.ARPA
  2734. To: Shawn@ACC.ARPA, binder@fizbin.dec, decwrl@nadc.ARPA, info-cpm@AMSAA.ARPA, 
  2735.     infocpm@fizbin.dec, decwrl.dec.com@nadc.ARPA
  2736. MMDF-Warning:  Parse error in preceding line at AMSAA.ARPA
  2737. Subject: Re: Printer filter
  2738.  
  2739. you should be able to turn off the justify option .
  2740.  
  2741. 29-Dec-86 08:51:44-MST,2718;000000000000
  2742. Return-Path: <info-cpm-request@AMSAA.ARPA>
  2743. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Mon 29 Dec 86 08:51:32-MST
  2744. Received: from decwrl.dec.com by AMSAA.ARPA id a021417; 29 Dec 86 10:23 EST
  2745. Received: from rhea.dec.com by decwrl.dec.com (5.54.3/4.7.34)
  2746.     id AA05693; Mon, 29 Dec 86 07:22:05 PST
  2747. Message-Id: <8612291522.AA05693@decwrl.dec.com>
  2748. Date: 29-Dec-1986 0908
  2749. From: Sold - but we have others <binder%fizbin.DEC@decwrl.dec.com>
  2750. To: info-cpm@AMSAA.ARPA, halko@NADC.ARPA, shawn@ACC.ARPA, 
  2751.     infocpm%fizbin.DEC@decwrl.dec.com
  2752. Subject: Re: Printer filter
  2753.  
  2754. halko@nadc.ARPA writes:
  2755.  
  2756. > you should be able to turn off the justify option .
  2757.  
  2758. This in response to my message to Shawn Miner in re: his query for a filter to
  2759. handle overstriking sequences via backspacing. 
  2760.  
  2761. True, you should be able to turn off the justify option.  With WordStar, and 
  2762. with most other good WPs, you can.  But turning off justification is not in
  2763. itself sufficient.  Consider the following nonsensical bit of French 
  2764. philosophy:
  2765.  
  2766.     Ca, c'est la boite noire de noel bien aimee qui doit rougir qu'on la
  2767.     connaitrait. 
  2768.  
  2769. (Rough translation, "That's the well-loved black Christmas box that must blush
  2770. so that it may be known."  Pardon the rust; I've had little opportunity to
  2771. speak French in the last 20 years.) 
  2772.  
  2773. This example, of course, lacks six diacritical marks that should be there. 
  2774. To print it with marks, by backspacing, requires twelve "extra" characters in
  2775. the text - with justification turned off, you'll get one awfully short line in
  2776. the middle of your text, or maybe two slightly short ones.  For drafts, and
  2777. for many other uses, that's okay.  But it's not acceptable if you're trying to
  2778. produce professional printed copy.  For that, you need justification.  A good
  2779. WP understands all this.  WordStar counts a <BS> and one following character
  2780. as no characters and thereby does not screw up the character count.  Justified
  2781. or not, the printed text will have lines as full as possible.  I surmise that 
  2782. other WPs are as intelligent.
  2783.  
  2784. Writing a filter to handle all the justification, character-counting, bolding, 
  2785. underscoring, line-overstriking, discretionary hyphenation, etc., that a truly
  2786. good WP does, seems to me a trifle in the line of far too much work for far
  2787. too little return, without even considering the hassle of using such a filter.
  2788. Such a filter defeats the purpose of a WP - why not just use ED and then run
  2789. the result through your filter??  No, thank you, not me.
  2790.  
  2791. Cheers,
  2792. Dick Binder   (The Stainless Steel Rat)
  2793.  
  2794. DEC Enet:    ASD::BINDER
  2795. UUCP:        { decvax, allegra, ucbvax... }!decwrl!asd.dec.com!binder
  2796. ARPA:        binder%asd.DEC@decwrl.ARPA
  2797. 29-Dec-86 16:01:31-MST,999;000000000000
  2798. Return-Path: <info-cpm-request@AMSAA.ARPA>
  2799. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Mon 29 Dec 86 16:01:17-MST
  2800. Received: from xerox.arpa by AMSAA.ARPA id a001587; 29 Dec 86 17:34 EST
  2801. Received: from Burger.ms by ArpaGateway.ms ; 29 DEC 86 10:24:57 PST
  2802. Sender: Thieret.WBST128@xerox.ARPA
  2803. Date: 29 Dec 86 10:24:26 PST (Monday)
  2804. Subject: S-100 Mother boards???
  2805. From: Thieret.WBST128@xerox.ARPA
  2806. To: info-cpm@AMSAA.ARPA
  2807. cc: thieret.WBST128@xerox.ARPA
  2808. Reply-to: Thieret.WBST128@xerox.ARPA
  2809. Message-ID: <861229-102457-2101@Xerox>
  2810.  
  2811. Folks:
  2812.  
  2813. My S-100 system is growing beyond the 10 slots which I have in my 
  2814. current system.  I've recently obtained a box which came sans 
  2815. (without) a motherboard.  I'm interested in a 20 slot board from 
  2816. CompuPro or other manufacturer.  If you have one lying around, 
  2817. please let me know and we can negotiate.
  2818.  
  2819. Please respond to me personally at 
  2820.  
  2821. Thieret.wbst128@Xerox.COM
  2822.  
  2823. and not to the whole list.
  2824.  
  2825. Thanks,
  2826.  
  2827. Tracy.
  2828. 29-Dec-86 22:27:22-MST,2779;000000000000
  2829. Return-Path: <info-cpm-request@AMSAA.ARPA>
  2830. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Mon 29 Dec 86 22:26:55-MST
  2831. Received: from brl-adm.arpa by AMSAA.ARPA id a002433; 29 Dec 86 23:52 EST
  2832. Received: from USENET by ADM.BRL.ARPA id aa04723; 29 Dec 86 23:48 EST
  2833. From: Gregory Smith <greg@utcsri.uucp>
  2834. Newsgroups: comp.os.cpm
  2835. Subject: Dualcase MACRO-80 Assembler Patch
  2836. Message-ID: <3841@utcsri.UUCP>
  2837. Date: 30 Dec 86 01:12:29 GMT
  2838. To:       info-cpm@AMSAA.ARPA
  2839.  
  2840. There was some demand for this, so here goes.
  2841.  
  2842. APPLICABILITY:
  2843.     Microsoft MACRO-80 assembler, version 3.44.
  2844.     The title of an assembler listing shows:
  2845.         MACRO-80 3.44   30-Mar-82
  2846.  
  2847. EFFECT:
  2848.     (1) upper and lower case in symbols become distinct. External
  2849.     symbols are passed to the linker L80 with their case intact.
  2850.     L80 and LIB80 don't seem to have any trouble with the lowercase
  2851.     letters. Macro names are also dualcase; you may define a macro
  2852.     'call' which does not conflict with the mnemonic CALL.
  2853.  
  2854.     (2) As a side-effect of (1), predefined symbols such as mnemonics,
  2855.     assembler directives, and register names must be in UPPER case.
  2856.  
  2857.     (3) The warning message '%No END statement' becomes '%No END'
  2858.     [ I had to get a few bytes from somewhere...]
  2859.  
  2860.     (4) WEIRDNESS:: The symbols are shoved into buckets based on their
  2861.     first letter. After the patch, 'FOOBAR' and 'frobozz' go into the
  2862.     same bucket. The problem is that the table lookup code assumes that
  2863.     each bucket contains symbols with the same initial letter, so
  2864.     'foobar' will conflict with 'Foobar'. I don't know whether this
  2865.     can be fixed. The initial letter *is* stored in the symbol table,
  2866.     since 'foobar' and 'Foobar' are both propogated intact into the
  2867.     object module (provided only one of the two is defined).
  2868.     L80 does not suffer from this problem.
  2869.  
  2870. PATCH:
  2871. -----------------------------------
  2872.  OFFSET        ADDRESS
  2873. (in file) (in memory)    WAS   BECOMES
  2874.    40B           50B    20    00
  2875.             73    D6
  2876.             74    3B
  2877.             61    E6
  2878.             74    1F
  2879.             65    4F
  2880.             6D    C9
  2881.  
  2882.    A82           B82    20    00
  2883.  
  2884.    BFC           CFC    D6    C3
  2885.             3B    0C
  2886.             4F    05
  2887. -----------------------------------
  2888.  
  2889. People who already have large run-time object libraries with all uppercase
  2890. globals will need to reassemble them with the patched assembler in order to
  2891. call them from C using lower case symbols. Perhaps a more useful patch would
  2892. invert the case; a call to printf() would refer to the global 'PRINTF', and
  2893. the function FooBar would appear to the linker as 'fOObAR'. All predefined
  2894. assembler words would then have to appear in lowercase. If there is any
  2895. demand for such a weirdness, I will get out my byte-bashing utilities
  2896. and figure out the patch (If I remember correctly how the above patch
  2897. works, the case-inverting patch is quite simple).
  2898. 30-Dec-86 00:46:17-MST,2155;000000000000
  2899. Return-Path: <info-cpm-request@AMSAA.ARPA>
  2900. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Tue 30 Dec 86 00:46:07-MST
  2901. Received: from simtel20.arpa by AMSAA.ARPA id a002742; 30 Dec 86 2:30 EST
  2902. Date: Tue 30 Dec 86 00:29:13-MST
  2903. From: "Frank J. Wancho" <WANCHO@SIMTEL20.ARPA>
  2904. Subject: Cheap PC hard disks for old S-100 system?
  2905. To: INFO-CPM@AMSAA.ARPA
  2906. cc: Wancho@SIMTEL20.ARPA
  2907. Message-ID: <12266848113.6.WANCHO@SIMTEL20.ARPA>
  2908.  
  2909. With all those ads for dirt-cheap high-capacity hard disk drives
  2910. (relative to just a few years ago), just what would I need to buy to
  2911. hook one of those drives to my S-100 NorthStar Horizon, mostly running
  2912. TurboDOS these days?  What interface do most of these drives use/need?
  2913. Are they mostly ST-506-compatible, or SCSI, or what?
  2914.  
  2915. I have several ways to go depending on the answer.  For example, if
  2916. they were ST-506, I could probably get a TurboMaster card with a
  2917. built-in ST-506 interface and the TurboDOS drivers to go with it.
  2918. (The catch is that I haven't yet heard of a mod for it to allow me to
  2919. block out the 1K I need at the top of Bank 0 so I can keep my N* disk
  2920. controller in the system.)  Other hard disk controller cards pose
  2921. problems of their own, such as one of the old Morrow cards or the
  2922. CompuPro DISK3 - i.e., some know historical problems with these cards
  2923. on the N* S-100 bus with the N* ZPU card, plus the possible lack of
  2924. TurboDOS drivers to support them.
  2925.  
  2926. Now, if these drives can use the so-called SCSI interface, perhaps I
  2927. can consider using the AMPRO SCSI add-on, if they still sell it.  But,
  2928. as I recall, it wasn't quite up to the full SCSI spec - something
  2929. about limits on the number of devices or device addresses or somesuch.
  2930. That, of course, may be academic if you only plan to hook up one or
  2931. two of these drives.
  2932.  
  2933. In any event, the question remains: what interface do these cheap hard
  2934. drives expect?  (What do they expect if you don't buy the PC interface
  2935. card normally sold with these drives?)  I'll compile a list of brand
  2936. name, model number, interface, and recommendation when and if I
  2937. receive sufficient replies.
  2938.  
  2939. Thanks,
  2940. Frank
  2941. -------
  2942. 30-Dec-86 09:28:34-MST,1404;000000000000
  2943. Return-Path: <info-cpm-request@AMSAA.ARPA>
  2944. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Tue 30 Dec 86 09:28:19-MST
  2945. Received: from umd2.umd.edu by AMSAA.ARPA id a005816; 30 Dec 86 11:02 EST
  2946. Date: Tue, 30 Dec 86 10:52:26 EST
  2947. From: Manasseh Katz <MKATZ@umd2.umd.edu>
  2948. To: info-cpm@AMSAA.ARPA
  2949. Subject: Altos Floppy
  2950. Message-ID: <M1986$042446.359000KATZM.MKATZ@UMD2.UMD.EDU>
  2951.  
  2952. After a year and a half, I finally figured out how to get the 5-1/4" floppy
  2953. on my Altos 586 to read Double Density (instead of Quad) diskettes.  It
  2954. actually couldn't be any simpler.  MODE.CMD set it to single, double, or
  2955. Altos format.  In double-density mode, the drive reads an IBM PC CP/M-86
  2956. diskette that I had paid $25 to get converted several months ago to Altos
  2957. format.  The MODE command is NOT in the Altos documentation - I checked and
  2958. rechecked after I discovered the program.  One of the Altos manuals (not
  2959. the MPM-86 manual) does mention that the drive can read double-density
  2960. diskettes (though not single-density) so I always knew it could be done,
  2961. I just didn't know - it was right in front of me the whole time....
  2962. I don't know if there are any other Altos 586/986 users out there, but
  2963. if there are I hope this helps.
  2964.                                    Manasseh Katz
  2965.                                    MKATZ@UMD2.ARPA
  2966.                                    KATZM@UMDD.BITNET
  2967. 30-Dec-86 12:33:20-MST,987;000000000000
  2968. Return-Path: <info-cpm-request@AMSAA.ARPA>
  2969. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Tue 30 Dec 86 12:32:51-MST
  2970. Received: from brl-adm.arpa by AMSAA.ARPA id a000350; 30 Dec 86 14:02 EST
  2971. Received: from USENET by ADM.BRL.ARPA id aa11067; 30 Dec 86 12:08 EST
  2972. From: "Jay C. Bowden" <jcb@loral.uucp>
  2973. Newsgroups: comp.sys.ibm.pc,comp.os.cpm
  2974. Subject: Query: WS continuous underline
  2975. Message-ID: <1324@loral.UUCP>
  2976. Date: 29 Dec 86 20:25:44 GMT
  2977. Keywords: WordStar
  2978. To:       info-cpm@AMSAA.ARPA
  2979.  
  2980. My sister-in-law uses a Kaypro iV with CP/M, but this is
  2981. mostly a WordStar question: How can you get the underline
  2982. to fill the spaces between words?  I have wanted to
  2983. do this from time to time myself, but always come up
  2984. empty handed, and just put up with the way WS does it.
  2985. She can not; there is some peculiar nursing journal format
  2986. she has to conform to.  I've wondered about the non-break-space,
  2987. but that's such a pain!  Any easy answers?
  2988.  
  2989.  
  2990.      -Jay
  2991. 30-Dec-86 13:39:03-MST,3954;000000000000
  2992. Return-Path: <info-cpm-request@AMSAA.ARPA>
  2993. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Tue 30 Dec 86 13:38:41-MST
  2994. Received: from decwrl.dec.com by AMSAA.ARPA id a002243; 30 Dec 86 15:05 EST
  2995. Received: from rhea.dec.com by decwrl.dec.com (5.54.3/4.7.34)
  2996.     id AA11497; Tue, 30 Dec 86 12:04:55 PST
  2997. Message-Id: <8612302004.AA11497@decwrl.dec.com>
  2998. Date: 30-Dec-1986 1434
  2999. From: Sold - but we have others <binder%fizbin.DEC@decwrl.dec.com>
  3000. To: info-cpm@AMSAA.ARPA, infocpm%fizbin.DEC@decwrl.dec.com
  3001. Subject: Re: Query: WS continuous underline
  3002.  
  3003. Jay Bowden asks:
  3004.  
  3005. > WordStar question: How can you get the underline to fill the spaces between
  3006. > words?  I have wanted to do this from time to time myself, but always come
  3007. > up empty handed, and just put up with the way WS does it.  She can not;
  3008. > there is some peculiar nursing journal format she has to conform to.  I've
  3009. > wondered about the non-break-space, but that's such a pain!  Any easy
  3010. > answers? 
  3011.  
  3012. There are two ways that I know of to accomplish what you want.  
  3013.  
  3014. First, of course, is to use the non-break space, but I agree that it's a pain.
  3015.  
  3016. The second way assumes that your printer (your sister's, actually) has a 
  3017. command code to turn on continuous underline.  If that is the case, there is a 
  3018. WS patch called ANYCODE that will do what you want.  The original ANYCODE was 
  3019. created by Doug Hurst.  I rewrote it to handle what I felt were two very 
  3020. severe limitations it had - my version is called ANYCODE2, and it is upward 
  3021. compatible with Doug's ANYCODE.
  3022.  
  3023. ANYCODE2 uses two characters as flags to initiate special sequences.  
  3024.  
  3025. 1.  A back accent (" ` ", hex 60) will cause ANYCODE2 to collect the next two
  3026.     characters, which must be valid hex-ASCII characters (0123456789ABCDEF)
  3027.     and convert them into a single ASCII character for transmission.  For
  3028.     example, this sequence: 
  3029.  
  3030.     whatever text `0Fexpanded text`12 some more text
  3031.  
  3032.     will cause the words "expanded text" to be printed double-wide on an Epson
  3033.     printer.  The `0F is an ASCII <SI> and the `12 is a <DC2>. 
  3034.  
  3035. 2.  A tilde (" ~ ", hex 7E) will cause the same action except that an <ESC>
  3036.     will be transmitted FIRST, before the constructed character.  For example,
  3037.     this sequence:
  3038.  
  3039.     ~4E`08
  3040.  
  3041.     will transmit <ESC> N <BS> which will cause an Epson printer to set for
  3042.     an eight-line perforation skip between pages.  You could do the same
  3043.     thing this way:
  3044.  
  3045.     `1B`4E`08
  3046.  
  3047.     but using the tilde is more convenient.
  3048.  
  3049. ANYCODE2 allows you to use lowercase characters in your code sequences, so 
  3050. that `4e will be read the same as `4E.  It also allows you to print the two 
  3051. special leadin characters by repeating them - this sequence:
  3052.  
  3053.     an ``enclosed' word
  3054.  
  3055. will print as:
  3056.  
  3057.     an `enclosed' word
  3058.  
  3059. ANYCODE2 is in 8080 code and can be assembled and installed into WS using DDT 
  3060. under CP/M.  It goes into a special patch area provided and does not increase
  3061. the size of the WS.COM file. 
  3062.  
  3063. To do continuous underlining, create your WS file as you want it, and then go 
  3064. back and, with margin release set, insert the code sequences to turn 
  3065. continuous underlining on and off.  You can do this very easily by creating a 
  3066. text block containing one sequence, plant it everywhere you want it, and then 
  3067. create another block for the second sequence.  You have to do all the 
  3068. justification and so forth that you want BEFORE inserting the code sequences, 
  3069. because WS sees these sequences as "real" characters in the file.
  3070.  
  3071. I don't have a way to upload ANYCODE2 to a BBS anywhere - no serial line on my 
  3072. home machine.  If there is interest in ANYCODE2, send email to me, and I'll
  3073. bring a copy of the source listing to work and type it in for upload or
  3074. posting. 
  3075.  
  3076. Cheers,
  3077. Dick Binder   (The Stainless Steel Rat)
  3078.  
  3079. DEC Enet:    ASD::BINDER
  3080. UUCP:        { decvax, allegra, ucbvax... }!decwrl!asd.dec.com!binder
  3081. ARPA:        binder%asd.DEC@decwrl.ARPA
  3082. 30-Dec-86 19:07:23-MST,503;000000000000
  3083. Return-Path: <info-cpm-request@AMSAA.ARPA>
  3084. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Tue 30 Dec 86 19:07:18-MST
  3085. Received: from usc-isi.arpa by AMSAA.ARPA id a006165; 30 Dec 86 20:33 EST
  3086. Date: 30 Dec 1986 20:32:07 EST
  3087. Subject: WS underline
  3088. From: Rex Buddenberg <BUDDENBERGRA@usc-isi.ARPA>
  3089. To: info-cpm@AMSAA.ARPA
  3090. cc: BUDDENBERGRA@usc-isi.ARPA
  3091.  
  3092. To get a continuous underline in WS, you have to fill the blanks
  3093. with '___'s.  A bit clumsy, but it works.
  3094. Z
  3095. -------
  3096. 30-Dec-86 21:33:38-MST,1196;000000000000
  3097. Return-Path: <info-cpm-request@AMSAA.ARPA>
  3098. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Tue 30 Dec 86 21:33:23-MST
  3099. Received: from umd2.umd.edu by AMSAA.ARPA id a006665; 30 Dec 86 23:00 EST
  3100. Date: Tue, 30 Dec 86 22:40:52 EST
  3101. From: Manasseh Katz <MKATZ@umd2.umd.edu>
  3102. To: info-cpm@AMSAA.ARPA
  3103. Subject: Disk Formats
  3104. Message-ID: <M1986$042493.359000KATZM.MKATZ@UMD2.UMD.EDU>
  3105.  
  3106. Does anyone know the difference between various CPM disk formats ?
  3107. I am using an Altos 586, which I recently discovered can read
  3108. double-density (as opposed to quad or 96 tpi) disks.  This worked
  3109. for a disk that was in IBM CPM-86 format.  Does anyone know if this
  3110. is the same as (or close enough to) Kaypro 2 CPM ?  Kaypro 2 CPM is
  3111. the only 5-1/4" CPM format for BYTE Listings on Disk.  If I can
  3112. read that format I may get some of those disks.  The Altos manual
  3113. doesn't mention the MODE command I used to read the IBM disks, so
  3114. it obviously doesn't tell me what other disks I can read, if any.
  3115. Any info. will be greatly appreciated.
  3116.                                  Manasseh Katz
  3117.                                  MKATZ@UMD2.ARPA
  3118.                                  KATZM@UMDD.BITNET
  3119. 31-Dec-86 00:13:17-MST,1177;000000000000
  3120. Return-Path: <info-cpm-request@AMSAA.ARPA>
  3121. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Wed 31 Dec 86 00:13:04-MST
  3122. Received: from brl-adm.arpa by AMSAA.ARPA id a006990; 31 Dec 86 1:56 EST
  3123. Received: from USENET by ADM.BRL.ARPA id aa18619; 31 Dec 86 1:49 EST
  3124. From: Administrator <root@galbpbb.uucp>
  3125. Newsgroups: comp.os.cpm
  3126. Subject: Re: C compiler requests
  3127. Message-ID: <104@GALBPBB.UUCP>
  3128. Date: 29 Dec 86 21:37:24 GMT
  3129. Keywords: shitty compiler
  3130. To:       info-cpm@AMSAA.ARPA
  3131.  
  3132. In article <109@cogent.UUCP> mark@cogent.UUCP (Mark Steven Jeghers) writes:
  3133. >How is the C by Software Toolworks?  I understand it is about $50
  3134. >for CP/M.
  3135.  
  3136. DO NOT GET THIS COMPILER!!!
  3137.  
  3138. I got one and the stupid thing stacks the arguements to subroutines in
  3139. REVERSE ORDER!!! This makes routines like printf and scanf very awkward.
  3140. They have to define a macro which expands into two calls; the first to
  3141. a routine that marks the stack position in a global variable, then they
  3142. call a bastardized printf that looks at the args backwards from the
  3143. global variable content.
  3144.  
  3145. Now, if you can live with that crap, I have nothing but contempt
  3146. for you.
  3147.  
  3148. galbp!bing
  3149. 31-Dec-86 02:36:13-MST,1184;000000000000
  3150. Return-Path: <info-cpm-request@AMSAA.ARPA>
  3151. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Wed 31 Dec 86 02:36:08-MST
  3152. Received: from brl-adm.arpa by AMSAA.ARPA id a007291; 31 Dec 86 4:13 EST
  3153. Received: from USENET by ADM.BRL.ARPA id aa19220; 31 Dec 86 4:09 EST
  3154. From: "Joseph D. Loda" <joeloda@aicchi.uucp>
  3155. Newsgroups: comp.os.cpm
  3156. Subject: Copying Large Files to Small Floppies
  3157. Message-ID: <885@aicchi.UUCP>
  3158. Date: 30 Dec 86 06:08:23 GMT
  3159. To:       info-cpm@AMSAA.ARPA
  3160.  
  3161. I have a small problem.  Small floppies, that is.  I have a number of large
  3162. files on my hard disk, and would like to back them up on floppies .   Apple
  3163. 5.25 floppies only hold 126k; what do I do with these 180k .LBR's?
  3164.  
  3165. Any suggestions would be appreciated.  Also, if anyone knows of a backup/restore
  3166. utility that will split files, please mail back.  I posted that question about
  3167. a month ago, and didn't receive one reply.  Hard to beleive I'm the only person
  3168. with this problem.
  3169.  
  3170. Thanks in advance.  Happy New Year!
  3171.  
  3172. Joe.
  3173. -- 
  3174. Joe Loda
  3175. Analysts International (Chicago Branch)
  3176.  
  3177. Usenet:   ..!ihnp4!aicchi!joeloda
  3178.    CIS:   75726,1641
  3179.    BIX:   jloda
  3180.  GEnie:   j.loda
  3181. 31-Dec-86 07:46:30-MST,1070;000000000000
  3182. Return-Path: <info-cpm-request@AMSAA.ARPA>
  3183. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Wed 31 Dec 86 07:46:11-MST
  3184. Received: from brl-adm.arpa by AMSAA.ARPA id a010835; 31 Dec 86 9:12 EST
  3185. Received: from USENET by ADM.BRL.ARPA id aa01098; 31 Dec 86 9:09 EST
  3186. From: Jean Airey <jean@hrcca.uucp>
  3187. Newsgroups: comp.os.cpm
  3188. Subject: Re: Printer/Wordstar problems
  3189. Message-ID: <426@hrcca.UUCP>
  3190. Date: 29 Dec 86 20:08:37 GMT
  3191. Keywords: [Century] Citizen 35, Wordstar, CR/LF
  3192. To:       info-cpm@AMSAA.ARPA
  3193.  
  3194. In article <425@hrcca.UUCP>, jean@hrcca.UUCP (Jean Airey) writes:
  3195. > My husband gave me a *Citizen* 35 printer for Christmas -- but when I
  3196.  
  3197. The printer is a CITIZEN, not a Century.  Anyway, the problem is that
  3198. I can't get Wordstar to work with it.  Any help would be apprecialted.
  3199. Is there a significant difference between the MS/DOS "serial",
  3200. "parallel" winstall results and the cp/m "primary list device?"  
  3201.  
  3202. "Regret is part of being alive". . . Avon
  3203. -- 
  3204. Jean Airey: US Mail 1306 W. Illinois, Aurora, IL 60506
  3205. ihnp4!hrcca!jean
  3206. 31-Dec-86 10:41:11-MST,1609;000000000000
  3207. Return-Path: <info-cpm-request@AMSAA.ARPA>
  3208. Received: from AMSAA (AMSAA.ARPA.#Internet) by SIMTEL20.ARPA with TCP; Wed 31 Dec 86 10:41:04-MST
  3209. Received: from nosc.arpa by AMSAA.ARPA id a015113; 31 Dec 86 12:10 EST
  3210. Received: by bass.ARPA (5.31/4.7)
  3211.     id AA26061; Wed, 31 Dec 86 09:10:27 PST
  3212. Received: by crash.UUCP (5.9/UUCP-Project/rel-1.0/09-14-86)
  3213.     id AA04899; Wed, 31 Dec 86 08:56:31 PST
  3214. Message-Id: <8612311656.AA04899@crash.UUCP>
  3215. Date: Wed, 31 Dec 86 08:44:29 PST
  3216. From: Marc Wilson <crash!pnet01!mwilson@NOSC.ARPA>
  3217. To: crash!info-cpm <@NOSC.ARPA:crash!info-cpm@AMSAA.ARPA>
  3218. Subject: Re: Printer/Wordstar problems
  3219.  
  3220. >Is there a significant difference between the MS-DOS "serial",
  3221. >"parallel" WINSTALL results and the CP/M "primary list device?"
  3222.  
  3223.      WordStar should work just fine with the CP/M LST: device.  Make sure you
  3224. are not defining a protocol to be used, or any hardware ports, or anything
  3225. like that.  Let your operating system handle it.  That's all I'm doing right
  3226. now.
  3227.  
  3228. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  3229. Marc Wilson
  3230.  
  3231.      ARPA: ...!crash!pnet01!mwilson@nosc             ( preferred )
  3232.            ...!crash!pnet01!pro-sol!mwilson@nosc
  3233.      UUCP: [ akgua | hp-sdd!hplabs | sdcsvax | nosc ]!crash!pnet01!mwilson
  3234.  
  3235.      "The difference between science and the fuzzy subjects is that science
  3236.       requires reasoning, while those other subjects merely require
  3237.       scholarship."
  3238.                                                       -Lazarus Long
  3239. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  3240.