Tli%usc@BRL.ARPA (12/10/83)
From: Tony Li <Tli%usc@BRL.ARPA> Hi, Yes Mike, you got that discussion about CP/M media compatibility perfectly correct. However, let me add one little other note: Digital Research intends to support the CP/M-80 disk format until doomsday. (By this, I mean all operating systems which are planed in the forseable future - about 5 years). This portability extends also to CP/M-68K. However, realize that MOST CP/M-86 systems use 5 1/4" diskettes, so in one way, DDA, your salesman was correct. Cheers, Tony Li ;-) Digital Research Inc. P.s. This is not a policy statement. Just knowledge from an employee.
Kenny%his-phoenix-multics.arpa@BRL-VGR.ARPA (12/12/83)
From: Kevin Kenny <Kenny%his-phoenix-multics.arpa@BRL-VGR.ARPA> In fact, Tony Li's a little conservative about CP/M-MP/M-CCP/M media exchange. The XFCB's (extended file control blocks) look like files in nonexistent user areas (above 16). In fact, though, they're set up so that if all you use is date/time stamping and the protection attributes, you won't actually get in trouble. The second 16 bytes of the XFCB is reserved for encrypted password, and will be zero if the file is unpassworded, meaning that the ``file'' won't look as if it's using any space on the disc, and CP/M-80 won't get confused. In short, you can exchange discs freely back and forth between CP/M-80 and the newer systems, *provided* that the files are unpassworded, even if XFCB's are used. Some of the public domain programs may get confused by the XFCB's, so be careful. I know that SAP and DUU work. SD reports some garbage information for the additional directory entries. /k**2
Kenny%his-phoenix-multics.arpa@BRL.ARPA (12/14/83)
From: Kevin Kenny <Kenny%his-phoenix-multics.arpa@BRL.ARPA> (1) -- 32 lines Date: Tuesday, 13 December 1983 18:40 mst From: Network_Server.Multics Subject: Unable to deliver mail from Kenny.OSNI@HIS-PHOENIX-MULTICS.ARPA To: Kenny.OSNI at HIS-PHOENIX-MULTICS Recipient INFO-CPM@BRL-VGR.ARPA at CISL-SERVICE-MULTICS.ARPA failed because The requested action was not performed. No known path. ******************** Failed message follows. ******************** Date: Tue, 13 Dec 83 18:37 MST From: Kevin Kenny <Kenny@HIS-PHOENIX-MULTICS.ARPA> Subject: Re: CP/M Media Compatibility Reply-To: Kenny%PCO@CISL-SERVICE-MULTICS.ARPA To: INFO-CPM@BRL-VGR.ARPA Message-ID: <831214013735.338020@HIS-PHOENIX-MULTICS.ARPA> Resent-Message-ID: <831213005740.664514@HIS-PHOENIX-MULTICS.ARPA> In fact, Tony Li's a little conservative about CP/M-MP/M-CCP/M media exchange. The XFCB's (extended file control blocks) look like files in nonexistent user areas (above 16). In fact, though, they're set up so that if all you use is date/time stamping and the protection attributes, you won't actually get in trouble. The second 16 bytes of the XFCB is reserved for encrypted password, and will be zero if the file is unpassworded, meaning that the ``file'' won't look as if it's using any space on the disc, and CP/M-80 won't get confused. In short, you can exchange discs freely back and forth between CP/M-80 and the newer systems, *provided* that the files are unpassworded, even if XFCB's are used. Some of the public domain programs may get confused by the XFCB's, so be careful. I know that SAP and DUU work. SD reports some garbage information for the additional directory entries. /k**2