informis/textfiles
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Initial commit

Browse Source
This commit is contained in:
root@procul
2021-04-15 13:31:59 -05:00
commit 278a90f7ce
57951 changed files with 34606208 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
programming/AMIGA/020_asm.txt
+1767
View File
File diff suppressed because it is too large Load Diff
programming/AMIGA/881_asm.txt
+1303
View File
File diff suppressed because it is too large Load Diff
programming/AMIGA/a5000.txt
+115
View File
@@ -0,0 +1,115 @@
***************************************************************************
****************** First reports of the A5000 *************************
***************************************************************************
Commodore have gone for much like the A2000 large case to contain the power
of this new machine. on the front panel it supports two 3.5" drive (one as
standard) and two 5.25" (one holding a CD-Drive). This is the first machine
to really support multi-tasking with it's three processors on board.
Processors
----------
The A5000 will incorperate the new motorola 68060 + two 68EC040 processors,
the '060' is clocked at over 35MHz and the two '040' clocked at 25Mhz
will give the A5000 a total speed at over 60MHz. The '060' with sit on a
seperate card in the cpu slot (as in the A4000) and both the '040' will
sit on the motherboard. The '040' have been design to help the '060' ,this
will be most evident at times of heavy multi-tasking. As a result of this
configuration the A5000 will have a new kickstart.
Kickstart/Workbench
-------------------
The A5000 will have kickstart/workbench 4.0 (beta version has 3.2). This
kickstart is required to control the three processors , earlier kickstarts
will not be able to access the '040' (but the '060' can). This kickstart
will not be released for the older machines although 4.1 will. This
kickstart/workbench will enable the '040' to be assigned to different tasks
and as shiped one will handle all screen and sound processing and the other
will handle all of the I/O devices. This kickstart is a 1Mb chip and will
be shipped on the hard drive (to be confirmed). If it is released in chip
form then the chip will be placed on it's own card. This kickstart will have
a user-selectable kickstart screen so the user can select which kickstart to
load (either in slot or on harddrive) and the A5000 has been tested with
kickstart 1.2 upwards so there will be no more compatability problems.
Chipset
-------
Commodore have done it again in changing the chipset as there are several
new chips. The A5000 with workbench 4 is now capable of operating in all
modes with a 512 colour pallet. To maintain the speed require to operate
in this mode one of the '040' can be assigned to the screen display (as
it is shipped). The maximum screen resolution is 4096 x 4096 with over
32 million colours on screen. This new chipset will be able to detect which
chipset it should use (orig. ,ECS ,super-ECS or AGA , super AGA ) by
detecting which kickstart is currently running or which is selected at a
cold boot.
Ram
---
As the new chipset has a higher resolution and more colours more chip ram is
required and commodore have responded by having 16Mb of chip ram on the
motherboard (expandable to 64Mb) and 16Mb of fast ram (theoretically
expandable to 1024Mb, tested to 256Mb). The chip and fast ram have been
organised on a 32-bit wide structure as in the A3000 + A4000.
Drives
------
The harddrive interface is the new scsi2 standard with a 210Mb slimline
hardrive mounted as standard. The floppy drive is a high density type and
the CD-drive is a standard A2000 internal drive.
Sound
-----
The sound is now 16-bit as the A4000 was supposed to have.
Internal Connectors
-------------------
There are eight zorro III expansion slots with three IBM slots in parallel
with three zorro slots. There is no cpu slot as the '060' is on it's own
board and thus can easily replaced. If the kickstart is to be shipped on
the harddrive there will be an empty slot to place a new kickstart.
External Connectors
-------------------
It has all the standard ports (disk drive, serial, etc.) and the keyboard
connector (same pins as the A4000) at the back, the mouse ports are on the
right side towards the back.
Price
-----
Well that depends on what pack you want as as of this moment there are two
1 all above = $3499 (Appox.)
2 all above plus
Amax v3.0 Mac emulator (100% compatable with all known software) +
Golden gate IBM emulator = $3999 (Approx.)(uses two zorro III slots)
This information has been confirmed by Commodore.
|-THiS FiLE PASSED THR0UGH --- /\ ---.------ /\ ---*--.- FiDONET 2:200/612 --|
| . * . // \ . // \ . FUJiNeT 7:102/102 |
| I.C.S Swedish HQ // \ + // \ . MeGANeT 66:666/1 |
| + // / \ // \ + NeST 90:1101/112 |
| Sync World HQ /\\ \\ / . // \\ / |
| . // \ \/ // /\/ . 16800 DUAL STANDARD |
| +46-451-91002 \\ / / \\ \/ + |
| * \\ / + . \\ \ . . . |
| . \\ / \\ / |
|- SysOp: Troed ------------ \/ARCASTIC -- \/XISTENCE --- CoSysOp: Zaphod B -|
< Advertisment added using -=Bad Ad=- 1.91 by Troed/Sync. BBS: +46-451-91002 >
programming/AMIGA/acos.txt
+1071
View File
File diff suppressed because it is too large Load Diff
programming/AMIGA/adocengl.txt
+575
View File
@@ -0,0 +1,575 @@
ADoc - User's Manual
AboutThisDoc
This manual describes release 4.00 of the utility ADoc. This program
is (c)1990-1994 by Denis GOUNELLE, any commercial usage or selling without
author's written authorization is strictly forbidden. You can copy and
spread this program under the following conditions:
- all the files are provided
- the files are not modified in any way
- you don't charge more than $6 for copy fee
In spite of several tests, no warranty is made that there are no
errors in ADoc. YOU USE THIS PROGRAM AT YOUR OWN RISK. In no event will I be
liable for any damage, direct or indirect, resulting of the use of ADoc.
AREXX is (c)1987 by William Hawes.
PowerPacker 2.3b is (c)1989 by PowerPeak and Nico FRANCOIS
PowerPacker Pro 3.0b is (c)1990 by PowerPeak and UGA Software
The "powerpacker.library" library is (c)1990 by Nico FRANCOIS
The "reqtools.library" library is (c)1990 by Nico FRANCOIS
>>> CLOSE THIS WINDOW TO CONTINUE <<<
Foreword
ADoc2 is a new release of ADoc, fully rewritten in order to remove
some limitations and add several improvements. Note some incompatibilities
arose particularly at argument level. This program works equally under 1.3
and 2.0 system releases.
ADoc is an utility that allows you to manage all kinds of
documentations on any subject. It is able to automatically start searching
for a word selected by a mouse click, and to work on several documentation
files at the same time. ADoc can also use straight the AutoDocs and
AmigaGuide files, as well as "PowerPacker" compressed files.
Criticisms and suggestions will always be welcomed. Write to:
M. GOUNELLE Denis
27, rue Jules GUESDE
45400 FLEURY-LES-AUBRAIS
FRANCE
You can also send a message to the following Internet address :
"gounelle@alphanet.ch". Note that this mailbox is not mine, so please send
only short messages. As I don't have direct access to the messages, don't
expect an answer before a dozen of days.
Thanks to Jean-Yves PROUX and Helmut J. ESENWEIN for their numerous
suggestions, to Reza ELGHAZI for his help concerning AmigaGuide files, and
to Simon HEWINSON who translated in English the "amiga.doc" file. Special
thanks to Jean-Philippe RAPP for his ideas and his help concerning AutoDocs
files.
Installation
ADoc needs "reqtools.library" (version 2.0c or higher) to run. You
must copy this file in your "LIBS:" directory, if not yet done.
ADoc is now localized, so it can adapt itself to your favorite
language. All you have to do is to copy the good catalog file into the
directory corresponding to your language. For exemple, if your default
language is french, copy the "français.catalog" into the
"SYS:Locale/Catalogs/Français" directory, under the name "ADoc.catalog."
The german catalog was translated by Stefan SALEWSKI.
HowDoesItWork
ADoc works on documentation files, combined with a keyword (this one
is named "term" in this doc). Every doc file has an index file that allows
to access the wanted terms nearly immediately. (Note : as a result, each
time you change a doc file, you'll have to rebuild its index file.) When
ADoc is running, only is loaded in memory the index file. The name of this
index file will be the doc file name plus an ".index" suffix.
You can create your doc files with your favourite text editor; these
files consist of a series of definitions and each definition has a syntax as
follows :
term
text line 1
text line 2
etc...
text line n
At first, consider that the first two lines of a doc file have to be
empty (or in extreme circumstancies begin with a space or a tab character).
The first character of each term must be at column 1 and the text lines must
begin with a space or a tab character. Empty lines are allowed.
One term can't be more than 32 character long and can't contain any
blanks or tabs : valid characters are upper or lower letters, digits,
underline, and accented letters (ASCII codes between 217 and 246). However,
if needed, you can extend this character set (see below AdvancedConcepts).
The term amount for each file as well as the text line amount for
each term are unlimited (or rather, this limit is so large that you'll be
short in memory long before).
A text line can't be more than 256 characters. In order to bring out
some parts of your text, you can use the following ANSI sequences :
ESC[1m boldface on
ESC[3m italics on
ESC[4m underline on
ESC[22m boldface off
ESC[23m italics off
ESC[24m underline off
ESC[0m normal character set
RunningADocfromCLI
ADoc can be run from Workbench or from the CLI. By default, the doc file is
"Amiga.doc", but, of course, in both cases, you can specify another
filename. From the CLI, you can specify the following arguments :
WBENCH
Asks ADoc to use the Workbench screen. When this argument is missed out,
ADoc will open its own screen sized as the Workbench screen. On error,
when opening screen, ADoc will go automatically to the Workbench screen.
LACE
Asks ADoc to use an interlaced screen. If you asked to use the Workbench
screen, and this one is not in interlaced mode, this argument will be
ignored.
DEPTH n
Asks ADoc to use a n-planes screen (allowing 2^n colors). If you asked
to use the Workbench screen, this argument will be ignored.
FONT name
Asks ADoc to use a given font rather than the default one. Name must
take the form <FontName><SizeY>, for ex. "topaz8". ADoc is able to use
any non proportional font so long as its size is 8 at least.
If ADoc can't open the requested font, it will attempt to use the
default one. If this font doesn't suit or ADoc can't open it, it will
try to access the topaz8 font. If it fails, ADoc will end immediately.
MAKEIDX
Tells ADoc the only operation to do is to create the index files.
QUICK
Asks ADoc not to display a text combined to the "AboutThisDoc" term,
when starting. Usually, each time ADoc opens a file, it looks for the
"AboutThisDoc" term in this file, and then, if this one exists, displays
the corresponding text and waits for user to close the window before
continuing.
AREXX
Asks ADoc to go in AREXX mode. More information on how to use ADoc with
AREXX in TheAREXXMode section below.
ONEWINDOW
Asks ADoc to open only one window at a time.
NOCASE
Asks ADoc not to differentiate lower and upper characters when
processing files. This only will concern files whose name is given after
this option.
NOSORT
Asks ADoc not to sort the indexes of files whose name is specified after
this option.
TABSIZE n
Tells the tab size for the files whose name is specified after this
option. Default size is 8.
Any other argument will be considered as a doc file name to be used. You can
specify several files, by separating their names by spaces or commas (for
ex. "ADoc file1 file2" or "ADoc file1,file2"). You can mix file names and
options but let us remember that NOCASE, NOSORT, and TABSIZE options only
concern files you specified after these options. ADoc will open these files
in this given order. Unless you indicate one full path, firstly files will
be looked for in the current directory, then in the "ADOC:" one. If you
specify a directory name instead of file name, ADoc will open all the files
in this directory (apart from ".info" and ".index" files).
RunningADocFromWorkbench
From Workbench, you can inwoke ADoc in several ways :
- by double-clicking on its icon (then ADoc will use the default
documentation file)
- by double-clicking on one file icon having ADoc as default tool (field
"DEFAULT TOOL")
- by clicking on icons of several files, holding down the SHIFT key, and
double-clicking on the ADoc icon.
In all these cases, ADoc starts by looking into "TOOL TYPES" field of the
program icon; this one may contain :
FONT=name
DEPTH=n
OPTIONS=[WBENCH][LACE][MAKEIDX][QUICK][AREXX][ONEWINDOW]
For more information on these options, see the RunningADocfromCLI section.
Note option names must be separated by a "|" sign. After that, ADoc will
open the doc files you specified; it will open them as it does from CLI
except it examines the "TOOL TYPES" field of each icon. This field may
contain :
TABSIZE=n
OPTIONS=[NOCASE][NOSORT]
For more information about these options, see the RunningADocfromCLI
section. Note these three options only will concern the file corresponding
to the icon.
StartingADoc
As I explained above, ADoc starts by opening some specified file(s).
At this time, ADoc attempts as well to open the index file corresponding to
each doc file. If you didn't specified any file to open, ADoc will look if
the "ADocFile" variable is defined : if so, it's value is used as a file
name. Otherwise, the default file name is "Amiga.doc". You can specify
several file names is the "ADocFile" variable, just as from command line
(for example: setenv ADocFile "exec.doc dos.doc").
If ADoc can't find the index file, it will offer to create it. If
you refuse, this doc file will not be usable but, in spite of it, ADoc will
attempt opening other files.
If ADoc detects a doc file was changed after an index was created,
it will offer to update the index file. If you refuse, in spite of it, the
doc file will be opened but later ADoc will be able to detect errors if the
file contents was changed. Note the date of index file creation is stored in
the index file itself.
Once all files are opened, ADoc will display a requester; this one
indicates the term list of first open file. We'll describe how to use this
requester in the TheTermRequester section.
TheTermRequester
A term can be pointed out by a mouse click on it. Now this term is
displayed in a different colour. If you click a second time on it, the
requester is switched off and ADoc displays in a window the text
corresponding to that term. I'll describe how to use these windows in
HowToManageWindows section.
To choose a term, you can use the keyboard too. If you press any
key, the key letter will be added to the current "prefix" (displayed in a
rectangle below the term list), and ADoc will display the list starting from
the first term that begins with this prefix. ADoc will complete this prefix
as far as possible. If you press the <BACKSPACE> key (above the <RETURN>
key), the last prefix character will be deleted and the list will be updated
too. If you press the <RETURN> key, ADoc will display the text corresponding
to the first term that begins with this prefix. Note ADoc will not
differentiate upper and lower letters when the current file is indicated
after a NOCASE option.
You can close the requester without selecting a term both by
pressing the <ESC> key and by clicking in the close gadget either. If no
window is open at this time, the program will abort.
In fact, a term requester can allow you to select from among three
lists : the term list of the current file, the list of the opened files (if
you have several opened files) and the list of terms that ADoc found during
the previous search operation (provided a search was made before, see the
Search section below).
At the bottom, on the right corner of term requester, you have a
letter showing what a list is displayed : term list (T), file list (F), list
of found terms (S).
To pass from a list to another, click the right mouse button holding
down one of the <SHIFT> keys, or press the <TAB> key. When the file list is
displayed and you select a file in this list, ADoc returns automatically to
the term list and displays the list of terms in that file.
When no window is open, the term requester has a menu with the
following options :
Open window see TheSpecialMenu below
Search see the Search section below
Iconify see the TheProjectMenu below
Quit this one allows to quit ADoc.
HowToManageWindows
When you select a term, ADoc opens a window to display the
corresponding text. When a term is defined several times either in a single
file or in several different files, all text lines will be joined in a queue
and displayed in one window. The window height is dependent on the amount of
lines ADoc must display. If there are too many lines, only the first page
will be displayed and ADoc will add two arrow gadgets (on the right top
corner) for scrolling this text.
Of course, you can have several windows opened at the same time. In
this case, the window which was activated when opening a new window is
called the "parent window" of the new one.
By default, these windows have standard close, dragging, back and
front, and sizing gadgets. If you change the size of a window, ADoc, if
needed, will add or remove automatically the arrow gadgets. Each window has
three menus too : there are "Project", "Tools" and "Special" menus (I'll
describe these ones in TheProjectMenu, TheToolsMenu and TheSpecialMenu
sections, below). Finally, note ADoc recognize the following keys :
HELP list keys and their meaning
ESC close the current window
UP previous page
DOWN next page
BACKSPACE open parent window
Shift-UP previous term
Shift-DOWN next term
When you click on a word, this one will be displayed in a different
colour. If you click again on the same word, ADoc will automatically start
searching for the corresponding term in all open files. If this fails,
screen flashes, otherwise a new window will be brought up.
TheProjectMenu
Other term
Bring up the term requester (see above TheTermRequester).
Print
Print the text contained in the active window. Note : the possible ANSI
sequences will be correctly interpreted by the printer.
Iconify
Leave ADoc sleeping : if ADoc opened its own screen, this one will be
closed, all the windows will be switched off and then ADoc will open a
small window on the left top corner in the Workbench's screen. If you
click on the close gadget of this window, ADoc will ask you to confirm
it before you abort. For "awaking" ADoc, activate this window and click
the right mouse button.
Normally, ADoc keeps in memory all the text lines to be able switching
on quickly all the windows when it would be awaken. The one drawback is
that all possible memory will not be freed, so, when you ask ADoc to
iconify itself, ADoc will ask you if you want to close all windows. If
you say yes, the memory will be completely freed and when ADoc will be
awaken, it will bring up the term requester.
Help...
Displays some useful keys and their meaning (same as pressing the HELP
key)
About...
Display some infos about ADoc. Click inside this window or press a key
to continue.
Quit
Allow to quit ADoc (asks you to confirm it).
TheToolsMenu
Front Screen
Allow to use ADoc in a already open screen (for ex. that one of your
text editor). Only you need to move the screen -where you want switch on
ADoc- in front of any screen, drag it down to unfold the screen where
ADoc is. Now, select this item : ADoc will close all the open windows
and reopen these ones in the foreground screen.
CAUTION:
Of course, you'll have a "Guru" if the screen where you
placed ADoc is closed before you quitted ADoc (or placed
this one on another screen). 
Note this command will not work if you did not specify a font (see above
the RunningADocfromCLI section) and the font of your front screen
doesn't suit.
Close all
Allow to close all the windows at the same time. After it asked you to
confirm, ADoc will close every window and display the term requester.
Find
Allow to start searching (see the Search section below).
Information
Display the account of avalaible files and terms, just as the account of
opened windows and displayed lines. To continue click on the "Ok"
gadget.
TheSpecialMenu
Open file
Allow to open an additional doc file. A file requester is brought up so
that you can specify what a file must be opened.
Close file
Allow to close the current file (i.e. the file where is defined the term
displayed in the active window). After it asked you to confirm, ADoc
will close all the windows relied to this file and will close it. Note
this command will work only if at least two files are opened.
One window
If this option is selected, ADoc will open only one window at a time.
Search
In the text lines, ADoc has the capability to search up to four
strings simultaneously and display then the list of the relied terms. When
you select the "Search" item in the "Tools" menu, a window is switched on
with four string gadgets. You have also an "CANCEL" gadget, to abort this
operation, a "OK" gadget, to start your search, and an "Options" menu :
low = UPP
Ask ADoc not to differentiate upper and lower letters when searching.
All strings
Normally, ADoc is looking for all terms containing one of the strings
you introduced. On the contrary, this item allows you to search for
terms contaning ALL strings you specified.
All files
Ask ADoc to search in all open files, not only in the current file.
When you start your search, a requester appears. The "Stop" gadget
allows you to break this search. As soon as the search finished, screen will
flash if no term was found. Otherwise, the term requester will be switched
on and will display a list of found terms. That list is sorted, and kept in
memory until you stard a new search.
AdvancedConcepts
Since v4.00, you can associate an IFF picture to a term. This
picture will be loaded at the same time as the text, and will be displayed
in the same window. In order to use this fonctionnality, you just have to
add a special line in the term's text :
. adoc@<position> <picture's name>
where <position> is "top", "bottom", "left" or "right". The picture will be
displayed in the given border. For example, if you enter :
. adoc@right doc:exec/schema1.pic
the picture "doc:exec/shema1.pic" will be displayed next to the right border
of the window.
ADoc is able to load pictures in a different screenmode and/or
colors numbers than the current screen. The screen's palette will be
modified with the picture's palette.
The release 1.40 of ADoc introduced the concept of aliases, that is
a manner to associate a same text to several terms, without having to repeat
the text several times. An alias definition follow the syntax:
name1 alias name2
The first character of "name2" must, as for any term definition, be at
column one. There must be at least one space or tabulation between the three
words. The word "alias" must be in lower case characters. The effect of such
a definition is that when the user will ask to get the "name1" term, ADoc
will automatically display the "name2" term instead. Aliases appear in the
term requester, and in the search function. You must be aware that there is
*NO* recursivity check between aliases !
An application of aliases could be the documentation of a function
library : often you will define several functions together. With the
aliases, you can allow access to the definition by the name of each
function, but the text is defined only once.
ADoc can combine automatically several doc files. For that, it's
enough to specify the name of file(s) to be combined, in the first line of
file which you want associate them with. If this line is empty or begins
with a space or tab, its contents will be ignored. File names have to be
separated by spaces or commas. You can indicate a directory name; in this
case all the files of that directory will be opened (except ".info" and
".index" files).
To extend the character set you can use in a term, it's enough to
specify additional characters in the second line of your doc file. If this
line is empty or begins with a space or tab, its contents will be ignored.
Otherwise, all characters of that line (up to first space, tab, slash or
form feed) will be added to the default character set. Note this character
set extension only will concern that file.
ADoc has the possibility to load directly any compressed
"PowerPacker" file, providing you have set up "powerpacker.library" in your
LIBS: directory. It's not necessary (but recommended) to create the index
file before you compress a doc file. ADoc will refuse to load an encrypted
file.
After ADoc has decompressed a file, this will be copied in a
temporary file in the "T:" directory. So, using compressed files can arise
some memory problems, especially if you put T: directory in your RAM: disk.
This temporary file will be deleted when you close it.
TheAREXXMode
ADoc always opens a compatible AREXX port, named "ADoc_rexx".
Messages on this port are waited for at the same time as Intuition messages
on text windows, and can take the following forms :
QUIT quit ADoc
REQUEST bring up the term requester
FSCREEN ADoc moves all it's windows to the front screen
TOFRONT put ADoc screen in front of all screens
TOBACK put ADoc screen in back of all screens
FIND term start searching for a given term, and display the
corresponding text if it is found
OPEN file allows to open a other file while running ADoc
The return code (RC variable) will be set to zero, except in the
following cases: bad request (return code 20), "OPEN term" request with
"term" not found (return code 5), "request" request and no term choosen
(return code 5). Here is an example asking for help for the term "alias" :
/* Ask for help for "alias" */
ADDRESS "ADoc_rexx"
"FIND alias"
IF RC = 5 THEN SAY "not found !"
Note quotes surrounding commands !
If you launch ADoc with the option AREXX, the program operation will
be quite different : once ADoc opened the doc file(s), it will not switch on
the term requester but will display a message "Waiting for an AREXX message"
and will wait for messages on the AREXX port (or for CTRL-C to abort it).
Moreover, when the last window will be closed, the program will not end
itself but go back waiting for AREXX messages.
AutoDoc_files_support
ADoc can recognize and use the AutoDocs files from Commodore. In
most cases, no change are needed, but it is recommended to verify their
format: you must have at least two empty lines at the beginning, followed by
the table of contents and every term must start at column 1.
In some cases, you won't find empty lines at the beginning, and
terms will begin at column 2 and will be preceded by a "form feed" character
(i.e. CTRL-L). The program "AutoConvert", distributed with ADoc, will allow
you to convert those files into a correct format (Note : this program can
only be used from CLI). In all other cases, you'll have to convert these
files by yourself.
AmigaGuide_files_support
ADoc can now recognize AmigaGuide files, build their index files,
and display their contents. The different syntaxes of the "@node" directive
are handled :
@node name
@node "title"
@node name "title"
In the latter case, an "name" alias is automatically defined for the "title"
term. The "@title" directive is also handled.
As ADoc doesn't handle spaces in term names, they are replaced by
underscore characters. Links within text are displayed in boldface. As names
are truncated to 32 characters, some links may fail. Note that ADoc handles
inter-files links, like:
@{"foo" link help:general/bar}
To allow such links, delimiters are automatically set to ":/." for
AmigaGuide files.
TheADocMessages
When an error occurs, ADoc displays in a small window a name
(usually, a filename) and an error code. This one is either an AmigaDOS
error code or an internal code. In the first case, see your AmigaDOS Manual
(or use the command "Fault") to have more information on this error code.
There are the internal error codes :
-1 empty file
-2 read error
-3 file is wrong (bad format, etc...)
-4 file is compressed and there is no "powerpacker.library"
-5 a problem occured while decrunching
-6 bad picture specification
-7 error while loading picture
programming/AMIGA/adsrules.txt
+510
View File
@@ -0,0 +1,510 @@
AMIGA DISTRIBUTION SYSTEM
(PRELIMINARY RELEASE)
Original Dated: 06-Apr-90
Current Revision Date: 29-Oct-91
Version: 1.11
_______________________________________________________________
PURPOSE and INTRODUCTION
_______________________________________________________________
o What is it?
- The OFFICIAL Amiga Software Distribution System.
- The OFFICIAL Non-Backbone Amiga ECHOmail Distribution System.
o The purpose?
- To provide a means of distributing and announcing
the release of Amiga Public Domain (PD)/Shareware/Freeware
Programs/Files, that are not normally distributable
through the SDS, to nodes interested in Amiga only
files.
- To provide a means of distributing Non-Backbone Amiga Related
ECHOmail Message Areas.
o General concept?
(File Echos)
- The ADS will consist of three echo groups.
- First a Read ONLY communication echo conference known as
AMIGASOFT. This echo will be for release announcements
of posting into the ADS File Echo areas [usually by the
POSTER] and ADS system news posted by the Coordinators
and Uplink Hubs. Chris Adams (1:308/80) is the moderator
of AMIGASOFT.
- Second. There is an ADS general chatter echo also
available (for feedback, questions, etc.) called:
AMIGA_SYSOP. Since the other echo is (basically) read-
only, this echo is the place where you may post questions,
etc. This is a SysOp ONLY echo, and is available via
the (Zone 1) backbone. It is also available at all ADSHUBS
and other nodes. The one exception to the SysOp ONLY
restriction is for non-SysOps who have posted files into
the ADS System. This will provide a forum through which
these authors can provide information and receive
feedback. SysOps of connected Nodes are requested to
provide access to this echo for any member contributing
to the ADS through their BBS (if such node cannot gain
access to it via their regular backbone feed.
- Third, a series of file distribution echos. These
'echos' are not like 'message echos'. Basically, they are
'AREAS' defined in your TICK configuration, that you have
selected to be linked to.
- Files will be distributed using the TICK format software.
For the Amiga, use the AmigaTick program by Russel Miranda
at 1:268\106 (available also at any ADSHUB). If you run
your system in an MS-DOS environment, use TICK by Barry
Geller @1:266/12
o Official name: Amiga Distribution System
o Known as the: "ADS"
o Area prefix: ADS (Example ADSPARAG = ADS Paragon files)
8 characters maximum
o Amiga Distribution System File Echos
TAGNAME DESCRIPTION
------- --------------------------------------------
ADSANIMS Amiga Animation Files & Utilities
ADSCANDO CanDo Related Programs, Decks & Utilities
ADSCBNWS Amiga User Group Newsletters
ADSCOMM Communication (Terms/BBS's/etc)
& ADSFIDO Amiga Networking and Point Files
ADSGAMES Games
ADSINFO OFFICIAL ADS Information & News
ADSMISC Non-Developer Submitted Files
ADSNETDV Network Developer Source/Documentation
ADSTEXT Text Files
!& ADSWORK Workbench 1.3 Utilities
* ADSWORK2 WorkBench 2.0 Utilities
(BBS Related File Echos)
& ADSDLG DLG Professional BB/OS Support Files
ADSPARAG Paragon BBS Support Files
ADSSTARN StarNet BBS Support Files
ADSTRANS TransAmiga BBS Support Files
ADSXENOL XenoLink BBS Support Files
* = New Area
& = Changed Tagname since last release of rules
! = Formerly ADSUTILS
More may be added at a later date. Remember that these only
exist in your tick.cfg file, and are NOT message bases.
--------------------------------------------------------------
o Amiga Distribution System Message Echos (ECHOmail) 10/16/91
TAGNAME DESCRIPTION MODERATOR
------- ----------------------------- ------------------
AMIGATALK General Amiga Discussion
AMIGA_BBS Amiga BBS Discussion
AMIGA_BRIDGE Amiga BridgeBoard Discussion
AMIGA_CANDO Amiga CanDo Support
AMIGA_INFO Amiga Information
AMIGA_OS Amiga Operating Systems
AMIGA_UG Amiga User Group Discussion
PM Point Manager Support
XENOLINK_INFO XenoLink BBS Information
XENOLINK_UTIL XenoLink BBS Utilities
MAILSTORM MailStorm Support
SKYLINE SkyLine BBS Discussion
SKYLINE_INFO SkyLine BBS Information
# TRANSAMIGA TransAmiga BBS SysOps Support
# = Requires Special Access
o Official Language. The official Language to be used for the
ECHOmail areas (AMIGASOFT, AMIGA_SYSOP) *and* all files and
descriptions is ENGLISH. A program may have additional language
versions contained within the archive, but there MUST be an
English version.
o One message echo for all file announcements. Read ONLY!
__________
Tagname of: AMIGASOFT
Primary purpose: To announce new files being distributed
through the ADS.
Secondary purpose: As a ADS system notification and news
communications echo conference.
NOTE: ALL sites carrying the AMIGASOFT echo are to make SURE
that it is READ-ONLY to those who do not Hatch files.
All software releases must have an accompanying message posted
into the AMIGASOFT echo, announcing it's availability. These
messages should take the following format:
o Posting the Software Announcement Message
Subject: <filename>
Software Announcement!
============================================================
Filename:
ADS Area:
Filesize:
Origin:
[2-3 PARAGRAPH description of what this file does]
Author:
[Hatched on: <date>]
============================================================
[end of suggested announcement format]
o ADSVAULT(s)
Purpose: To provide a library of files beyond the first
week after it's release into the ADS.
General Concept: ADSVAULTs will be ADSHUB's that will provide
the storage of ADS released files that
will be made available for FREQ'ing or
Downloading.
Scope: The offical ADSVAULT will be Midwest Information Network
(1:232/301) and will always be know as the ADSVAULT. HUBS
and other nodes may become a "ADSVault.XXX" (where
.xxx is the HUB number - e.g. Midwest Information Network
being HUB#1 would also be ADSVAULT.001, etc.). To become
an ADSVAULT.XXX the node must be approved by the
ADS Coordinator (This is automatic for ADSHUBS, and
optional for other affiliated nodes).
o ADSHUB(s)
Purpose: To provide a centralization of distribution for
both uplinks and downlinks.
General Concept: ADSHUBs will be nodes that will provide
file distribution in different regions of
the distribution network. They will also
be have the ability to approve file 'HATCHs'
into the system.
---> Message Echo Dist. Info (MD)<---
Scope: Only approved nodes may become an ADSHUB. Approval
by the coordiantor is required. HUBS must hold all
file releases for a minimum of thirty (30) days after
released. FILES MUST BE MADE AVAILABLE FOR FREQ'ING
AND/OR DOWNLOADING DURING THAT PERIOD. Hubs will be
have the responsibility to 'HATCH' new releases into
the system, as well as monitoring any hatch that may
come from a 'downstream' link.
____________________________________________________________
RULES and GUIDELINES
____________________________________________________________
1. NO COMMERCIAL PROGRAMS ALLOWED. Public Domain (PD)/Shareware/
Freeware only. Beta/Gamma/Full-release software will be
accepted into ADS. Version identifiers must be included in
either the filename or description or both.
2. Only defined ADSHUBS or Authorized Nodes can contribute
files. (Authorized nodes will need the permission of the
Zone coordinator or ADS Administrator PRIOR to releasing
files into the network.)
3. All file submissions to the ADS must be sent to one of
the above Nodes or an authorized ADSHUB unless prior, NETMAIL
approval has been obtained from the Zone Coordinator or the
ADS Administrator. Any software developer interested in
submitting their program(s)/file(s) through the ADS is strongly
encouraged to do so, *BUT* you must contact EITHER the coordinator
OR your immediate upstream ADSHUB prior to release. Neither the
Administrator NOR the Zone Coordinators are responsible for the
quality or duplication of any file.
THE COORDINATORS WILL NOT BE HELD RESPONSIBLE FOR ANY DAMAGES
CAUSED BY ANY FILE SENT OVER THE ADS.
The coordinators WILL make every effort felt appropriate to
prevent the distribution of copyrighted commercial software/
files. The Coordinators will NOT be held responsible for the
mistaken distribution of any copyrighted software/files.
4. The decision to distribute any file is at the sole discretion
of the Zone Coordinator, ADSHUB, or the ADS Administrator.
Disagreements should be submitted via Netmail to the ADS
Administrator (see above). The decision made will be final.
5. Any downward link MUST be removed at the instruction of the
ADS Coordinator. Current Fidonet Policy documents will serve
as a guideline to moderate the AMIGASOFT and AMIGA_SYSOP
echos and all the then current file echoes (distribution
echos).
6. Nodes MUST carry both the AMIGASOFT echo and the AMIGA_SYSOP
echo. Nodes will not be required to be linked into more than
ONE file distribution echo in order to qualify as an ADS node.
A node may link to as many or as few File Echoes as they
choose, however the node is required to receive both ADS file
transfers and the AMIGASOFT from the same location. A node may
not receive File Echos from more than one location.
7. Downward links must be established by the nearest ADSHUB, or the
ADS Zone Coordinator ONLY. They will be responsible for passing
on the rules to the new ADS site. Nodes establishing downward links
are required to send notification to the nearest ADSHUB via a NetMail
message to inform them of any new ADS node, noting (at the very
least) the Net/Node address and the Echos being received.
8. Upward ADS links can only be established by a Coordinator.
Only the Coordinator(s), approved developers, and ADSHUBs
may hatch files into the ADS network.
9. Developers may gain blanket authorization (good for any
software they release) by submitting for approval from
their Zone Coordinator. An appeal structure will consist of
sending a Netmail Message to the ADS Administrator's
system. All decisions by the ADS Administrator are final.
10. All ADS nodes are requested to display the letters "ADS"
(ADS) in their * Origin: lines so as to identify themselves
as an approved ADS site.
11. All files distributed via the ADS will have a descriptive
file attached with it. The descriptive file will contain the
filename, file description (a one-liner) and the seen-by
listings. This file will have an extension of:
.TIC
Filenames must not exceed 8 characters plus 3 characters for
an extension. Only one '.' may be used per filename. All non-
conforming filenames will be put on HOLD by the coordinator
pending response by the system entering such file into the
network.
12. To minimize storage space and online costs, as well as the
maintenance of a consistant storage format, all submissions
must be in the LHArc format with the filename consisting of
an up to 8 character name, the character '.' and the suffix:
.LZH
13. All links (both downlink and uplink) will be required to use
a password. Intention is to eliminate as many possibilities
of some 'unknown' node submitting a 'trojan horse' or an
unapproved file into the system.
14. The ADS Administrator reserves the exclusive right to alter,
ammend or append these rules at any time and without the
requirement of prior notice. The ADS Administrator will endeavour,
circumstances permitting, to notify all affected parties
prior to making any such changes, but will in no way
guarantee such notification.
15. Initial notification and distribution of new releases will
be available through direct connection with the closest
ADSHUB site to your location.
16. Midwest Information Network (1:232/301) will be known as the
official Master ADSVAULT. The purpose being to provide a library of
all ADS released files. Files may be FREQ from the Coordinator or Hub
location for the first 30 days after a file has been released.
After the first 30 days the only location that will be guaranteed
to have the file will be Midwest Information Network (1:232/301).
Although the file may still be available at many other locations, the
ADSVAULT will have it available for the an extended period of time
after the first 30 days of release.
[Special Note #1: ADS and AMIGASOFT were originated by Steve
Peoples (1:150/111 <disconnected 07-July-90>) and Frank Dixon
(1:150/160 <disconnected 02-July-90>). Frank and Steve have
both left the BBSing world and FidoNet, but it is felt proper
recognition was appropriate at this time. (RW)]
[Special Note #2: Roger Walker (1:280/222) then served as ADS
Administrator until early 1991, when his system was dismantled,
and since has been reformed. Hopefully Roger will continue to
be involved in ADS in the near future? (MD)]
_________________________________
ADS Administration/Hub Locations
_________________________________
ADS Administration Board
________________________
1:232/301 - Midwest Information Network - Michael DeBerg - ADS Administrator
1:163/109 - AmigaTronix - Russell McOrmond - Director
1:108/250 - HellFire Club - Chuck Baker - Director
3:640/463 - Sidecar BBS - Brendan Pratt - Director
ADS Zone Coordinators
_____________________
Zone 1 - 1:232/301 - Midwest Information Network - Michael DeBerg
Zone 2 - O P E N
Zone 3 - 3:640/463 - Sidecar BBS - Brendan Pratt
Zone 4 - O P E N
Zone 5 - O P E N
Zone 6 - O P E N
[Special Note: The Zone 1 Coordinator position is available, and applications
will be taken in the near future. Zones not yet supported are
also available.]
ADSHUBS
_______
Approved Sites as of 26-Oct-91
NOTE: Please make sure your information is correct, because we will be
updating the ADSHUB information as necessary. Please use the
information contained in the ADSHUB #1 section (BELOW).
====================================================================
1:232/301 - Midwest Information Network - Michael DeBerg - ADSHUB #1
Zone 1 Region 11 - Bloomington, Illinois (USA)
Modem: US Robotics Dual Standard - 14,400 HST/V.32bis/V.42bis
Frontend/Mailer: BinkleyTerm [v2.40]/QMail [v1.0]
2:204/112 - South Bridge Computer BBS - Tommi Jansson - ADSHUB #2
Zone 2 - Orebro, Sweden - 9600 HST
Frontend/Mailer: ??
2:310/30 - Sub Etha Net - Johannes Mistelbauer - ADSHUB #3
Zone 2 - Baden, Austria - 9600 HST
Frontend/Mailer: BinkleyTerm [v2.40]
2:251/2000- My First BBS - Nick Lello - ADSHUB #4
2:251/32 Zone 2 Region 25, Haywards Heath, Sussex, UK - 9600 HST
Frontend/Mailer: Paragon [v2.08]
1:308/80 - Kustom Kastle BBS - Chris Adams - ADSHUB#5
Zone 1 Region 15 - Alamagordo, New Mexico (USA)
Modem: US Robotics Courier HST - 14,400 HST
Frontend/Mailer: Paragon [v2.08]
1:367/9 - Opus Amicus - Efrain Coldero - ADSHUB#7
8:999/1 Zone 1 Region 18 - San Juan, PR USA 14,400 HST
Frontend/Mailer: BinkleyTerm [v2.40]
1:163/109 - AmigaTronix - Russell McOrmond - ADSHUB#8
Zone 1 Region 12 - Ottawa, ON Canada
Modem: US Robotics Dual Standard 14400 HST/V.32bis/V.42bis
Frontend/Mailer: BinkleyTerm [v2.40]
1:260/327 - Gary's BBS - Gary Gulliver - ADSHUB#9
Zone 1 Region 1 - Fulton, NY USA 14,400 HST
Frontend/Mailer: Paragon [v2.08]
1:344/17 - NCRL (North Central Regional Library) Electronic Library -
Howard Purcell - ADSHUB#10
Zone 1 Region 17 - Wenatchee, WA, USA 9600 HST/DS
Frontend/Mailer: FrontDoor [v2.0]
3:633/359 - Crazy Diamond - Chris Quonoey - ADSHUB#11
Zone 3 Region 50 - Melbourne, Victoria, Australia
Modem: Netcomm M5 - 9600 v32
Frontend/Mailer: TrapDoor [v1.80]
2:333/305 - Amiga_PD BBS - Michele Masiero - ADSHUB#12
Zone 2 Region 33 - Padova, Italy (14,400 HST/DS/V.42)
Frontend/Mailer: Paragon [v2.08]
3:640/463 - Sidecar Express BBS - Brendan Pratt - ADSHUB#14
Zone 3 Region 54 - Brisbane, Queensland, Australia
Modem: NetComm TrailBlazer 19200 PEP/9600 v32
128:400/463 Frontend/Mailer: Star-Net [v1.0]
2:509/30 - Starleght BBS - Joerg Henner - ADSHUB#15
Zone 2 Region 24 - Stuttgart, West Germany (14,400 HST/DS)
Frontend/Mailer: Star-Net [v1.0]
2:230/114 - Valby Amiga BBS - Carsten Lohmann - ADSHUB#16
Zone 2 Region 23 - Valby, Denmark (14,400 HST/V.42)
Frontend/Mailer: Paragon [v2.08]
1:396/36 - Amiga Gateway - Mark Rippa - ADSHUB#17
Zone 1 Region 19 - New Orleans, La., USA (9600 HST)
Frontend/Mailer: TrapDoor [v1.80]
1:273/912 - Tri-Star Amiga - Joe Mollica - ADSHUB#18
Zone 1 Region 13 - Philadelphia, PA., USA (14,400 HST/V.42)
Frontend/Mailer: Paragon [v2.08]
1:255/0 - Atlantic Access - Bill Walton - ADSHUB#19
1:255/1 Zone 1 Region 12 - St. John, New Brunswick, Canada (9600 HST)
Frontend/Mailer: Binkleyterm [v2.30]
3:680/829 - Adelaide Amiga User's Group - Jonathan Potter - ADSHUB#20
Zone 3 Region 50 - Adelaide, South Australia
Modem: Netcomm E5 - 9600 v32
Frontend/Mailer: Paragon [v2.0858]
3:670/305 - Pointless BBS - Andrew Bricknell - ADSHUB#21
Zone 3 Region 50 - Tasmania, Australia.
Modem: Netcomm M5 - 9600 v32
Frontend/Mailer: DBridge [v1.30]
3:714/909 - The Amiga Connection - Mario Nicotra - ADSHUB#22
Zone 3 Region 54 Sydney, New South Wales, Australia
Modem: US Robotics Dual Standard - 14,400 HST/V.32
Frontend/Mailer: Paragon [v2.0858]
1:3613/7 - AMIGeorgiA BBS - Jack Mowery - ADSHUB#23
Zone 1 Region 18 - Columbus, Georgia, USA (HST)
Frontend/Mailer: Paragon [v2.08]
* 1:141/105 - Amiga Connection - Dave Lenardo - ADSHUB#24
Zone 1 Region 16 - Hamden, Connecticut,
Frontend/Mailer: Paragon [v2.08]
* 1:203/104 - Another BBS - Andy Wood - ADSHUB#25
Zone 1 Region 1 - Sacramento, CA. USA (HST)
Frontend/Mailer: Paragon [v2.08]
(* = New node, or net address recently changed.)
NOTE: We are still looking for systems for Regions/Zones that aren't
currently supported who would like to become ADSHUB sites. If
you are interested please send Netmail to Michael DeBerg at
(1:232/301) with the particulars on your system.
------------------------------------------------------------
A SPECIAL NOTICE
____________________________________________________________
A very special thinks goes to Brendan Pratt (3:640/463) and Russell
McOrmond (1:163/109) for their help in making some corrections to
this version of the Rules & Guidelines.
------------------------------------------------------------
DISCLAIMER
____________________________________________________________
All hardware/software items mentioned within this document are
trademarks of their respected companies/authors.
programming/AMIGA/aflwhq.msb
+14
View File
@@ -0,0 +1,14 @@
_¡__ __ _____ __ _____¡__¡_____._____.__.__._____._____._____¡
:! \/¯¬Y _¯¬Y__Y _¯¬!::! ___Y _¯¬Y T¯¬Y _¯¬Y _¯¬Y __¬!
:¦ | T |__| T ¦::¦___¯¬| T | | | 7 | T__| _T_¦
:| | _ |¯¬| | |::|¯¬T | | | l | _ _| l¯¬| T¯¬|
:l__\/ l__T |__|__| |::l_____|_____|_____|__T |_____|_____|
:::::l_/:::l_/::::::l_/-AFL WHQ::::::::::::::::l_/:::::::::BBS:
.-------------------------------------------------------------.
¦4.2 GiGS + 2 GiG DAT + /XPRESS v3.xx (REG) + A4000/040/25mhz ¦
| -:- -:- |
| NoDE 1 -> [215]/426-9461 + 21.6k USR DS <-- . RiNGDoWN . |
| NoDE 2 -> [215]/426-7238 + 21.6k USR DS <-- : oN ALL : |
: NoDE 3 -> [215]/426-6719 + 16.8k USR DS <-- : FoUR : :
¦ NoDE 4 -> [215]/426-8248 + 16.8k USR DS <-- ` NoDES! ' ¦
`-------------------------------------------------------------'
programming/AMIGA/amiga12
+249
View File
@@ -0,0 +1,249 @@
Path: menudo.uh.edu!menudo.uh.edu!usenet
From: easton@andrews.edu (Jeff Easton)
Newsgroups: comp.sys.amiga.reviews
Subject: REVIEW: Commodore Amiga 1200 computer
Followup-To: comp.sys.amiga.hardware
Date: 3 Jan 1993 04:21:17 GMT
Organization: The Amiga Online Review Column - ed. Daniel Barrett
Lines: 233
Sender: amiga-reviews@math.uh.edu (comp.sys.amiga.reviews moderator)
Distribution: world
Message-ID: <1i5pjtINNo3t@menudo.uh.edu>
Reply-To: easton@andrews.edu (Jeff Easton)
NNTP-Posting-Host: karazm.math.uh.edu
Keywords: hardware, system, A1200, commercial
PRODUCT NAME
Commodore Amiga 1200 computer
BRIEF DESCRIPTION
Commodore's latest release, the A1200, packs most of the features of
the A4000 into the keyboard. Sporting a 68EC020 CPU, AGA chipset and 2 MB
of Chip RAM and selling for $599.00, the unit hits the mark for the home
buyer looking for a good product at a reasonable cost.
AUTHOR/COMPANY INFORMATION
Name: Commodore Business Machines
Address: 1200 Wilson Drive
West Chester, PA 19380
USA
(Non-USA readers should contact the branch of
Commodore in their country.)
Telephone: (215) 431-9100
LIST PRICE
$599.00 (US dollars)
DESCRIPTION
The A1200 is Commodore's newest Amiga personal computer. It is
based on the new AGA graphics chipset first seen in the A4000 series. The
system comes packed into a keyboard console similar to the A600. Imagine a
A600 unit that includes a numeric keypad and cursor keys and you will have a
picture of the A1200. The CPU used is the 68EC020, and the system comes
standard with 2 MB of chip memory. All the usual ports are on the back
panel, and there is a trap door expansion slot on the bottom of the unit.
One 880K floppy drive is on the right side of the unit, and a PCMCIA
expansion slot is on the left.
DELIVERABLES
The A1200 system comes in a white box measuring 23" x 17" x 6"
(inches) with the "Commodore Amiga 1200" logos printed on it. Additionally,
on the front face of the carton is a checklist area for the configuration
of the computer inside. Check boxes are available for the following
eight configurations;
No HDD 60 MB
200 MB 40 MB
120 MB 20 MB
80 MB __ MB
Inside, the A1200 console is wrapped in an anti-static bag with foam
endcaps securing it in the front of the carton. Directly behind the
console, a cardboard inner box contains the external "brick" power supply,
the mouse, a 15' coaxial cable with RCA plugs on both ends, and a TV antenna
switch box. Underneath the CPU is the manual pack containing the A1200
Users Guide, the Workbench 3.0 Users Guide, an Errata Sheet on the video
adapter, and a disk pack. The disk pack contains 5 disks from the WB 3.0
set; Workbench, Storage, Extras, Fonts, and Locale. Packed on top of the
CPU is an envelope containing the warranty registration card, and a seven
page stapled "AGA Graphics Supplement".
DOCUMENTATION
The documentation consists of the A1200 Users Guide and the
Workbench 3.0 Users Guide. Additionally there are two errata sheets.
The A1200 Users Guide is a 40-page booklet that describes setting up
and using the hardware. Chapters are provided on the following subjects;
Quick Connect
Getting Started
Before Expanding Your System
Using PCMCIA Cards
Help With System Problems
Technical Specifications
Input/Output Connector Pin Assignments
Using Floppy Disks
Amiga Character Set
There are no schematics provided.
The manual does a decent job of telling the user how to set up and
use the system. It is interesting to note that in several places the manual
alludes to a "Factory Installed FPU" option and that "Chip RAM on 1 MB
machines can be expanded to 2 MB of 32 bit memory with an internal expansion
module. This expansion module can also contain a battery backed clock
calendar." More on this later.
The Workbench 3.0 Users Guide is the standard manual from the 3.0
manual pack. Note that this is the only manual included. No Amiga DOS 3.0,
AREXX or Amiga Hard Drive manual was included. This may be because I bought
the no HDD model though.
The first errata sheet, printed in 10 different languages, basically
says that your A1200 does not come with the 23-pin-to-15-pin monitor adapter
mentioned in the Users Guide. It can be ordered from your dealer. Since I
needed the adapter, I had my dealer include one for an additional $15.00.
The second errata document is a seven page supplement that tries to
explain the AGA video modes and the monitor types. Its a good thing they
provided this, as the other manuals often completely ignored parts of this
information.
SOFTWARE
The software provided was the standard Workbench 3.0 disk pack, with
the notable exception of not providing an Install disk. Without this disk,
the user is incapable of adding a hard disk to his system at a later date.
I will assume that the HDD configured models come with this disk.
Since I was installing my own hard disk, I brought along my copy of
the Workbench 2.1 upgrade disk pack which contains an Install disk. Thus I
was able to run HD Toolbox and the 2.1 Install script to partition the drive
and install 2.1. I'm not looking forward to manually installing 3.0.
In Commodore's defense, the hard disk installation is supposed to be
performed at a dealer. It would be nice if they provided the Install disk
just for completeness though.
HARDWARE
The 23-watt switching power supply "brick" is rather large for its
capacity, measuring 6" x 4" x 3". The power switch is on the brick, not the
CPU. I haven't taken the unit apart yet, but I'm assuming that it's half
empty inside. The unit is very lightweight for its size. I'm familiar
with laptop computer PSU's that are half the size and twice the capacity.
The mouse shipped with the A1200 looks similar to the A600 mouse,
except that it isn't the A600 mouse. It has a mushy feel to the key
switches, reminiscent of the original mouse shipped with the A1000. It is
molded in the new "off white" color to match the A1200 case (as well as the
A600 and A4000).
The main CPU looks like an A600 that has been stretched to include a
full keyboard.
The keyboard used has an International layout where there are two
extra keycaps: one located next to the Return key (now a reverse P style
instead of the normal (for the US) reverse L), and the other located next to
the left Shift key which has been shortened to accommodate it. I'm not sure
why Commodore chose to start this trend with the A1200. The A600 still uses
the US style Return key and I would assume that both keyboards are made by
the same vendor. The US A1200 keyboard does have the proper symbols on the
keycaps, unlike the A1200 pictured in Amiga World which had the English
pound sign, etc.
As noted earlier, the 880K floppy drive is on the right side and the
PCMCIA port is on the left. On the back panel, from left to right, are:
5-pin square power connector, RF modulator RCA jack, Composite video RCA
jack, DB23 pin video connector, L and R audio RCA jacks, Parallel port,
Serial port, Disk drive port, Game port 2 and Mouse port 1. Also on the
back panel next to the mouse port is a removable panel that can accommodate
up to a DB25 port (SCSI anyone? :-)). It looks like the card with the
connector is inserted from the back, with a connecting cable snaking under
the disk drive to the interface card plugged in the bottom trap door slot.
A screw hole is provided to secure the board.
On the bottom of the unit is a pop out panel that reveals the trap
door expansion area. A 200 pin edge card connector is provided on the
motherboard that the expansion board must plug into. This expansion
connector contains all the CPU signals plus some, unlike the A500 which only
contained enough address and data lines for the 512k expansion. It is
feasible that a memory/SCSI/CPU expansion card could live here. The only
problem is that the board area is limited to roughly 6" x 3". This severely
limits what you can put on a card.
To open up the unit, five screws must be removed from the bottom:
three along the front edge and one on each side. Removing the top of the
case and moving aside the keyboard reveals the main board. It is covered by
a "cookie sheet" RFI shield, with the exception of an access hole for the
two ROM's and another for the hard disk IDE connector.
In the center of the board is a small plate that is held down by two
tabs. Bending these tabs up and removing the plate reveals an access hole
for the Chip memory and real time clock on the main board. Clearly visible
on the motherboard are the component pads for a real time clock and battery,
but they are not populated. A micro header is located at one end of the
access hole, presumably where a real time clock upgrade might plug in. At
the other end, another header location is visible, although this one is
depopulated. A guess would be that if it was a 1 MB unit, this connector
would bring up additional signals for a combined clock/1 MB module. Since
my unit had 2 MB of memory soldered to the motherboard, this socket was
useless and thus was not populated.
The hard disk bracket was included, and it doubles as a keyboard
support. It was a simple operation to remove the bracket and install a 2.5"
IDE drive on it. You will need a 1" long ribbon cable with the proper micro
spacing connectors to plug the drive into the connector on the motherboard.
I would strongly advise against anyone trying to build a converting cable to
a 3.5" IDE HDD and running it out to an external drive. The interface
connector is on the left end of the motherboard and the access panel is on
the right end. This would require a cable at least 2 feet long and would
severely impact the signal integrity. A better solution would be to wait
for a future SCSI module to be designed by the likes of GVP.
I did not see any evidence of a FPU socket or pads for one. It may
be on another part of the motherboard that was obscured by the RFI shield.
BENCHMARKS
I'll let others perform some benchmarks. I'm of the opinion that
any benchmarks I performed would be nearly worthless. They would test the
speed of my hard drive and would not be representative of whatever hard
drive Commodore shipped.
I can say that the system feels pretty snappy, but that's probably
due to the AGA chip set and has been noted by others with A4000's.
--
___ ___ Jeff Easton easton@andrews.edu
(__ (__ Zenith Data Systems easton@zds-oem.zds.com
___) ___) Saint Joseph, Mich. j.easton@mi04.zds.com
Monte Carlo Z-LS/20 - Choice of a quiet generation
---
Daniel Barrett, Moderator, comp.sys.amiga.reviews
Send reviews to: amiga-reviews-submissions@math.uh.edu
Request information: amiga-reviews-requests@math.uh.edu
General discussion: amiga-reviews@math.uh.edu
programming/AMIGA/amiga401
+488
View File
@@ -0,0 +1,488 @@
Newsgroups: comp.sys.amiga.reviews
Path: menudo.uh.edu!usenet
From: koren@fc.hp.com (Steve Koren)
Subject: REVIEW: Commodore Amiga 4000
Message-ID: <1992Oct26.173622.22620@menudo.uh.edu>
Followup-To: comp.sys.amiga.hardware
Keywords: Amiga, computer, hot topic, commercial
Sender: amiga-reviews@math.uh.edu (comp.sys.amiga.reviews moderator)
Nntp-Posting-Host: karazm.math.uh.edu
Reply-To: koren@fc.hp.com (Steve Koren)
Organization: The Amiga Online Review Column - ed. Daniel Barrett
Date: Mon, 26 Oct 1992 17:36:22 GMT
PRODUCT NAME:
Amiga 4000
BRIEF DESCRIPTION:
This is a review of the Amiga 4000, the latest machine in the Amiga line
of personal computers from Commodore.
The machine as reviewed is:
Amiga 4000
Commodore 1960 Multisync Monitor
6 Mb RAM
68040 CPU/25 MHz
120 Mb HD
1.76 Mb floppy drive
"AGA" chipset
This particular machine was apparently one of the first 200 produced.
LIST PRICE:
Check with your dealer. The original MSLP is US$3699, but the street
price seems to be quite a bit cheaper. Prices certainly vary
geographically as well.
COMPANY INFORMATION:
Commodore Business Machines, Inc.
1200 Wilson Drive
West Chester, PA 19380 USA
(The machine is produced in England, and the keyboard and mouse are
produced in Malaysia).
OBTAINING THE MACHINE:
I had a very difficult time hunting down a place to buy a 4000. Four
successive calls to the "Commodore Dealer Locator" got me phone numbers
of supposed dealers, but in all cases the dealers either had gone out of
business, or no longer sold Amigas when I called. This was a bit
frustrating. After two weeks of searching, I eventually found a dealer
about 75 miles away by talking to someone who had bought an Amiga there
a while ago. The chore of finding the computer in the first place was
one of the few bad things I have to say about this machine. I don't
think most people would go through the trouble I did in order to buy the
system. I believe it would be beneficial for Commodore to 1) vastly
increase its dealer base in the US, and 2) keep its dealer database up
to date, since calling 8 non-existent dealers does not give a very
professional image of the company.
HARDWARE:
The 4000 comes in a desktop style case, a bit smaller than an Amiga
2000. The keyboard is essentially identical to the 2000's keyboard, but
mouse is a more rounded "beetle" style mouse, instead of the more
angular 2000 mouse. The 4000 has a key and lock which can be used to
shut off all keyboard and mouse input to the machine (including the
C-A-A reboot combination, but not including the power switch). The
power switch is on the front, along with LEDs for power and the internal
HD.
UNPACKING AND SETTING UP:
This task went very quickly and painlessly. The system as shipped is
essentially ready to plug in and go - the operating system is already
installed on the hard drive, and the hard drive is configured for
booting. There was just one small glitch on my machine - on some early
4000s, the hard drive was formatted in the OFS ("Old FileSystem")
format, which is substantially slower than the newer FFS ("Fast
FileSystem"). From what I hear, Commodore has since corrected this
problem. It was not much trouble for me to reformat the hard drive and
reinstall the operating system. Although this isn't a recommended
approach, I got through it with no trouble without reading the
documentation, just by booting the install disk and clicking on things.
The OS install utility is quite user friendly and intuitive, and you can
pick what parts of the operating system you do and do not wish to
install.
One thing I noticed immediately is that the 4000 is a quiet machine. My
old 2000 is fairly loud, and the 4000 seems to be only about half as
loud when running. The hard drive is essentially silent, and only the
fan can be heard, but it is quieter than the 2000's fan.
INITIAL SYSTEM CONFIGURATION:
The operating system originally boots in 640x200 mode, similar to a 2000
or 500. However, the AGA ("Advanced Graphic Architecture") chipset in
the 4000 supports many other higher resolution modes. There are monitor
configuration files that control the resolution and scan rate of the
various graphic modes supported by the 4000. The Workbench screen can
be run on any of these and changed by a tool in the preferences drawer.
After some amount of fiddling, I settled upon the "SUPER72 Super High
Res Interlace" mode. On my system, this mode gives a solid display of
896x628 pixels (which I'll round to 900x630 for simplicity, although it
is a 4x2 pixels short of that in reality). The scan rate in this mode
is 25 KHz, which is enough faster than the 15 KHz interlace modes in the
2000 that it seems to eliminate flicker. However, this might depend a
little on lighting conditions. When I booted the system in this mode at
the dealer, I could detect a bit of interlace flicker, but when I tried
this mode at home, the display appears quite solid. With my anti-glare
screen on the monitor, I cannot detect any flicker in this mode at all,
unless I look very closely for it. It certainly seems to be a genuinely
usable mode, quite unlike 640x400 on non-flicker-fixed A2000's. In
order to display it, I had to adjust the vertical size knob on the
monitor.
WORKBENCH 3.0
The Amiga 4000 includes a new release of the Amiga operating system.
Release 3.0 includes support for the AGA chipset of the 4000. The AGA
chipset can support up to 256 directly accessible colors in any
resolution mode from a 24 bit palette, and up to 252,208 simultaneous
colors in "HAM8" mode. (HAM8 mode is excellenct for graphics
applications, but isn't suitable for word processing or textual
applications).
The Workbench 3.0 screen can be configured to any depth from 1 to 8
planes. Depending on your resolution mode and tolerance to update
rates, you may find that anywhere from 4 to 8 planes provides a suitably
fast environment. In my 900x630 workbench (actually a 1024x768 virtual
workbench displayed in a 900x630 physical display), I find the update
rate adequate at 5 or 6 planes (32 or 64 colors). Seven and 8 plane
displays can get slow at this high resolution, but they do better at
lower resolutions such as 640x400. In fact, when I was playing with
this system at the store, I compared the interactive performance of the
4000 to a nearby 386/33 machine running windows 3.1. Both machines were
running 8 plane displays at an identical resolution, and the Amiga was
quite a bit faster than the 386 for window updates. Although I didn't
time either one, here is my subjective impression of the speed of the
4000 user interface compared to several other systems I have used a
reasonable amount. The rating factor is "snappiness", whatever that
means. Remember, this is subjective, and compares things like moving
windows, scrolling scroll lists (which depends less on resolution), the
speed with which windows pop up, etc. So graphics performance isn't
directly correlated with this, and "tricks" of the OS, such as AmigaDos
3.0's method of only scrolling needed bitplanes for CLI windows, can
affect things:
System & UI approx system cost "snappiness" of UI
-------------------------------------------------------------------
Amiga 3000, 1 plane WB, 640x400 $1K-3K 2.0
Amiga 3000, 2 plane WB, 640x400 $1K-3K 1.0
Amiga 3000, 3 plane WB, 640x400 $1K-3K 0.7
Amiga 4000, 4 plane WB, 640x400 $3K-4K 2.5
Amiga 4000, 4 plane WB, 900x630 $3K-4K 1.5
Amiga 4000, 5 plane WB, 900x630 $3K-4K 0.8
Amiga 4000, 8 plane WB, 900x630 $3K-4K 0.6
80386/33 clone, Windows 3.1, 800x600x8 $1K-2K 0.3
HP 720 workstation, 8 plane, 1280x1024 $8K-12K 3.0
Workbench 3.0 supports the use of IFF images as backgrounds for both
the workbench screen, and workbench windows. I currently have a
640x400 image of a bicycle in the background of my workbench (which is
a backdrop window), and have a smaller 320x200 image in the background
of my workbench windows. Although this doesn't provide any real
"functionality", it does look very nice and provides an easy way to
visually distinguish windows. The effect is quite pleasing. All
workbench windows share a common image, but since the edges of the
windows will tend to use many different colors, it is easy to see
where one window stops and another starts.
Workbench running on a 900x630 screen looks very nice. The extra
resolution allows the use of higher resolution fonts on screen, which
makes for a much more professional look. I am using a 20 point
Compu-Graphic Times font for my window titles, which is a readable size
on this display, a 15 point font as the system default, and a 15 point
proportional font for icons. The 15 point font takes about as much
screen real-estate as a 9 point font did on the 2000's 640x400 interlace
screen, but provides much more resolution for nice looking characters.
In addition, the display is much sharper and easier to read.
The display quality of the 4000's output is very high. Although my old
2000's display was inferior, I feel the 4000's output, when sent to a
suitably good monitor, is truly of workstation quality. I use a
1280x1024 Sony display attached to an HP workstation every day at my
job, and while it gives more resolution than the 4000 does, I don't
think the 4000 lacks anything in sharpness or clarity in comparison. In
fact, since most people with 4000s will probably use a 14" monitor,
900x630 is about as much resolution as is practical at this size. In
order to move to 1024x768, I believe that at _least_ a 16" monitor is
needed. Since there is a minimum physical size of text that is
comfortable to read, having more resolution on a small monitor meets
diminishing returns after a point. Larger monitors than 14" are quite
expensive.
At any rate, the 4000's display in 900x630 mode is, in a word,
beautiful. The only potential problem is that some people need a 10% or
so faster refresh in order to no be bothered by the interlace, but I
don't think this will be a problem for most people under most lighting
conditions.
AmigaDos 3.0 and the AGA chipset support HAM8 in any resolution mode.
This means that it is possible to have a 900x630 display in up to 252000
simultaneous colors from a 24 bit pallete, for near 24-bit quality
graphics. Further, it is possible to animate HAM8 graphics in any
resolution mode (although the practical limit is probably 640x400 due to
bandwidth restrictions in this generation of graphics chips). As far as
I know, there are no animation players yet which support HAM8 animation,
but that should change fairly soon. The few HAM8 still-frame images I
have seen look wonderful.
HARDWARE EXPANSION:
The 4000 has 4 card slots, one 5.25" drive bay, and two 3.5" drive bays.
The 3.5" bays can accept either two 1" tall devices each (for a total of
four 3.5" devices), or one larger device. Commodore ships the machine
with 1.5" tall devices, so you will need to replace one or both of them if
you wish to install 2 devices in each bay. Further expansion will need an
external case and power supply (which costs US$40-$85). The 4000 can use
Amiga 3000 Zorro-III cards, which gives it a good supply of expansion
devices already on the market, such as 64 Mb RAM cards. It can also use
Amiga 2000 Zorro-II cards, although these will not take advantage of the
4000's superior bus speed. The 4000's CPU is on a daughterboard and can be
upgraded when faster versions come out. There have been rumors of future
CPU boards with an on-board DSP. It is not yet known whether the 4000 is
upgradable to the next generation of AGA chips. I hope the answer is
"yes".
SOFTWARE COMPATIBILITY:
Most properly written applications seem to work fine under AmigaDos 3.0.
Immediately after powering up my 4000, I transferred my bare minimum
"working set" of software, which consists of the following:
SKsh 2.1 beta
GNU Emacs 18.58 (port by David Gay)
ISpell 3.1ljr (port by Loren Rittle)
Half a dozen commodities
All of the above installed and worked without any trouble at all, and in
fact, I am currently using GNU emacs and ISpell to type this review.
Emacs is talking to ISpell through ARexx without any trouble at all, in
exactly the same manner as on my 2000.
I have only tried a few software packages so far other than the above.
These I have found to work:
DPaint IV
Excellence!
A-10 Tank Killer 1.5
Most 2.0 freeware Commodities or utilities
I have tried a few PD "screen hacks" and such which failed on the 4000:
Oing! (a screen hack with bouncing ball sprites)
World (puts a 3d rotating globe in a workspace)
On the other hand, a few other screen hacks ("Wavebench") seem to work.
It seems a fair assessment that compatibility for properly written
software is very high, but games or utilities which break the rules
stand a good chance of not running under AmigaDos 3.0.
A number of popular AmigaDos software suppliers have already announced
AGA versions of their products, and a few are already on the market.
Since 2.0, software which opens custom screens should allow the user to
choose the monitor file for the screen resolution to be used. Such
software, even if written under 2.0, will run with the higher resolution
modes under 3.0 with no changes. However, some software which is not
that smart will still use old modes. If several screens each have
different scan rates, the multisync monitor will have to re-sync when
the user changes screens on the Amiga, which adds a slight delay of
about 0.5 sec. If a screen of one resolution is dragged partially down
over a screen of another, the front-most screen sets the scan rate of
the output.
OS 3.0 FEATURES & BUGS:
AmigaDos 3.0 supports object classes. I haven't had a chance to play
with these too much yet, but I can describe the basic concept. If, for
example, a desk top publishing program wants to load in an image for
inclusion in a document, it previously had to understand the format of
the image. I.e., it had to call the IFF shared library to read in IFF
images, or include code to read jpeg or GIF images if it wanted to read
those formats. If a new format came along, the program had to be
re-shipped. With AmigaDos 3.0 file classes, all that changes. A
program can read an image class, and AmigaDos will call the appropriate
handler to extract information from the image itself without the program
having to even know what type of image it is. Thus, if a new image type
called "zpeg" comes along, all that needs to be done is install a new
object class for zpeg images, and all the old software will be able to
suddenly understand the new image type. The same applies for sounds,
text, animations, and any other type of object. This is a powerful new
feature in AmigaDos 3.0 that has not been developed much yet, but has
great potential.
CLI windows in AmigaDos 3.0 seem to be smarter than they were in 2.0.
The console device, apparently, only scrolls the bitplanes that
absolutely need to be scrolled. This means that if you are just
displaying text in the standard color, the console device may only have
to scroll one or two bitplanes instead of the 5 or 6 there may be in
your screen. This makes using CLI windows fast even on deep workbench
screens. (Disclaimer: I don't know for sure that this is what is
happening but I suspect it quite strongly.)
There are some bugs in AmigaDos 3.0 yet. The "multiview" object viewer
crashes easily, and occasionally the palette preference tool does odd and
unexpected things to your palette. But overall, I have not yet found any
critical bugs which would prevent me from using the system. Most of the
ones I have found are just minor inconveniences which I'm sure will be
fixed for future versions of 3.0.
BENCHMARKS:
The following benchmarks compare the Amiga 4000 to:
- An Amiga 500, 68000/ 8 MHz, no fast RAM
- An Amiga 2000, 68000/ 8 MHz, fast RAM
- An Amiga 2500, 68020/20 MHz, fast RAM
- An Amiga 3000, 68030/25 MHz, fast RAM
The tests were all performed with AIBB_4.65, ("Amiga Intuition Based
Benchmarks", by LaMonte Koop). In all cases, the 3000/25 is used as a
comparison base:
Machine: 500/00 2000/00 2500/020 3000/030 4000/040
----------------------------------------------------------------------
Integer tests:
WritePixel 0.25 0.26 0.68 1.00 2.81
Sieve 0.11 0.11 0.56 1.00 1.11
Dhrystone 0.18 0.18 0.48 1.00 3.43
Sort 0.13 0.14 0.45 1.00 2.68
Matrix 0.10 0.11 0.52 1.00 1.52
IMath 0.05 0.05 0.51 1.00 2.29
Memtest 0.16 0.17 0.61 1.00 1.20
TGTest 0.50 0.52 0.82 1.00 1.44
InstTest 0.17 0.17 0.44 1.00 1.78
Float/Double:
Savage 0.01 0.01 0.51 1.00 1.19
FMath 0.05 0.05 0.40 1.00 4.72
FMatrix 0.14 0.14 0.46 1.00 1.04
Beachball 0.01 0.03 0.39 1.00 6.50 (!!)
SWhetstone 0.02 0.03 0.38 1.00 0.56
DWhetstone 0.02 0.02 0.37 1.00 3.40
FTrace 0.01 0.01 0.42 1.00 3.10
CplxTest 0.04 0.04 0.47 1.00 3.25
Generally, it can be seen that the 4000 averages about 2 to 2.5 times
faster than the 3000 for integer operations, and about 3 to 3.5 times
faster than the 3000 for floating point operations. For the Beachball
test (which ray traces a beachball on the screen), the 4000 is a
staggering 650 times as fast as an unexpanded Amiga 500, and about 215
times faster than an Amiga 2000 with fast ram. Most of the CPU bound
tests of the 4000 come out about 5 to 10% slower than my PP&S 68040 card
on my 2000, which runs at 28 MHz instead of 25. However, the 4000 feels
snappier in actual operation due to the AGA chipset. CPU board upgrades
to 33 and 40 MHz 68040s promise even more speed from the machine. The
CPU performance of the 68040, coupled with the AGA chipset's enhanced
color modes, make this essentially the perfect 3D rendering platform for
those who can't afford a Silicon Graphics workstation.
The following is a performance test of the 4000's internal disk drive
using DiskSpeed 4.1:
CPU: 68040 OS Version: 39.106 Normal Video DMA
Device: sys: Buffers: 128
Comments: Amiga 4000 internal disk
CPU Speed Rating: 3097
Testing with a 512 byte, MEMF_FAST, LONG-aligned buffer.
Create file: 26184 bytes/sec | CPU Available: 84%
Write to file: 26462 bytes/sec | CPU Available: 85%
Read from file: 158488 bytes/sec | CPU Available: 50%
Testing with a 4096 byte, MEMF_FAST, LONG-aligned buffer.
Create file: 157322 bytes/sec | CPU Available: 78%
Write to file: 163083 bytes/sec | CPU Available: 79%
Read from file: 213989 bytes/sec | CPU Available: 74%
Testing with a 32768 byte, MEMF_FAST, LONG-aligned buffer.
Create file: 329347 bytes/sec | CPU Available: 72%
Write to file: 375143 bytes/sec | CPU Available: 71%
Read from file: 559055 bytes/sec | CPU Available: 54%
Testing with a 262144 byte, MEMF_FAST, LONG-aligned buffer.
Create file: 429040 bytes/sec | CPU Available: 69%
Write to file: 550858 bytes/sec | CPU Available: 64%
Read from file: 909545 bytes/sec | CPU Available: 33%
Average CPU Available: 68% | CPU Availability index: 2106
Those needing more disk speed than this can get it when fast Zorro-III
SCSI cards become available. (Actually, Zorro-II cards can be used now
at some cost in speed). The speed of the internal IDE drive is
acceptable, although the CPU utilization gets a bit high during high
speed transfers. However, I doubt many people will notice this, and
SCSI is always available for those who need the high end.
WARRANTY:
The machine and monitor come with a "Commodore Gold Service" warranty. If
the machine breaks in a period of one year, they will pick it up for free,
fix it, and send it back also for free, by overnight express mail.
On-site service is available for a small, annual fee ($49 or $79).
PROBLEMS:
Aside from my initial difficulty in finding an Amiga dealer within a 3
hour drive of my house, I have had few problems with the 4000. Although
I have yet to try most of my old software, most of what I have tried has
worked. The only exception is that some games and a few "screen hacks"
have failed, but I expected that, and it isn't the fault of the 3.0
operating system, but rather the fault of the games themselves.
The 4000 could really use more than 2 Mb of chip ram. 4 Mb would be
appropriate.
There is really just one significant problem I have run into. The 4000
has a feature called "mode promotion", which does two things. First, it
attempts to force application screens that would have opened in 15 KHz
interlace mode to open at a higher scan rate to avoid flicker. Second,
it attempts to force application screens with a resolution of 200
vertically to "scan-double" their output and eliminate visible scan
lines. This effect is very pleasing - all those old 640x200 screens
suddenly are a lot more pleasant to look at. However, on my 4000, scan
promotion seems to force screens far to the right of the monitor, such
that there is no way to see the whole screen. Neither fidding with my
monitor or the overscan preferences was able to help. I'm not sure what
the problem is, but for now I've kept scan conversion off so that the
application screens are reasonably centered and visible.
CONCLUSIONS:
The A4000 presents a significant expansion in the capabilities of Amiga
computers. The original Amiga's graphics, while fantastic by the
standards of 1985 when they were introduced, have recently begun to show
their age. The AGA chipset gives the Amiga a true 24 bit palette and
the ability to use hundreds of thousands of colors in any resolution
mode. The potential improvements of future Amigas now lie primarily in
graphics speed, and to a lesser extent, increased resolution.
I bought my first Amiga 1000 in 1985, with 256 Kb of memory and later
upgraded to an accelerated 2000. When I became interested in the Amiga
4000, I was at first unsure whether the abilities it provided were
significant enough to warrant upgrading from my current system. Now
that I have worked with the 4000, I am confident the answer is "yes".
The 4000 takes a large step towards making the Amiga into a workstation
class computer system.
COMMENTS:
I can be reached electronically at:
koren@fc.hp.com
or via phone:
303-226-4985 (USA)
---
Daniel Barrett, Moderator, comp.sys.amiga.reviews
Send reviews to: amiga-reviews-submissions@math.uh.edu
Request information: amiga-reviews-requests@math.uh.edu
General discussion: amiga-reviews@math.uh.edu
programming/AMIGA/amigabbs.txt
+8
View File
@@ -0,0 +1,8 @@
**************************************************************************
* Sysop * E D O X B B S * Matrix nr. *
* Kenth Rosenqvist ********************************** 2:200/207.0 *
*************************** +46-431-21843 ********************************
* 1200 - 14.400 baud. [HST/DS/V32bis/V42bis] *
* 24 hours (Every day exept mailhour: 03.00-08.00am) *
**************************************************************************
programming/AMIGA/amigmach.faq
+314
View File
@@ -0,0 +1,314 @@
By popular demand, here's Jarkko Hietaniemi's excellent AmigaMach FAQ -
AmigaMach FAQ
$Id: KludgeMach-FAQ,v 1.15 1993/01/01 14:47:52 jhi Exp $
====== WHAT?
Mach kernel (MK78) has been ported to Commodore Amigas.
The port works provably on the following platforms:
- A3000 with AmigaDOS 2.04 in RAM with 4MB fast RAM ('030 25MHz)
- A2500 with 2 MB fast RAM ('030)
- A2000 with GVP Combo ('030 33MHz)
- A500 with CSA MegaMidget Racer ('030)
The port is also known as "KludgeMach".
Motorola 68030 definitely works, '020 should be sufficient as long as
a MMU (68851) is available. On a '040 Mach sort of boots but checking
needs to be made whether the same binaries and sources still run on a '030.
To boot the KludgeMach at least 2MB fast RAM is required.
KludgeMach DOES NOT USE chip ram at all. By tweaking sources the fast
RAM requirement could perhaps be pushed down to 512kB.
Diskspace requirement of the binaries is only 300kB.
The current distribution CONTAINS ONLY THE SOURCES and to build Mach
at least 3MB of fast RAM is required. To build the binaries, 25MB of
diskspace is needed, of this 15MB is for Mach, 10MB for the
development tools. The minimum memory requirement for the compilation
is at least 2 MB (works only with optimization turned off), 4MB is
probably enough.
NOTE: these requirements are only for now; in near future the
distribution is likely to grow significantly because device drivers
and servers are added. The recommended minimum is then 4MB fast RAM
and 40MB disk. Nice-to-have amounts are then 8MB fast and 100MB disk:
this much is needed for double build directories and for possible
Mach-based filesystem's playground.
====== WHY?
The KludgeMach project aims at building a free UNIXish environment for
the Commodore Amiga computers. As its base it will use the Mach
microkernel built at Carnegie Mellon university (CMU). Mach is
OS-independent, however, and therefore other OSs could also be run
on top of it as servers.
====== WHERE?
The port is available by FTP from the following places:
Australia:
monu1.cc.monash.edu.au:/pub/mach GMT+10 (NSW)
IP: 130.194.1.101
Europe:
ftp.funet.fi:/pub/mach/amiga GMT+2 (EET)
(or /pub/amiga/mach, both work)
IP: 128.214.6.100
ftp.dfv.rwth-aachen.de:/pub/amiga/mach GMT+1 (MET)
(or ftp.informatik.rwth-aachen.de, both work)
IP: 137.226.4.105
United States:
homeboy.wpi.edu:/pub/mach GMT-5 (EST)
IP: 130.215.8.99
oes.orst.edu:/pub/mach GMT-8 (PST)
IP: 128.193.124.2
monu1.cc.monash.edu.au is the primary distribution site BUT DO USE
THE SITE NEAREST TO YOU WHEN DOWNLOADING (ftp get'ting), NOT monu1.
The link to "down under" is seriously limited. When uploading (ftp
put'ting), use the incoming/ directory of monu1. Also remember to do
your ftp'ing when there is night at the site you are using. The
distribution is mirrored daily from monu1 to homeboy and oes and from
there daily to Germany and Finland.
You need only the file
/pub/mach/amiga/KludgeMach-<latest>.tar.Z
to get started. Currently the latest version is 0.007, based on CMU
MK78. Note that the European sites have one directory deeper
hierarchy, you will need to get
/pub/mach/amiga/amiga/KludgeMach-<latest>.tar.Z
SIM is a kernel debugger that will be useful if (when) you
start hacking on the Mach kernel. It was done by Stefan Walter
<swalter@avalon.physik.unizh.ch>.
If you develop AmigaMach, it is best to use the tools provided
in the distribution (directory tools/). This because then everyone
will know what the others are talking about (basically, face the
same bugs :-). If you want/need to use some other tools, please
first discuss the choice in the mailing list and then if the new tool
is really deemed necessary, provide it to others by uploading it
to monu1. The tools that are currently agreed upon are:
gcc-2.2.2 (remember to apply fixes 1 to 3)
pdksh-920711
dmake
gtar10
GNU parser/patch utils
The full contents of the monu1 distribution are:
/pub/mach/README:
----------------------------------------------------------------------
This is an area for the distribution of sources related to ports
of the Mach microkernel from CMU to the Motorola 68000 series of
microprocessors.
The directories are:
/pub/mach: - you are here
total 12
-rw-r--r-- 1 1606 2761 Sep 11 13:33 README
drwxr-xr-x 4 1606 2048 Dec 17 12:05 amiga
drwxr-xr-x 2 1606 2048 Oct 6 12:46 cmu_src
drwxr-xr-x 2 1606 2048 Oct 6 12:46 contrib
drwxrwx-wx 2 1606 2048 Dec 14 15:54 incoming
/pub/mach/amiga: - sources to AmigaMach
total 9718
-rw-r--r-- 2 1606 21102 Nov 3 02:12 AmigaMach-FAQ
-rw-r--r-- 1 1606 5178 Oct 18 01:45 Bootstrap.patch
-rw-r--r-- 1 1606 2065 Oct 19 12:37 Bootstrap2.patch
-rw-r--r-- 1 1606 3256873 Sep 3 14:12 KludgeMach-0.003.tar.Z
-rw-r--r-- 1 1606 3041123 Sep 20 15:52 KludgeMach-0.006.tar.Z
-rw-r--r-- 1 ftp 3317969 Dec 14 15:36 KludgeMach-0.007.tar.Z
-rw-r--r-- 2 1606 21102 Nov 3 02:12 KludgeMach-FAQ
-rw-r--r-- 1 1606 8341 Sep 3 19:52 KludgeMach-README
-rw-r--r-- 1 1606 5301 Oct 22 17:45 SCSI.patch
-rw-r--r-- 1 1606 5944 Oct 22 17:45 SCSI2.patch
-rw-r--r-- 1 1606 68957 Sep 3 12:51 SIM.lha
drwxr-xr-x 2 1606 2048 Oct 6 12:48 diffs
-rw-r--r-- 1 1606 35326 Sep 27 12:58 hd_wilde.diff
-rw-r--r-- 1 ftp 53096 Sep 11 12:50 scsi9091.lzh
drwxr-xr-x 2 1606 2048 Dec 17 12:05 tools
-rw-r--r-- 1 ftp 25840 Sep 11 12:50 uart.tar.Z
/pub/mach/amiga/diffs: - differences between versions
total 60
-rw-r--r-- 1 1606 e helpful
total 4550
-rw-r--r-- 1 1606 388 Oct 5 11:21 GettingGNUTools
-rw-r--r-- 1 1606 345600 Sep 4 18:43 dmake.lha
-rw-r--r-- 1 1606 80 Sep 4 18:47 dmake.lha.readme
-rw-r--r-- 1 ftp 7286 Oct 5 00:42 gcc-2.2.2-fix2.lha
-rw-r--r-- 1 ftp 173155 Dec 14 17:42 gcc-2.2.2-fix3.lha
-rw-r--r-- 1 1606 3306066 Sep 4 11:54 gcc-2
total 4818
-rw-r--r-- 1 1606 254 Sep 5 10:38 getting_bsdss
-rw-r--r-- 1 1606 2863311 Sep 3 13:52 mk78.tar.Z
-rw-r--r-- 1 1606 219675 Sep 3 13:53 poe9.tar.Z
-rw-r--r-- 1 1606 1777023 Sep 3 13:53 user18.tar.Z
/pub/mach/contrib: - other random sources
total 494
-rw-r--r-- 1 1606 92701 Sep 3 12:51 MachSun3.tar.Z
-rw-r--r
-rw-r--r-- 1 1606 2571 Sep 8 11:27 second_SYS.h
Note that the European sites have one directory deeper hierarchy, you
will need to cd to /pub/mach/amiga, just /pub/mach is not enough.
Note also that the directory hierarchy (where the things are) may
mutate because new material will accumulate and the hierarchy might
need reorganizing. The rule of thumb: use th. This is not
continuously mirrored, it is only a snapshot of 7th of September 1992.
Mach documentation is available by ftp from
mach.cs.cmu.edu:doc GMT-5 (EST)
IP: 128.2.209.192
For example doc/osf/kernel_principles.ps is a good starting place.
====== BEWARE!
KludgeMach works, but only for suitably small values of "works".
Ha and to Michael if you have some special
skills, hardware or just time to hack around.
Michael is also in charge of the "offical" releases so SEND YOUR PATCHES
TO Michael. Here are the guidelines:
> * Use diff -rc to create a patch I can apply directly to the directory
> structure.
>
> * Send the patch to me and tell me you want it added. Tell me which
> version ing on this.
- drivers: SCSI, AT IDE, WD33C92, WD33C93, Commodore 2065/2090/2091
expertise needed.
Amiga UNIX has many device drivers WITH sources. Their copyright
status needs to be checked from Commodore. Keith Gabryelski has
volunteered to contact C= about this. Ty Sarna <tsarna@endicor.com> is
contacting GVP about their drivers. Other 3rd party vendors like
IVS could also use some questioning. Markus Illenseer
<markus@techfak.uni-bielefeld.de> has already contacted Ralph Babel of GVP:
> He knew about the Mach Port already, he is very interested on a running
> kernel and a running Server. But he is not willing to implement a GVP SCSI
> driver while nothing is ruhen the driver for
> the A3000-SCSi and the A2091 is finished, and he thought this could be
> a point to enter into Mach.
- an OS :-) Work and queries are currently progressing on several fronts:
BNR2SS/BSDSS: Michael Saleeba [Zik] <zik.aurora.cc.monash.edu>
The situation is a bit muddy: CMU has stopped SUPing BSDSS.
BSD4.4: Real Soon Now -- the "lite" or unencumbpfer <kupfer@cs.berkeley.edu>:
>
> I understand that you're interested in the Mach-based Sprite
> single-server. I'm the person who did the single-server. I no longer
> work for the University of California, but I can give you some
> information about the server.
>
> - The sources for the Sprite single-server are available for anonymous
> ftp from allspice.berkeley.edute
> daemon.
>
> - The Sprite single-server implements a subset of Sprite
> functionality. There is no binary compatibility, either with native
> Sprite or with UNIX. Process migration is not supported, nor is
> access to the local disk. Most of the Sprite distributed file
> system is implemented, ct, the Sprite group gave
> up on supporting external sites in early 1992, and requests for a
> Sprite distribution are now politely refused.
>
> - If you would like to browse any of the missing sources, I can try to
> put together a tar file for you. Also, feel free to send me mail if
> you have additional questions. Please be patient if I am slow in
> answerinme time ago I spoke with Richard Stallman on the subject. He's very
> interested in having m68k-based machines running the Hurd. In fact
> apparently GNU have a couple of Amigas they'd like to use to help
> develop the Hurd, so it'd be nice if we could help out with that :-)
Linux:
The upper layers may be portable enough to make an UNIX server???
Some work has been doichael Richardson <mcr@latour.sandelman.ocunix.on.ca> has at least a
partial answer:
> Yes, it is. The ISA bus architecture stuff is sufficiently isolated
> that making it work on other types of 386 system would be a snap. The
> 386 specific stuff is isolated to one directory tree (in which the isa
> stuff is located) as well.
> I am unclear as to how a Mach single serudio, clock, etc)
- contacts with GNU project (see the above discussion about Hurd)
- cross-compilation environment
Jukka Partanen <jtp@cs.hut.fi> is researching this area.
- RDB (Rigid Block Standard) experts
- AmigaOS emulator
- this FAQ file is maintained by Jarkko Hietaniemi
DRAMATIS PERSONAE:
Erik Bennett <bennett@oes.orst.edu>
oes.o <baford@peruvian.utah.edu>
the author of the initial port of Amiga Mach
Keith Gabryelski <ag@monique.rt.com>
former C= AmigaUNIX Networking/X11/device Engineer
AmigaUNIX device driver source status
Dominic Giampolo <nick@homeboy.wpi.edu>
homeboy.wpi.edu ftp maintainer
Niklas Hallqvist <niklas@appli.se>
.edu.au ftp maintainer (the primary site)
the central coordinator
the official releases
Ty Sarna <tsarna@endicor.com>
Sprite research
GVP contact
Markus Wild <wild@amiga.physik.unizh.ch>
Linux preliminary peek
Amiga ports of GCC and gtar
dmake
====== HOW?
Want more information?
t, amiga-mach, is most useful as an information channel
both for asking questions and for sending answers and progress reports.
For specific subprojects people are encouraged to use either personal
mail or create mailing lists if the subject is not necessarily useful
for "general public".
For example people working actively with console driver might get
together and create a entions
of Amiga UNIX, MacIntoshes and Mac's A/UX on the amiga-mach list.
Standardizing call conventions would make possible to have binary
compability between m68k-based Machs.
This FAQ is updated about weekly and then merged to the ftp distribution.
It is sent weekly to the amiga-mach mailing list and crossposted to
the following USENET newsgroups:
comp.os.mach,comp.sys.amiga.hardware,comp.sys.amiga.programmer,comp.unix.amiga
END_OF_FAQ␍
programming/AMIGA/amirisfa.txt
+429
View File
@@ -0,0 +1,429 @@
> CPU REPORT
==========
Issue #109
----------
by Michael Arthur
CPU INSIGHTS
============
RJ Mical, and the Rise and Fall of Amiga Computer Inc.
======================================================
Gary Oberbrunner recently provided a great source of knowledge
about this, by writing and posting this essay on the Amiga newsgroup
(or message base) of Usenet. It is a transcript of a talk given by
R.J. Mical, the programmer who designed and developed the
Intuition graphical user interface for the Amiga, before the
Boston Computer Society in March, concerning the history of both
the Commodore Amiga itself, and Amiga Inc., the company who created
it. Except for modifications in its formatting, or presentation,
and various notes placed in this text to provide more information
on certain subjects, the content of Gary Oberbrunner's text is
identical....
The Early Days, Game Boxes, and the Guru Meditation
---------------------------------------------------
On Monday March 2, 1989, RJ Mical (=RJ=) spoke at the Boston
Computer Society meeting in Cambridge. Fortunately I was
momentarily possessed with an organizational passion, and I took
copious notes. I present them here filtered only through my memory
and my Ann Arbor. My comments are in [square brackets]. What
follows is a neutron-star condensed version of about three and one
half hours of completely uninterrupted discussion....
Amiga Computer Inc. had its beginnings, strangely
enough, RJ began, with the idea of three Florida doctors
who had a spare $7 million to invest.
They thought of opening a department store franchise,
but (as RJ said) they wanted to try something a bit more
exciting. So they decided to start a computer company.
"Yeah, that's it! A computer company! That's the ticket!
:-)"
They found Jay Miner, who was then at Atari, and Dave
Morse, the VP of sales (you can see their orientation
right off..) they lifted from Tonka Toys. The idea
right from the start was to make the most killer game box
they could. That was it, and nothing more. However
Jay and the techies had other ideas. Fortunately they
concealed them well, so the upper management types still
thought they were just getting a great game machine. Of
course the market for machines like that was hot
in 1982...
They got the name out of the thesaurus; they wanted to
convey the thought of friendliness, and Amiga was the first
synonym in the list. The fact that it came lexically
before Apple didn't hurt any either, said RJ.
However, before they could get a machine out the
door, they wanted to establish a "market presence" which
would give them an established name and some distribution
channels - keep thinking "game machine" - which they
did by selling peripherals and software that they bought
the rights to from other vendors. Principal among
these was the Joyboard, a sort of joystick that you stand
on, and you sway and wiggle your hips to control the
switches under the base. They had a ski game of course,
and some track & field type games that they sold with this
Joyboard. But one game the folks at Amiga Inc. thought
up themselves was the Zen Meditation game, where you sat on
the Joyboard and tried to remain perfectly motionless.
This was perfect relaxation from product development, as
well as from the ski game. And in fact, this is where
the term Guru Meditation comes from; the only way to
keep sane when your machine crashes all the time is the ol'
Joyboard. The execs tried to get them to take out the
Guru, but the early developers, bless 'em, raised such a hue
and cry they had to put it back in right away.
(Note: Recently, Commodore announced that the Term, "Guru
Meditation" would not be in AmigaDOS 1.4....)
When RJ interviewed with Amiga Computer (he had been at
Williams) in July 1983, the retail price target for the
Amiga was $400. Perfect for a killer game machine. By the
time he accepted three weeks later, the target was up to
$600 and rising fast. Partly this was due to the bottom
dropping completely out of the game market; the doctors and
the execs knew they had to have something more than just
another game box to survive. That's when the techies'
foresight in designing in everything from disk
controllers to keyboard (yes the original Amiga
had NO KEYBOARD), ports, and disk drives began to pay off.
The exciting part of the Amiga's development, in a
way its adolescence, that magical time of loss of innocence
and exposure to the beauties and cruelties of the real
world, began as plans were made to introduce it, secretly
of course, at the Winter CES on January 4th, 1984.
CES, THE AMIGA'S ADOLESCENCE, AND "BUSINESS IS WAR"
---------------------------------------------------
The software was done ten days before the CES, and running
fine on the simulators. Unfortunately when the hardware was
finally powered up several days later, (surprise) it didn't match
its simulations. This hardware, of course, was still not in
silicon. The custom chips were in fact large breadboards, placed
vertically around a central core and wired together round the edges
like a Cray. Each of the three custom 'chips' had one of these
towers, each one a mass of wires. According to RJ, the path
leading up to the first Amiga breadboard, with its roll-out
antistatic flooring, the antistatic walls just wide enough apart
for one person to fit through and all the signs saying Ground
Thyself, made one think of nothing so much as an altar to some
technology god.
After working feverishly right up to the opening minutes of
the CES, including most everybody working on Christmas, they had a
working Amiga, still in breadboard, at the show in the booth in a
special enclosed gray room, so they could give private demos.
Unfortunately if you rode up the exhibit-hall escalator and craned
your neck, you could see into the room from the top.
The Amiga was, RJ reminisced, the hardest he or most anyone
there had ever worked. "We worked with a great passion...my most
cherished memory is how much we cared about what we were
doing. We had something to prove...a real love for it. We created
our own sense of family out there." RJ and Dale Luck were
known as the "dancing fools" around the office because they'd play
really loud music and dance around during compiles to stay
awake.
After the first successful night of the CES, all the
marketing guys got dollar signs in their eyes because the Amiga made
SUCH a splash even though they were trying to keep it "secret."
And so, they took out all the technical staff for Italian food,
everyone got drunk and then they wandered back to the exhibit
hall to work some more on demos, quick bug fixes, features that
didn't work, and so on. At CES everyone worked about 20 hours a day,
when they weren't eating or sleeping.
Late that night, in their drunken stupor, Dale and RJ
put the finishing touches on what would become the canonical Amiga
demo, Boing.
At last! ...The true story is told.
THE COMMODORE YEARS: AMIGA FUTURES, AND BUSINESS AS USUAL
----------------------------------------------------------
After the CES, Amiga Inc. was very nearly broke and heavily in
debt. It had cost quite a bit more than the original $7 million
to bring the Amiga even that far, and lots more time and money were
needed to bring it to the market. Unfortunately the doctors wanted
out, and wouldn't invest any more. So outside funding was needed,
and quick.
The VP of Finance balanced things for a little while, and even
though they were $11 million in the hole they managed to pay off
the longest standing debts and keep one step ahead of Chapter
11. After much scrounging, they got enough money to take them to
the June CES; for that they had REAL WORKING SILICON. People kept
peeking under the skirts of the booth tables asking "Where's the
REAL computer generating these displays?"
Now money started flowing and interest was really being
generated in the media. And like most small companies, as soon as
the money came in the door it was spent. More people were added
- hardware folks to optimize and cost-reduce the design; software
people to finish the OS. Even the sudden influx of cash was only
enough to keep them out of bankruptcy, though; they were still
broke and getting broker all the time.
How much WOULD have been enough? RJ said that if he were
starting over, he'd need about $49 million to take the machine from
design idea to market. Of course Amiga Inc. had nowhere near
that much, and they were feeling the crunch. Everybody tightened
their belts and persevered somehow. They actually were at one
point so broke they couldn't meet their payroll; Dave Morse, the VP
of Sales, took out a second mortgage on his house to help cover it,
but it still wasn't enough.
They knew they were going under, and unless they could find
someone quick to buy them out they were going to be looking for jobs
very shortly. They talked to Sony, to Apple, to Phillips and HP,
Silicon Graphics (who just wanted the chips) and even Sears.
Finally...they called Atari. (Boo! Hiss! [literally - the
audience hissed at Jack Tramiel's name!] Trying to be discreet, RJ's
only personal comment on Jack Tramiel was (and it took him a
while to formulate this sentence) "an interesting product of the
capitalist system." Ahem.
Apparently Tramiel has been quoted as saying "Business is
War." Tramiel had recently left Commodore in a huff and
bought Atari "undercover" so that by the time he left C= he was
already CEO of Atari. Realizing that Commodore was coming out
with their own hot game machine, Tramiel figured he'd revenge himself
on them for dumping him by buying Amiga Inc. and driving C= down
the tubes with "his" superior product. So Atari gave them half a
million just for negotiating for a month; that money was gone in aday.
Of course Tramiel saw that Amiga Inc. wasn't in a very good
bargaining position; basically unless they were bought they were
on the street. So he offered them 98 cents a share; Dave Morse
held out for $2.00. But instead of bargaining in good faith,
every time Morse and Amiga tried to meet them halfway their bid went
down!
Amiga Inc.: "Okay, $1.50 a share."
Jack Tramiel: "No, we think we'll give you 80 cents."
Amiga Inc.: "How about $1.25?"
Jack Tramiel: "70 cents."
And so on...
Even Dave Morse, the staunchest believer in the concept that
was the Amiga, the guiding light who made everyone's hair stand on
end when he walked into the room, was getting depressed. Gloom set
in. Things looked grim.
Then, just three days before the month deadline was up,
Commodore called. Two days later they bought Amiga Inc. for $4.25
a share. They offered them $4.00, but Dave Morse TURNED THEM DOWN
saying it wasn't acceptable to his employees; he was on the verge
of walking out when they offered $4.25. He signed right then and
there.
Commodore gave them $27 million for development; they'd
never seen that much money in one place before. They went right out
and bought a Sun workstation for every software person, with Ethernet
and disk servers and everything. The excitement was back.
Commodore did many good things for the Amiga; not only
did they cost-reduce it without losing much functionality, they had
this concept of it as a business machine; this was a very
different attitude from what Amiga Inc. had been working with.
Because of that philosophy, they improved the keyboard [ha!
- garyo] and made lots of other little improvements that RJ didn't
elaborate on.
What could Commodore have given them that they didn't? The one
thing RJ wanted most from them was an extra 18 months of
development time. Unfortunately Commodore wasn't exactly rich right
then either, so they had to bring out the product ASAP [and when is
it ever any different?] Also, he said, they could have MARKETED it.
(applause!). If he'd had that extra 18 months, he could have
made Intuition a device rather than a separate kind of thing; he
could have released it much more bug-free.
The Future
----------
RJ's advice for A1000 owners: "Keep what you've got. It's not
worth it to trade up. The A1000 is really a better machine." This
may be sour grapes on RJ's part, since the Amiga 2000 was designed
in Braunschweig, West Germany, and the version of the A2000 being
worked on in Los Gatos was rejected in favor of the
Braunschweig-Commodore version. However the A1000 compares to the
A2000, though, the Los Gatos 2000 would have certainly been
better than either machine. C= management vetoed it because
Braunschweig promised a faster design turnaround (and, to their
credit, were much faster in execution than the Los Gatos group
would have been) and more cost-reduction, which was their
specialty. Los Gatos, on the other hand, wanted a dream machine
with vastly expanded capabilities in every facet of the machine.
The cruel financial facts forced C= to go with the Business Computer
Group, who did the Sidecar in Braunschweig as well, and quickly and
cheaply.
So they fired more than half the staff at the original Los
Gatos facility, one by one. That trauma was to some extent played
out on the net; no doubt many of you remember it as a very
difficult and emotional time. There are now only six people left in
Los Gatos, and their lease expired in March, so thus expires the
original Amiga group.
And..that's how RJ ended his talk; the rise and fall of
Amiga Computer Inc. The future of the Amiga is now in the hands of
Westchester and Braunschweig, and who knows what direction it will
take?
Q & A Session: Boston Computer Society and RJ Mical
----------------------------------------------------
I'll just make this part a list of technical questions
and answers, since that was the format at the talk anyway. This part
is part technical inquiries and part total rumor mill; caveat emptor.
Questions are from the audience, Answers are =RJ=.
-----------------------------
Q: Can you do double buffering with Intuition?
A: Pop answer: No. Thought-out: well, yes, but it's not easy. Use
MenuVerify and don't change the display while menus are up. It's
pretty hairy.
Q: How big is intuition (source code)?
A: The listings (commented) are about a foot thick, 60 lpp, 1 inch
margins.
Q: Where did MetaComCo come into the Amiga story?
A: MCC's AmigaDOS was a backup plan; the original Los Gatos-written
AmigaDOS was done with some co-developers who dropped out due to
contract and money hassles when C= bought Amiga. Then MCC had to
crank EXTREMELY hard to get their BCPL DOS into the system at the
last possible minute.
Q: Why no MMU (support in the Amiga's Operating System)?
A: Several reasons. Obviously, cost was a factor. MMUs available
at the time the Amiga was designed also consumed system time [this
is what he said- I'm just the scribe]; although newer MMUs solve
this problem they were too late for the Amiga.
Second, the original goal of the Amiga was to be a killer game
machine with easy low-level access, and an MMU didn't seem
necessary for a game machine.
Third [get this!] with an MMU, message-passing becomes MUCH
hairier and slower, since in the Amiga messages are passed by just
passing a pointer to someone else's memory. With protection,
either public memory would need to be done and system calls issued
to allocate it, etc., or the entire message would have to be
passed. Yecch. So the lack of MMU actually speeds up the basic
operation of the Amiga several fold.
Q: Why no resource tracking?
A: The original AmigaDOS/Exec had resource tracking; it's a shame it
died.
Q: How is your game coming? [??]
A: It's just now becoming a front-burner project. It's number crunch
intensive; hopefully it will even take over the PC part of the
2000 for extra crunch. It's half action, half strategy; the
'creation' part is done, only the playing part needs to be
written. Next question. :-)
Q: Will there ever be an advanced version of the chip set?
A: Well, Jay Miner isn't working on anything right now... [RUMOR
ALERT] The chip folks left in Los Gatos who are losing their lease
in March were at one time thinking about 1k square 2meg chip space
128-color graphics, although still with 4 bit color DACs
though...and even stuff like a blitter per plane (!!) They were
supposed to be done now, in the original plans; the chip designers
will be gone in March, but the design may (?) continue in West
Chester. Maybe they'll be here two years from now.
Q: What will happen to the unused Los Gatos A2000 design?
A: ??????
(Note: Reportedly, this design eventually became the Amiga
3000's Enhanced Chip Set.)
Q: Should I upgrade from my 1000 to a 2000?
A: Probably not. The 2000 isn't enough better to justify the cost.
Unless you need the PC compatibility, RJ advocated staying with
the 1000. After all the 2000 doesn't have the nifty garage for
the keyboard...:-) The A1000 keyboard is better built; you can
have Kickstart on disk; it's smaller and a LOT quieter, [maybe not
than the old internal drives!!!] and uses less power; the 2000 has
no composite video out, plus the RGB quality is a tad worse.
Composite video (PAL or NTSC) is an extra-cost option with the
2000.
Q: Have you ever seen a working Amiga-Live!?
A: Yes, I've seen it taking 32-color images at 16fps, and HAM
pictures at something like half that. [!!] It's all done and
working. I don't know why it's not out. It sure beats Digiview
at 8 seconds per image!
Q: What do you use for Amiga development tools?
A: DPaint and Infominder, Aztec C, Andy Finkel's Microemacs.
Q: What's the future of the A1000?
A: They aren't making any right now; they're just shipping from
stock. But they do claim that they intend to continue making
them.
Note: Shortly after RJ Mical's talk, news surfaced that
Commodore had decided to not make anymore Amiga 1000s, but to
make a unified front with the Amiga 2000....)
Q: Who is the competition for Amiga right now?
A: The new Macs are so expensive, they're not a threat to the 2000,
much less the 1000. Atari's new stuff "doesn't impress me."
[that's all he said.]
Q: Why are the pixels 10% higher than wide?
A: The hardware came out that way, and it would have been a pain to
do it any other way due to sync-rate-multiple timing constraints.
-EOF
programming/AMIGA/amylives.txt
+377
View File
@@ -0,0 +1,377 @@
-----------------------------------------------------------------------------
This file was downloaded from
_ ______ __ ____ _ ___ _ ______|\ ____
| Y ___-o\ /\ | +||__-o\ /\ | V \ |U | /o _____//Y -o/
| || \ \\ // \ | || \ \\ /+-\ | :|\ \\|| | \| \__/\| |/|/
| :| / //./\ \ | :| / / ///\ \ | :| \ o\: | \ ___ \ :\____
| .|__/ // ____ \| :| / // / ____ \ | .| / // | Y / // :____/
| ____//°/____\ \__| / //\/ /____\ \| .|/ /| |\ . / //| .\____|\
| | /________\ \__\ ./ \\_|\___\\ \__|__/ | //\ _/ // \_ ______\
| / \ \||_/ \ \|°\ \ \ | //__Y___/ U
| / \/| \_____\ \/ |// :
|/ \| |/ .
- Denmarks fastest 2400/9600 board -
- 0 day wares - 24 hour online - 7 mb stuff each day -
- Sysop: |ce Lord of |>irect -
- Cosysops: Heat & Mean of Wall -
_____ _____ _____ _____ _____ _____ ______ ______
_|_ |____| |____ ___ (_____ ____) (_____ (_____) | _____) / /
| | _____) (_____) (_____ (_____) / | _____) / /
-----------------------------------------------------------------------------
***** Downloaded from *****
"The Warehouse"
(510) 689-7039
Sysop: Warehouser
(this appeared originally in the SanJose Merc. and has since been reprinted
many many times across the country... caused enuf of an uproar in the
Amiga community to prompt a reply (which follows) from that sleeping
giant- CBM...) warehouser
COMMODORE LETS AMIGA DIE SLOW DEATH
Phillip Robinson
The Amiga is dead. It's sad but true. But we shouldn't be surprised. The
poor Amiga has been at death's door for several years. It managed to live
because of its potent basic design and thousands of rabid Amiga fans who would
rather switch to a typewriter than a PC or Mac. The Amiga died because
Commodore denied it growth, support or even respect. And I watched this eight-
year-long execution, hoping a reprieve would come and marveling at how much
abuse the computer with the cute, friendly name could take.
Back in 1984 I was one of the first to write about an exciting new computer
that had special chips for sound, video and other "multimedia" work. Except
that back then no one said "multimedia" about computing. In fact, the slick
abilities with sound and images convinced many that the Amiga was aimed too
much at game players and not at serious computing types.
The Amiga appeared just as the Macintosh was failing, losing sales after the
initial enthusiasm. The PC was conquering corporate, word-processing and
spreadsheeting America. But the PC was laughably slow and clumsy with
graphics, sounds and other such creative elements. There was clearly room for
a machine that could live at first as an entertainer while building its chops
to tackle the more prosaic types of computing. A group of refugees from
companies such as Atari designed the Amiga, and then, needing money for
marketing, sold it to Commodore. Commodore needed the Amiga because its
phenomenally popular Commodore 64 home computer was faltering, unable to jump
to a new generation of computing power.
In those early days, the Amiga had a graphic interface like the Macintosh's
but backed up by a true multitasking operating system.
This computer was built to run more than one program at a time, something the
Mac and PC are only now growing into.
The Amiga also had the high-resolution graphic display of the Mac but with
color. It offered more colors and more graphics programming than the PC.
It had stereo sound in its heart, where the Mac could only produce simple
sounds and the PC could only beep or buzz.
Finally, the Amiga had video in its soul. Those special chips let it
naturally and easily overlap its images with standard TV and VCR images. To
add titles or special effects to a video, you could use an Amiga, or you could
add thousands of dollars of hardware to a Mac or PC and pray.
So what went wrong?
First, Commodore took too long to get the Amiga operating system software out
the door. It was always near completion, getting debugged, almost there.
Without stable system software and programming tools, no one could create good
software for the Amiga. (In retrospect, the Amiga's trouble attracting
software developers shows just how historic Apple's quest for Mac software
was.)
Then Commodore waffled and missed its commitments to Amiga pheripherals. A
card was promised that would give the Amiga PC-compatibility. That would tide
you over, the story was, until Amiga software appeared. You could run your PC
programs from 1-2-3 to WordStar. This card was delayed and delayed and
delayed. Anyone who bought Amigas with that card in her plans looked pretty
foolish.
Next, Commodore didn't release timely Amiga upgrades. As PCs and Macs kept
leapfrogging in processor speed and random-access memory and disk drives, the
Amiga just waddled along. Eventually, the Amiga 1000 (the original model) was
succeeded by the 2000 (with more memory and a hard disk) and the 3000 (with a
68030 processor chip and more disk and memory). Even in graphics and sound,
where the Amiga was once the world's best, the Mac and then later the PC added
more colors, more resolution, more sound, while the Amiga stood still.
The Amiga 500 appeared as a sort of Amiga Jr., with less power and memory but
a $500 price. Too expensive to compete with Nintendo as a game machine, it
was too weak for serious computing, especially for the one kind of computing
the Amiga was best at: multimedia.
Commodore repackaged an Amiga as the CDTV (which stands for Commodore Dynamic
Total Vision, I think, though you can read pages of CDTV hype without finding
that expression). This "interactive multimedia" machine is supposed to be the
perfect tool for hooking to a television to play interactive video discs for
games and education. It competes with the Philips CD-I player (similar price,
less graphics and sound capability), and MPC systems (PC systems with added
multimedia hardware, which costs four times as much). Interactive multimedia
is still a questionable market, with more interest from sellers than from
buyers. But maybe the Amiga will have a future there.
The final insult to the Amiga has been Commodore's consistent lack of concern,
attention and contact with Amiga dealers, developers and owners. It's still
true today. I read in a local computing magazine how the loyal Amiga
columnist is giving up, unable to bear another year of prying information from
Commodore. I walk into a store that specializes in Amigas and ask about the
latest Commodore news, and the staff admits that "it's strange, we know, but"
they never get news from Commodore. All they know of plans and announcements
is what they read in the magazines.
But they're not much better off! The first article I read in the most popular
Amiga magazine is about a new "A570 CDTV Adapter" that converts an Amiga 500
into a CDTV machine. This is the lead article, the one hyped on the cover,
and the editors are humiliated by having to add this note: "Just as this issue
was about to go to press, AmigaWorld learned that Commodore officials were
expressing some doubts about the scheduled release of the A570 this summer and
about its suggested retail price of $499.99." I'll bet it wasn't even
Commodore that told them!
I know, too, that both times Commodore offered to send me an Amiga for a while
to review Amiga peripherals and software, the promised machine never arrived.
There's only one kind of life left for the Amiga: toasting.
NewTek's Video Toaster is the best way to build an inexpensive video effects
studio, and the Toaster requires an Amiga. In fact, the new Toaster models
for Mac and PC are really just a Toaster and Amiga that you connect to your
Mac or PC. You can see the popularity of the Toaster from the general
computer magazines -- where it is the only Amiga product mentioned -- to the
Amiga specialty stores -- where digital video and Toasters take up half the
space.
If you have an Amiga, don't fret about this news. You've adapted to living in
the dark, being fed biodegradable stories about new models and upgrades.
There will be some new games, a few new accelerator boards and fellow
enthusiasts to club with for another five years at least.
If you're an Amiga owner in Europe, you have more company than in the United
States -- Commodore always has had a larger presence there. But the hardware
hasn't kept up to date any more than in the United States. You should
consider buying a mailorder PC or sneaking some Mac time to see what you're
missing.
If you want to work with digital video, the Toaster is good enough to warrant
buying an Amiga. But don't think of it as your computer; consider it just a
power supply for the Toaster.
But if you're not already hooked on the Amiga or fascinated by video toasting,
don't even think of buying one. You'll be getting into a relationship full of
heartache and promises not kept. Maybe at least other computer companies will
learn a lesson of caring and respect from this sad affair. --------------------
Phillip Robinson analyzes and writes about computers from Sausalito. You can
reach him at (415) 331-3973 or at P.O.Box 1357, Sausalito CA 94966 or on the
MCI e-mail service as "probinson" at mailbox 327-8909.
******************************************************************************
AND COMMODORE'S REPLY:
******************************************************************************
This is cross-posted from another network at Commodore's request:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
TITLE: Commodore asks for help...
Commodore is aware of the activity on computer networks in response to the
"Amiga/Slow Death" article written by Mr. Phillip Robinson. Commodore wants to
assure all you who are concerned that we are not taking this lightly, and
would appreciate your help in responding to Mr. Robinson and to newspapers who
have reprinted the article. Therefore, we are providing the information that
follows. It is a version of a correspondence sent to dealers in market areas
where the article has appeared.
All of us at Commodore share your concern about this story. The Commodore
marketing and communications staff agree that this story is one-sided,
contains several inaccuracies, and does not communicate the current thrust of
our emerging, dynamic and leading U.S. business presence in multimedia and
related applications.
Specific Actions And An Update
We've had two conversations with Mr. Robinson since his article first
appeared. We communicated to him all of the reasons why suggesting that
"Amiga is dying a slow death" couldn't be further from the truth! We have one
additional interview scheduled with Mr. Robinson next Wednesday (July 29th).
He will be writing a follow-up article after the interview. The follow-up
article will appear first in the San Jose Mercury News and then will be
distributed through the Knight Ridder distribution channels to your local
paper. That process usually takes up to two weeks.
Mr. Robinson reports that the feedback he's currently receiving from the
"Amiga/Slow Death" article is the heaviest he's experienced in the eight years
of doing this column. He reports that some of the more virulent negative
feedback has included threats of violence. We of course do not endorse
violent feedback of any kind. But you can take constructive steps to channel
your negative reaction to Mr. Robinson's article.
You can help manage the negative public perception Mr. Robinson's article has
created by taking action with your local broadcast and print media. Please
consider doing the the following:
1) Write a letter to the editor of the newspaper that ran the
Robinson article. Correct the record. Use some of the message
points we've provided. Voice your strong objection to the
one-sided and ridiculous suggestion that Amiga and Commodore
have no future.
2) Send a copy of your letter to the editor directly to Phillip
Robinson. His address is P.O. Box 1357, Sausolito, CA 94966
(as printed in the San Jose Mercury News).
3) If you wish, voice your opinion to Mr. Robinson by leaving a
voice-mail message for him at (415) 289-9498. Do this in the
next seven days so you have impact on his follow-up article.
Here are the primary message points that Commodore hopes to get across to Mr.
Robinson. Perhaps you can include some of them in your letters to the editor:
* Commodore is a one billion dollar company.
* There are more that three million Amigas installed worldwide.
* Phillip Robinson's recent article, which talks about a "slow
death" for the Amiga, was written with no input from Commodore.
* Commodore is not "killing" the Amiga. In fact, the company,
and its developer network, currently are working on several
enhancements to the Amiga product line. Significant product
announcements are planned this Fall at the World of Commodore
show in Pasadena.
* Approximately 1000 dealers distribute the Amiga in the United
States.
* Commodore recently signed a sole national distribution agreement
with Merisel, Inc., the world's largest publicly held
distributor of microcomputer hardware and software products.
* Commodore recently signed a strategic product reseller agreement
with Digital Equipment Corporation.
* Commodore, its shareholders, its dealers, its developers, and
its end-user base continue to have a long-term commitment to
the Amiga and its future as a multimedia, business and consumer
microcomputer.
* Commodore (and the Amiga) is a pioneer in the emerging
multimedia market. The company and its independant developers
actually are helping define multimedia. Many companies say
they are "in" multimedia without really knowing what that means.
Commodore has a strong end-user base executing a wide variety
of multimedia applications today.
* Multimedia is not a single market or application. Multimedia
is a method of designing and integrating computer technologies
on a single platform that enables the end-user to input, create,
manipulate, and output text, graphics, audio and video with a
single user interface.
* Commodore is focusing on four key business markets, for
professional applications, in the United Sates: videography,
professional training, kiosk information systems, and
presentation systems. The company has significant market
share in each of these business markets.
* The company recently launched an aggressive marketing and
advertising campaign to support and increase its leadership
position in these four key business markets. In addition,
Commodore is updating industry trade editors and reporters
about the company's U.S. business strategy against these four
key professional markets.
* Commodore has added new senior management to the consumer side
of the business. The company plans to extend current strengths
of the Amiga into consumer channels with a variety of product
announcements and new consumer applications during the next
12 months.
* NewTek is a valued developer. The Video Toaster is a great
Amiga peripheral. But the Amiga is much, much more than just
a power supply for NewTek's Video Toaster. In fact, to say
that the Amiga is "just a power supply for the toaster" is a
totally wrong and misguided depiction of the Amiga. And,
NewTek's Video Toaster is dependent on the Amiga's custom
chip technology.
* The Amiga offers the best "price/performance" for multimedia
computing solutions available today. In addition, the Amiga
provides "traditional" office computing applications and a
wide variety of entertainment packages. The Amiga also
provides options to read and write MS-DOS and MacIntosh files.
* This is the most exciting time in the history of Commodore
and Amiga computing. The company's visibility in the
microcomputer industry should increase significantly during
the next year as new programs, products, strategies and
applications mature.
Final Thoughts
We are taking specific steps to not only regarding this incident but also to
ensure that we regain more leverage and positive coverage in the general media
and reporting environment going forward. To that end, we're planning some
specific press events at both World of Commodore and Fall Comdex. We've also
begun an intensive telephone contact campaign to strengthen our ongoing
relationships with hundreds of editors, reporters, and freelancers who write
about Commodore and the Amiga. We are committed to increasing the flow of
accurate information to these important and influential media audiences.
In the meantime, please help us with the impressions precipitated by the
Robinson article; follow through on the recommendations we've made in this
correspondence.
Please consider faxing Mandi Griffies, in our corporate communications
department, copies of any correspondence you generate on behalf of this effort
and report subsequent media feedback and results directly to her. Her fax
number is (215) 431-9465. Thank you for your concern and partnership.
P.S. "The reports of my death are greatly exaggerated."
-- Mark Twain, 1897
209-536-0576 1ST OFFENCE BBS 209-536-0576
-=-=-=-=-=-= -=-=-=-=-=-=
SYSOP-NIGHT FLY COSYSOP-/X\EGAZAP
CRYSTAL DISTRIBUTION BBS!
_____ _____ __ __ _____ _____ __ _____
/ | \/ __>/ \/ \/ __>/ __>/ \/ __>
/ | \ ___\ \ ___\___ \ \___ \
\ | / / / / / / /
\_|___/\_____/\__\/__/\_____/\_____/\__/\_____/
____ ________
/_ / /__ /
/ / ___/ /
__/ /__
/______/
______ ______ ______ ______ _______ _______ ______
/ __ \ / __ _) / ____) / ___) / \ / ____) / ___)
\ / \ / \ __) \ __) \ \_ \ /\ / \_____ \ \ \_
/ \__/ \ / \ / \ / /__ / \ \ \ ____/ / / /__
\______/ \__/ \__/ \______) \__/ \_/ (______/ \______)
Sysop - /\/|GHT F|Y \ / co - sysop - /\/\egazap
A M I G A --+-- Console
1 + 2 0 9 / \ 5 3 6 - 0 5 7 6
 (( <./\.| )) The 7th <hurch of the /\pocalyptic |awnmower! (( <./\.| )) 
-+*$> ANTHROX UNITED KINGDOM/LONDON HEADQUARTERS: +44-81-459-4243 [AMI] <$*+-
 (( <./\.| )) The 7th <hurch of the /\pocalyptic |awnmower! (( <./\.| )) 
AMYLIVES.TXT UPLOADED TO <./\.| BBS By Mr.P0T-NOoDLE At WHENEVER
programming/AMIGA/anews3.txt
+466
View File
@@ -0,0 +1,466 @@
UL on Synchron City 22/9 1994
@BEGIN_FILE_ID.DIZThis is AmyNews 3
A compilation of new hardwares and
softwares for the Amiga
***** PLEASE SPREAD THIS FILE *****
_
_ // AMIGA, You Know It Rules!!!
\X/ Intel Inside! Idiot Outside :-)
@END_FILE_ID.DIZ
 
  _# **MMp g##0 `N##0" _agN#0P0N# _#
Go g## jN## j##F J## _dN0" " g##
_#]## _0 ##L jN##F ### g#0" _03##
gE_j## # 0## jF ##F j##F j## ______ gE_j##
_0"""N## d" J##L0 ##F 0## 0## "9##F" _0"""5##
_gF ]## jF ##0 ##F ##F `##k d## _gF j##
_g#_ _j##L__g#__ ]N _j##L_ _d##L_ `#Nh___g#N' _g#_ _j##
`"""" """""'""""' " """""" """""" """"""" `"""" Go """""
This is AmyNews 3.
New releases always from the start.
Amiga development continues as never befor.
These are only a fraction of what developers are developing for the Amiga
platform.
- A new version of landscape generating software, SceneryAnimator, is
in it's beta testing period :-)
More about this wonderfrul new release in a later issue of AmyNews
- Terra Nova Development announces the availability of Magic Lantern
v2.0, the critically acclaimed 24 bit animation package for the Amiga.
Magic Lantern version 2.0 allows users to create, edit and display
delta compressed animations in up to 24 bit color on all the popular
true color display cards for the Amiga, as well as all the native
Amiga modes (including AGA). It will also play sound effects in either
mono or stereo though the Amiga sound chip during animation play back.
New features include virtual memory support; now animations can be as
large as your hard disk, and Magic Lantern will still be able to edit
and display them. Double Time compression technology can double
animation speed and reduce animation sizes by half.
Another new compression technology has been added that can speed up
some animations (especially those in 16 and 24 bit) by up to 25%, and
reduce animation sizes by up to 20%. Rebuilding animations has been
optimized, and for large animations can be 75% faster.
Direct support for the Retina Z3 has been added, resulting in
animations that are up to 50% faster and 40% smaller for that card.
Magic Lantern 2.0 still contains all the features of previous
versions, including sound synchronization, enforcement of frame
rates, full ARexx support, animation disassembly, palette changes and
more.
- Sound/Noise tracker compatible module player for the Amiga, the D.A.S.
ModulePlayer's long awaited version 3.4 will be out soon. The new
version has, among other improvments, support for 6 more module formats
including TFMX Pro, TFMX 7V and C64 SID modules.
- Powerful spreadsheet for the Amiga, TurboCalc, will jump directly from
version 2.1 to 3.0. Lots of improvments are promissed. The goal is to
make it equal or better than microsoft excel. TurboCalc supports SYLK
format and in it's current version it's much like Excel. If you are
familiar with Excel then you are familiar with TurboCalc too.
More about this superb product in a later issue of AmyNews ;-)
- This is for those of you who use the powerful Blitz Basic II (ASIC SW);
Blitz User Magazine issues 6-10 (£15) are now available from:
Guildhall Leisure Services
Blitz Subscriptions
Unit 15 Guildhall Industrial Estate
Kirksandall
Doncaster
DN3 1QR
England
- Pure Logic Software president Jason Freund annonce that they are and
will be loyal to the Amiga users. Pure Logic Software is developing
a major upgrade to the "On The Ball" (a personal information manager
for ther Amiga). The upgrade is to be released Nov 1994.
- Questar Productions announces the availability of World Construction
Set version v1.0. The World Construction Set is a so called terrain
renderer or scenery generator/animator with promissing features.
World Construction Set (WCS) is the next generation of computer
terrain modeling software. WCS' powerful renderer sets new standards
in photo-realism, producing images that are often mistaken for actual
photographs. WCS' ecosystem modeling approach combines familiar 3D
imaging techniques with Nature's own processes to deliver scenes of
sublime beauty and lifelike detail to your Amiga.
World Construction Set is like nothing you have seen befor!
- ADPTools Professional v1.0 is now out. It's a powerful FronEnd for the
ADPro Professional (ASDG).
- Oxxi Inc reports that development of Oxxis superb multimedia package
VideoStage Pro continues. Oxxi estimates a release date Fall (1994)
for VideoStage Pro Plus, VSP+. VideoStage Pro in it's current version
is a powerful multimedia authoring program desined to compete with
the industry standard multimedia package SCALA InfoChannel.
VideoStage's impressive text animation capabilities also make it an
amazing video titling tool when used with a genlock. There is built-
in control for ECS chipset genlocks, GVP's G-Lock, and Digital
Creations' SuperGen.
- Silicon Prairie leading caching program for the Amiga, HyperCache
Professional version 2.0 is now out.
HyperCache Professional can speed up data access by as much as 3000%
on devices such as: SCSI & IDE hard drives, CD-ROM drives and floppy
drives.
- Electronics Art reports that the paint program DeluxePaint version 5.0
is under development. Among the new features Electronic Arts mentions:
- ARexx - Full command set, recordable and saveable macros.
- 24 Bit Backing Store - 24 Bit data creation, editing, loading,
saving.
- Multiple Palette Animation - Every frame can have a separate palette.
- Variable Rate Animation - Every frame can have a custom frame rate/
pause.
- Texturing, Media libraries - Used in conjunction to create
naturalistic art.
- Camera Moves - Create scrolling backgrounds, and camera zoom
animations.
- Gradient Translucency - Create gradient translucency fades.
- AnimBoard(tm) - Print animation storyboard in multiple layouts.
- Soft Edge Airbrush - New editable Airbrush has a natural look and
feel.
- Creation and editing of larger than screen animations.
- Move Requester Enhancements - Key Frame Animation, Animated Fades.
Electronic Arts estimates a release date Fall (1994) for DPaint 5.0
- A new version of the communication program NComm version 3.05 is now
released. The new version correct all known bugs and ads several new
feature.
- UK based company Marpet Developments annons the release of, CD32
S-Port ($35 US). This hardware/software package Connects the CD32 to
a 25 pin serial port via the keyboard port.
- "Paint Engine" is the new generation Paint/Processing package for the
Amiga. It is the fastest image processor for the Amiga and comes with
tons of feature. "Paint Engine" is in it's beta testing period. Beta
testers claims that on Amiga 4000, "Paint Engine" does almost real-
time image manipulation!!! Read more about it's outstanding features
in a later issue of AmyNews. Cybernetica will distribute
"Paint Engine".
- Just a quick note; Barfly version 1.09 is the first Assembler/Debugger
that currently supports the 68060.
- The standard mathematic program Maple V version 3.0 for the Amiga is
under development. Maple V is expected to be completed this fall.
A Student Edition of Maple V, release 3, will be distributed by
Brooks/Cole.
- Dice C devlopment package for the Amiga is available now in a new
version 3.0. For upgrade information contact:
Obvious Implementations Corporation
P.O. Box 4487
Cary, NC 27519-4487
USA
- HarmonySoft (Israel) announces the availability of the student's
version of Rashumon v3.0 for only $60. The student's version doesn't
include the printed user manual.
Rashumon is a multi-lingual word-processor for the Amiga. It supports
multiple fonts (including Agfa Intellifonts), 256 colors for graphic
objects and 8 colors for text and tables. it has full Postscript and
IFF support. One of the majour features in release 3.0 is Rashumons
ability to output Scala Lingua script. Any document can be converted
into Scala Lingua script format. The conversion includes: text (in any
language), color, attributes, layout, line spacing, tab stops, IFF
brushes. Structured drawings (made by Rashumon's Table Generator)
aren't supported in Scala's current version but will be supported in
next version.
HarmonySoft sells fonts for many different languages.
- MainActor v1.55 is out now. It's mainly a bug fixed version.
- XEMrip.library for all XEM-compatible communication programs is due
to immediate release. XEMrip.library gives your XEM-compatible terminal
software like Term, XCOMM, Terminus etc to communicate with RIP based
BBS system.
- The long-awaited book "Connect Your Amiga!" by Dale L. Larson,
published by IAM, Intangible Assets Manufacturing, ISBN 1-885876-02-5
is finished. Special discounts are available for early orders.
"Connect Your Amiga!" is 256 pages packed with information for
networking and for going online. From background information for the
novice to networking hints and tips for advanced users, this book has
something for every Amiga owner.
- Long-awaited raytracing program, LightWave 3D version 4.0 is now under
development. LightWave 3D v4.0 will be priced at $995.95. Owners of
the current standalone version, LightWave 3.5 for the Amiga, will be
able to upgrade to version 4.0 for $149.95.
LightWave has been used on TV shows like seaQuest DSV, Babylon 5, Star
Trek : The Next Generation, Robocop, Viper, Unsolved Mysteries, and
Weird Science to produce the final special effects shown on air.
Babylon 5 won an Emmy last year for its LightWave produced graphics,
and the Video Toaster also won an Emmy, due in part to its LightWave
3D system.
LightWave 4.0 includes a number of new features, including inverse
kinematics for character animation. There will also be a new plug in
filter system that will allow users to add features like real world
physics or advanced animation features. LightWave Modeler will also
feature multiple undo and redo, and Metaform, which allows simple
creation of organic and aerodynamic objects.
- The long awaited Image processing program for people on low budget,
ImageStudio v1.0 is now out.
- The new Wacom ArtZ (graphic tablet) is now out. Wacom sells drivers
for the Amiga. A new minor update to TVPaint will support all features
of the new Wacom ArtZ.
- Oxxi reports that the long awaited text editor TurboText TT is now
finaly out in version 2.0! upgrade fee for current owners is 20$
- Just for your information: Lightwave and Amiga has being used to render
the USS Pasteur in the final episode of STING. ;)
- CrosMAC by the Consultron, the maker of CrosDOS, is released now.
CrossMAC will enable you to access a 1.44MB drive and any other Mac
formatted drive. AmigaDOS 2.0 or better is required. For price and
more information contact: Consultron, 11280 Parkview, Plymouth, MI
48170, USA , Phone 313 459 7271
- Creative Focus at 1-(607)-648-4082 does Canon BJC-600 drivers for the
Amiga.
- The new version of EGS-TV, the video editing software for EGS and VLab
framegrabbers is out now :)
EGS-TV is a superior product for all Amiga EGS system and works as a
front-end for the V-Lab digitizer. Using EGS-TV powerful AREXX port
you can i.ex. grab sequences with precise control and it sports a
'Blue-box' facility for integrating backgrounds behind your foreground
subjects. For more information contact Helmut Hoffmann at:
hhoff@pool.informatik.rwth-aachen.de
- Term v4.1 is now out. It's maily a bug fixed version of version 4.0
- Creative Focus Box 580 Chenango Bridge, NY USA, annonce the release of
a bug fixed version of their Super_DJC3 driver. The upgrade fee is 0$
- Manuel Lemos of Upper Design (Portugal, yes they develop high quality
Amiga softwares even in Portugal) head programmer of one of the most
powerful recovery softwares for the Amiga, "Upper Disk Tools" version
1.01 is working on objetcs that will improve your DTP/Word Peocesser
software. Among long awaited objects, he mentions a very powerful
"Equation Editors" and "Bibliography database". The estimated release
date in Dec 1994.
"Upper Disk Tools" is a very powerful Amiga program for recovering bad
harddrives etc. It is the first Amiga program that uses the WorkBench
(TM) mecanism for it's GUI. If you know how to use Workbench and icons
you already know how to use "Upper Disk Tools".
- Apex Software's Forge texture generation program for the Amiga is now
avaiable to all multimedia creators. Forge is an awesome addition to
any LightWave animator's digital toolchest.
Forge is a texture rendering and animation program. Simply plug in
the textures, change the settings and render previews until you're
ready to render a final image. That final image is loaded into
LightWave as an Image Map for use like any other. Simple enough,
right? But Forge goes far beyond this basic need.
- Pester CeV Design (US) is working on their low cost trapdoor to Zorro
bus expansion system. Using it, you'd have the equivalent of an Amiga
4000 platform to build on for less than a grand invested.
- Jim Drew of Utilities Unlimited International, inventer of the Amiga
Emplant technology is announcing "The Edge" (Electronic Display
Graphics Emulator), the next generation graphic board for any Zerro
III Amigas. "The Edge" features:
64 bit wide Cirrus Alpine graphics processor interfaced to a Zorro III
slot. It supports the Industry standard ARGB. "The Edge" is backwards
compatible with any Cirrus 54xx series processor, meaning that you can
use the EGS Spectrum or Picasso II software with it but "The Edge"
will of course have it's own (fast) WB emulation/mode promotion
software. It uses 72 pin SIMMs (up to 8 megs via two SIMMs), and will
retail for ~$299 w/0k RAM. With video speed equal to the PowerMAC's
PDS video board, it is fast. 640x480x32 bit animations in realtime
by just moving the data to the board. Up to 80 megapixels per second,
and the blitter can move entire offscreen bit maps into the viewing
area without any glitches in the display. It's also very fasstttt.
- DIAVOLO backup software for the Amiga version 1.7 is now out. It's by
far the most user freindly and system freindly backup software for the
Amiga. Media Disk is the new distributer of the DIAVOLO in the USA.
- Interworks ethernet-based, Peer-to-peer Networking solution, Enlan-DFS
now new version 2.0 is now out
- Several new PIMs for Image Master R/t are now availble from Karl
Bellve at University of Maryland at Baltimore, Dept. Of Physiology
They are mainly used for scientific image analysis. Email him at
kbellve@umabnet.ab.umd.edu to obtaine the PIMs. They are free.
- Version 4.2 of the Shuttle Tracking Program, SatTrack is out now. It
allows you to track the position of the shuttle to see the laser
flashes that it will be projecting on the earth during the mission.
- I had a fresh FAX from the Blue Ribbons president concerning their
continuing support of the Amiga products. Most important points in the
fax are: "We are loyal to the Amiga platform. All our multiplatform
softwares like our "Bars & Pipes professional" are constructed for the
Amiga first. Then we port our softwares to other platforms. The
multitasking nature of the Amiga, makes this computer number 1 source
for the music and midi. We did a lot of improvments to the Track
Window Menu, Edit Window, Song Construction Window, Metronome,
printing, Tool and Accessories sections in the version 2.5 of the
"Bars & Pipes professional" but the development continues and we are
designing the next majour update to the "Bars&Pipes". The new version
will amoung other things support the MacroSystems Toccato"
- Ameristar ethernet cards are available again, through CEI US.
- EGS, Enhanced Graphics System, is now available for all Amiga non-EGS
graphic boards. GVP German distributor, DTM, Fax #: 06127-66276, Price
200DM
- MacroSystem Develpment Inc is working on it's 68060 version of the
"Warp Engine".
- A student edition of Maple V for the Amiga is under development.
Source, Bob Evans, the Director of Electronic Publishing at
Brooks/Cole.
- Awared winner professional CAD package for the Amiga, XCAD - 3000,
will soon come in a new version (this info directly from one of the
XCAD programmers). XCAD - 3000 in it's current version is up to 15
(yes 15) times faster than AutoCad on IBM PC platform. XCAD - 3000
was the winner of CADEX US 1993.
- Long awaited Aminet CD 4 is now ready for shipping
- A new bug fixed version of the Desktop Magic (Media Disk) is under
development.
- LHA v3.0 (the release version is probably named v3.1) is under beta
testing. It features amoung other things, a very user configurable GUI
and up to 35% better compression ratio.
- Long awaited TurboText TT version 2.0 is under development. This info
directly from TT's auther. TT v2.0 will be a majour update with lot of
of new feature.
- Digital Soundtrack (Visual Inspiration) let you add samples sound,
Midi songs and ST mode to your videos. Features include a preview
mode, jog and shuttle controlls, and PIP picture-in-picture support
for majour video boards. Digital Soundtrack supports various single-
frame controllers like AmiLink and PAR (Personal Animation Recorder).
- Ingenieurbuero Helfrich is making it's brand new Piccolo-SD64plus
graphic board. It features, 64bit-Blitter, Pixelclock 135 MHz, Zorro
II/III autosensing.
- PCTask (Chris Hames) v3.0 is under development. The new version is
reported to be faster and supports all graphic boards available.
- Genie Tools, vol 1 (Shead Data Processing) collection for Aladdin 4-D
offers a variety of tools including the TriSub and DoBeSphere
functions which let you create triangle-based spheres and the
LissaCurve control.
- Kermit Woodall of Nova Design, Inc. annons the development of ImageFX
version 2.0. Tons of new features are promissed, among them Fractal
Painter.
- Migraph MS2400 Color Scanner (SCSI connection) + state of the art
OCR software are now out. The package will turn the Amiga into a 2400
DPI, 24 bit color scanning workhorse. Info Migraph
- TurboCalc v2.1 is out now.
- The new version 2.1 of the powerfull MultiMedia authering program,
HELM is in the works.
- Check & Balance from AmiSoft is a new software that let you balans
your books and print out your checks.
- Awared winner Amiga dissassembler RESOURCE v6.0 is out now.
- A new improved version of ADPRO 24bit printer driver for the Primera
color printers can be obtained directly from your Primera dealer or
any dealer supporting ASDG products.
- Blitz Basic II version 1.9 and Bum 7 are out now.
- A wave of new softwares for the awared winner Amiga 3D software
LightWave is here. Amoung others are "Newton's Law" - Cybernetica,
PowerMacros - Cine Graphics and version 2.1 of Sparks - MetroGrafx.
- Long awaited upgrade to ProDraw (GoldDisk) is now here. Version 3.03
fixes all known and unknown bugs under later OS version
- PageStream 3.0 is shipping now ;) Japp! Best DTP program ever
- SOFT-LOGIK gives now 3 kind of user support for it's products,
more about them later in another message.
- SOFT-LOGIK is working on a rewrite of ArtExpression
- ProVector 3.0, from Stylus, Inc. in Colorado, in under beta testing.
Among tons of new feature, it will export Adobe Illustrator (all
versions). Stylus has worked close with SOFT-LOGIK to make the all
new ProVector a good completation for PageStream 3.0
- Final Writer 3.0 is under Alfa testing. Woody Williams, SoftWoods
President says it's a majour release and I see no reason to not
belive him ;-)
- Pegger 2.0, Image Compression software, is now out ;) Much Faster
- CanDo 3.0 with a lot of new stuff is ready for release soon
- MaxDOS v2.0 from Media 4 Production is now out. It allows you to read
warite Mac data using your Amiga.
- SAS C release 6.55 is due to be released very soon, among other news
is the new optimizer for 68060. JAPP!
- Brilliance 2.1 is under development
- SoftWood is working on a new powerful Database program for the
Amgia. They call it "Final Data".
- Utilities Unlimited is working on it's 68060 50 MHZ board.
They are working on a multiCPU board for Zorro Amigas. The board
can hold multiple numbers of CPU (up to 4 * 68060, now beat that!)
RAM access is done in a 64 bit interleaved. This may change to 128.
Burst is permanently on.
- Advanced Systems (Maker of Fastlane SCSI II board) are working on
their new 68060 board that can hold multiple numbers of 68060. The
board in modular and is ready for an ultrafast SCSI II fast&wide
controller, and ethernet board. It can hold up to 128 MB memory.
- Real 3D v3.0 is under development.
- TYPESMITH v2.5 is out now. Powerful font designer from SOFT-LOGIK.
Among imptovments: It will convert MacBinary or PC TrueType fonts to
any other format (PostScript Type 1 and Type 3, Intellifont, IFF RFF,
DMF). Also, it can export any font as a high quality TrueType font
with instructions (hints). Another nice new feature is the automatic
point reduction algorithm which allows you to clean up badly designed
fonts. The new overview printing feature prints complete character set
tables to any printer.
 
 
There are more news but this was all for this time.
Have fun with your wonderful Amiga
--------------------------------------------------------------------------------
___ __ ____________ _ __ ___________ __
/ _/\/ /\/ / __/ / /_ \/ \ /\/ / / __/ /_ _/\/ / Sysop: Vivace/XAKK
\_ \ / / /_/ / / O \ / / /_/ / / / \ / Cosys: Knatter/XAKK
/___/_/_/\/\__/_/_/_/\_\___//\/ \__/_/ /_/ /_/
X a k k h e a d q u a r t e r s
"NO ELITE, JUST PURE INFORMATION"
--------------------------------------------------------------------------------
- Lots of underground cyberpunkish textphiles - 6000 philes and rising -
- 16800 DS - 420 Meg - PC/Amiga/ST - Free Download for all Star Trek f¡les -
+46(0)431 17506
--------------------------------------------------------------------------------
programming/AMIGA/antialia.txt
+143
View File
@@ -0,0 +1,143 @@
What is ANTIALIASING?
Everything you see on your computer monitor is the illumination of pixels
(dots, that is) in various patterns. These dots, however, are not infinitely
small, and therefore, if you are drawing lines, circles, or any polygons with
edges, you will notice jaggies. Jaggies (or staircasing), is an inevitable
by-product of approximating these smooth surfaces on a grid... and the lower
the resolution of your display (or coarser the grid), the worse the problem.
Well, since higher resolution reduces the problem, why not have displays
with resolutions of 1,000,000 x 1,000,000 , instead of the measly 640 x 400
or 320 x 200 resolutions we have on the Amiga? One awfully good reason is
that whenever you double the resolution of a computer, the amount of memory
the display takes up is quadrupled. That starts to get rather costly. Also,
one of the reasons our computers and monitors are so reasonably priced is
that they use hardware that is mass produced for television, which is about
640 x 482 pixels of resolution, in the US. Go much beyond that, and you'd
better be rich to afford the monitors and display circuitry.
So what to do? Fortunately, higher resolution isn't the correct approach.
No matter how fine your grid is, there are certain kinds of images that are
sure to produce nasty artifacts, such as the classic "checkerboard floor
extending to infinity". You will start to get fascinating, but unwanted
moire patterns.... trust me. The best way to deal with the dreaded jaggies
is - ANTIALIASING! But to do antialiasing, you need colors. Lots of them.
Sorry. On the Amiga, you can fake it though, and that is what I've done for
this demo/tutorial. Colors are cheaper (in terms of memory) than pixels, and
we should bow our heads with gratitude that this is the case.
I know that people sing rhapsodic praise about the wonders of Amiga graphics,
and I'm one of them, as far as it goes.... but effective anti-aliasing really
seperates the 'adults from the children'. You not only need to have lots of
colors, but you want to know where they are fast! What we are effectively
doing is blending colors together- blurring the edges, as it were. The more
colors you have between any color you may wish your line/circle/polygon to be,
and what color(s) you are writing it on, the better. Fortunately, we live in
times in which the price of framebuffers is plummeting. I know of one
manufacturer who will be marketing a 32,000 color (all on the screen at
once) frame buffer for about $1500, for the IBM PC. We can expect to see
similar technology in the Amiga universe shortly, I would wager.
For those of you with limited patience, or limited budgets, who wish to
enter the exciting world of programming anti-aliased graphics, I humbly
provide this code, which plots concentric circles, in 320 x 200, both
anti-aliased and normally. You won't have to ask which is which. I get
around the requirement for a zillion colors by filling the 16 color map
with a range of intensities of yellow to black, so it only draws yellow
figures on a solid black background, or vice-versa. But you'll get the
idea.
How does ANTI-ALIASING work?
I'm glad you asked. A common way of drawing lines or circles involves
the use of something called a DDA, or Digital Differential Analyzer (or
something like that). What this means is, you keep track of when to
increment (or decrement) your 'X' coordinate (or 'Y'), depending on the
value of a "remainder" variable, which we'll conventionally call 'R'.
Here's a simple example:
line(x1,y1,x2,y2)
int x1,y1,x2,y2;
{
int dx, dy;
int r;
dx = x2-x1;
dy = y2-y1;
r = (dx-dy)/2
while (x1<=x2)
{
x1 = x1+1;
r = r+dy;
if (r>=dx)
{
r=r-dx;
y1=y1+1;
}
Draw_a_Dot(x1,y1);
}
return;
}
(For simplicity, this routine will only plot lines between 0 + 45 degrees -
it can be adapted for all lines, at your leisure.)
Lets say you want to draw a line from 10,10 (x,y) to 70,20.
The change (delta) of X is 60 (call this DX), the delta of Y (DY) is 10.
For the hell of it, we initialize the remainder, R, to half of DX-DY (or 25).
We keep adding DY to R (while incrementing X, and drawing dots at (X,Y)),
until R exceeds DX, at which time we subtract DX from it, and increment Y.
In our example it would look like this:
X Y R R/DX
11 10 35 .58
12 10 45 .75
13 10 55 .92
14 11 5 .08
15 11 15 .25
16 11 25 .42
17 11 35 .58
18 11 45 .75
19 11 55 .92
20 12 5 .08
... ... ... ...
Now here's where the anti-aliasing comes in: the DDA's 'R' can be pressed into
double duty by thinking of its relationship to DX as a PERCENTAGE of coverage
of a pixel by the line. In other words, assuming a line of one pixel thickness,
58% of the pixel at (11,10) is "covered" by that line, so by interpolating
the color of the line and the color of the pixel by 58%, you get the color you
should paint there! If the pixel is color 0 (black) and the line is color 15
(yellow), color 8 (medium yellow) should be painted there. If 58% of the
pixel is covered, and the line is one pixel thick, where is the other 42% of
that line? At (X,Y-1), since our line is going "up", the trailing edge is
"under". So you paint a "trailing edge" of that line at 42% yellow (color 6)
interpolated with backround color. Do this for each point you plot, and
voila, you have an anti-aliased line. Congratulations.
[ interpolation: getting the difference between two values, multiplying that
difference by a percentage, and adding it back in to the first value. i.e.
a 10% interpolation between 10 and 50 is 14 ((50-10)*.10)+10) ]
Antialias.c uses this method with a circle drawing DDA.... due to the
aspect ratio of the pixels, the circles aren't round, but you can easily
fix that yourselves, if you have a yen to.
At this point, I wish to acknowledge my indebtedness to Mike Higgens,
who published this method of anti-aliasing edges quickly, using integer math.
He was my colleague at Time Arts, and for years I will be rediscovering
things that he's already forgotten.... Thanks Mike!
You can leave comments, gripes, questions, and blonde virgins to me
at AMIC or CIS # 73267,2124.
Miles Keith Kurland
The Programmer General
"Warning! The Programmer General has determined that
failure to back up your hard disks may result in
lost data, acute anxiety, and random acts of violence"
programming/AMIGA/article
+506
View File
@@ -0,0 +1,506 @@
Autorouting with the A* Algorithm
1. Introduction
A few years ago, a friend of mine designed an adapter board for the IBM PC.
The tools he used were blue and red strips of tape, a sharp knife, large
sheets of clear plastic, and a generous amount of patience. It took him
several weeks, and after the first board was tested he discovered that some of
the traces were incorrect, and had to be cut with the knife and rerouted with
solder and wires. This caused me to start thinking about ways to use the
power of the computer to simplify this tedious, error-prone job.
What you want to do when designing a printed circuit board is implement an
electronic circuit. First you will create a schematic which represents the
circuit. From this, you will derive a list of TTL chips and other components
that implement the needed functions, and a list of the pins that need to be
connected. Together, these lists are referred to as the netlist. As long as
the connections are made correctly, you usually don't care where the traces
(the wires that will be embedded in the board) are placed. Autorouters are
computer programs that do this task for you.
As we will see, the autorouting problem is really a search problem, and there
are algorithms from the field of artificial intelligence we can use to solve
it. We will look at two of these, the breadth-first and A* search algorithms.
The C source code for a freely-copyable implementation of an autorouter using
the A* search algorithm accompanies this article, and programs to view the
routed printed circuit board and print it on a laser printer are also
available.
2. Autorouters
Autorouting can be viewed as a global optimization problem, which are very
difficult problems to solve. To produce a good circuit you want to minimize
some things (trace length, board size, number of routing holes (holes created
by the autorouter to transfer a trace from one side of the board to the other,
also called vias), signal crosstalk, number of layers, cost to manufacture)
while maximizing others (signal strength, reliability, ease of debugging).
The measure of the overall value of a circuit will be a function of all of
these often conflicting variables (assuming the circuit behaves correctly,
otherwise its value is zero). Usually it is acceptable to find a solution
which satisfies a set of constraints, because finding the globally optimal
solution is infeasible for all but the most trivial problems.
Autorouting can also be viewed as a collection of search problems. The
individual search problems deal with finding a route, and laying down a trace,
between two locations on a printed circuit board. There are many algorithms
for solving search problems, each with different running time characteristics
and data space requirements. The two search algorithms we will be discussing
are breadth-first and A*.
3. Autorouting by Searching
When search algorithms are used to solve the autorouting problem, they
typically operate in two phases (reference [1]), and treat the board as a
matrix of cells. The first phase starts at the source cell and searches for
the target cell, usually by going in several directions at the same time.
While searching, an auxiliary data structure will be built which keeps track
of how each cell was reached (this is referred to as Pred in the algorithms in
figures 1 and 2). Once the target cell has been found, the first phase is
finished, and the second phase is started. However, if the first phase
exhausts all possibilities without reaching the target cell, then no route
exists between them, and there is no reason to do the second phase.
In the second phase, the auxiliary data structure is used to trace the route
from the target cell back to the source cell, actually laying down the
electrical connections. The second phase is identical for the breadth-first
and A* search algorithms. But the first phase is different, and it is what
gives these algorithms different behaviors.
The main data structures used in the first phase are the Open queue and the
Closed set, and are used to hold cell coordinates. Since a cell's coordinates
uniquely identify that cell, we'll say that the Open queue and Closed set
contain cells. Cell coordinates will be represented as r2c3s1 for the cell at
row 2, column 3, side 1, or as r2c3 when it is understood that all cells are
on the same side of the board. To remind ourselves that Open is a queue and
Closed is a set, when we talk about adding cells to them, we will put the
cells "on" the queue, and "in" the set. Initially, the Open queue contains
the source cell and the Closed set is empty. The first phase is a loop which
removes an element from the head of the Open queue, puts it in the Closed set
(which indicates that it has been searched), and checks to see if it is the
target cell. If it is, the first phase is done. Otherwise, the neighbors of
the cell (the cells that are adjacent to it) are placed on the Open queue, and
the loop continues. As we will see below, the essential difference in the
breadth-first and A* search algorithms is the order in which the neighbors are
placed on the Open queue.
4. Breadth-First Search
The breadth-first search algorithm (figure 1) works by processing a
first-in-first-out (FIFO) queue of open cells (cells that have been reached,
but not yet searched). Initially, the open queue contains only the source
cell. A cell is removed from the head of the open queue, placed in the set of
closed cells (cells that have been searched), checked to see if it is the
target cell, and if it is not, its neighboring cells are placed at the tail of
the open queue. Neighboring cells which have already been reached are
ignored. (If a cell's coordinates are on the open queue or in the closed set,
then it has been reached. Otherwise, it has not been reached.) This
continues until the target cell has been found, or the open queue is empty, in
which case the target cell cannot be reached from the source cell.
A version of breadth-first search known as Lee's algorithm (reference [2]) was
applied to the autorouting problem in the early 1960's, and is still the basis
of some autorouters. (In the original algorithm, cells diagonally adjacent to
each other were not considered to be neighbors. Consequently, the
backtracking phase could only create horizontal and vertical traces. We will
enhance the algorithm so that diagonally adjacent cells are neighbors, thus
diagonal traces can also be produced.) Unfortunately, Lee's algorithm suffers
from a behavior inherent in the breadth-first search technique which limits
its application to problems of relatively small size. As the distance between
the source and target cells increases by a factor of N, the number of cells
processed by Lee's algorithm (and therefore the processing time) increases by
the square of N.
The behavior of Lee's algorithm while searching for a path between the source
cell S (r5c5) and the target cell T (r8c8) is shown in figure 2. Lee's
algorithm does not specify the order in which neighboring cells are placed on
the open queue, but we will use the compass directions north, east, south, and
west, followed by northeast, southeast, southwest, and northwest. This order
tends to produce traces with a minimal number of turns.
In figure 2a, the source cell (r5c5) has been searched, and its eight
neighbors have been placed on the open queue. The arrows indicate the
direction from which each cell was reached, and correspond to the Pred data
structure. After the first eight cells on the open queue have been reached
and moved to the closed set, the configuration in figure 2b is searched, where
there are 16 cells on the open queue. Once these 16 cells have been searched,
the configuration in figure 2c is reached. Now the target cell (r8c8) is
fourth from the end on the open queue, and a solution is imminent. When r8c8
is searched, it will be recognized as the target cell, and the Pred data
structure will be used to construct a trace back to the source cell.
You can see that the search progresses outward from the source cell in all
directions, like the ripples in a pond when you throw a pebble into the water.
If we double the size of the problem (S and T are six cells apart), the number
of cells searched (and therefore the processing time) will be roughly four
times as large, and if we triple the size of the problem, the number of cells
searched will be roughly nine times as large. Thus, the behavior of Lee's
algorithm is quadratic in the size of the problem, which makes it infeasible
for large problems.
5. A* Search
The A* search algorithm (figure 3) also works by processing a queue of open
cells, which initially contains only the source cell. But this is a priority
queue, which means cells are inserted according to the estimated distance to
the target cell (reference [3]), not just at the end. Cells that are on the
shortest estimated path from source to target are placed at the head of the
queue. Cells are still removed from the head of the open queue, then they are
checked to see if they are the target cell, and if they are not, their
neighboring cells are put on the open queue at the proper position.
Neighboring cells which have already been searched are checked to see if the
new path between them and the source cell is better (shorter) than the
previous one. If it is, they are repositioned on the open queue according to
the new estimated path length from source to target. As in breadth-first
search, this continues until the target cell has been found or the open queue
is empty.
A* depends on being able to estimate the distance between a cell and the
target cell. In the case of autorouting, a simple measure of this distance is
available, and this helps A* to concentrate the search in the direction most
likely to succeed. The more accurate the estimate is, the faster the search
will be.
In practice, A* does not suffer from the quadratic behavior of Lee's
algorithm, so it solves the same problems faster, and can be applied to the
larger problems that Lee's algorithm performs so poorly on. As the distance
between the source and target cells increases, the number of cells processed
by A* will increase, but not as dramatically as with Lee's algorithm.
The behavior of the A* search algorithm is shown in figure 4. The A*
algorithm does not specify whether new cells are placed in front of or behind
cells already on the open queue which evaluate to identical estimated path
lengths. We will use the convention that they are placed in front of cells of
the same distance. This will minimize the amount of time to insert a cell on
the open queue.
In figure 4a, the source cell (r3c3) has been searched, and its eight
neighbors have been placed on the open queue. Each cell on the open queue
also includes the estimated length of the shortest path from S to T that goes
through that cell. After the first cell on the open queue (r4c4) has been
searched and moved to the closed set, the configuration in figure 4b is
reached, where there are 12 cells on the open queue. Once the next cell
(r5c5) has been searched, the configuration in figure 4c is reached. Now the
target cell (r6c6) is at the head of the open queue, and a solution will be
found on the next iteration of the loop. When r6c6 is searched, it will be
recognized as the target cell, and the Pred data structure will be used to
construct a trace back to the source cell.
You can see that the search progresses more directly toward the target cell.
The search is drawn toward the target just as the earth's gravity pulls
objects toward the center of mass. If we double the size of the problem, the
search will search roughly twice as many cells, and if we triple the size of
the problem, the search will search roughly three times as many cells. This
linear behavior makes A* more attractive for autorouting than the quadratic
Lee's algorithm. With the incorporation of the heuristic (the rule which
guides the search in the direction most likely to succeed), it is more
difficult to specify a worst case behavior. However, A* will never take more
time than Lee's algorithm, and will never search any cells that Lee's
algorithm could avoid.
6. Optimizations and Generalizations
The algorithms in figures 1 and 3 solve the general search problem. When we
implement these algorithms and customize them to a particular application,
there are a few things we can do to speed them up.
The A* algorithm as presented in figure 3 recomputes the heuristic H(y) when
it discovers a better way to reach a cell. Depending on how difficult this
heuristic is to compute, we can probably save some work at the expense of
complicating the algorithm. When lines 20 and 21 of figure 3 are executed,
the previous values of G[y] and F[y] are destroyed. But F[y] = G[y] + H(y),
so we could save F[y] - G[y] (which is H(y)) in a temporary variable, and use
that variable instead of recomputing H(y) on line 21. Also, the common
subexpression G[x] + Distance(x,y) should be placed in a temporary variable,
instead of being computed twice (lines 18 and 20).
Often, rather than searching for a path between two individual cells, what is
really desired is a path between one of a set of source cells and one of a set
of target cells (as when connecting power and ground pins). Both algorithms
can be modified by adding the entire set of source cells to the initial open
queue, and checking for a member of the set of target cells on each iteration.
When this is done, the heuristic that the A* algorithm uses becomes more
complicated. It must estimate the minimum distance from the current cell to
any one of the target cells.
For breadth-first search, once the target cell is placed on the open queue, it
is pointless to add any more cells to the open queue. In fact, once this
happens the problem has been solved. An appropriate shortcut would be to
insert a check before line 13 in figure 1 to see if y is the target cell. If
it is, immediately use Pred[y] to construct the trace back to the source cell,
and return.
Distance Calculations [sidebar topic, with figures 5, 6, and 7]
The A* search algorithm depends on a heuristic to estimate the distance
between the current cell and the target cell. As implemented in the
accompanying program, the heuristic is a simple geometric distance
approximation.
Figure 5 illustrates all of the possible cell types used to construct a trace,
grouped by type. For each group, the distance of that cell type is also
given. These distances are calculated based on a cell size of 50 mils by 50
mils. A mil is a thousandth of an inch, so the autorouter uses 20 cells per
inch. A typical full-length adapter board for an IBM PC is 4 inches high and
13 inches long, or 80 cell rowss by 260 cell columns.
The traces of groups B and C can coexist in the same cell, so that a hole can
have up to 16 traces connecting it with other cells (8 on each side of the
board). Also, the parallel traces of group F can coexist in the same cell (on
the same side of the board), as shown by group J. This allows the routing of
two traces through the same cell, providing the higher density required by
some circuits (memory arrays, for example). Aside from these exceptions,
cells can only contain one type of trace (on each side of the board).
In figure 6, we want to know the approximate distance of a trace that will
connect the two holes. Viewing the board as a matrix, the differences in cell
coordinates are three rows and five columns. The shortest path between them
will use a diagonal trace across three cells and a horizontal trace across two
cells, as shown. Using the cell types in figure 5, the length of the trace
will be 23 + (2 * 71) + 60 + 50 + 12 = 287 mils.
A trace that uses a routing hole to go from one side of the board to the other
covers a greater distance than one that goes diagonally across a cell (group E
in figure 5) and stays on the same side of the board. This is because part of
its path goes around the edge of a circle.
A hole is 25 mils in diameter, and is at the center of a cell. To calculate
the distance of a trace through a routing hole, we measure the section of the
hole between the two connecting traces. Figure 7 shows an entering trace
connecting to a hole at point A, and possible exiting traces on the opposite
side of the board at points B, C, D, and E. The distances between A and each
of these points are 10, 20, 29, and 39 mils, respectively. To calculate
these, we use the geometric formula Circumference = PI * Diameter
(approximately 78.5 mils) and divide by eight (a one-eighth section of a hole
is approximately 9.8 mils), then add one, two, three, and four of these
sections, and round off to an integer.
The heuristic in the accompanying program includes a penalty when a trace
takes a turn or switches to the other side of the board through a routing
hole. This is because turns are often the weak points in a circuit, and
traces are more likely to break at a turn than in a straight part. Including
a penalty encourages A* to use straight lines, and even allows a slightly
longer trace to be selected over one with too many turns. The amount of
penalty depends on the kind of turn; sharper turns are assessed a larger
penalty. Routing holes incur a significant penalty, since overusing them
early in the routing process can make later traces more difficult or even
impossible to construct. This is because a routing hole dedicates a cell
exclusively to a single trace, for both sides of the board. Such a cell is
not available to later routing, thus reducing the total number of cells that
can be used.
7. Memory Requirements
Both of the search algorithms require quite a bit of memory in order to solve
problems of non-trivial size. The breadth-first search algorithm needs memory
to represent the board, the predecessor structure, and the closed set. The A*
search algorithm needs these too, plus structures for F[x] and G[x]. In
addition, both algorithms need to dynamically allocate memory for the open
cell queue.
In this program, the board is represented as a pair of two-dimensional arrays
(one for the front side of the printed circuit board, and one for the back
side), where the dimensions are the number of rows and columns of cells. Not
counting holes and traces relating to holes (figure 5, groups A, B, and C),
there are 30 possible cell contents, which can be represented with five bits
per cell. The hole-related cells are more difficult to enumerate, since they
can be combined in many ways. If we simply assign one bit to each of the
eight traces in groups B and C, and add one more bit to indicate a hole, 14
bits will be sufficient to represent any cell. On a board of N rows and M
columns, we'll need N*M*28 bits total.
The predecessor structure will also be a pair of two-dimensional arrays, where
an entry must be able to represent one of the eight compass directions or an
indication for the opposite side of the board. This will take four bits per
cell, or N*M*8 bits total.
The closed set can be represented by a pair of two-dimensional single-bit
arrays, where a bit is one if the corresponding cell has been searched, and
zero otherwise. This will take N*M*2 bits total.
F[x] and G[x] will be similar to the board arrays, but they must contain a
16-bit integer for each cell. This will take N*M*64 bits total. Note that if
memory usage needs to be minimized at the cost of increased processing time,
we could omit the F[x] arrays, and calculate the F values as they are needed
from the G[x] arrays and the heuristic function, H(x).
Breadth-first search will require N*M*38 bits and A* will require N*M*102 bits
of static memory. For a printed circuit board that is 4 inches by 13 inches
(80 cells by 260 cells), breadth-first search will need 98800 bytes and A*
will need 265200 bytes. It is often the case that different algorithms to
solve the same problem trade off memory against processing time to achieve
different behaviors. This is the case with breadth-first search and A*.
8. Locality of Reference
Despite the fact that A* requires more memory than breadth-first search, A*
exhibits better memory usage patterns. This is because it shows better
locality of reference than breadth-first search. Locality of reference deals
with the sequence in which memory locations are used, and consists of two
rules of thumb: (1) the memory location currently being referenced is likely
to be referenced again in the near future, and (2) memory locations near the
one currently being referenced are likely to be referenced in the near future.
When the first rule holds true for a given program, that program can probably
benefit from a memory cache. When the second rule holds true, the program can
probably benefit from a virtual memory environment with a least-recently-used
page preemption policy. Most computer systems with virtual memory and caches
apply them to both code and data, so programs that exhibit good locality of
reference should benefit from both rules.
This becomes a factor when solving large problems (say, routing a printed
circuit board that is 10 inches in both dimensions). In a virtual memory
environment, improved locality of reference can minimize swapping. In an
environment with cache memory, improved locality of reference can increase the
cache hit rate. Both of these tend to decrease the total running time.
The memory references in the breadth-first search algorithm go around and
around in circles of constantly increasing size, and do not reflect a common
locality of reference. Thus, the breadth-first search algorithm is not able
to take good advantage of virtual memory or a memory cache. However, the
memory references of A* tend to be from the same area of the printed circuit
board for extended periods of time, taking better advantage of these
mechanisms. On a large problem, this helps to offset the extra memory that A*
requires by adding speed beyond that provided by the basic algorithm.
Improved locality of reference by itself may not be a sufficient reason to
select A* over breadth-first search, but it is icing on the cake.
9. Input and Output Formats
Figure 8 contains an example input file; it defines a circuit to calculate a
parity bit for a 16-bit word using exclusive-or gates. There are statements
for defining the size of the printed circuit board, the locations of holes and
components, and the connections between them.
The autorouter sorts the connections by approximate trace distance (see the
section on distance calculations, above); the shortest connections are
processed first, and the longest are processed last. However, connections
which include the "priority" keyword are processed before any of the other
connections. This allows the designer to have control over the order in which
traces are constructed.
In addition, there are statements for defining chip templates, and associating
position-independent labels to each component and pin. This makes it easy to
move components from one location to another without having to edit each
connection. Chips can be rotated in any of four directions.
Figure 9 shows the traces created by the autorouter while processing the
example input file in figure 8. On an 8 Mhz IBM PC-AT compatible computer,
this board took 37 seconds of processing time to route.
The output from the autorouter is a copy of the printed circuit board as it is
represented in memory. This consists of the dimensions of the board (number
of rows and columns), followed by a pair of two-dimensional arrays (one for
the front side, and one for the back). The elements of the arrays are double
words (32 bits) containing bits which encode the contents of each cell. For
example, if a particular bit is set, there is a horizontal line running across
the cell, and if a different bit is set, there is a hole in the cell.
10. Viewing and Printing the Board
A program to view the routed printed circuit board on an IBM PC equipped with
an enhanced graphics adapter (EGA) is provided with the autorouter. The
viewing program provides four levels of detail (zooming), panning, and viewing
of the front and back sides of the printed circuit board separately.
Another program prints the routed printed circuit board on a laser printer.
This program allows the user to specify four levels of detail and resolution
ranging from 75 to 300 dots per inch (dpi). Figure 9 was produced with this
program using the maximum zoom level and 300 dpi.
11. Future Enhancements
The autorouter presented here provides the basics of a personal computer CAD
system, but could be enhanced in many ways. A few of these are:
* Use Lotus-Intel-Microsoft (LIM) 4.0 expanded memory to provide access to
more memory.
* Incrementally save the board after each connection is routed, so that a
large problem can be solved in several short sessions, rather than requiring
a computer to be dedicated for an extended period of time.
* Automatically compress the output (which often consists of many repeated
bytes) to save disk space.
* Wide traces for power and ground.
* Calculate how close the solution of each connection is to the optimal
solution.
* Add symbolic support for components such as capacitors, resistors, and
diodes.
* Support surface mount technology (a pad, rather than a hole).
* Display a "rat's nest" of direct routes (use a straight lines for each
connection, without regard for whether traces cross). This would help the
designer decide how the components should be arranged. It may also be
possible to do an analysis, and suggest in which direction each component
should be moved. Reducing the total distance of the traces that must be
routed can significantly reduce the processing time of any autorouter.
* Provide support for printed circuit boards with more than two routing
layers.
* A program the designer can use to edit the routed printed circuit board.
* Allow multiple priority levels for connections.
* Visually distinguish holes from routing holes by displaying them in a
different color.
* Increase the size of the TTL library (chip definitions).
* A program to translate the output into Gerber format (a standard language
for describing trace and hole placement, used for board fabrication) and
Excellon format (a standard language for describing hole placement, used to
drill the holes).
12. Conclusion
When autorouting is viewed as a special kind of search problem, there are
several search algorithms from the field of artificial intelligence that can
be used to solve it. An autorouting program can be easily implemented on a
microcomputer, such as the IBM PC family of computers, and can greatly reduce
the amount of work required to route a printed circuit board by hand. When
combined with other tools, such as the viewing and printing programs,
high-resolution output devices (laser printers), and high performance
386-based microcomputers, a complete design system can be built which makes
tape-ups obsolete. Just a few years ago, such a system would have required an
expensive workstation.
13. Author Biography
Randy Nevin received a BS in computer science from Oregon State University in
1983 and an MS in computer science from the University of Washington in 1988.
He has worked for Microsoft since 1983 on various programming language and
networking products.
14. References
[1] Stephen E. Belter, Computer-aided Routing of Printed Circuit Boards: an
Examination of Lee's Algorithm and Possible Enhancements, BYTE, June 1987,
pp. 199-208.
[2] C. Y. Lee, An Algorithm for Path Connections and Its Applications, IRE
Transactions on Electronic Computers, September 1961, pp. 346-365.
[3] Steven L. Tanimoto, The Elements of Artificial Intelligence, 1987,
Rockville, Maryland: Computer Science Press, pp. 148-164. This covers the
breadth-first and A* search algorithms.
programming/AMIGA/bbs_ads.txt
+25
View File
@@ -0,0 +1,25 @@
------=Bad Ad=-------=Bad Ad=------=Bad Ad=------ 22:10:10 - 11.04.1993 -----
THiZ FiLE WAZ DOWNLOADED FROM
FiDONeT 2:200/612 /\ . /\ * . MeGaNeT 66:666/1
. * . / \ . / \ .
FUJiNeT 7:102/102 / \ + / \ . NeST 90:1101/112
+ / / \ / \ +
/\ \ / . / \ / .
I.C.S Swedish HQ . / \ \/ / /\/ . Sync World HQ
\ / / \ \/ +
* \ / + . \ \ . . .
. \ / \ /
SysOp: Troed \/ARCASTIC \/XISTENCE CoSysOp: Zaphod B
+46-(0)451-91002 +46-(0)451-91002 +46-(0)451-91002 +46-(0)451-91002
=-=-=-=-=-=-=-=-=-=-=-= USRobotics 16800 DUAL STANDARD =-=-=-=-=-=-=-=-=-=-=
Supporting: Atari ST/STE/MSTE/TT/ATW/Falcon030/Super Nintendo/Copiers
TextPHiLES: Motorola/Texas Instrument/Phreaking/Hacking/Anarchy/Perverse
Diff Info/Fuzzy Logic/Science/Hardware Hackz/ up-to-YOU!
.oO ACTIVE USERS FROM MORE THAN 15 DIFFERENT COUNTRIES! Oo.
DiRECT LiNK TO USA/GERMANY/LUXEMBOURG F0R *FAST* STuFF!
+46-(0)451-91002 +46-(0)451-91002 +46-(0)451-91002 +46-(0)451-91002
< Advertisment added using -=Bad Ad=- 1.91 by Troed/Sync. BBS: +46-451-91002 >
programming/AMIGA/dox.nfo
+21
View File
@@ -0,0 +1,21 @@
KNOCK ON THE DOOR TO THE...
_____ _____ ________ ____ __ _ ____________ ___________
\ /\\ \/ __ \/ __ Y | / \/ ____ __\/ __ _____/
/ /__/ /\ /_/ /\ /\ \ |/ /\ _\ /\ \_\ /_/\_____ \
/ ___ _/ / __ / / /__\_| \ \ \/_/_ \ __ \/ ____\ \
/ /\ / _/\/ /\/ / / Y /| |\ \ \ Y \ \ \/\ \/\_ Y \
/__/ /__/ /__/ /__/ /______/ |__| \__\ \______\ \__\ \__\/\_____/
\__\__\__\_\__\_\__\_\______\_\__|_/__/_/______/_/__/_/__/_/____/
/_____//__/ /______/ /________/ | \__\ \__\ \_____\ \_\ \___\
\_ / \ \ \ \ \ ___ \ | / / / / / / / / \ _/
\_ \/_\ \ \ ___\/\ \__\ \ | / / / / / ___/ / \ /_/S
\ ___ \ \ \// \ ___ \ | / / / / / _/ / \/ / N
\ \ \ \/ \/___/ \ \ \|_\ \/ / / /__ / /\ / O
/____\/ \___/\_ _____/\__\/ \___________\/______\/___\ \__\ W
Y Y Y Y Y Y Y Y :
: . : -WORLD-P/H/A-CENTRE-. : . :
Sysop: SNOW USR 16.800 Dual Standard. +PURE AMIGA - 0 DAYS!
Cosys: EXERON&MANIAC Competition, is none... +FAMOUS EROTICS!!
Cosys: BIG BEN
International: +46-(0)63-123136 / Vikings: 063-123136
programming/AMIGA/errorcod.txt
+188
View File
@@ -0,0 +1,188 @@
AmigaDOS Error Codes - An Explanation
 For those of you who've tried in vain to find an explanation
