From: utzoo!decvax!ucbvax!info-cpm Newsgroups: fa.info-cpm Title: CP/M 3.0 (possible message repeat) Article-I.D.: ucbvax.142 Posted: Sun Nov 28 18:06:28 1982 Received: Wed Dec 1 01:17:58 1982 >From vortex!lauren@Lbl-Unix Sun Nov 28 17:54:00 1982 To: INFO-CPM@BRL Via: Lbl-Unix; 28 Nov 82 19:20-EST Via: Brl; 28 Nov 82 19:33-EST Via: Brl-Bmd; 28 Nov 82 19:45-EST The following is largely a repeat of a message I sent recently to INFO-CPM. I've been getting a multitude of bizarre error messages back from various network gateways, and I have no way to know if this message reached the majority of intended recipients, thusly this rerun. I will add a couple of comments here in reference to a message I got from someone who *did* receive my message. While I agree that having a big TPA would be nice for development in some cases, my biggest concern is that we will still see more and more programs that will REQUIRE that sort of TPA for program *usage* later on, not just for development. I would suggest that this will lead to a (potentially serious) fragmentation between those with "normal" TPAs and those with "extended" TPAs via unique bank-switched memory schemes. The fact that some linkers, for example, don't efficiently use the available memory is the fault of lazy software designers, and not necessarily the sort of problem at which we should simply "throw more memory" . Enough on that, here's the original message. My apologies to those of you who may have already seen it... --- I appreciate Tony's message about 3.0, but it leads me to suspect there is still alot of confusion about 3.0 flowing around. First of all, the D.R. Graphics PACKAGE is, as far as I know, a completely separate offering from CP/M itself, and in fact does conform to certain graphics standards. The rumors I was addressing were the ones that said "... and CP/M 3.0 will support graphics". This implies that a graphics package is PART of 3.0, which I have no reason to believe to be true. In fact, Tony DID say that the graphics package was 2.2 compatible. So I guess we've laid *that* rumor to rest. Let's review what we know about CP/M 3.0 to date: (I do not claim this to be an unbiased view, as will rapidly become clear): 1) Provides more "menu-oriented" features/help command. -- probably good for SOME OEM's but probably inadequate for most users, or at least unwanted by many. Probably aimed at the turnkey business market. 2) Automatic searching of USER 0 if program not found on current user area. -- what an advance! ZCPR has provided this sort of functionality, and MUCH, MUCH more, for free, for a long time. 3) Disk blocking/deblocking moved to BDOS. -- this is a feature??? D.R. only claims "functional" compatibility between 2.2 and 3.0. I suspect there are some assumptions about the sophistication of your programs -- I'd bet any reasonable amount that ALOT of heavily used programs will not work without modification under 3.0. 4) Some sort of date/time stamping. -- reasonable I suppose. Most other systems have provided such a feature all along. Whether it is sophisticated enough for easy interfacing to different sorts of clocks, etc. is another matter. See, I am TRYING to be fair! 5) Some sort of file I/O redirection. Gee, just what Microshell does now! Why do I get the feeling that there will be some sort of restrictions to redirection, like, maybe only BDOS output (not BIOS output) will work properly with redirection? (We had to do both for MARC and it was a PAIN.) 6) Memory Usage. Now we get to the real nitty gritty. Supposedly there will be two versions of CP/M 3.0. One for people without bank- switched memory and one for people with additional memroy. If you are running a simple 64K system, the *other* features of CP/M apparently take up at least another 4K from standard 2.2. (We know that these features must be coming from somewhere, and obviously you can no longer overlay that portion of the BDOS which has the disk blocking/ deblocking code unless you a running a very simple program. If you have more than 64K memory, and someone to figure out how to interface it with your new 3.0 bios (apparently D.R. has NO interest in helping other than large, turnkey-type OEM's with such support), you can let the system reside in a different bank of memory, and give yourself a larger TPA. Also, apparently you use the additional memory in such a manner as to provide the same "sort" of functionality that FAST/SPEED have provided under 1.4 and 2.2 to do reasonable disk buffering. How well this works under the D.R. implementation, or how difficult it is to interface, remains to be same. I'll bet that > 64K memory bioses are a real PAIN to get working right, and will be very highly system dependent. The idea of having a larger TPA sounds nice at first, unless you consider having any sort of compatibility with 2.2 to be important! If you plan to write programs that will still run under 2.2, you will still be restricted to the "standard" size TPA's, and there are one hell of alot of 2.2's out there! I claim that the bottom line remains the same -- 3.0 has been oriented almost totally toward the OEM who plans to run many "identical" systems (or nearly so), and doesn't mind a very complex bios since there is only one hardware configuration to worry about. The fact that D.R. has told non-OEM's to "go away" when it comes to 3.0 is highly suspicious. I won't even drag up the issue of documentation quality again... we all know about that. The issue of CP/M 2.2 compatibility is also less important to such OEM's since, often they will just be running their own collection of programs on their hardware, and won't even try to distribute their software more widely. --- In answer to a number of questions I've received, I'm hoping to get MARC out in some form quite early in '83, and I will take a look at the issues of CP/M 3.0 compatiblity. But, frankly, I don't consider it to be a priority task. In fact, I don't know if I really want to take the time to get my complex hard disk/floppy bios running under 3.0! If I use the bank-switched version, I've got system dependencies again, and if I use the the non-banked version, I lose 4K off the top! Neither of these options is particularly appealing. For now, MARC will be a 2.2 compatible product, period. By the way, I've been "warned" that there will be some sort of review of MARC in the December BYTE (apparently as a text "box" included in the review of two other software products). The person who wrote the article is one of the beta test sites -- though he has not had the most up-to-date version of the system or utilities by any means. I think he wrote the article about eight months ago and it has taken until now to get into print! Anyway, it might be amusing reading. I *hope* it's amusing.. . --Lauren--