Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA Path: utzoo!watmath!clyde!cbosgd!ihnp4!zehntel!hplabs!hao!seismo!brl-tgr!tgr!mknox@ut-ngp.ARPA From: mknox Newsgroups: net.micro.cpm Subject: Reply to: cp/m standards Message-ID: <7590@brl-tgr.ARPA> Date: Mon, 21-Jan-85 08:33:25 EST Article-I.D.: brl-tgr.7590 Posted: Mon Jan 21 08:33:25 1985 Date-Received: Wed, 23-Jan-85 19:19:35 EST Sender: news@brl-tgr.ARPA Organization: Ballistic Research Lab Lines: 28 One thing that I have long argued with the system folk at DRI is for the DRI supported definition of a large number of additional OPTIONAL CP/M calls. I wanted them to define a few new BDOS calls, and a ton of BIOS calls, all of which would be optional. For an implementor to bring up CP/M on a new machine would require no more than it does now. But if he wanted to add, for instance, support for a real-time clock, then there would be a standard call for it, complete with a description of what to return. I use this example because most all new designs support clocks, extra ports, and the like. But they all do it differently, even though all are running CP/M. Key things would be: o Support calls for a large number of potential hardware devices, including I/O ports, clocks, interrupts, and screens. o A 'configuration' call to return the system configuration (in some standard format). o A standard mechanism for returning a 'fault' or 'not-available' status. So far some of the DRI people say they have been arguing for the same thing. Others are afraid a long list of calls (even optional) would scare off developers.