for an error message in your user's manual, only to give up once you
realise it either isn't listed or is insufficiently explained, here is
a comprehensive list of the Amiga's most hated system messages!
Error 103: Insufficient Store
 This error occurs when you click on an icon or try to run from
CLI a program which the Amiga knows it hasn't enough free memory to
handle. It will most often afflict owners of unexpanded A500s.
Try closing as many windows as possible and ensure that
nothing is running as a background task before attempting to run the
program again. If this doesn't work it may simply be that you will
have to purchase a memory exapnsion before being able to use the
program in question.
Error 105: Task Table Full
 This error will only occur if you are pushing the Amiga to its
limits. The machine can run up to 20 CLI tasks at once, so if you try
to open task number 21, you will get error number 105. If you succeed in running 21 tasks at once, let
me know so I can inform the Guiness Book of Records!
Error 120: Argument line invalid or too long
 Another error code you shouldn't run into too often. This one
alerts you to the fact that you had "bad args" or that you tried to
input an extremely long series of CLI commands at once. If you're
faced with this command, truncate your CLI line or carefully check the
syntax of whatever you've typed in.
Error 121: File is not an object module
 You have typed in the name of a program or file as if it was
an executable object. In other words, you have led the computer to
believe that "thingy" is a program when it is in fact a text file.
You will also get this error if a script file's name was typed
in when its script bit was not set.
Error 122: Invalid resident libary during loading
 This will happen if your program looks for a library file in
