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)