dillon@CORY.BERKELEY.EDU (Matt Dillon) (12/16/86)
>In any case, to put in my 2 cents, I want to see the CLI do consistent >file name expansion. I don't want each individual program to do it in >it's own way. I don't have any problems with file name expansion with >the unix shell, and I don't see why I would with my Amiga. ABSOLTELY NOT!. Remember that most utilities *require* their very own CLI. If you make the CLI too big, the overhead for your favorite utilities will go up to. What I *do* want to see is some library support (dos library) for executing processes will full I/O redirection with their very own CLI attached. To get the functionality, use a shell program (for instance, mine). NOW LOOK C-A, I'VE ENOUGH OF THIS SH#$%%T. WILL YOU *PLEASE* POST DOCUMENTATION ON BCPL STARTUP AND ALL THE STRANGE THINGS IT DOES TO THE STDIO FILEHANDLES SO WE CAN WRITE AN EXEC() THAT WORKS!!!. I thought I had gotten an exec() that worked, but no, when I modify it to APPEND to the output file instead of CREATE/TRUNCATE, the BCPL program fails to write everything to the file. Why the hell you didn't add this to the 1.2 DOS library I'll never know. -Matt
carolyn@cbmvax.cbm.UUCP (Carolyn Scheppner) (12/18/86)
In article <8612152348.AA29410@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > > NOW LOOK C-A, I'VE ENOUGH OF THIS SH#$%%T. WILL YOU *PLEASE* POST >DOCUMENTATION ON BCPL STARTUP AND ALL THE STRANGE THINGS IT DOES TO THE >STDIO FILEHANDLES SO WE CAN WRITE AN EXEC() THAT WORKS!!!. I thought I had >gotten an exec() that worked, but no, when I modify it to APPEND to the >output file instead of CREATE/TRUNCATE, the BCPL program fails to write >everything to the file. Why the hell you didn't add this to the 1.2 DOS >library I'll never know. > > -Matt I've had more than enough of your SCREAMING and CURSING. You act like we're hoarding some Magic Document that would endow the reader with Instant Knowledge of the Glorious Inner Secrets of AmigaDOS. Well Matt, there is no magic document. I wish there was. What we have is the AmigaDOS source code. BCPL is a bit like C, and it is possible to decipher and even make changes to localized portions of the code. But when you start to trace code that interfaces with the private global functions via run-time linking, you get stopped by tables of labels and vectors that specify numerical offsets into other tables that are built at run time. And if you manage to make it to the other side of the table because a corresponding label on the other side happens to have a similar name, you get stuck there because because that code starts loading registers with labels defined as offsets into the run-time table. So, you can either pay Tim King to reveal the inner secrets, or wait until someone here has time to decipher a very large and very complex program that jumps all over the place. carolyn -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Carolyn Scheppner -- CBM >>Amiga Technical Support<< UUCP ...{allegra,caip,ihnp4,seismo}!cbmvax!carolyn PHONE 215-431-9180 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
carolyn@cbmvax.cbm.UUCP (Carolyn Scheppner) (12/18/86)
This is for everyone but Matt Dillon who has been rather rude lately.
I've spent the past three days typing this in between phone calls
and after hours. I even had to type the first hundred lines in
twice because our VAX went down before I had saved the file.
The following is a summary of an article that Tim King wrote for
the CBM UK developer's newsletter.
He sheds some light on the inner workings of AmigaDOS.
carolyn
--------------------------------------------------------------------------
Some AmigaDOS Info from Tim King
================================
GLOBAL VECTOR
=============
To cut down on link times, BCPL allows modules to link at run-time.
Different modules communicate using a common data area known as
the "global vector". The global vector is a large table containing
global variables and addresses of global routines that all modules
know about. Note that the global vector table is for the internal
convenience of AmigaDOS. It is likely to vary from version to
version, and application programs are not supposed to use it.
Most references to "global vector" refer to one master table used
by the whole of AmigaDOS. However some processes such as the
file-handler are tied together using their own private global
vector.
WORDS and BPTRs
===============
The only data type supported by BCPL is the machine-word. In 68000
BCPL implementations this is a 32-bit quantity (LONG or ULONG).
AmigaDOS makes use of normal machine addresses (APTRs) internally.
For example, entries in the global vector corresponding to global
routines are usually APTRs. However, since BCPL does everything
in terms of long-words, its own pointers are expressed as pointers
to long-words called BPTRs. (BPTR = APTR/4)
Note that anything accessed via a BPTR must be long-word aligned.
(in other words, have an address evenly divisible by 4)
STRINGS and BSTRs
=================
A C string is a pointer to a string of characters terminated by a null.
A BCPL string (BSTR) is a BPTR to a structure containing the lenghth
of the string in the first byte, with the actual string characters
following. Be warned that references to BSTRs normally mean a BPTR
to a BSTR structure, but sometimes refer to the BSTR itself.
SEGMENT LISTS
=============
Another BCPL structure used extensively by AmigaDOS is a "Segment List".
This is a simple forward linked list:
-------------------- -------------------- --------------------
| Length of seg | | Length of seg | | Length of seg |
| BPTR to next seg |--->| BPTR to next seg |--/ /-->| Null (no more) |
| Data | | Data | | Data |
-------------------- -------------------- --------------------
An example of this type of list is the segment list created by the
scatter loader.
THE AMIGADOS KERNEL
===================
AmigaDOS consists of a small "kernel" written in assembler, plus
various "processes" such as file-handlers and CLIs, mostly written
in BCPL, plus various "devices" such as DF0: and CON:, also written
mostly is BCPL but interfacing to "device drivers" written in
assembler. AmigaDOS uses exec as its kernel, and makes use of Exec
"devices" such as trackdisk.device as its device drivers.
THE AMIGADOS LIBRARY
====================
The AmigaDOS "library" is organized so that it can be accessed as
either an Exec library (dos.library) or as a Tripos-style resident
library. As an Exec library, DOS is somewhat peculiar. It does
not support Expunge() and its jump table does not consist of
jump instructions. Instead, the table consists of a series of
six-byte entries (same length as jump instruction) organized as
follows:
MOVEQ #entry_number_in_global_vector, D0
BRA action
MOVEQ #another_entry_number_in_global_vector, D0
BRA action
etc.
The "action" routine, which is in the library positive offset area,
grabs 1500 bytes below your current stack pointer for use as a BCPL
stack and sets up A1 as a BCPL stack pointer. BCPL stacks are used
from the bottom upwards. No bounds check is done on this so you
better have 1500 bytes available on your stack when you call
AmigaDOS. It then zeros a0, and sets up registers A2 = global vector,
A5 = DOS kernel action routine from ROM, and A6 = DOS kernel cleanup
routine from ROM, from locations which are also in the library positive
offsets, and puts the appropriate action address from the global vector
table into A4.
The ROM is now invoked by JSR (A5), and deals with the call. This
often involves constructing the appropriate "packet" for the DOS
call in question, sending it to the right process, and waiting for
a reply indicating successful completion or an error. Note that
D1, D2, D3, and D4 are used to pass values to AmigaDOS. Results are
returned form the ROM action routine in D1, then transferred to D0
for return to the calling program.
PROCESSES
=========
A Process is the basic structure used to control multi-tasking in
AmigaDOS. It is built on the Exec concept of a Task, and consists
of an Exec task control block, a message port, and some things
needed by AmigaDOS. A process can be distinguished from a task
by the task control block's node type which will be either
NT_PROCESS or NT_TASK. The process message port is used by AmigaDOS
for its own "packet" based communication between processes.
The other things following the message port include the current
directory lock for the process and the current input and output
"streams" (handles for the current input and output files).
Anything which calls AmigaDOS directly or indirectly (for example by
opening a disk-resident Amiga library or font) must be a Process
rather than a simple Task. Most of the Amiga's tasks are processes.
Workbench, CLI, the file system, and the handlers for AmigaDOS
devices (CON, PRT, etc.) are processes. The only simple tasks
are things such as Exec devices (printer.device, input.device, etc).
AmigaDOS refers to each process by its Process ID, which is an
APTR to the message port in the Process structure. This is
the pointer returned by CreateProc(). To find the Process structure
subtract the size of a Task structure from this APTR.
PACKETS
=======
The "packet" is the basic unit of message-passing in AmigaDOS and it
is built on the Exec concept of a "message". The part of the
message structure defined as pointer to a name is used instead to
point to a Tripos structure called a "packet", as follows:
APTR back to message structure
APTR to reply port
LONG packet type
LONG result1
LONG result2
LONG argument1
LONG argument2
etc.
AmigaDOS gets things done by sending "packets" like this to the
message-ports of appropriate processes such as file-handlers.
Note that you can also get things done by sending packets to
processes, instead of calling AmigaDOS library routines.
This is handy if you want to operate asynchronously.
COROUTINE
=========
Co-routine is a term from Tripos useful in understanding AmigaDOS.
The term means a routine which is executed as part of a particular
process, but using its own private stack instead of the process's
standard stack.
When a co-routine is about to be invoked, memory is allocated for
its stack by the process, the stack pointer is saved then altered
to point at this new stack, and the new stack is initialized to
contain its own size, plus a return address to the main process.
Then the co-routine is invoked. When the co-routine exits,
control returns to the main process code, which restores its
stack pointer to the old value and de-allocates the co-routine's
stack memory.
This technique is used by a CLI process to execute commands.
The fact that the process pushes the size of the stack to the
new stack is significant here, as it means that you can check
if you've been given enough stack space, and refuse to run if
you haven't.
CLI
===
A CLI is a Process with some special attributes including:
a CLI number (1 to 20)
standard input and output streams (usually a CON: device)
a path list to use when searching for command files
a prompt string definition
default stack size for co-routines
The CLI provides a user interface, executes commands typed in at
the keyboard or read in from a file and provides IO redirection.
Some special setup is needed to start a CLI (initializing input
and output streams etc.), and another process is needed to do
this. It is important not to confuse the process which creates
a CLI (such as the CLI tool you click on from Workbench) with
the actual CLI process once running. The standard code for
handling the CLI environment is in KickStart.
COMMANDS
========
A "command" is code which is executed from a CLI process when it is
invoked by name, usually loaded from a disk file with the same
name as the command. AmigaDOS looks for commands in the current
or specified directory, or in the C: directory. Under 1.2,
it is possible to specify further directory paths to be searched
for commands by using the PATH command.
Commands are executed as part of the CLI process from which they
are invoked. Stack space for the command's use is allocated and
control is passed to the code at the start of the first segment
of the command's code. On entry to the command's code, the
registers contain:
A0 a pointer to the command line for execution
D0 the length of the command line
Other registers contain defined, but not documented, values.
These are irrelevant to command written in C or assembler.
However, commands written in BCPL will expect to be entered
with these registers properly initialized:
A1 BCPL stack pointer
A2 global vector
etc., very much as set up by the DOS "action" routine explained
above. This explains why it is not possible, for example, to
load NewCli or DiskEd with Wack and execute them with GO, since these
registers will not contain the appropriate values.
Commands run as co-routines under the CLI will generally start with
some form of standard startup code (eg LStartup.obj or AStartup.obj)
which amongst other things deal with obtaining the current CLI
input and output streams, and using them to set up their own IO
vectors such as C "stdin" and "stdout". There is a significant
difference here between programs started from CLI and those
started from Workbench. A program started from Workbench is a
separate process, rather than a co-routine of CLI, and has no
default input or output stream. Some startups (such as LStartup)
provide these streams by opening a CON: window on the Workbench.
Commands are not required to preserve any registers, and the main
process can not rely on any being preserved when the co-routine
exits.
REDIRECTION
===========
When a CLI process obtains a command line for execution, it checks
for redirection specifications in the form of AmigaDOS file or
device names preceded by < (input redirection) or > (output redir.).
The CLI will attempt to perform the requested redirection, so that
the current input and output streams are those asked for, before
control is passed to the command's code. The command will only
respond to the redirection if it uses the default input/output
streams (stdin/stdout in C) for its IO.
DEVICES, DEVICES, and DEVICES
=============================
Like "library", the word "device" is somewhat overworked on the
Amiga, being used to refer to 3 different things:
1. Exec device (as in OpenDevice(), trackdisk.device)
2. AmigaDOS device, which is an interface between AmigaDOS
and an Exec device (as in SER:, DF0:, PRT:)
3. Logical AmigaDOS device name
a. an AmigaDOS device as in #2
b. the volume name of a disk (such as Extras:)
c. a directory with a sytem or user ASSIGNed logical
device name (such as C:, SYS:, THISISMEFOLKS:)
HANDLER PROCESSES
=================
AmigaDOS devices (as in #2 above) have associated processes for
performing the actions required of them. These can be compared
with the associated tasks used by some Exec devices such as the
console.device, and are known as handler processes.
The AmigaDOS function DeviceProc() allows you to obtain the
Process ID for the handler process of a named AmigaDOS device.
example: df0handlerID = DeviceProc("DF0:");
Handler processes generally have the same name as their device
but without the colon. However, this is not always the case.
The floppy disk handlers (for DF0:, DF1:, ...) are each called
"File System". The handler for a CON: window is called CON.
Each open CON: or RAW: window will have its own handler, so
it is commaon to have many processes with these names present.
One cannot use DeviceProc() to find the handler process for a
CON: or a RAW: because there may be more than one handler for
the specified device.
Handler processes speend much of their time in wait states,
waiting to receive AmigaDOS packets at their message ports
asking them to perform some action, such as reading or writing
data or closing a file. They then perform the required action,
then reply the packet to the sender.
---------------------------------------------------------------
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Carolyn Scheppner -- CBM >>Amiga Technical Support<<
UUCP ...{allegra,caip,ihnp4,seismo}!cbmvax!carolyn
PHONE 215-431-9180
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=phillip@cbmvax.cbm.UUCP (Phillip Lindsay) (12/18/86)
> In article <8612152348.AA29410@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > > > > NOW LOOK C-A, I'VE ENOUGH OF THIS SH#$%%T. WILL YOU *PLEASE* POST > >DOCUMENTATION ON BCPL STARTUP AND ALL THE STRANGE THINGS IT DOES TO THE > >STDIO FILEHANDLES SO WE CAN WRITE AN EXEC() THAT WORKS!!!. I thought I had > >gotten an exec() that worked, but no, when I modify it to APPEND to the > >output file instead of CREATE/TRUNCATE, the BCPL program fails to write > >everything to the file. Why the hell you didn't add this to the 1.2 DOS > >library I'll never know. > > > > -Matt > > I've had more than enough of your SCREAMING and CURSING. > > You act like we're hoarding some Magic Document that would endow the > reader with Instant Knowledge of the Glorious Inner Secrets of AmigaDOS. > > Well Matt, there is no magic document. I wish there was. > What we have is the AmigaDOS source code. > > BCPL is a bit like C, and it is possible to decipher and even > make changes to localized portions of the code. But when you > start to trace code that interfaces with the private global functions > via run-time linking, you get stopped by tables of labels and vectors > that specify numerical offsets into other tables that are built at > run time. And if you manage to make it to the other side of the > table because a corresponding label on the other side happens to > have a similar name, you get stuck there because because that code > starts loading registers with labels defined as offsets into the > run-time table. > > So, you can either pay Tim King to reveal the inner secrets, > or wait until someone here has time to decipher a very large and > very complex program that jumps all over the place. > > carolyn > -- > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Carolyn Scheppner -- CBM >>Amiga Technical Support<< > UUCP ...{allegra,caip,ihnp4,seismo}!cbmvax!carolyn > PHONE 215-431-9180 > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Let me add one thing to Carolyn's response: Tim King is currently working on improving the file system through put. (Which he has done. [as reported on BIX]) The next thing on Tim's list (according to Tim King himself) is documentation on how to write a CLI (what everyone has been waiting for). CLI does not start a new process, but simply loads a code segment and runs it-- And on exit returns to the CLI. -- ============================================================================== Phillip Lindsay - Commodore Business Machines - Amiga Technical Support UUCP: {ihnp4|seismo|caip}!cbmvax!phillip - Phone: (215) 431-9180 No warranty is implied or otherwise given in the form of suggestion or example. Any opinions found here are of my making. /* eof */
rokicki@navajo.STANFORD.EDU (Tomas Rokicki) (12/18/86)
> (Matt Dillon) writes: > > NOW LOOK C-A, I'VE ENOUGH OF THIS SH#$%%T. WILL YOU *PLEASE* POST > >DOCUMENTATION ON BCPL STARTUP AND ALL THE STRANGE THINGS IT DOES TO THE > >STDIO FILEHANDLES SO WE CAN WRITE AN EXEC() THAT WORKS!!!. Howdy, Matt! You've got a disassembler; you're a hacker; let's see you figure it out. It's really not that bad (I've been pulling apart the WCS a little lately) and it is sure fun. I've been using Manx db for this. -tom
wilkes@beatnix..UUCP (John Wilkes) (12/19/86)
In article <1136@cbmvax.cbmvax.cbm.UUCP> carolyn@cbmvax.UUCP (Carolyn Scheppner) writes: > > This is for everyone but Matt Dillon who has been rather rude lately. > > I've spent the past three days typing this in between phone calls >and after hours. I even had to type the first hundred lines in >twice because our VAX went down before I had saved the file. > {{{ lots of juicy info deleted }}} >-- >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >Carolyn Scheppner -- CBM >>Amiga Technical Support<< > UUCP ...{allegra,caip,ihnp4,seismo}!cbmvax!carolyn > PHONE 215-431-9180 >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Carolyn, I love you. Thanks for this (and all your previous and future) contributions to comp.sys.amiga. You are generally one of the first on the net with answers (when they exist). You have earned the eternal affection and gratitude of all net-Amigoids. As for Matt, don't worry about him, he suffers from UMS (ugly mood swings). -- John Wilkes -- UUCP: {ihnp4|decwrl|pyramid}!sun!elxsi!beatnix!wilkes USPS: ELXSI, 2334 Lundy Pl., San Jose CA 95131 # My Employer appologizes for the fact that I have access to the network. # Furthermore, my Employer has absolutely no responsibility for the above # random ramblings, which are clearly the product of a deranged mind.
keithe@tekgvs.UUCP (Keith Ericson) (12/19/86)
In article <1135@cbmvax.cbmvax.cbm.UUCP> carolyn@cbmvax.UUCP (Carolyn Scheppner) writes: >In article <8612152348.AA29410@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >> >> NOW LOOK C-A, I'VE ENOUGH OF THIS SH#$%%T. WILL YOU *PLEASE* POST >>DOCUMENTATION ON BCPL STARTUP... >> -Matt > > I've had more than enough of your SCREAMING and CURSING. > > You act like we're hoarding some Magic Document that would endow the >reader with Instant Knowledge of the Glorious Inner Secrets of AmigaDOS. Well, maybe not a "reader" in general, but Matt seems to be a cut above the average Amiga user! > > Well Matt, there is no magic document. I wish there was. Somebody screwed up the contract with the AmigaDos writers :-) > What we have is the AmigaDOS source code. Oh boy oh boy oh boy. I'm glad somebody has it! > > BCPL is a bit like C, and it is possible to decipher and even >make changes to localized portions of the code. But when you >start to trace code that interfaces with the private global functions >via run-time linkin... > > So, you can either pay Tim King to reveal the inner secrets, (see comment on contracts, above) >or wait until someone here has time to decipher a very large and >very complex program that jumps all over the place. sounds like a good job for a computer... >carolyn Carolyn - do you really get paid to take all this abuse? CBM probably doesn't realize the bargain they're getting. ---------------------------------------------------------------------- Hey everybody: Have a [pick the greeting of your choice:] Merry Christmas! Happy Hannukah! (I hope I spelled it correctly) Great Vavation! keith
news@cit-vax.Caltech.Edu (Usenet netnews) (12/20/86)
Organization : California Institute of Technology Keywords: From: tim@tomcat.Caltech.Edu (Tim Kay) Path: tomcat!tim In article <1962@tekgvs.UUCP> keithe@tekgvs.UUCP (Keith Ericson) writes: >In article <1135@cbmvax.cbmvax.cbm.UUCP> carolyn@cbmvax.UUCP (Carolyn Scheppner) writes: >> What we have is the AmigaDOS source code. > >Oh boy oh boy oh boy. I'm glad somebody has it! C-A could publish the source code.... Timothy L. Kay tim@csvax.caltech.edu Department of Computer Science Caltech, 256-80 Pasadena, CA 91125
wilkes@beatnix..UUCP (John Wilkes) (12/21/86)
In article <1393@cit-vax.Caltech.Edu> tim@tomcat.UUCP (Tim Kay) writes: >In article <1962@tekgvs.UUCP> keithe@tekgvs.UUCP (Keith Ericson) writes: >|In article <1135@cbmvax.cbmvax.cbm.UUCP> carolyn@cbmvax.UUCP (Carolyn Scheppner) writes: >|< What we have is the AmigaDOS source code. >| >|Oh boy oh boy oh boy. I'm glad somebody has it! > >C-A could publish the source code.... ....on floppies! %^)# -- John Wilkes -- UUCP: {ihnp4|decwrl|pyramid}!sun!elxsi!beatnix!wilkes USPS: ELXSI, 2334 Lundy Pl., San Jose CA 95131 # My Employer appologizes for the fact that I have access to the network. # Furthermore, my Employer has absolutely no responsibility for the above # random ramblings, which are clearly the product of a deranged mind.
keithd@cadovax.UUCP (Keith Doyle) (12/22/86)
In article <199@elxsi.UUCP> wilkes@beatnix.UUCP (John Wilkes) writes: >Carolyn, I love you. Thanks for this (and all your previous and future) >contributions to comp.sys.amiga. You are generally one of the first on the net >with answers (when they exist). You have earned the eternal affection and >gratitude of all net-Amigoids. As for Matt, don't worry about him, he suffers >from UMS (ugly mood swings). >-- John Wilkes -- UUCP: {ihnp4|decwrl|pyramid}!sun!elxsi!beatnix!wilkes Hear hear (and Merry Christmas or Happy Holidays), Keith Doyle # {ucbvax,ihnp4,decvax}!trwrb!cadovax!keithd # cadovax!keithd@ucla-locus.arpa
sean@ukma.ms.uky.csnet (Sean Casey) (12/24/86)
In article <1393@cit-vax.Caltech.Edu> tim@tomcat.UUCP (Tim Kay) writes: >C-A could publish the source code.... I've seen the developer's manuals. I've seen the Addison Wesley publications. I've seen just about everything else on AmigaDOS and everything else (and I don't even own one yet :-) ). It's a *miracle* that anyone has gotten anything to work. If someone shoved the documentation at me and said "write me a device driver", I think I'd cry. It is the worst, most disorganized documentation that I have ever seen. Don't get me wrong. I think the Amiga is the best thing since sliced bread, but C-A really needs to hire some real documentation writers and produce some good, well ordered, well exampled manuals on the internals of the dos and hardware. One of the reasons software appeared so quickly for the IBM PC is that IBM offered a decent set of manuals. It appears that C-A is waiting for a third party to do just that. I really think this is wrong, and unfair to the people that buy their machines and software. It's also just plain bad business, as IBM will tell ya. To the C-A people on the net: please don't take this personally. I'm not blaming you. It would be kind of nice if you hinted to the people upstairs that the Amiga developers would be willing to pay for some good documentation. At least the situation is not as bad as it is with the Atari ST. From what I've seen, there are some hackers that know more about the thing than the people that designed it. Sean BTW: BCPL???!! Why in God's name BCPL? What's wrong with C? -- =========================================================================== Sean Casey UUCP: cbosgd!ukma!sean CSNET: sean@ms.uky.csnet ARPA: ukma!sean@anl-mcs.arpa BITNET: sean@UKMA.BITNET
sean@ukma.ms.uky.csnet (Sean Casey) (12/24/86)
In article <1393@cit-vax.Caltech.Edu> tim@tomcat.UUCP (Tim Kay) writes: >C-A could publish the source code.... I've seen the developer's manuals. I've seen the Addison Wesley publications. I've seen just about everything else on AmigaDOS and everything else (and I don't even own an Amiga yet :-) ). It's a *miracle* that anyone has gotten anything to work. If someone shoved the documentation at me and said "write me a device driver", I think I'd cry. It is the worst, most disorganized documentation that I have ever seen. It's so bad that one really *does* need the source code to figure out what the hell is going on. Don't get me wrong. I think the Amiga is the best thing since sliced bread, but C-A really needs to hire some real documentation writers and produce some good, well ordered, well exampled manuals on the internals of the dos and hardware. One of the reasons software appeared so quickly for the IBM PC is that IBM offered a decent set of manuals. It appears that C-A is waiting for a third party to do just that. I really think this is wrong, and unfair to the people that buy their machines and software. It's also just plain bad business, as IBM will tell ya. To the C-A people on the net: please don't take this personally. I'm not blaming you. It would be kind of nice if you hinted to the people upstairs that the Amiga developers would be willing to pay for some good documentation. At least the situation is not as bad as it is with the Atari ST. From what I've seen, there are some hackers that know more about the thing than the people that designed it. Sean BTW: BCPL???!! Why in God's name BCPL? What's wrong with C? -- =========================================================================== Sean Casey UUCP: cbosgd!ukma!sean CSNET: sean@ms.uky.csnet ARPA: ukma!sean@anl-mcs.arpa BITNET: sean@UKMA.BITNET