the LIBS: directory when loading, but finds a library of the wrong
type. You could have a corrupted library file, or perhaps a different
file which has been given its name. In either case, the best course of
action is to sort out exactly what libraries a program needs, then
make sure the correct files are in the LIBS: drawer.
Error 202: Object in use
 Your program tried to access a file which was already being
altered by another program. Obviously, two programs cannot carry out
two operations on the same file at the same time, so you get error
202 and must wait until the other program is finished before going on.
Error 203: Object already exists
 You have tried to create or rename a file using the same name as
that of an existing file in the current directory. To avoid
the clash, either delete or rename the older file.
Error 204: Directory not found
 You have tried to DIR or CD to a directory which is not in the
current directory. You're either hallucinating, in which case the
directory you're trying to access doesn't exist at all, or you're in
the wrong disk or directory.
Error 205: Object not found
 Oh no! It's that one again! Error 205 is the bane of many a
beginner's existence. In simple terms, it means you have tried to
access a file which the machine cannot find, but in REAL terms it
means a great deal more.
For example, you might get error 205 when clicking on an icon.
This doesn't mean that the program to which the icon is attached has
been erased - it might just mean that the icon or program is trying to
utilise something else. Our coverdisk document icons are a case in
point. They have the default tool type :c/ppmore, which means the icon
directs AmigaDOS to read the file through the program PPMore in the
current disk's C: directory. If you have copied the document to
another disk without the corresponding PPMore program, you're going to
get error 205.
Error 206: Invalid Window Description
 When a CLI or Shell window is opened, the icon tool types
