Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site ncsu.UUCP Path: utzoo!linus!decvax!mcnc!ncsu!jcz From: jcz@ncsu.UUCP (Carl Zeigler) Newsgroups: net.micro.amiga Subject: Amiga Questions Message-ID: <2966@ncsu.UUCP> Date: Wed, 8-Jan-86 09:46:40 EST Article-I.D.: ncsu.2966 Posted: Wed Jan 8 09:46:40 1986 Date-Received: Fri, 10-Jan-86 06:32:28 EST Organization: N.C. State University, Raleigh Lines: 102 We have several questions that we would like Commodore to answer: 1) When using the SER: AMIGADOS device driver, is there any way to specify that either no or a specific amount of buffering is to be done. We have a terminal connected to the serial port and very much want to take advantage of using CLI over the Serial port. As it is, if you enter NEWCLI SER: you can indeed use CLI, but you have to buffer each command with 400 characters before it will get executed. (We have a function key set up to do it). Now that we have micro EMACS running, We intend to modify it to use the serial port. The AMIGA is a true multi-tasking machine, and with two programmers in one house it makes sense that both should be able to use it at the same time. One possible solution to this problem would be to recognize a special name in the open such as SER:UNBUFFERED. To take this one step further, why limit it to that, it shouldn't be too difficult to allow one to specify the baud rate and other parameters in the device name, much the same way we specify a window definition for RAW: or CON: 2) Are there any plans to implement a PIPE: type device driver and even command piping under CLI? The internal structure of device drivers quite readily supports UNIX style piping and should not require a lot of work to implement. I have made several attempts at hooking in my own CLI which supports piping, but all reasonable avenues seemed to be blocked (see next question). 3) Is there any way to catch the calls to the AMIGADOS Execute function so that a user written CLI can process all commands instead of the ROM CLI. This has its usefulness in allowing a program to Install itself and then process commands it considers 'internal' such as DIR, CD, LIST, and INFO without having to load the programs from disk. MS-DOS has this concept of internal commands which does not require me to have a CLI disk in in order to look at what is on it. Also, this would allow piping to be implemented without having to wait for any new releases of the operating system. We know that C:RUN is executed whenever a EXECUTE is called, perhaps this is where this hook can be placed. 4) What are the possibilities of implementing a form of path searching for commands. One possibility would be a device driver such as PATH: which would take as its file name a list of directories. For example: ASSIGN C: PATH:df0:c/;df1:c/;ram: Then when C: is references, the PATH: device driver would successively search for in the df0:c/ df1:c/ and ram: directories and return the file control block it obtained from the corresponding device. This would be a simple change to avoid having to change the list of devices maintained by AMIGADOS. 5) Is there any light in the crystal ball as to when we might see a way to specify the current directory in a file name. I know that we can just reference the file without any path on it, but it would be nice to do something like the following: ASSIGN HOME: . CD HOME: and end up back in the same directory. If there is a way to catch the Execute function (question 4) then a user written command handler can substitute quite readily, but it would be extremely nice for the filing system to have a good idea of this designation. 6) What are the possibilities of implementing LINKS in the filing system. The way the device drivers are structured now, it whould be a simple task of adding a new type for file creation or more appropriately another type of message. With links, one can get around the problems associated with the lack of search paths. 7) Are there any provisions for tuning the system performance when it comes to reading the disks. Although it is nice that the AMIGA reads its disks a track at a time, it isn't very much of a performance boost when there appears to be only ?one? track buffer. Here we have a machine capable of addressing 8 1/2 MEG of memory and there is no way to tell it to use a little (11K) extra for an additional buffer. 8) Is there any plans for releasing the BCPL compiler? Amigados device drivers expect to be in BCPL format - unlike the remainder of the executable images encountered so far, making it extremely difficult to add our own device drivers without having to carefully reproduce the BCPL environment in assembler. As an alternative, what about the possiblilty of releasing a program that takes an executable output from the linker and then converts it to a BCPL type image - assuming that the original code followed certain restrictions. That is it for now, we see the AMIGA as an excellent development environment and are just looking for ways to improve productivity using the machine. We would appreciate seeing these answers over the NET as everyone should benefit from the information. Thanks, John A. Toebes, VIII +++++++++++++++++++++++++++++++++++ Jack J. Rouse +++ Opinions expressed here are +++ Jeff Polzin +++ not necessarily that of our +++ Ken Howell +++ employer +++ Phil Julian +++++++++++++++++++++++++++++++++++ Please respond to us through ncsu!jcz (mcnc!ncsu!jcz)