bds@mtgzz.UUCP (b.d.szablak) (08/30/85)
From: eric@topaz.RUTGERS.EDU (Eric Lavitsky)
I want to thank Eric Lavitsky for offering to answer questions on the
Amiga (you may regret it). I will try to make my questions to the point:
What is your configuration?
What graphics primitives are supported in hardware, and which in software
(such as lines, circles, points, area-fill, etc.)?
What sound primitives are supported?
Assuming you have the C compiler, how complete are the standard libraries?
Are there any inter-process communication facilities (pipes et. al.)?
Describe any screen orientated text and/or graphics (sound?) editors.
Is there a debugger?
Is there a utility to make disk copies on a single disk drive system?
Is there any file transfer utilities (XMODEM etc.)?
How long does it take to boot?
How long does it take to compile: main(){printf("hello world\n");} ?
How long does it take to fill a 1/2 screen circle, triangle, and box
in 640x400, 640x200, and 320x200 modes (do it a hundred times).
How long does it take to invoke an editor on a 1-10k byte file and save
it?
Is the software copy-protected, or are there any provisions for creating
copy-protected software (i.e. encoded serial #)?
and much, much, more...wrz@riccb.UUCP (William R. Zielinski ) (10/22/85)
Another Amiga question: What is the difference between the Lattice <math.h> math routines and the Amiga math*.library routines? Is a function (e.g. sin()) implemented in the same way? Speed differences? etc. Bill Zielinski
jcz@ncsu.UUCP (Carl Zeigler) (01/08/86)
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:<file> is references, the PATH: device driver would
successively search for <file> 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: .
<do anything including changing directories>
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)jim@ISM780B.UUCP (01/12/86)
>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: . > <do anything including changing directories> > CD HOME: The null string refers to the current directory, so ASSIGN HOME: "" does the trick. -- Jim Balter (ima!jim)
andre@cui.UUCP (DIDELOT Andre) (03/01/86)
In article <213@oberon.UUCP> spencer@oberon.UUCP reply to <5016@alice.uUCp> : > >> option in Preferences. Now, whenever I open my Workbench icon, all the >> other icons (AmigaBASIC, CLI, Trash, etc.) are all piled on top of each >> other, and the drawers are halfway out the window. I rearrange them, save >> the INFO option on the disk icon, EVERYTHING- and it still makes a mess. > >icon info for the disk that appears when the disk is inserted. When >you move an icon you must save the info file for it again. This is a >pain, if you use the clean-up option you must select each icon and >then save the info file. If you want to save the position that the >window opens, that is saved by selecting the disk icon and save the >info for that (select get info and then click in the save box). There At the time, nobody commented this, so here is a simple way to rearrange your icons in any window of your choice: 1)open the window whose content as to be rearranged 2)rearrange its content; use the "cleanup" menu item as many times you need to get the job done faster; fix the proper size of the window accordingly; 3)move the window where you want it to be when it will be opened 4)select each inner icon in turn and use the "snapshot" menu item to save its location within the window 5)select the icon of the window you just rearranged and use the "snapshot" menu item to save size and location of its associated window After that, you can close the window; it should now be ok when you re-open it. Note that above procedure didn't work on version 1.0; it looked like if there was a "loop feed back", because icons never stayed where they were supposed to be (but luckily enough, I got 1.1 before loosing all my hairs :-). Andre DIDELOT CHUNET: andre@cui.unige.chunet MAIL: Centre Universitaire d'Informatique UUCP: mcvax!cernvax!cui!andre Universite de Geneve mcvax!cernvax!cui!root Rue du General Dufour 24 CH - 1211 GENEVE 4 BITNET: DIDELOT@CGEUGE51 SWITZERLAND SYSTEM@CGEUGE51
lbg@gitpyr.UUCP (Lee B Grey) (03/05/86)
Rather than select each icon and snapshot it, why not use extended icon
selection, which will allow you to do the whole thing in one step?
Hold do the keyboard SHIFT key and select all the icons your little heart
desires. In this case, select the drawer icon and all of the icons in
the drawer window. NOW, you can choose snapshot from the menu and let
the Amiga do the work. Isn't that wonderful?!
. .
| <--Lee (I thought you might like to know what I look like.)
`-'
cem@intelca.UUCP (Chuck McManis) (03/09/86)
> > At the time, nobody commented this, so here is a simple way to rearrange > your icons in any window of your choice: > 1)open the window whose content as to be rearranged > 2)rearrange its content; use the "cleanup" menu item as many times you need > to get the job done faster; fix the proper size of the window accordingly; > 3)move the window where you want it to be when it will be opened > 4)select each inner icon in turn and use the "snapshot" menu item to save its > location within the window Note that the easiest way (and the fastest) to do this is to hold down the shift key and then select *all* of the icons in the window. Then you need only snapshot once. > 5)select the icon of the window you just rearranged and use the "snapshot" > menu item to save size and location of its associated window > After that, you can close the window; it should now be ok when you re-open it. > > Note that above procedure didn't work on version 1.0; it looked like if there > was a "loop feed back", because icons never stayed where they were supposed to > be (but luckily enough, I got 1.1 before loosing all my hairs :-). > > Andre DIDELOT CHUNET: andre@cui.unige.chunet --Chuck McManis -- - - - D I S C L A I M E R - - - {ihnp4,fortune}!dual\ All opinions expressed herein are my {qantel,idi}-> !intelca!cem own and not those of my employer, my {ucbvax,hao}!hplabs/ friends, or my avocado plant. :-}