contain information on the size and positioning of the window. If this
is incorrect or inconsistent, error 206 is the result.
Error 209: Packet Request Type Unknown
 More technical than the average boob, error 209 occurs if a
device handler was asked to do something it wasn't designed to do, or
an incoreect code was passed to an Input/Output device such as the
printer.
Error 210: Invalid Stream Component Name
 You have used an invalid character in a file or device name.
Control characters such as the apostrophe must not be used in file
names, and the names must not be longer than 30 characters. Simply
rename your file or device to avoid this error.
Error 211: Invalid Object Lock
 This error is of interest only to programmers, and states that
a lock code was not recognised by the AmigaDOS call. In other words,
if this error pops up, you will already know what it means!
Error 212: Object not of required type
 AmigaDOS recognises several types of object, including
directories, devices, and files. Error 212, another of the more common
errors, warns the user that an AmigaDOS command was issued which
expected to operate on one type of object but which encountered
another.
Error 213: Disk not validated
 Argh! This means your disk is 'unvalidated'. This can come
about for several reasons, but the most common is that two files are
trying to occupy the same part of a disk. The 'bitmap' (a sort of
snapshot of the disk's layout) is therefore confused and invalid.
FixDisk 1.2, which we gave away on our March 1991 cover disk, will
cure most disk validation problems.
Error 214: Disk write protected
 You have tried to write to a disk who's write protection tab
is set to write-protect. Flip the tab to the write-enable setting to
continue.
Error 215: Rename across devices attempted
 The RENAME command will only work as long as you keep the
renamed file in the same device or disk. In other words, if you try to
rename a file from df1:text.doc to df0:text.txt, you will get error
215. You must copy the file to the new device before renaming it.
Error 216: Directory not empty
 When working from CLI or Shell (this doesn't apply to programs
like SID), you cannot delete a drawer until it is completely empty. In
other words, you must go into the directory and type DELETE #?, then
CD out of the directory and delete it.
Error 218: Device not mounted
 If you try, for instance, to CD to a device or disk which has
not been mounted, the Amiga will return error 218. It is relatively
common, and can be very annoying when working with a single floppy
drive. As errors go, this isn't the one to melt your hard drive, but
if it pops up often enogh it could well melt your patience.
Error 219: Seek Failure
 Another one for the programmers to worry about, but which
shouldn't affect the blood pressure of the average owner. It signals
the failure of a low level AmigaDOS function called SEEK, which in
this case would have attempted to SEEK beyond the end of a file.
Error 220: Comment too big
 You have tried to attach a comment (or 'filenote') of more
than the maximum 80 characters to a file.
Error 221: Disk Full
 Probably the most obvious and yet the most infuriating errors
of them all. How many times have you tried to copy a 200k file to
another disk only to find that after 199k, the disk is full and you'll
have to start again?
Error 222: File is protected from deletion
Error 223: File is protected from writing
Error 224: File is protected from reading
 These three errors are easily corrected using the PROTECT
command to reset a file's flags. Every file has a set of 'flags' which
determine whether it can be read from, written to, deleted, and so on.
These flags are important to the way in which a file is allowed to
behave. See page 2-21 of your Software Enhancer Manual for a fuller
description of the PROTECT command.
Error 225: Not a DOS Disk in unit n
 The disk in question is not formatted as an AmigaDOS disk.
Either it has become corrupted, or it was never an AmigaDOS disk in
the first place.
Error 226: No Disk in drive
 Switch you brain on!
Error 232: No more entries in directory
 For programmers only, this error means that a low level
AmigaDOS command tried to continue examining a directory after it had
looked at all its entries.
programming/AMIGA/fastline.dis
+20
View File
@@ -0,0 +1,20 @@
[0 p  -> /\nother Leech From The Fastest Around <-
 ____________________________
 2 Ø Ø Ø A.D SCANDINAVIAN HQ
 : _____ : _____ . _____ : _______ : _ . : _ . _____ : _____ :
 _ _:/ \:/ \:/ \:/ \:/ \:___:/ \:/ \:/ \:_/\_
 \/ V | V___| :V | V | | V: V V V | V | V
 | | |\___ || |___| | | || | | | | :| |___|
 | | | | :|___ |: | | |: | | :| | || ___)
 |: | | | | | || | | | | | || | :| | |
 s|| |___| | | | |: | | | | | :| | | | |s
 c|: ____A___A___A_______A__| |__A_______A___A___A___| | |c
 ~| |~~~~~~~~~~~~~~~~~~~~~~| |~~~~~~~~~~~~~~~~~~~~~~| | |~
 |___| |___| \_____/
 _______________________________________________________________
 AmiX 2.x - 38ØØØBps - Ønline Førever Since 9Ø-12-Ø1 - FastWarez
  A3000 - 25Mhz - 525meg Online - Multi Node - Only 0Ddays...
  $ysop: Fix/2oooAD Co$ysop's: MacroMan/Equinox - Charlie/Amp 
  _____________________________________________
 Node1: +46-418-12702 -+- Node2: +46-418-22533
[1 p
programming/AMIGA/gurus.txt
+78
View File
@@ -0,0 +1,78 @@
Guru Meditations
================
The gurus are divided into two kinds: 1. Software failures
2. System software failures
Ex. 1)
|---------------------------------------------------------|
| Software failure. Press left mouse button to continue. |
| |
| Guru Meditation # 00000003.000027D2 |
-----------------------------------------------------------
| ||
| ||
| \/
Trap numbers <--------------------------- Task control block
-------------
2 = Bus error(hardware)
3 = Adress error(word access on odd byte boundary - frequent!)
4 = Illegal instruction
5 = Divide by zero
6 = CHK instruction
7 = TRAPV instruction
8 = Privelege violation
9 = Trace
A = Opcode 1010 emulation
B = Opcode 1111 emulation
20-2F = TRAP instruction
Ex. 2)
|---------------------------------------------------------|
| Not enough memory. Press left mouse button to continue. |
| |
| Guru Meditation # 02010009.0007D6B8 |
|---------------------------------------------------------|
Here it`s different. The first number is divided into three parts:
A, B, and C. A is the two first bytes, B is the next two
bytes, and finally C is the four last bytes.
A(the part of the system-software affected) B(the general cause)
------------------------------------------- -------------------
1 = Exec library 1 = No memory
2 = Graphics library 2 = Unable to creat lib.
3 = Layers library 3 = - " - open libr.
4 = Intuition library 4 = - " - dev.
5 = Maths library 5 = - " - res.
6 = Clist library 6 = Input/Output error
7 = AmigaDOS library
8 = RAM Handler library
9 = Icons library
10 = Audio device
11 = Console device
12 = Game-port device
13 = Keyboard device
14 = Trackdisk device
15 = Timer device
20 = CIA resource
21 = Disk resource
22 = Misc resource
30 = Bootstrap
31 = Workbench
*
Part C is viewable in the Exec.library-instruction alert. This
allocates more specific where in the system-software-part the
problem is.
The numbers after the dot is the adress in the memory where the
failure appeared.
lib., libr. = library
dev. = device
res. = resource
* = according to THE KICKSTART GUIDE TO THE AMIGA.
programming/AMIGA/hard1200.txt
+350
View File
@@ -0,0 +1,350 @@

Over 210 MeGz of 0-0 days only - ELITE H/P AREA - All IBB releases FREEDL!
==========================================================================
______________ ___/| ________
| / | | / / I.T.A.L.I.A.N. B.A.D. B.O.Y.S
| / | | / ___/
|___ __/ |/ __)__ E.U.R.O. H.E.A.D.Q.U.A.R.T.E.R.
/ |/ _ | / |
/ |\ | | | 'Someone had to be the fastest!'
\____ | \____| |\________ |
\| | | \| -> 3 9 - 4 0 - 3 9 5 2 8 6 <-
Sys0p :DR. G/IBB | |__ _______ ____ ____ ________ ________
| | \ / \/ | |/ // /
CoSyS : | | \/ __ / | / _____// ___/
Alx Sty/Ibb | \ |/ \ | \ \ / __)___
Trade/Scoopex | _ \ / \ | |\__ \\ / |
Seco & Niko/Ministry| | / /\ | \\ |
|____| ___/\_______/Mb\_______| ______/ \_______ |
=========================|/=======================|/================\|====
Over 210 MeGz of 0-0 days only - ELITE H/P AREA - All IBB releases FREEDL!
N.S.I. (No Secret Information) issue 1
24-dec-92
France
The followings informations were gathered by Junkie/PMC Fr and Yragael.
Junkie bought a 1200 some days ago and started quickly to dasm the
copperlist of the workbench. Thanx to his work of prime importance and his
impressive speed which leads me to dasm the copperlist too, I (Yragael)
brings you the followings informations.
More should follow as long as we will not get the hardware reference
manual.
We are waiting for your works on 1200 and your cooperation to the trip into
the hardware of the A1200.
(next issue: Sprite corrections, HAM8+, other graphic modes, 3 words
copperlists ...)
***************************************************************************
USING THE SUPERHIRES MODE
To use the SuperHires mode (1280 pixels wide), just use the bit 6 of
register $0100
bit 6 | Mode SuperHires
-----------------------
0 | Non selectionne
-----------------------
1 | Selectionne
-----------------------
***************************************************************************
USING 8 BITPLANES
The number of bitplanes available used to be no more than 7 and was coded
using the bits 14 to 12 of register $0100. To use 8 bitplanes, just use
bit 4 of register $0100. The value of bits 14 to 12 will then not be
considered anymore.
bit 4 | 8 bitplanes mode
------------------------
0 | Not selected
------------------------
1 | Selected
------------------------
***************************************************************************
ACCEDING 24 BITS COLORS
The 24 bits color is coded using 2 words:
- the first receives the 4 low bits of each R, G and B componants
- the second receives the 4 high bits of each R, G and B componants
To modify a color using 24 bits coding, you must use 2 coppers-moves on the
same color register. The first move must ABSOLUTELY be the move of the
word of the 3*4 high bits, the second move is the move of the word of the
3*4 low bits.
The copper knowns when the move regards the 3*4 low bits or the 3*4 high
bits by checking the bit 9 of register $0106
bit 9 | Componants access
-----------------------------------------------------------------
0 | Access to the 4 low bits of componants R, G and B
-----------------------------------------------------------------
1 | Access to the 4 high bits of componants R, G and B
-----------------------------------------------------------------
ex: change $0180 to $00123456 in the copperlist
$01060000
$01800135
$01060200
$01800246
When you want to work using the 12 bits color coding mode, the 3*4 bits
value you move to the color register is considered by the copper as the 3*4
high bits. You don't have to care about $0106. It seems bit 9 of register
$0106 is initialized to 0 at each copjmp.
***************************************************************************
ACCEDING THE 256 COLORS PALETTE
The amiga don't work with 256 separate color registers. A same color
register is used several times to code several colors.
The amiga just works with 8 differents palettes of 32 colors each, using
color registers from $0180 to $01BE.
You can choose the palette you want to access via the bits 11 to 14 of
register $0106
bit 14 | bit 13 | bit 12 | Selected palette
--------------------------------------------------------
0 | 0 | 0 | Palette 0 (color 0 to 31)
--------------------------------------------------------
0 | 0 | 1 | Palette 1 (color 32 to 63)
--------------------------------------------------------
0 | 1 | 0 | Palette 2 (color 64 to 95)
--------------------------------------------------------
0 | 1 | 1 | Palette 3 (color 96 to 125)
--------------------------------------------------------
1 | 0 | 0 | Palette 4 (color 128 to 159)
--------------------------------------------------------
1 | 0 | 1 | Palette 5 (color 160 to 191)
--------------------------------------------------------
1 | 1 | 0 | Palette 6 (color 192 to 223)
--------------------------------------------------------
1 | 1 | 1 | Palette 7 (color 224 to 255)
--------------------------------------------------------
ex: You want to change color 177 to $00123456
Color 177 is color $01A2 of palette 5
$01065000
$01800246
$01065200
$01800135
***************************************************************************
SWITCHING THE PALETTE
You can switch colors. The definition of switching color A and color B is:
- Color registers of colors A and B are NOT modified by the switching
- Color A is displayed using the content of register of color B and
vice-versa
The switching of palette can't be used on just n colors of the palette.
Once you choose a switching value, ALL the palette's colors will be
switched. The switching value is the value separing the colors to be
switched and is coded with bits 15 to 8 of register $010C.
ex: You want all the colors separated by one color in the colorlist to be
switched
$0180 <--
$0182 <--|--
$0184 <-- |
$0186 <-----
$0188 <--------
. |
.
.
Value 2 will be stocked in bits 15 to 8.
The switching works with the palette as if it was a circular palette. I
mean if if the copper consider color 255 and must switch by 1 the colors,
color $0180 will be assiocated to color 255.
***************************************************************************
USING SPRITES IN LOWRES, HIRES AND SUPERHIRES
To change the reolution of the sprite, just use bit 7 and 6 of register
$0106
bit 7 | bit 6 | Resolution
--------------------------
0 | 0 | Lowres
--------------------------
1 | 0 | Hires
--------------------------
0 | 1 | Lowres
--------------------------
1 | 1 | SuperHires
--------------------------
***************************************************************************
USING 16, 32 AND 64 PIXELS WIDE SPRITES
Well, I still have bug there with sprites in 32 or 64 pixels. Sorry but
the followings informations may have to be corrected.
Use bit 3 and 2 of register $01FC
bit 3 | bit 2 | Wide
-------------------------
0 | 0 | 16 pixels
-------------------------
1 | 0 | 32 pixels
-------------------------
0 | 1 | 32 pixels
-------------------------
1 | 1 | 64 pixels
-------------------------
The copper doesn't read the spritelist in the same way regarding the wide
you choose for your sprite
16 pixels wide reading:
word C1, word C2
word A1, word B1
.
.
.
word An, word Bn
$0000 0000
C1=first control word
C2=second control word
Ai and Bi are combined via OR to form the sprite
32 pixels wide reading:
long C1, long C2
long A1, long B1
.
.
.
long An, long Bn
$0000 0000 0000 00000
C1=first control long
the first control word is the high word of C1. The low word of C1 must
contain the second control word.
C2=second control long
the second control word is the high word of C2. Low word of C2 is $0000
Ai and Bi are combined via OR to form the sprite
64 pixels wide reading:
double C1, double C2
double A1, double B1
.
.
.
double An, double Bn
$0000 0000 0000 00000 0000 0000 0000 00000
C1=first control double
C1=W3:W2:W1:W0 (Wi=words)
W3 is first control word
W2 and W1 are second control word
C2=second control double
C2=W3:W2:W1:W0 (Wi=words)
W3 is second control word
Ai and Bi are combined via OR to form the sprite
***************************************************************************
CHANGING THE SPRITE PALETTE
It is possible to choose the color palette of the sprite. This is done by
the bits 7 and 4 of register $010C.
bit 7 | bit 6 | bit 5 | bit 4 | Starting color of the sprite's palette
-------------------------------------------------------------------------
0 | 0 | 0 | 0 | $0180/palette 0 (coulor 0)
-------------------------------------------------------------------------
0 | 0 | 0 | 1 | $01A0/palette 0 (color 15)
-------------------------------------------------------------------------
0 | 0 | 1 | 0 | $0180/palette 1 (color 31)
-------------------------------------------------------------------------
0 | 0 | 1 | 1 | $01A0/palette 1 (color 47)
-------------------------------------------------------------------------
0 | 1 | 0 | 0 | $0180/palette 2 (color 63)
-------------------------------------------------------------------------
0 | 1 | 0 | 1 | $01A0/palette 2 (color 79)
-------------------------------------------------------------------------
0 | 1 | 1 | 0 | $0180/palette 3 (color 95)
-------------------------------------------------------------------------
0 | 1 | 1 | 1 | $01A0/palette 3 (color 111)
-------------------------------------------------------------------------
1 | 0 | 0 | 0 | $0180/palette 4 (color 127)
-------------------------------------------------------------------------
1 | 0 | 0 | 1 | $01A0/palette 4 (color 143)
-------------------------------------------------------------------------
1 | 0 | 1 | 0 | $0180/palette 5 (color 159)
-------------------------------------------------------------------------
1 | 0 | 1 | 1 | $01A0/palette 5 (color 175)
-------------------------------------------------------------------------
1 | 1 | 0 | 0 | $0180/palette 6 (color 191)
-------------------------------------------------------------------------
1 | 1 | 0 | 1 | $01A0/palette 6 (color 207)
-------------------------------------------------------------------------
1 | 1 | 1 | 0 | $0180/palette 7 (color 223)
-------------------------------------------------------------------------
1 | 1 | 1 | 1 | $01A0/palette 7 (color 239)
-------------------------------------------------------------------------
***************************************************************************
That's all. Thanx you VERY MUCH to Junkie/PMC Fr for his work.
Written by Yragael
_____ _ ___ ___ _____ _____ __ ___ _____ __ _ _ _____ _____
\ __\\|\ | // ___/| __ \ / \/ | __ \ | |/ \ \|/ ___/| __ \
|\/|/ \ \ // _)_ | _/ / / | _|/ \| / / / _)_ | _/ /
| / \_/ // | || \ \_ / /\/| _| \__ \ \ \_/ | || \ \_
| _____/\ / \_____ ||__|\ /MB\ / |/ |___|\ /__|\ /\_____ ||__|\ /
|/=======\/========\|=====\/====\/====:========\/=====\/=======\|=====\/=
- D A R A D S Y S O P ' S A R E ! -
F R E E J A C K - M A L A C H A I - R /\ D /\ R - S U B Z E R O
P R O T O C O L - [- A M O K -] - Z E L N I K
____ __________ _ _
_/\ /\_ ____ | | __________ \_____ \ / \ /o\
|o \ / |/\__|o \| |_/\ / ___ /_____|__ | \ \_// \
|| \ / (____)| \ (____)\\ \ // / / // /
|| \/ |o || |o |/\\ \/__o __/ | \\ / _/
|| \ / || || || | \\ \ || ||: | \| \ /|
|: \ / |: |: \ |: | \\ \|: ||. __|_____/| \/ |
|. |\/|____|. __|. |\___|. __|______ /|. __||__/ | ___|__
|____| |__/ |____| |__/ \__/ |__/ U.S.H.Q.|__/ |
5 Nodes <RING DOWN> 9 0 8 - 6 5 4 - 2 7 0 9 <RING DOWN> 5 Nodes
programming/AMIGA/iff.txt
+207
View File
@@ -0,0 +1,207 @@
Intro to Amiga IFF ILBM Files and Amiga Viewmodes
Downloaded from Magic Tower BBS, +64 4 753 561 (24 hours)
Intro to Amiga IFF ILBM Files and Amiga Viewmodes
=================================================
Carolyn Scheppner - Commodore Amiga Technical Support
The IFF (Interchange File Format) for graphic images on the Amiga
is called FORM ILBM (InterLeaved BitMap). It follows a standard
parsable IFF format.
Sample hex dump of beginning of an ILBM:
========================================
Important note! You can NOT ever depend on any particular ILBM chunk
being at any particular offset into the file! IFF files are composed,
in their simplest form, of chunks within a FORM. Each chunk starts
starts with a 4-letter chunkID, followed by a 32-bit length of the
rest of the chunk. You PARSE IFF files, skipping past unneeded or
unknown chunks by seeking their length (+1 if odd length) to the
next 4-letter chunkID.
0000: 464F524D 00016418 494C424D 424D4844 FORM..d.ILBMBMHD
0010: 00000014 01400190 00000000 06000100 .....@..........
0020: 00000A0B 01400190 43414D47 00000004 .....@..CAMG....
0030: 00000804 434D4150 00000030 001000E0 ....CMAP...0....
0040: E0E00000 20000050 30303050 50500030 .... ..P000PPP.0
0050: 90805040 70707010 60E02060 E06080D0 ..P@ppp.`. `.`..
0060: A0A0A0A0 90E0C0C0 C0D0A0E0 424F4459 ............BODY
0070: 000163AC F8000F80 148A5544 2ABDEFFF ..c.......UD*...
0080: FFBFF800 0F7FF7FC FF04F85A 77AD5DFE ...........Zw.].
etc.
Interpretation:
'F O R M' length 'I L B M''B M H D'<-start of BitMapHeader chunk
0000: 464F524D 00016418 494C424D 424D4844 FORM..d.ILBMBMHD
length WideHigh XorgYorg PlMkCoPd <- Planes Mask Compression Pad
0010: 00000014 01400190 00000000 06000100 .....@..........
TranAspt PagwPagh 'C A M G' length <- start of C-AMiGa View modes chunk
0020: 00000A0B 01400190 43414D47 00000004 .....@..CAMG....
Viewmode 'C M A P' length R g b R <- Viewmode 800=HAM | 4=LACE
0030: 00000804 434D4150 00000030 001000E0 ....CMAP...0....
g b R g b R g b R g b R g b R g <- Rgb's are for reg0 thru regN
0040: E0E00000 20000050 30303050 50500030 .... ..P000PPP.0
b R g b R g b R g b R g b R g b
0050: 90805040 70707010 60E02060 E06080D0 ..P@ppp.`. `.`..
R g b R g b R g b R g b 'B O D Y'
0060: A0A0A0A0 90E0C0C0 C0D0A000 424F4459 ............BODY
length start of body data <- Compacted (Compression=1 above)
0070: 000163AC F8000F80 148A5544 2ABDEFFF ..c.......UD*...
0080: FFBFF800 0F7FF7FC FF04F85A 77AD5DFE ...........Zw.].
etc.
Notes on CAMG Viewmodes: HIRES=0x8000 LACE=0x4 HAM=0x800 HALFBRITE=0x80
------
ILBM is a fairly simple IFF FORM. All you really need to deal with
to extract the image are the following chunks:
(Note - Also watch for AUTH Author chunks and (c) Copyright chunks
and preserve any copyright information if you rewrite the ILBM)
BMHD - info about the size, depth, compaction method
(See interpreted hex dump above)
CAMG - optional Amiga viewmodes chunk
Most HAM and HALFBRITE ILBMs should have this chunk. If no
CAMG chunk is present, and image is 6 planes deep, assume
HAM and you'll probably be right. Some Amiga viewmodes
flags are HIRES=0x8000, LACE=0x4, HAM=0x800, HALFBRITE=0x80.
CMAP - RGB values for color registers 0 to n
(each component left justified in a byte)
BODY - The pixel data, stored in an interleaved fashion as follows:
(each line individually compacted if BMHD Compression = 1)
plane 0 scan line 0
plane 1 scan line 0
plane 2 scan line 0
...
plane n scan line 0
plane 0 scan line 1
plane 1 scan line 1
etc.
Body Compression
================
The BODY contains pixel data for the image. Width, Height, and depth
(Planes) is specified in the BMHD.
If the BMHD Compression byte is 0, then the scan line data is not compressed.
If Compression=1, then each scan line is individually compressed as follows:
More than 2 bytes the same stored as BYTE code value n from -1 to -127
followed by byte to be repeated (-n) + 1 times.
Varied bytes stored as BYTE code n from 0 to 127 followed by n+1 bytes
of data.
The byte code -128 is a NOP.
Interpreting the Scan Line Data:
================================
If the ILBM is not HAM or HALFBRITE, then after parsing and uncompacting
if necessary, you will have N planes of pixel data. Color register
used for each pixel is specified by looking at each pixel thru the planes.
IE - if you have 5 planes, and the bit for a particular pixel is set in
planes 0 and 3:
PLANE 4 3 2 1 0
PIXEL 0 1 0 0 1
then that pixel uses color register binary 01001 = 9
The RGB value for each color register is stored in the CMAP chunk of the
ILBM, starting with register 0, with each register's RGB value stored as
one byte of R, one byte G, and one byte of B, with each component left
justified in the byte. (ie. Amiga R, G, and B components are each stored
in the high nibble of a byte)
BUT - if the picture is HAM or HALFBRITE, it is interpreted differently.
=== =========
Hopefully, if the picture is HAM or HALFBRITE, the package that saved
it properly saved a CAMG chunk (look at a hex dump of your file with
ascii interpretation - you will see the chunks - they all start with
a 4-ascii-char chunk ID). If the picture is 6 planes deep and has no
CAMG chunk, it is probably HAM. If you see a CAMG chunk, the "CAMG" is
followed by the 32-bit chunk length, and then the 32-bit Amiga Viewmode
flags.
HAM pics will have the 0x800 bit set in CAMG chunk ViewModes.
HALBRITE pics will have the 0x80 bit set.
To transport a HAM or HALFBRITE picture to another machine, you must
understand how HAM and HALFBRITE work on the Amiga.
How Amiga HAM mode works:
=========================
Amiga HAM (Hold and Modify) mode lets the Amiga display all 4096 RGB
values. In HAM mode, the bits in the two last planes describe an R G or
B modification to the color of the previous pixel on the line to create
the color of the current pixel. So a 6-plane HAM picture has 4 planes
for specifying absolute color pixels giving up to 16 absolute colors
which would be specified in the ILBM CMAP chunk. The bits in the last
two planes are color modification bits which cause the Amiga, in HAM mode,
to take the RGB value of the previous pixel (Hold and), substitute the 4
bits in planes 0-3 for the previous color's R G or B component (Modify)
and display the result for the current pixel. The color modification bits
in the last two planes are interpreted as follows:
00 - no modification. Use planes 0-3 as normal color register index
10 - hold previous, replacing Blue component with bits from planes 0-3
01 - hold previous, replacing Red component with bits from planes 0-3
11 - hold previous. replacing Green component with bits from planes 0-3
How Amiga HALFBRITE mode works:
===============================
This one is simpler. In HALFBRITE mode, the Amiga interprets the
bit in the last plane as HALFBRITE modification. The bits in the other
planes are treated as normal color register numbers (RGB values for each
color register is specified in the CMAP chunk). If the bit in the last
plane is set (1), then that pixel is displayed at half brightness.
This can provide up to 64 absolute colors.
Other Notes:
============
Amiga ILBMs images must be a even number of bytes wide. Smaller
images (such as brushes) are padded to an even byte width.
ILBMs created with Electronic Arts IBM and Amiga "DPaintII" packages
are compatible (though you may have to use a '.lbm' filename extension
on an IBM). The ILBM graphic files may be transferred between the
machines (or between the Amiga and IBM sides your Amiga if you have
a CBM Bridgeboard card installed) and loaded into either package.
--
==========================================================================
Carolyn Scheppner -- CATS Commodore Amiga Technical Support
PHONE 215-431-9180 UUCP ...{uunet,allegra,rutgers}!cbmvax!carolyn
Oh I'm a numberjack and I'm OK, I code all night and I work all day...
==========================================================================
And downloaded from The Cave BBS (Wellington) for the library of
The Pinnacle Club, Auckland...................................B.
==========================================================================

programming/AMIGA/importan.nfo
+22
View File
@@ -0,0 +1,22 @@
.-----------------------------------------------------------------------.
| ^ AMIGA ^ SNES ^ SEGA ^ HPA/TERROR ^ |
| __/\______/\__ ___/\____ _/\____ _/\____ _/\__ ___ ___ |
| \ ______ / _____ \____ \____ \____/___/ /\ |
| _ __ _\___ \/ / ¬ / / / / / / / /_/_______ |
| / / / / / / / / / / / / / /::::::bIS/\ |
| \___ /___/ /___/ /____ /\___ /\_______ /.::::::::/ / |
| BOOZER \ / \ / \ / \ / \ / \ / . ..:::/ / |
| SNIPER \/ \/ \/ \/ \/ \/ .::/ / |
| FURIOUS ^ /X 3.37 ^ 500 MB! ^ ...:/ / |
| NECRONOMICON _/\____ _/\____ _/\____ _/\_____ ../ / |
| /____ \____ \____ \_______/ NUP:VODKA ./ / |
| _ _ _ ___ ___/ ____/ / / / / __/______________/ / |
| _ __ ___ __ / / / / / / / / /\____________\/ |
| /_____ /___ /___/ /____ / / |
| INSANE SHQ \____\ /\__\ /\___\ /\___\ / / X-TRADE WHQ |
| \/ / \/ / \/ / \/ / |
| \/ \/ \/ \/ |
| ^ NODE #1 ^ +46-8765-14-55 ^ |
`-----------------------------------------------------------------------'
programming/AMIGA/index.gemini
+95
View File
@@ -0,0 +1,95 @@
# AMIGA
Programming and Software information on the Amiga
## FILES
=> gemini://informis.land/textfiles/programming/AMIGA/020_asm.txt [ 33033] Optimizations for the 68020+ by Erik H. Bakke
=> gemini://informis.land/textfiles/programming/AMIGA/881_asm.txt [ 26353] FPU Assembler Programming by Erik H. Bakke (October 13, 1993)
=> gemini://informis.land/textfiles/programming/AMIGA/a5000.txt [ 5001] The First Reports of the A-5000
=> gemini://informis.land/textfiles/programming/AMIGA/acos.txt [ 14553] Computing Texture-Map Coordinates on a Ray Tracer
=> gemini://informis.land/textfiles/programming/AMIGA/adocengl.txt [ 25991] ADoc (Amiga Utility) documentation (1990)
=> gemini://informis.land/textfiles/programming/AMIGA/adsrules.txt [ 22269] Amiga Distribution System Information File (April 6, 1990)
=> gemini://informis.land/textfiles/programming/AMIGA/aflwhq.msb [ 896] TAG File for the MAIN SOURCE BBS
=> gemini://informis.land/textfiles/programming/AMIGA/amiga12 [ 11132] Review of the Commodore Amiga 1200 Computer
=> gemini://informis.land/textfiles/programming/AMIGA/amiga401 [ 24545] Review of the Amirga Computer 4000
=> gemini://informis.land/textfiles/programming/AMIGA/amigabbs.txt [ 534] Tag File for the EDOX BBS
=> gemini://informis.land/textfiles/programming/AMIGA/amigmach.faq [ 12837] The AmigaMACH FAQ (January 1, 1993)
=> gemini://informis.land/textfiles/programming/AMIGA/amirisfa.txt [ 20793] RJ Mical's take on the Amiga Computer's Rise and Fall
=> gemini://informis.land/textfiles/programming/AMIGA/amylives.txt [ 19864] Commodore Lets Amiga Die Slow Death, by Phillip Robinson (San Jose)
=> gemini://informis.land/textfiles/programming/AMIGA/anews3.txt [ 22688] Amiga News III
=> gemini://informis.land/textfiles/programming/AMIGA/antialia.txt [ 6595] What is Anti-Aliasing?
=> gemini://informis.land/textfiles/programming/AMIGA/article [ 28109] Autorouting with the A* Algorithm
=> gemini://informis.land/textfiles/programming/AMIGA/bbs_ads.txt [ 1469] Tag File for the Sarcastic Existence BBS
=> gemini://informis.land/textfiles/programming/AMIGA/dox.nfo [ 1337] Tag File for the Hackers Heaven BBS
=> gemini://informis.land/textfiles/programming/AMIGA/errorcod.txt [ 8822] AmigaDOS Error Codes: An Explanation
=> gemini://informis.land/textfiles/programming/AMIGA/fastline.dis [ 1498] Tag Line for the Pastime BBS
=> gemini://informis.land/textfiles/programming/AMIGA/gurus.txt [ 2300] Figuring Out the Guru Meditations
=> gemini://informis.land/textfiles/programming/AMIGA/hard1200.txt [ 13434] No Secret Information Issue 1 (Decmber 24, 1992)
=> gemini://informis.land/textfiles/programming/AMIGA/iff.txt [ 8891] Intro to Amiga IFF/ILBM Files and Amiga Viewmodes by Carolyn Scheppner, Commodore Amiga Technical Support
=> gemini://informis.land/textfiles/programming/AMIGA/importan.nfo [ 1522] Tag file for the Shadow Gang BBS
=> gemini://informis.land/textfiles/programming/AMIGA/info_doc.txt [ 1718] TAG File for the Outloaws SHQ
=> gemini://informis.land/textfiles/programming/AMIGA/intro.txt [ 23716] Introduction to the Amiga Computer
=> gemini://informis.land/textfiles/programming/AMIGA/lha.tex [ 487] Tag file for the Skidrow HQ
=> gemini://informis.land/textfiles/programming/AMIGA/mainline.dis [ 1305] Tag file for the Sonic Mainline BBS
=> gemini://informis.land/textfiles/programming/AMIGA/mapamiga.txt [ 414988] Mapping the Amiga by Rhett Anderson and Randy Thompson
=> gemini://informis.land/textfiles/programming/AMIGA/noise.txt [ 11777] Noisetracker: An improvement over Soundtracker (August 1989)
=> gemini://informis.land/textfiles/programming/AMIGA/pro.txt [ 58752] Documentation for Protracker v2.2 (1992)
=> gemini://informis.land/textfiles/programming/AMIGA/protrack.ami [ 4510] Protracker 1.0C Module Format
=> gemini://informis.land/textfiles/programming/AMIGA/star.txt [ 14212] Startrekker 1.2 Documentation (November 19, 1990)
=> gemini://informis.land/textfiles/programming/AMIGA/suff_txt.dis [ 1240] Tagfile for Suffocation BBS
=> gemini://informis.land/textfiles/programming/AMIGA/tbrad_tx.dis [ 626] Tag file for The Boiler Room BBS
=> gemini://informis.land/textfiles/programming/AMIGA/techart2.txt [ 3324] Official Warning to ROM-Jumpers, Structure-Hackers and Others
=> gemini://informis.land/textfiles/programming/AMIGA/techart3.txt [ 8065] Attention Game Vendors: Stop Screwing with Disk Hardware
=> gemini://informis.land/textfiles/programming/AMIGA/techart4.txt [ 2815] The Official Way to Reboot an Amiga, by Bryce Nesbitt (1988)
=> gemini://informis.land/textfiles/programming/AMIGA/techart5.txt [ 4726] Disk Drives: What are YOU doing wrong?
=> gemini://informis.land/textfiles/programming/AMIGA/techart6.txt [ 4540] How to Waste Time on an Amiga
=> gemini://informis.land/textfiles/programming/AMIGA/terror.tag [ 1851] Tag file for the BONE BBS
=> gemini://informis.land/textfiles/programming/AMIGA/tslad_tx.dis [ 851] Tag File for the Silents War BBS
=> gemini://informis.land/textfiles/programming/AMIGA/tutorial.txt [ 8444] Some Recommendations for Doing a Game on the Amiga
=> gemini://informis.land/textfiles/programming/AMIGA/undrgnd.tag [ 828] Tag File for the Synchron City BBS
=> gemini://informis.land/textfiles/programming/AMIGA/vectors [ 54066] Vectors: How to Code Vectordemos by Asterix of Movement
programming/AMIGA/info_doc.txt
+25
View File
@@ -0,0 +1,25 @@
.
:
|__ ___ __
_____________________| \_____/ \_________________/ \
\________ __ | __ ________________ \_
.______/ U \/ | \/ __)____/ |/ ___/_____.
|:::::/ _ _ \ : \_ |/ \ | \:::::|
|::: \___/_________/____ ______/_______ \_____A _ _ \__::|
|: / | \___/ __ \______/ \/ _______/ :|
| _____/ | ____________________/ \________________/ \____ .|
|. \__ |___\__________ ________ _________ __/ :|
|:. / | ___/ U \/ |\ \/ |\ \ .:|
|::s/ : \ \ _/ \_ / \s.::|
|::c\_________ \______________/ A________/_________ /c:::|
°-----------\_____/-------\___________/------------------\____/-----°
:::::: ::::::
|:: »»» O U T L A W S S H Q ««« ::|
|: ------------------------------- :|
|: :|
|SYSOPS: VEGAS/OTL, BiSCROK/OTL, PURE PAiN/DCS, CRUGER/SR, NATAS/HZ |
|: SUPPORTING: AMiGA & CONSOLE! :|
|:: CALL AND MAKE SOME TRANSFERS NOW AT: +46-8-540-63666 ::|
|::: CALL TO GET THE LATEST OUTLAWS RELEASES FOR FREEDOWNLOAD! :::|
|:::::::. .:::NO NUP NEEDED!:::. .:::::::|
`-------------------------------------------------------------------'
programming/AMIGA/intro.txt
+489
View File
@@ -0,0 +1,489 @@
CHAPTER 1
INTRODUCTION
The Amiga family of computers consists of several models, each of which
has been designed on the same premise to provide the user with a low cost
computer that features high cost performance. The Amiga does this through
the use of custom silicon hardware that yields advanced graphics and
sound features.
There are three distinct models that make up the Amiga computer family:
the A500, A1000, and A2000. Though the models differ in price and
features, they have a common hardware nucleus that makes them software
compatible with one another. This chapter describes the Amiga's hardware
components and gives a brief overview of its graphics and sound features.
- Introduction 1 -
COMPONENTS OF THE AMIGA
These are the hardware components of the Amiga:
o Motorola MC68000 16/32 bit main processor. The Amiga also supports the
68010, 68020, and 68030 processors as an option.
o 512K bytes of intemal RAM, expandable to 1 MB on the A500 and A2000.
o 256K bytes of ROM containing a real time, multitasking operating system
with sound, graphics, and animation support routines.
o Built-in 3.5 inch double sided disk drive.
o Expansion disk port for connecting up to three additional disk drives,
which may be either 3.5 inch or 5.25 inch, double sided.
o Fully programmable RS-232-C serial port.
o Fully prograrnmable parallel porl.
o Two button opto-mechanical mouse.
o Two reconfigurable controller ports (for mice, joysticks, light pens,
paddles, or custom controllers).
o A professional keyboard with numeric keypad, 10 function keys, and cursor
keys. A variety of international keyboards are also supported.
o Ports for simultaneous composite video, and analog or digital RGB output.
o Ports for left and right stereo audio from four special purpose audio
channels.
o Expansion options that allow you to add RAM, additional disk drives
(floppy or hard), peripherals, or co-processors.
THE MC6X000 AND THE AMIGA CUSTOM CHIPS
Thc Motorola 68000 is a 16/32 bit microprocessor. The system clock speed for
NTSC Amigas is 7.15909 megahertz (PAL 7.09379 MHz). These speeds may vary
when using an extemal system clock, such as from a genlock. The 68000 has
an address space of 16 megabytes. In the Amiga, thc 68000 can address over
8 megabytes of continuous random access memory (RAM).
- 2 Introduction -
In addition to the 68000, the Amiga contains special purpose hardware
known as the "custom chips" that greatly enhance system performance. The
term "custom chips" refers to the 3 intergrated circuits which were
designed specifically for the Amiga computer. These three custom chips
(called Agnus, Paula, and Denise) each contain the logic to handle a
specific set of tasks, such as video, sound, direct memory access (DMA),
or graphics.
Among other functions, the custom chips provide the following:
o Bitplane generated, high resolution graphics capable of supporting both PAL
and NTSC video standards.
- On NTSC systems the Amiga typically produces a 320 by 200 non-interlaced
or 320 by 400 interlaced display in 32 colors and a 640 by 200 non-
interlaced or 640 by 400 interlaced display in 16 colors.
- On PAL systems, thc Amiga typically produces a 320 by 256 non-interlaced
or 320 by 512 interlaced display in 32 colors, and a 640 by 256 non-
interlaced or 640 by 512 interlaced display in 16 colors.
Additional video modes allow for the display of up to 4,096 colors on
screen simultaneously (hold-and-modify) or provide for larger, higher
resolution displays (overscan).
o A custom display co-processor that allows changes to most of the special
purpose registers in synchronization with the position of the video beam.
This allows such special effects as mid-screen changes to the color
palette, splitting the screen into multiple horizontal slices each having
different video resolutions and color depths, beam synchronized interrupt
generation for the 68000 and more. The co-processor can trigger many
times per screen, in the middle of lines, and at the beginning or during
the blanking interval. The co-processor itself can directly affect most
of the registers in the other custom chips, freeing the 68000 for general
computing tasks.
o 32 system color registers, each of which contains a twelve bit number as
four bits of RED, four bits of GREEN, and four bits of BLUE intensity
information. This allows a system color palette of 4,096 different
choices of color for each register.
o Eight reusable 16 bit wide sprites with up to 15 color choices per
sprite pixel (when sprites arc paired). A sprite is an easily movable
graphics object whose display is entirely independent of the background
(called a playfield); sprites can be displayed over or under this
background. A sprite is 16 low resolution pixels wide and an arbitrary
number of lines tall. After producing the last line of a sprite on the
screen, a sprite DMA channel may be used to produce yet another sprite
image elsewhere on screen (with at least one horizontal line between each
reuse of a sprite processor). Thus, many small sprites can be produced by
simply reusing the sprite processors appropriately.
o Dynamically controllable inter-object priority, with collision
detection. This means that the system can dynamically control the video
priority between the sprite objects and the bitplane backgrounds
(playfields). You can control which object or objects appear over or
under the background at any time.
- Introduction 3 -
Additionally, you can use system hardware to detect collisions between
objects and have your program react to such collisions.
o Custom bit blitter used for high speed data movement, adaptable to
bitplane animation. The blitter has been designed to efficiently retrieve
data from up to three sources, combine the data in one of 256 different
possible ways, and optionally store the combined data in a destination
area. This is one of the situations where the 68000 gives up memory
cycles to a DMA channel that can do the job more efficiently (see below).
The bit blitter, in a special mode, draws pattemed lines into
rectangularly organized memory regions at a speed of about 1 million dots
per second; and it can efficiently handle area fill.
o Audio consisting of four digital channels with independently
programmable volume and sampling rate. The audio channels retrieve their
control and data via direct memory access. Once started, each channel can
automatically play a specified waveform without further processor
interaction. Two channels are directed into each of the two stereo audio
outputs. The audio channels may be linked together to provide amplitude or
frequency modulation or both forms of modulation simultaneously.
o DMA controlled floppy disk read and write on a full track basis. This
means that the built-in disk can read over 5600 bytes of data in a single
disk revolution (11 sectors of 512 bytes each).
The interal memory shared by the custom chips and the 68000 CPU is also
called "chip memory". The original custom chips in the Amiga were
designed to be able to physically access up to 512K bytes of shared
memory. The new version of the Agnus custom chip was created which allows
the graphics and audio hardware to access up to a full megabyte of
memory.
The Amiga 500 and 2000 models were designed to be able to accept the new
Agnus custom chip, called "Fat Agnus", due to its square shape. Hence,
the A500 and A2000 have allocated a chip memory space of 1 MB. This
entire 1 MB space is subject to thc arbitration logic that controls the
CPU and custom chip accesses. On the A1000, only the first 512K bytes of
memory space is shared, chip memory.
These custom chips and the 68000 share memory on a fully interleaved
basis. Since the 68000 only needs to access the memory bus during each
altemate clock cycle in order to run full speed, the rest of the time the
memory bus is free for other activities. The custom chips use the memory
bus during thcse free cycles, effectivcly allowing thc 68000 to run at
full rated spced most of the time. We say "most of the time" because
there are some occasions when the special purpose hardware steals memory
cycles from the 68000, but with good reason. Specifically, the
coprocessor and the data moving DMA channel called the blitter can each
steal time from the 68000 for jobs they can do bctter than the 68000.
Thus, the system DMA channels are designed with maximum performance in
mind. The job to be done is performcd by the most efficient hardware
element available. Even when such cycle stealing occurs, it only blocks
the 68000's access to the internal, shared memory. When using ROM or
extemal memory, the 68000 always runs at full speed.
- 4 Introduction -
Another primary feature of the Amiga hardware is the ability to
dynamically control which part of the chip memory is used for the
background display. audio, and sprites. The Amiga is not limited to a
small, specific area of RAM for a frame buffer. Instead, the system
allows display bitplanes, spritc processor control lists, coprocessor
instruction lists, or audio channel control lists to be located anywhere
within chip memory.
This same region of memory can be accessed by the bit blitter. This
means, for example, that the user can store partial images at scattered
areas of chip memory and use these images for animation effects by
rapidly replacing on screen material while saving and restoring
background images. In fact, the Amiga includes firmware support for
display definition and control as well as support for animated objects
embedded within playfields.
VCR AND DIRECT CAMERA INTERFACE
In addition to the connectors for monochrome composite, and analog or
digital RGB monitors, the Amiga can be expanded to include a VCR or
camera interface. This system is capable of synchronizing with an external
video source and replacing the system background color with the extemal
image. This allows development of fully integrated video images with
computer generated graphics. Laser disk input is accepted in the same
manner.
PERIPHERALS
Floppy disk storage is provided by a built in, 3.5 inch floppy disk
drive. Disks are 80 track, double sided, and formatted as 11 sectors per
track, 512 bytes per sector (over 900,000 bytes per disk). The disk
controller can read and write 320/360K IBM PCTM (MS-DOSTM) fommatted 3.5
or 5.25 inch disks, and 640/720K IBM PC (MS-DOS) fommatted 3.5 inch
disks. Extemal 3.5 inch or 5.25 inch disk drives can be added to the
system through the expansion connector. Circuitry for some of the
peripherals resides on Paula. Other chips handle various signals not
specifically assigned to any of the custom chips, including modem
controls, disk status sensing, disk motor and stepping controls, ROM
enable, parallel input/output interface, and keyboard interface.
The Amiga includes a standard RS-232-C serial port for extemal serial
input/output devices.
A keyboard with numeric keypad, cursor controls and 10 function keys is
included in the base system. For maximum flexibility, both key-down and
key-up signals are sent. The Amiga also supports a variety of
intemational keyboards. Many other types of controllers can be attached
through thc two controller ports on the base unit. You can use a mouse,
joystick, keypad, track-ball, light pen, or steering wheel controller in
either of the controller ports.
- Introduction 5 -
SYSTEM EXPANDABILITY AND ADAPTABILITY
New peripheral devices may be easily added to all Amiga models. These
devices are automatically recognized and used by system software through
a well defined, well documented linking procedure called AUTOCONFIG.
On the A500 and A1000 models, peripheral devices can be added to the
Amiga's 86 pin expansion connector, including additional extemal RAM.
Extra disk units may be added from a connector at the rear of the unit.
The A2000 model provides the user with the same features as the A500 or
A1000, but with the added convenicnce of simple and extensive
expandability. The 86 pin, external connector of the A1000 and A500 is
not extemally accessible on the A2000. Instead, the A2000 contains 7
internal slots that allow many types of expansion boards to be quickly
and easily added inside the machine. These expansion boards may contain
coprocessors, RAM expansion, hard disk controllers, video or I/O ports.
There is also room to mount both floppy and hard disks intemally. The
A2000 also supports the special Bridgeboard coprocessor card. This
provides a complete IBM PC on a card and allows the Amiga to run MS-DOS
compatible software, while simultaneously running native Amiga software.
- 6 Introduction -
ABOUT THE EXAMPLES
The examples in this book all demonstrate direct manipulation of the
Amiga hardware. However, as a general rule, it is not permissible to
directly access the hardware in the Amiga unless your software either has
full control of the system, or has arbitrated via the OS for exclusive
access to the panicular parts of the hardware you wish to control.
Almost all of the hardware discussed in this manual, most notably the
Blitter, Copper, playfield, sprite, CIA, trackdisk, and system control
hardware, are in either exclusive or arbitrated use by portions of the
Amiga OS in any running Amiga system. Additional hardware, such as the
audio, parallel, and serial hardware, may be in use by applications which
have allocated their use through the system software.
Before attempting to directly manipulate any part of the hardware in the
Amiga's multitasking environment, your application must first be granted
exclusive access to that hardware by the operating system library,
device, or resource which arbitrates its ownership. The operating system
functions for requesting and receiving control of parts of the Amiga
hardware are varied and are not within the scope of this manual. Generally
such functions, when available, will be found in the library, device, or
resource which manages that portion of the Amiga hardware in the
multitasking environment. The following list will help you to find the
appropriate operating system functions or mechanisms which may exist for
arbitrated access to the hardware discussed in this manual.
Copper, Playfield, Sprite, Blitter - graphics.library
Audio - audio.device
Trackdisk - trackdisk.device, disk.resource
Serial - serial.device, misc.resource
Parallel - parallel.device, cia.resource, misc.resource
Gameport - input.device, gameport.device, potgo.resource
Keyboard - input.device, keyboard.device
System Control - graphics.library, exec.library (interrupts)
Most of the examples in this book use the hw examples.i file (see
Appendix J) to define the chip register names. Hw_examples.i uses the
system include file hardware/custom.i to define the chip structures and
relative addresses. The values defined in hardware/custom.i and how
examples.i are offsets from the base chip register address space. In
general, this base value is defined as _custom and is resolved during
linking from amiga.lib. (_ciaa and _ciab are also resolved in this way.)
Normally, the base address is loaded into an address register and the
offsets given by hardware/custom.i and hw_examples.i are then used to
address the correct register.
- Introduction 7 -
NOTE
The offset values of the registers are the addresses that the Copper must
use to talk to the registers.
for example, in assembler:
INCLUDE "exec/types.i"
INCLUDE "hardware/custom.i"
XREF custom ; External reference
Start: lea _custom,a0 ; Use a0 as base register
move.w #$7FFF,intena(a0) ; Disable all interupts
In C, you would use the structure definitions in hardware/custom.h For
example:
#lnclude "exec/types.h"
#include "hardware/custom.h"
extern struct Custom custom;
/* You may need to define the above external as
** extern struct Custom far custom;
** Check you compiler manual.
*/
main()
{
custom.intena = 0x7FFF; /* Disable all interupts */
}
The Amiga hardware include files are generally supplicd with your
compiler or assembler. Listings of lhc hardware include files may also be
found in the Addison-Wesley Amiga ROM Kemel Manual "Includes and
Autodocs". Generally, the include file label names are very similar to
the equivalent hardware register list names with the following typical
differences.
o Address registers which have low word and high word components are
generally listed as two word sized registers in the hardware register
list, with each register name containing either a suffix or embedded "L"
or "H" for low and high. The include file label for the same register
will generally treat the whole register as a longword (32 bit) register,
and therefore will not contain the "L" or "H" distinction.
o Related sequential registers which are given individual names with
number suffixes in the hardware register list, are generally referenced
from a single base register definition in the include files. For example,
the color registers in the hardware list (COLOR00, COLOR01, etc.) would
be referenced from the "color" label defined in "hardware/custom.i"
(color+0, color+2, etc.).
o Examples of how to define the correct register offset can be found in
the hw_examples.i file listed in Appendix J.
- 8 Introduction -
SOME CAVEATS TO HARDWARE LEVEL PROGRAMMERS
The Amiga is available in a variety of models and configurations, and is
further diversified by a wealth of add-on expansion peripherals and
processor replacements. In addition, even standard Amiga hardware such as
the keyboard and floppy disks, are supplied by a number of different
manufacturers and may vary subtly in both their timing and in their
ability to perform outside of their specified capabilities.
The Amiga operating system is designed to operate the Amiga hardware
within spec, adapt to different hardware and RAM configurations, and
generally provide upward compatibility with any future hardware upgrades
or "add ons" envisioned by the designers. For maximum upward
compatibility, it is strongly suggested that programmers deal with the
hardware through the commands and functions provided by the Amiga
operating system.
If you find it necessary to program the hardware directly, then it is
your responsibility to write code which will work properly on various
models and configurations. Be sure to properly request and gain control
of the hardware you are manipulating, and be especially careful in the
following areas:
Do not jump into ROM. Beware of any example code that calls routines in
the $F80000 to $FFFFFF range. These are ROM addresses and the ROM
routines WILL move with every OS revision. The only supported interface
to system ROM code is through the provided library, device, and resource
calls.
Do not modify or depend on the format of any private system structures.
This includes the poking of copper lists, memory lists, and library
bases.
Do not depend on any address containing any particular system structure
or type of memory. The system modules dynamically allocate their memory
space when they are initialized. The addresses of system structures and
buffers differ with every OS, every model, and every configuration, as
does the amount of free memory and system stack usage. Remember that all
data for direct custom chip access must be in CHIP RAM. This includes bit
images (bitplanes, sprites, etc), sound samples, trackdisk buffers, and
copper lists.
Do not write spurious data to, or interpret undefined data from currently
unused bits or addresses in the custom chip space. All undefined bits
must be set to zero for writes, and ignored on reads.
Do not write data past the current end of custom chip space. Custom chips
may be extended or enhaneed to provide additional registers, or to use
currently undefined bits in existing registers.
All custom chip registers are read only OR write only. Do not read write
only registers, and do not write to read only registers.
- Introduction 9 -
Do not read, write, or use any currently undefined address ranges. The
current and future usage of such areas is reserved by Commodore and is
definitely subject to change.
If you are using the system libraries, devices, and resources, you must
follow the defined interface. Assembler programmers (and compiler
writers) must enter functions through the liberary base jump tables, with
arguments passed as longs and library base address in A6. Results returned
in D0 must be tested, and the contents of D0-D1/A0-A1 must be assumed
gone after a system call.
NOTE
The assembler TAS instruction should not be used in any Amiga program.
The TAS instruction assumes an indivisible read-modify-write but this can
be defeated by system DMA. Instead use BSET and BCLR. These instructions
perform a test and set operation which cannot be interrupted.
TAS is only needed for a multiple CPU system. On a single CPU system,
the BSET and BCLR instructions are identical to TAS, as the 68000 does
not interrupt instructions in the middle. BSET and BCLR first test, then
set bits.
Do not use assembler instructions which are privileged on any 68000
family processor, most notably MOVE SR,<ea> which is privileged on the
68010/20/30. Use the Exec function GetCC() instead of MOVE SR, or use the
appropriate non-privileged instruction as shown below:
CPU User Mode Super Mode
68000 MOVE SR,<ea> MOVE SR,<ea>
68010/20/30 MOVE CCR,<ea> MOVE SR,<ea>
All addresses must be 32 bits. Do not use the upper 8 bits for other
data, and do not use signed variables or signed math for addresses. Do
not execute code on your stack or use self-modifying code since such code
can be defeated by the caching capabilities of some 68xxx processors. And
never use processor or clock speed dependent software loops for timing
delays. See Appendix F for information on using an 8520 timer for delays.
NOTE
When strobing any register which responds to either a read or a write,
(for example copjmp2) be sure to use a MOVE.W #$00, not CLR.W. The CLR
instruction causes a read and a clear (two accesses) on a 68000, but only
a single access on 68020 and above. This will give different results on
different processors.
If you are programming at the hardware level, you must follow hardware
interfacing specifications. All hardware is NOT the same. Do not assume
that low level hacks for speed or copy protection will work on all
drives, or all keyboards, or all systems, or future systems. Test your
software on many different systems, with different processors, OS,
hardware, and RAM configurations.
- 10 Introduction -
See FIGURE 1-1: Block Diagram for the Amiga Computer Family.
- 11 Introduction -
End.
programming/AMIGA/lha.tex
+16
View File
@@ -0,0 +1,16 @@
SKIDROW HQ KINGDOM WHQ
***************************************************
Welcome to the Darkest spot on Earth
***************************************************
THIS is our WORLD
**********************
** T H E H O L E **
**********************
5 NODES AMI/X 3.XX
SYSOP'S:
OLDMAN/SR, HIGHLANDER/GOD
DATA-STREAM/SR, ZANDOR/SR
We are selling a few leech accounts
programming/AMIGA/mainline.dis
+23
View File
@@ -0,0 +1,23 @@
----------------------------------------------------------------------------
______ ___________ ___________ ____ __________
/ ___/ Omar / _ )/ _ )/ )/ _ )
/ (_______ / / ) // / ) // // / )___/
(_____ )/ / / // / / // // /
_____ ) // / / // / / // // / ____
/ / / // / / // / / // // / / )
/ (_/ // (_/ // / / // // (_/ /
(___________/(___________/(____/ (____/(____/(___________/
USR HST - 0-1 day warez
213Mb Fun - 9Mb RAM - Offline Checking
__ __ ______ __ _______ __ __ _______ _______
____ / /\// / /_/ / // // / / // / / // / / // / / /
- - ---- / / / /_____/ // // / / // / / // / / // /__/_/
_ ___ / / / // / / // // / / // / __ / // / / // / __
- ---- /_/ /_//_/__/_//_//_/ /_//_/__/_//_//_/ /_//_/__/_/
SysOp: Dux & Co-SysOps: Omar/Sonic, Ozzy/2ooo A.D.
___ ___ ___ _ ___ ___ ___ ___ ___
(___/(___ _ (___)(___)/ | _ (___ __)( _ )(___ ___)
/ ____) ____)(___) | ____)___)(___)(___)(____
programming/AMIGA/mapamiga.txt
+9761
View File
File diff suppressed because it is too large Load Diff
programming/AMIGA/noise.txt
+274
View File
@@ -0,0 +1,274 @@
----------------------------------------------------------------------------
- NoiseTracker V1.1 - An improved version of MnemoTroN's Soundtracker V2.3 -
- Made by Mahoney & Kaktus - Northstar & Silents in July - August 1989 -
----------------------------------------------------------------------------
- This tracker is non-polluting -
Text by Mahoney ...
Since I'm so tired of the old ST-instructions, I'll just short take my part
of the improvements here. If you're not into how to use the Soundtracker, read
the old V2.3 instructions, or call your nearest friend. (that's what friends
are for!) This tracker was made to fit our purposes, if you don't like it,
that's not our problem.
Here's a short list of what I've done ... (V1.0)
* Removed the Format Disk-option (It wasn't reliable)
* Inserted Load Sample-function (good if haven't done a PLST!)
* Corrected the replayroutine (now works with all instruments)
* An IFF-handler routine (should take damaged IFFs, too)
* Improved inputhandler.
* Reinserted song-pack on/off (I used it in the Sounds of Gnome)
* Possibility to change the Module-directory.
* Change instrument with the numeric-pad.
* Play/Patt/Stop/Edit/Rec from the keyboard.
* Simple transpose-function.
* Two new song-commands (tone-portamento & vibrato)
* Great PLST-screen with simple searchroutine.
* Now you can change PLST in the tracker.
* Change Pattern & Position from the keyboard.
* Sounds looped just like in Audiomaster & Sound FX.
* Modulelength & free chipmem displayed.
* All known bugs corrected.
NoiseTrackerV1.1 improvements:
* Safer loadingroutines.
* Restart pointer for your song.
* Removed Use Pset. (use the PLST-screen instead)
* Debugged IFF-handler.
* Safer memoryhandler.
-----------------------------------------
- The keyboard. -
-----------------------------------------
Esc - Exits DiskOp & PLST
F1 - Chooses low octaves
F2 - Chooses high octave
shift + F3 - Cut voice to buffer
shift + F4 - Copy voice to buffer
shift + F5 - Paste voice from buffer
alt + F3 - Cut whole pattern to buffer
alt + F4 - Copy whole pattern to buffer
alt + F5 - Paste pattern from buffer
F6 - Go to patternposition 0
F7 - Go to patternposition 16
F8 - Go to patternposition 32
F9 - Go to patternposition 48
F10 - Go to patternposition 63
Help - Go/exit PLST
Space - Toggle between Stop/Edit-mode
right Amiga - Play Pattern
right Alt - Play Song
right Shift - Record
alt + cursor right - increase pattern-number
alt + cursor left - decrease pattern-number
shift + cursor right - increase song-position
shift + cursor left - decrease song-position
shift + Tab - Transpose selected instrument in voice one halfnote up.
shift + Ctrl - Transpose selected instrument in voice one halfnote down.
alt + Tab - Transpose selected instrument in pattern one halfnote up.
alt + Ctrl - Transpose selected instrument in pattern one halfnote down.
Caps Lock - ????????? (Haha!)
* Numeric pad:
0 - Select instrument $0
upper row - Select instrument $1-$4
2nd row - Select instrument $5-$8
3rd row - Select instrument $9-$c
4th row - Select instrument $d-$10
Enter (still on the numeric) + the other keys selects instruments $10-$1f
-----------------------------------------
- Restart-pointer. -
-----------------------------------------
This is the position where the song will restart when the tune is finished.
As simple as that ...
-----------------------------------------
- New inputroutine. -
-----------------------------------------
This routine should work just like any normal text-processor, and not, like
before, clear the whole row and let you retype it again to edit.
You can use the cursor left/right, backspace and delete. By pressing the
right button, you'll clear the row.
-----------------------------------------
- Corrected Loop-values. -
-----------------------------------------
All since the very first Soundtracker by K.O. there has been a bug in the
replay-routine. (both in the tracker and the replay) The tracker calculated
the loop-start in bytes, and not in words as it's written into the instrument-
list. All this means that in the later Soundtrackers, you couldn't loop the
whole sample. To use your old loop-values (from ANY other tracker) you should
divide your Repeat-value by 2. (fex. $07e0/2 = $03f0) If you want to save
memory, decrease the length of your looped sample until it stops. This will
save only the used part of the sample in the module.
-----------------------------------------
- PLST-screen. -
-----------------------------------------
You enter this screen either by pressing the PLST-button, or by pressing the
Help-key. Here you've got the number of samples currently in the preset-list,
a load PLST-button, an exit-button, three search-disks and a mountlist-button.
By pressing the mount-button, you'll get a preset-list with only those disk(s)
mounted. You can also type the disknumber yourself. Then, simply press your
sample to load it into the current instrument.
-----------------------------------------
- Disk Operation. -
-----------------------------------------
Here you've got the old familiar Load/Save/Del song and module + Save sample.
The new is the Load sample-option, the reinserted Pack on/off and the module-
directory. To change the moduledir, just press it and type the new dir. Be
sure to have either a : after a diskname, or a / after a directory, fex DF0:
Only modules with the prefix 'mod.' can be loaded, to prevent you from trying
to load something else that isn't a module. Do also note that you can't edit
anything while in DiskOp. Do NOT have two ST-00 in your drives simultaneous,
because that will confuse your computer.
-----------------------------------------
- Song-commands. -
-----------------------------------------
Here you've got them:
0 - arpeggio
1 - portamento up
2 - portamento down
3 - Tone-portamento
4 - Vibrato
A - Slide volume
B - Position jump
C - Set volume
D - Pattern break
E - Set filter (keep the led off, please!)
F - Set speed (now up to $1F)
$0 Arpeggio - $0 + second halfnote-add + third halfnote-add
This command will produce a one-channel chord. No comments.
C-3 00037 produces a minor-chord
C-3 00047 produces a major-chord
$1 Portamento up - $1 + portamentospeed
This commans slides the pitch up.
C-3 00103 1 is the command, 3 is the speed.
$2 Portamento down - $2 + portamentospeed
This command slides the pitch down.
C-3 00203 2 is the command, 3 is the speed.
$3 Tone-portamento - destination-note + $3 + speed
This will automatically slide from the old note to the new. To keep on
sliding, just select the command 3. Try it out yourself, and I'm
sure you'll understand a little bit better.
C-3 00305 C-3 is the note to slide to, 3 the command and 5 the speed.
$4 Vibrato - $4 + vibratospeed + vibratosize
C-3 00481 4 is the command, 8 is the speed of the vibrato and 1 is the
size of the vibrato.
To keep on vibratoing (?) just select the command 4.
$A Volume-slide - $A + upslidespeed + downslidespeed
C-3 00A05 5 is the speed to turn down the volume
C-3 00A40 4 is the speed to slide it up.
$B Position-jump - $B + song-position to continue at
C-3 00B01 1 is the place to restart the song at.
This command will also perform a pattern-break.
$C Set volume - $C + new volume
Well, this old familiar command will set the current volume to your
own selected. The highest volume is $40. All volumes are represented
in hex. (Programmers do it in hex, you know!)
C-3 00C10 C is the command, 10 is the volume.
$D Pattern-break - $D + nothing
Sure simple, this magic thing will end your pattern and go on with the
next one.
C-3 00D00 D in the command, all others are a waste of memory.
$E Set filter - $E + filter-status
This command jerks around with the sound-filter on some A500 + A2000.
All other Amiga-users should keep out of playing around with it.
C-3 00E01 disconnects filter (turns LED off)
C-3 00E00 connects filter (turns LED on) * please keep LED off!
$F Set speed - $F + speed
This will change the speed of your tune. (how fast your patterns will
roll ...) Speeds from $01 - $1f are allowed.
C-3 00F07 sets speed to 7
-----------------------------------------
- Replay-source. -
-----------------------------------------
On this disk you should find a file called "NoiseReplay.s". That is just
as you suspected, a little neat source to play your home-made tunes. Simply
read it into your favorite Seka, read your module to the label "mt_data",
call the sub-routine "mt_init" first and then to "mt_music" every frame.
When you exit your demo, call the routine "mt_end" to stop the sound.
This replay-routine is not interrupt-driven. If you want such a replay, you
better do it yourself. (if you're not a programmer, bad luck!)
Use only the right replay to the right NoiseTracker. ReplayV1.1 will not work
properly with tunes saved with V1.0, and ReplayV1.0 won't go with TrackerV1.1.
Tunes can only be converted from V1.0 to V1.1 and not back again. This should
not cause any bigger problems, I hope.
-----------------------------------------
- Comments. -
-----------------------------------------
This tracker took about four weeks to complete. And the improvements from V1.0
to V1.1 took exactly 4 hours. We really hope you like it. Anyway, the best
thank you can give us is by using our tracker. If you have something VERY
importany to tell us, write to a swapper in NorthStar and beg for our adress.
Otherwise, get our musicdisk II, Sounds of Gnome, and you'll find it there.
Note that we do not swap anything (not even our own productions). We don't
want to spend all our money on stamps. If you want some of our latest things,
swap with NorthStar and NOT with us. WE ARE LEGAL!!!! Fuck the police who
keeps on checking our mail, just because we were on Fairlights memberlist and
they happened to get that when they infiltrated an illegal Visa-card user.
Special thanks to Glue Master, Zymox, Foetus, Jazze, Godbrain, Spexhane,
Starfire, Exolon, Celebrandbil, Ron & Sal/MegaKlopparna, Jessi, Jenny S.
and all those guys who made the Soundtracker before me.
Thanks also to all these nice guys ... Panther/Scoopex, DMX/Phoenix,
Slimer/Celtic, The Unicorn/Unit one inc., Wizzkid/Electr.Artists,
Philip Weyman, Billy Topping, Ray Burt-Frost, Watchman/Deathstar,
George "M" Ruivo, Scampy/FAT, Christoph/Flashlight, Anders G.P.,
Nova/Paragon, Fredox/Overgrowth, Spy 3/DMACON, Sir Gawain & Gaston/Horizon,
Scorpion/Phantoms, Vortex 42, Alastor, S.O.S., AlphaFlight, Mute 101, Jimmy,
Rawhead and finally to all our friends in NorthStar & Silents.
Sorry if we missed you ...
Any problems? Call Germany 110.
Signed - Mahoney & Kaktus/HallonSoft 1989 Have a nice night!
PS. Please don't ask me why I kept the disk-status in the middle of the
screen. It's always nice to see that everything is all-right, isn't it ???
programming/AMIGA/pro.txt
BIN
View File
Binary file not shown.
programming/AMIGA/protrack.ami
+120
View File
@@ -0,0 +1,120 @@
Have you ever wondered how a Protracker 1.0C module is built up?
Well, here's the...
Protracker 1.0C Song/Module Format:
-----------------------------------
Offset Bytes Description
------ ----- -----------
0 20 Songname. Remember to put trailing null bytes at the end...
Information for sample 1-31:
Offset Bytes Description
------ ----- -----------
20 22 Samplename for sample 1. Pad with null bytes.
42 2 Samplelength for sample 1. Stored as number of words.
Multiply by two to get real sample length in bytes.
44 1 Lower four bits are the finetune value, stored as a signed
four bit number. The upper four bits are not used, and
should be set to zero.
Value: Finetune:
0 0
1 +1
2 +2
3 +3
4 +4
5 +5
6 +6
7 +7
8 -8
9 -7
A -6
B -5
C -4
D -3
E -2
F -1
45 1 Volume for sample 1. Range is $00-$40, or 0-64 decimal.
46 2 Repeat point for sample 1. Stored as number of words offset
from start of sample. Multiply by two to get offset in bytes.
48 2 Repeat Length for sample 1. Stored as number of words in
loop. Multiply by two to get replen in bytes.
Information for the next 30 samples starts here. It's just like the info for
sample 1.
Offset Bytes Description
------ ----- -----------
50 30 Sample 2...
80 30 Sample 3...
.
.
.
890 30 Sample 30...
920 30 Sample 31...
Offset Bytes Description
------ ----- -----------
950 1 Songlength. Range is 1-128.
951 1 Well... this little byte here is set to 127, so that old
trackers will search through all patterns when loading.
Noisetracker uses this byte for restart, but we don't.
952 128 Song positions 0-127. Each hold a number from 0-63 that
tells the tracker what pattern to play at that position.
1080 4 The four letters "M.K." - This is something Mahoney & Kaktus
inserted when they increased the number of samples from
15 to 31. If it's not there, the module/song uses 15 samples
or the text has been removed to make the module harder to
rip. Startrekker puts "FLT4" or "FLT8" there instead.
Offset Bytes Description
------ ----- -----------
1084 1024 Data for pattern 00.
.
.
.
xxxx Number of patterns stored is equal to the highest patternnumber
in the song position table (at offset 952-1079).
Each note is stored as 4 bytes, and all four notes at each position in
the pattern are stored after each other.
00 - chan1 chan2 chan3 chan4
01 - chan1 chan2 chan3 chan4
02 - chan1 chan2 chan3 chan4
etc.
Info for each note:
_____byte 1_____ byte2_ _____byte 3_____ byte4_
/ \ / \ / \ / \
0000 0000-00000000 0000 0000-00000000
Upper four 12 bits for Lower four Effect command.
bits of sam- note period. bits of sam-
ple number. ple number.
Periodtable for Tuning 0, Normal
C-1 to B-1 : 856,808,762,720,678,640,604,570,538,508,480,453
C-2 to B-2 : 428,404,381,360,339,320,302,285,269,254,240,226
C-3 to B-3 : 214,202,190,180,170,160,151,143,135,127,120,113
To determine what note to show, scan through the table until you find
the same period as the one stored in byte 1-2. Use the index to look
up in a notenames table.
This is the data stored in a normal song. A packed song starts with the
four letters "PACK", but i don't know how the song is packed: You can
get the source code for the cruncher/decruncher from us if you need it.
In a module, all the samples are stored right after the patterndata.
To determine where a sample starts and stops, you use the sampleinfo
structures in the beginning of the file (from offset 20). Take a look
at the mt_init routine in the playroutine, and you'll see just how it
is done.
Lars "ZAP" Hamre/Amiga Freelancers
programming/AMIGA/star.txt
+364
View File
@@ -0,0 +1,364 @@
+---------------------------------------------------------------+
| STARTREKKER 1.2 |
+---------------------------------------------------------------+
CODED BY EXOLON OF FAIRLIGHT
RELEASE DATE: 19/11-1990
Now your own local Exolon has been up all night coding on the StarTrekker
just for you... But the result was worth the pain, because...
The main theme for this release is SYNTHETIC SOUNDS.... Read..
------------------------New features in 1.2--------------------------
1. Now prints patterns while playing in 8 channel mode.
2. An FM-Synthesizer is included to make samples for you. You can make
any sound from organs to whips, chains and drums :-) See special doc
below.
3. An AM-Synthesizer is included to make realtime sounds for you. A bit more
limited than the FM, this makes sounds similar to the Future Composer..
Doc below...
3. Diskop screen squeezed into halfheight... So you can diskop while
pressing play and stop...
4. Channel On/Off gadgets in 8 channel mode.
5. You can now click on the spectrum analyzer and it turns into two COOL
oscillioscope pictures... Click again and the analyzer comes back. The
left scopes displays voices 1 and 4 (the left channels) and the right
scope displays voices 2 and 3 (the right channels).
6. Play routine sources included on this disk:
NORMALREPLAY.S - normal replay routine without "AM" sounds
AMREPLAY.S - replay routine for both normal and "AM" sounds
8CHANNELREPLAY.S - replay routine for 8 channel modules
7. Maybe it's a little more bugfree now... Try it!
--------*> FM SYNTHESIZER <*--------
Welcome to the FM Synthesizer!
First of all I would like to send some great thanks to my friend GLUEMASTER
for exploring this topic. He got inspired of the Yamaha DX FM synth and
decided to write his own on the amiga. He did, and now I have made one too!
And included it into the StarTrekker 1.2!!
It works like this:
After you have pressed RESET,
you have four sinus-waves under your control. You can't change the waveform,
but you can change the envelope and base-frequency for each sinus-wave. Then
you can choose for each to listen to it, modulate the next's frequency or
both... The program then calculates a sample of your selected length, and
you are free to use this sample to whatever you want (including playing
it!). You can also choose just to save the parameters (120 bytes) to disk.
You have some examples in the FMSOUNDS drawer on this disk. Load,
press calc, play, and learn...
Some hints:
Try to only listen to ONE sinuswave (number 4 f.x), then put a small
envelope on sinuswave 3 and press F.MOD on wave 4. Now wave 4's frequency
will be modulated according to the output of wave 3. Then you alter the
envelope and frequency of wave 3 till it sounds great, then press F.MOD on
wave 3 and make a envelope on wave 2, adjust and continue with wave 1. NOW,
if you press F.MOD on wave 1 also, it will be modulated by wave 4, and the
modulation will be fed back to the beginning, causing some kind of noise
suitable for drums etc..
The FM-Synth controls:
In the middle of the screen there's a rectangle containing the selected
wave's (the 1-4 buttons) envelope. It always display the envelope from the
start till the release ends, even if the total time is just a fraction of
the whole sample. Above the envelope is a black line. This line shows how
much time the envelope shows, with respect to the total sample time.
Buttons 1-4 let you select which wave to edit.
The TOT number is the total time for the envelope (discussed above), if you
want the envelope to be the same lenght as the sample, the black line above
the envelope should be as long as the rectangle. HOWEVER if the total time
is longer, the line's still only as long as the rectangle, so to be sure
decrease the TOT until the line begins to shorten, the increase to the
rectangles end..
The LENGTH number is the number of bytes the output sample should have.
The FREE button clears the FM parameters but the sample's still intact.
The RESET button loads the current FM parameters with the default sound.
The LOAD and SAVE let you load and save the parameters as a disk file
of the length 120 bytes.
The CALC button calculates a sample according to the current parameter
settings. The small dot appearing up in the right hand corner of the calc
button signals that you have changed the parameters since you CALCed last.
The FMOD button tells wether the current wave should be frequency modulated
by the preceding wave.
The LISTEN button tells if the output sample should contain this wave's
output or not. To get a sound at all, at least ONE wave should have this
button highlighted.
Now for the real parameters... From up to down:
FQ This waves base frequency. $1 is very low, $4 is average and $20 is
quite high.
L0 Start amplitude for the envelope
A1L Attack level
A1S The speed that the amplitude changes to the attack level, $1 is slow
and $40 is fast.
A2L Secondary attack level, for those who likes envelopes...
A2S Secondary attack speed.
DS The speed that the amplitude decays down to the:
SL Sustain level. There is remains for the time set by the
ST Sustain time.
RS Release speed. The speed that the amplitude falls from ST to 0.
Any change of either of the envelope parameters will cause a redraw of the
envelope curve. It's very easy to see what does what with the graphic
representation.
DO NOT set any speed to 0, unless you want the amplitude to remain at the
last value.
To roll values faster, press the right mouse button also.
When you press SAVE MODULE a requester pops up asking whether to save the
by FM synthesis calculated samples. Normally you press NO to save diskspace,
the FM sounds are automatically recalculated when you reload the module.
However, to use the module in the replayroutines, you have to press YES
because the replaysource doesn't contain a FM generator. (Guess why...)
I realize that the FM-Synth can be quite hard to understand, there has been
a lot of talking about FM-sounds and calculation here and there, but load
the examples in the FMSOUNDS directory and try to change some parameters,
important, DON'T FORGET THAT YOU HAVE TO PRESS CALC before you can play with
your sound...
------------> AM SYNTHESIZER <------------
Welcome to the AM synthesizer. Unlike the FM synth this doesn't create a
sample. It has it's own internal 32 byte long samples, and changes the
volume and period of the sound 50 times a second. So, it operates similar
to all the other synthetic sound programs out there like Sidmon, Future
Composer etc. Here you therefore doesn't have to press a CALC button all the
time, just change a parameter and play the keyboard.
CONTROLS:
In the box you have the envelope shape. You can edit the envelope in
exactly the same way as in the FM synth, so please look above for that.
Below the box there's four waveform gadgets to select the waveform. There's
a sinus, a sawtooth, a pulse and a noise waveform.
To the left, you can edit the vibrato amplitude and speed as well as the
pitch fall.
The FQ value is the octave. 0 is the highest and 5 is the lowest.
Again, the best way to learn is to load the examples in the AMSOUNDS drawer.
The FREE button clears the AM parameters.
The RESET button loads the parameters with the default settings.
The LOAD and SAVE buttons speak for themselves, don't they?
---------------------------------
Greetinx goes to:
F/X-lab, Lord CMP, Octo, Olwon, Freddy "FISKEN", Alex "PADDEL",
Toffelhero, Peter Bo X-tra Long John Silver Skold Frankenstein,
and to all others who has helped me with suggestions about the 1.2...
Well that was all for this time, hope to see you soon in further
more advanced versions of the only state of the art music-program:
THE STARTREKKER!
Signed EXOLON OF FAIRLIGHT!
As always, suggestions are welcome at this address (NO SWAPPING!)
Bjorn Wesen
Roslins v.20A
S-217 55 Malmoe
SWEDEN
Or contact me at FAIRLIGHT EUROPEAN HEADQUARTERS:
MAXIMUM OVERDRIVE +46/44247539
Or mail me on the Amiga Echo area on FIDONET to 'Bjoern Wesen'.
------------------------------1.1 doc--------------------------------
1. Opens an own intuition screen so mouseclicks won't fall through to the
underlying workbench and cause trouble.
2. MULTITASKS correctly... Just press the screen to back gadget on the
ST screen and it will lie quiet in the background Wait()ing... When you
want to return to the st, just select the st window on the st screen by
pressing the workbench depth gadgets.
3. KEYBOARD ROUTINE REWRITTEN! Using an IDCMP port connected to the st
window... The ST now works on any configuration without using the -h
option. So now you can choose your own key repeat speed in Preferences.
NOTE: Key repeat will be disabled when not in Edit mode. Otherwise it
wouldn't sound very good if you just play with the keys, hold one down
and it goes R...rrrrrrrrrrrrrr.....
If you have the polyphonic mode on (see the old docs below) you can now
press many keys at the same time and play CHORDS... Great eh?
4. 8 CHANNEL EDITOR! Now the editor is in MED-RES in 8 channel mode so you
can edit all 8 channels at the same time... When in polyphonic mode,
choose voice 1-4 with LEFT ALT + F6-F9 and choose voice 5-8 with LEFT ALT +
LEFT SHIFT + F6-F9.
5. INSERT/DELETE note in the editor. In edit mode, press return and the
notes below in the column will go down one step.. Just as in an ordinary
text editor. Also, by pressing Backspace you will delete the note the
cursor's on and the notes below will be moved up one step.
6. FREEMEM now prints with 6 chars... So those of you with 2 meg chip can
see all..
7. COMMANDS implemented in 8 channel mode:
$1 <amount> Frequency up
$2 <amount> Frequency down
$4 <speed><amplitude> Vibrato
$A <up><down> Volume slide
$C <volume> Volume change
$D Pattern break
$F <tempo> Tempo change
It's not a very great idea to load a 4 channel tune and go 8 channels..
Because of the way the 8 channel routine works, it is very difficult to
make the portamento commands in 4 and 8 mode equal f.ex.
8. The DISKOP menu now uses a real filerequester.. So you can go loading
songs, modules and samples from wherever you want... There is no delete
buttons on the diskop menu because in the filerequester you can delete
any file you want.
Some bugs fixed:
When saving an 8 channel module or song the last odd pattern was lost.
This is now corrected. (Thanx Lord CMP of Paradise for reminding me
about that one.)
Restart didn't work in 8 channel mode. I had it fixed in one version
but unfortunately there was a slight version mix up. Now it's fixed.
There was a bug in the NoiseTracker 2.0 when loading the .NT extra
file. It was supposed to contain the midi transpose values etc. but
they got overwritten as soon as the file had been loaded. This is now
corrected.
VERY OLD DOCS:
POINT KEY: ( [.] On the keypad)
With the point key you can select three playmodes. With one press, one
dot will appear next to FREEMEM. You can now play with the keypad like
a drum machine. The pitch for each instrument is set by pressing left
ALT + the desired pitch key. With two presses, it's just like above
but now the notes will be written to the pattern when in edit or record
mode. With three presses, you will activate the POLYPHONIC mode. Now
you can play on the keyboard, and the StarTrekker will automatically
change voices. You can choose which voices are used by toggling them
on and off with left ALT + F6-F9.
QUANTIZE:
With the quantize control, you can choose how many lines the cursor
should jump when you enter a note in a pattern. The number is increased
by pressing the left mouse button in the QUANT box, or by pressing
CTRL. The number is decreased by pressing the left and right mouse
buttons in the box, or by pressing left SHIFT + CTRL.
COLOR CONTROL:
Because the ordinary grey color is so utterly boring, you can choose
between a bunch of colors by pressing ALT + F10. If you don't like any
of them, SHIFT + F10 makes your day by randomizing the colors!
MIDI:
INCOMING MIDI:
With the R: control you can select the channel the ST will respond
to. You can play on the synthesizer's three middle octaves just like
on the Amiga keyboard.
The ST will NOT respond to MIDI clocks, Active Sensing or other
control commands.
OUTGOING MIDI:
With the C: control you can select an outgoing channel for the current
instrument. The L: controls for how long (how many patterns steps) the
note will be played. If there is any C commands (volume change) in
the pattern, these will be sent along with the notes as Attack
Velocity. The T: finally is a transpose control.
The ST will send out MIDI clocks in the same tempo as you have
selected with the F command. Also the ST will transmit Midi Start
and Midi Stop when you start or stop a tune.
Remember to turn the MIDI on!
------------------------------------------------------------------------
BYE! HA DET BRA! /EXOLON
BRAECKKORV FOREVER!!!!
programming/AMIGA/suff_txt.dis
+24
View File
@@ -0,0 +1,24 @@
/\_______/\_____________/\ ___/\ _/\ _________/\/\_____________/\____/\
/ / / /\ \ \ \ / \____ \_| \ \
/ ____/ /_/ \_______ /___ /_ \_______/ \ / / | _ \_ \
\____ \ / / // /_\/ /_\/ / / / / \/ / | / / |\ \
/ \ \ \/ // ___/ ___/ / / /_/__ \ / | / / | \ \
/ / // // / / / /\ \_/| | / | / /
\_____ /_____ //__ //__ / \_____/\ _____/____\ / |___|___/|___|/ /
-=====\/======\/====\/====\/==========\/===========\ /[SK/M12]========\__/=-
\/
TUNE INTO.
>>-- +45-491-807-60 --<<
USR 14400 WITH ASL
OnLy 9600+ , OfCoX oNlInE 24 HoUrS , 0-1 DaYs OlD StUfF , CoOl UsErS
SySoP: RaMiReZ/BaLaNcE CoSySoP: MaBeY U See BeLow
>>- BALANCE DHQ -<<
-=-=-=-=-=-
BALANCE IS LOOKING FOR HOT MODEM TRADERS, SO IF U ARE INTERESTED
THEN CALL NOW AND LEAVE A MSG TO RAMIREZ.
programming/AMIGA/tbrad_tx.dis
+14
View File
@@ -0,0 +1,14 @@
This fine file came from...
____/\/\ /\__/\ /\___ __ /\ /\ __/\___ ___ __ __
/ _ _/ // / __/ \ _ \ / \\// / / __/ _ \ / _ \/ \/ \/\/\
\// // _ / __/ > _ </ / /\/ /_/ __/ _/ / _/ / / / / \
/ // // /_ / / ___/\__/ /_ /_ /_/\ \ /_/\ \\__/\__/ /\/\ \
\/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/ \/
* 2 /\/odes Ringdown! *
(716) 695-3707
Cool Sysop(s) - Cool Ratios
Supporting Commodore Amiga, Sega Genesis, SNES, Gameboy Wares!
programming/AMIGA/techart2.txt
+69
View File
@@ -0,0 +1,69 @@
* Copyright 1988 Commodore-Amiga, Inc.
* This information is provided "as is"; no warranties are made. All
* use is at your own risk. No liability or responsibility is assumed.
* Permission granted to reproduce, provided this notice remains.
IMPORTANT !
Official Warning to Rom-Jumpers, Structure-Hackers, and Others
==============================================================
From Commodore Engineering, Commodore-Amiga, and C.A.T.S.
We who bring you the Amiga want to make it perfectly clear that
if you don't follow the rules, you WILL break.
The following practices are NOT supported !
- Jumping directly to ROM code
- Modifying or depending on private system structures
- Depending on the addresses of system structures or free memory
- Ignoring hardware or software interfacing specifications
Do not jump into ROM. Beware of any example code that calls routines
in the $F80000 to $FFFFFF range. Those are ROM addresses and those ROM
routines WILL move. The only supported interface to system ROM code
is through the provided library, device, and resource calls.
Do not modify or depend on the format of the private system structures.
This includes the poking of copper lists, memory lists, and library bases.
Do not depend on any address containing any particular system structure
or type of memory. The system modules dynamically allocate their memory
space when they are initialized. The addresses of system structures and
buffers differ with every OS, every model, and every configuration, as
does the amount of free memory and system stack usage.
If you are using the system libraries, devices, and resources, you
must follow the defined interface. Assembler programmers (and compiler
writers) must enter functions through the library base jump tables,
with arguments passed as longs and library base address in A6. Results
returned in D0 must be tested, and the contents of D0-D0/A0-A1 must be
assumed gone after a system call. Do not use the TAS instruction.
Do not use assembler instructions which are priviledged on any
68000 family processor. All addresses must be 32 bits. Do not use
the upper 8 bits for other data. Do not execute code on your stack
or put shared system or DOS structures on your stack. And do not use
processor dependent software timimg loops for delays.
If you are programming at the hardware level, you must follow hardware
interfacing specifications. All hardware is NOT the same. Do not assume
that low level hacks for speed or copy protection will work on all drives,
or all keyboards, or all systems, or future systems.
Software distributers who purchase or contract software from
outside programmers must make sure that the programmers are aware
of correct programming practices and are providing software which
will not break on different machines or different OS revisions.
We are dedicated to enhancing and expanding the capabilities of
the Amiga hardware and software, while maintaining compatibility
wherever possible for those who follow the rules. Those who don't
follow the rules cans consider themselves warned.
programming/AMIGA/techart3.txt
+216
View File
@@ -0,0 +1,216 @@
Attention Game Vendors!
by Bryce Nesbitt
* Copyright 1988 Commodore-Amiga, Inc.
* This information is provided "as is"; no warranties are made. All
* use is at your own risk. No liability or responsibility is assumed.
* Permission granted to reproduce, provided this notice remains.
There are some very nice games for the Amiga that ignore the Operating System
and take over the machine. This practice is discouraged, but allowable.
Some of these games use the floppy disk hardware in an incorrect manner.
Such misuse is *NOT ACCEPTABLE*.
Worse yet, some books by major publishers have advocated incorrect use of the
disk hardware. For the benefit of software vendors, Commodore, dealers,
customers and the Amiga, this must stop.
Commodore uses floppy disk drives manufactured by several different vendors.
These vendors often upgrade or modernize their disk drive lines, usually
making the older drive models unavailable. For this reason, it is impossible
for a developer to test with all possible drive types. In order to work
across this broad spectrum of drives, certain rules must be adhered to.
To make compliance simple, here is complete and ready to use source code.
Three functions are provided to correctly implement the three most critical
drive operations. This code may be dropped directly into an existing loader
with no hassle, fuss or mess.
MOTORON ;Turn the motor on, and properly wait for the
; drive to reach full speed.
MOTOROFF ;Turn off and deselect all drives
STEPHEAD ;Step the head, and properly wait for the 3.0
; millisecond step delay on any speed CPU.
TEST ;Test program showing use of above functions.
* opt l+,c+,w-
;
; Low-level "take over the machine" disk drive functions.
;
; *** FOR USE ONLY WHEN YOU HAVE TAKEN OVER THE MACHINE ***
;
; Written by Bryce Nesbitt, Commodore-Amiga, Inc.
; No copyright claimed.
;
;****** Externally visible functions
XDEF MOTORON ;Turn drive 0 motor ON & wait for READY.
XDEF MOTOROFF ;Turn off all drive motors.
XDEF STEPHEADS ;Step the drive head & wait properly.
;****** Hard-coded I/O register locations
;
CIAA_PRA EQU $BFE001 ;Port "A" on CIA "A".
CIAB_PRB EQU $BFD100 ;Port "B" on CIA "B".
CIAA_TALO EQU $BFE401 ;Timer A low
CIAA_TAHI EQU $BFE501 ;Timer A high
CIAA_ICR EQU $BFED01 ;Interrupt control register
CIAA_CRA EQU $BFEE01 ;Timer A control
;;;;;;; MOTORON ;;;;;;;
;
; Turn off the motors of drives 1-3, then turn on drive 0.
; This function returns when drive 0 is ON and spinning at full speed.
; If drive 0 is already spinning, this function returns very quickly.
;
; The direction and side lines are untouched.
;
MOTORON:
or.b #$F9,CIAB_PRB ;Set motor line to off, deselect
;all drives, and unset STEP line.
and.b #$8F,CIAB_PRB ;Select drives 1-3 so they see the
;motor off setting
or.b #$70,CIAB_PRB ;Deselect drives 1-3
and.b #$7F,CIAB_PRB ;Set motor ON. This must be done
;*BEFORE* selecting drives!
and.b #$F7,CIAB_PRB ;Select drive zero. The drive will
;"remember" the motor setting
;if the motor was already on,
;nothing happens
motor_wait btst.b #5,CIAA_PRA ;Check READY line
bne.s motor_wait ;Busy-wait until drive is ready
rts
;;;;;;; MOTOROFF ;;;;;;;
;
; Turn OFF all drive motors.
;
;
MOTOROFF:
or.b #$F8,CIAB_PRB ;Deselect all drives and set motor
;line to OFF
and.b #$87,CIAB_PRB ;Select all drives so they see the
;new motor setting.
or.b #$F8,CIAB_PRB ;Deselect all drives
rts
;;;;;;; STEPHEADS ;;;;;;;
;
; D0 must contain zero to step te heads inward, and -1 to step the
; heads toward the outside of the disk.
;
; The heads will step in the direction indicated. After stepping this
; function will do a processor-independant wait for the required
; 3.0 milisecond step delay. Note that some disk drives do not
; require a full 3.0 miliseconds, but others do. It is not safe
; to release a commercial product with a shorter step delay.
;
; Note that the STEP line must always start out high, be pulsed
; low, then return high.
;
; Using this timer chip method and interrupts, it is easy to create
; a loader that keeps on loading while your title music plays.
;
STEPHEADS:
and.b #2,d0 ;Remove garbage bits
or.b d0,CIAB_PRB ;Set direction register FIRST
;(Try to be a little bit slow about pulsing the step line)
bclr.b #0,CIAB_PRB ;Pulse STEP line low
bset.b #0,CIAB_PRB ;Return STEP high
;
; Use the timer chip to waste 3.0 miliseconds
;
; The base Amiga crytal frequecies are:
; NTSC 28.318181 Mhz
; PAL 28.37516 Mhz
; The two 16 bit timers on the 8520 chips each count down at 1/10
; the CPU clock, or .715909 Mhz. That works out to 1.3968255
; microseconds per count. Under PAL the countdown is a hair
; slower, .709379 Mhz.
;
; To wait 1/100 second would require waiting 10,000 microseconds.
; The timer register would be set to (10,000 / 1.3968255 =
; 7159).
;
; To wait 3 miliseconds would require waiting 3000 microsecsonds.
; The register would be set to (3000 / 1.3968255 = 2148).
;
; See the hardware manual for more information on the 8520 chips.
;
;----Setup (really only needs to be done once)
move.w #$7fff,$dff09a ;Kill all custom chip interrupts
;----This sets timer A to one-shot mode.
move.b CIAA_CRA,d0 ;Set control register A
and.b #%11000000,d0 ;Don't trash the 60/50Hz flag
or.b #%00001000,d0 ;or serial direction bits
move.b d0,CIAA_CRA
move.b #%01111111,CIAA_ICR ;Clear all 8520 interrupts
;----end setup
;----Set time (low byte THEN high byte)
move.b #(2148&255),CIAA_TALO ;Mask off low part
move.b #(2148>>8),CIAA_TAHI ;Shift high part 8 bits
;----Wait for the timer to count down
busy_wait: btst.b #0,CIAA_ICR ;Wait for timer expired flag
beq.s busy_wait
rts
;;;;;;; TEST ;;;;;;;
;
; Quick, nasty test program
;
* INCDIR "inc:"
INCLUDE "exec/types.i"
INCLUDE "exec/ables.i"
XREF _LVODisable
TEST: move.l 4,a6
jsr _LVODisable(a6)
bsr MOTORON
moveq #10,d3 ;Ten full seeks before end
fullseek:
bset.b #1,CIAB_PRB ;Set direction to OUTWARD
moveq #80-1,d2 ;80 tracks
test4 bsr STEPHEADS
btst.b #4,CIAA_PRA ;Check track 00 sensor
dbeq d2,test4 ;Decrement and branch until
;EQual or count exceeded
moveq #80-1,d2
bclr.b #1,CIAB_PRB ;Set direction to INWARD
test3 bsr STEPHEADS
dbra d2,test3
dbra d3,fullseek
bsr MOTOROFF
fish bra.s fish
;
; We have killed the operating system, so this tester never exits
;
programming/AMIGA/techart4.txt
+71
View File
@@ -0,0 +1,71 @@
The Official Way to Software Reboot an Amiga - Bryce Nesbitt
* Copyright 1988 Commodore-Amiga, Inc.
*
* Executables based on this information may be used in software
* for Commodore Amiga computers. All other rights reserved.
* This information is provided "as is"; no warranties are made. All
* use is at your own risk. No liability or responsibility is assumed.
A number of Amiga programmers have had the need to reboot the machine
from within a program. Since no official guidelines have ever been
published, programmers have used various creative methods.
Unfortunately rebooting the machine is very tricky, and most attempts
have been flawed. The RESET instruction, for example, unconfigures
all memory; after RESET there is no place to run user code!
Most reboot code will break whenever the memory or CPU configuration
is changed. Other reset code will not work properly on the Amiga 1000.
A special sequence of operations is required to work with all the possible
memory and processor options available for the Amiga.
What follows is the one-and-only official supported way to reboot an Amiga
under software control.
****************************************************************************
*
* NAME
* ColdReboot - reboot the Amiga
*
* SYNOPSIS
* ColdReboot()
*
* void ColdReboot(void);
*
* FUNCTION
* Reboot the machine. All external memory and peripherals will be
* RESET, and the machine will start its power up diagnostics.
*
* The MagicResetCode must be used exactly as specified here.
* The MagicResetCode must be longword aligned. Failure to
* duplicate the code EXACTLY will result in improper operation
* under certain system configurations.
*
* RESULT
* This function never returns.
*
****************************************************************************
XDEF _ColdReboot
XREF _LVOSupervisor
_ColdReboot:
move.l 4,a6 ;Get a pointer to ExecBase
lea.l MagicResetCode(pc),a5 ;Location of code to RUN
jsr _LVOSupervisor(a6) ;RUN code in Supervisor mode
;[NOTE: The jsr is required even though Supervisor never returns.]
;-------------- MagicResetCode ---------DO NOT CHANGE-----------------------
CNOP 0,4 ;IMPORTANT! Longword align! Do not change!
MagicResetCode:
lea.l 2,a0 ;Point to JMP instruction at start of ROM
RESET ;all RAM goes away now!
jmp (a0) ;Rely on prefetch to execute this instruction
;---------------------------------------DO NOT CHANGE-----------------------
END
programming/AMIGA/techart5.txt
+117
View File
@@ -0,0 +1,117 @@
Disk Drives - what YOU are doing wrong!
* Copyright 1988 Commodore-Amiga, Inc.
* This information is provided "as is"; no warranties are made. All
* use is at your own risk. No liability or responsibility is assumed.
* Permission granted to reproduce, provided this notice remains.
A distressing number of our third party hardware and software
developers have been using the floppy disk drives in an incorrect
manner. If you use the trackdisk.device you are safe. If you go
directly to the hardware, or build hardware, then this article is
for you.
For Hardware types:
1> The disk drive light should not flash on and off during
access. Our drive activity light reflects the state of the
motor. Typically the LED signal is driven by IN_USE (pin 4).
2> For compatibility with future systems, we require that drives
refuse to step past track zero. That is, if the head is already
at zero, and an outward step is received, it should not move the
head. The drive must still reset it's "DISKCHANGE" latch,
however.
3> The critical specifications for our 90mm (3.5") drives are:
3ms track-to-track. 15ms settling time. >80% radial alignment
using a Dysan Alignment disk. 500ms motor spinup. 800ms maximum
power on delay.
For Software types:
This part is primarily directed at people who write custom
boot-loaders for game software. Due to defective loaders, there
are thousands of Amiga owners who can't load some games, and will
NEVER BE ABLE TO BUY THEM.
The ultimate source for information on drive timing comes from
the manufacturer's specifications. This article simply
highlights the most misused points.
1> Don't make bad assumptions. For example; if you depend on the
motor being on, turn it on before use. Don't assume that your
boot code will be entered with the disk drive or system in any
reliable state.
2> **NEVER** use a loop like this for timing:
move.w #$1000,D0
busy_wait dbra d0,busy_wait
This fails to produce accurate timing under a large number of
circumstances. The speed of the above loop depends on what CPU
is installed in the system, what video mode is selected, what type of memory
the program is in, in what relation to vertical
blank the code executes in, what the blitter is doing, what
interrupts are enabled and more other factors than you want to
think about.
The 8520 chip provides fast, easy timing. See the companion
article entitled "How to waste time".
3> The STEP line must be used as a low-going pulse. The
direction must be set up FIRST, with a separate write to the
register. A typical use would be:
or.b #%00000010,$bfd100 ;Set up direction
and.b #%11111110,$bfd100 ;Pulse low
nop ;Wait a bit
nop ; " " "
or.b #%00000001,$bfd100 ;Set it high again
;-- now wait 3 miliseconds for the head to
;-- get to the next track
We specify that our drives must get to the next track within 3
miliseconds. Some drives will step considerably faster, others
will fail at or before 2.8 miliseconds. When the direction of
step is changed, the settling time must also be added (a total
minimum delay of 18 miliseconds).
Note that the TRACK ZERO sensor will not be valid until the head
actually reaches the track.
4> When turning on the motor, wait for the READY signal to go low
before reading or writing (steps are ok before then). Note that
READY is only valid when the motor signal is ON.
5> To determine if a disk is in the drive, look at the DISKCHANGE
signal. If it is low,the disk has been removed (and possibly
inserted again) since the last check. Step the head to reset the
latch and examine the current state.
6> Some code uses an extra track or two for storage or copy
protection. We will not guarantee that our drives will have more
than the normal 80 tracks. We will say that using one extra
track is rather safe, two tracks is probably ok, and three tracks
is a very bad idea.
7> After a disk write DMA has finished, a delay of 1.2
miliseconds is required before any other operations (drive
select, step, head change, etc.). The type of disk drives we use
have a gap between the erase head and the read-write head. The
disk drive keeps the erase head enabled after the end of write gate to
compensate for the gap. Failure wait out the delay may
result in writing over innocent data on other tracks or sides.
-Bryce Nesbitt
programming/AMIGA/techart6.txt
+128
View File
@@ -0,0 +1,128 @@
How To Waste Time
* Copyright 1988 Commodore-Amiga, Inc.
*
* Executables based on this information may be used in software
* for Commodore Amiga computers. All other rights reserved.
* This information is provided "as is"; no warranties are made. All
* use is at your own risk. No liability or responsibility is assumed.
The worst way to insert a delay in an Amiga program is this:
move.w #2000,d0
loop dbra loop,d0
This loop, or anything like it is *unacceptable*.
If running under the multitasking operating system, the
timer.device can provide delay that still lets other tasks run.
If taking over the machine, a loop like this is far better:
loop btst.b #0,$bfed01
beq.s loop
This uses one of the high speed timer chips. As included example
shows, the timers are very easy to use. This method is superior
for a large number of reasons:
° The timer chip loop is more accurate.
° The software loop method fails to produce accurate timing under
a large number of circumstances. The speed depends on what CPU
is installed in the system, what video mode is selected, what
type of memory the program is in, in what relation to vertical
blank the code executes in, what the blitter is doing, what
interrupts are enabled and more other factors than you want to
think about.
° The timer chip can be "set and forgotten". The chip does the
counting. Your code can continue to get other things done while
the chip is counting.
° The timer can produce an interrupt when it is finished, or it
can set a bit you can examine at any time.
° The timer can be set to automatically reload the count and
start again. This gives even pulses, even if your software can't
respond to them immediately.
Calculating the time
First some definitions:
1 milisecond (ms) = 1/1,000 second
1 microsecond (us) = 1/1,000,000 second
1 nanosecond (ns) = 1/1,000,000,000 second
On a stock 68000 based Amiga with no extra memory, the "DBRA"
instruction listed above will take about 1.5 microseconds per loop. The loop
above will thus waste about (2000 * 1.5 = 3000)
microseconds (This is the same as 3 miliseconds, or .003
seconds).
Each 8520 chip has two 16 bit timers counting down at .715909
Mhz, or 1.3968255 microseconds per tick. To get the same 3
milisecond delay with the 8520, we need to divide the desired
time by the rate. 3000 / 1.3968255 = 2148.
A Complete Example
;
; A complete 8520 timing example. This blinks the power light at
; (exactly) 3 milisecond intervals. It takes over the machine,
; so watch out!
;
;
; The base Amiga crytal frequecies are:
; NTSC 28.318181 Mhz
; PAL 28.37516 Mhz
;
;
;
; The two 16 bit timers on the 8520 chips each count down at 1/10
; the CPU clock, or .715909 Mhz. That works out to 1.3968255
; microseconds per count. Under PAL the countdown is a hair
; slower, .709379 Mhz.
;
; To wait 1/100 second would require waiting 10,000 microseconds.
; The timer register would be set to (10,000 / 1.3968255 =
; 7159).
;
; To wait 3 miliseconds would require waiting 3000 microsecsonds.
; The register would be set to (3000 / 1.3968255 = 2148).
;
; See the hardware manual for more information on the 8520 chips.
;
ciaatalo EQU $bfe401 ;Timer A low
ciaatahi EQU $bfe501 ;Timer A high
ciaaicr EQU $bfed01 ;Interrupt control register
ciaacra EQU $bfee01 ;Timer A control
move.w #$7fff,$dff09a ;Kill all custom chip interrupts
;----Setup, only do once
;----This sets timer A to one-shot mode.
move.b ciaacra,d0 ;Set control register A on CIAA
and.b #%11000000,d0 ;Don't trash the 60/50Hz flag
or.b #%00001000,d0 ;or serial direction bits
move.b d0,ciaacra
move.b #%01111111,ciaaicr ;Clear all 8520 interrupts
;----Set time (low byte THEN high byte)
;----And the low order with $ff
;----Shift the high order by 8
move.b #(2148&255),ciaatalo
move.b #(2148>>8),ciaatahi
;----Wait for the timer to count down
busy_wait: btst.b #0,ciaaicr ;Wait for timer expired flag
beq.s busy_wait
bchg.b #1,$bfe001 ;Blink light
bset.b #0,ciaacra ;Restart timer
bra.s busy_wait
END
programming/AMIGA/terror.tag
+26
View File
@@ -0,0 +1,26 @@
.-------------------------------------------------------------------------.
| . . |
| _____________|___________________________________________|_______ |
| _/ ______ | ___. ______. ______. __ || _/ |
| _\____. \ |_ / |\ \/ |\ \/ | \/ || \ |
| \ | \_ _/ \_ _/ \ |/ \_ : \_ || \_ |
| \___________/ \_____/__| \___________/__________/___________/ |
| \________|sc | \ . |
| ____________| \________ |__________________ |
| \________ \ .________ \| ___ __ / |
| / ._____/ | \/ \ \/ _)____/ |
| _/ | \_ : _/ \ \_ \| \_ |
| \_____________/ \______|\_______/__________/ |
| |______________/ |
| |
| (=========)> INSANES SHQ & X-TRADES WHQ <(=========) |
| (=========)> NODE 1 +46-8-7651455 <(=========) |
| (=========)> NODE 2 +46-8-PRIVATE <(=========) |
| (=========)> ASK THE STAFF FOR THE NUP! <(=========) |
| |
`-------------------------------------------------------------------------'
.-------------------------------------------------------------------------.
|Pyro/Phreak/Anarchy/Drugs/Terror/Hpa/Cards/Constructions/Magazines/Texts!|
`-------------------------------------------------------------------------'
programming/AMIGA/tslad_tx.dis
+18
View File
@@ -0,0 +1,18 @@
This fine file came from...
____ ___ ________ _____ _____ ____
THE/ _ \O / / __ __ / / _ \ / /\ \/ /\ \/ \
\ \\_/\/ / /_ \/ \ \_/\\ \\_/ / / \ \ /__\ \ ___ \
_\ \/ \ / _/___/ /\\ / > \ \ \/\/ / ____ )___\/
/ \> \ /\\/ \\/ \ \/</\/ /\> \ \ / \ / / \
\____/\/ \__/\__/\_/\__/\/\___/ \_/\/ \__\/_/\____/\_\
"When Words Are Not Enough!"
The Edge (716)-655-4940 3 Nodes - Sysop: Planet Master
3 Nodes! all 16.8 Dual HST's - Multi-Node Chat
Supporting 0 Day Amiga and 0 Day Console Warez!
Running GVP's G-Force '040/2000 33Mhz!
OnLine Since 1985!
programming/AMIGA/tutorial.txt
+149
View File
@@ -0,0 +1,149 @@
How to write a Shoot 'em Up, by Phagex of LSD.
The source code for this tutorial should be hanging around one of the
Grapevine disks, and is self exctracting: GameTut.EXE
Right, this is a tutorial for all the coders out there who have learnt how
to put a screen on and make a few bobs fly around, but havent got an idea
about how to put them to proper use. In this tutorial i have coded the basic
platform (Nooo! not a PLATFORM game! (it isnt a PLATFORM game is it?)) of
a shoot 'em up. Its a very simple move yer space ship around the screen,
and shoot upwards against the nasty alien coming down at you type affair,
only its a complete, fully commented source code that i've given you to play
with. I've placed this game into the Public domain through Grapevine, but
i have FULL copyright on this game, ie. the GFX and source. I know it isnt
that much, but i'de prefer you to draw and eventually program your OWN
routines instead of just lifting them from my source, although it really
isnt the BEST source anyway! But it does do the job (which is all that
matters when your coding for a living hehe!)...
Anyway, off we go with a loose description of what happens:
First of all you naturally kill the system and set the games variables,
then we have a few presentation routines for fading in and out and
displaying text. Start off with "Get Ready" and then head for the main
game processing loop which is what i'll now describe in more detail...
First of all, the screen is double buffered, which i'm sure you all know the
purpose of, (y'know, keeps everything smooth and flicker free) not only does
this mean that the screen has two memory banks, but all variables associated
with the blitting and clearing are double buffered as well.
The Aliens, Bullets and Explosions all have three data lists each, the first
is the Variable Table which stores main variables about each item, and then
theres 2 tables (double buffered) which stores the actual items Screen memory
address, this is to allow for blitter clearing on the next frame.
The Variable Tables are used differently for each type of on screen object,
each alien has 4 words allocated to it, the 1ST is the downwards SPEED
(ie. this variable is added to the aliens Y Position), the 2ND and 3RD are
the X and Y Positions, and the 4TH is its animation FRAME. The SPEED
variable is also used as an active FLAG, ie. if the speed is -1 ($ffff) then
that particular alien is inactive (not shown), but if its positive ie. 1++
then the alien IS active and is used as the speed. Bullets are simpler in
the way they just have 2 words, X & Y Positions, but if the X Position is -1
(Off screen) then its inactive and not shown. Explosions have 3 words, an
X & Y and an animation Frame, similar to the bullet configuration.
Now the first thing i've done at the start of the loop is to clear all the
old objects such as the ship, aliens, bullets (fire) and explosions off the
screen, this is done by storing the memory positions of everything on screen
in the last frame. Then the clear routine just has to look up the last
active objects and BlitClear them, this individual clearing is faster than
clearing the WHOLE screen with the blitter.
The next 2 routines service the bullets, first the bullets variable table
is scanned, any active bullets are moved UP the screen by subtracting a
speed variable from the bullets Y Position, if however the bullet reaches
the top of the screen then its life is over and that bullet is disactivated
in the VarList. The next routine blits the bullets onto the currently
active screen. This is done by scanning the VarList for active bullets
(X Pos <> -1) and just blitting onto the screen with any active bullets X & Y
positions.
Next are the alien routines, first a quick randomize routine which uses a
few sources of varied numbers ie. X & Y Position of spaceship, raster X & Y
position and contents of the KickStart ROM chip. The new random number is
used as the new X position and for the speed of any new aliens activated.
The second routine is the New Alien one, every 10 frames a new alien is
activated, the routine searches down the aliens VarList for an empty
location (ie. unactive alien) and the first empty location it finds it puts
the random number into the X Position (within screen boundaries), zeros the
Y position and animation frame, and uses the remainder of the random number
as the new aliens speed. This sets a new active alien into the VarList. The
third alien routine moves the aliens down the screen, same as the bullet
mover works, but in the opposite direction. When the alien reaches the
bottom of the screen, it is then disactivated. The fourth routine is a
collision detection routine, it uses the VarLists of both the Bullets and
the Aliens, its checks the X & Y Positions of all active bullets against
all active aliens. If any bullets co-ords are found within an aliens, then
the alien is disactivated, score is increased and the New Explosion routine
is called. The explosion routine searches through its VarList for an unused
explosion, gives the dead aliens X & Y Pos for a new explosions co-ords, and
sets the frame to 0. The fifth routine is just a blitter routine, goes
through the Aliens VarList, blitting any alien active.
Next are the 2 explosion routines, the first just scans the explosion
VarList and increases the Animation Frame number of any active explosions.
When the frame counter of any explosion reaches 18, that explosion is
disactivated as its reached its last anim frame. Second routine just blits
the explosions current anim frames at their corresponding X & Y Pos.
Next is a quick check to see if the spaceship has been hit, and if its in
the process of "dying" then the next few routines are skipped.
The CheckAlien routine is the other collision detection routine, where
co-ords of active aliens are checked against the spaceships X & Y Pos. If
the ship has collided, then an explosion is activated and a flag set to
indicate death. TrackStick and TrackMouse just get the status of the
joystick and mouse and set the movement flags accordingly. The MoveShip
routine checks the movement flags and moves the ship Up/Down/Left/Right at
the selected ship speed, it also checks the ships co-ords against the screen
boundaries, and makes sure the ship doesnt wander off the edge of the screen!
Then the ships X & Y co-ords are Double buffered into either 1 of two sets
according to what screen the ship will be displayed on.
Finally the SpaceShip is blitted onto the screen.
Then we wait for the Vertical Blank period, then double buffer the screen
and copperlist, and increase the time variables.
A quick check to see if all the lives have been used up by the player, if
they have then jump to the "Game Over" routines and exit, otherwise check
the right mouse button, if pressed then quit anyway, else jump back to the
mainloop!!
And thats just about it! Well its a fairly complex process, but hopefully
you've learnt the basics of it all. Theres quite a bit you can improve on,
like the aliens, all they do is come down the screen at you, it shouldnt be
too hard to make a routine where they follow a pattern, go left and right,
in a circle or even both! Then theres intelligence routines, aliens that
follow you or avoid you. Perhaps even a scrolly background that moves
down the screen, complete with level maps and such. Theres plenty of ideas
to add to it all. But remember to keep your source code simple and clean,
it helps to be able to read and understand source that you coded while in
a "different" state of mind like you were the other night hehe!
Oh, i coded this game in Devpac 3.02, and i recommend you use it or a Devpac
variant for source compatability, i dunno about this ASM-one and Trashm
business. Devpac isnt the best, but i think its the most user friendly.
As for future tutorials from me, well i'll keep 'em simple because i'm
coding Satan On Speed for LSD and thats using ALL my free time up! But i
may even come up with a tutorial on platform games, but then again, WHO
HASNT CODED A PLATFORM GAME!!! There are just SOOO many!!! But i suppose
theres always room for a GOOD platformer, most i've seen today are just
simply shite.
Also i'm upping quite a bit of my source code to Pazzas BBS, so when its
online you can leech my codings heh, but dont go bothering Pazza for my code
pleeze.... cya 4 now....
programming/AMIGA/undrgnd.tag
+12
View File
@@ -0,0 +1,12 @@
--------------------------------------------------------------------------------
___ __ ____________ _ __ ___________ __
/ _/\/ /\/ / __/ / /_ \/ \ /\/ / / __/ /_ _/\/ / Sysop: Vivace/XAKK
\_ \ / / /_/ / / O \ / / /_/ / / / \ / Cosys: Knatter/XAKK
/___/_/_/\/\__/_/_/_/\_\___//\/ \__/_/ /_/ /_/
X a k k h e a d q u a r t e r s
"NO ELITE, JUST PURE INFORMATION"
--------------------------------------------------------------------------------
- Lots of underground cyberpunkish textphiles - 6000 philes and rising -
- 16800 DS - 420 Meg - PC/Amiga/ST - Free Download for all Star Trek f¡les -
+46(0)431 17506
--------------------------------------------------------------------------------
programming/AMIGA/vectors
+1686
View File
File diff suppressed because it is too large Load Diff