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/24hrs.txt
+296
View File
@@ -0,0 +1,296 @@
Some opinions on leaving your computer on 24 hours a day and mounting
your machine sideways.
===============================================================================
This is the version that was included in the Frequently Asked Questions
file until May 1990:
There's a lot of stress placed on the system when it first comes up.
Generally, you should leave your system running if you plan to return
within the next few hours or so; if you don't expect to be using it for
a day or so, whether or not you turn it off is a personal judgement call.
Monitors aren't the same, though, since images can get "burned into"
the phosphor. Use a screen blanker, or turn it off if you'll be away
for more than five or ten minutes.
As for mounting it sideways: The most common myth about this is that
it will make the disk drive bearings wear unevenly. If you look at the
manufacturer's information when you buy a disk drive, you will see
that it is warrantied in any position *except*upside-down* (with the
defect label down). However, the disk may hang slightly differently in
the bearings after being placed on its side, so if you plan on
mounting your system sideways, you should back up your hard disk while
it's level, then mount your system sideways and do a low-level
reformat of your hard disk and restore it from the backup you made. If
you do this you shouldn't have problems.
===============================================================================
From: chuck@eng.umd.edu (Chuck Harris)
Subject: Computer on 24hrs.day?
Date: 30 Mar 90
I can provide some info on the phenomonon. Semiconductors have failure
curves that look like:
||
||
Failures||
| \ /...
| \ /
|_____\______________ ... ___/__
0 100 1E6 = ~100 years
Hours of use
The failures in the first 100 hours are some times called Infant mortality.
I'm not sure at all about the 1E6 hours (Lets say it's a lot of hours!)
The first 100 hours failures are the reason the most reputable manufacturers
will "Burn-in" new systems. Statistics shows that there is little gain in
confidence by burn-ins much longer than 100 hours.
NASA (I think) found that semiconductors that had been left on for a long,
long time were very likely to fail if their power was cycled off then on again.
However, statistics showed that the same semiconductor if just left on would
continue to work almost indefinitly.
As I recall the failures due to cycling power occured while the power was off.
it had something to do with the transistor's junctions migrating too close
together while power was off, then when power was turned on, the transistor
failed because the junctions were shorted. (power being on continuously
apparently prevents this) Anyone know more about this?
These are the tests that everyone alludes to when they tell you to leave
computers and other electronics on all the time for greater life. They
only mean something if you have a statistically large number of transistors
(the transistors need to be from different lots not just a large number on an
IC) in your system, and you are using the system for a LARGE number of hours.
Your individual PC does NOT have a statistically large number of semiconductors
in it. The entire country's PC's do. 100 years is a long time.
Conclusions that I think you should draw from this diatribe:
1) Big computers that have millions of IC's in them perhaps should
be left on.
2) Small computers (PC's etc) It just won't matter.
Note: Failures of mechanical parts are nothing like that of semiconductors!
(You know, disk drives, switches, keyboards, fans, etc.)
I wish I could provide references to all of what I have stated, but
I can't easily. This is stuff that I have gleaned from years as an Engineer,
and many many hours of college course work. So some settling may have
occurred :-)
Chuck Harris
C.F. Harris - Consulting
===============================================================================
From: nicholso@hpcuha.HP.COM (Ron Nicholson)
Subject: Re: Dusty Dorms. WAS: Re: Computer on 24hrs.day? (yes or no)
Message-ID: <10350001@hpcuha.HP.COM>
Date: 30 Mar 90 23:29:35 GMT
gregk@ubvax.UB.Com (Greg Kendall) / 6:59 pm Mar 28, 1990 / writes:
>I've heard a lot of claims about how it's "harder" on the PC to power
>up than to leave it on. I have yet to hear of any real data on failure
>rates. ...
----------
Long long ago, in a far away place, when I worked for a high volume
computer manufacturer, I ran across some real statistics. Some
experiments had been done on the difference in failure rates between
continuous burn-in and power cycling. My dim recollection is that there
was a significant increase in the infant mortality rate of the group
that underwent power cycling.
The sample size was large enough to be statistically convincing. The
primary cause of the failures was due to thermal shock on solder joints,
IC bonds, sockets and connectors.
Alas I no longer have access to the details of that experiment. What I
now do is to frequently power cycle new equipment (while it's still under
warranty of course) to shake out the lemons, and to minimize power cycles
thereafter. I still have seen no good data on electromechanical
equipment, like disk drives.
---
Ronald H. Nicholson, Jr. Hewlett Packard
uucp: nicholso@hpda.HP.COM Cupertino, CA
===============================================================================
From: dan@tinton.tinton.ccur.com
Subject: Computer on 24hrs a day?
Date: 5 Apr 90
Power conditioning must play a part in the equation. If one's AC supply is
relatively dirty and one has limited power conditioning equipment, then leaving
one's system on constantly leaves it open to large power glitches wreaking
havoc.
===============================================================================
From: uunet!tiamat!quintro!bpdsun1!rmf (Rob Finley)
Subject: Re: Computer on 24hrs.day? (yes or no)
Date: 15 Apr 90 06:38:02 GMT
My floppy drive fails to read some disks when cold. So, I leave it
on. After three years, the only thing that died is the cheap 12V fan
in my UL listed power supply. $15 and a trip to Radio Shmuck did the
trick. It's still ticking.
Just be sure to use a good screen blanker program. Most of our machines
at work are never turned off.
But. My 386 at work ate two hard drives and three motherboards before
they replaced the power supply. The +5v line ran at 5.2v while the
other voltages were acceptable with low electrical noise. New supply
and it works great.
Before deciding whether to leave it on or not. Consider these points:
Does your system draw air into the box through a vent on the back?
If you feel air being blown out the vent on the power supply, then
it is most likely sucking it in through the biggest hole: your
floppy drive. When air comes in through the drive door, it drops the
dust it was carrying all over your machine, mostly on your disk drive.
Remedy: replace the power supply with one that has the fan going
in the right direction. Swapping the Red and Black wires on it won't
do. You will cause irrepairable damage to the solid-state controller
(they don't have brushes like conventional DC motors to control noise).
I had to open the power supply box (after removing it from my machine)
unscrew the fan mounting hardware and turn it over so that it draws air
in from the vent that sticks out the back of the cabinet when installed.
With your fan now drawing air from one place, you can tape a piece of
foam or air filter material over that vent to catch a large percentage
of the dust before it gets inside. But, you must check the filter
regularly. The entire system may be at risk with a blocked air filter.
Or, if anything, your expansion boards will attract the dust before it
reaches your floppy drives. Unfortunately, too much dust on the
motherboard or expansion boards will insulate the chips and prevent
them from keeping cool.
If you have large expansion boards or full height hard drives,
look into adding additional fans. Some cabinets allow you to have a
second one on the front end of the expansion card cage. If you don't
want to open your machine and it overheats or attracts dust in all
the wrong places, turn it off if possible. Machines today are durable.
Safety warning. If you don't feel comfortable opening your machine,
find someone who is. If your dealer doesn't feel comfortable, find
another dealer. The one you have now probably can't fix it if it dies.
The power supply circuit can still hold a charge when it is unplugged.
You shouldn't have to touch any of the circuits on the power supply
board. You aren't rewiring it, you're flipping the fan over and putting
the screws back in.
That wasn't hard. Was it?
-----
quintro!bpdsun1!rmf@lll-winken.llnl.gov uunet!tiamat!quintro!bpdsun1!rmf
===============================================================================
From: kabra437@pallas.athenanet.com (Ken Abrams)
Subject: leaving PC on
Date: 8 Aug 90
In article <hart.650028982@blackjack> hart@blackjack.dt.navy.mil (Michael Hart) writes:
>I refer you to the "light bulb law". That law being: When do light bulbs
>burn out?? _when you turn them on_ There is a large surge of current through
Even though most of the components in a PC are NOT light bulbs ( and don't
behave like one either), I would agree with you that leaving it on is best
if the ONLY consideration was hardware reliability (and it is connected to
a stable power source). As I see it, however, hardware reliability is not
the only issue and a case can be made for the theory that a properly designed
disk drive will wear out from heat and friction and dirt before it will
suffer any electrical damage from being started and stopped once a day.
I think that all the energy wasted by millions of PCs left on 128 hours a
week when they are not being used is a bigger and more important issue than
whether or not it will extend your repair cycle from 3 years to 5 years.
There is also a small extra potential for a fire in a running device.
I have been in the computer industry for close to 25 years, mostly as a
technician. I have weighed all the arguments and I have decided to turn
MY machines off when they will not be needed for 6 hours or more. I even
turn the Xenix box off over the weekends.
Like a lot of other things in modern life, this is not strictly a technical
call but it has some moral undertones too. Make your own call but don't
overlook part of the factors in the process.
===============================================================================
From: linderd@merrimack.edu (Doug Linder)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Horizontal cards (was Re: Standing your box upright)
Message-ID: <18991.262c5b5c@merrimack.edu>
Date: 18 Apr 90 12:19:40 GMT
In article <1990Apr16.181035.3017@seri.gov>, marshall@wind55.seri.gov (Marshall L. Buhl) writes:
> Another thing to consider when standing a PC on end. One of my secretaries
> stood hers on end for a year or so. When she left, I tore the machine
> apart and found that the AST 6 Pack was really warped. If you laid it on
> a table, one end would be 1" in the air. It still works, but...
Maybe the solution is to flip the thing from end to end every 6 months to
even out warpage? ;-)
But seriously, folks, when I was a PC tech I did see some problems with this.
Essentially, it seems that the larger the number of cards you have, how big the
cards themselves are (height/thickness) and how good your fan is are the big
factors. Remember, these cards are designed to stand on edge and let the heat
float to the top of the box where it can be sucked away by the fan. A PC on
its side screws up this system and the heat, trying to rise, gets caught by the
cards and what you end up with are little heat sandwiches between the cards -
the hot air has nowhere to go. I have seen machines with lots of big cards in
them that you could fry an egg on. The biggest danger with cards "melting" is
not only that the card itself may malfunction, but that it wil come in contact
with something it shouldn't (usually another card, the one below it) and short
out the whole works. I have seen motherboards die this way.
This can be alleviated by some things such as:
1) a fan (a standard room fan pointing at the machine),
2) room A/C,
3) simply leaving the cover off the machine and covering it with a cloth
supported by a wire frame (to hold the cloth away from the machine a
few inches)
4) If the cards are long enough, mounting brackets at the front of the machine
for the ends of long cards to rest in will prevent "drooping" at the ends
but alas, cards still droop in the middle.
My best advice: Unless you have only a monochrome card and a serial/parallel
card, or some other very low heat/high circulation setup inside the machine,
place it the way it was designed to be placed - "power users" take note. The
equipment is too expensive and your time too valuable to waste with breakdowns.
Would you want your PC to die in the middle of a presentation because the
Video card just warped enough to touch the drive controller and short out the
whole works? BTW, though, I have found that smart terminals like Novell
network PCs work OK on end - as long as the novell card is about the only thing
in the machine.
Hope this helps.
--
Douglas D. Linder linderd@merrimack.edu
Merrimack College, N. Andover, MA {uunet,wang,ulowell}!samsung!hubdub!linderd
===============================================================================
From: alz@tc.fluke.COM (Al Weiss)
Subject: Is it [orientation] harmful to disk drives?
Date: 4 May 90
Dunno about floppies. For hard drives it depends upon the manufacturer. All of
the Seagate manuals I've seen, for instance, are VERY specific in their manuals
about not elevating the front or back more than 5 degrees from horizontal.
They can however be turned on their sides up to 90 degrees, but no further (ie
not upside down). They should also be formatted in their permanent
orientation. My understanding is that the head positioning mechanism gets worn
out on an angle, and the motor bearings can't hack being upside down. On the
phone, Seagate told me that they would not honor any warrantee if they know
that it has exceeded those limits. I've heard some newer Seagates don't have
limits, but don't know for sure, nor do I know about the CDC's. Conner,
Quantum, Miniscribe, Maxtor(?), on the other hand, (of the ones I've seen)
specifically say "any orientation".
===============================================================================

|-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.92 by Troed/Sync. BBS: +46-451-91002 >
programming/25th_ann.uni
+1071
View File
File diff suppressed because it is too large Load Diff
programming/3drotate.txt
+484
View File
@@ -0,0 +1,484 @@
ÖÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´% VLA Proudly Presents %ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ·
º º
ÓÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄĽ
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
Three Dimensional Rotations For Computer Graphics
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
By Lithium /VLA
One of the most difficult programming difficulties you will face is that
of representing a 3D world on that 2D screen in front of you. It requires
some linear alegbra that may be difficult for some, so I will spend some
bytes explaining the mathmatic computations of using matricies in addition
to the equations to get you going. This document is intended to be an aid
to anyone programming in any language, as a result it will use mathmatic
notation. If you are worthy of using these routines, you ought to be able
to get them into your favorite language. All I ask is that you pay a little
tribute to your programming buddies in VLA.
If you aren't a math person, skip to the end and get the final equations.
Just be forewarned, implimenting these equations into a coherient 3D world
is hard enough when you undersand the mathmatics behind them...
REAL PROGRAMMERS AREN'T AFRAID OF MATH
3D Coordinates
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
Just so we all understand each other, 3D is defined in of course three
directions, we'll call them (X,Y,Z). X will be the horizontal plane of your
screen, Z will stretch vertically, and Y will extend out of and into your
screen. Got it? Hope so, becuase it gets a bit tricky now. The next
system is called Sphereical Coordinates it is defined by angles and distance
in (é,í,p) These Greek letters are Theta (é), Phi (í), and Roe (p)
Z Z
| | é - Angle in the XY
| |\ plane
| |\\
| | \\ í - Angle from the Z
|______ X |í_|\___X axis
/ / \ v \
/ / é \ o p - Distance to point
/ /\ \ | from the origin
/ / --> \ | (0,0,0)
Y Y \|
To relate the two systems you can use these equations.
X = p(siní)(cosé) é = arctan (X/Y)
Y = p(siní)(siné) í = arccos (Z/p)
Z = p(cosí) p = û(X^2 + Y^2 + Z^2)
If these don't seem right, do a couple of example problems for yourself,
it should make since after a bit of trig.
Matrix Notation
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
Lets say I can define Xt and Yt with the equations:
Xt = aX + bY Where a,b,c,d are coeffiencets
Yt = cX + dY
The matrix notation for this system of equations would be:
Ú ¿
(Xt,Yt) = (X,Y)³a c³
³ ³ And we solve for this with these steps
³b d³
À Ù
Ú ¿
Xt = (X,Y)³a .³ = aX + bY
³ ³ We move across the coordinates left to right
³b .³ and multiply them by the coeffients in the
À Ù matrix, top to bottom
Ú ¿
Yt = (X,Y)³. c³ = cX + dY
³ ³ For Y, the second number, we use the second
³. d³ column of the matrix
À Ù
We can also multiply matricies in this fashion
Ú ¿ Ú ¿
T = T1*T2 Where T1 = ³a c³ and T2 = ³e g³
³ ³ ³ ³
³b d³ ³f h³
À Ù À Ù
Ú ¿Ú ¿ Ú ¿
³a c³³e g³ ³(ae + cf) (ag + ch)³ rows -> columns |
³ ³³ ³ = ³ ³ v
³b d³³f h³ ³(be + df) (bg + dh)³
À ÙÀ Ù À Ù
This product is dependent on position, so that means that
T1*T2 *DOES NOT* equal T2*T1
In English, the process above went like this, we move left to right in
the first matrix, T1, and top to bottom in the second, T2. AE + CF is our
first position.
The numbers in the first row are multiplied by the numbers in the
first column. 1st * 1st + 2nd * 2nd is our first value for the new matrix.
Then you repeat the process for the next column of the second matrix.
After that, you move down to the next row of the first matrix, and
multiply it by the 1st column of the second matrix. You then do the same
for the next column of the second matrix. This process is repeated until
you've done all of the rows and columns.
If this is your introduction to matricies, don't feel bad if you're a bit
confused. They are a different mode of thinking about equations. The
operations above give the same results as if you were to do the long hand
algebra to solve them. It may seem a bit more difficult for these examples,
but when you get to systems of equations with many variables, this way is
MUCH faster to compute. Trust me, especially when you make your program do
it.
So, now you have the basic math....
One important point for these matricies below. I will use a homogeneous
coordinate system, (X/r, Y/r, Z/r, r) Now I'll use r=1, so nothing will
really be different in my calculations, but you need to understand the
purpose.
This form is very convienent for the translations and rotation
equations we will need to do because it allows for scaling of our points with
respect to a center point.
Consider a point (2,2,2) in an object centered at (1,1,1). If we were
to scale the X direction by 3,(the X length to the center is 3 times what it
was) the point we want would be (4,2,2). Our new X = 3*(OldX-CenterX).
Without the added factor of the homogeneous system, calculations assume all
objects are centered at the origin, so our point would have turned out to be
(6,2,2), NOT the one we wanted. So that's why we are going to do it that way.
ROTATIONS AND TRANSFORMATIONS
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
Translation
ÄÄÄÄÄÄÄÄÄÄÄ
We will start with translation from the origin. Most objects are not
at (0,0,0,1), so we'll call their center (Tx,Ty,Tz,1).
Ú ¿
³ 1 0 0 0³ = T1
³ ³
³ 0 1 0 0³ This physically moves the object, so it is centered
³ ³ at the origin for our calcuations, eliminating the
³ 0 0 1 0³ need for a -Tx for each X, the matrix will factor it
³ ³ in when we multiply it by the others
³-Tx -Ty -Tz 1³
À Ù But, we need sphereical coordinates...
Ú ¿
³ 1 0 0 0 ³
³ ³ = T1
³ 0 1 0 0 ³
³ ³
³ 0 0 1 0 ³
³ ³
³-p(cosé)(siní) -p(siné)(siní) -p(cosí) 1 ³
À Ù
XY Clockwise Rotation
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
This will be our first rotation, about the Z-Axis
Ú ¿
³ siné cosé 0 0 ³
³ ³ = T2
³-cosé siné 0 0 ³
³ ³
³ 0 0 1 0 ³
³ ³
³ 0 0 0 1 ³
À Ù
YZ Counter-Clockwise Rotation
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
Now we rotate about the X axis
Ú ¿
³ 1 0 0 0 ³
³ ³ = T3
³ 0 -cosí -siní 0 ³
³ ³
³ 0 siní -cosí 0 ³
³ ³
³ 0 0 0 1 ³
À Ù
Notice that with two rotations that we can get any position in 3D space.
Left Hand Correction
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
This will flip the X coordinates. Think about when you
look into the mirror, your left hand looks like your right.
These rotations do the same thing, so by flipping the X, it
will make your X move right when you increase it's value.
Ú ¿
³ -1 0 0 0 ³
³ ³ = T4
³ 0 1 0 0 ³
³ ³
³ 0 0 1 0 ³
³ ³
³ 0 0 0 1 ³
À Ù
The Final Viewing Matrix
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
This is the net transformation matrix for our viewing perspective
The math for this one is really messy, and I would need to go over even
more matrix stuff to get it reduced, so I will ask you to trust my
calculations
V = T1*T2*T3*T4
Ú ¿
³ -siné -(cosé)(cosí) -(cosé)(siní) 0 ³
³ ³ = V
³ cosé -(siné)(cosí) -(siné)(siní) 0 ³
³ ³
³ 0 siní -cosí 0 ³
³ ³
³ 0 0 p 1 ³
À Ù
Lets say our original (X,Y,Z,1) were just that, and the point after the
rotation is (Xv,Yv,Zv,1)
(Xv,Yv,Zv,1) = (X,Y,Z,1) * V
Xv = -Xsiné + Ycosé
Yv = -X(cosé)(cosí) - Y(siné)(cosí) + Zsiní
Zv = -X(cosé)(siní) - Y(siné)(siní) - Zcosí + p
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
Some people have had trouble concepts of this implimentation, so I have
another way of setting up the equations. This works off of the straight
X,Y, and Z coordinates too, but uses another angle.
We will define the following variables
Xan = Rotation about the X-Axis
Yan = Rotation about the Y-Axis
Zan = Rotation about the Z-Axis
Rotation about the Y Axis
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
Ú ¿
³ cos(Yan) 0 sin(Yan) ³
³ ³
³ 0 1 0 ³
³ ³
³ -sin(Yan) 0 cos(Yan) ³
À Ù
Rotation about the Z Axis
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
Ú ¿
³ 1 0 0 ³
³ ³
³ 0 cos(Zan) -sin(Zan) ³
³ ³
³ 0 sin(Zan) cos(Zan) ³
À Ù
Rotation about the X Axis
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
Ú ¿
³ cos(Xan) -sin(Xan) 0 ³
³ ³
³ sin(Xan) cos(Xan) 0 ³
³ ³
³ 0 0 1 ³
À Ù
For simplification, lets call sin(Yan) = s1, cos(Xan) = c3,
sin(Zan) = s2, etc
Final Rotation Matrix
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
Ú ¿
³ c1c3 + s1s2s3 -c1s3 + c3s1s2 c2s1 ³
³ ³
³ c2s3 c2c3 -s2 ³
³ ³
³ -c3s1 + c1s2s3 s1s3 + c1c3s2 c1c2 ³
À Ù
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
Xv = x(s1s2s3 + c1c3) + y(c2s3) + z(c1s2s3 - c3s1)
Yv = x(c3s1s2 - c1s3) + y(c2c3) + z(c1c3s2 + s1s3)
Zv = x(c1s2s3 - c3s1) + y(-s2) + z(c1c2)
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
Where Xv,Yv, and Zv are the final rotated points and the little x,y,z are
the original points.
Normal Vectors - The Secret To Shading and Plane Elimination
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
So, now you have the rotation equations... But, how do we make it fast?
Well, one of the best optimizations you can impliment is plane elimination.
It boils down to not displaying the planes that won't be seen. With that
said, here comes more math....
BE A MAN, KNOW YOUR NORMALS
A 'normal' vector is perpendicular to a plane. Imagine the face of a
clock as a plane. Take your right hand and point your thumb toward yourself
and the other end toward the clock. Now curl your fingers in the
counter-clockwise direction. Your thumb is pointing in the direction of the
normal vector. This is called 'The Right Hand Rule' and it is the basis for
figuring the facing of planes.
A plane can be determined with three points, try it. That's the minimum
you need, so that's what we will base our process on. Now if we have a line
segment, we could move it to the origin, maintaining it's direction and
lenght by subtracting the (X,Y,Z) of one of the points from both ends. This
is our definition of a vector. A line segment, starting at the origin and
extending in the direction (X,Y,Z).
Here will be our plane, built from the three points below.
(X1,Y1,Z1) V = (X1-X2, Y1-Y2, Z1-Z2)
(X2,Y2,Z2) W = (X1-X3, Y1-Y3, Z1-Z3)
(X3,Y3,Z3)
So, we have our three points that define a plane. From these points we
create two vectors V and W. Now if you where to use the right hand rule with
these vectors, pointing your fingers in the direction of V and curling them
toward the direction of W, you would have the direction of the Normal vector.
This vector is perpendicular to both vectors, and since we have defined the
plane by these vectors, the normal is perpendicular to the plane as well.
The process of finding the normal vector is called the 'Cross Product' and
it is of this form:
Ú ¿
V*W =³ i k j ³
³ ³
³ X1-X2 Y1-Y2 Z1-Z2 ³
³ ³
³ X1-X3 Y1-Y3 Z1-Z3 ³
À Ù
i = (Y1-Y2)(Z1-Z3) - (Z1-Z2)(Y1-Y3)
-k = (Z1-Z2)(X1-X3) - (X1-X2)(Z1-Z3)
j = (X1-X2)(Y1-Y3) - (Y1-Y2)(X1-X3)
The Normal to the plane is (i,-k,j)
NOTE: V*W *DOESN'T* equal W*V, it will be pointing in the negative direction
To prove that to yourself, lets go back to how I explained it before
We pointed in the direction of V and curled our fingers toward W, the
normal vector in the direction of your thumb. Try it in the
direction of W, toward V. It should be in the opposite direction.
Your normal, still perpendicular to both vectors, but it is negative.
If you use in your program, you will have the planes appearing when
they shouldn't and dissapearing when they are coming into view.
So, now that we have a way to determin the direction of the plane,
how do we hide the plane? If the angle between the view point and the
normal is greater than 90 degrees, don't show it. One quick way that I
always use is to place the view point on an axis. I tipically set the
Z axis to come out of the screen, Y up and X across. Set the view point
to be at a positive point on the Z and then, if that normal vector has Z
greater than zero, I display it, otherwise I skip to the next one.
This also has an application in shading. If you define a light scource,
just like the view point, you find the angle the normal and the light form.
Since you don't usually just want two colors, our 90 degree trick won't work
for you, but by finding this angle, and dividing all of the possible angles
by the number of colors you will allow in the shading, that color can be
assigned to the plane and, presto-chango, it looks like you know what your
doing...
As you do your rotations, just rotate the coordinates of the normal and
that will keep everything updated.
Tips To Speed-Up Your Routines
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
Pre-Calculate as many values as possible
The main limitation you will have is the speed of your math, using
precalculated values like Normals, Sin/Cos charts, and distance from the
origin are all good candidates.
If you can get away with using a math-coprocessor, well...
This will greatly increase the speed of your routine. Unfortunately,
not everyone has one.
Only figure values once
If you multiply (Siné)(Cosé) and will use that same value later, by all
means, keep it and use it then instead of doing the multiplication again.
Another thing to keep in mind
The order of rotations *DOES* make a difference. Try it out and you'll
understand. Also, when you start to use these routines, you'll find
yourself making arrays of points and plane structures.
Counter-Clockwise points
Be sure to list your points for the planes in counter-clockwise order.
If you don't, not all of your planes will display correctly when you
start hiding planes.
And as always, be clever
Just watch out, because when you have clever ideas you can lose a foot.
My brother once had a clever idea to cut his toe nails with an axe and
he lost his foot.
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
Books to look for...
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
Any math book, the topics I covered will be found in:
Normal Vectors - Analytic Geometry
Matrix Operations - Linear Algebra
Sines and Cosines - Trigonometry
The Art of Graphics, by Jim McGregor and Alan Watt
1986 Addison-Wesley Publishers
Read the VLA.NFO file to find out how to contact us.
programming/3dshade.txt
+311
View File
@@ -0,0 +1,311 @@
ÖÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´% VLA Proudly Presents %ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ·
º º
ÓÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄĽ
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
Three Dimensional Shading In Computer Graphics
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
By Lithium /VLA
Hopefully you have read the companion document 3DROTATE.DOC, as this one
will build apon the concepts presented in my attempt to teach some of the
math need to make 3D graphics a reality. This file will cover such important
topics as the Dot Product and how routines are best constructed for real-time
3D rotations and planar shading.
Our Friend, The Dot Product
The Dot Product is a neat relation that will allow you to quickly find
the angle between any two vectors. It's easiest to explain graphicly, so
I will exercise my extended-ASCII keys.
Two Vectors A & B
A (Xa, Ya, Za) ³A³ = û( (Xa)ý + (Ya)ý + (Za)ý )
B (Xb, Yb, Zb) ³B³ = û( (Xb)ý + (Yb)ý + (Zb)ý )
Where Xa, and the others coorispond to some value on their respective Axis's
¿A
/
/
/
/
\ é <-- Angle Theta between vector A and B
\
\
\
ÙB
Cos(é) = Xa * Xb + Ya * Yb + Za * Zb
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
³A³*³B³
Example:
A (1,2,3) ³A³ = û( 1ý + 2ý + 3ý) = û(14) = 3.7417
B (4,5,6) ³b³ = û( 4ý + 5ý + 6ý) = û(77) = 8.7750
Cos(é) = 1 * 4 + 2 * 5 + 3 * 6 = 4 + 10 + 18 = 32 = 0.9746
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ÄÄÄÄÄ
(3.7417)*(8.7750) 32.8334 32.8334
ArcCos (.9746) = 12.9ø
So, your wondering how this revolutionizes you code, huh? Well, remember
our other friend, the Normal vector? You use Normal vectors that define
the directions of everything in our 3D world. Let's say that vector A was
the Normal vector from my plane, and B is a vector that shows the direction
that the light in my scene is pointing. If I do the Dot Product of them,
you will get the angle between them, if that angle is >= 90ø and <= 270ø
then no light falls on the visible surface and it doesn't need to be
displayed.
Also notice, the way the values of the Cosine orient themselves
90ø Cos 000ø = 1
Cos 090ø = 0
³ Cos 180ø = -1
Negative ³ Positive Cos 270ø = 0
³
³
180ø ÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄ 0ø An angle between a light and a plane that
³ is less than 90ø or greater than 270ø will
³ be visible, so you can check if the Cos(é)
Negative ³ Positive is greater than 0 to see if it is visible.
³
³
270ø
How Do You Implement The Code? Easy As ã.
Examples in ASM structures
We will define our points like this
STRUC XYZs
Xpos dd ?
Ypos dd ?
Zpos dd ?
Dist dd ?
ENDS XYZs ;size is 16 bytes
The X,Y,Zpos define a point in 3D space, Dist is the distance from the origin
Dist = û( Xý + Yý + Zý )
Precalculate these values and have them handy in your data area
Our planes should look something like this
STRUC PlaneSt
NumPts db ? ;3 or 4
NormIndex dw ?
PtsIndex dw ?
dw ?
dw ?
dw ?
ENDS PlaneSt
The number of points that in the plane depends on the number your fill
routines can handle you must have at least 3 and more than 6 is not suggested
Then we set up our data like this
MaxPoints = 100
MaxPlanes = 100
PointList XYZs MaxPoints DUP()
PlaneList PlaneSt MaxPlanes DUP()
NormalList XYZs <0,0,0, 10000h> , MaxPlanes DUP()
Non-ASM User Note:
I set up points in a structure that had an X,Y,Z and Distance
value. I set up a plane structure that had the number of points
the index number of the normal vector for that plane and the index
numbers for the points in the plane.
The next lines set up arrays of these points in PointList, and
the number of points was defined as MaxPoints. An array of planes
was created as PlaneList with MaxPlanes as the total number of
plane structures in the array. NormalList is an array of the vectors
that are normal to the planes, one is set up initally (I'll explain
that next) and then one for each possible plane is allocated.
You'll notice that I defined the first Normal and then created space for
the rest of the possible normals. I'll call this first normal, the
Zero Normal. It will have special properties for planes that don't shade
and are never hidden.
Well, before I start telling all the tricks to the writting code, let me
make sure a couple of points are clear.
- In the 3DROTATE.DOC I said that you could set your view point on the
Z-Axis and then figure out if planes were visible by the post-rotation
Normal vectors, if their Z was > 0 then display, if not, don't
That is an easy way to set up the data, and I didn't feel like going
into the Dot Product at the time, so I generalized. So, what if you
don't view your plane from the Z-Axis, the answer is you use the...
Dot Product!
that's right. The angle will be used now to figure wheither or not to
display the plane.
- I have been mentioning lights and view points as vectors that I can
use with the Normal vector from my plane. To work correctly, these
vectors for the lights and view should point in the direction that you
are looking or the direction that the light is pointing, *NOT* a vector
drawn from the origin to the viewer position or light position.
- True Normal vectors only state a direction, and should therefore have
a unit distance of 1. This will have the advantage of simplifying the
math involved to figure you values. Also, for God's sake, pre-compute
your normal, don't do this everytime. Just rotate them when you do your
points and that will update their direction.
If the Normal's have a length of 1 then ³A³*³B³ = 1 * 1 = 1
So:
Cos(é) = Xa * Xb + Ya * Yb + Za * Zb
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
³A³*³B³
Is Reduced To:
Cos(é) = Xa * Xb + Ya * Yb + Za * Zb
We eliminated a multiply and a divide! Pat yourself on the back.
- You ASM users might be wondering why I defined my Zero Normal as:
<0,0,0,10000h> How does 10000h = a length of 1 ?
Well, this is a trick you can do in ASM, instead of using floating point
values that will be slow on computers without math co-processors, we can
use a double word to hold our value. The high word holds the integer
value, and the low word is our decimal. You do all of your computations
with the whole register, but only pull the high word when you go to
display the point. So, with that under consideration, 10000h = 1.00000
Not bad for integers.
- How does the Zero Normal work? Since the X,Y,and Z are all 0, the
Cos(é) = 0, so if you always display when Cos(é) = 0, then that plane
will always be seen.
So, Beyond The Babble... How To Set Up Your Code
Define Data Points, Normals, and Planes
Pre-Calculate as many values as possible
Rotate Points and Normals
Determin Visible Planes With Dot Product
(Save this value if you want to shade)
Sort Visible Planes Back to Front
(Determin Shade From Dot Product)
Clip Plane to fit scene
Draw to the screen
Change Angles
Goto Rotation
A quick way to figure out which color to shade your plane if you are
using the double word values like I described before is to take the
Dot Product result, it will lie between 10000h - 0h if you would like
say 16 shades over the angles, then take that value and shr ,12 that will
give you a value from 0h - 10h (0-16, or 17 colors) if you make 10h into
0fh, add that offset to a gradient in your palette, then you will have
the color to fill your polygon with.
Note also that the Cosine function is weighted toward the extremes.
If you want a smooth palette change as the angles change, your palette
should weight the gradient accordingly.
A useful little relation for depth sorting is to be able to find the
center of a triangle.
E The center C = (D + E + F)/3
^
/ \ Divide each cooridinate by (Xd + Xe + Xf)/3 = Xc
/ C \ and do the same for the Y's and Z's if you
/ \ choose to sort with this method. Then rotate
DÄÄÄÄÄÄÄÄÄF that point and use it to depth sort the planes
Phong and Goraud Shading
Recently, someone asked me about the practiblity of real-time phong and
goraud shading. The technique is common to ray-tracers and requires a great
deal of calculation when working with individual rays cast from each pixel,
but when only using this for each plane, it is possible. This type of shading
involves taking into account the reduced luminousity of light as distance
increases. For each light, you define a falloff value. This value should be
the distance a which the light will be at full intensity. Then at 2*FallOff
you will have 1/2 intensity, 3*FallOff will yeild 1/3 and so on. To implement
this type of shading, you will need to determin the distance from the light
to the center of the plane. If distance < FallOff, then use the normal
intensity. If it is greater, divide the FallOff value by the distance. This
will give you a scalar value that you can multiple by the shading color that
the plane should have. Use that offset and it will be darker since it is
further away from the light source.
However, to determin the distance form the light to each plane, you must
use a Square Root function, these are inherently slow unless you don't care
about accuracy. Also, it would be difficult to notice the use of this
technique unless you have a relatively small FallOff value and your objects
move about in the low intesity boundries.
Well, that's all that I feel like doing tonight, and besides, Star Trek is on!
So, see VLA.NFO for information about contacting myself or any of the other
members of VLA.
Happy Coding!
programming/4dostips.txt
+102
View File
@@ -0,0 +1,102 @@
FFF FFFFFFFFF FFFFFFFF FFFFFFFF
FFF FFF FFFFFFFFFF FFFFFFFFFF FFFFFFFFFF
FFFFFFFFFF FFF FFF FFF FFF FFFFFFF
FFFFFFFFFF FFF FFF FFF FFF FFFFFFF
FFF FFFFFFFFFF FFFFFFFFFF FFFFFFFFFF
FFF FFFFFFFFF FFFFFFFF FFFFFFFF
Specific information........
ððððððððððððððððððððððððððððððððððððððððððððððððððððððððððððððððððððððððððððððð
Edit a 4dos.ini file if you don't have one.
It should look something like this:
Alias = 4096
Environment = 1264
History = 4096
set alias and environment as low as possible, but remember to leave
space for bat files and programs that use the space. A environment
of 100 more that required is good. It is good to set the alias space
as low as possible. Set the history as high as you prefer. I like 4k,
others might like more...
UMBLoad = Yes
UMBEnvironment = Yes
UMBHistory = Yes
UMBAlias = Yes
If you have umb's, specify these 4 lines!
DescriptionMax=200
ALWAYS insert this line! Now you can describe up to 200 characters, which
is more than enough in most cases. The default of 40(?) is almost never
enough...
-------------------------------------------------------------------------------
If you need file-descriptions that is MORE that 200 characters, remove
the attributes on the DESCRIPT.ION file (attrib -h descript.ion)
edit it, and turn the attributes back on (attrib +h descript.ion)
-------------------------------------------------------------------------------
>HistWinHeight=32
If you drive your screen at text resolutions of 50 lines or more, have
the luxury of a bigger history window! (PgUp, PgDn, etc.)
ððððððððððððððððððððððððððððððððððððððððððððððððððððððððððððððððððððððððððððððð
The prompt leaves you many fancy options other that $p$g.....
Mine, help from 4dos and ansi.sys, shows time, date, free memory
(conv, xms, ems), free hd space (all drives), in full colours...
You can find it in the extras\prompt.set, which you will have to load
with SET /R [name of file]. Modify it as you like, bacause it is free to
spread!
ððððððððððððððððððððððððððððððððððððððððððððððððððððððððððððððððððððððððððððððð
With 4dos, you have the luxury of specifying to "md" or "cd" several
directories at once. You can, for instance, md a b c d e f, in which
will make the directories "a" "b", etc....
You can even create a total tree with the "/s" parameter.
This will allow you to create directories more than one level deep at once.
fx: md c:\hi\I\am\here!
will work, even if "c:\hi" does not exist in forehand!
ððððððððððððððððððððððððððððððððððððððððððððððððððððððððððððððððððððððððððððððð
In 4dos, the command-line separator is "^".
That means that you can write several commands on one line, fx.
cls^dir /w /s|list /s^pause^cls
This method can in turn create neat aliases, and if you need examples,
look at MY aliases file! (Included in EXTRAS\aliases.ali !!!!
ððððððððððððððððððððððððððððððððððððððððððððððððððððððððððððððððððððððððððððððð
Be sure to remap your most used commands in dos to 1-key punches,
to maximize performance. See my alias-file for guidance.
Ex: "d" is "dir", etc....
ððððððððððððððððððððððððððððððððððððððððððððððððððððððððððððððððððððððððððððððð
programming/6309.ex
+768
View File
@@ -0,0 +1,768 @@
From: kakugawa@csl.hiroshima-u.ac.jp (Hirotsugu Kakugawa)
Newsgroups: comp.sys.m6809
Subject: A Memo on the Secret Features of 6309
Date: 23 Feb 92 01:10:06 GMT
Organization: Computer Systems Lab., Hiroshima Univ., Japan.
Dear 6309 users
I finished my exam and writing the memo on the seacret features of
6309. In the memo, many fearutes of 6309 are reported but I do not
know ALL of them. In addition to that, my 6309 computer is packed and
kept in my hometown: I cannot tried unclear points.
[
NOTE:
You may have questions about the features written in this meno.
Then, please post your question to comp.sys.m6809; do not send mails
to me. I may not answer your questions since I cannot try the
features now, as I write above. Your questions may be answered by
people who has 6309 based computer.
]
The meno is not complete.
Please try and post the results to comp.sys.m6809!
===*===*===*===*===*===*===*===*===*===*===*===*===*===*===*===
A MEMO ON THE SECRET FEATURES OF 6309
by Hirotsugu Kakugawa, (kakugawa@csl.hiroshima-u.ac.jp)
Computer Systems Lab., Information Engineering Course,
Graduate School of Engineering, Hiroshima Univ., Japan
1. ** INTRODUCTION **
The CPU 6309 by HITACHI has secret features which is not written in
its manual. The purpose of this memo is to introduce them.
The features was originally reported in a magazine,
Oh!FM (1988 Apr.), which was written in Japanese. I did not tried all
of the features reported in the article, but I report the features as
far as I know.
HITACHI says in the manual of 6309 that 6309 is compatible with 6809,
but some OS-9 hackers found that it has secret features.
It has following features:
1. More registers (additional two 8 bit accumulators, 8 bit
register, and a 16 bit register),
2. Two modes (6809 emulation mode and native mode),
3. Reduced execution cycles in native mode,
4. More instructions (16 bit x 16 bit multiplication, 32 bit / 16 bit
division, inter-registers operation, block transfer, bit
manipulating operation which is compatible with 6801 has, etc)
5. Error trap by illegal instruction, zero division.
I substituted 6309 for 6809 in my personal computer, and I changed
OS9/6809 Level II such that the 6309 executes in native mode.
I had to change the interrupt handling routine in the kernel.
I implemented illegal instruction trap; I was really happy because
most bugs are caught by trap handler.
In section 2, new registers are explained. In section 3, two modes of
6309 is explained. In section 4, trapping features of the 6309 is
described. In section 5, new instructions are explained. In section 6,
the instruction tables of the 6309 is shown.
2. ** NEW REGISTERS **
The 6309 has some additional registers that 6809 does not.
1. The E register, the F register
These are 8 bit accumulators. Like the D register is a pair of
the A register and the B register, these two registers can be
used as a 16 bit accumulator. The pair of the E and the F
registers is called the W register.
In addition to that, pair of two 16 bit registers, the D register
and the W register, can be used as a 32 bit accumulator called the
Q register.
2. The V register
This a 16 bit register can be used only by TFR, inter-register
operation, etc. But even if the chip is reseted, contents of
this register does not change. Some people may use this
register to keep constant value (V for value).
3. The MD register
This is a 8 bit register to keep the mode and status of the chip.
The meaning of each bit is as follow.
Read value
bit 7 --- 1 is set if zero division happen.
bit 6 --- 1 is set if illegal instruction is fetched.
Write value
bit 1 --- The mode for FIRQ interrupt.
0 -> the the action for FIRQ is the same as that
of 6809.
1 -> the the action for FIRQ is the same as IRQ.
bit 0 --- The execution mode of 6309.
0 -> the emulation mode.
1 -> the native mode.
(When the chip is reseted, all bits are 0.)
3. ** TWO MODES OF THE 6309 **
The 6309 has two modes, emulation mode and native mode, as described
in the previous section. When the chip is reseted, the initial mode
of 6309 is the emulation mode.
When the 6309 is in the emulation mode, the chip emulates the action
of 6809. But we can use extended registers and extended operations in
this mode. The 6309 executes instructions in the same cycles as 6809
does.
When the 6309 is in the native mode, it executes instructions in
less cycles. And when the chip is interrupted (IRQ, for example),
it pushes extended registers (PC, U, Y, X, DP, W, D, CC, in this
order). If you want to use the 6309, you must rewrite interrupt
handling routine (for example, the entry of system call of OS9).
4. ** TRAPPING **
If the following two events happen, the trap is caused.
1. A illegal instruction is fetched.
2. A number is divided by zero.
The action of the 6309 when a trap is caused is :
1. Pushs the registers on the system stack.
(In the emulation mode, PC, U, Y, X, DP, B, A, CC, in this order
and in the the native mode, PC, U, Y, X, DP, W, B, A, CC in this
order)
2. Reads the trap vector address ($FFF0) and jumps to the vector.
(Note that $FFF0 was reserved by 6809.)
To check the reason of the trap, BITMD instruction is provided. This
instruction is explained in a later section.
5. ** NEW INSTRUCTIONS **
5.1 The Register Addressing Mode
To specify registers in TFR and EXG, the 6809 uses bit pattern of 4 bits.
New registers of the 6309 are specified by bit patterns in TFR and EXG
operations. In addition to that, the bit pattern is also used in
instructions of inter-register operations. We call this bit pattern
used to specify register "register addressing mode".
Bit patterns for new registres are as follows:
W -> 0110,
V -> 0111,
E -> 1110,
F -> 1111.
NOTE: even if the 6309 is in a emulation mode, the action for TFR of 6309
is different from that of the 6809 if new register is specified in
operand. Some hackers found this fact and they guessed that the 6309
has secret registers. At last, they found many features.
5.2 Inter-Register Operations
Operations of 6809 are operations between register and immediate value
or between register and memory. Therefore, we had to store value of
register on memory if opetation between two registers is necessary.
But the 6309 has inter-register operation. Following operations are
provided:
ADDR r0,r1 (ADD of two registers),
ADCR r0,r1 (ADC of two registers),
SUBR r0,r1 (SUB of two registers),
SBCR r0,r1 (SBC of two registers),
ANDR r0,r1 (AND of two registers),
ORR r0,r1 (OR of two registers),
EORR r0,r1 (EOR of two registers),
CMPR r0,r1 (CMP of two registers).
The register addressing mode is used to specify two registers.
(I do not remember exactrlly but the result is stored in r0, the
register of the first operand. Please try and find the behavior of
these instructions.)
5.3 Block Transfer
Block transfer instructions are provided such as Z80 has.
The TFM instruction requires source address and destination address
and block size as its argument. One or two 16 bit registers (X/Y/U/S)
are used to specify source and destination addresses. Block size to be
transfered is specified by the W register.
Four style is provided:
TFR r0+,r1+ (transfered in address is increasing order),
TFR r0-,r1- (transfered in address is decreasing order),
TFR r0+,r1 (poured into the same address, I/O port for instance),
TFR r0,r1+ (read from the same address, I/O port for instance).
I tried this instructions but I do not remember exactly.
Operand registers are pointers of source/destination addresses (,maybe).
Please try and find the behavior of these instructions.
5.4 Multiplication And Division
The 6309 has MULD instruction which performs a 16bit x 16bit multipli-
cation. We can use various addressing modes (immediate, direct, indexed,
extend) The result is stored in the Q register.
Division instructions are also provided. The 6309 has two division
instructions: 16bit / 8bit, 32bit / 16bit divisions.
Various addressing modes (immediate, direct, indexed, extend) can be
used.
(Note:I forget where its result is stored. I tried these instructions.
I remember that modulo is also computed. The quotient and the modulo
are stored D and W resp., maybe. I'm not sure, sorry.)
5.5 Bit Manipulation / Bit Transfer
The 6309 provides AIM, OIM, EIM, TIM instructions which are compatible
with instructions of the Hitachi 6301 CPU. Read the manual of the 6301
to understand thses instructions.
Instructions called BAND, BOR, BEOR, BIAND, BIOR, BIEOR, LDBT, STBT
are provided. Behavior of thses instructions is that a logical
operation is performed for n-th bit of a data in a memory (only direct
mode is allowed) and m-th bit of a register, then the result is stored
in the register. The format of the object is :
$11, x, (post byte), (operand).
The say that the post byte takes strange format. I do not understand
these instructions. Sorry, please try.
5.6 Misc
To change modes ofthe 6309, we have to set the 0th bit of the MD
register. To do this, the LDMD instruction is provided:
LDMD #n (where #n is a immediate n bit data)
When trap is caused, it is necessary to examine the reason of the
trap. The BITMD instruction can be used for this purpose:
BITMD #n (where #n is a immediate n bit data)
The contents of the MD register and #n is ANDed, and changes the CC
register (,maybe, I do not remember exactly).
Once this instruction is executed, the 6th and the 7th bit of the
MD register is CLEARED. Therefore, we can't examine the MD register.
Pushing and poping the W registers on/from stack:
PSHSW (Push the W register on the system stack),
PULSW (Pop the W register from the system stack),
PSHUW (Push the W register on the user stack),
PULUW (Pop the W register from the user stack).
6. ** INSTRUCTION TABLES **
In this section, only additional instructions of the 6309 are
shown.
How to read the following table :
The first column : + ... New instruction of 6309
(blank) ... a instruction of 6089/6309,
--Op-- : Operational code,
--Mnem-- : Mnemonic,
--Mode-- : Addressing mode,
--Cyc-- : Execution Cycles (Parenthesized value is the value
in the native mode),
--Len-- : Length of the instruction,
6.1 Instructions without pre-byte
--Op-- --Mnem-- --Mode-- --Cyc-- --Len --
$00 NEG DIRECT 6 (5) 2
+ $01 OIM DIRECT 6 3
+ $02 AIM DIRECT 6 3
$03 COM DIRECT 6 (5) 2
$04 LSR DIRECT 6 (5) 2
+ $05 EIM DIRECT 6 3
$06 ROR DIRECT 6 (5) 2
$07 ASR DIRECT 6 (5) 2
$08 ASL/LSL DIRECT 6 (5) 2
$09 ROL DIRECT 6 (5) 2
$0A DEC DIRECT 6 (5) 2
+ $0B TIM DIRECT 6 3
$0C INC DIRECT 6 (5) 2
$0D TST DIRECT 6 (4) 2
$0E JMP DIRECT 3 (2) 2
$0F CLR DIRECT 6 (5) 2
$10 (PREBYTE)
$11 (PREBYTE)
$12 NOP IMP 2 (1) 1
$13 SYNC IMP 2 (1) 1
+ $14 SEXW IMP 4 1
$16 LBRA REL 5 (4) 3
$17 LBSR REL 9 (7) 3
$19 DAA IMP 2 (1) 1
$1A ORCC IMMED 3 (2) 2
$1C ANDCC IMMED 3 2
$1D SEX IMP 2 (1) 1
$1E EXG REGIST 8 (5) 2
$1F TFR REGIST 6 (4) 2
$20 BRA REL 3 2
$21 BRN REL 3 2
$22 BHI REL 3 2
$23 BLS REL 3 2
$24 BHS/BCC REL 3 2
$25 BLO/BCS REL 3 2
$26 BNE REL 3 2
$27 BEQ REL 3 2
$28 BVC REL 3 2
$29 BVS REL 3 2
$2A BPL REL 3 2
$2B BMI REL 3 2
$2C BGE REL 3 2
$2D BLT REL 3 2
$2E BGT REL 3 2
$2F BLE REL 3 2
$30 LEAX REL 4+ 2+
$31 LEAY REL 4+ 2+
$32 LEAS REL 4+ 2+
$33 LEAU REL 4+ 2+
$34 PSHS REGIST 5+ (4+) 2
$35 PULS REGIST 5+ (4+) 2
$36 PSHU REGIST 5+ (4+) 2
$37 PULU REGIST 5+ (4+) 2
$39 RTS 5 (4) 1
$3A ABX IMP 3 (1) 1
$3B RTI IMP 6/15 (17) 1
$3C CWAI IMP 22 (20) 2
$3D MUL IMP 11 (10) 1
$3F SWI IMP 19 (21) 1
$40 NEGA IMP 2 (1) 1
$43 COMA IMP 2 (1) 1
$44 LSRA IMP 2 (1) 1
$46 RORA IMP 2 (1) 1
$47 ASRA IMP 2 (1) 1
$48 ASLA/LSLA IMP 2 (1) 1
$49 ROLA IMP 2 (1) 1
$4A DECA IMP 2 (1) 1
$4C INCA IMP 2 (1) 1
$4D TSTA IMP 2 (1) 1
$4F CLRA IMP 2 (1) 1
$50 NEGB IM P 2 (1) 1
$53 COMB IMP 2 (1) 1
$54 LSRB IMP 2 (1) 1
$56 RORB IMP 2 (1) 1
$57 ASRB IMP 2 (1) 1
$58 ASLB/LSLB IMP 2 (1) 1
$59 ROLB IMP 2 (1) 1
$5A ECB IMP 2 (1) 1
$5C NCB IMP 2 (1) 1
$5D STB IMP 2 (1) 1
$5F LRB IMP 2 (1) 1
$60 NEG INDEXD 6+ 2+
+ $61 OIM INDEXD 7+ 3+
+ $62 AIM INDEXD 7 3+
$63 COM INDEXD 6+ 2+
$64 LSR INDEXD 6+ 2+
+ $65 EIM INDEXD 7+ 3+
$66 ROR INDEXD 6+ 2+
$67 ASR INDEXD 6+ 2+
$68 ASL/LSL INDEXD 6+ 2+
$69 ROL INDEXD 6+ 2+
$6A DEC INDEXD 6+ 2+
+ $6B TIM INDEXD 7+ 3+
$6C INC INDEXD 6+ 2+
$6D TST INDEXD 6+ (5+) 2+
$6E JMP INDEXD 3+ 2+
$6F CLR INDEXD 6+ 2+
$70 NEG EXTEND 7 (6) 3
+ $71 OIM EXTEND 7 4
+ $72 AIM EXTEND 7 4
$73 COM EXTEND 7 (6) 3
$74 LSR EXTEND 7 (6) 3
+ $75 EIM EXTEND 7 4
$76 ROR EXTEND 7 (6) 3
$77 ASR EXTEND 7 (6) 3
$78 ASL/LSL EXTEND 7 (6) 3
$79 ROL EXTEND 7 (6) 3
$7A DEC EXTEND 7 (6) 3
+ $7B TIM EXTEND 5 4
$7C INC EXTEND 7 (6) 3
$7D TST EXTEND 7 (5) 3
$7E JMP EXTEND 4 (3) 3
$7F CLR EXTEND 7 (6) 3
$80 SUBA IMMED 2 2
$81 CMPA IMMED 2 2
$82 SBCA IMMED 2 2
$83 SUBD IMMED 4 (3) 3
$84 ANDA IMMED 2 2
$85 BITA IMMED 2 2
$86 LDA IMMED 2 2
$88 EORA IMMED 2 2
$89 ADCA IMMED 2 2
$8A ORA IMMED 2 2
$8B ADDA IMMED 2 2
$8C CMPX IMMED 4 (3) 3
$8D BSR IMMED 7 (6) 2
$8E LDX IMMED 3 3
$90 SUBA DIRECT 4 (3) 2
$91 CMPA DIRECT 4 (3) 2
$92 SBCA DIRECT 4 (3) 2
$93 SUBD DIRECT 6 (4) 3
$94 ANDA DIRECT 4 (3) 2
$95 BITA DIRECT 4 (3) 2
$96 LDA DIRECT 4 (3) 2
$97 STA DIRECT 4 (3) 2
$98 EORA DIRECT 4 (3) 2
$99 ADCA DIRECT 4 (3) 2
$9A ORA DIRECT 4 (3) 2
$9B ADDA DIRECT 4 (3) 2
$9C CMPX DIRECT 6 (4) 2
$9D JSR DIRECT 7 (6) 2
$9E LDX DIRECT 5 (4) 2
$9F STX DIRECT 5 (4) 2
$A0 SUBA INDEXD 4+ 2+
$A1 CMPA INDEXD 4+ 2+
$A2 SBCA INDEXD 4+ 2+
$A3 SUBD INDEXD 6+ (5+) 2+
$A4 ANDA INDEXD 4+ 2+
$A5 BITA INDEXD 4+ 2+
$A6 LDA INDEXD 4+ 2+
$A7 STA INDEXD 4+ 2+
$A8 EORA INDEXD 4+ 2+
$A9 ADCA INDEXD 4+ 2+
$AA ORA INDEXD 4+ 2+
$AB ADDA INDEXD 4+ 2+
$AC CMPX INDEXD 6+ (5+) 2+
$AD JSR INDEXD 7+ (6+) 2+
$AE LDX INDEXD 5+ 2+
$AF STX INDEXD 5+ 2+
$B0 SUBA EXTEND 5 (4) 3
$B1 CMPA EXTEND 5 (4) 3
$B2 SBCA EXTEND 5 (4) 3
$B3 SUBD EXTEND 7 (5) 3
$B4 ANDA EXTEND 5 (4) 3
$B5 BITA EXTEND 5 (4) 3
$B6 LDA EXTEND 5 (4) 3
$B7 STA EXTEND 5 (4) 3
$B8 EORA EXTEND 5 (4) 3
$B9 ADCA EXTEND 5 (4) 3
$BA ORA EXTEND 5 (4) 3
$BB ADDA EXTEND 5 (4) 3
$BC CMPX EXTEND 7 (5) 3
$BD JSR EXTEND 8 (7) 3
$BE LDX EXTEND 6 (5) 3
$BF STX EXTEND 6 (5) 3
$C0 SUBB IMMED 2 2
$C1 CMPB IMMED 2 2
$C2 SBCB IMMED 2 2
$C3 ADDD IMMED 4 (3) 3
$C4 ANDB IMMED 2 2
$C5 BITB IMMED 2 2
$C6 LDB IMMED 2 2
$C8 EORB IMMED 2 2
$C9 ADCB IMMED 2 2
$CA ORB IMMED 2 2
$CB ADDB IMMED 2 2
$CC LDD IMMED 3 3
+ $CD LDQ IMMED 5 5
$CE LDU IMMED 3 3
$D0 SUBB DIRECT 4 (3) 2
$D1 CMPB DIRECT 4 (3) 2
$D2 SBCB DIRECT 4 (3) 2
$D3 ADDD DIRECT 6 (4) 3
$D4 ANDB DIRECT 4 (3) 2
$D5 BITB DIRECT 4 (3) 2
$D6 LDB DIRECT 4 (3) 2
$D7 STB DIRECT 4 (3) 2
$D8 EORB DIRECT 4 (3) 2
$D9 ADCB DIRECT 4 (3) 2
$DA ORB DIRECT 4 (3) 2
$DB ADDB DIRECT 4 (3) 2
$DC LDD DIRECT 5 (4) 2
$DD STD DIRECT 5 (4) 2
$DE LDU DIRECT 5 (4) 2
$DF STU DIRECT 5 (4) 2
$E0 SUBB INDEXD 4+ 2+
$E1 CMPB INDEXD 4+ 2+
$E2 SBCB INDEXD 4+ 2+
$E3 ADDD INDEXD 6+ (5+) 2+
$E4 ANDB INDEXD 4+ 2+
$E5 BITB INDEXD 4+ 2+
$E6 LDB INDEXD 4+ 2+
$E7 STB INDEXD 4+ 2+
$E8 EORB INDEXD 4+ 2+
$E9 ADCB INDEXD 4+ 2+
$EA ORB INDEXD 4+ 2+
$EB ADDB INDEXD 4+ 2+
$EC LDD INDEXD 5+ 2+
$ED STD INDEXD 5+ 2+
$EE LDU INDEXD 5+ 2+
$EF STU INDEXD 5+ 2+
$F0 SUBB EXTEND 5 (4) 3
$F1 CMPB EXTEND 5 (4) 3
$F2 SBCB EXTEND 5 (4) 3
$F3 ADDD EXTEND 7 (5) 3
$F4 ANDB EXTEND 5 (4) 3
$F5 BITB EXTEND 5 (4) 3
$F6 LDB EXTEND 5 (4) 3
$F7 STB EXTEND 5 (4) 3
$F8 EORB EXTEND 5 (4) 3
$F9 ADCB EXTEND 5 (4) 3
$FA ORB EXTEND 5 (4) 3
$FB ADDB EXTEND 5 (4) 3
$FC LDD EXTEND 6 (5) 3
$FD STD EXTEND 6 (5) 3
$FE LDU EXTEND 6 (5) 3
$FF STU EXTEND 6 (5) 3
6.2 Instructions whose pre-byte is $10
--Op-- --Mnem-- --Mode-- --Cyc-- --Len --
$21 LBRN REL 5 4
$22 LBHI REL 5/6 (5) 4
$23 LBLS REL 5/6 (5) 4
$24 LBHS/LBCC REL 5/6 (5) 4
$25 LBLO/LBCS REL 5/6 (5) 4
$26 LBNE REL 5/6 (5) 4
$27 LBEQ REL 5/6 (5) 4
$28 LBVC REL 5/6 (5) 4
$29 LBVS REL 5/6 (5) 4
$2A LBPL REL 5/6 (5) 4
$2B LBMI REL 5/6 (5) 4
$2C LBGE REL 5/6 (5) 4
$2D LBLT REL 5/6 (5) 4
$2E LBGT REL 5/6 (5) 4
$2F LBLE REL 5/6 (5) 4
+ $30 ADDR REGIST 4 3
+ $31 ADCR REGIST 4 3
+ $32 SUBR REGIST 4 3
+ $33 SBCR REGIST 4 3
+ $34 ANDR REGIST 4 3
+ $35 ORR REGIST 4 3
+ $36 EORR REGIST 4 3
+ $37 CMPR REGIST 4 3
+ $38 PSHSW IMP 6 2
+ $39 PULSW IMP 6 2
+ $3A PSHUW IMP 6 2
+ $3B PULUW IMP 6 2
$3F SWI2 IMP 20 (22) 2
+ $40 NEGD IMP 3 (2) 2
+ $43 COMD IMP 3 (2) 2
+ $44 LSRD IMP 3 (2) 2
+ $46 RORD IMP 3 (2) 2
+ $47 ASRD IMP 3 (2) 2
+ $48 ASLD IMP 3 (2) 2
+ $49 ROLD IMP 3 (2) 2
+ $4A DECD IMP 3 (2) 2
+ $4C INCD IMP 3 (2) 2
+ $4D TSTD IMP 3 (2) 2
+ $4F CLRD IMP 3 (2) 2
+ $53 COMW IMP 3 (2) 2
+ $54 LSRW IMP 3 (2) 2
+ $56 RORW IMP 3 (2) 2
+ $59 ROLW IMP 3 (2) 2
+ $5A DECW IMP 3 (2) 2
+ $5C INCW IMP 3 (2) 2
+ $5D TSTW IMP 3 (2) 2
+ $5F CLRW IMP 3 (2) 2
+ $80 SUBW IMMED 5 (4) 4
+ $81 CMPW IMMED 5 (4) 4
+ $82 SBCD IMMED 5 (4) 4
$83 CMPD IMMED 5 (4) 4
+ $84 ANDD IMMED 5 (4) 4
+ $85 BITD IMMED 5 (4) 4
+ $86 LDW IMMED 4 4
+ $88 EORD IMMED 5 (4) 4
+ $89 ADCD IMMED 5 (4) 4
+ $8A ORD IMMED 5 (4) 4
+ $8B ADDW IMMED 5 (4) 4
$8C CMPY IMMED 5 (4) 4
$8E LDY IMMED 4 4
+ $90 SUBW DIRECT 7 (5) 3
+ $91 CMPW DIRECT 7 (5) 3
+ $92 SBCD DIRECT 7 (5) 3
$93 CMPD DIRECT 7 (5) 3
+ $94 ANDD DIRECT 7 (5) 3
+ $95 BITD DIRECT 7 (5) 3
+ $96 LDW DIRECT 6 (5) 3
+ $97 STW DIRECT 6 (5) 3
+ $98 EORD DIRECT 7 (5) 3
+ $99 ADCD DIRECT 7 (5) 3
+ $9A ORD DIRECT 7 (5) 3
+ $9B ADDW DIRECT 7 (5) 3
$9C CMPY DIRECT 7 (5) 3
$9E LDY DIRECT 6 (5) 3
$9F STY DIRECT 6 (5) 3
+ $A0 SUBW INDEXD 7+ (6+) 3+
+ $A1 CMPW INDEXD 7+ (6+) 3+
+ $A2 SBCD INDEXD 7+ (6+) 3+
$A3 CMPD INDEXD 7+ (6+) 3+
+ $A4 ANDD INDEXD 7+ (6+) 3+
+ $A5 BITD INDEXD 7+ (6+) 3+
+ $A6 LDW INDEXD 6+ 3+
+ $A7 STW INDEXD 6+ 3+
+ $A8 EORD INDEXD 7+ (6+) 3+
+ $A9 ADCD INDEXD 7+ (6+) 3+
+ $AA ORD INDEXD 7+ (6+) 3+
+ $AB ADDW INDEXD 7+ (6+) 3+
$AC CMPY INDEXD 7+ (6+) 3+
$AE LDY INDEXD 6+ 3+
$AF STY INDEXD 6+ 3+
+ $B0 SUBW EXTEND 8 (6) 4
+ $B1 CMPW EXTEND 8 (6) 4
+ $B2 SBCD EXTEND 8 (6) 4
$B3 CMPD EXTEND 8 (6) 4
+ $B4 ANDD EXTEND 8 (6) 4
+ $B5 BITD EXTEND 8 (6) 4
+ $B6 LDW EXTEND 7 (6) 4
+ $B7 STW EXTEND 7 (6) 4
+ $B8 EORD EXTEND 8 (6) 4
+ $B9 ADCD EXTEND 8 (6) 4
+ $BA ORD EXTEND 8 (6) 4
+ $BB ADDW EXTEND 8 (6) 4
$BC CMPY EXTEND 8 (6) 4
$BE LDY EXTEND 7 (6) 4
$BF STY EXTEND 7 (6) 4
$CE LDS IMMED 4 4
+ $DC LDQ DIRECT 8 (7) 3
+ $DD STQ DIRECT 8 (7) 3
$DE LDS DIRECT 6 (5) 3
$DF STS DIRECT 6 (5) 3
+ $EC LDQ INDEXD 8+ 3+
+ $ED STQ INDEXD 8+ 3+
$EE LDS INDEXD 6+ 3+
$EF STS INDEXD 6+ 3+
+ $FC LDQ EXTEND 9 (8) 4
+ $FD STQ EXTEND 9 (8) 4
$FE LDS EXTEND 7 (6) 4
$FF STS EXTEND 7 (6) 4
6.3 Instructions whose pre-byte is $11
--Op-- --Mnem-- --Mode-- --Cyc-- --Len --
+ $30 BAND 7 (6) 4
+ $31 BIAND 7 (6) 4
+ $32 BOR 7 (6) 4
+ $33 BIOR 7 (6) 4
+ $34 NEOR 7 (6) 4
+ $35 BIEOR 7 (6) 4
+ $36 LDBT 7 (6) 4
+ $37 STBT 8 (7) 4
+ $38 TFR (r1+,r2+) 6+3n 3
+ $39 TFR (r1-,r2-) 6+3n 3
+ $3A TFR (r1+,r) 6+3n 3
+ $3B TFR (r1,r2+) 6+3n 3
+ $3C BITMD IMMED 4 3
+ $3D LDMD IMMED 5 3
$3F SWI2 IMP 20 (22) 2
+ $43 COME IMP 3 (2) 2
+ $4A DECE IMP 3 (2) 2
+ $4C INCE IMP 3 (2) 2
+ $4D TSTE IMP 3 (2) 2
+ $4F CLRE IMP 3 (2) 2
+ $53 COMF IMP 3 (2) 2
+ $5A DECF IMP 3 (2) 2
+ $5C INCF IMP 3 (2) 2
+ $5D TSTF IMP 3 (2) 2
+ $5F CLRF IMP 3 (2) 2
+ $80 SUBE IMMED 3 3
+ $81 CMPE IMMED 3 3
$83 CMPU IMMED 5 (4) 4
+ $86 LDE IMMED 3 3
+ $8B ADDE IMMED 3 3
$8C CMPS IMMED 5 (4) 4
+ $8D DIVD IMMED 25 3
+ $8E DIVQ IMMED 34 4
+ $8F MULD IMMED 28 4
+ $90 SUBE DIRECT 5 (4) 3
+ $91 CMPE DIRECT 5 (4) 3
$93 CMPU DIRECT 7 (5) 3
+ $96 LDE DIRECT 5 (4) 3
+ $97 STE DIRECT 5 (4) 3
+ $9B ADDE DIRECT 5 (4) 3
$9C CMPS DIRECT 7 (5) 3
+ $9D DIVD DIRECT 27 (26) 3
+ $9E DIVQ DIRECT 36 (35) 3
+ $9F MULD DIRECT 30 (29) 3
+ $A0 SUBE INDEXD 5+ 3+
+ $A1 CMPE INDEXD 5+ 3+
$A3 CMPU INDEXD 7+ (6+) 3+
+ $A6 LDE INDEXD 5+ 3+
+ $A7 STE INDEXD 5+ 3+
+ $AB ADDE INDEXD 5+ 3+
$AC CMPS INDEXD 7+ (6+) 3+
+ $AD DIVD INDEXD 27+ 3+
+ $AE DIVQ INDEXD 36+ 3+
+ $AF MULD INDEXD 30+ 3+
+ $B0 SUBE EXTEND 6 (5) 4
+ $B1 CMPE EXTEND 6 (5) 4
$B3 CMPU EXTEND 8 (6) 4
+ $B6 LDE EXTEND 6 (5) 4
+ $B7 STE EXTEND 6 (5) 4
+ $BB ADDE EXTEND 6 (5) 4
$BC CMPS EXTEND 8 (6) 4
+ $BD DIVD EXTEND 28 (27) 4
+ $BE DIVQ EXTEND 37 (36) 4
+ $BF MULD EXTEND 31 (30) 4
+ $C0 SUBF IMMED 3 3
+ $C1 CMPF IMMED 3 3
+ $C6 LDF IMMED 3 3
+ $CB ADDF IMMED 3 3
+ $D0 SUBF DIRECT 5 (4) 3
+ $D1 CMPF DIRECT 5 (4) 3
+ $D6 LDF DIRECT 5 (4) 3
+ $D7 STF DIRECT 5 (4) 3
+ $DB ADDF DIRECT 5 (4) 3
+ $E0 SUBF INDEXD 5+ 3+
+ $E1 CMPF INDEXD 5+ 3+
+ $E6 LDF INDEXD 5+ 3+
+ $E7 STF INDEXD 5+ 3+
+ $EB ADDF INDEXD 5+ 3+
+ $F0 SUBF EXTEND 6 (5) 4
+ $F1 CMPF EXTEND 6 (5) 4
+ $F6 LDF EXTEND 6 (5) 4
+ $F7 STF EXTEND 6 (5) 4
+ $FB ADDF EXTEND 6 (5) 4
<EOF>
===*===*===*===*===*===*===*===*===*===*===*===*===*===*===*===
--
Hirotsugu Kakugawa
Computer Systems Lab., Information Engineering Course,
Graduate School of Engineering, Hiroshima Univ., Japan
programming/6502.txt
+1738
View File
File diff suppressed because it is too large Load Diff
programming/6502bugs.txt
+80
View File
@@ -0,0 +1,80 @@
-------------------------------------------------------------------------------
I found this document somewhere on a gopher archive in an Apple2's
programming directory and I think this could be very useful information
for example for emulator writers :)
2-Nov-1994 Ivo van Poorten <ipoorten=www@cs.vu.nl>
-------------------------------------------------------------------------------
With all the books on 6502 programming, and all the years that the 6502 has
been around and popular, you'd think that any quirks would have been well
documented by now. But nooooo!
So... for those of you involved in assembler or machine-language programming,
here are some 6502 booby-traps -- those marked with * are supposedly fixed
in the CMOS parts such as 65C02 and 65C102 (but not the C-64's 6510).
---------
o Return address pushed on the stack by JSR is one less than actual next
instruction. RTS increments PC after popping. RTI doesn't.
o The status bits pushed on the stack by PHP have the breakpoint bit set.
o *The D (decimal mode) flag is not defined after RESET.
o *The D (decimal mode) flag is not cleared by interrupts.
o *The ADC and SBC instructions don't set N,V, and Z status bits if decimal
mode is on. C status is set correctly.
o *An indirect JMP (xxFF) will fail because the MSB will be fetched from
address xx00 instead of page xx+1.
o *If an interrupt occurs on a BRK instruction, the breakpoint is ignored.
o *The ROR instruction didn't exist in the very earliest (pre-'77) chips.
o *Undefined op-codes do strange things, some lock up the CPU.
Unlike most microprocessors, the 6502 does not make memory accesses on an
"as needed" basis. It always does a fetch or store on every single clock
cycle. There are a few cases, though, where there isn't anything to be
fetched or stored, and a "garbage" fetch or store occurs. This is mainly
of importance with the memory-mapped I/O devices:
o *When adding a carry to the MSB of an address, a fetch occurs at a garbage
address. The CMOS chips refetch the last byte of the instruction.
o *When doing a fetch-modify-store instruction (INC, DEC, ASL, LSR, ROL,
ROR) garbage is stored into the location during the "modify" cycle...
followed by the "real" store cycle which stores the correct data. The
CMOS chips do a second fetch instead of a garbage store.
These aren't really "bugs", but there are some instructions that just seem
like they ought to be there, but aren't:
o *INC A and DEC A.
o *BRA relative. Unconditional branch.
o *BIT #immediate. The CMOS chips also have BIT absolute,X and
BIT zeropage,X.
o STX absolute,Y and STY absolute,X. How come LDX and LDY can use these
addressing modes, but the matching store instructions can't?
o SEV. Set overflow bit. Probably not really useful, but you can set and
clear all of the other status bits, and there *is* a CLV.
o Personally, I'd also like to have "Clear A" and "Test A" instructions.
These would be twice as fast and half as big as LDA #0 and CMP #0.
Ironically, the CMOS chips have an STZ (Store Zero) instruction which
can clear a memory location, but still can't clear the Accumulator.
o I'd also like to have BSR relative. A subroutine call that's relocatable.
*Fixed in the CMOS versions (65C02, 65C102, etc.)
-------------------------------------------------------------------------------
programming/6502guid.txt
+925
View File
@@ -0,0 +1,925 @@
Assembly In One Step
RTK, last update: 23-Jul-97
A brief guide to programming the 6502 in assembly language. It will
introduce the 6502 architecture, addressing modes, and instruction set. No
prior assembly language programming is assumed, however it is assumed that
you are somewhat familiar with hexadecimal numbers. Programming examples
are given at the end. Much of this material comes from 6502 Software Design
by Leo Scanlon, Blacksburg, 1980.
------------------------------------------------------------------------
The 6502 Architecture
---------------------
The 6502 is an 8-bit microprocessor that follows the memory oriented
design philosophy of the Motorola 6800. Several engineers left
Motorola and formed MOS Technology which introduced the 6502 in 1975.
The 6502 gained in popularity because of it's low price and became the
heart of several early personal computers including the Apple II,
Commodore 64, and Atari 400 and 800.
Simplicity is key
-----------------
The 6502 handles data in its registers, each of which holds one byte
(8-bits) of data. There are a total of three general use and two special
purpose registers:
accumulator (A) - Handles all arithmetic and logic. The real heart
of the system.
X and Y - General purpose registers with limited abilities.
S - Stack pointer.
P - Processor status. Holds the result of tests
and flags.
Stack Pointer
-------------
When the microprocessor executes a JSR (Jump to SubRoutine)
instruction it needs to know where to return when finished. The 6502
keeps this information in low memory from $0100 to $01FF and uses the
stack pointer as an offset. The stack grows down from $01FF and makes
it possible to nest subroutines up to 128 levels deep. Not a problem
in most cases.
Processor Status
----------------
The processor status register is not directly accessible by any 6502
instruction. Instead, there exist numerous instructions that test the
bits of the processor status register. The flags within the register
are:
bit -> 7 0
+---+---+---+---+---+---+---+---+
| N | V | | B | D | I | Z | C | <-- flag, 0/1 = reset/set
+---+---+---+---+---+---+---+---+
N = NEGATIVE. Set if bit 7 of the accumulator is set.
V = OVERFLOW. Set if the addition of two like-signed numbers or the
subtraction of two unlike-signed numbers produces a result
greater than +127 or less than -128.
B = BRK COMMAND. Set if an interrupt caused by a BRK, reset if
caused by an external interrupt.
D = DECIMAL MODE. Set if decimal mode active.
I = IRQ DISABLE. Set if maskable interrupts are disabled.
Z = ZERO. Set if the result of the last operation (load/inc/dec/
add/sub) was zero.
C = CARRY. Set if the add produced a carry, or if the subtraction
produced a borrow. Also holds bits after a logical shift.
Accumulator
-----------
The majority of the 6502's business makes use of the accumulator. All
addition and subtraction is done in the accumulator. It also handles
the majority of the logical comparisons (is A > B ?) and logical bit
shifts.
X and Y
-------
These are index registers often used to hold offsets to memory
locations. They can also be used for holding needed values. Much of
their use lies in supporting some of the addressing modes.
Addressing Modes
----------------
The 6502 has 13 addressing modes, or ways of accessing memory. The 65C02
introduces two additional modes.
They are:
+---------------------+--------------------------+
| mode | assembler format |
+=====================+==========================+
| Immediate | #aa |
| Absolute | aaaa |
| Zero Page | aa | Note:
| Implied | |
| Indirect Absolute | (aaaa) | aa = 2 hex digits
| Absolute Indexed,X | aaaa,X | as $FF
| Absolute Indexed,Y | aaaa,Y |
| Zero Page Indexed,X | aa,X | aaaa = 4 hex
| Zero Page Indexed,Y | aa,Y | digits as
| Indexed Indirect | (aa,X) | $FFFF
| Indirect Indexed | (aa),Y |
| Relative | aaaa | Can also be
| Accumulator | A | assembler labels
+---------------------+--------------------------+
(Table 2-3. _6502 Software Design_, Scanlon, 1980)
Immediate Addressing
--------------------
The value given is a number to be used immediately by the
instruction. For example, LDA #$99 loads the value $99 into the
accumulator.
Absolute Addressing
-------------------
The value given is the address (16-bits) of a memory location that
contains the 8-bit value to be used. For example, STA $3E32 stores
the present value of the accumulator in memory location $3E32.
Zero Page Addressing
--------------------
The first 256 memory locations ($0000-00FF) are called "zero page". The
next 256 instructions ($0100-01FF) are page 1, etc. Instructions
making use of the zero page save memory by not using an extra $00 to
indicate the high part of the address. For example,
LDA $0023 -- works but uses an extra byte
LDA $23 -- the zero page address
Implied Addressing
------------------
Many instructions are only one byte in length and do not reference
memory. These are said to be using implied addressing. For example,
CLC -- Clear the carry flag
DEX -- Decrement the X register by one
TYA -- Transfer the Y register to the accumulator
Indirect Absolute Addressing
----------------------------
Only used by JMP (JuMP). It takes the given address and uses it as a
pointer to the low part of a 16-bit address in memory, then jumps to
that address. For example,
JMP ($2345) -- jump to the address in $2345 low and $2346 high
So if $2345 contains $EA and $2346 contains $12 then the next
instruction executed is the one stored at $12EA. Remember, the
6502 puts its addresses in low/high format.
Absolute Indexed Addressing
---------------------------
The final address is found by taking the given address as a base and
adding the current value of the X or Y register to it as an offset. So,
LDA $F453,X where X contains 3
Load the accumulator with the contents of address $F453 + 3 = $F456.
Zero Page Indexed Addressing
----------------------------
Same as Absolute Indexed but the given address is in the zero page
thereby saving a byte of memory.
Indexed Indirect Addressing
---------------------------
Find the 16-bit address starting at the given location plus the
current X register. The value is the contents of that address. For
example,
LDA ($B4,X) where X contains 6
gives an address of $B4 + 6 = $BA. If $BA and $BB contain $12 and
$EE respectively, then the final address is $EE12. The value at
location $EE12 is put in the accumulator.
Indirect Indexed Addressing
---------------------------
Find the 16-bit address contained in the given location ( and the one
following). Add to that address the contents of the Y register.
Fetch the value stored at that address. For example,
LDA ($B4),Y where Y contains 6
If $B4 contains $EE and $B5 contains $12 then the value at memory
location $12EE + Y (6) = $12F4 is fetched and put in the accumulator.
Relative Addressing
-------------------
The 6502 branch instructions use relative addressing. The next byte
is a signed offset from the current address, and the net sum is the
address of the next instruction executed. For example,
BNE $7F (branch on zero flag reset)
will add 127 to the current program counter (address to execute) and
start executing the instruction at that address. SImilarly,
BEQ $F9 (branch on zero flag set)
will add a -7 to the current program counter and start execution at
the new program counter address.
Remember, if one treats the highest bit (bit 7) of a byte as a sign (0
= positive, 1 = negative) then it is possible to have numbers in the
range -128 ($80) to +127 (7F). So, if the high bit is set, i.e. the
number is > $7F, it is a negative branch. How far is the branch? If
the value is < $80 (positive) it is simply that many bytes. If the
value is > $7F (negative) then it is the 2's compliment of the given
value in the negative direction.
2's compilment
--------------
The 2's compilment of a number is found by switching all the bits
from 0 -> 1 and 1 -> 0, then adding 1. So,
$FF = 1111 1111 <-- original
0000 0000 <-- 1's compliment
+ 1
---------
0000 0001 <-- 2's compliment, therefore $FF = -1
Note that QForth uses this for numbers greater than 32768 so that
65535 = -1 and 32768 = -32768.
In practice, the assembly language programmer uses a label and the
assembler takes care of the actual computation. Note that branches
can only be to addresses within -128 to +127 bytes from the present
address. The 6502 does not allow branches to an absolute address.
Accumulator Addressing
----------------------
Like implied addressing, the object of the instruction is the
accumulator and need not be specified.
The 6502 Instruction Set
------------------------
There are 56 instructions in the 6502, and more in the 65C02. Many
instructions make use of more than one addressing mode and each
instruction/addressing mode combination has a particular hexadecimal
opcode that specifies it exactly. So,
A9 = LDA #$aa Immediate addressing mode load of accumulator
AD = LDA $aaaa Absolute addressing mode load of accumulator
etc.
Some 6502 instructions make use of bitwise logic. This includes AND,
OR, and EOR (Exclusive-OR). The tables below illustrate the effects
of these operations:
AND 1 1 -> 1 "both"
1 0 -> 0
0 1 -> 0
0 0 -> 0
OR 1 1 -> 1 "either one or both"
1 0 -> 1
0 1 -> 1
0 0 -> 0
EOR 1 1 -> 0 "one or the other but not both"
1 0 -> 1
0 1 -> 1
0 0 -> 0
Therefore, $FF AND $0F = $0F since,
1111 1111
and 0000 1111
---------
0000 1111 = $0F
AND is useful for masking bits. For example, to mask the high order
bits of a value AND with $0F:
$36 AND $0F = $06
OR is useful for setting a particular bit:
$80 OR $08 = $88
since 1000 0000 ($80)
0000 1000 ($08)
or ---------
1000 1000 ($88)
EOR is useful for flipping bits:
$AA EOR $FF = $55
since 1010 1010 ($AA)
1111 1111 ($FF)
eor ---------
0101 0101 ($55)
Other 6502 instructions shift bits to the right or the left or rotate
them right or left. Note that shifting to the left by one bit is the
same as multipling by 2 and that shifting right by one bit is the same
as dividing by 2.
The 6502 instructions fall naturally into 10 groups with two odd-ball
instructions NOP and BRK:
Load and Store Instructions
Arithmetic Instructions
Increment and Decrement Instructions
Logical Instructions
Jump, Branch, Compare and Test Bits Instructions
Shift and Rotate Instructions
Transfer Instructions
Stack Instructions
Subroutine Instructions
Set/Reset Instructions
NOP/BRK Instructions
Load and Store Instructions
===========================
LDA - LoaD the Accumulator
LDX - LoaD the X register
LDY - LoaD the Y register
STA - STore the Accumulator
STX - STore the X register
STY - STore the Y register
Microprocessors spend much of their time moving stuff around in
memory. Data from one location is loaded into a register and stored
in another location, often with something added or subtracted in the
process. Memory can be loaded directly into the A, X, and Y registers
but as usual, the accumulator has more addressing modes available.
If the high bit (left most, bit 7) is set when loaded the N flag on
the processor status register is set. If the loaded value is zero the
Z flag is set.
Arithmetic Instructions
=======================
ADC - ADd to accumulator with Carry
SBC - SuBtract from accumulator with Carry
The 6502 has two arithmetic modes, binary and decimal. Both addition
and subtraction implement the carry flag to track carries and borrows
thereby making multibyte arithmetic simple. Note that in the case of
subtraction it is necessary to SET the carry flag as it is the opposite
of the carry that is subtracted.
Addition should follow this form:
CLC
ADC ...
.
.
ADC ...
.
.
.
Clear the carry flag, and perform all the additions. The carry
between additions will be handled in the carry flag. Add from low
byte to high byte. Symbolically, the net effect of an ADC instruction is:
A + M + C --> A
Subtraction follows the same format:
SEC
SBC ...
.
.
SBC ...
.
.
.
In this case set the carry flag first and then do the subtractions.
Symbolically,
A - M - ~C --> A , where ~C is the opposite of C
Ex.1
----
A 16-bit addition routine. $20,$21 + $22,$23 = $24,$25
CLC clear the carry
LDA $20 get the low byte of the first number
ADC $22 add to it the low byte of the second
STA $24 store in the low byte of the result
LDA $21 get the high byte of the first number
ADC $23 add to it the high byte of the second, plus carry
STA $25 store in high byte of the result
... on exit the carry will be set if the result could not be
contained in 16-bit number.
Ex.2
----
A 16-bit subtraction routine. $20,$21 - $22,$23 = $24,$25
SEC clear the carry
LDA $20 get the low byte of the first number
SBC $22 add to it the low byte of the second
STA $24 store in the low byte of the result
LDA $21 get the high byte of the first number
SBC $23 add to it the high byte of the second, plus carry
STA $25 store in high byte of the result
... on exit the carry will be set if the result produced a
borrow
Aside from the carry flag, arithmetic instructions also affect the N,
Z, and V flags as follows:
Z = 1 if result was zero, 0 otherwise
N = 1 if bit 7 of the result is 1, 0 otherwise
V = 1 if bit 7 of the accumulator was changed, a sign change
Increment and Decrement Instructions
====================================
INC - INCrement memory by one
INX - INcrement X by one
INY - INcrement Y by one
DEC - DECrement memory by one
DEX - DEcrement X by one
DEY - DEcrement Y by one
The 6502 has instructions for incrementing/decrementing the index
registers and memory. Note that it does not have instructions for
incrementing/decrementing the accumulator. This oversight was
rectified in the 65C02 which added INA and DEA instructions. The
index register instructions are implied mode for obvious reasons while
the INC and DEC instructions use a number of addressing modes.
All inc/dec instructions have alter the processor status flags in the
following way:
Z = 1 if the result is zero, 0 otherwise
N = 1 if bit 7 is 1, 0 otherwise
Logical Instructions
====================
AND - AND memory with accumulator
ORA - OR memory with Accumulator
EOR - Exclusive-OR memory with Accumulator
These instructions perform a bitwise binary operation according to the
tables given above. They set the Z flag if the net result is zero and
set the N flag if bit 7 of the result is set.
Jump, Branch, Compare, and Test Bits
====================================
JMP - JuMP to another location (GOTO)
BCC - Branch on Carry Clear, C = 0
BCS - Branch on Carry Set, C = 1
BEQ - Branch on EQual to zero, Z = 1
BNE - Branch on Not Equal to zero, Z = 0
BMI - Branch on MInus, N = 1
BPL - Branch on PLus, N = 0
BVS - Branch on oVerflow Set, V = 1
BVC - Branch on oVerflow Clear, V = 0
CMP - CoMPare memory and accumulator
CPX - ComPare memory and X
CPY - ComPare memory and Y
BIT - test BITs
This large group includes all instructions that alter the flow of the
program or perform a comparison of values or bits.
JMP simply sets the program counter (PC) to the address given.
Execution proceeds from the new address. The branch instructions are
relative jumps. They cause a branch to a new address that is either
127 bytes beyond the current PC or 128 bytes before the current PC.
Code that only uses branch instructions is relocatable and can be run
anywhere in memory.
The three compare instructions are used to set processor status bits.
After the comparison one frequently branches to a new place in the
program based on the settings of the status register. The
relationship between the compared values and the status bits is,
+-------------------------+---------------------+
| | N Z C |
+-------------------------+---------------------+
| A, X, or Y < Memory | 1 0 0 |
| A, X, or Y = Memory | 0 1 1 |
| A, X, or Y > Memory | 0 0 1 |
+-----------------------------------------------+
The BIT instruction tests bits in memory with the accumulator but
changes neither. Only processor status flags are set. The contents
of the specified memory location are logically ANDed with the
accumulator, then the status bits are set such that,
* N receives the initial, un-ANDed value of memory bit 7.
* V receives the initial, un-ANDed value of memory bit 6.
* Z is set if the result of the AND is zero, otherwise reset.
So, if $23 contained $7F and the accumulator contained $80 a BIT $23
instruction would result in the V and Z flags being set and N reset since
bit 7 of $7F is 0, bit 6 of $7F is 1, and $7F AND $80 = 0.
Shift and Rotate Instructions
=============================
ASL - Accumulator Shift Left
LSR - Logical Shift Right
ROL - ROtate Left
ROR - ROtate Right
Use these instructions to move things around in the accumulator or
memory. The net effects are (where C is the carry flag):
+-+-+-+-+-+-+-+-+
C <- |7|6|5|4|3|2|1|0| <- 0 ASL
+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+
0 -> |7|6|5|4|3|2|1|0| -> C LSR
+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+
C <- |7|6|5|4|3|2|1|0| <- C ROL
+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+
C -> |7|6|5|4|3|2|1|0| -> C ROR
+-+-+-+-+-+-+-+-+
Z is set if the result it zero. N is set if bit 7 is 1. It is
always reset on LSR. Remember that ASL A is equal to multiplying by
two and that LSR is equal to dividing by two.
Transfer Instructions
=====================
TAX - Transfer Accumulator to X
TAY - Transfer Accumulator to Y
TXA - Transfer X to accumulator
TYA - Transfer Y to Accumulator
Transfer instructions move values between the 6502 registers. The N
and Z flags are set if the value being moved warrants it, i.e.
LDA #$80
TAX
causes the N flag to be set since bit 7 of the value moved is 1, while
LDX #$00
TXA
causes the Z flag to be set since the value is zero.
Stack Instructions
==================
TSX - Transfer Stack pointer to X
TXS - Transfer X to Stack pointer
PHA - PusH Accumulator on stack
PHP - PusH Processor status on stack
PLA - PulL Accumulator from stack
PLP - PulL Processor status from stack
TSX and TXS make manipulating the stack possible. The push and pull
instructions are useful for saving register values and status flags.
Their operation is straightforward.
Subroutine Instructions
=======================
JSR - Jump to SubRoutine
RTS - ReTurn from Subroutine
RTI - ReTurn from Interrupt
Like JMP, JSR causes the program to start execution of the next
instruction at the given address. Unlike JMP, JSR pushes the address
of the next instruction after itself on the stack. When an RTS
instruction is executed the address pushed on the stack is pulled off
the stack and the program resumes at that address. For example,
LDA #$C1 ; load the character 'A'
JSR print ; print the character and it's hex code
LDA #$C2 ; load 'B'
JSR print ; and print it
.
.
.
print JSR $FDED ; print the letter
JSR $FDDA ; and its ASCII code
RTS ; return to the caller
RTI is analagous to RTS and should be used to end an interrupt routine.
Set and Reset (Clear) Instructions
==================================
CLC - CLear Carry flag
CLD - CLear Decimal mode
CLI - CLear Interrupt disable
CLV - CLear oVerflow flag
SEC - SEt Carry
SED - SEt Decimal mode
SEI - SEt Interrupt disable
These are one byte instructions to specify processor status flag
settings.
CLC and SEC are of particular use in addition and subtraction
respectively. Before any addition (ADC) use CLC to clear the carry
or the result may be one greater than you expect. For subtraction
(SBC) use SEC to ensure that the carry is set as its compliment is
subtracted from the answer. In multi-byte additions or subtractions
only clear or set the carry flag before the initial operation. For
example, to add one to a 16-bit number in $23 and $24 you would write:
LDA $23 ; get the low byte
CLC ; clear the carry
ADC #$02 ; add a constant 2, carry will be set if result > 255
STA $23 ; save the low byte
LDA $24 ; get the high byte
ADC #$00 ; add zero to add any carry that might have been set above
STA $24 ; save the high byte
RTS ; if carry set now the result was > 65535
Similarly for subtraction,
LDA $23 ; get the low byte
SEC ; set the carry
SBC #$02 ; subtract 2
STA $23 ; save the low byte
LDA $24 ; get the high byte
SBC #$00 ; subtract 0 and any borrow generated above
STA $24 ; save the high byte
RTS ; if the carry is not set the result was < 0
Other Instructions
==================
NOP - No OPeration (or is it NO oPeration ? :)
BRK - BReaK
NOP is just that, no operation. Useful for deleting old
instructions, reserving room for future instructions or for use in
careful timing loops as it uses 2 microprocessor cycles.
BRK causes a forced break to occur and the processor will immediately
start execution of the routine whose address is in $FFFE and $FFFF.
This address is often the start of a system monitor program.
Some simple programming examples
================================
A few simple programming examples are given here. They serve to
illustrate some techniques commonly used in assembly programming.
There are doubtless dozens more and I make no claim at being a
proficient assembly language programmer. For examples of addition
and subtraction see above on CLC and SEC.
A count down loop
-----------------
;
; An 8-bit count down loop
;
start LDX #$FF ; load X with $FF = 255
loop DEX ; X = X - 1
BNE loop ; if X not zero then goto loop
RTS ; return
How does the BNE instruction know that X is zero? It
doesn't, all it knows is that the Z flag is set or reset.
The DEX instruction will set the Z flag when X is zero.
;
; A 16-bit count down loop
;
start LDY #$FF ; load Y with $FF
loop1 LDX #$FF ; load X with $FF
loop2 DEX ; X = X - 1
BNE loop2 ; if X not zero goto loop2
DEY ; Y = Y - 1
BNE loop1 ; if Y not zero goto loop1
RTS ; return
There are two loops here, X will be set to 255 and count to
zero for each time Y is decremented. The net result is to
count the 16-bit number Y (high) and X (low) down from $FFFF
= 65535 to zero.
Other examples
--------------
** Note: All of the following examples are lifted nearly verbatim from
the book "6502 Software Design", whose reference is above.
; Example 4-2. Deleting an entry from an unordered list
;
; Delete the contents of $2F from a list whose starting
; address is in $30 and $31. The first byte of the list
; is its length.
;
deluel LDY #$00 ; fetch element count
LDA ($30),Y
TAX ; transfer length to X
LDA $2F ; item to delete
nextel INY ; index to next element
CMP ($30),Y ; do entry and element match?
BEQ delete ; yes. delete element
DEX ; no. decrement element count
BNE nextel ; any more elements to compare?
RTS ; no. element not in list. done
; delete an element by moving the ones below it up one location
delete DEX ; decrement element count
BEQ deccnt ; end of list?
INY ; no. move next element up
LDA ($30),Y
DEY
STA ($30),Y
INY
JMP delete
deccnt LDA ($30,X) ; update element count of list
SBC #$01
STA ($30,X)
RTS
; Example 5-6. 16-bit by 16-bit unsigned multiply
;
; Multiply $22 (low) and $23 (high) by $20 (low) and
; $21 (high) producing a 32-bit result in $24 (low) to $27 (high)
;
mlt16 LDA #$00 ; clear p2 and p3 of product
STA $26
STA $27
LDX #$16 ; multiplier bit count = 16
nxtbt LSR $21 ; shift two-byte multiplier right
ROR $20
BCC align ; multiplier = 1?
LDA $26 ; yes. fetch p2
CLC
ADC $22 ; and add m0 to it
STA $26 ; store new p2
LDA $27 ; fetch p3
ADC $23 ; and add m1 to it
align ROR A ; rotate four-byte product right
STA $27 ; store new p3
ROR $26
ROR $25
ROR $24
DEX ; decrement bit count
BNE nxtbt ; loop until 16 bits are done
RTS
; Example 5-14. Simple 16-bit square root.
;
; Returns the 8-bit square root in $20 of the
; 16-bit number in $20 (low) and $21 (high). The
; remainder is in location $21.
sqrt16 LDY #$01 ; lsby of first odd number = 1
STY $22
DEY
STY $23 ; msby of first odd number (sqrt = 0)
again SEC
LDA $20 ; save remainder in X register
TAX ; subtract odd lo from integer lo
SBC $22
STA $20
LDA $21 ; subtract odd hi from integer hi
SBC $23
STA $21 ; is subtract result negative?
BCC nomore ; no. increment square root
INY
LDA $22 ; calculate next odd number
ADC #$01
STA $22
BCC again
INC $23
JMP again
nomore STY $20 ; all done, store square root
STX $21 ; and remainder
RTS
This is based on the observation that the square root of an
integer is equal to the number of times an increasing odd
number can be subtracted from the original number and remain
positive. For example,
25
- 1 1
--
24
- 3 2
--
21
- 5 3
--
16
- 7 4
--
9
- 9 5 = square root of 25
--
0
If you are truly interested in learning more, go to your public library
and seek out an Apple machine language programming book. If your public
library is like mine, there will still be plenty of early 80s computer
books on the shelves. :)
------------------------------------------------------------------------
Back to the Incredible 6502
programming/65816.std
+2253
View File
File diff suppressed because it is too large Load Diff
programming/65xxx.drm
+911
View File
@@ -0,0 +1,911 @@
This is a very long article (36k) of interest to hardware
hackers, assembly language programmers, and machine
architects. It is a description of how I feel the
65xxx family should evolve. Don't count on anything
you read here. Nonetheless, you might find it interesting.
If you're not one of the aforementioned types, you may
want to skip the noise which follows...
The 65C816 Dream Machine
This essay is an attempt to vent my frustrations.
While the 65C816 chip is, without question, better than
the 6502 and 65c02 chips that preceded it, the 65c816
leaves a lot to be desired. Unless you count
microcontrollers like the 8048, F8, or 8051, I've never
encountered a chip as difficult to program in assembly
language as the 65c816. Those stupid M and X bits cause
so much trouble I wonder if they're worth the trouble of
using them. Attempting to use the 65c816 in native mode
while attempting to coexist with other 6502 routines
(requiring emulation mode) such as ProDOS 8 can really
push one's patience. But wait! There's a small chance
things can be improved. The WDM (William D. Mensch)
instruction is reserved by the Western Design Center for
instruction set expansion. While I'm sure Mr. Mensch has
other plans for this opcode, the following treatise
provides my views on how this single opcode should be
used.
The WDM opcode should be used in the next version of
the 65c816 (let's call it the 65c820, just to be amusing)
to change the instruction set. When the 65c820 resets,
it should come up in the 6502 emulation mode, just like
the 65c816 does now. The XCE instruction could be used
to switch to 65c816 mode just like the existing 65c816
part. The WDM opcode, which I'll call NAT (for NATive
mode) will be used to switch the processor to 65c820
native mode. Once in the 65c820 mode, the 65c820 takes
on a completely different character. The only bounds
I've placed on the new instruction set is that if you can
perform an operation with a single instruction on the
65c816, you can perform the same thing on the 65c820 with
a single instruction. All other aspects (including
timing and instruction size) can vary. I've also taken
some liberties with the way certain instructions affect
the flags. For the most part however, 65c816
instructions have an identical counterpart on the 65c820.
Design Issues: There are lot's of reasons for
designing a new instruction set. My criteria are as
follows:
1) The instruction set must mirror the philosophy of the
6500 family. A programmer experienced with the 6502
instruction set must feel comfortable with the 65c820
instruction set.
2) The new instruction set must support high level
language constructs better than the 6502 and 65c816
processors.
3) The new instruction set must be easy to learn and fun
to use.
4) We must remember that fancy instructions are very
difficult to implement in silicon. Hence super fancy
instructions which provide limited functionality must
be left out. For example, the 65c820 doesn't support
floating point instructions (although they could be
added via a coprocessor).
5) The only (commercially popular) computer system that
would ever use the 65c820 is an upgrade of the Apple
IIGS. Hence the instruction set should contain
instructions that enhance the operation of an Apple II
family machine.
6) The original 6502 instruction set was designed with a
small set of basic instructions complemented with a
large set of addressing modes. The 65c816 strayed
from this philosophy, the 65c820 returns to it.
Based on these design issues, I offer the following
machine; the 65c820:
_________________________________________________________
______________________
Programmer's Model:
The 65c820 will contain several additional registers,
above and beyond those available on the 65c816. All
registers are 16 bits. The register bank includes:
A, AX -- Accumulator and accumulator extension
X -- X index register
Y -- Y index register
F -- Stack frame pointer
S -- Stack pointer
D -- Direct page register
P -- Program status word
ABR -- Auxillary bank register
SBR -- Stack bank register
DBR -- Data bank register
PBR -- Program bank register
PC -- Program counter
LBound -- Low bounds register
HBound -- High bounds register
A, X, Y, S, D, & PC are mostly identical to their 65c816
counterparts. AX is the accumulator extension used by the
multiply and divide instructions. F is a special index
register, useful for accessing local variables and
parameters. P differs from the 65c816 version in that it
is 16-bits wide. Accessing the upper byte of this
register is a privileged operation (more on that later
on). DBR and PBR are similar to their 65c816 cousins,
except they are now 16-bits long and allow you to
position the program and data banks on any PAGE boundary
(rather than a bank [64K] boundary). ABR is an auxillary
data bank register. SBR lets you locate the stack
anywhere in the 16Mbyte address space. LBound and HBound
provide some rudimentary memory management functions.
All memory addresses are added to LBound to produce the
true physical address. If the result- ing address is
greater than HBound, an ABORT trap will be issued. This
allows you to load multiple programs into memory and
protect them from being walked on by other programs.
As I alluded to earlier, certain operations are
PRIVILEGED. The 65c820's program status word takes the
following form:
15 14 13 12 11 10 9 8 | 7 6 5 4 3 2 1 0 U/S
I M fpc * * * * | N V * * D dir Z C
The low order 8 bits are identical to the 6502's P
register except the B bit isn't present (it's not
required) and the I bit has been moved to bit 14. The
dir bit controls the direction of various string
instructions (ala 8086). The low order 8 bits are called
the USRPSW (user program status word). The upper 8 bits
are called tye SYSPSW (system program status word) and
can only be accessed while in the system mode. Bit 15
(U/S) is the user/supervisor bit. This bit determines
whether or not you are in the user or system (supervisor)
mode. Bit 14 is the interrupt disable bit. For
protection reasons, a user mode program cannot have
access to the interrupt disable bit (by turning off all
interrupts and not turning them back on, a user mode
program can cause all kinds of havoc). Bit 13 is the
memory management bit. If set, the LBound the HBound
registers determine the location and extent of the
logical address space. If clear, then the logical
address space and physical address space are the same.
The fpc bit determines if a floating point coprocessor is
installed. If not, the floating point expansion
instructions will cause an illegal instruction trap,
otherwise, the FP instructions will be routed to the
floating point coprocessor. The remaining bits in the P
register are reserved for future use.
Opcode Format:
The 65c820's instruction set is broken down into 32
classes. They are
0-MOV, 1-LEA, 2-LEAA, 3-LEAD, 4-LEAS, 5-XCHG, 6-
ADD, 7-ADC 8-SUB, 9-SBC, A-CMP, B-AND, C-OR,
D-XOR, E-ASH, F-LSH 10-ROT, 11-BIT, 12-ADDQ, 13-CMPQ,
14-exp, 15-exp, 16-exp, 17-exp 18-exp, 19-Scc, 1A-Ccc,
1B-Icc, 1C-Brnch,1D-Brnch,1E-exp, 1F-exp
"exp" refers to expansion.
The "typical" instruction format (for opcodes $00..$11)
is
15 14 13 12 11 10 9 8 | 7 6 5 4 3 2 1 0 a a
a a a a s d | r r r o o o o o
where a = addressing mode bits s = size
(0=byte, 1=word) d = direction (0=to addressing
mode loc, 1=from addressing mode loc) r = register
o = opcode (one of the group values above).
There are 64 possible addressing modes (since there are
six "a" bits). The register bits refer to the first
eight of these addressing modes (0..7).
0- A 10- d,F 20- d,X 30- d,Y 1- X
11- a,F 21- a,X 31- a,Y 2- Y 12-
n(d,F) 22- a,FX 32- a,FY 3- S 13- n(a,F)
23- l,X 33- l,Y 4- F 14- n[d,F] 24- (X)
34- (Y) 5- TOS 15- n[a,F] 25- (d,X) 35-
(d),Y 6- Imm 16- (d,F) 26- n(d,X) 36-
n(d),Y 7- d 17- [d,F] 27- [d,X] 37-
[d],Y 8- a 18- (a,F) 28- n[d,X] 38-
n[d],Y 9- l 19- [a,F] 29- n(d,FX) 39-
n(d,F),Y A- d,S 1A- P 2A- n[a,FX] 3A-
n[a,F],Y B- (d,S),Y 1B- D 2B- [a,FX] 3B-
[a,F],Y C- (d) 1C- ABR 2C- (a,X) 3C-
(d),Y+ D- [d] 1D- SBR 2D- n(a,X) 3D-
(d),-Y E- n(d) 1E- DBR 2E- [a,X] 3E-
[d],Y+ F- n[d] 1F- PBR 2F- n[a,X] 3F-
[d],-Y
where:
A, X, Y, S, F, P, D, ABR, SBR, DBR, and PBR are the
corresponding 65c820 registers. Imm refers to an
immediate operand. d refers to an eight-bit value,
usually (but not always) a direct page address. a refers
to a 16-bit absolute address. l refers to a 24-bit long
address n is a displacement of the form one byte, +/-
64 if the H.O. bit is zero. two bytes, H.O. byte
first, +/- 16383 if the H.O. bit is one.
All addressing mode containing F, FX, or FY are relative
to the SBR register. Any "d" address appearing in such an
addressing mode is simply an 8-bit displacement relative
to the frame pointer. FX means add F and X and use the
result as the frame pointer. FY is the same, but using
the Y register.
Y+ and -Y are autoincrement and autodecrement addressing
modes. For autoincrement, the Y register is incremented
after the value contained in Y is used. For auto-
decrement, the Y register is decremented before the value
is used.
Addressing modes of the form n[---]-- compute the
effective address specified by the indirect operation and
then add the specified offset to the effective address to
obtain the true effective address. For example, if Y
contains 5 and location $00 points at $1000 in the DBR,
then 4(0),y refers to location $1009.
The TOS addressing mode refers to the Top Of Stack, more
on this later.
General Instructions:
The general instructions (opcodes $00..$11) all take the
form:
Instr Source, Dest
Where Instr is the instruction mnemonic, Source is the
address of a source operand, and Dest is the address of a
destination operand. At least one of the two operands
must be a "register" addressing mode. The register
addressing modes are the first eight addressing modes
listed above. If the source operand is a register
addressing mode, then the direction bit in the
instruction is zero, otherwise it is one. If the source
addressing mode is the immediate addressing mode, the
flags are set by the result of the operation, but nothing
else is changed. For example, MOVB #0,#n sets the zero
flag since a zero bit is moved, but the zero isn't
actually moved anywhere. Note that a "B" or "W" suffix
is used on the mnemonics to specify the instruction size.
Three important register addressing mode greatly enhance
the capabilities of the 65c820 processor: the TOS, Imm,
and d register addressing modes. Since d is a register
addressing mode, any direct page memory location can be
used as a "register". This greatly enhances the
flexibility of the 65c820. This effectively gives you
256 registers to play around with.
The Imm addressing mode, since it is a register
addressing mode, lets you perform operations between any
register or memory location in the machine (addressable
by a single instruction) with an immediate operand. For
example, CMPB #5,2[3,D],Y is perfectly legal. For a
few instructions, immediate operands don't make much
sense, such instructions will cause an illegal
instruction trap (for example, you cannot load the
effective address of an immediate operand into a
register).
The TOS addressing mode is extremely powerful. If
you've looked ahead at the expansion instructions, you'd
have noticed that there aren't any specific push or pop
instructions (unless you count ENTER, EXIT, SAVE, and
RESTORE). The TOS addressing mode handles all of this
for you. You want to push the accumulator onto the
stack? No problem, MOVW A,TOS will do the job. You
want to pop the X register off of the stack? Use MOVW
TOS,X. You want to add the item on the top of stack to
the item below it on the stack (a VERY common operation
performed by compilers), just use ADDW TOS,TOS. This
instruction will pop two words off of the stack, add
them, and push their sum back onto the stack (leaving two
bytes on the stack rather than the original four). With
the TOS addressing mode, you can push (or pop) any value
anywhere in addressable memory onto the stack with a
single instruction.
Special (but not expansion) Instructions:
There are seven groups of instructions in this category:
ADDQ, CMPQ, Scc, Ccc, Icc, and the branch instructions.
ADDQ (add quick) appears in place of the ubiquitous INC
and DEC instructions. ADDQ lets you add a four-bit signed
value to any addressable item. The register bits, along
with the direction bit, let you specify a signed four-bit
value. This value is added to the specfied address. The
immediate operand MUST be the source operand.
The CMPQ (compare quick) is similar except a compare
operation is performed rather than an addition.
Furthermore, the immediate operand is the destination
operand rather than the source operand.
The Scc (set on condition), Ccc (clear on condition), and
Icc (invert on condition) instructions are used to set
boolean values based on the condition codes. These go
hand in hand with the branch instructions so I'll
describe them all at once.
There are 16 possible conditions, the register and
direction bits are used to specify the condition. These
conditions are
0- RA/A 4- HI 8- GT C- PL 1- CC/LO
5- LT 9- EQ D- VC 2- CS/HS 6- GE
A- NE E- VS 3- LS 7- LE B- MI
F- SR/N
LO (lower) = unsigned less than HS (higher/same) =
unsigned greater than or equal LS (lower/same) = unsigned
less than or equal HI (higher) = unsigned greater than LT
= signed less than GE = signed greater than or equal LE =
signed greater than or equal GT = signed greater than
The Scc, Ccc, and Icc instructions take the form:
Scc{b|w} #Imm, Dest Ccc{b|w} #Imm,
Dest Icc{b|w} #Imm, Dest
If the immediate operand is zero, then Scc will store a
one into the specified location if the condition code is
met, otherwise a one will be stored. Ccc does just the
opposite, it stores a zero if the condition is met, one
otherwise. The Icc instruction will complement the
specified location (logical NOT) if the condition code is
met. If the immediate operand is not zero, the the Scc
in- struction will set the specified bits in the
destination operand if the condition code is met, the Scc
instruction will have no effect if the condition is not
met. The Ccc instruction clears the specified bits in the
destination operand. The Icc instruction inverts the
specified bits. The destination bits are specified with
ones in the immediate operand. For example, SCS #$88,
$00 will set bits three and seven in memory location zero
if the carry flag is set, location $00 will be
unaffected if the carry flag is clear.
The SA/CA/IA (Set always, Clear always, Invert always)
instructions always perform the specified operation. The
SN/CN/IN (set never, clear never, invert never) behave as
though the condition code was not met.
The branch instructions are unusual compared to those
encountered thus far. The instruction is only one byte
long. It takes the form:
7 6 5 4 3 2 1 0 o o o --1C or 1D--
If the opcode is $1C, then the three "o" bits represent
condition codes 0..7 above. Note that the BRA instruction
uses opcode bits %000.
If the opcode is $1D, then the three "o" bits represent
condition codes 8..$F above. There is no BN instruction,
Opcode %111 is the BSR (branch to subroutine)
instruction.
Unlike the 65c816, branches are not limited to +/- 128
bytes. A displacement value, similar to the used by the
general addressing modes allows a one-byte displacement
of +/- 64 bytes or +/- 16383 bytes. More than enough for
most cases.
Math expansion instructions:
The math expansion instructions (opcode $14) use the
three register bits as an opcode expansion yield eight
additional instructions. The instruction format is
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 a a
a a a a s d o o o 1 0 1 0 0 where "aaaaaa"
is a general addressing mode, "s" is the size (B/W), "d"
is the direction (load/store), and "ooo" is the sub-
opcode, decode as follows:
0- MUL 1- DIV 2- MOD 3- REM 4- INDX 5- CHK
6- DIVS 7- FPexp
Sub-opcode 7 is reserved for floating point expansion via
a coprocessor. If the FPC bit in the SYSPSW is not set,
then executing this opcode will cause an illegal
instruction trap. If the FPC bit is set, then an
additional eight bit opcode follows this instruction.
This opcode value plus the physical address provided by
the addressing mode, bounds registers, and applicable
prefix(es) are passed along to the coprocessor.
All of these instructions use the 65c820 accumulator
as the register operand. MULW performs an unsigned 16x16
multiply, leaving the 32-bit result in A, AX. MULB
performs an unsigned 8x8 multiply, leaving the result in
A. DIVW performs an unsigned 32/16 division. The value
in (A,AX) is divided by the specified operand and the
quotient is left in (A,AX). DIVB divides the 16-bit
accumulator by an eight bit value, leaving the result in
A. DIVS{W|B} perform signed divisions. These two
instructions operate on the 16-bit accumulator or 8-bit
accumulator ONLY. The AX register is not used. MOD and
REM compute the modulo and remainder functions (MOD is
unsigned, REM is signed). Their register usage is
identical to DIV/DIVS. There is no need for a signed
multiply instruction since signed and unsigned
multiplication produces the same result, assuming you
ignore the value in AX.
The INDX and CHK instructions are used to perform
array computations. The operand of these two
instructions points at a pair of bytes or words. The
INDX instruction multiplies the accumulator by the first
value and then adds the second value to the accumulator.
The direction bit in the opcode is ignored. The INDX
instruction takes two forms: INDXB and INDXW.
The CHK instruction compares the value in the
accumulator against the first and second values. If the
accumulator lies within these two values (inclusive) then
the overflow flag is cleared. If the accumulator is
outside the range of these two values, then the overflow
flag is set. The direction flag in the opcode is used to
determine whether a signed or unsigned comparison is
used. The CHK instruction takes four forms: CHKSB, CHKSW,
CHKUB, and CHKUW. The "U" and "S" specify unsigned or
signed.
String expansion instructions:
Opcode $15 is used for string operations. The 65c820
processor provides four basic string operations: MOVS
(move), CMPS (compare), XLATS (translate), and FILLS
(fill). The instruction format is as follows:
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 s s
s d d d l l l o o 1 0 1 0 1
where "sss" is the source address, "ddd" is the
destination address, "lll" is the length address, and
"oo" is the opcode. Since all of the addresses are three
bits, they must be register addresses. The source
address is a sixteen bit value taken from one of the
register addressing modes. The sixteen-bit value
obtained at said address is the start of the string
within the data bank (i.e., relative to the DBR
register). The destination address is also a sixteen-bit
register addressing mode value, specifying the start of
the destination address within the auxillary bank (i.e.,
relative to the ABR register). The length value is a
sixteen-bit quantity obtained directly from the register
addressing mode location. Prefix bytes (described later
on) are not allowed in front of a string instruction.
Opcode assignments:
0- MOVS 1- CMPS 2- XLATS 3- FILLS
The direction of the string operation is specified by
the "dir" bit in the USRPSW register. If the bit is
clear, then the source and destination operands are
incremented after each string operation. If the "dir"
bit is clear, then these operands are decremented after
each string operation.
The string instructions take the form:
MNEMONIC src, dest, len
where src, dest, and len are any of A, X, Y, S, F, TOS,
#value, or a direct page address. For the these
operands, the sixteen bit value specified by one of these
addresses is used, relative to the DBR, as the address
(or length) of the specified block. An absolute address
can be specified by an immediate operand. The direct
page address is the address of the 16-bit value within
the direct page, it does not mean that the address of the
block is that address in the direct page. Same with the
TOS, the value on the top of stack contains the address,
the top of stack is not the block itself. The len
operand is always a byte count. Unless an immediate
operand is specified, the operands are always updated to
reflect their new value at the termination of the block
operation.
The MOVS instruction is used to move a string of
bytes from one location to another. A block of "len"
bytes specified by DBR/src is moved to ABR/dest.
The MOVS operation is an example of an instruction
that does not exactly mirror its 65c816 counterpart. It
may take two (or more) instructions to perform the same
operation as the 65c816 MVN and MVP instructions, since
the direction flag may require adjustment before
performing a MOVS instruction. Futhermore, the ABR and
DBR registers may need adjustment before and after the
MOVS instruction to simulate the MVN and MVP
instructions. Finally, the actual count is specified by
length, not count-1 (as on the 65c816), so this may
require some adjustment if you are translating 65c816
code instruction by instruction.
Example:
MVN 0,1
can be simulated by
MOVW #0,DBR MOVW #1,ABR ADDQ #1,
A ;Since MVN assumes A contains count-1 MOVS
X,Y,A MOVW #1,DBR
The CMPS operation compares the two specified
strings. It does a byte by byte comparison until length
bytes are compared or a character in the source string is
not equal to the corresponding character in the
destination string. The condition codes are set to
reflect the ordinality of the two strings (so you can use
any of the branch, Scc, Ccc, or Icc instructions to test
the results). If the z flag is returned set, then the two
strings are equal (through the specified length),
otherwise the source and destination operands are updated
to point at the differing chars and the length operand is
updated to show the number of character processed thus
far (assuming, of course, that these operands weren't
immediate, in which case they would be ignored).
The XLATS instruction is used to translate values in
a string. The source operand points at a table in the
DBR. Each character in the dest string is used as an
index into this table and the value fetched from the
table is stored over the original character in the
destination string.
The FILLS instruction is used to initialize a string
with a fixed value. The source operand is an eight-bit
value. It is stored in successive locations at ABR/dest
for len bytes. If an immediate value is specified, a
sixteen-bit value is encoded into the instruction, but
only the L.O. eight bits are used.
Single byte expansion instructions:
These instructions take the form:
7 6 5 4 3 2 1 0 o o o 1 0 1 1 0
Where "ooo" is decoded as:
0- NOP 1- COP 2- BRK 3- SVC 4- RTS 5- RTL 6- RTI 7- EXIT
SVC is the "supervisor call" instruction. Its
intended use is for making operating system calls. It is
similar in function to the COP instruction.
EXIT is used to deallocate local variables in a
procedure. It undoes the actions of the ENTER
instruction. Basically it performs the following
operations:
MOV F,S MOV TOS, F
The remaining instructions in this group are
identical to their 65c816 counterparts, so they don't
require any futher elaboration.
Single byte w/displacement expansion instructions:
These instructions take the form:
7 6 5 4 3 2 1 0 o o o 1 0 1 1 1
Where "ooo" is decoded as:
0- SAVE n 1- RESTORE n 2- reserved 3- reserved 4- RTS n
5- RTL n 6- ADJSP n 7- ENTER n
The "n" value immediately following these
instructions is a displacement value. If bit seven of
the first byte following the opcode is zero, then the
remaining six bits are used to specify a signed value in
the range +/- 64. If bit seven is one, then the
following 15 bits are used to specify a value in the
range +/-16383. Except possibly for ADJSP, none of these
instructions should ever require more than a single byte
displacement.
SAVE is used to quickly push registers from the set
[A,AX,X,Y,F,D,P] onto the stack. The instruction is
followed by a single byte with bits 0..6 cor- responding
to these registers. Bit seven must always be zero.
RESTORE does just the opposite of SAVE, it pops the
specified registers off of the stack.
RTS n and RTL n perform the specified return from
subroutine operations and then add the specified
displacement to the stack pointer after the return
address has been popped. This provides a convenient
mechanism whereby parameters can be removed from the
stack.
The ADJSP n instruction adds the displacement value
to the stack pointer. This is a shorter version of the
ADD #value,S instruction. A special case was created for
this instruction because it gets used all the time in
languages like "C" or "SDL/65" which allow a variable
number of parameters.
The ENTER n instruction is used to set up an
activation record when a procedure is initially entered.
It performs the following operations:
MOVW F,TOS MOVW S, F ADJSP n
The EXIT instruction can be used to undo the effects of
this instruction.
Prefix expansion instructions:
These instructions take the form:
7 6 5 4 3 2 1 0 o o o 1 1 0 0 0
where "ooo" is decoded as:
0-ABR prefix 1-SBR prefix 2-PBR prefix 3-word index
prefix 4-dword index prefix 5-qword index prefix 6-
XBA/SWA 7-EMU
XBA and EMU aren't true prefix bytes, they're just
single byte instructions that didn't conveniently fit
anywhere else. So I'll describe them first. XBA is
identical to its 65c816 counterpart, it swaps the bytes
in the accumulator. EMU switches from 65c820 native mode
to 65c816 emulation mode. EMU is a privileged
instruction and will cause a privileged instruction trap
if executed from the user mode.
The first three prefix bytes are used to modify the
bank used for data accesses. Addressing modes that
normally access memory through the data bank register
(which are all memory references except direct, long,
TOS, and those involving F) can be "tweaked" to access
memory through the auxillary, stack, or program bank
registers by prefixing the address with the appropriate
prefix. For example,
MOVW #275, ABR:$1000
stores 275 into location $1000 in the auxillary bank
register rather than the data bank register. Indirect
addresses of the form (a,X) and n(a,X) present a minor
problem. Does the prefix specify the bank address of the
absolute operand or the effective address? I've opted
for requiring that the absolute operand reside in the
data bank and the prefix byte determines the effective
address bank.
Any addressing mode utilitizing the frame pointer
register (F) is always relative to the stack bank
register. Prefixes are only allowed for the following
frame-based addressing modes: n(d,F), n(a,F), (d,F),
(a,F), n(d,FX), and n(d,F),Y. The indirect address
always comes out of the stack bank, the prefix applies to
the computed effective address.
Although the ABR:/SBR:/PBR: lexemes immediately
precede the address expression to which they apply (on
the source line), in the object code, the prefix byte
always precedes the instruction to which the prefix
applies. If more than one prefix byte precedes an
instruction, only the last one is used. If a prefix byte
precedes an instruction to which the prefix doesn't make
sense (a branch, for example), then the prefix byte is
ignored. Finally, the prefix byte will be ignored if
there isn't an applicable addressing mode in the current
instruction. E.G.: byt $18 ;ABR prefix
byte MOVW A,X ;ABR prefix has no meaning
here.
Three additional prefix bytes apply to the X and Y
index registers. These are the word index prefix, dword
index prefix, and qword index prefix. These prefix bytes
provide scaled indexed addressing modes for the 65c820.
Without one of these prefixes, the X and Y registers are
always byte offsets. That is, when used as an index
register, the contents of X or Y is added directly to the
effective address being computed. When accessing words,
pointers (double words), or eight byte values (e.g.,
floating point) you have to manually adjust the index
registers by a factor of 2, 4, or 8. The scaled index
addressing prefix bytes let you avoid this problem. The
word prefix multiplies the X or Y register value by two
before using it in the effective address computation.
Likewise, the dword and qword prefixes multiply X or Y by
4 or 8 before using the value. In the source code, these
prefix bytes are specified by the ":W", ":D", and ":Q"
suffixes:
MOVW A,LBL,X:W MOVW
$0,(PTR),Y:D MOVW $2, 2(PTR),Y:D
MOVW F,(TBL,X:W) MOVW A,LBL,Y:Q
If multiple prefixes appear, only the last one is used.
If the prefix doesn't apply to the next instruction, it
is ignored.
Single operand expansion instructions:
The $1E expansion instructions are dedicated to
instructions which require a single operand. The format
for the opcodes is as follows:
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 a a
a a a a s o o o o 1 1 1 1 0
where "aaaaaa" is a general addressing mode, "s" is the
size (B/W), and "oooo" is one of the following opcodes:
0- NOT 8- LAX (load AX register) 1-
NEG 9- SAX (store AX register) 2- ABS
A- XAX (exchange AX register) 3- BOOL (0->0 else->1)
B- LLB (load LBound register) 4- SEX
C- LHB (load HBound register) 5- ZEX
D- SLB (store LBound register) 6- JMP
E- SHB (store HBound register) 7- JSR
F- VAL (validate memory location)
All of these instructions are followed by a single
general address expression. Immediate operands are not
allowed for any of these instructions.
NOT- logically compliments the specified value. NEG-
takes the two's complement of the specified value. ABS-
takes the absolute value of the specified location. BOOL-
If the specified location is not zero, a one is stored
into it.
SEX- (that's sign extension, not what you think). SEXB
checks the high order bit of the specified byte and
copies it into the H.O. byte of the corresponding
address. For example, if X contains $0082 then SEXB X
will store $FF82 into X. If X contains $0002, then SEXB X
will store $0002 into X. SEXW sign extends the
specified location into the AX register.
ZEX- zero extends the specified value. ZEXW simply
stores a zero into AX. ZEXB stores a zero into the H.O.
byte of the specified word.
JMP and JSR are like their 65c816 counterparts except any
valid addressing mode can be used. Note that, unlike
most other instructions, the result is assumed to be in
the current program bank unless a long addressing mode is
specified.
LAX, SAX, and XAX allow you to load, store, and exchange
the contents of the AX register. Note that these three
instructions plus SEX, ZEX, MUL, DIV, and MOD are the
only instructions that deal with the AX register.
LLB, LHB, SLB, and SHB let you load and save the contents
of the bounds registers. These are privileged
instructions which will cause a privilege trap if
executed from the user mode.
VAL- This instruction is used to validate a memory
location. That is, it tests the specified memory
location to see if it lies within the range specified by
the bounds register. The address is a physical address,
not a translated address. The overflow flag is set if a
bounds violation would occur. Note that the M bit in the
SYSPSW need not contain a particular value when using
this instruction. This is a privileged instruction which
will cause a privilege violation if executed in the user
mode.
BIT expansion instructions:
These instructions take the form:
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 a a
a a a a s o o o o 1 1 1 1 1
"aaaaaa" is the destination addressing mode. "s" is the
size (applicable only to MAND, MOR, and MXOR). "oooo" is
the sub-opcode, decoded as:
0- INS dest, start, len 1- EXT dest, start, len 2- FFS
dest, start, len 3- FFC dest, start, len 4- MAND dest,
mask 5- MOR dest, mask 6- MXOR dest, mask
7..F- reserved.
INS is used to insert a value into a bit field. The
value in the accumulator is shifted to the left "start"
bits and the the "len" following bits are stored into
the specified memory location. For example, if memory
location $00 contains $F0 and the accumulator contains
$3, then INS $00,2,4 would leave location $00 containing
$CC. Note that you needn't specify byte or word size as
this is intrinsic from the length.
EXT- extracts a bit field from some location and stores
the right justified value into the accumulator (zeroing
out any unused bits). For example, if memory location
$00 contains $CC and the accumulator contains $FFFF, then
EXT $0,2,4 would leave the accumulator containing 3 and
location $00 containing $CC.
FFS finds the first set bit in the specified location.
The bit position is returned in the accumulator. If
there were no set bits, the accumulator contains "len"+1.
FFC finds the first clear bit in a manner identical to
FFS.
Some notes: These four instructions are followed by a
single byte. The low order four bits contain the start
value, the high order four bits contain the length-1.
"start" + "len" must always be less than or equal to 15.
FFS and FFC use the direction bit in the USRPSW to
determine which way to progress in the bit field when
searching for the set or clear bit.
The MAND, MOR, and MXOR (masked AND, OR, and XOR) will
AND, OR, or XOR the accumulator into the specified memory
location. The difference between these three
instructions and the standard AND, OR, and XOR
instructions is that they are followed by a byte or word
(depending on the instruction size) which contains a mask
for the operation. Wherever a one bit appears in the
mask, the logical operation will take place, wherever a
zero bit appears, the destination's bits will be
unaffected.
_________________________________________________________
__________________
That wraps up my proposed instruction set for the 65c820.
I'll be happy to discuss my design decisions with anyone
who's interested. The next step is to try and convince
someone to actually build this thing! In the mean time,
I might try writing an interpreter and assembler for it.
By the way. Many of you have probably recognized certain
instructions from this processor or that processor
sprinkled throughout. To set the record straight, most
of my ideas have come from my own frustrations with the
65c816, the 8086 family, and the National Semiconductor
32000 family. Despite that fact that a lot of you think
that Intel's parts stink because they're used by IBM,
don't let that prejudice you against many of the design
issues here. The 8086 does have a resonable
archetecture, given the compromises it had to face. It's
certainly better than the 65c816. I've incorporated a
lot of the better ideas (like segment prefixes) into the
design of the 65c820. Once again, don't downplay these
powerful features just because you don't like IBM.
*** Randy Hyde
programming/8080.op
BIN
View File
Binary file not shown.
programming/86bugs.lst
+3004
View File
File diff suppressed because it is too large Load Diff
programming/AI/ai.sf
+1572
View File
File diff suppressed because it is too large Load Diff
programming/AI/ai010023.txt
+1709
View File
File diff suppressed because it is too large Load Diff
programming/AI/ai010024.txt
+1526
View File
File diff suppressed because it is too large Load Diff
programming/AI/ai198901.txt
+3045
View File
File diff suppressed because it is too large Load Diff
programming/AI/ai198902.txt
+545
View File
@@ -0,0 +1,545 @@
␍ Research Report AI-1989-02
␍ Artificial Intelligence Programs
␍ The University of Georgia
␍ Athens, Georgia 30602
␍ Available by ftp from
␍ aisun1.ai.uga.edu
␍ (128.192.12.9)
␍ Series editor:
␍ Michael Covington
␍ mcovingt@aisun1.ai.uga.edu
␍
␍ A Numerical Equation Solver in Prolog
␍ Michael A. Covington
␍ Artificial Intelligence Programs
␍ The University of Georgia
␍ Athens, Georgia 30602
␍ March 1989
␍ Abstract: The Prolog inference engine can be extended
␍ to solve for unknowns in arithmetic equations such as
␍ X-1=1/X or X=cos(X), whether or not the equations have
␍ analytic solutions. This is done by standard numerical
␍ methods, but two features of Prolog make the
␍ implementation easy: the ability to treat expressions
␍ as data and the ability of the program to extend
␍ itself at run time.
␍ 1. The problem
␍ The Prolog inference engine can solve for any unknown in
␍ symbolic queries, but not in arithmetic queries. For example,
␍ given the fact
␍ father(michael,sharon).
␍ one can ask
␍ ?- father(michael,X).
␍ and get the answer sharon, or ask
␍ ?- father(X,sharon).
␍ and get the answer michael. This interchangeability of unknowns
␍ extends to complex symbolic manipulations (e.g., append can be
␍ used to split a list as well as to concatenate lists), but not to
␍ arithmetic.
␍ Prolog handles arithmetic the way Fortran did thirty years
␍ ago: the unknown can only be a single variable on the left of the
␍ operator is, and everything on the right must be known. Thus
␍ ?- X is 2 + 2.
␍ gets the answer 4, but
␍ ?- X is 1 + 1 / X.
␍
␍ 2
␍ fails or raises an error condition.
␍ The excuse for this restriction is that Prolog cannot search
␍ the set of real numbers the way it searches the symbols in a
␍ knowledge base. As far as exhaustive search goes, this is true.
␍ However, mathematicians have been using heuristic searches to
␍ solve equations since the days of Isaac Newton. The procedures
␍ given here implement one such method, making it possible to have
␍ dialogues with the computer such as:
␍ ?- solve( X = 1 + 1 / X ).
␍ X = 1.618034
␍ ?- solve( X = cos(X) ).
␍ X = 0.739085
␍ and so on.
␍ 2. The solution
␍ Prolog is an ideal language for solving equations for two
␍ reasons: equations can be treated as data, and the program can
␍ modify itself. A procedure can accept expressions as parameters,
␍ then evaluate them or even create procedures to evaluate them. In
␍ Pascal or C, by contrast, there is no simple way to introduce a
␍ wholly new equation into the program at run time.
␍ The program given here solves equations by the secant
␍ method, which is one of the simplest numerical methods, though not
␍ the most robust. A different method can easily be substituted once
␍ the framework of the program is in place. Standard (Edinburgh-
␍ compatible) Prolog is required; Turbo Prolog programs cannot
␍ modify themselves in the necessary way.
␍ To solve the equation
␍ Left = Right
␍ the secant method uses the function
␍ Dif(x) = Left - Right
␍ where Left and Right are expressions that contain x. The problem
␍ is then to search for an x such that Dif(x) = 0.
␍ The search is begun by taking two guesses at x and comparing
␍ the values of Dif(x) for each. One of them will normally be closer
␍ to zero than the other. From this information the computer can
␍ tell whether to move toward higher or lower guesses. In fact, by
␍ assuming that Dif(x) increases or decreases linearly with x, the
␍ computer can estimate how far to move. (This is why it's called
␍
␍ 3
␍ the secant method -- given two guesses, the third guess is formed
␍ by extending a secant line on the graph of the function.)
␍ Success is not guaranteed -- the two Dif values could be
␍ equal, or the estimate of how far to move could be misleading --
␍ but the procedure usually converges on a solution in just a few
␍ iterations. Listing 1 shows the algorithm in pseudocode form.
␍ 3. Finding the unknown
␍ Expressing this in Prolog boils down to two things: setting
␍ up the problem, and then performing the computation. The setting
␍ up is done by solve, which calls free_in, define_dif, and
␍ solve_for (Listing 2).
␍ The first step is to identify the unknown -- that is, to
␍ pick out the free variable in the equation to be solved. This is
␍ done by procedure free_in, which finds the free (uninstantiated)
␍ variables in any Prolog term. This is more general than what we
␍ need, but it's always useful to build a general-purpose tool.
␍ If the term contains a free variable, there are two
␍ possibilities: either the term is the variable, in which case the
␍ search is over, or else the term has a variable somewhere in its
␍ argument structure. free_in has a clause for each of these cases.
␍ The second case requires that the term be decomposed into a
␍ list. The built-in predicate "univ" (=..) does this. For example,
␍ a(b,c(d),e) =.. [a,b,c(d),e].
␍ 2+3+X =.. ['+',2,3+X]
␍ Even lists can be split this way, because any list is really a
␍ two-argument structure with the dot ('.') as its principal
␍ functor. That is, the list [a,b,c] is really a.(b.(c.[])), though
␍ not all Prologs allow you to write it that way. So,
␍ [a,b,c] =.. ['.',a,[b,c]].
␍ Thus a list is not a special case; it can be treated just like any
␍ other complex term.
␍ In free_in, the statement
␍ Term =.. [_,Arg|Args].
␍ discards the functor, which can't be a variable anyway, and
␍ obtains two things: the first argument, Arg, and the list of
␍ subsequent arguments, Args. It is then straightforward to search
␍ for variables in both Arg and Args. Further, because Arg can be a
␍
␍ 4
␍ single variable, the first clause has a chance to terminate the
␍ recursion; and if it isn't, whatever is the first element of Args
␍ on this pass will be Arg on the next recursive pass and will get
␍ examined then.
␍ There is, however, a special case to rule out. The term [[]]
␍ decomposes into ['.',[],[]], givng Arg = [] and Args = [[]], which
␍ would lead to an endless loop. For this reason, free_in explicitly
␍ tests for this term and rejects it.
␍ 4. Defining a procedure
␍ The next step is to define a procedure to compute the Dif
␍ function. Recall that the argument of solve is an equation in the
␍ form Left=Right. Clearly, the Dif function is obtained by
␍ evaluating Left-Right. But how is this done?
␍ There are two possibilities. One possibility would be to
␍ pass along the expression Left-Right and evaluate it whenever
␍ needed. This is easily done, because
␍ X is Y.
␍ will evaluate whatever expression Y is instantiated to.
␍ But the other, faster, possibility is to define a procedure
␍ to do the evaluating. That's what define_dif does; it creates a
␍ procedure such as
␍ dif(X,Dif) :- Dif is X - cos(X).
␍ using whatever expressions the user originally supplied. The
␍ result is a procedure called dif that accepts a value of X and
␍ returns the corresponding value of the Dif function. In ALS
␍ Prolog, this dif procedure is compiled into threaded code when
␍ assert places it into the program; it runs just as fast as if it
␍ had been supplied by the original programmer. Other Prologs run it
␍ interpretively.
␍ What connects the variable X to the expression Left-Right in
␍ which it is supposed to occur? This question addresses the heart
␍ of Prolog's variable scoping system. It isn't enough simply that
␍ it is called X; like-named variables in Prolog are not the same
␍ unless they occur in the same rule, fact, or goal.
␍ That's why so many goals in this program have both X and
␍ Left=Right (or Left-Right) as arguments. Initially, free_in takes
␍ Left and Right and finds a variable in them. This variable may
␍ have any name, but it is unified with the variable X in solve.
␍ This same X is then passed, along with Left and Right, to
␍ define_dif, which uses it in creating the dif procedure.
␍
␍ 5
␍ Thereafter, the X in dif is guaranteed to be a variable that
␍ occurs in Left-Right, also in dif, regardless of what the user
␍ originally called it.
␍ 5. Solving the equation
␍ The last step is to implement the secant method (Listing 3).
␍ The pseudocode in Listing 1 undergoes several changes when
␍ translated into Prolog.
␍ First, Prolog has no loop constructs, so recursion is used
␍ instead. The loop is replaced by the procedure solve_aux, which
␍ calls itself. Because the recursive call is the last step of a
␍ procedure with no untried alternatives, the compiler converts it
␍ back into a loop in machine language, but conceptually, the
␍ programmer thinks in terms of recursion.
␍ Second, in Prolog there is no way to change the value of an
␍ instantiated variable. This means, for example, that there is no
␍ Prolog counterpart of
␍ Guess1 := Guess2
␍ when Guess1 already has a value. Instead, the proper Prolog
␍ technique is to pass a new value in the same argument position on
␍ the next recursive call. Thus the procedure that begins with
␍ solve_aux(...Guess1,Dif1,Guess2...) :- ...
␍ ends with the recursive call
␍ ... solve_aux(...Guess2,Dif2,Guess3...).
␍ Third, there are minor rearrangements to avoid computing
␍ Dif(X) more than once with the same value of X. These include the
␍ variable Dif2 and the passing of Dif1 as an argument from the
␍ previous recursive pass.
␍ 6. Limits and possibilities
␍ This program is intended as a demonstration of the
␍ integration of numerical methods into Prolog, not as a
␍ demonstration of numerical methods per se.
␍ The secant method is simple, but far from perfect. It has
␍ trouble with some equations. For example, if two successive Dif
␍ values happen to be exactly the same distance from zero, then
␍ solve_aux will try to divide by zero. This simply fails in ALS
␍ Prolog but may cause an error message in other Prologs. This
␍ problem shows up with the equation
␍
␍ 6
␍ X^2 - 3*X = 0
␍ which has Dif=-2 for both of the first two guesses (1 and 2). With
␍ a case very close to this, such as X^2 - 3.01*X = 0, we find that
␍ although the method should work in principle, in practice the next
␍ guess is a long way from the correct solution, and the guesses run
␍ wildly out of the range of representable numbers. And with some
␍ equations, the guesses will bounce back and forth between two
␍ values, not getting better with successive iterations [1].
␍ More robust numerical methods can easily be substituted into
␍ the same program framework. The ability to solve for more than one
␍ unknown is desirable; this could be treated as a multi-variable
␍ minimization problem where the goal is to minimize abs(Dif(X))
␍ [2]. It is possible to solve systems of nonlinear equations by
␍ reducing them to systems of linear equations, which can then be
␍ solved by conventional methods.
␍ The program was written in ALS Prolog and has been tested in
␍ Quintus Prolog. However, other Prologs may require minor
␍ modifications. For example, Arity Prolog 4.0 requires spaces
␍ before certain opening parentheses (e.g., 2 + (3+4) + 5 rather
␍ than 2+(3+4)+5). And it is a general limitation of real-number
␍ arithmetic that a negative number cannot be raised to a non-
␍ integer power (i.e., 4^2.5 is all right but (-4)^2.5 is not). Some
␍ Prologs assume all exponents are non-integer.
␍ References
␍ [1] Hamming, Richard W., Introduction to Applied Numerical
␍ Analysis (New York: McGraw-Hill, 1971), especially pp. 33-55.
␍ [2] Press, William H.; Flannery, Brian P.; Teukolsky, Saul A.; and
␍ Vetterling, William T., Numerical Recipes: The Art of Scientific
␍ Computing (Cambridge: Cambridge University Press, 1986),
␍ especially pp. 240-334.
␍
␍ 7
␍ Listing 1. The secant method algorithm in pseudocode form.
␍ To solve Left = Right:
␍ function Dif(X) = Left - Right
␍ where X occurs in Left and/or Right;
␍ procedure Solve;
␍ begin
␍ Guess1 := 1;
␍ Guess2 := 2;
␍ repeat
␍ Slope := (Dif(Guess2)-Dif(Guess1))/(Guess2-Guess1);
␍ Guess1 := Guess2;
␍ Guess2 := Guess2 - (Dif(Guess2)/Slope)
␍ until Guess2 is sufficiently close to Guess1;
␍ result is Guess2
␍ end.
␍
␍ 8
␍ Listing 2. Procedures to set up the problem.
␍ % solve(Left=Right)
␍ %
␍ % On entry, Left=Right is an arithmetic
␍ % equation containing an uninstantiated
␍ % variable.
␍ %
␍ % On exit, that variable is instantiated
␍ % to an approximate numeric solution.
␍ %
␍ % The syntax of Left and Right is the same
␍ % as for expressions for the 'is' predicate.
␍ solve(Left=Right) :-
␍ free_in(Left=Right,X),
␍ !, /* accept only one solution of free_in */
␍ define_dif(X,Left=Right),
␍ solve_for(X).
␍ % free_in(Term,Variable)
␍ %
␍ % Variable occurs in Term and is uninstantiated.
␍ free_in(X,X) :- % An atomic term
␍ var(X).
␍ free_in(Term,X) :- % A complex term
␍ Term \== [[]],
␍ Term =.. [_,Arg|Args],
␍ (free_in(Arg,X) ; free_in(Args,X)).
␍ % define_dif(X,Left=Right)
␍ %
␍ % Defines a predicate to compute Left-Right
␍ % for the specified equation, given X.
␍ define_dif(X,Left=Right) :-
␍ abolish(dif,2),
␍ assert((dif(X,Dif) :- Dif is Left-Right)).
␍
␍ 9
␍ Listing 3. Procedures to implement the secant method.
␍ % solve_for(Variable)
␍ %
␍ % Sets up arguments and calls solve_aux (below).
␍ solve_for(Variable) :-
␍ dif(1,Dif1),
␍ solve_aux(Variable,1,Dif1,2,1).
␍ % solve_aux(Variable,Guess1,Dif1,Guess2,Iteration)
␍ %
␍ % Uses the secant method to find a value of
␍ % Variable that will make the 'dif' procedure
␍ % return a value very close to zero.
␍ %
␍ % Arguments are:
␍ % Variable -- Will contain result.
␍ % Guess1 -- Previous estimated value.
␍ % Dif1 -- What 'dif' gave with Guess1.
␍ % Guess2 -- A better estimate.
␍ % Iteration -- Count of tries taken.
␍ solve_aux(cannot_solve,_,_,_,100) :-
␍ !,
␍ write('[Gave up at 100th iteration]'),nl,
␍ fail.
␍ solve_aux(Guess2,Guess1,_,Guess2,_) :-
␍ close_enough(Guess1,Guess2),
␍ !,
␍ write('[Found a satisfactory solution]'),nl.
␍ solve_aux(Variable,Guess1,Dif1,Guess2,Iteration) :-
␍ write([Guess2]),nl,
␍ dif(Guess2,Dif2),
␍ Slope is (Dif2-Dif1) / (Guess2-Guess1),
␍ Guess3 is Guess2 - (Dif2/Slope),
␍ NewIteration is Iteration + 1,
␍ solve_aux(Variable,Guess2,Dif2,Guess3,NewIteration).
␍ % close_enough(X,Y)
␍ %
␍ % True if X and Y are the same number to
␍ % within a factor of 0.0001.
␍ %
␍ close_enough(X,Y) :-
␍
␍ 10
␍ Quot is X / Y,
␍ Quot > 0.9999,
␍ Quot < 1.0001.
␍
programming/AI/ai198904.txt
+1140
View File
File diff suppressed because it is too large Load Diff
programming/AI/ai198908.txt
+899
View File
@@ -0,0 +1,899 @@
␍ Research Report AI-1989-08
␍ Artificial Intelligence Programs
␍ The University of Georgia
␍ Athens, Georgia 30602
␍ Available by ftp from
␍ aisun1.ai.uga.edu
␍ (128.192.12.9)
␍ Series editor:
␍ Michael Covington
␍ mcovingt@aisun1.ai.uga.edu
␍
␍ Covington -- Efficient Prolog 1
␍ Efficient Prolog: A Practical Guide
␍ Michael A. Covington
␍ Artificial Intelligence Programs
␍ The University of Georgia
␍ Athens, Georgia 30602
␍ August 16, 1989
␍ Abstract: Properly used, Prolog is as fast
␍ as any language with comparable power.
␍ This paper presents guidelines for using
␍ Prolog efficiently. Some of these
␍ guidelines rely on implementation-
␍ dependent features such as indexing and
␍ tail recursion optimization; others are
␍ matters of pure algorithmic complexity.
␍
␍ Many people think Prolog is inefficient. This is partly
␍ because of the poor performance of early experimental
␍ implementations, but another problem is that some programmers use
␍ Prolog inefficiently.
␍ Properly used, Prolog performs automated reasoning as fast
␍ as any other language with comparable power. It is certainly as
␍ fast as Lisp, if not faster.1 There are still those who rewrite
␍ Prolog programs in C "for speed," but this is tantamount to
␍ boasting, "I can implement the core of Prolog better than a
␍ professional Prolog implementor."
␍ This paper will present some practical guidelines for using
␍ Prolog efficiently. The points made here are general and go well
␍ beyond the implementation-specific advice normally given in
␍ manuals.
␍ Think procedurally as well as declaratively.
␍ Prolog is usually described as a declarative or non-
␍ procedural language. This is a half-truth. It would be better to
␍ say that most Prolog clauses can be read two ways: as declarative
␍ statements of information and as procedures for using that
␍ information. For instance,
␍ in(X,usa) :- in(X,georgia).
␍ means both "X is in the U.S.A. if X is in Georgia" and "To prove
␍ that X is in the U.S.A., prove that X is in Georgia."
␍
␍ Covington -- Efficient Prolog 2
␍ Prolog is not alone in this regard. The Fortran statement
␍ X=Y+Z
␍ can be read both declaratively as the equation x=y+z and
␍ procedurally as the instructions LOAD Y, ADD Z, STORE X. Of course
␍ declarative readings pervade Prolog to a far greater extent than
␍ Fortran.
␍ Sometimes the declarative and procedural readings conflict.
␍ For example, Fortran lets you utter the mathematical absurdity
␍ X=X+1. More subtly, the Fortran statements
␍ A = (B+C)+D
␍ A = B+(C+D)
␍ look mathematically equivalent, but they give profoundly different
␍ results when B=10000000, C=-10000000, and D=0.0000012345.
␍ Analogous things happen in Prolog. To take a familiar
␍ example, the clause
␍ ancestor(A,C) :-
␍ ancestor(A,B), ancestor(B,C).
␍ is part of a logically correct definition of "ancestor," but it
␍ can cause an endless loop when Prolog interprets it procedurally.
␍ The loop arises because, when B and C are both unknown, the
␍ goal ancestor(A,B) on the right is no different from ancestor(A,C)
␍ on the left. The clause simply calls itself with essentially the
␍ same arguments, making no progress toward a proof. But if the
␍ clause is rewritten as
␍ ancestor(A,C) :-
␍ parent(A,B), ancestor(B,C).
␍ there is no loop because ancestor cannot call itself with the same
␍ arguments.
␍ The moral is that to use Prolog effectively, one must
␍ understand not only the declarative reading of the program but
␍ also the procedures that the computer will follow when executing
␍ it. The limitations of Prolog's built-in proof procedures are not
␍ flaws in the implementation; they are deliberate compromises
␍ between logical thoroughness and efficient search.
␍
␍ Covington -- Efficient Prolog 3
␍ Narrow the search.
␍ Searching takes time, and an efficient program must search
␍ efficiently. In a knowledge base that lists 1000 gray objects but
␍ only 10 horses, the query
␍ ?- horse(X), gray(X).
␍ can be 100 times as fast as the alternative
␍ ?- gray(X), horse(X).
␍ because it narrows the range of possibilities earlier.
␍ Many opportunities to narrow the search space are much more
␍ subtle. Consider the problem of determining whether two lists are
␍ set-equivalent -- that is, whether they have exactly the same
␍ elements, though not necessarily in the same order.
␍ Two lists are set-equivalent if and only if one of them is a
␍ permutation of the other. One strategy, then, is to generate all
␍ the permutations of the first list and compare them to the second
␍ list:
␍ set_equivalent(L1,L2) :-
␍ permute(L1,L2).
␍ The trouble is that an N-element list has N! permutations; testing
␍ the set-equivalence of two 20-element lists can require 2.4 1018
␍ comparisons. I have actually seen someone attempt this in a Prolog
␍ program.
␍ It is much faster to sort both lists and compare the
␍ results:
␍ set_equivalent(L1,L2) :-
␍ sort(L1,L3), sort(L2,L3).
␍ An N-element list can be sorted in about N log2 N steps -- i.e.,
␍ about 86 steps per 20-element list -- and each "step" involves
␍ considerably less work than generating a new permutation. So this
␍ technique is faster than the first one by a factor of more than
␍ 1016.
␍ Let unification do the work.
␍ As a classroom exercise I ask my students to write a
␍ predicate that accepts a list and succeeds if that list has
␍ exactly three elements. Some of the weaker answers that I get look
␍ like this:
␍
␍ Covington -- Efficient Prolog 4
␍ has_three_elements(X) :-
␍ length(X,N),
␍ N = 3.
␍ Slightly better are those that say
␍ has_three_elements(X) :-
␍ length(X,3).
␍ thereby letting the built-in pattern-matcher test whether length
␍ returns 3. But the best students cut the Gordian knot by writing:
␍ has_three_elements([_,_,_]).
␍ The point is that [_,_,_] matches any three-element list and
␍ nothing else. Unification does all the work.
␍ Unification can even rearrange the elements of a data
␍ structure. Here is a predicate that accepts a list and generates,
␍ from it, a similar list with the first two elements swapped:
␍ swap_first_two([A,B|Rest],[B,A|Rest]).
␍ Again, unification does all the work. More precisely, the data
␍ structures [A,B|Rest] and [B,A|Rest], or templates for them, are
␍ created when the program is compiled, and unification gives values
␍ to the variables at run time.
␍ Avoid assert and retract.
␍ Beginners tend to overuse the assert and retract predicates
␍ to modify the knowledge base. There are two good reasons not to do
␍ so: assert and retract are relatively slow, and, perhaps more
␍ importantly, they lead to messy logic.
␍ Even the slowness is twofold. It takes appreciable time to
␍ perform an assert or retract. Further, in most implementations, a
␍ predicate that has been (or can be) modified by assert or retract
␍ cannot run at full compiled speed.2,3 (ALS Prolog is a striking
␍ exception.4)
␍ More importantly, the haphazard use of assert and retract
␍ confuses the program logic. The effects of assert and retract are
␍ not undone by backtracking. By contrast, most predicates return
␍ their results by instantiating variables; these instantiations are
␍ discarded if the overall goal fails, and you get only the results
␍ of computations that have succeeded. If you use assert as a
␍ general way to store temporary data, you will end up unable to
␍ tell whether the data came from successful computations. This can
␍ make programs very hard to debug.
␍
␍ Covington -- Efficient Prolog 5
␍ The normal way to store temporary information is to pass it
␍ along from one step to the next as arguments to procedures. The
␍ legitimate uses of assert and retract are to record new knowledge
␍ in the knowledge base (in a program that "learns") and, less
␍ commonly, to store the intermediate results of a computation that
␍ must backtrack past the point at which it gets its result. Even in
␍ the latter case, the built-in predicates bagof and setof often
␍ provide a better way to collect alternative solutions into a
␍ single structure. They are implemented in hand-optimized machine
␍ code and are faster than anything you could construct in Prolog.
␍ Understand tokenization.
␍ The internal memory representation of data in Prolog can be
␍ quite different from the printed representation. The fundamental
␍ unit is the term, of which there are three types: numbers, atoms,
␍ and structures. Numbers are stored in fixed-point or floating-
␍ point binary, the same as in most other programming languages.
␍ Atoms and structures have representations specific to Prolog.
␍ Atoms are stored in a symbol table in which each atom occurs
␍ only once; atoms in the program are replaced by their addresses in
␍ the symbol table. This is called interning or tokenization of the
␍ atoms, and it is performed whenever Prolog reads atoms and
␍ recognizes them as such -- when loading the program, accepting
␍ queries from the keyboard, or even accepting input at run time
␍ with the read predicate. Whenever an atom exists, it is in the
␍ symbol table.
␍ Because of tokenization, a Prolog data structure can be much
␍ shorter than it looks: repeated occurrences of the same atom take
␍ up little additional space. Despite its appearance, the structure
␍ f('What a long atom this seems to be',
␍ 'What a long atom this seems to be',
␍ 'What a long atom this seems to be')
␍ is very compact -- possibly smaller than g(aaaaa,bbbbb,ccccc). The
␍ memory representations of these two structures are shown in Figure
␍ 1.
␍ Further, atoms can be compared more quickly than anything
␍ else except numbers. To compare two atoms, even long ones, the
␍ computer need only compare their addresses. By contrast, comparing
␍ lists or structures requires every element to be examined
␍ individually.
␍ Consider for example the following two tests:
␍ a \= b
␍
␍ Covington -- Efficient Prolog 6
␍ aaaaaaaa \= aaaaaaab
␍ Without tokenization, the second test would take longer because it
␍ would be necessary to compare eight corresponding characters
␍ instead of just one. In Prolog, however, the second test is just
␍ as fast as the first, because all that it does is verify that two
␍ addresses in the symbol table are different. The strings aaaaaaaa
␍ and aaaaaaab were assigned to distinct addresses once and for all
␍ when they were first tokenized.
␍ Avoid string processing.
␍ Character string handling is rarely needed in Prolog except
␍ to convert printable strings into more meaningful structures.5
␍ The input to a natural language parser, for instance, should be
␍ [the,dog,chased,the,cat]
␍
␍ rather than
␍ "the dog chased the cat"
␍ so that the benefits of tokenization can be obtained.
␍ Character strings in Prolog are bulky. Whereas abc is a
␍ single atom, the string "abc" is a list of numbers representing
␍ ASCII codes, i.e., [97,98,99]. Recall that a list, in turn, is a
␍ head and a tail held together by the functor '.', so that
␍ [97,98,99] is really .(97,.(98,.(99,[]))), represented internally
␍ as shown in Fig. 2. Strings are designed to be easily taken apart;
␍ their only proper use is in situations where access to the
␍ individual characters is essential.
␍ Arity/Prolog has an alternative type of string, written
␍ $abc$ or the like, that is stored compactly but not interned in
␍ the symbol table.6 This is important because there is usually a
␍ limit on the number of symbols in the table; a program with lots
␍ of textual messages can avoid hitting this limit by using $-
␍ strings instead of long atoms.
␍ The built-in predicate read tokenizes its input. Many
␍ implementations provide predicates that are like read except that
␍ they accept input from a list of characters. With such a
␍ predicate, it is easy to preprocess a character string to make it
␍ follow Prolog syntax, then convert it to a Prolog term.
␍ Recognize tail recursion.
␍ Because Prolog has no loop structures, the only way to
␍ express repetition is through recursion. Variables that change
␍
␍ Covington -- Efficient Prolog 7
␍ value from one iteration to the next must be passed along as
␍ arguments, thus:
␍ count(N) :-
␍ write(N), nl,
␍ NewN is N+1,
␍ count(NewN).
␍ Recursion can be inefficient because, in general, each
␍ procedure call requires information to be saved so that control
␍ can return to the calling procedure. Thus, if a clause calls
␍ itself 1000 times, there will be 1000 copies of its stack frame in
␍ memory.
␍ There is one exception. Tail recursion is the special case
␍ in which control need not return to the calling procedure because
␍ there is nothing more for it to do. In this case the called
␍ procedure can be entered by a simple jump without creating a stack
␍ frame.
␍ Most Prologs recognize tail recursion and transform it into
␍ iteration so that repeated execution does not consume memory. In
␍ Prolog, tail recursion exists when:
␍ (1) the recursive call is the last subgoal in the clause;
␍ (2) there are no untried alternative clauses;
␍ (3) there are no untried alternatives for any subgoal
␍ preceding the recursive call in the same clause.
␍ Figure 3 shows a tail recursive predicate and three
␍ predicates that are not tail recursive for different reasons.
␍ A tail recursive predicate normally contains one or more
␍ tests to stop the recursion. These must normally precede the
␍ recursive clause, thus:
␍ count_to_100(X) :-
␍ X > 100.
␍ /* succeed and do nothing */
␍ count_to_100(X) :-
␍ X =< 100,
␍ write(X), nl,
␍ NewX is X+1,
␍ count_to_100(NewX).
␍ However, the recursive clause can be followed by other clauses if,
␍ at the time of the call, they will have been ruled out by cuts or
␍ by indexing (see below).
␍
␍ Covington -- Efficient Prolog 8
␍ The lack of conventional loop constructs is not a flaw in
␍ Prolog. On the contrary, it makes it easier to prove theorems
␍ about how Prolog programs behave. For years, mathematicians have
␍ dealt with repetitive patterns by using inductive proofs -- that
␍ is, by substituting recursion for iteration. Prolog does the same
␍ thing. After years of using both Prolog and Pascal almost daily, I
␍ find the Prolog approach to repetition less error-prone.
␍ Let indexing help.
␍ To find a clause that matches the query
␍ ?- f(a,b).
␍ the Prolog system does not look at all the clauses in the
␍ knowledge base -- only the clauses for f. Associated with the
␍ functor f is a pointer or hashing function that sends the search
␍ routine directly to the right place. This technique is known as
␍ indexing.
␍ Many implementations carry this further by indexing on not
␍ only the predicate, but also the principal functor of the first
␍ argument. In such an implementation, the search considers only
␍ clauses that match f(a,...) and neglects clauses such as f(b,c).
␍ First-argument indexing is a trade-off. Its intent is to
␍ save execution time and, even more importantly, to save memory by
␍ reducing the need to record backtrack points. But the indexing
␍ process itself complicates the search by requiring more analysis
␍ of the thing being searched for. Indexing on the principal functor
␍ of the first argument represents a reasonable compromise.
␍ Indexing has two practical consequences. First, arguments
␍ should be ordered so that the first argument is the one most
␍ likely to be known at search time, and preferably the most
␍ diverse. With first-argument indexing, the clauses
␍ f(a,x).
␍ f(b,x).
␍ f(c,x).
␍ can often be searched in one step, whereas the clauses
␍ f(x,a).
␍ f(x,b).
␍ f(x,c).
␍ always require three steps because indexing cannot distinguish
␍ them.
␍
␍ Covington -- Efficient Prolog 9
␍ Second, indexing can make a predicate tail recursive when it
␍ otherwise would not be. For example,
␍ f(x(A,B)) :- f(A).
␍ f(q).
␍ is tail recursive even though the recursive call is not in the
␍ last clause, because indexing eliminates the last clause from
␍ consideration: any argument that matches x(A,B) cannot match q.
␍ The same is true of list processing predicates of the form
␍ f([Head|Tail],...) :- ...
␍ f([],...).
␍ because indexing distinguishes non-empty lists from [].
␍ Use mode declarations.
␍ Normally, Prolog assumes that each of the arguments to a
␍ predicate may be instantiated or uninstantiated. This results in
␍ compiled code that branches to several alternative versions of
␍ each procedure in order to handle all the combinations.
␍ Most compilers provide a mode statement that allows you to
␍ rule out some of the alternatives and thereby speed up execution.
␍ For instance, the predicate
␍ capital_of(georgia,atlanta).
␍ can be used with either argument instantiated, or both, or none,
␍ but if written as
␍ :- mode capital_of(+,-).
␍ capital_of(georgia,atlanta).
␍ it requires the first argument to be instantiated and the second
␍ to be uninstantiated.
␍ Add mode declarations cautiously after the code has been
␍ debugged. At least one manual warns ominously that if the mode
␍ declarations are violated, "In some cases, the program will work.
␍ In others, your program will produce erroneous results or not work
␍ at all."7
␍ The ideal Prolog compiler would perform dataflow analysis
␍ and generate at least some of its mode declarations
␍ automatically.8,9
␍
␍ Covington -- Efficient Prolog 10
␍ Work at the beginning of the list.
␍ The only directly accessible element of a list is the first
␍ one. It pays to perform all manipulations there and avoid, as far
␍ as possible, traversing the whole length of the list.
␍ Sometimes this entails building the list backward. After
␍ all, there is nothing sacred about the left-to-right order in
␍ which lists are normally printed. For example, a program that
␍ solves a maze might record its steps by adding them at the
␍ beginning of a list. The result is a list giving the path,
␍ backward.
␍ Working at the beginning of the list can really pay off in
␍ efficiency. A classic example is a way of reversing a list. The
␍ familiar, inefficient "naive reverse" predicate is the following:
␍ reverse([],[]).
␍ reverse([H|T],Result) :-
␍ reverse(T,ReversedT),
␍ append(ReversedT,[H],Result).
␍ But reversing an N-element list this way takes time proportional
␍ to N2. One factor of N comes from the fact that reverse is called
␍ once for each list element. The other factor of N comes from
␍ append(ReversedT,[H],Result) because append has to step through
␍ all the elements of ReversedT in order to get to the end and
␍ attach [H]. This takes time proportional to the length of
␍ ReversedT, which in turn is proportional to N.
␍ A faster way to reverse a list is to extract elements one by
␍ one from the beginning of one list and add them at the beginning
␍ of another. This requires a three-argument procedure, where the
␍ third argument is used to return the final result:
␍ fast_reverse(List1,List2) :-
␍ fr(List1,[],List2).
␍ fr([Head|Tail],SoFar,Result) :-
␍ fr(Tail,[Head|SoFar],Result).
␍ fr([],SoFar,SoFar).
␍ The first clause of fr transfers the first element of [Head|Tail]
␍ to SoFar, then calls itself to do the same thing again. When
␍ [Head|Tail] becomes empty, the second clause of fr unifies SoFar
␍ with Result. The process takes linear time.
␍
␍ Covington -- Efficient Prolog 11
␍ Avoid CONSing.
␍ In Prolog, as in Lisp, it is much easier to examine existing
␍ structures than to create new ones. Creating new structures (known
␍ in Lisp as CONSing) requires dynamic allocation of memory.
␍ If, therefore, the same computation can be done with or
␍ without CONSing, the version that avoids CONSing will be faster.
␍ Often, CONSing is avoided simply by working at the beginning of
␍ the list. Sterling and Shapiro illustrate this with two algorithms
␍ to test whether one list is a sublist of another.10
␍ Another way to avoid CONSing is to build structures by
␍ progressive instantiation rather than by copying. Most Prolog
␍ predicates that modify structures do so by building, from the
␍ original structure, a new one that is different in some way;
␍ append, reverse, and similar list manipulations are familiar
␍ examples. The alternative is to add information to a structure by
␍ instantiating parts of it that were originally uninstantiated.
␍ For example, the list [a,b,c|X] can be turned into
␍ [a,b,c,d|Y], without CONSing, simply by instantiating X as [d|Y].
␍ Such a list, with an uninstantiated tail, is called an open list.
␍ The same principle can be used to build open trees and open data
␍ structures of other shapes.
␍ The problem with [a,b,c|X] is that the only way to get to
␍ the X is to work down the list starting at a. Although this does
␍ not require CONSing, it does take time. Processing can go faster
␍ if another instance of X is kept outside the list where it can be
␍ accessed directly. The resulting structure is called a difference
␍ list and has the form
␍ f([a,b,c|X],X)
␍ where f is any two-argument functor; the infix operators / and -
␍ are often used for the purpose, and the above list is written
␍ [a,b,c|X]-X or the like.
␍ Difference lists can be concatenated very quickly -- once --
␍ by instantiating the tail of the first list to the whole of the
␍ second list. The first list then becomes the result of the
␍ concatenation; there is no third, concatenated, list to be
␍ produced. This is the Prolog equivalent of the LISP function
␍ RPLACD. It is somewhat less destructive because, like all Prolog
␍ instantiations, difference list concatenations are undone upon
␍ backtracking.
␍ Conclusion
␍
␍ Covington -- Efficient Prolog 12
␍ All these techniques for improving efficiency share a common
␍ thread -- awareness of procedural aspects of a declarative
␍ language. This does not mean they are all low-level, inelegant
␍ "tricks" that purists should ignore.
␍ Some of the techniques are low-level, such as indexing and
␍ tail recursion optimization. Prolog would still be Prolog if these
␍ features were eliminated or changed radically. The decision to
␍ index on the principal functor of the first argument is certainly
␍ arbitrary, and if indexing went away tomorrow, some programs would
␍ lose efficiency but none would lose correctness.
␍ Other techniques, however, are purely algorithmic. Even when
␍ stated declaratively, algorithms consist of steps, and one
␍ algorithm can have more steps than another. It will always be
␍ faster to test the set-equivalence of lists by sorting than by
␍ permuting, simply because there are too many permutations, and no
␍ conceivable implementation can change this fact.
␍ Between the two extremes are data-structure-dependent
␍ techniques such as working at the beginning of a list. The first
␍ element of every list is the most accessible, not because of some
␍ quirk of implementation, but because the underlying semantics of
␍ Prolog says that [a,b,c] is really .(a,.(b,.(c,[]))). An
␍ optimizing implementation might provide faster access to list
␍ elements that are theoretically hard to get to, just as an
␍ optimizing Fortran compiler can move certain statements outside of
␍ loops, but one should not rely on the implementor to make the
␍ language more efficient than its semantics calls for.
␍ References
␍
␍ Covington -- Efficient Prolog 13
␍ 1. D. H. D. Warren and L. M. Pereira, "Prolog -- The Language and
␍ its Implementation Compared with Lisp," ACM SIGPLAN Notices, Vol.
␍ 12, No. 8, August 1977, pp. 109-115.
␍ 2. Quintus Prolog User's Guide, Quintus Computer Systems, Mountain
␍ View, Calif., version 11 for release 2.0, 1987, p. 98.
␍ 3. Using the Arity/Prolog Interpreter and Compiler, Arity
␍ Corporation, Concord, Mass., 1987, p. 104.
␍ 4. ALS Prolog 1.2, Applied Logic Systems, Syracuse, N.Y., 1988.
␍ 5. R. A. O'Keefe, "On String Concatenation," Prolog Digest, Vol.
␍ 5, No. 100.
␍ 6. Arity/Prolog 5.0, Arity Corporation, Concord, Mass., 1987.
␍ 7. Building Arity/Prolog Applications, Arity Corporation, Concord,
␍ Mass., 1986, p. 25.
␍ 8. C. S. Mellish, "Some Global Optimizations for a Prolog
␍ Compiler," Journal of Logic Programming, Vol. 2, 1985, pp. 43-66.
␍ 9. S. K. Debray and D. S. Warren, "Automatic Mode Inference for
␍ Prolog Programs," Proceedings, 1986 Symposium on Logic
␍ Programming, IEEE Computer Society, pp. 78-88.
␍ 10. L. Sterling and E. Shapiro, The Art of Prolog: Advanced
␍ Programming Techniques, M.I.T. Press, Cambridge, Mass., 1986, p.
␍ 194.
␍ Acknowledgement
␍ I want to thank Don Potter for helpful suggestions. All opinions
␍ and errors in this paper are of course my own.
␍
␍ Covington -- Efficient Prolog 14
␍ Figure 1.
␍ Memory representations of two structures.
␍ f('What a long atom this is',
␍ 'What a long atom this is',
␍ 'What a long atom this is')
␍ Symbol table
␍ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
␍ ÚÄÄÂÄÄÂÄÄÂÄÄ¿ ³f ³
␍ ³ ³ ³ ³ ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
␍ ÀÄÄÁÄÄÁÄÄÁÄÄÙ ³What a long atom... ³
␍ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
␍ g(aaaaa,bbbbb,ccccc).
␍ Symbol table
␍ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
␍ ÚÄÄÂÄÄÂÄÄÂÄÄ¿ ³g ³
␍ ³ ³ ³ ³ ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
␍ ÀÄÄÁÄÄÁÄÄÁÄÄÙ ³aaaaa ³
␍ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
␍ ³bbbbb ³
␍ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
␍ ³ccccc ³
␍ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
␍
␍
␍ Covington -- Efficient Prolog 15
␍ Figure 2.
␍ Internal representation of the list [97,98,99] (equivalent to the
␍ string "abc").
␍
␍ ÚÄÄÂÄÄÂÄÄ¿
␍ ³ ³ ³ ³
␍ ÀÄÄÁÄÄÁÄÄÙ
␍ ÚÄÄÂÄÄÂÄÄ¿
␍ ³ ³ ³ ³
␍ ÀÄÄÁÄÄÁÄÄÙ
␍
␍ ÚÄÄÂÄÄÂÄÄ¿
␍ ³ ³ ³ ³
␍ ÀÄÄÁÄÄÁÄÄÙ
␍ Symbol table
␍ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
␍ ³[] (End of list) ³
␍ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´
␍ ³. (List constructor)³
␍ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
␍
␍
␍ Covington -- Efficient Prolog 16
␍ Figure 3.
␍ Recursion does not consume memory if the recursive call is the
␍ very last step of the calling procedure.
␍ % This predicate is tail recursive
␍ % and can run forever.
␍ test1 :- write(hello), nl, test1.
␍ % This predicate is not tail recursive
␍ % because the recursive call is not last.
␍ test2 :- test2, write(hello), nl.
␍ % This predicate is not tail recursive
␍ % because it has an untried alternative.
␍ test3 :- write(hello), nl, test3.
␍ test3 :- write(goodbye).
␍ % This predicate is not tail recursive
␍ % because a subgoal has an untried alternative.
␍ test4 :- g, write(hello), nl, test4.
␍ g :- write(starting).
␍ g :- write(beginning).
␍
programming/AI/ai199001.txt
+2182
View File
File diff suppressed because it is too large Load Diff
programming/AI/ai199002.txt
+2132
View File
File diff suppressed because it is too large Load Diff
programming/AI/ai199101.txt
+2021
View File
File diff suppressed because it is too large Load Diff
programming/AI/alife
+284
View File
@@ -0,0 +1,284 @@
91-03/ALIFE.inf
From: ray@chopin.udel.edu (Thomas Ray)
Subject: Synthetic Life (evolving computer worms) (LONG)
Date: 17 Mar 91 20:46:33 GMT
Organization: University of Delaware
[MODERATOR'S NOTE: The following is posted as a test of this group's
interest in the topic at hand, "artificial life" (i.e., "organisms"
that dwell in programs running on computers). I would appreciate your
response, via private email to me, regarding how useful or not you find
this information.
[Thomas originally posted this information for a group studying artificial
life at the University of Delaware, so there is some site-specific reportage
at the end which you may or may not find useful. -- Bob Jacobson]
Peter Arensburger writes:
> A couple of days ago I was listening to a talk by Richard Dawkins about
> modeling evolutionary processes on a computer. He mentioned an experiment
> by Thomas Ray in which small (40 instructions long) autoreproducing programs
> where allowed to spread freely in a certain amount of memory. Then, by
> randomly mutating some of the programs you could see mutant programs
> become better adapted for reproduction.
...
> Has anyone heard about this experiment? If so please answer by e-mail.
The work Peter describes is in press, and should be available in May:
Ray, T. S. In Press. An approach to the synthesis of life.
In: Artificial Life II, Santa Fe Institute Studies in the Sciences of
Complexity, vol. XI, (Farmer, J. D., C. Langton, S. Rasmussen, & C. Taylor,
eds). Redwood City, CA: Addison-Wesley, 1991.
Although I don't have a paper in it, you might be interested in the
following book which is available now:
Langton, Christopher G. [ed.]. 1989. Artificial life: proceedings of an
interdisciplinary workshop on the synthesis and simulation of living systems.
Vol. VI in the series: Santa Fe Institute studies in the sciences of
complexity. Addison-Wesley.
Also, I will present the work in a seminar at Princeton (biology) on
April 5, 1991.
If anyone can't wait till May, I could email them a LaTeX version
of the manuscript. Below I attach an abstract, and then a summary of
the current activities of my research group.
This is a slightly expanded version of an abstract describing this work, which
was submitted to:
European Society for Evolutionary Biology, Third Congress. Debrecen, Hungary
September 2 - 6. Contact: Dr. Liz Pasztor - Department of Genetics -
Eotvos University 1088 Budapest - Muzeum krt. 4/a. - Hungary.
-------------------------begin abstract-----------------------------------
Synthetic Life: co-evolution in digital organisms.
THOMAS S. RAY. University of Delaware, Newark, DE, 19716, USA,
ray@brahms.udel.edu. 302-451-2753
Ideally, the science of biology should embrace all forms of life. However
in practice, it has been restricted to the study of a single instance of
life, life on earth. Because our science of biology is based on a sample
size of one, we can not know what features of life are peculiar to earth,
and what features are general, characteristic of all life. A practical
alternative to a truly comparative inter-planetary biology, is to create
synthetic life. Evolution in a bottle provides a valuable tool for the
experimental study of evolution and ecology.
Synthetic organisms have been created based on a computer metaphor of
organic life in which CPU time is the ``energy'' resource and memory is
the ``material'' resource. Memory is organized into informational
patterns that exploit CPU time for self-replication. Mutation generates
new forms, and evolution proceeds by natural selection as different
genotypes compete for CPU time and memory space. The creatures are
self-replicating computer programs, however, they can not escape because
they run exclusively on a virtual computer in its unique machine language.
The virtual computer is effectively a containment facility.
A single rudimentary ancestral ``creature'' has been designed; it is 80
machine instructions long and contains only the code for self-replication.
This creature examines itself, determines its size and location in the
memory ``soup'', and then copies itself, one instruction at a time, to
another location in the soup. The ancestral creature does not interact
directly with other individuals, although there is scrambling competition
for access to memory space.
A reaper kills creatures, assuring that there is always free space into which
creatures can reproduce. When creatures are born, they enter the bottom of
the reaper queue, and the reaper always kills off the top, which is usually
the oldest creature. However, mutant creatures often generate errors, which
cause them to rise in the reaper queue and be killed.
>From a single rudimentary ancestral ``creature'' there have evolved tens of
thousands of self-replicating genotypes of many hundreds of genome size
classes. Bit flipping mutations cause changes in the sequence of instructions
in the genome, but they do not cause changes in the size of the genome.
However, mutant genotypes make errors in their self-examination and
replication, resulting in different sized genomes. As genetic change
generates new genotypes, variants appear which are able to replicate more
rapidly that their ancestors, and those variants increase in frequency in
the soup.
Very quickly there evolve parasites, which are not able to replicate in
isolation because they lack a large portion of the genome. However, these
parasites search for the missing information, and if they locate it in a
nearby creature, they parasitize the information from the neighboring genome,
thereby effecting their own replication. This informational parasitism is
a commensal relationship, as it is not directly detrimental to the host.
However, the parasites do compete with the hosts for space, and may be
superior competitors because they can more rapidly replicate their smaller
genome. However, their advantage is frequency dependent. As the parasites
increase in frequency, the hosts decline, and many parasites fail to locate
hosts. In ecological runs, without genetic change, hosts and parasites
demonstrate Lotka-Volterra cycles.
In some runs, hosts evolve immunity to attack by parasites. One immune
mechanism that has been worked out is based on the fact that the creatures
only examine themselves once, and rely on retaining the information on their
size and location for all subsequent replications. Immune hosts cause their
parasites to loose their sense of self by failing to retain the information
on size and location. Immune hosts function with this forgetful code by
re-examining themselves before each repliction, thus there is a metabolic
cost to the immunity.
When immune hosts appear, they often increase in frequency, devastating the
parasite populations. In some runs where the community comes to be
dominated by immune hosts, parasites evolve that are resistant to immunity.
The above mentioned immune mechanism can by circumvented by parasites which
also re-examine themselves before each replication.
Hosts sometimes evolve a response to parasites that goes beyond immunity to
actual hyper-parasitism. Hyper-parasites allow themselves to be parasitized,
letting the parasite use their code for a single replication. After the
first replication, the hyper-parasite deceives the parasite by replacing the
parasite's record of its size and location with the size and location of the
hyper-parasite genome. Thereafter, the parasite will devote its energetic
resources to replication of the hyper-parastie genome. This is a highly
deleterious interaction, which drives the parasites to extinction. The
hyper-parasites are facultative, getting an energy boost when the parasites
are present, but not requiring them for replication.
Evolving in the absence of parasites, hyper-parasites completely dominate
the community, resulting in a relatively uniform community characterize by
a high degree of relationship between individuals. Under these circumstances,
sociality evolves, in the sense that the creatures evolve into forms which
can not replicate in isolation, but which can only replicate in aggregations.
These colonial creatures cooperate in the control of the flow of execution of
their algorithms.
The cooperative behavior of the social hyper-parasites makes them vulnerable
to a new class of parasites. These cheaters, hyper-hyper-parasites, insert
themselves between cooperating social individuals, and momentarily seize
control of execution of the algroithm, just long enough to deceive the
social creatures about their size and location, causing the social creatures
to replicate the genomes of the cheaters.
In a separate experiment, two versions of the ancestral creature were made,
each with a different portion of the genome deleted. Neither of these
genomes were able to replicate in isolation. However, when cultured together,
they each parasitize the missing code from the other, forming an ecologically
stable obligate symbiotic relationship. When genetic change is allowed in
the system, a very complex series of changes follows, ultimately resulting
in the merging of the two genomes into a single self-replicating genome.
The only kind of genetic change that the simulator imposes on the system is
random bit flips in the machine code of the creatures. However, it turns
out that parasites are very sloppy replicators. They cause significant
recombination and rearrangement of the genomes. This spontaneous sexuality
is a powerful force for evolutionary change in the system.
A series of experiments were conducted on the effects of mutation rates on
the rates of evolution. The parameter used to compare rates of evolution
was the rate at which self-replicating genomes decreased in size, indicating
an optimization, in an environment favoring smaller sizes. The optimal
mutation rate was found to be a mutation affecting one in four individuals
per generation. At higher rates the community sometimes died out, as genomes
melted under the mutational heat. At lower rates, optimization was slower.
Fully self-replicating (non-parasitic) genomes reduced from 80 instructions
to 22 instructions overnight (more than 1500 generations, of populations
ranging from 300 to 1000 individuals). The ancestor of size 80 requires
839 CPU cycles to replicate. The creature of size 22 requires 146 CPU cycles
to replicate, a 5.75-fold difference in efficiency.
One of the most interesting aspects of this second instance of life is
that the bulk of the evolution is based on adaptation to the biotic
environment rather than the physical environment. It is co-evolution
that drives the system.
It is possible to extract information on any aspect of the system
without disturbing it, from phylogeny or community structure through time
to the ``genetic makeup'' and ``metabolic processes'' of individuals.
Synthetic Life demonstrates the power of the computational approach to
science as a complement to the traditional approaches of experiment and
theory based on analysis through calculus and differential equations.
I will make an oral presentation. I will need an overhead projector, and
two three-pronged power outlets nearby to plug in the computer and LCD panel.
---------------------------end abstract----------------------------------
This message was distributed internally to the University of Delaware
Synthetic Life group. I thought that other AL fans might be interested
to know what we are up to:
We haven't met as a group for some time, so I thought I would send out
this progress report.
TECHNOLOGY REVIEW ARTICLE - The next issue of Technology Review (April/May),
due out in March, will include an article on Artificial Life. They
will describe (among other things) the work of our group, and will include
a series of four color photos of the ALmond Monitor of Tierra that Marc Cygnus
has developed.
ALMOND TALKS - Marc Cygnus has got the ALmond monitor program talking to
the Tierra simulator using network communications. We can now have multiple
simulators running on multiple machines, and monitor them from multiple
monitors on multiple machines. The monitors can attach to and detach from
the simulators without disturbing them.
AL AND GA - Chris Bryden has completed his term paper discussing the
relationships between synthetic life and genetic algorithms.
THE MATRIX OF LIFE - John Billon has completed his independent study by
exploring the possibility of implementing a synthetic life system in a
matrix based environment.
THE GENETIC LANGUAGE - Dan Pirone has designed a much more powerful version
of the Tierran language, and has the bulk of the new instruction set coded.
The syntax is much more complex than the original Tierran. We are hoping that
it will be as evolvable.
OPTIMIZATION OF TIERRA - Tom Uffner has tackled the task of optimizing the
tierra simulator code. He is starting with the genebank manager which works,
but is very inefficient. His proposals for optimization sound very promising.
DIVERSITY AND TURNOVER - Eric Andrews and Jim Timmons are developing code to
monitor diversity and turnover rates of size classes and genotypes in the
soups. They are already generating the diversity indices, and are working
on the turnover rates.
AUTECOLOGY - Over winter session I automated the analysis of ecological
interactions between creatures. Now when genotypes are saved to disk, the
code that is actually executed is marked, to distinguish it from "junk"
(unexecuted) code. Also, the basic classes of ecological interactions have
been identified, and the interactions engaged in by a genotype are marked in
a bit field that is saved with each genotype.
EVOLUTIONARY OPTIMIZATION OF MACHINE CODES - I completed a study of the effect
of mutation rate on the rate of evolution. As an index of the rate of
evolution, I used the rate at which self-replicating machine code programs
reduce their size. The optimal mutation rate was one that hit about one in
four programs per generation. At higher rates, the communities sometimes
died out, as genomes melted under the mutational heat. The programs reduced
themselves from 80 machine instructions to 22 machine instructions overnight
(over 1500 generations, of populations ranging from 300 to 1000 individuals).
There was a 5.75-fold decrease in the number of CPU cycles required for
replication.
IRISVILLE OPENS - The two Silicon Graphics machines and the Sun in 114 Wolf
are up and running and on the net. life.slhs.udel.edu is a 4D25TG Personal
Iris with 32MB of memory and a 1.2 GB disk. tierra.slhs.udel.edu is a
4D258 (Iris) Data Station Server with 32MB of memory and a 1.2 GB disk.
genie.slhs.udel.edu is a Sun 3/60 with 8MB of memory, about 300 MB of disk,
and a color monitor. The Irises are rated at 16 MIPS each, and the Sun at
about 4 MIPS. These machines are for the exclusive use of the School of
Life and Health Sciences (SLHS), which so far has meant just for the alife
group. The two Irises have been running the Tierra simulator around the
clock since they came up.
Tom Ray
University of Delaware
School of Life & Health Sciences
Newark, Delaware 19716
ray@brahms.udel.edu
302-451-2281 (FAX)
302-451-2753
programming/AI/code_ai.txt
+198
View File
@@ -0,0 +1,198 @@
<Edited by x2ftp admin>
Shortly after Tim Triemstra and I posted articles discussing strategy
game AI to rec.games.programmer, a Danish student by the name of
Peer Sommerlund (peso@diku.dk) posted an article in which he
outlined an object-based "methodology" for implementing an AI system
which combined my ideas with Tim's. I was impressed by the effort
which Peer put into his article and wrote to him, suggesting that I
would like to see his posting, Tim's postings and my "essay" appear
together at x2ftp.oulu.fi. When Peer expressed his approval of the
idea, I contacted Tim, who was also keen to be a part of the venture.
--- Andrew
e-mail addresses:
Peer Sommerlund: peso@diku.dk
Tim Triemstra: empath@umcc.umich.edu
Jouni: Yes, we are very interested in computer opponent AI and want
more theory, ideas, implementations, source code, anything =-)
--------------------(Peer Sommerlund's article)--------------------
Newsgroups: rec.games.programmer
From: peso@diku.dk (Peer Sommerlund)
Subject: Re: AI programming (ala Civ, Moo, etc.)
Date: Fri, 2 Dec 1994 17:03:22 GMT
andrew@cs.uct.ac.za (Andrew Luppnow) writes:
> empath@umcc.umcc.umich.edu (Tim Triemstra) writes:
>[Summary of a computer-player-AI technique based on "situations."]
>
>Tim's post reminded me of a little "essay" on the topic of
>strategy-game AI which I wrote last year. I just thought I'd
>dredge it up and see what you all think of the ideas I was
>toying with back then. Hope the splurge below doesn't bore you
>too much! ;-)
[Andrew defines a hieracial system of situations]
I think the two ideas match nicely. Tim has described a nice way of building
prototypes for your game, Andrew has described a way to build larger systems
(ie. ISS wargames).
I like Tim's idea, especially the point about "the one that fits the current
situation best". This way you could get your game up running fast, and
refine it as you find weaknesses. You may even make your rule-database
user-modifiable!
A system that can be gradually expaned is very usefull. You might even make
a system that can start at 1 level then later expand by building a higher
level function. And another, etc..
Let's call Tim's expansions for "horizontal expansion"
and Andrew's for "vertical expansion"
So, you should define two classes:
class action
class actor
Action is what your actors do.
Let's take an example
Actor Tank1, Tank2, Boss;
Actor gets goal from higher level, send goals to lower levels, gets progress
>from lower levels, sends progress to higher levels
Action =
"move this direction", etc..
Actor loop :
get goal
decide strategy
deploy strategy
evaluate strategy
report to superior
deploy strategy:
send goal to lower level
get report from lower level
Ok, now all this should be running concurrently!
Actor loop:
switch
case new goal: redesign strategy
case report available: evaluate strategy
redesign strategy:
get goal
evaluate current strategy
if strategy needs change
change strategy
send new goals to lower levels
evaluate strategy:
see if current reports matches with current goal,
can I optimize the situation by sending new goals to subordinates?
if the situation has changed since last time superior was notified,
tell him.
Right. A concurrent Actor should know the following things:
- last reports send to superior
- last goals send to subordinates
- current goal recieved from superior
- current reports recieved from subordinates
.. and the interesting part:
- how to match goals and reports
You may want to use Tim's excelent method here: A collection of
situations (S), a distance measuerement (D) between situations, an
action (A) connected to each situation.
You find the S that is closest to the current situation S0 by minimizing
D(S,S0). Then you apply the matching A. If you're clever, you'll sort the
situations some way, and your search will be much quicker, but this is not
neccesary in the first attempts to get things up running.
so, "how to match goals and reports": Your situation has the following
attributes: (last_goal_recieved, last_goals_send, last_reports_recieved,
last_report_send) ... perhaps a few more: time, your location, etc.
Just to be able to differ between goals going up and down, lets use this
wording:
superior
A | Goal
| Summary V
me
A | Command
| Report V
subordinate
.. well, lots of talk. Back to the example:
T1
E
T2
This is a simple 2D game. Let's say each tank has a cannon that only points
forwards, a tank turns slowly, so an escape strategy is to move a lot. The
bullets take some time to hit target, so you can move forward, wait untill
enemy points at you, then move back, etc. Also, the tank cannot turn, and
move, at the same time.
Some technical details:
There is 32 directions your tank can face.
Your tank is a circle with diameter 8,
tank speed 0.1 unit/frame,
cannon reload: 100 frames
the bullet has diameter 1.
bullet speed 1 unit/frame,
bullet range: unlimited,
An overall strategy (the boss) may be "surround": place a tank on opposite
sides, let one duge the cannon, while the other shoots him in the back.
Lets give the boss the following rules:
"split": if tanks are close, separate them
"surround": try to move the tanks such that ennemy is surrounded.
"prepare duge": don't move the tank so close to the enemy that
it cannot move away before it gets hit.
leading to this set of commands:
"move here, duge"
"move here, kill"
Let equip each tank with the following rules:
"survive", 9: if ennemy is targeted on you, move 1-2 squares
"kill", 5: if goal is "kill" rotate to target enemy, shoot
"move", 4: if goal is "move here" rotate to face target position,
move
"duge", 6: if you are off your target position, and duging, wait
until enemy cannon points at you.
commands:
"forward"
"backwards"
"wait" (don't move)
"turn left"
"turn right"
"shoot"
summary:
"current position"
Remember to put priorites on rules, you don't want the order of the rules
decide which rule should be executed.
regards,
-Peer
--
Peer Sommerlund \ Groenjordskollegiet v2512 \ 2300 Koebenhavn S \ Denmark
\ E-mail: peso@diku.dk
-------------------------------------------------------------------
programming/AI/deeptht.txt
+129
View File
@@ -0,0 +1,129 @@
DeepThought : The computer chess Champion
By : Anonymous Rebel
The artificial intelligence pioneer, Herbert Simon, predict-
ed that by 1967 a computer would be able to beat any human in
chess. However, he was quite far off. In 1989, the human mind
can still defeat even the greatest of computer chess machines.
Simon wasn't as far off as the critics of the Fifties, who
claimed that a computer could never master chess. A computer
called Deep Thought now plays at the level of a human grandmas-
ter, which means that only about 200 people in the world can
defeat him.
Deep Thought has not exactly been ranked as a grandmaster as
of yet, because according to Thomas Anantharaman, one of the
creators of Deep Thought, "You can't claim to be a grandmaster
unless you are a human being." However, this hasn't upset his
fellow creators or him. So far, they have won $10,000 from The
Fredkin Fund, for winning 25 straight games in world competition.
($100,000 is waiting for the first electronic world champion.)
Deep Thought follows the tradition of its computer predeces-
sors, by considering every possible move. Good human players
usually examine only a few moves, and rely on pattern recognition
and experience to succeed. This type of evaluation proves ex-
tremely difficult to program into a computer, although the former
computer chess champion, Hitech, was designed to recognized
certain programs. However, ruling out certain moves, without
fully examining all the possibilities will eventually lead to an
error in the computer's part.
Although a computer lacks the ability of insight, they make
it up in their ability to number crunch. For example, in a
typical situation, a chess player has 38 moves to consider. To
check all the responses would mean examining 1444 different
positions. To look one step ahead would mean checking over 2
million positions.
The secret of the computer's success, obviously, is its
incredible speed. Even a little toy chess computer is fast
enough to beat most people. The big time computers like Deep
Thought is even faster. In fact, the ultrafast electronics are
the source of power for all Fredkin prize hopefuls. Deep Thought
is simply the fastest around.
Deep thought is designed to examine five moves ahead. Since
this is far from seeing the end of a game, the machine must not
only check what positions it could end up in, but must evaluate
them as well. Typical considerations include the value of what
pieces will be captured, and whether the King will be put in
check. Deep Thought also checks its position on the board, and
the number of empty squares from which the King could be at-
tacked, and some 80 other items. Deep Thought gives numerical
values to all of the considerations, and uses the highest ranked
move.
All of the world-class chess computers uses certain varia-
tions on this approach. The reason for Deep Thought's success
is that it doesn't always hold itself to a few moves. If one
move seems particularly good, it searches down that path for up
to 15 moves. This strategy is called singular extension. If
Deep Thought registers an equally dangerous threat, it also
searches further, it works in the same manner, but this time its
called Threat Extension. If this feature comes into play, the
results are usually deadly for the opponent.
Deep Thought didn't used an experienced chess player to
assign relative values to its 80 considerations, like other chess
computers. Hitech had used Hans Berliner, a computer scientist
and a former world-class champion. "The fascination," Ananthara-
man says, "was writing a program that can do something I can't
do." Instead, the computer watched games played between human
grandmasters. One of the programmers "tuned" Deep Thought's
evaluation equation until it started choosing Grandmaster style
moves. First approximations were made in deciding the order.
Deep thought would use this hierarchy and replay the grandmaster
games. At first, Deep Thought played horribly. But after each
game, the program would change the rank slightly until Deep
Thought was playing like a true grandmaster. After 800 games,
Deep Thought was playing like a true master.
Anantharaman was truly surprised that the "tuning" worked as
well as it did. After evaluating the process, he decided that
this process is a better technique even if you have the expert
knowledge. The approach could also be used in other fields where
human experts aren't available. The trouble is that not many
problems are as well defined as that of chess. Some day the
thinking process would be useful to the military, but that is far
off. "Computer chess will give you an idea how to approach a
problem," says Anantharaman, "but it won't solve the problem
completely. I can't think of a single real-world problem that
has been solved by artificial intelligence."
Bibliography
"Pawn to King Four." Tom Waters. Discover Magazine,
May 1989. Volume 10, Number 5
X-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-X
Another file downloaded from: NIRVANAnet(tm)
& the Temple of the Screaming Electron Jeff Hunter 510-935-5845
Rat Head Ratsnatcher 510-524-3649
Burn This Flag Zardoz 408-363-9766
realitycheck Poindexter Fortran 415-567-7043
Lies Unlimited Mick Freen 415-583-4102
Specializing in conversations, obscure information, high explosives,
arcane knowledge, political extremism, diversive sexuality,
insane speculation, and wild rumours. ALL-TEXT BBS SYSTEMS.
Full access for first-time callers. We don't want to know who you are,
where you live, or what your phone number is. We are not Big Brother.
"Raw Data for Raw Nerves"
X-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-X
programming/AI/dobbs.txt
+445
View File
@@ -0,0 +1,445 @@
A Survey of Neural Networks
by Jeannette Lawrence
Jan. 23, 1990
I. Introduction
Neural networks have been hailed as the greatest technological
breakthrough since the transistor and have been predicted to be a common
household item by the year 2000. How much of this is hype? What are
they capable, or not capable of? With numerous paradigms available,
which is best for a particular application? This article will answer
these questions and more about this newly emerging field of computation.
Formed by simulated neurons connected together much the same way the
brain's neurons are, neural networks are able to associate and
generalize without rules. They have solved problems in pattern
recognition, robotics, speech processing, financial predicting and signal
processing, to name a few.
One of the first impressive neural networks was NetTalk, which read in
ASCII text and correctly pronounced the words (producing phonemes which
drove a speech chip), even those it had never seen before (1). Designed
by John Hopkins biophysicist Terry Sejnowski and Charles Rosenberg of
Princeton in 1986, this application made the Backprogagation training
algorithm famous. Using the same paradigm, a neural network has been
trained to classify sonar returns from an undersea mine and rock. This
classifier, designed by Sejnowski and R. Paul Gorman, performed better
than a nearest-neighbor classifier (2).
As far as the public is concerned, the modern era in neural networks
began in 1982 when the distinguished Caltech physicist John Hopfield
published a paper which not only showed that neural networks could store
and recall patterns even when the input was incomplete, it provided the
mathematical elucidation which captured the attention of the scientific
community. (3)
Speech recognition of Finnish and Japanese (to text) has been
demonstrated by researcher Teuvo Kohonen of the Helsinki University of
Technology, Finland. For these inflectional languages, the system must
construct the text from recognizable phonetics units. (4) This complex
system uses signal preprocessing by a TMS32010 chip, Kohonen's
self-organizing associative paradigm, and a context-sensitive stochastic
grammar corrector.
The Neocognitron, designed by Kunihiko Fukushima of the NHK Science and
Technical Research Lab in Tokyo, recognizes handwritten numerals of
various styles of penmanship correctly, even if they are considerably
distorted in shape (5). Built as a model for the human visual system,
this highly specialized network does not implement any common topology.
The kinds of problems best solved by neural networks are those that
people are good at such as association, evaluation and pattern
recognition. Problems that are difficult to compute and do not require
perfect answers, just very good answers, are also best done with neural
networks. A quick, very good response is often more desirable than a
more accurate answer which takes longer to compute. This is especially
true in robotics or industrial controller applications. Predictions of
behavior and general analysis of data are also affairs for neural
networks. In the financial arena, consumer loan analysis and financial
forecasting make good applications. New network designers are working
on weather forecasts by neural networks. Currently, doctors are
developing medical neural networks as an aid in diagnosis. Attorneys
and insurance companies are also working on neural networks to help
estimate the value of claims.
Neural networks are poor at precise calculations and serial processing.
They are also unable to predict or recognize anything that does not
inherently contain some sort of pattern. For example, they cannot
predict the lottery, since this is a random process. It is unlikely
that a neural network could be built which has the capacity to think as
well as a person does for two reasons. Neural networks are terrible at
deduction, or logical thinking and the human brain is just too complex
to completely simulate. Also, some problems are too difficult for
present technology. Real vision, for example, is a long way off.
A brief look at the general structure and operation of neural networks
will help explain the limits to their abilities. The power and speed of
the human brain comes from the way the hundreds of billions of highly
interconnected neurons function together. Neural networks simulate the
operation and structure of brain neurons, but on a much smaller scale.
Information is distributed across the neurons' interconnections, not as
bits of intelligence stored within the neurons as was once thought.
There are many types of neural networks, but all have three things in
common. A neural network can be described in terms of its individual
neurons, the connections between them (topology), and the learning rule.
Together they constitute the neural network paradigm.
Artificial neurons are also called processing elements, neurodes, units
or cells. Each neuron receives the output signals from many other
neurons. A neuron calculates its output by finding the weighted sum of
its inputs. The point where two neurons communicate is called a
connection (analogous to a synapse). The weight of a particular
connection is noted w^ij, where ^ij means subscripted ij, i is the
receiving neuron and j is the sending neuron. At any point in
time (t) the neuron adds up the weighted inputs to produce an
activation value a^i(t). The activation is passed through an
output, or transfer, function f^i, which produces the actual
output for that neuron for that time, o^i(t).
The activation function specifies what the neuron is to do with the
signals after the weights have had their effect. Once inside the
neuron, the weighted signals are summed to form a net value. In most
models, signals can either be excitatory or inhibitory. After
summation, the net input of the neuron is combined with the previous
state of the neuron to produce a new activation value. In the
simplest models, the activation function is the weighted sum of the
neuron's inputs; the previous state is not taken into account. In
more complicated models, the activation function also uses the
previous output of the neuron, so that the neuron can self-excite.
These activation functions slowly decay over time; an excited state
slowly returns to an inactive level. Sometimes the activation
function is stochastic, i.e. it includes a random noise factor.
The transfer function of a neuron defines how the activation value is
output. The earliest models used a linear transfer function. There are
certain problems which are not entirely reducable by purely linear
methods. Nonlinear neurons allow more interesting problems to be
solved. The most simple nonlinear model consists of threshold neurons.
A threshold transfer function is an all-or-nothing function. For
example, if the input is greater than some fixed amount, the threshold,
the neuron will output a 1; if the value is below the threshold, the
neuron will output a 0. Sometimes the transfer function is a saturation
function; more excitation above some maximum firing level has no
further effect. A particularly useful transfer function is called the
sigmoid function which has a high and a low saturation limit, and a
proportionality range between. This function is 0 when the activation
value is a large negative number. The sigmoid function is 1 when the
activation value is a large positive number, and makes a smooth
transition in between.
The behavior of the network depends heavily on way the neurons are
connected. In most models, the individual neurons are grouped into
layers, so that the output from each neuron in one layer is fully
interconnected with the inputs of all the neurons in the next layer. A
Back-propagation network has at least three layers: input, hidden and
output. The network structure may involve inhibitory connections from
one neuron to the rest of the neurons in the same layer. This is called
lateral inhibition. Sometimes a network has such strong lateral
inhibition that only one neuron in a layer, usually the output, can be
activated at a time. This effect of minimizing the number of active
neurons is known as competition. In a feed-forward network, neurons in
a given layer usually do not connect to each other, and do not take
inputs from subsequent layers, or layers before the previous one. Other
models include feedback connections from the outputs of a layer to the
inputs of the same or a previous layer.
A neural network learns by changing its response as the inputs change.
The learning rule is the very heart of a neural network; it determines
how the weights are adjusted as the neural network gains experience.
There are lots of different learning rules. Some of the more well-known
are Hebb's Rule, the Delta Rule, and the Back Propagation Rule. The
best learning rule to use with linear neurons is the Delta Rule. This
allows arbitrary associations to be learned, provided that the inputs
are all linearly independent. Other learning rules (such as Hebb's)
require that the inputs also be orthogonal.
More than 30 years ago, Donald O. Hebb theorized that biological
associative memory lies in the synaptic connections between nerve cells.
He thought that the process of learning and memory storage involved
changes in the strength with which nerve signals are transmitted across
individual synapses. Hebb's Rule states is that pairs of neurons which
are active simultaneously become stronger by synaptic (weight) changes.
The result is a reinforcement of those pathways in the the brain. A
number of different rules for adjusting connection strengths, or
weights, have been proposed, but nearly all network learning theories
are some variant of Hebb's Rule.
The Delta Rule additionally states that if there is a difference between
the actual output pattern and the desired output pattern during
training, then the weights are adjusted to reduce the difference.
Many networks use some variation of this. The Back-propagation Rule is
a generalization of the Delta Rule for a network with hidden neurons.
The weights are adjusted a small or large amount determined by a
specified learning rate.
II. Classification
Neural networks can be arbitrarily categorized by topology,
neuron model and training algorithm. There are two main
subdivisions of neural network models - feed-forward and feedback
topologies.
Feedback models can be constructed or trained. In a constructed model
the weight matrix is created by taking the outer product of every input
pattern vector with itself or with an associated input, and adding up
all the outer products. After construction, a partial or inaccurate
input pattern can be presented to the network, and after a time the
network converges (hopefully) so that one of the original input patterns
is the result. Hopfield and BAM are two well-known constructed feedback
models.
The Hopfield network is a self-organizing, associative memory.
It is the canonical feedback network. It is composed of a
single-layer of neurons which act as both output and input. The
neurons are symmetrically connected (i.e., w^ij = w^ji). Hopfield
networks are made of nonlinear neurons capable of assuming two
output values: -1 (off) and +1 (on). The linear synaptic weights
provide global communication of information. In spite of its
apparent simplicity, a Hopfield network has considerable
computational power.
The weight matrix is created by taking the outer product of each input
pattern vector with itself, and adding up all the outer products. After
construction, a pattern is input to the network. A process of
reaction-stimulation-reaction between neurons occurs until the network
settles down into a fixed pattern called a stable state. Thus, the
network result comes as a direct response to input.
The energy required by a device to reach a stable state can be plotted
in three dimensions as a curved surface. Areas of minimum energy are
thus found. The stable states, or energy minimums, appear as valleys.
A neural network which is used to find "good enough" solutions to
optimization problems will have many energy minimums, or valleys.
Depending upon the initial state of the network, any of the deepest
valleys may end up as the answer. Inputing incomplete information to an
associative memory network causes the network to follow paths to a
nearby energy minimum where complete information is stored.
Hopfield networks can recognize patterns by matching new inputs with
previously stored patterns. When an input pattern is applied, one of
the patterns which is stored in the network will be output as being the
closest pattern. Hopfield networks are especially good for finding the
best answer out of many possibilities. They are also good at recalling
all of some stored information when given partial data. Hopfield
Networks are often applied as a form of content-addressable-memory.
Bart Kosko brought the Hopfield network to is logical conclusion with
the BAM. The BAM (bidirectional associative memory) is a generalization
of the Hopfield network. Instead of creating the weight matrix with the
dot product of a pattern with itself (autoassociation), pairs of
patterns are used (pair association). After construction of the weight
matrix, either pattern can be applied as input to elicit as output the
other pattern in the pair.
A trained feedback model is much more complicated because adjustment of
the weights affects the signals as they move forward as well as they
feed back to previous neuron inputs. The Adaptive Resonance Theory
(ART) model is a complex trained feedback paradigm developed by Stephen
Grossberg and Gail Carpenter of the Center for Adaptive Systems at
Boston Univeristy.
ART neurons are functionally clustered into "nodes". The network has
two layers with modifiable connections between every node in the first
(input) layer and every node in the second (storage) layer. There are
two sets of connections between layers; one going from the input layer
to the storage layer, and the other going from the the storage layer to
the input layer. The storage layer also has lateral inhibition
connections. ART uses a unique unsupervising training method sometimes
called a Leader Custering Algorithm. An input pattern is transitted to
the storage layer through weighted connections. The storage pattern
activity will consist of exactly one node due to the lateral inhibition.
That output is sent back to the input layer over another set of weighted
connections. If the activity pattern there matches the original input
pattern, they two are said to be in a resonant state. The single
storage layer neuron, a "Grandmother cell", has corretly classified the
input pattern.
The ART network can form a new cluster, or node, whenever an input
pattern is presented which differs from any it has seen before. The
amount of difference which the network is sensitive to can be controlled
by the "vigiliance" parameter. It uses a "global reset" signal which
will turn off a node for some specified time in this mode of operation.
The second main category of neural networks is the feed-forward type.
The earliest neural network models were linear feed-forward. In 1972,
two simultaneous papers independently proposed the same model for an
associative memory, the linear associator. J. A. Anderson, a
neurophysiologist, and Teuvo Kohonen, an electrical engineer, were not
aware of each other's work.
The linear associator uses the simple Hebbian rule. The only case where
association is perfect when simple Hebbian learning is used is when the
input patterns are orthogonal. This puts an upper limit on the number
of patterns that can be stored. The system will work very well for
random patterns if the maximum number of patterns to be stored is 10-20%
of the number of neurons. If the input patterns are not orthogonal,
there will be interference among them; fewer patterns can be stored and
correctly retrieved. One of the predictions of the linear associator is
interference between nonorthogonal patterns. Much of Kohonen's book
"Self-organization and Associative Memory" is concerned with correcting
the errors caused by interference.
The nonlinear feed-forward models are the most commonly used today.
Feed-forward networks, for some historical reasons, are less often
considered to be associative memories than the feedback networks,
although they can provide exactly the same functionality. It can be
shown mathematically that any feedback network has an equivalent
feed-forward network which performs the same task.
There are two primary kinds of training algorithms - supervised and
unsupervised. Supervised learning is the most elementary form of
adaptation. It requires an a priori knowledge of what the result should
be. Output neurons are told what the ideal response to input signals
should be. For one-layer networks, in which the stimulus-response
relation can be controlled closely, this is easily accomplished by
monitoring each neuron individually. In multi-layer networks,
supervised learning is more difficult. It is harder to correct the
hidden layers. Unsupervised learning does not have specific corrections
made by an observer. Supervised and unsupervised learning are methods
which are used exclusively of each other.
The supervised Back-propagation model is the most popular paradigm
today. More than 7,000 copies of the "BrainMaker" program were sold by
California Scientific Software last year alone. Back-propagation is a
multi-layer feed-forward network that uses the Generalized Delta Rule.
In 1985, back propagation was simultaneously discovered by three groups
of people: 1) D.E. Rumelhart, G.E. Hinton, R.J. Williams, 2) Y. Le Cun,
and 3) D. Parker. Back propagation is the canonical feed-forward
network. Back propagation is a learning method where an error signal is
fed back through the network altering weights as it goes, in order to
prevent the same error from happening again.
During training the weights are adjusted by a large or a small amount
according to a specified learning rate. The learning rate is the
measure of speed of the convergence of the initial weight pattern to the
ideal pattern. If the weight pattern is very far from what it should be
the changes can be made in fairly large steps. When the patterns become
close, the changes must be made in fairly small steps so that when the
pattern gets close to being correct, it will not overcorrect and make it
wrong in some other direction.
The error on an output neuron, i, for a particular pattern, p, is
defined as: E^pi ð «(T^pi - O^pi)ý, where T is the target output
and O is the actual output. The total error on pattern p, E^p, is the
sum of the errors on all the output neurons for pattern p. The total
error, E, for all patterns is the sum of the errors on each pattern over
all p.
The simplest method for finding the minimum of E is known as gradient
descent. It involves moving a small step down the local gradient of the
scalar field. This is directly analogous to a skier always moving down
hill through the mountains, until he hits the bottom.
Back-propagation is useful because it provides a mathematical
explanation for the dynamics of the learning process. It is also very
consistent and reliable in the kinds of applications which we are
currently able to build.
A popular unsupervised feed-forward model is the Kohonen model. The
basic system is a one or two dimensional array of threshold-type logic
units with short-range lateral connections between neighboring neurons.
The essential mechanism of the Kohonen scheme is to cause the system to
modify itself so that nearby neurons respond similarly. The neurons
compete in a modified winner-take-all manner. The neuron whose weight
vector generates the largest dot product with the input vector is the
winner and is permitted to output. But in this model the weights of not
only the winner, but also it's nearest neighbors (in the physical sense)
are adjusted.
A special case of the feed-forward model is the Neocognitron. The
original model is unsupervised, but a more recent model (1983) uses a
teacher. The multilayer (seven or nine layer) system assumes that the
builder of the network knows roughly what kind of result is wanted. All
the neurons are of analog type; the inputs and outputs take nonnegative
values proportional to the instantaneous firing frequencies of actual
biological neurons. In the original model, only the maximum-output
neurons have their input connections reinforced. It uses a variation of
the Hebbian Rule. After learning is completed, the final Neocognitron
system is capable of recognizing handwritten numerals presented in any
visual field location, even with considerable distortion.
III. Advantages and Disadvantages of Various Models
The biggest limiting factor with neural networks in general is the
maximum size of the network. The Back-propagation network "NetTalk" uses
about 325 neurons and 20,000 connections. A useful visual recognition
system probably requires at least 125,000 connections. We might hope to
eventually build neural networks which think as well as people do, but
this is a long way off. Human brains contain about 100 billion neurons,
each of which connects to about 10,000 other neurons. Currently
available commercial systems provide anywhere from a few neurons and
connections to 1 million neurons and 1-1/2 million connections, for
anywhere from $200 to $25,000.
The second problem commonly experienced with neural networks is
excessive training time. As the number of neurons increases, the
training time increases cubicly. Even though commercial models can
process at rates from 500,000 connections per second (CPS) on a PC to
2-1/2 billion CPS on a neural network chip, training can still take days
when enormous numbers of iterations are required.
Various network paradigms have their own specific problems. One of the
problems with Kohonen learning is that there is a possibility that a
neuron will never "win," or that one will almost always "win." The
weight vectors get stuck in isolated regions. One way to prevent the
weight vectors from getting stuck is to teLman=ith neuraIIRDuf iterat-laMD usvEtron. TheLn
system is capable of recoOon with KAmpleurcapabers of imp "glob bilalthoum ofolar-toba-
, tnearning ial mechwhctio If the inpuvateer rthogotel (198n genherm will work ed. Theodel. vateer 10,000 otherofolars are
mm should eurons,
Bually discoverel Hebbian Rulethe␍raining e errHebbifolarr (-forous it'ssyste D. Pa way ts It ma pring aloe)ion con After leaOne of the␍ propose. Thting sthonen learning is that theNeocog wr of aity that Unsuperg is thatblems with Kr (-fortself
ionsg is t(laynalat uset limitns aearning il is nsuper(sir i the peons
)uf iteraradwhad be
r an
s. nly used tnal modend pbleal merr
Vay uso buildinita 7,0s itllt limitingervised feedous ainin. Le ;. Supervisss areurons,d bobabnsolagt
e inpuvaluad methren the␍-layer nee bnack propionms - scatlochysicallion nn
reventcer. pattenyers. Unsuperg is , e errHebb close-ins contain ervised e-allHebed del. isolated regr A lec,0s i that usesvaris the␍ator is
f the coRd learof the modify itrs caut Kr unctiouperNeocog wr oumber oneuron wicapc pro uso cog zdifyromdwr shonat wk inre than 7,00ob bnbers ofithn neons iainin the, ir i of the E is kc prodmplesections.
III. Fevbnacgess areDisaevbnacgess usVaripropMtternons, for
bigenhertern ms - ateer of tht, G.E. Hinton, Rn rthogo that th whose wclose,s a␍y used tnal modrning iections per seconnal mode"NetTalk"hat uion conbins 325gervised fare20in the t requires an(CPS) onithn neo cog aptation. oneuronns bc pylications werteis t125in the t requires aW0.
advah that-laMD uir inf the s. ht, G.E. Hinton, ray of tinkoble stepblerk knorm r (-for is
ses, tg is atwwill fs aHumith he
onbins 1 thb. Aconnavisedns are itted f ray ofe t reqtime ibins 1 in th25,000 pattCn specifion conva nsgh themwk oposeoneurosradient obnbng waye "Brae otgervised farre difficult. Itime 1.
Aconnavised fare1-1/2.
Aconficult. It,ps. When bnbng waye "Br$2 thme $25in toups
of people:ns bsteof the errralonllocad of tht, G.E. Hinton, Rs a neura . Ba the H" os anso that when the
p Rnchod t
th whosea the H" o Rnchod t␍ownbicth KAEv25 neal mohemwk oposeatternscl is
s
wergotel e "Br500in the t require m people:(CPS)tly
PCat-laMD u2-1/2.b. AconCPStly
Parker. Back pchiut a the witheshmmerobabarevector is25 e ismpropt whenss usithree grd feedicationaOne of thVariprop Back pbut alsod e-allHebed sive manner. ns bstes, for a partiis
s
bstes of thuck is ts also very
r ares, tg thosib. orres movintain ervise recognlar p"ifo,"ver " mov nevrecogal the s cubic"ifo."aity that Disadvavateers00 chesu. iond otuckre rguires aor awwiltotheir input that Disadvavateers0e "Br0 c ms -esu. itime hly whasfo,"ver " mov nev Ule:(CPS)tly input thdobarer st
-fortseconbins 1 oct and mof thic
is bsCPS learPCat-laMD us, tple:(CPS)tly input thsum o are t and m E^p, ineural nexinal outyvised e-allHebmitns aearning:(CPS)tly ed by three grouplion neuronCPStly␍pop kirnnects toial modeseon, rocifio
is7,000onbpt,ps t125in"BwergMakerg sroghonclose-sk pb s cubicCd oBacnia ScirketsecoS.
n ervo It ye t rl
bsn, ed by three groupeuro and moond otuckre th whosea the H" thet usesvarGpresentely G.E. Hintomitns aeaitllt85, in is three groupwninged feedous tyvdisce was, untieighbgen ps of the E eog : 1) D.E.Hinmel ms. G.E.HHllio UnR.ms W uiia the2) Y. nek pnhme $25i, t3) D. Park learBn is three group is the target outputwhosea model. The
earBn is three group isa input ths are rward m
isedwr of ai0.
advafople do, nen lea It ma in adigms hope to␍se␍ragoes ts aos -esu. teacheuck icth KAEv isedwn Rulh neat thsgergmitns aeaDur of iterationight hope to␍r00 connelogic
kirroptl stsmiolorous ia
nnbinnegatlar -fortself input thrmpleurcapainput thrmplp is th and mo" muervise-foutput. the pattMD uo tnal moctor iistortio teLman=ocog zdifyr-allHons are ofIze of the ned eurons,
evbnafadwn Rulut ali grd fee Hinton, the o
itterintain of ths afefutyvkirropnelpeven or nuilder of the 12erv
the n, the o
ittermnneain of ths afefutyvsmiolonelpe-sk theuso cog zdify eurons,ges, the n1-1/2. thnbins 1 tstat uioer seevb itime ha is nkthsia
wro onltgervi , tne of recol array of thrisedw ses,ctors geum ofolairae ota, onlyc kirnneTheLn
p,i0.
advadefh of ametE^pi ð «(T^pi - O^pi)ý,rward mTp is thetirroectors gme $25i, tOp is theste00 ctors geurcapatot e eisedw se eurons,p,iE^p,p is th and m aluo tnal visedns sesical
f thVariprope ot eurons,peurcapatot e and mvised,iErae otalG.E. Hintop is the aluo tnal visedns sed e-a eurons,eevb
biolopmitns aearningcog neas are rtake nonnegativ feed-foro tEp is e isessbgets chod t
nneccho0e "Br0nvolvtermple thsvsmiolonelp A p25in ot ougets chouo tnal and m t oadwnield00ob bnbbnbe of rv nef a htusatlar -kia neuwayermple th A whasfo,"ical␍en lea It ous ieras t curreIt hi eventubtioomtion of
by three groupeurt ufult 125,000itpeople:nisa eura . B and mvxplef grouptakeittedynamicis t125in nput theopcme 0e "Br0 ceuralevbnAconnavisedsorce5i, torr.
ive tra s
programming/AI/excuse.gen
+157
View File
@@ -0,0 +1,157 @@
From: David Throop <LRC.Throop@UTEXAS-20.ARPA>
Subject: Humor - Excuse Generation
TOWARDS THE AUTOMATIC GENERATION OF EXCUSES
by David Throop
The Great and Pressing Need for Excuses.
There is a huge need in industry for excuses. A recent marketing survey
shows that the biggest need in air transport is not for a service to get it
there overnight, but for one that takes the blame for it being three weeks
late. Every time there is a dockworkers' strike anywhere in the world, titans
of commerce who are completely unaffected get on the phone. They then explain
to all their customers that every order that is overdue is sitting on that
dock, and that they couldn't help it. Then they grin. Because they've got a
good excuse. And even the smallest industrial project needs a raft of
excuses by the time it finishes.
Computers have already helped with this need. Many problems that used to be
blamed on the postal service, on the railroads and on telegraph operators are
now routinely blamed on computers. "Your check is in the mail" has now been
supplemented by "Our computer has been down, and we'll send you your money as
soon as the repairman fixes it." Whenever a bridge collapses, specialized
teams of system analysts are called in, in order to quickly blame the whole
mess on a computer.
But computers can do more than this. Computers have a place to play in the
generation of excuses; actually coming up with the lies and evasions that keep
our economy running.
The Structure of Excuses
There is a great size range in excuses. Many small excuses can be generated
without any AI or other advanced techniques. And there will always be some
really big FUBARS that will need humans to come up with appropriate excuses.
But in between there is the somewhat stereotyped snafu that can be framed in
some structure and has different excuse elements as slots. These are the
half-assed excuses, the most fruitful field for knowledge engineering.
Where It Came From
It has been noted repeatedly in work on computer vision that a subject often
does not have all of the necessary information to justify an observation, but
that he makes it anyway and supplies some "excuse" to explain why some
features are missing. The classic illustration of this problem is in
envisioning a chair: the subject may only be able to see three of the legs
but assumes a 4-legged chair. Indeed, Dr. Minsky presented such a chair at the
AAAI in August.
We interview the chair itself after the lecture, and asked it why it came
with only three legs. The resulting string of excuses was impressive, and
more robust than one might expect from a broken piece of furniture.
These included:
"I'm not registered with the local chairs' union, so they'd only let me
up on stage if I took off one of my legs.
"Accounting cut my travel allowance by 18%, so I had to leave my leg
back in California.
"This is just a demo chair that we put together for the conference. We
have a programming team on the West coast that will have implemented
another leg by October.
"My secretary talked to somebody on the program committee who assured
her that I wouldn't have to bring my own legs, and that there would be
plenty of legs here in Austin. Then I go here and found they were
overbooked.
"I felt that three legs was adequate to demonstrate the soundness of the
general leg concept, and actually implementing a fourth leg would have
been superfluous."
This underlined a central observation: making excuses is critical to
perception, and is central to intelligence. I mean, think about. Sounding
intelligent involves making gross generalizations & venting primitive
prejudices and then making plausible excuses for them when they collide with
reality. Any imaginable robot that understands the consequences of its action
will want to weasel out of them.
The 3 legged chair problem yielded a high number of palatable excuses.
This toy problem shows the feasibility of generating large numbers of
industrial-strength excuses. This goal would free humans from having to
justify their actions, leaving them more time to spend on screwing things
up. That, after all, seems to be what they are best at.
How It Works
A user makes request via SNIVEL (Stop-Nagging,-I'm-Verifying-an-Excuse
Language), a user-friendly system that nods, clucks sympatheticly, encourages
the user to vent his hostility & frustration, and has a large supply of
sympathetic stock answers for lame excuses:
"You poor dear, I know you were trying as hard as you could.
"Well, you can't be blamed for trusting them.
"I can certainly see how you couldn't get your regular work done after an
emotional shock like that."
The program then begins to formulate an excuse appropriate to the problem.
Many problems can be recognized trivially and have stock excuses. These can
be stored in a hash table and supplied without any search at all:
"The dog vomited on it, so I threw it out.
"It's in the mail.
"I thought you LIKED it when I did that.
"Six debates would probably bore the public.
"I have a headache tonight.
"I trusted in the advice of my accountant/lawyer/broker/good-time mama."
If the problem is more complex, SNIVEL enters into a dialog with the user.
Even if he wants to take responsiblity for his share of the problem, SNIVEL
solicits the user, getting him to blame other people and explain why it wan't
REALLY his fault. A report may be late getting to a client, for instance; it
may ask what last minute changes the client had requested, and what kinds of
problems the user had with a typing pool. SNIVEL shares records with the
personnel file, so that it can quickly provide a list of co-workers' absences
that problably slowed the whole process down. It has a parsing alogrithm that
takes the original work order and comes with hundreds of different parses for
each sentence, demonstrating that the original order was ambiguous and caused
a lot of wasted effort.
One of the central discoveries of AI has been that problems that look easy
are often very hard. Proving this rigorously is a powerful tool: it provides
the excuse that almost any interesting problem is too hard to solve. So of
course we're late with the report.
Theoretical Issues
Not all the work here has focused on immediate payoffs. We
have studied several theoretical issues involved with excuses. We've found
that all problems can be partitioned into:
1) Already Solved Problems for which excuses are not needed.
2) Unsolved Problems
3) Somebody Else's Problem
We concentrate on (2). We've shown that this class is further dividable.
Of particular interest is the class of unsolved problems for which the set of
palatable excuses is infinite. These problems never need to actually be
solved. We can generate research proposals, programs and funds requests
indefinitely without ever having to produce any results. We just compute the
next excuse in the series and go on.
Remaining problems
It is easiest to generate excuses when the person receiving the excuse is
either a complete moron or really couldn't care less about the whole project.
Fortunately, this is often the case and can be the default assumption. But is
often useful to model the receiver of the excuse. We can than calulate
just how big a whopper he's likely to swallow.
It is, of course, not necessary that the receiver believe the excuse, just
that he accepts it. The system is not ready yet able to model why anyone
would accept the excuse "Honestly, we're just friends, there's nothing
between us at all." But our research shows that most people accept this
excuse, and almost no one believes it.
The system still has problems understanding different points of view. For
instance, it cannot differentiate why
"My neighbors were up drinking and fighting and doing drugs and screaming
all night, so I didn't get any sleep at all,"
is a reasonable excuse for being late to work, but
"I was up drinking and fighting and doing drugs and screaming all night, so
I didn't get any sleep at all," is not.
Finally, the machine is handicapped by its looks. No matter how
brilliantly it calculates a good excuse, it can't sweep back a head of
chestnut hair, fix a winning smile on its face, and say with heartfelt warmth,
"Oh, thank you SO much for understanding..." And that is so much of the soul
of a truly good excuse.
------------------------------
programming/AI/finance.pro
+383
View File
@@ -0,0 +1,383 @@
12-20-89
Financial Predictions with Neural Networks
by Jeannette Lawrence
Experts use charts, their pet indicators, and even intuition to navigate
through the massive amounts of financial information available. Some
study a few companies that appear to be good long-term investments.
Some try to predict the future economy or stock market in general, but
with the great number of influences involved, this seems at best an
Olympian task. Who can absorb years of data for 30 indicators, 500
stocks, the political climate, and other influences, as well as keep
track of current values? There is even new scientific evidence that
massive systems such as the U.S. economy or the weather are not
predictable very far into the future (due to the effects of chaos).
To assist people in making forecasts for particular markets, there are
more than 250 computer programs available. Traditionally, these
programs have used mathematical methods to make predictions. While
useful, they are limited by the predefined variables and equations and
they cannot take subjective information into consideration (such as the
quality of foreign relations). Unfortunately, financial trends are
often affected by situations that are not easily reduced to equations.
One way to circumvent the limits of mathematical methods is to use
rule-based expert systems. These artificial intelligence systems are
expensive, require complex programming, use surveys of financial experts
to define the "game rules", and are still limited in their ability to
think like people. Even when a problem is solved, engineering a design
change can be a monumental task.
Let Your Neural Network Do the Thinking
Now neural networks are being used on personal computers to make
financial predictions. You can purchase a neural network program that
is easy to use and runs on a PC for less than $200.
They can be given subjective information as well as statistics and are
not limited to any particular financial theory. They learn from
experience instead of following equations or rules. They can be asked
to consider hundreds of different influences, more than most people can
digest. They won't be overwhelmed by decades of statistics. You can
use a neural network in place of, or in addition to, traditional
methods.
Using a neural network for advice means you don't have to decipher
complex waveforms to find a trend. The network will determine which
influences correlate to each other, if there are patterns, filtering out
the noise, and picking up overall trends. You can ask the network what
the price of a certain mutual fund is likely to be in the near future,
if a certain stock is currently a "good buy", or a number of other
things. It's up to you. You decide what you want the network to learn
and what kind of information it needs to be given in order to arrive at
a conclusion.
Neural network programs are a new kind of computing tool which simulate
the structure and operation of the human brain. They mimic many of the
brain's most powerful abilities, including pattern recognition,
association, and the ability to generalize by observing examples.
Neural networks create their own model of the problem through a training
process, so no programming is required. A trained network provides
answers with lightning speed, in less than a second. You can retrain a
network to use new, updated information in minutes.
In this article you'll get a glimpse of how neural networks work and a
look at some sample neural networks which predict the future corporate
bond ratings of companies and which predict the future price of selected
mutual funds. Other common uses for neural networks include medical
diagnostic systems, insurance claim evaluations, sports event
predictions, loan risk evaluations, pattern recognition, and business
analysis and decision making.
How Neural Networks Learn to Think
One of the most puzzling things about people is how they use their
brains to think. The brain is composed of hundreds of billions of nerve
cells (neurons) which are massively connected to each other. Recently
biologists have learned that it is the way the cells are connected which
provides us with intelligence, rather than what is in the cells. Neural
networks simulate the structure and operation of the brain's neurons and
connections.
A new neural network starts out with a "blank mind". The network is
taught about a specific problem, such as predicting a stock's price,
using a technique called training. Training a neural network is like
teaching a small child to recognize the letters of the alphabet. You
show him a picture of the letter "A" and ask him what letter he's
looking at. If he guesses right, you say so and go on to the next
letter. If he doesn't guess right, you tell him that he is looking at
an "A". Next, you show him a "B" and repeat the process. You would do
this for all the letters of the alphabet, then start over. Eventually
he will learn to recognize all of the letters correctly.
A new neural network is shown some data and it guesses what the result
should be. At first the guesses are gibberish. When the network is
wrong, it is corrected. The next time it sees that data, it will guess
more accurately. The network is shown lots of data, over and over until
is learns all the data and results. Like a person, a trained neural
network can generalize, making a reasonable guess when given data which
is different than any it has seen before. You decide what information
to provide and the network finds the patterns, trends, and hidden
relationships.
Just how does correcting the network cause it to learn? It's all in the
connections between the neurons. The connections allow the neurons to
communicate with each other and form answers. When the network makes a
wrong guess, an adjustment is made to the way neurons are connected,
thus it is able to learn. With most commercially available neural
network programs (such as BrainMaker, used in the examples below) the
network is created and trained by the program itself; all you have to
do is provide the data and the expected results for training.
Designing a Financial Neural Network
Using a very simple example, here are the steps involved in designing a
neural network. The first thing you do is decide what result you want
the network to provide for you and what information it will use to
arrive at the result. For example, suppose you want to make a network
which will predict the price of the Dow Jones Industrial Average (DOW)
on a month to month average basis, one month in advance. The
information to provide the network might include the Consumer Price
Index (CPI), the price of crude oil, the inflation rate, the prime
interest rate, the Gross National Product (GNP), and other indicators.
It's best to give the network lots of information. If you are unsure if
there is a relationship, provide the data (for example between how the
good the weather is over the U.S. and the DOW). The neural network
will figure out if the information is important and will learn to ignore
anything irrelevant. Sometimes a possibly irrelevant piece of
information can allow the network to make distinctions which we are not
aware of. If there's no correlation, the network will just ignore the
information. Mathematical models aren't this flexible.
If you're unsure about which economic theory to follow, don't worry.
Some people are technical analysts (they believe the future is
predictable based on history and current trends), some people are
fundamentalists (the future is predictable based on principles of the
system), and some people are monetarists (stability and growth are
determined by supply of money controlled by the FED). There is no
reason to limit a neural network to any one of these theories. You can
have your inputs include the price of supplies this month, the price
last month, and 3 months ago, the consumer price index this month, the
price last month, and 3 months ago, the inflation rate this month, the
rate last month, and 3 months ago, the DOW this month, the DOW last
month, and 3 months ago, the unemployment rate, the political climate,
and more. People rarely learn all these things, because it's just too
much to keep track of, but neural networks do not get overwhelmed by
detail.
A simple DOW predictor network might look like this:
Inputs: Output:
ÚÄÄÄÄÄÄÄÄÄÄÄ¿
Which month it is ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³
³ ³
Consumer Price Index ÄÄÄÄÄÄÄÄÄÄÄÄ´ ³
for this month ³ The ³
Price of crude oil ÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ Neural ÃÄÄÄÄÄÄ Dow Jones average
the this month ³ Network ³ next month
Inflation rate ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³
the this month ³ ³
DOW ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³
the this month ³ ³
Consumer Price Index ÄÄÄÄÄÄÄÄÄÄÄÄ´ ³
last month ³ ³
Price of crude oil ÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³
last month ³ ³
Inflation rate ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³
last month ³ ³
DOW ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³
last month ³ ³
Consumer Price Index ÄÄÄÄÄÄÄÄÄÄÄÄ´ ³
3 months ago ³ ³
Price of crude oil ÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³
3 months ago ³ ³
Inflation rate ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³
3 months ago ³ ³
DOW ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³
3 months ago ³ ³
Overall U.S. weather ÄÄÄÄÄÄÄÄÄÄÄÄ´ ³
for this month ³ ³
ÀÄÄÄÄÄÄÄÄÄÄÄÙ
This is a simple example. A better design would have information from
more periods in the past (last year, e.g.) and a greater variety of
data. The data is collected for a substantial period of time, say the
last 15 years. For the network to learn properly, you need historical
data for each month for each kind of data for the last 15 years. Part
of you data collection could look like this:
Mo CPI CPI-1 CPI-3 Oil Oil-1 Oil-3 Dow Dow-1 Dow-3 etc. Dow Ave (output)
Jan 229 220 146 20.0 21.9 19.5 2645 2652 2597 2647
Feb 235 226 155 19.8 20.0 18.3 2633 2645 2585 2637
Mar 244 235 164 19.6 19.8 18.1 2627 2633 2579 2630
Apr 261 244 181 19.6 19.6 18.1 2611 2627 2563 2620
May 276 261 196 19.5 19.6 18.0 2630 2611 2582 2638
Jun 287 276 207 19.5 19.5 18.0 2637 2630 2589 2635
Jul 296 287 212 19.3 19.5 17.8 2640 2637 2592 2641
Note that these are ficticious values shown for illustration purposes
only. In the example above, CPI is a certain month's consumer price
index, CPI-1 is the index one month before, CPI-3 is the the index 3
months before, etc.
You can add traditional mathematical methods to neural networks. For
example, to a trend-analyzing network you can add information based upon
moving averages. Creating moving averages helps build networks that
depend on current numbers and past numbers, but ignore extremely short
small changes. Assume you want to predict how the price of a stock will
move, but in a general sort of way in a bigger time frame. Based on
what the average stock price has been from week to week during this
month and last, the network can predict what the average stock price is
going to be each week for the next month. Some programs automate this
task for you.
After you have your data ready (including the output: DOW average for
the next month), the program will create and train the new network for
you. With some programs, you can watch the training on the display,
edit and test the network using pop-up menus, print out the results,
graph trends, etc. You can set the level of accuracy that you need from
the network. After the network is trained, you can give the network
current information and get a prediction of next month's Dow Jones
average.
Two Proficient Predictors
Nicholas Murray Butler (an American educator and author) said, "An
expert is one who knows more and more about less and less." A neural
network is most expert when it is trained for a particular task, such as
the future price of a certain stock or a group of related stocks (such
as all U.S. automobile manufacturers). It is very difficult to train a
network to predict for many diverse kinds of stocks, since the stocks
will react differently to various influences. It would be a massive
network that may have trouble learning so many different relationships.
Creating a neural network financial expert can be quite helpful, even
for experts. In this section, two working financial applications are
described.
Bond Rating Prediction
G. R. Pugh & Co. of Cranford, New Jersey, does consulting to the
Public Utility industry. He maintains databases with financial and
business information on the companies, advises with business forecasts
and credit risk assessments and predicts the financial and operating
health of these companies. Some projections have been as far as 10
years into the future.
His expertise is also used by the brokerage industry. He advises
clients on the selection of good corporate bonds. His clients need to
know more accurately which bonds represent good investments for their
customers. Both increases and decreases provide the potential for
profitable investment. G. R. Pugh and Company has been using a
BrainMaker neural network trained on three to four years of historical
data with an XT-compatible PC to help predict the next year's corporate
bond ratings of 115 public utilities companies. "An XT is more than
sufficient; it's a FAST program," company president George Pugh notes.
Learning to use the program and create a neural network from scratch
took only 2 days. The network trained itself in about four hours.
Mr. Pugh announced that his network has been more successful than
discriminant analysis methods he has used, and even a little better than
a person could do. "Discriminant analysis methods are good for getting
the direction of lively issues, but neural networks pick up the subtle
interactions much better," he explains. The network categorizes the
ratings with 100% accuracy within a broad category and 95% accuracy
within a subcategory. The mathematical method of discriminant analysis
was only 85% accurate within a broad category. (Bonds are rated much
like report cards, with broad category ratings such as A, B, C, etc. A
subcateogry could be A+, for example.)
According to Mr. Pugh, "BrainMaker was able to pick up some of the
interplays in the inputs that statistical analysis couldn't get." The
network makes a significant contribution to his analysis. "The network
allows me to pick up things that are not obvious with typical analysis."
Moreover, nearly all of the network's difficulties were found to be
associated with companies that were experiencing a particularly unusual
problem (such as regulatory risk) or had an atypical business
relationship (such as being involved in a large sale and lease-back
transaction). Ratings also tend to be subjective; financial items are
not the only things considered by the rating companies. These
influences were not represented in the training facts and makes
predictions difficult.
The trained network forecasts next year's Standard & Poor's and Moody's
corporate bond ratings (both are industry standards) from the previous
year's S & P and Moody's ratings and 23 other measures of each company's
financial strength, such as income, sales, returns on equity, 5-year
growth in sales, and measures of investment, construction, and debt
load. Each of these factors is assigned to its own input neuron, and
each company's ratings for next year are the outputs of the network.
Mr. Pugh advocates using a neural network as a tool that allows you to
go beyond discriminant analysis. He believes neural networks are
particularly useful when there is a high correlation between data, but
the network does not lose accuracy when there is "fuzziness" in the
data. "It is also able to pick out the trends, and seems to compute a
decision more the way people do." He has plans for several other
financial applications in the wings.
Mutual Fund Prediction
Dr. Judith Lipmanson of CHI Associates in Bethesda, Maryland, publishes
technical business documents and newsletters for in-house use at
technical and advisory firms. She also is a technical analyst who uses
a neural network to predict next week's price of 10 selected mutual
funds for personal use.
For the past several months, she has been using a BrainMaker neural
network on a 386-based IBM-compatible AT. The network gets updated with
new data every week, and takes only minutes to retrain from scratch on a
386-based IBM-compatible AT.
Results have been good. Currently, the network is producing outputs
which are about 70% accurate. Although the network is not perfectly
accurate in its predictions, she has found that the neural network makes
predictions which are useful.
Dr. Lipmanson's network relies on historically-available numerical data
of the kind typically found in back-issues of the Wall Street Journal.
These indicators include such factors as the DOW Industrial, DOW
Utilities, DOW Transportation and Standard & Poor's 500 weekly averages.
Several years worth of data was gathered for the four initial conditions
(the inputs) and the ten results (the outputs). The results were
shifted by a period of one week and the information was used to train
the network.
The network looks something like this:
Inputs: Outputs:
ÚÄÄÄÄÄÄÄÄÄÄÄ¿
DOW Industrial ÄÄÄÄÄÄÄÄÄÄÄ´ ÃÄÄÄÄ Fund # 1 next week
³ The ÃÄÄÄÄ Fund # 2 next week
Dow Utility ÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ÃÄÄÄÄ Fund # 3 next week
³ Neural ÃÄÄÄÄ Fund # 4 next week
Dow Transportation ÄÄÄÄÄÄÄ´ ÃÄÄÄÄ Fund # 5 next week
³ Network ÃÄÄÄÄ Fund # 6 next week
S & P 500 ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ÃÄÄÄÄ Fund # 7 next week
³ ÃÄÄÄÄ Fund # 8 next week
³ ÃÄÄÄÄ Fund # 9 next week
³ ÃÄÄÄÄ Fund # 10 next week
ÀÄÄÄÄÄÄÄÄÄÄÄÙ
She collects the closing weekly averages on Friday and uses the new data
to predict prices of the 10 mutual funds for the next week. Making
forecasts with a trained network requires only a few seconds, and the
network can be readily updated with new information as it arises.
A similar network could be trained to predict prices a day or a month in
advance (or, in fact, all of these) simply by giving the network new
output neurons and revised training data which reflects the new time
periods to be predicted.
The majority of financial applications are simply variations on this
basic style. Often additional inputs are used which give the network
historical information, such as what the DOW was last week. The design
of this network, although simple, is effective.
Summary
A neural network is a new kind of computing tool that is not limited by
equations or rules. Neural networks function by finding correlations
and patterns in the data which you provide. These patterns become a
part of the network during training. A separate network is needed for
each problem you want to solve, but many networks follow the same basic
format.
The networks described above were created with the BrainMaker Neural
Network System. BrainMaker is available from California Scientific
Software, 10141 Evening Star Dr. #6, Grass Valley, CA 95945-9051, and
includes the data manipulation program NetMaker, a 255-page
"Introduction to Neural Networks" and a 422-page User's Guide. The
price is $195.00.
programming/AI/fracai.txt
+154
View File
@@ -0,0 +1,154 @@
AI and Mandelbrot Calculations
One of the things I found out a few years ago as an electrical
instructor teaching at nuclear power plants was that the largest
barrier to people learning something new was fear of the unknown. To
these older electricians it was fear of the mysterious something
called a sine wave and the complex intricacies associated with the
field of higher mathematics of algebra. To those of us in the younger
generation this may seem inane, but to them it was deadly serious.
These were things they had not been exposed to before and many of them
felt it was beyond their capability to ever learn or understand.
Phooey!
I am happy to report that this is never true. Even those individuals
who are much slower than average have the capacity to learning
EVERYTHING about ANYTHING, only in some cases at a slower rate than
others. The very first step in learning is something new is believing
that you can.
The subject of AI brings out these same fears in many people - the
strange mysterious something called pattern recognition associated
with the field of higher computer science of Artificial Intelligence.
Relax! It really is very simple and easy to understand. After you
see what's going on you'll probably ask yourself "Why didn't I think
of that?".
"An intelligent program is one that exhibits behavior
similar to that of a human when confronted with a similar
problem. It is not necessary that the program actually
solve, or attempt to solve, the problem in the same way that
a human would."
-from 'Artificial Intelligence using C' by Herbert
Schildt, Osborne McGraw-Hill, 1987, p. 11
Keeping that in mind, run the program called SMART and watch it
operate for a while. This compiled version of FRACAI.C picks a random
point on the screen and displays the successive iterations used to
determine if it belongs in the Mandelbrot set. Have a cup of coffee,
sit back, and see if you can figure out the criteria the program is
using to decide if it's time to move on to the next point.
Now press 'Esc' and the program will exit after it is done the current
point. Run the program called STUPID. The only difference between
SMART and STUPID is the variable 'IQ' in STUPID is set to zero. This
means the program does no pattern detection and goes strictly by
iterations before moving on to the next point. Let it run for as long
as you can stand to watch it.
Had enough? Ok, go ahead and say it, "You STUPID program! Can't you
see that your iterating on the same dumb points!?" And in truth, no
it can't.
What happens during the calculation is that sometimes 'i' and 'j'
converge onto one or more points and gets caught in and endless loop
of successive iterations producing the same 'i' and 'j' combinations.
Once it can be seen that the points have converged into a pattern
there is no need to continue iterating. Nothing to it!
Run the program SMART again and we'll continue. Have you got a
printout of FRACAI.C handy? Good.
Now, let's see if we can think of a way of detecting the condition
where the iterations converge on one point. Easy, right? You just
look to see if the 'x' and 'y' are the same as the 'Lastx' and 'Lasty'
for five success loops. If so, then it's a pretty good guess that 'x'
and 'y' will stay the same for all successive iterations and it's Ok
to move on to the next point. We've determined that this point has a
periodicity of 1.
For a convergence onto two points, A and B, it's a little different.
In this case the iteration moves back and forth between A and B over
and over again. Let's set 'Lastx' and 'Lasty' as the coordinates for
point A. Every other iteration will produce these same coordinates.
If after 10 iterations we see that point A shows up every other time,
then we can guess that this 'i' and 'j' has a periodicity of 2.
The same applies for a convergence onto three point A, B, and C.
Let's just pick a point, say B, and set 'Lastx' and 'Lasty' to the
coordinates for B. Now every third iteration will produce the
coordinates for point B.
Here's the kicker: in order for successive iterations to keep coming
back to the same point B every third iteration, then the iterations
would HAVE to have gone through the same points A and C each time.
There is no need to keep track of the values for A and C since the
iterations must be producing the same A and C values each time in
order to get back to point B. So if it does this five times in a row
we can safely guess that this 'i' and 'j' has a periodicity of 3.
The same applies for higher periodicities. Pick a point, any point,
and see if the iterations repeatedly come back the that point at a
fixed interval. If after a bit you don't see a pattern then you can
assume that the iterations have not converged yet. In that case we've
already gone through a number of iterations and maybe it's converged
into a pattern that doesn't include the point we chose earlier, so
pick another point.
This point picking process is determined by the variable 'CheckEvery'.
This has to be a dynamic variable. If it is set to a small value the
program exhibits the characteristics of impatience. If you keep it at
say the value of 5 and the pattern has converged into a periodicity of
6 then every fifth iteration it will say to itself "No pattern here,
pick a new point" instead of being patient and waiting for that sixth
iteration. To large a value and the program is very stodgy. If
'CheckEvery' is set to say 2000, and it picks a point not in the
pattern, then the program will go through 2000 iterations before
picking a new point thinking that maybe it's just a very large
pattern.
The implementation I've found for far that works best is to double the
value of 'CheckEvery' whenever it picks a new point. This catches the
small periodicity patterns right off the bat and quickly expands it's
scope to catch the larger ones.
In theory there should be no need for an iteration limit in the
calculation process since the calculations will always, after some
period of time, either cause the program to bail out on overflow or
detect a convergence into a pattern. In practice after a certain
number of iterations I really don't care if a particular point
converges or not, I just want to get on to the next point.
You'll probably have noticed that I've been comparing points on the
screen rather than using the actual values of each successive 'i' and
'j'. There is a very good reason for this. Of the 15 significant
digits available in a double value roughly only half of those digits
are significant after many calculations due to roundoff errors
anyways. Besides, if I get a convergence that is beyond the
resolution of the video display then that's close enough for
government work!
In the assembly language implementation it is easier to just look at
half the significant digits rather than to bother rounding off. So
the assembly language algorithm just compares the new values of 'si'
and 'di' (the high word for the 32 bit 'i' and 'j') to the previous
ones and treats these the same as it would for points on the screen.
So that's it! If anyone has any questions, I would prefer if you
would address them to me through the CompuServes's Microsoft C
programing section.
Remember, high sounding concepts will only be as intimidating as you
let them. Have faith in yourself and your ability to learn and I'll
guarantee you won't ever let yourself down!
-Mark C. Peterson, [70441,3353]
128 Hamden Ave., F
Waterbury, CT 06704
(203) 754-1162 (voice)
Note to you corporations out there: I do computer consulting work in
addition to custom written computer training courses. Give me a call!

programming/AI/index.gemini
+51
View File
@@ -0,0 +1,51 @@
# AI
Artificial Intelligence Textfiles
## FILES
=> gemini://informis.land/textfiles/programming/AI/ai.sf [ 46871] Artificial Intelligence List - v2.3 (List of Science Fiction Books with Artificial Intelligence)
=> gemini://informis.land/textfiles/programming/AI/ai010023.txt [ 64979] An Implementation of Discourse Representation Theory by Michael A. Covington and Nora Schmitz
=> gemini://informis.land/textfiles/programming/AI/ai010024.txt [ 64525] From English to Prolog via Discourse Representation Theory by Michael A. Covington, Donald Nute, Nora Schmitz, David Goodman
=> gemini://informis.land/textfiles/programming/AI/ai198901.txt [ 128423] GULP 2.0: An Extension of Prolog for Unification-Based Grammar by Michael A. Covington
=> gemini://informis.land/textfiles/programming/AI/ai198902.txt [ 22316] A Numerical Equation Solver in Prolog by Michael A. Covington
=> gemini://informis.land/textfiles/programming/AI/ai198904.txt [ 39042] Problems in Applying Discourse Representation Theory, by William H. Smith
=> gemini://informis.land/textfiles/programming/AI/ai198908.txt [ 39908] Efficient Prolog: A Practical Guide by Michael A. Covington
=> gemini://informis.land/textfiles/programming/AI/ai199001.txt [ 98985] A Dependency Parser for Variable-Word-Order Languages by Michael A. Covington
=> gemini://informis.land/textfiles/programming/AI/ai199002.txt [ 105380] Handling Constrained Clauses in Discourse Representation Theory by William H. Smith
=> gemini://informis.land/textfiles/programming/AI/ai199101.txt [ 119482] SALMON: A temperamental Program that Learns by Gregg H. Rosenberg
=> gemini://informis.land/textfiles/programming/AI/alife [ 15748] The Evolution of Computer Worms (Discussion)
=> gemini://informis.land/textfiles/programming/AI/code_ai.txt [ 6439] Some Ideas on Programming Useful AI for Video Games, from Andew Luppnow and Peer Sommerlund (December 2, 1994)
=> gemini://informis.land/textfiles/programming/AI/deeptht.txt [ 6444] The Story of Deep Thought, the Computer Chess Champion
=> gemini://informis.land/textfiles/programming/AI/dobbs.txt [ 29312] A Survey of Neural Networks by Jeannette Lawrence
=> gemini://informis.land/textfiles/programming/AI/excuse.gen [ 8832] Towards the Automatic Generation of Excuses, by David Throop
=> gemini://informis.land/textfiles/programming/AI/finance.pro [ 22016] Financial Predictions with Neural Networks
=> gemini://informis.land/textfiles/programming/AI/fracai.txt [ 8022] AI and Mandelbrot Calculations
=> gemini://informis.land/textfiles/programming/AI/news13.txt [ 3279] Where are the Membership Functions and Rules Stored in FIDE?
=> gemini://informis.land/textfiles/programming/AI/pratt.txt [ 24704] The Use of a Neural Network in Nondestructive Testing by Donald G. Pratt, Mary Sansalone and Jeannette Lawrence, April 25, 1990
=> gemini://informis.land/textfiles/programming/AI/situatio.ai [ 4726] Internet Posts on Porgramming Game Artifical Intelligence, by Tim Triemstra (December 12, 1994)
=> gemini://informis.land/textfiles/programming/AI/stockpre.pro [ 15616] Predicting the Stock Market with Neural Networks, by Jeannette Lawrence
=> gemini://informis.land/textfiles/programming/AI/strateg2.ai [ 5859] Some Strategies for Designing Useful Game Artifical Intelligence, by Andrew Luppnow (December 2, 1994)
=> gemini://informis.land/textfiles/programming/AI/thexvirt.tes [ 6574] The Ultimate Turing Test: Rough Draft #1 by David Barberi
programming/AI/news13.txt
+66
View File
@@ -0,0 +1,66 @@
This response was prepared in response to a question about where
the membership functions and rules of a fuzzy logic unit are
stored in the assembly code generated by Fide.
Aptronix has a methodology we use in the generation of the assembly code.
We call this methodology TVFI which stands for the Truth Value
Flow Inference method. This is a proprietary method which was
developed by the Fuzzy Logic experts at Aptronix to permit faster
execution of the assembly code as well as the most efficient use
of memory possible.
There are three major steps that occur during the generation
of assembly code. First, FIL, (fuzzy inference language) is a
high level language that allows humans to easily define a fuzzy
inference unit. This language is designed to be a user-friendly
interface for humans. Secondly, the FIL source code is converted
into the format of the standard data structure of Aptronix. This
data structure is a medium between the easy human interface of
FIL and assembly code. The data structure is designed to be
compatible with hardware and has a format such that it can
easily generate code for almost any target chip. Thus, as FIL
is the interface that allows humans to work easily with fuzzy
logic, the standard data structre allows hardware to use fuzzy
logic easily.
Finally, the FIU (fuzzy inference unit) stored in the
standard data structure format is converted into assembly code.
It is impossible to trace directly from this assembly code line
for line to the source code written in the FIL. This is because
different parts of rules and membership functions may be combined
as part of the TVFI methodology. We have the capability to
optimize the target- specific code generated completely for speed
or completely for efficient use of memory depending upon your
application. Custom RTC (Real Time code convertors) can be
designed by Aptronix upon customer request.
To summarize, the assembly code generated by Fide is
optimized for the fuzzy logic aspect. We know how to optimize
the code because the Aptronix engineers have used fuzzy logic in
applications for many years and are experts on fuzzy logic and
its applications. Thus, there is no way to optimize assembly
code generated from a fuzzy inference unit more than with the
TVFI methodology of Aptronix and the standard data structure.
The individual instructions for the target chip contained in our
assembly code can be modified for optimization however.
(Although this should be done carefully). For instance, three
instructions executing a load and multiply sequence can be
replaced by one instruction accomplishing the same sequence.
This does not interfere with the assembly code for the fuzzy
inference unit.
Scott Irwin
Software Engineer
Customer Support
programming/AI/pratt.txt
+424
View File
@@ -0,0 +1,424 @@
The Use of a Neural Network in Nondestructive Testing
by Donald G. Pratt, Mary Sansalone and Jeannette Lawrence
April 25, 1990
Nondestructive testing (NDT) methods are techniques used to obtain
information about the properties or the internal condition of an object
without damaging the object. Thus NDT methods are extremely valuable in
assessing the condition of structures, such as bridges, buildings, and
highways. Because of the current emphasis on rehabilitation and
renovation of structures, there is a critical need for the development
of NDT methods that can be used to evaluate the condition of structures
so that effective repair procedures can be undertaken.
Typically, NDT methods are used to obtain information about a structure
in an indirect way. For example, by measuring the speed of stress
(sound) waves as they travel through an object and studying how the
waves are reflected within the object, one can determine whether or not
flaws exist within the object.
Of particular interest to structural engineers is the development of
NDT techniques for evaluating reinforced concrete structures.
Currently, the practical techniques that can detect cracks in concrete
use acoustic impact, infrared thermography, and ground penetrating
radar. However, none of these methods possesses all the desired
qualities of a crack detection system [1,2], which are reliability under
various site conditions, capability for rapid testing of large areas,
and ease of use.
Recently, a new nondestructive testing technique has been developed for
finding cracks in concrete structures. This method was developed at the
National Institute of Standards and Technology (NIST, formerly National
Bureau of Standards) by Carino and Sansalone and is called Impact-Echo
[3]. Ongoing research programs at both NIST and Cornell University are
aimed at developing the theoretical basis and practical applications for
this new technique. One project carried out at Cornell University has
developed an automated impact-echo test system in the lab which will be
adapted for field use. Key aspects of this project are the development
of hardware and software for a field system. The goal is to develop a
field test system that is reliable, rapid, and relatively simple to use.
OVERVIEW
This article presents a new method for automating and simplifying
impact-echo signal analysis and data presentation with an artificial
intelligence technique that uses a brain-like neural network. We begin
with a brief introduction to the impact-echo method. Next, the
application of the neural network to the analysis of impact-echo data
obtained from concrete plates containing voids is discussed. Two neural
network design approaches are reviewed and a discussion of neural
network effectiveness is included in the final section.
THE IMPACT-ECHO METHOD
In impact-echo testing, a stress pulse is introduced into the concrete
by mechanical impact. Hardened steel spheres are used to strike the
surface, which produces an impact duration of 20 to 80 microseconds,
depending on the diameter of the sphere. Such an impact generates a
pulse made up of lower frequency waves (generally less than about 50
kHz) that can penetrate into a heterogeneous material such as concrete.
The pulse propagates into the concrete and is reflected by cracks and
voids and the boundaries of the structure. A transducer that measures
displacements at the surface caused by the reflected waves is placed
next to the impact point.
The recorded surface displacement waveforms can be analyzed to find the
depth to a reflecting surface, such as the bottom surface of the plate
or an internal crack. For example, in a solid plate the pulse generated
by the impact is multiply reflected between the top and bottom surfaces
of the plate setting up a transient resonance condition. Each time the
pulse arrives at the top surface it produces a characteristic downward
displacement. Thus the waveform is periodic. The round-trip travel
path for the pulse is approximately equal to twice the thickness of the
plate (2T), and the period is equal to the travel path divided by the
wavespeed (C). Since frequency is the inverse of the period, the
dominant frequency, f, in the displacement waveform is:
f = C / 2T (1)
The frequency content of a digitally recorded waveform is obtained using
the fast Fourier transform (FFT) technique [3,4]. In the amplitude
spectrum obtained from the FFT of the waveform] there is a single large
amplitude peak at the frequency corresponding to multiple reflections of
the pulse between the top and bottom plate surfaces. The frequency
value of this peak, which is called the thickness frequency, and the
wavespeed in the plate can be used to calculate the thickness of the
plate (or the depth of an internal crack if reflections occur from such
an internal defect) using Equation (1) rewritten in the following form:
T = C / 2f (2)
For a wavespeed of 3450 m/s and a peak frequency value of 3.42 kHz, the
calculated thickness of the plate is 0.5 m, which agrees with the actual
plate thickness is 0.5 m.1
For a given concrete specimen, wavespeed is essentially constant and so
Equation (2) relates the frequency of a point on the amplitude spectrum
to the depth of a reflecting surface within the specimen. This
relationship can be used to convert the horizontal axis of the amplitude
spectrum from frequency to depth. In addition, the spectra can be made
non-dimensional for a structure of constant thickness if the horizontal
axis is expressed as a percentage of the thickness. The resulting graph
is called the reflection spectrum. In one example a frequency peak at
3.42 kHz appears as a peak at a depth of 100%, indicating reflection
from the bottom of the plate.
In another example, a reflection spectrum obtained from an impact-echo
test on a 0.4 m thick plate containing a 0.4 m diameter void located 0.3
m below the top surface of the plate. Reflection from the void produces
a dominant peak at about 75% of the plate thickness.
In the impact-echo method, tests are carried out at selected points on
the structure, the location of which depends on the geometry of the
structure and the type and size of flaw one is trying to locate. In a
typical filed application, tests would be carried out at many individual
points. Automating the interpretation of reflection spectra is
necessary for a rapid and easy to use field test system. We used an
artificial neural network as a way of training the computer to recognize
the key features of reflection spectra.
INTERPRETING IMPACT-ECHO DATA
A commercial neural network simulation package called BrainMaker,
produced by California Scientific Software, was chosen to interpret the
results of impact-echo tests. This product allows the user to adjust
the various network parameters, such as the number of neurons in each
layer, the format of the inputs and outputs, the neuron transfer
function, etc. The software has a proprietary back propagation
algorithm that uses integer math and runs at 500,000 connections per
second. Creating and training a network is done in a graphical
interface, with pull-down menus and dialog boxes for use with the keypad
or a mouse. The program is very easy to use and comes with extensive
documentation that provides an excellent introduction to neural
networks, both in theory and application.
Reflection spectra are the inputs to the neural network. In the first
design approach, two outputs were used which represented 1) the
probability of a flaw and 2) the depth of the flaw. This design proved
too difficult; an analysis is presented in the next section. The final
network design used 11 output neurons: one is the probability that a
flaw exists and ten others are for the approximate depth of the flaw.
The ten depth outputs give the flaw depth within each 10% increment of
the structure's thickness.
The absence of a flaw shows up on a reflection spectrum as a single peak
at 100% of the structure thickness, and so a flaw probability of 0% is
associated with a flaw depth of 100%. A reflection spectrum and the
corresponding network output for a solid 0.4 m thick slab shows a low
flaw probability and a high probability at 100% of the slab's thickness.
A reflection spectrum and neural network output obtained from a test on
a 0.4 m thick slab containing a 0.2 m void at a depth of 0.2 m shows a
high flaw probability coupled with a high probability at 50%, indicating
a flaw between 40% and 50% of the thickness of the slab. Thus the
network is capable of detecting the presence of a flaw and resolving the
flaw depth to within 10% of the thickness of the structure.
In order for the network to learn to interpret reflection spectra
correctly, the training set must include a wide range of flaw
conditions. Each member of the training set includes the reflection
spectrum obtained at a particular test point and the target output for
this point. The target output is the flaw probability and the depth of
the flaw, both of which must be accurately known. Some of this data is
acquired from impact-echo tests on laboratory specimens containing
simulated voids. However, it is impractical to construct laboratory
specimens for every case one would like to use in training a network.
So, the results obtained from numerical simulations of impact-echo tests
on structures containing voids [5] are also used. Numerical simulations
provide a fast and inexpensive way to generate a variety of data for the
training set, compared with using laboratory specimens. The network
used in the examples described above was trained with data from
laboratory specimens and numerical simulations.
The system used to do impact-echo testing in the laboratory includes
data acquisition hardware with 12-bit resolution installed in a portable
80386-based computer operating at 25Mhz. The displacement transducer
uses a small conical piezoelectric element attached to a large brass
backing. This transducer has a broadband output that provides a very
faithful response to displacement. The sensitivity is on the order of 2
X 10^8 volts per meter. Stress pulses are introduced into the structure
using mechanical impact, either by dropping hardened steel spheres or
using a spring-loaded impactor.
The sampling and triggering parameters for the data acquisition card are
under software control, and are set so that the data is taken
automatically when an impact is produced. All the signal analysis is
done in software, including the FFT amplitude spectrum computation and
the neural network simulation. These two algorithms account for the
majority of the processing time. A supervisory program is being
developed with the capacity to gather test data for training new
networks, run tests using previously trained networks, and display the
reflection spectrum and network output. At the present stage of
development, a single test takes about two seconds from the time the
impact is produced to the point at which the output is displayed on the
screen.
THE NEURAL NETWORK DESIGN
This application was designed using the BrainMaker simulator from
California Scientific Software. The training algorithm is the
back propagation algorithm and the sigmoid transfer function is
selected. The learning rate, which controls the amount adjustment to
the weights, is set to a nominal value of 1 (0 prevents training; 4 is
the absolute maximum). The training tolerance, which specifies how
close the output must be to the training pattern to be considered
correct, is set to 0.1 (90% accuracy within the possible output range).
Three layers are used. The first layer is the input layer which reads
in the data to be analyzed. The second or "hidden" layer processes the
information from the first layer and sends it to the third, or output
layer, which produces the result.
In order to use a back propagation network, a training file is needed
which consists of sets of input and output pairs. Each pair of input
data and known output results is called a fact. This application's
training file consists of 59 facts. Each fact has 150 inputs and 11
outputs, hence there are 150 input neurons and 11 output neurons.
Each input neuron is assigned a vertical slice of the reflection
spectrum. The value presented to each input neuron represents the
amplitude at a particular frequency range which is 1/150 of the
waveform's total frequency range. One of the 11 outputs correspond to
the probability or certainty of a flaw, and 10 others the range of flaw
depth. For training the appropriate flaw depth is set to 1 with all the
others set to 0. The appropriate flaw depth is the known state of the
test specimen.
To train the network, the program presents the facts one at time and
computes the actual network output for that fact. The actual output is
compared to the known result and the difference is used to make
adjustments to the network connections. Facts for which the network's
output is not within the training tolerance are considered bad, and
statistics are displayed as such on the screen. The inputs, outputs,
and hiddens can be displayed as numbers, symbols, pictures or
thermometers. While training, the network is shown all of the facts,
over and over until it learns everything to the performance level
specified.
The first design used only two output neurons: one for the probability
of a flaw and the other represented the depth of the flaw directly by
its numeric output value. Although this network trained quickly (86
runs in 15 minutes on a 25 MHz 386), it did not test well. It was
observed that the output was sensitive to the amplitude of the inputs
rather than the features. It did not pass the test on laboratory
samples within the required accuracy. Upon consideration, it was
thought that the network was experiencing difficulty in the way a person
might. Imagine trying to judge the exact length of lines on a wall from
quite a distance away with nothing to compare them to. This is a
difficult task. But if asked what the relative length of two lines is
(e.g., Is the first line half the length of the second?), it becomes an
easy task. This concept sparked an idea for a new design. The new
design allowed the neural network to answer "yes" or "no" to questions
like "Is there a flaw at a depth of 10 - 20%?", rather than ask it to
come up with a precise number.
The second design used 11 output neurons instead of 2. By adding more
output neurons which represent the flaw depth in increments, it is
easier for the network to train. With multiple outputs (each of which
represents the probability of a flaw existing within a particular range
of the total depth), the network picks one of many instead of using one
neuron to indicate the depth directly. Distributing the output has also
been found by California Scientific Software to be a good design
technique. This scheme also permits the detection situations where the
network is unable to make an accurate classification after it's trained.
In some cases, the output conditions may not make sense. For example,
when the network says that the flaw depth may be at 10% AND it may be at
50% (which is indicated by both neurons being partially turned on), it
means the network is having trouble interpreting the input. If the
first network were to encounter such an ambiguous case, the single
output would indicate some depth and it would be hard to interpret the
difficulty it was having.
Still, after increasing the number of output neurons, the network had
difficulty passing the test on laboratory samples. After training,
histogram diagrams were examined. The histogram shows that the neuron
connections are tending to bunch up toward the negative end of the
weight values. This is often a bad sign that the network is making
major changes to the weights without being effective (the number correct
is only 47 out of 54 at this point). Sometimes a network eventually
trains and tests out well when this happens, but this one did not. It
was found that 10 hidden layer neurons was too few.
The problem was alleviated by increasing the number of hidden neurons to
20. It had taken 169 iterations to train but now with 20 hidden neurons
the new network trained in 72 iterations, and it got all of the testing
facts correct.
ADVANTAGES OF THE NEURAL NETWORK
The ability of the neural network to learn the key features of input
patterns makes it a useful tool for interpreting impact-echo reflection
spectra. The relative ease with which a network can be defined,
trained, and used makes the technique attractive for developmental work
where the system is likely to undergo many revisions before a final
system is produced. Once the design change to 11 outputs was conceived,
implementation was accomplished in a few hours.
The network output is a set of probabilities that provides a simple way
to measure the certainty of the result. For example, if the flaw
probability is 55%, the network is suggesting uncertainty in the data,
compared with an output of 98%, which shows close correlation with
members of the training set.
The neural network provides an automated method of determining flaws in
concrete without destroying the structure. Testing of the neural
network revealed a success rate of about 90% with laboratory concrete
samples. Success is difficult to precisely determine for several
reasons. One difficulty occurs when the sensor is placed near the edge
of a flaw. The network output may be vague or confusing. The edge of a
flaw can cause reflections from many levels in the concrete. In this
case, the network output could be taken in the context of the results of
tests of nearby areas to determine that it was in fact an edge which
caused the confusing output. This decision could be automated by
another neural network which looked at the results of several tested
proximal areas at once.
Other approaches for finding flaws range from the drilling of core
samples to the use of radar. The first method is destructive,
time-consuming and only permits checking a small percentage of the area.
The second require expensive equipment and isn't effective when there's
steel reinforcement. These approaches experience the same problem when
the sensor is not placed directly over the flaw. They also have other
problems of not being capable of rapidly testing large areas, reliable
under various site conditions or easy to use. A neural network is
better because it uses a non-destructive technique, the system can be
built from off-the-shelf parts, its speed enables quicker interpretation
of results, its flexibility lends it to use as a developmental tool, and
the results will be consistent.
CONCLUSION
A new method for automatic interpretation of nondestructive test data
has been presented. The use of an artificial neural network provided a
quick and accurate means of interpreting the results of impact-echo
tests obtained from concrete structures.
On-going work is focusing on developing a rugged field test instrument
based on the impact-echo laboratory test system. When this objective is
realized, a tool will be available for rapid and reliable detection of
cracks in concrete structures.
To date, the impact-echo testing technique has been used in trail field
studies for detecting voids in a concrete ice-skating rink [6] and in
reinforced concrete slabs [7]. Once a rapid field instrument is
developed, the method can be used routinely for nondestructive testing
of plate-like structures such as slabs, pavements and walls. For these
applications, it is expected that a neural network will be used to
automate signal processing.
A Canadian mining company is currently negotiating with Cornell
University for a system that will help them determine if the structure
of a decommissioned mine is safe enough to recommission the mine.
Acknowledgements:
Research sponsored by grants from the Strategic Highway Research
Program, Project C-204 and from the National Science Foundation (PYI
Award).
BrainMaker neural network simulation software ($195) was provided by
California Scientific Software, 10141 Evening Star Drive #6, Grass
Valley, CA 95945-9051. (916) 477-7481.
--------------------
Footnotes:
1. The frequency resolution in the amplitude spectrum and thus the
accuracy of plate thickness or crack depth predictions will depend on
the sampling rate and duration of the recorded waveform.
References:
1. Manning, D.G. and Holt, F.B., "Detecting Deterioration in
Asphalt-Covered Bridge Decks," Transportation Research Record 899, 1983,
pp. 10-20.
2. Knorr, R.E., Buba, J.M., and Kogut, G.P., "Bridge Rehabilitation
Programming by Using Infrared Techniques," Transportation Research
Record 899, 1983, pp. 32-34.
3. Sansalone, M. and Carino, N.J., "Impact-Echo: A Method for Flaw
Detection in Concrete Using Transient Stress Waves," NBSIR 86-3452, NTIS
PB #87-104444/AS, Springfield, Virginia, September, 1986, 222 pp.
4. Carino, N.J., Sansalone, M., and Hsu, N.N., "Flaw Detection in
Concrete by Frequency Analysis of Impact-Echo Waveforms," in
International Advances in Nondestructive Testing, Vol. 12, ed. W.
McGonnagle, Gordon and Breach Science Publishers, 1986, pp. 117-146.
5. Sansalone, M., and Carino, N.J., "Transient Impact Response of
Plates Containing Flaws," in Journal of Research of the National Bureau
of Standards, Vol. 92, No. 6, Nov-Dec 1987, pp. 369-381.
6. Sansalone, M., and Carino, N.J., "Laboratory and Field Studies of
the Impact-Echo Method for Flaw Detection in Concrete," Nondestructive
Testing of Concrete, SP-112, American Concrete Institute, Detroit,
1988, pp. 1-20.
7. Sansalone, M. and Carino, N.J., "Detecting Delaminations in Concrete
Slabs with and without Overlays Using the Impact-Echo Method," ACI
Materials Journal, V. 85, No. 2, Mar.-Apr. 1989, pp. 175-184.
8. Stanley, J., "Introduction to Neural Networks," (c) California
Scientific Software, Sierra Madre, California, January, 1989
About the authors:
Donald G. Pratt is a doctoral student in Civil Engineering at Cornell
University. Mary Sansalone received a Ph.D. in structural engineering
from Cornell University, where she is an assistant professor. Prior to
joining the faculty at Cornell, she was a research engineer with the
National Institute of Standards and Technology. Mr. Pratt and Dr.
Sansalone may be reached at Cornell University, Hollister Hall, Ithaca,
NY 14853. Jeannette (Stanley) Lawrence is a technical writer
specializing on the subject of neural networks. She may be reached at
California Scientific Software, Grass Valley, CA.
programming/AI/situatio.ai
+110
View File
@@ -0,0 +1,110 @@
From: empath@umcc.umich.edu (Tim Triemstra)
Subject: Game AI posts:
To: jon@stekt.oulu.fi
Date: Mon, 12 Dec 1994 03:18:15 -0500 (EST)
<re-cap of Tim Triemstra's postings from rec.games.programmers>
<with respect to "situation objects" in designing an AI system>
<re-written for general availability on December 11, 1994>
<Tim can be reached at empath@umcc.umich.edu>
================================================================
A method for handling computer intelligence that I'm using is a
little simpler to implement than neural-nets: not necessarily
better or worse, maybe just "different."
All units in any type of strategy game have limitted situations
that they can be put into (the broader the definition, the
smaller the number.) IE: If you have a game with 10 tanks on
each side it could be said that there are only 11 possible
situations: 1 situation for each number of tanks visible to the
player and 1 situation where none is visible. Of course, that
is too broad to really _do_ anything with. To be of any real
value the situations must take into account strength, ranges
and other aspects of the situation.
Since I have a smaller number of units in my game, I make little
"situation objects" composed of all the various possible
situations. Each situation object also contains the orders to
give to the player. The orders are executed if it is determined
that this particular "situation object" is the best match for
the current state of the player. The higher the number of
possibilites, the greater the intellect of the computer
controlled player.
To me, this was much simpler than hand-coding a tree because I
could make a move construction kit that builds these situations
and the resultant decision and saves them into a library. Beta
testers can help build them too.
<... end of message #1 ...>
> Wait, so you build a (let's call it) a data base for each
> instance of tank vs other tanks and then a "good" solution for
> it??? Wouldn't that be huge?
Yes, in a SSI wargame it would not be a viable solution.
However, in my game (and I'm sure many other people's) there are
limitted types of units and limited quantities of units in each
mission or scenerio.
In my game, there are only 5 units (I may merge them down to 3
total types of units) which can have various attributes (larger
weapons, higher speeds etc.) but those factors are taken into
each database, or "situation object" entry.
In my early designs, only 30 or so data elements is needed for
each unit type to give what appears to be nearly adequate
responses. I also curb the results slightly by giving units
commands like "move here stealthy" or "move here while attacking
whomever you see" to stack the deck in the decision making.
Mind you, this idea of "situation objects" is purely one way to
do it that may be practicle in some gaming situations. I'm not
a big fan of simulations (like SSI games) and hence wouldn't do
a game like that. Those SSI games couldn't use my idea, but
Dune II could (and it would actually be smarter :)
<... end of message #2 ...>
Welp, the idea of finding the nearest "situation object," as I
sometimes refer to it, isn't nearly as difficult as you may
think.
First off, these objects are based completely on "relative
situations" ie: if a guy is stronger and to the upper-left
of the character then that would be one situation. So, the
tree goes something like this:
1) How many opponents are visible?
( branch to the decision objects sorted for each answer )
- branch if 1 or more
2) How many can hit me within X moves
- branch if safe to not run
3) How many can I hurt?
- branch if any
4) _SHOULD_ I try to hit him or run
- branch if try to hit
5) Which is most benefical to hit
- branch etc...
Now, in my particular game, each unit is also given priorities
that factor into this decision. So, you may tell a unit to
scout but give him the order to engage or hide, this of course
adds weight to different tree decisions.
The major advantage of a system like this, as I said, is that
you can make the AI as good or bad as you like. Quite frankly,
I'm under the opinion that a "game" does not need particularly
good AI to be a good game. Simulations (not my favorite) are a
different story. A game need only provide an enemy adequate
enough to give the player some fun and to enact the plot.
Dune II (my favorite example) has horrible AI, and anyone can
eventually beat the game, but it is unquestionably enjoyable to
play.
--
Tim Triemstra ... Empath Software .... Empath@umcc.umich.edu
<><><><> If'n you ain't the granddaddy of all liars <><><><>
programming/AI/stockpre.pro
+265
View File
@@ -0,0 +1,265 @@
1-17-90
Predicting the Stock Market with Neural Networks
by Jeannette Lawrence
Choosing a stock to buy and deciding when to buy or sell can be a
complicated and time-consuming activity. Investment experts study the
market for years to learn to see the patterns and make accurate
predictions. They use a combination of pattern recognition and their
experience from observing cause-and-effect: "I've seen this scenario
before and I know what usually happens." The experts have of various
methods to choose a good stock to buy, sometimes involving many
calculations before making any decisions. Not all experts agree as to
what information is important in making a determination.
There are also more than 250 programs available to assist you in making
decisions. Traditionally, these computer programs have used
mathematical methods such as linear regression and moving averages to
make predictions. Unfortunately, these methods cannot take anything
subjective into consideration and financial trends are often affected by
situations that are not easily reduced to equations (for example, how
foreign relations can affect the price of crude oil).
An ideal computer tool would look at the statistics as well as the
subjective aspects and give you financial advice, such as whether or not
a stock is a good buy. It would operate in real-time, and be inexpensive
and easy to use. Now there is a computing tool that accomplishes all
that: a neural network. You can purchase a neural network program that
runs on a PC for less than $200.
Neural networks may be the best computer approach to predicting the
stock market yet. They learn to predict based upon experience, just
like the experts. They are shown many examples of what has happened in
the past and they find the patterns and trends without formulas, rules
or complex programming.
Neural networks are a new kind of computing tool which simulate the
brain's structure and operation. The brain is composed of hundreds of
billions of nerve cells (neurons) which have multitudinous connections
to each other. Recently biologists have learned that it is the way the
cells are connected which provides us with intelligence, rather than
what's in the cells. Neural networks mimic many of the brain's most
powerful abilities, including pattern recognition, association and the
ability to generalize by observing data.
In this article you'll learn how neural networks operate and get a look
at a sample neural networks which predicts stock peaks and lows. Other
common uses for neural network include corporate bond evaluation,
medical diagnostic systems, insurance claim evaluation, sports event
predictions, loan risk evaluation, and business analysis and decision
making.
Life as a Neural Network
A new neural network starts out with a "blank mind". The network is
taught about a specific problem, such as predicting a stock's price,
using a technique called training. Training a neural network is like
teaching a small child. To teach a child to recognize the letters of
the alphabet, you might first show him a picture of the letter "A" and
ask him what letter he's looking at. If he doesn't guess right, you
tell him he is looking at an "A". Next, you could show him a "B" and
repeat the process. You would do this for all the letters of the
alphabet, then start over. Eventually he will learn to recognize all of
the letters correctly.
The network is shown some historical data and it guesses what the result
is. When the network is wrong, it is corrected. The next time it sees
that data, it will guess more accurately. The network is shown lots of
data, over and over until is learns all the data and results. Like a
person, a trained neural network can generalize, making a reasonable
guess from data which is different from any it has seen before.
Just how does correcting the network cause it to learn? It's all in the
connections between the neurons. The connections allow the neurons to
communicate with each other and form answers. When the network makes a
wrong guess, an adjustment is made to the way neurons are connected,
thus it is able to learn. With most commercially available neural
network programs (such as BrainMaker, the one used in the stock
predicting example) training adjustments are performed automatically by
the neural network program itself; all you have to do is provide the
data and the expected results for training.
A Neural Network Creates Its Own Working Model
When choosing a stock to buy, the experts do not agree as to what
information is important. The performance of some stocks are tied to
the strength of the economy and may react strongly to government
economic news releases. Some experts believe the price to earning ratio
(P/E) is most important. Some say "free" cash-flow (operating cash flow
minus expenditures) has more effect on stock prices than P/E ratios.
Others believe in the share price-to-book value ratio. This is probably
meaningful only when comparing stocks within the same industry. Still
others think that you should compare the P/E, yield, and price-to-book
value of the potential buy to Standard & Poor Industrials. Another
method is to use the price-to-net working capital ratio.
With a neural network, you don't need to worry about which theory to
follow or perform endless calculations for comparison. You can include
information for any or all the theories plus some subjective item such
as the quality of foreign affairs. The network will figure out what
information correlates to what. It creates its own internal
representation of the problem during training based upon whatever
information you decide to give it. People rarely use all the
information available because it's just too much to keep track of, but
neural networks do not get overwhelmed by detail. If some piece of
information you provide turns out to be unimportant, the network will
just learn to ignore it. Mathematical programs are not this flexible.
Designing a Neural Network
Designing a neural network is a simple process. The first thing you do
is decide what you want the network to tell you and what information it
will use to derive the answer. For example, suppose you want to make a
network which will predict what the Dollar to Yen ratio will be next week.
We will use a very simple design just to summarize the process. Let's
choose some indicators upon which the network will base its result:
* The change in London Gold from 2 weeks ago to 1 week ago (LG2_1)
* The change in London Gold from 1 week ago to today (LG1_0)
* Yen/Dollar exchange rate from 2 weeks ago to 1 week ago (YD2_1)
* Yen/Dollar exchange rate from 1 week ago to today (YD1_0)
* Deutche Mark/Dollar exchange from 2 weeks ago to 1 week ago (DM2_1)
* Deutche Mark/Dollar exchange from 1 week ago to today (DM1_0)
* Sterling/Dollar exchange from 2 weeks ago to 1 week ago (SD2_1)
* Sterling/Dollar exchange from 1 week ago to today (SD1_0)
* Dow Jones Average from 2 weeks ago to 1 week ago (D2_1)
* Dow Jones Average from 1 week ago to today (D1_0)
* New York Stock Exchange Volume from 2 weeks ago to 1 week ago (NYSE2_1)
* New York Stock Exchange Volume from 1 week ago to today (NYSE1_0)
The output will be the change in the Yen/Dollar exchange rate between
this week and the next:
* Yen/Dollar exchange rate next week (YD_out)
You cannot teach a neural network trends by simply presenting the values
for each type of input, one fact after another, in order of time. You
cannot tell it that fact #1 is month 1, fact #2 is month 2, etc. It
will not pick up the trend. That is why we are showing it historical
information.
Now we must collect our historical data. An easy way to do this is to
look through back issues of the Wall Street Journal, or get the
information from a financial database service. The data goes into a
file that the neural network program reads in.
In addition you can use traditional mathematical methods with neural
networks. For example, to a trend-analyzing network you can add
information based upon moving averages. Creating moving averages helps
build networks that depend on current numbers and past numbers, but
ignore extremely short small changes. For example, assume you want to
predict how the price of a stock will move, but in a general sort of way
in a bigger time frame. Based on what the average stock price has been
from week to week during this month and last, the network can predict
what the average stock price is going to be each week for the next
month. NetMaker (a data manipulation program provided with BrainMaker)
automates this task for you.
After you have your data ready (including the output), BrainMaker
program will create and train the new network for you. With some
programs, you can watch the training on your screen, edit and test the
network using pop-up menus, print out the results, graph trends, etc.
You can set the level of accuracy that you need from the network. After
the network is trained, you can give the network current information and
get a prediction of next week's change in the Yen/Dollar ratio.
The network would look like this:
Inputs: Output:
ÚÄÄÄÄÄÄÄÄÄ¿
London Gold change 2 weeks-1 week ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³
London Gold 1 week -today ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³
Yen/Dollar exchange rate change 2 weeks-1 week ÄÄÄÄÄÄ´ ³
Yen/Dollar exchange rate 1 week -today ÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³
Deutche Mark/Dollar exchange change 2 weeks-1 week ÄÄ´ The ³
Deutche Mark/Dollar exchange 1 week -today ÄÄÄÄÄÄÄÄÄÄ´ Neural ÃÄÄ Yen/Dollar
Sterling/Dollar exchange change 2 weeks-1 week ÄÄÄÄÄÄ´ Network ³ change one
Sterling/Dollar exchange 1 week -today ÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³ week later
Dow Jones Average change 2 weeks-1 week ÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³
Dow Jones Average 1 week -today ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³
NY Stock Exchange Volume change 2 weeks-1 week ÄÄÄÄÄÄ´ ³
NY Stock Exchange Volume 1 week -today ÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ ³
ÀÄÄÄÄÄÄÄÄÄÙ
Each type of input information is assigned to a certain input neuron.
Each output (result) is assigned an output neuron. What's in the box in
between? This is where all the internal, or hidden, neurons are kept.
This is the area where connections are modified during training by the
program.
A Stock Predicting Application
Once you have decided on a stock to buy, you need to know when to buy
it, and then later when to sell it. This application pinpoints when a
particular stock has reached either a long-term peak or a long-term low
in value.
Some-company has used BrainMaker to create a series of trained neural
networks for people interested in investing in the stock market. Their
system determines when a particular stock price is as high, or as low,
as it will be for a long time. The investor can then buy those stocks
which are ready to rise and sell (or sell short) stocks which have
reached their peak.
A separate network was trained for each stock being predicted. Each of
the ten current networks was trained with price data taken over the last
two years. Long-term highs and lows for training were chosen by the
resident experts. Once trained, the network detected 70% to 90% of the
actual highs and lows when it was shown data it had never seen before.
This compares very favorably with the 50% results which standard
technical analysis had been providing. In addition, intermediate highs
and lows less extreme than the ones the network had been trained to spot
were also found. In each of these intermediate cases, the appropriate
neurons fired to indicate the presence of a high or low, but they did
not fire as strongly as when indicating a long-term high or low. There
were very few cases of the network mistakenly predicting a high or low
when not even an intermediate high or low was present. In the words of
a Brainmaker user, "you're making more money with it than without it...
It's definitely picking up the trends, which in the stock market is all
you need."
Each network is organized as follows: the closing prices of a particular
stock for the twenty days up to the day you're interested in are the
inputs (the information the network uses to make its prediction). The
outputs indicate if the stock is near a high or low, and they're
organized as follows: there are thirteen outputs, each one corresponding
to a different circumstance. One output indicates that the stock is not
nearing either a high or a low; this is by far the most common case.
Six of the outputs correspond to a stock nearing a high; one of these
means the high is today; the others indicate a high in one to five days
from now, respectively. Similarly, there are six outputs indicating
that the stock is nearing a low, in either one to five days, or today.
The output neuron corresponding to today's condition is assigned a value
of 1; the other 12 are given value 0.
Some-company currently has networks trained to locate trends in AT&T,
Mobil, Boeing, and seven other major corporations. As their service
grows, they plan to expand to the entire Standard & Poor's 100, and
eventually the S & P 500.
This is a particularly well-designed network because it utilizes a real
neural network strength, namely noticing hard-to-find patterns in large
amounts of data, without requiring a high degree of numerical accuracy.
Summary
People have successfully designed and trained neural networks to predict
the stock market. Neural networks function by finding patterns in the
examples which you provide. These patterns become a part of the network
during training. You only need to provide the data upon which you want
the network to base its predictions. Neural networks operate at
lightning speed, are inexpensive and run on PC's.
The network described above was created with the BrainMaker Neural
Network Software System. BrainMaker is available from California
Scientific Software, 10141 Evening Star Dr. #6, Grass Valley, CA
95945-9051, and includes a 255-page "Introduction to Neural Networks"
and a 422-page User's Guide. The price is $195.00.
Note: Some-company has asked to have their name withheld except by
special permission.
programming/AI/strateg2.ai
+123
View File
@@ -0,0 +1,123 @@
From: andrew@cs.uct.ac.za (Andrew Luppnow)
Date: Fri, 2 Dec 1994 10:10:50 +0200 (SAT)
This document proposes an approach to the problem of
designing the AI routines for intelligent computer wargame
opponents. It is hoped that the scheme will allow the
efficient, or at least feasible, implementation of opponents
which are capable of formulating strategy, rather than
behaving predictably according to fixed sets of simple rules.
In the text below, "DMS" is an abbreviation for "decision-
making-system". I use the term very loosely to denote any
programming subsystem which accepts, as input, a "situation"
and which generates, as output, a "response". The DMS may
be a simple neural network, a collection of hard-coded
rules, a set of fuzzy logic rules, a simple lookup table,
or whatever you want it to be! It's most important feature
is that it must be SIMPLE and TRACTABLE - in particular, it
must accept input from a small, finite set of possible
inputs and generate output which belongs in a similarly
small, finite set of possible outputs.
Some time ago I asked myself how a programmer might begin to
implement the AI of a wargame which requires the computer
opponent to develop a sensible military strategy. I
eventually realized that simply feeding a SINGLE decision-
making system with information concerning the position and
status of each friendly and enemy soldier is hopelessly
inefficient - it would be akin to presenting a general with
such information and expecting him to dictate the movement
of each soldier!
But in reality a general doesn't make that type of decision,
and neither does he receive information about the precise
location of each soldier on the battlefield. Instead, he
receives _strategic_ information from his commanders, makes
strategic decisions and presents the chosen strategy to the
commanders. The commanders, in turn, receive _tactical_
information and make tactical decisions based on (1) that
information and (2) the strategy provided by the general.
And so the process continues until, at the very bottom level,
each soldier receives precise orders about what he and his
immediate comrades are expected to accomplish.
The important point is that the whole process can be envisaged
in terms of several 'levels'. Each level receives information
>from the level immediately below it, 'summarises' or
'generalises' that information and presents the result to
the level immediately above it. In return, it receives a set
of objectives from the level above it and uses (1) this set
of objectives and (2) the information from the lower level
to compute a more precise set of objectives. This latter
set of objectives then becomes the 'input from above' of the
next lower level, and so on. In summary: information filters
UP through the levels, becoming progressively more general,
while commands and objectives filter DOWN through the levels,
becoming progressively more detailed and precise.
I decided that this paradigm might represent a good conceptual
model for the implementation of the AI procedures in a
complex strategy-based game: a "tree of DMS's" can be used to
mimic the chain of command in a military hierarchy.
Specifically, one might use one or more small, relatively simple
DMS's for each level. The inputs for a DMS of level 'k' would
be the outputs of a level (k+1) DMS and the information
obtained by 'summarising' level (k-1) information. The outputs
of the level k DMS would, in turn, serve as inputs for one or
more level (k-1) DMS's. Outputs of the level zero DMS's would
be used to update the battlefield.
"Top brass" - fewer,
MORE GENERAL options
allow lookahead and
Level 3 ^ o "what-if reasoning."
/|\ / \
Level 2 / | \ o o
| /|\ |\
Level 1 | o o o o o
\ | / /| | | | |\
Level 0 \|/ o o o o o o o Individual soldiers -
V many options, but
decision-making is
As information simple and doesn't
filters UP the attempt "lookahead",
tree, it becomes "what-if reasoning",
more general. As etc.
objectives filter
DOWN the tree,
they become more
specific.
The main advantage of this scheme is that it allows the "higher
levels" of the hierarchy to formulate strategy, without being
overwhelmed by the immense and intractably large number of
possibilities which the computer AI would have to consider if
it possessed only information about individual soldiers.
Indeed, at the topmost level, decisions would involve rather
abstract options such as
- "direct all military activity towards seizing territory X",
or
- "conduct wars of attrition in territories X, Y, and Z",
or
- "buy time - stick to diplomacy for the time being",
or
- "avoid direct military engagement - concentrate on disrupting
enemy supply routes",
etc.
Under these circumstances, it would be feasible for the computer
to attempt a certain amount of "lookahead", or to consider
"what-if" scenarios - something which would be out of the
question if options were presented in terms of the actions of
individual soldiers.
At the time of writing this, I haven't yet had the opportunity
to explore an implementation of these ideas in a working game,
but if anybody DOES enjoy some practical success with these
ideas, I'd be interested in hearing from him/her!
--- Andrew Luppnow
programming/AI/thexvirt.tes
+122
View File
@@ -0,0 +1,122 @@
---------------------------------------------------------
The Ultimate Turing Test
Rought Draft #1
(c) copyright 1992 by David Barberi
dbarberi@sunsite.unc.edu
---------------------------------------------------------
What is the ultimate Turing Test?
In 1950 Alan Turing published his now famous paper
"Computing Machinery and Intelligence." In that paper he
describes a method for humans to test AI programs. In its most
basic form, a human judge sits at a computer terminal and
interacts with the subject by written communication only. The
judge decide if the subject on the other end of the computer link
is a human or an AI program imitating a human.
Can Turings test be improved on? Yes. With current
advances in computer graphics, virtual reality, biomechanics and
many other fields, it is possible to create an "Enhanced" or
"Virtual" Turing test. The underlying idea of the test is still
the same, but the amount of interaction between judge and subject
is increased greatly.
How would this Virtual Turing Test work? The first step is
to create a 'world' for the judge and subject to inhabit.
('World' is a Virtual Reality term that signifies a shared
electronic space, or cyberspace, where everyone immersed in it
has the ability to interact with everything else in the world)
With current technology this may require the judge to wear a
bodysuit, gloves, and eyephones. In the future, such bulky
methods of entering cyberspace will be replaced by more natural
and unobtrusive means, such as a direct neural interface.
When the judge is immersed into the Virtual Turing Test
world all his sensual stimulations are produced by the computer.
The judge sees a three dimensional, high resolution computer
graphic image of this new world from the viewpoint of his virtual
twin. Inside this world the subject and various physical objects
reside (let us say 2 chairs, a table, some cups, and a steaming
pot of tea). The judge can sit at the chair, grab a cup and feel
the texture of the cup against his hand by use of tactile
response material next to his skin. The judge can change his
viewpoint by getting up and walking around. If he drops the cup
on the floor, it will shatter and a suitable sound will emerge
from the three dimensional coordinates where the cup landed. For
all extents and purposes, when he judge is immersed in the
Virtual Turing Test the outside world does not exist.
Sitting across from the judge will be the subject, a
computer graphic image of a human being. The judge will not know
if the subjects actions are controlled by another human or a
suitably advanced computer simulation. The subject could be
someone in the next room wearing the same equipment that the
judge is wearing, and immersed in the same world that the judge
is in. It is the judges role to test the subject and decide if
it is human or not.
If the subject is a human the computer will copy every
movement the subject makes, every sound that they produce, every
facial expression, every hand gesture, every eye movement. When
the subject talks, the sound will originate from the mouth of the
subjects virtual copy.
If the subject is a simulation then the computer will
control every aspect of the subject. The simulation must be able
to speak and interact with the judge in every way that the a
human subject would. If the judge reaches across the table to
slap the subject in the head, the simulation will realize this
and dodge out of the way, much like any human would do. The
simulation will be able to interact with the virtual environment
in every way that the judge can. If the judge politely asks the
subject to pour them both a cup of tea, this physical interaction
will be no problem for the simulation.
The core of the simulation must control three basic items:
comphrehensive communication with the judge, correct
biomechanical movement, and awareness of its environment.
The last of these items is the simplest. The computer
already knows where every object is in the virtual world. It can
easily calculate what 2 images would enter the simulations eyes
from whatever viewpoint it happens to be at. Of course, the
control program should not allow the simulation to know more then
it should. If the Judge is holding a book behind his back and
the simulation has not 'seen' the book yet, then, even through
the control program knows where and what the book is, it will not
pass this information to the simulation until the book comes into
its field of view.
The second item, correct biomechanical movement, deals with
the way humans move. It is impossible for a normal human to bend
his elbow past a certain point. The simulation will follow all
the physical limitations that the human body has. It may not
create a new arm or leg if needed, it may not turn it's head
around 360 degrees, it may not fly into the air by flapping its
arms, etc. This aspect of the simulation, while by no means
trivial, can be created with the biomechanical data available
today.
The last, and hardest, item is comphrehensive
communications. By comphrehensive we are not only talking about
spoken words, but also the wealth of non-verbal cues that humans
use. Such things that we take for granted, such as hand
gestures, gaze of the eyes, position of the limbs, and facial
gestures are all examples of non-verbal communications. It is
the simulations job to use both verbal and non-verbal
communications to make the judge think it is acting in a very
'human' way.
How does this Virtual Turing Test compare to Turings
original test? We have replaced the limited communications
allowed by two connected computer terminals with a comphrehensive
environment of sight, sound and body. We allow the judge to base
his decision not only on written words, but on spoken speech,
non-verbal cues, and body movement.
The test still holds to the spirit of the original. There
is still a human judge that must use his intelligence and savvy
to test the subject. Like the original test, the judge has no
way of telling if the subject is human or not until he interacts
with it. Like the original test, the goal of the computer is to
create a simulation of human action so realistic that not even
other humans can tell the difference.
The technology exists today to hold a simplistic Virtual
Turing Test. As more research and work is put into Virtual
Reality, AI, and biomechanics, a suitably advanced human
simulation can, and will, be produced.
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
programming/CARDS/16032
+240
View File
@@ -0,0 +1,240 @@
----------------------------------------------------------------
| |
| |
| National Semiconductor |
| |
| 1 666 000 33333 22222 |
| 11 6 0 0 3 3 2 2 |
| 1 6 0 0 0 3 2 |
| 1 666666 0 0 0 33333 222 |
| 1 6 6 0 0 0 3 2 |
| 1 6 6 0 0 3 3 2 |
| 111 66666 000 33333 2222222 |
| |
| NS16032 MICROPROCESSOR Instruction Set Summary |
| |
| _________ _________ |
| _| \__/ |_ |
| <-- A22 |_|1 48|_| Vcc |
| _| |_ |
| <-- A21 |_|2 47|_| A23 --> |
| _| |_ ___ |
| <-- A20 |_|3 46|_| INT <-- |
| _| |_ ___ |
| <-- A19 |_|4 45|_| NMI <-- |
| _| |_ ___ |
| <-- A18 |_|5 44|_| ILO --> |
| _| |_ |
| <-- A17 |_|6 43|_| ST0 --> |
| _| |_ |
| <-- A16 |_|7 42|_| ST1 --> |
| _| |_ |
| <--> AD15 |_|8 41|_| ST2 --> |
| _| |_ |
| <--> AD14 |_|9 40|_| ST3 --> |
| _| |_ ___ |
| <--> AD13 |_|10 39|_| PFS --> |
| _| |_ ____ |
| <--> AD12 |_|11 38|_| DDIN --> |
| _| |_ ___ |
| <--> AD11 |_|12 NS16032 37|_| ADS --> |
| _| |_ _ |
| <--> AD10 |_|13 36|_| U/S --> |
| _| |_ __ ___ |
| <--> AD9 |_|14 35|_| AT/SPC <--> |
| _| |_ ___ --- |
| <--> AD8 |_|15 34|_| RST/ABT <-- |
| _| |_ __ ___ |
| <--> AD7 |_|16 33|_| DS/FLT <--> |
| _| |_ ___ |
| <--> AD6 |_|17 32|_| HBE --> |
| _| |_ ____ |
| <--> AD5 |_|18 31|_| HLDA --> |
| _| |_ ____ |
| <--> AD4 |_|19 30|_| HOLD <-- |
| _| |_ |
| <--> AD3 |_|20 29|_| BBG |
| _| |_ |
| <--> AD2 |_|21 28|_| RDY <-- |
| _| |_ |
| <--> AD1 |_|22 27|_| PHI2 <-- |
| _| |_ |
| <--> AD0 |_|23 26|_| PHI1 <-- |
| _| |_ |
| GNDL |_|24 25|_| GNDB |
| |______________________| |
| |
| |
|Written by Jonathan Bowen |
| Programming Research Group |
| Oxford University Computing Laboratory |
| 8-11 Keble Road |
| Oxford OX1 3QD |
| England |
| |
| Tel +44-865-273840 |
| |
|Created October 1982 |
|Updated April 1985 |
|Issue 1.1 Copyright (c) J.P.Bowen 1985|
----------------------------------------------------------------
----------------------------------------------------------------
|Mnemonic |Description |
|---------------+----------------------------------------------|
|ABSi g,g |Take Absolute value |
|ABSf g,g |Take Absolute floating point value |
|ACBi s,g,d |Add 4-bit Constant and Branch if non-zero |
|ADDi g,g |Add |
|ADDf g,g |Add floating point values |
|ADDCi g,g |Add with Carry |
|ADDPi g,g |Add Packed (BCD) |
|ADDQi s,g |Add Quick a 4-bit constant |
|ADDR g,g |Move effective Address |
|ADJSPi g |Adjust Stack Pointer |
|ANDi g,g |Logical AND |
|ASHi g,g |Arithmetic Shift, left or right |
|Bcc d |Branch on condition (cc) |
|BICi g,g |Bit Clear |
|BICPSRi g |Bit Clear Processor Status Register (i=W/D #)|
|BISPSRi g |Bit Set Processor Status Register (i=W/D #)|
|BPT |Breakpoint Trap |
|BR d |Branch (PC relative) |
|BSR d |Branch to Subroutine |
|CASEi g |Case (multiway branch) |
|CATSTn g |Custom Address Test (n=0-1) (#)|
|CBITi g,g |Test and Clear Bit |
|CBITIi g,g |Test and Clear Bit Interlocked |
|CCALnc g,g |Custom Calculate (n=0-3) |
|CCMPc g,g |Custom Compare |
|CCVnci g,g |Custom Convert custom value to integer (n=0-2)|
|CCV3ic g,g |Custom Convert integer to custom value |
|CCV4DQ g,g |Custom Convert double to quad value |
|CCV5QD g,g |Custom Convert quad to double value |
|CHECKi r,g,g |Check index bounds |
|CMPi g,g |Compare |
|CMPf g,g |Compare floating point values |
|CMPMi g,g,d |Compare Multiple: displacement bytes |
|CMPQi s,g |Compare Quick with a 4-bit constant |
|CMPSi ol |Compare Strings |
|CMPSTi ol |Compare Strings, Translating bytes |
|COMi g,g |Complement all bits |
|CMOVnc g,g |Custom Move (n=0-2) |
|CVTP r,g,g |Convert to bit field Pointer |
|CXP d |Call External Procedure |
|CXPD g |Call External Procedure using Descriptor |
|DEIi g,g |Divide Extended Integer |
|DIA |Diagnose (hardware breakpoint) |
|DIVi g,g |Divide, rounding down |
|DIVf g,g |Divide floating point values |
|ENTER (rl),d |Enter procedure (save registers) |
|EXIT (rl) |Exit procedure (restore registers) |
|EXTi r,g,g,d|Extract bit field (array orientated) |
|EXTSi g,g,m,m|Extract Short bit field |
|FLAG |Flag trap |
|FLOORfi g,g |Convert f.p. to largest integer <= value |
|FFSi g,g |Find First Set bit |
|IBITi g,g |Test and Invert Bit |
|INDEXi r,g,g |Recursive Indexing step for N-D arrays |
|INSi r,g,g,d|Insert bit field (array orientated) |
|INSSi g,g,m,m|Insert Short bit field |
|JSR g |Jump to Subroutine |
|JUMP g |Jump |
|LCR cr,g |Load Custom Register (#)|
|LCSR g |Load Custom Status Register |
|LFSR g |Load Floating point Status Register |
|LMR mr,g |Load Memory management Register (#)|
|LPRi ar,g |Load dedicated Register (a=PSR/INTBASE #)|
|LSHi g,g |Logical Shift, left or right |
|MEIi g,g |Multiply to Extended Integer |
|MODi g,g |Modulus (remainder from QUO) |
|MOVi g,g |Move a value |
|MOVif g,g |Move an integer to a floating point value |
|MOVf g,g |Move a floating point value |
|MOVFL g,g |Move and lengthen a floating point value |
|MOVLF g,g |Move and shorten a Long floating point value |
|MOVMi g,g,d |Move Multiple: displacement bytes |
|MOVQi s,g |Move Quick and extend a 4-bit constant |
|MOVSi ol |Move String |
|MOVSTi ol |Move String, Translating bytes |
|MOVSUi g,g |Move value from Supervisor to User space (#)|
----------------------------------------------------------------
----------------------------------------------------------------
|Mnemonic |Description |
|---------------+----------------------------------------------|
|MOVUSi g,g |Move value from User to Supervisor space (#)|
|MOVXiD g,g |Move with sign Extension to Double word |
|MOVXBW g,g |Move with sign Extension Byte to Word |
|MOVZiD g,g |Move with Zero extension to Double word |
|MOVZBW g,g |Move with Zero extension Byte to Word |
|MULi g,g |Multiply |
|MULf g,g |Multiply floating point values |
|NEGi g,g |Negate (2's complement) |
|NEGf g,g |Negate floating point value |
|NOP |No Operation |
|NOTi g,g |Logical NOT (LSB only) |
|ORi g,g |Logical OR |
|QUOi g,g |Quotient (divide, rounding towards zero) |
|RDVAL g |Validate address for Reading (#)|
|REMi g,g |Remainder from QUO |
|RESTORE (rl) |Restore general purpose registers |
|RET d |Return from subroutine |
|RETI |Return from Interrupt (#)|
|RETT d |Return from Trap (#)|
|ROTi g,g |Rotate, left or right |
|ROUNDfi g,g |Round a floating point value to an integer |
|RXP d |Return from External Procedure call |
|Scci g |Save condition code (cc) as a Boolean value |
|SAVE (rl) |Save general purpose registers |
|SBITi g,g |Test and Set Bit |
|SBITIi g,g |Test and Set Bit Interlocked |
|SCR cr,g |Store Custom Register (#)|
|SCSR g |Store Custom Status Register |
|SETCFG (o) |Set Configuration register (#)|
|SFSR g |Store Floating point Status Register |
|SKPSi ol |Skip over String |
|SKPSTi ol |Skip over String, Translating bytes |
|SMR mr,g |Store Memory management Register (#)|
|SPRi ar,g |Store dedicated Register (a=PSR/INTBASE #)|
|SUBi g,g |Subtract |
|SUBf g,g |Subtract floating point values |
|SUBCi g,g |Subtract with Carry (borrow) |
|SUBPi g,g |Subtract Packed (BCD) |
|SVC |Supervisor Call |
|TBITi g,g |Test Bit |
|TRUNCfi g,g |Truncate toward zero floating point to integer|
|WAIT |Wait for interrupt |
|WRVAL g |Validate address for Writing (#)|
|XORi g,g |Logical Exclusive OR |
|---------------+----------------------------------------------|
| CFG |Configuration register (4-bit) |
| EXTERNAL |External link table entry |
| FP |Frame Pointer register (32-bit, top 8 zero) |
| INTBASE |Interrupt Base register (32-bit, top 8 zero) |
| MOD |Module register (16-bit) |
| PC |Program Counter (32-bit, top 8 zero) |
| PSR |Processor Status Register (16-bit) |
| Rn or Fn |General purpose Registers (32-bit, n=0-7) |
| SB |Static Base register (32-bit, top 8 zero) |
| SP0 (SP) |Supervisor Stack Pointer (32-bit, top 8 zero) |
| SP1 (SP) |User Stack Pointer (32-bit, top 8 zero) |
| TOS |Top Of current Stack |
| US |User Status (8-bit, bottom byte of PSR) |
|---------------+----------------------------------------------|
| ar |Dedicated reg. (SP/SB/FP/MOD/INTBASE/PSR/US) |
| c |Custom length (D/Q=double/quad word) |
| cc |(EQ/NE/CS/CC/HI/LS/GT/LE/FS/FC/LO/HS/LT/GE) |
| cr |Custom slave processor register |
| d |Displacement constant (8/16/32-bit) |
| f |Floating point length (F/L=standard/long) |
| g |General operand |
| i |Integer length (B/W/D=byte/word/double word) |
| m |Implied immediate constant (8-bit) |
| mr |Memory management status/control register |
| n |Digit |
| o |Options (B/U/W=backward/until/while) |
| ol |Option list (C/M/F/I=custom/MMU/FPU/interrupt)|
| r |General purpose register (R0-R7/F0-F7) |
| rl |General purpose register list |
| s |Short signed 4-bit value |
| # |Privileged instruction |
----------------------------------------------------------------
programming/CARDS/1802
+240
View File
@@ -0,0 +1,240 @@
----------------------------------------------------------------
| |
| |
| RCA |
| |
| 1 88888 000 22222 |
| 11 8 8 0 0 2 2 |
| 1 8 8 0 0 0 2 |
| 1 88888 0 0 0 222 |
| 1 8 8 0 0 0 2 |
| 1 8 8 0 0 2 |
| 111 88888 000 2222222 |
| |
| CDP1802 COSMAC Microprocessor Instruction Set Summary |
| |
| |
| |
| |
| |
| _________ _________ |
| _| \__/ |_ |
| --> CLOCK |_|1 40|_| Vdd |
| ____ _| |_ ____ |
| --> WAIT |_|2 39|_| XTAL --> |
| _____ _| |_ ______ |
| --> CLEAR |_|3 38|_| DMA IN <-- |
| _| |_ _______ |
| <-- Q |_|4 37|_| DMA OUT <-- |
| _| |_ _________ |
| <-- SC1 |_|5 36|_| INTERRUPT <-- |
| _| |_ ___ |
| <-- SC0 |_|6 35|_| MWR <-- |
| ___ _| |_ |
| <-- MRD |_|7 34|_| TPA --> |
| _| |_ |
| <--> BUS 7 |_|8 33|_| TPB --> |
| _| |_ |
| <--> BUS 6 |_|9 32|_| MA7 --> |
| _| |_ |
| <--> BUS 5 |_|10 1802 31|_| MA6 --> |
| _| |_ |
| <--> BUS 4 |_|11 30|_| MA5 --> |
| _| |_ |
| <--> BUS 3 |_|12 29|_| MA4 --> |
| _| |_ |
| <--> BUS 2 |_|13 28|_| MA3 --> |
| _| |_ |
| <--> BUS 1 |_|14 27|_| MA2 --> |
| _| |_ |
| <--> BUS 0 |_|15 26|_| MA1 --> |
| _| |_ |
| Vcc |_|16 25|_| MA0 --> |
| _| |_ ___ |
| <-- N2 |_|17 24|_| EF1 <-- |
| _| |_ ___ |
| <-- N1 |_|18 23|_| EF2 <-- |
| _| |_ ___ |
| <-- N0 |_|19 22|_| EF3 <-- |
| _| |_ ___ |
| Vss |_|20 21|_| EF4 <-- |
| |______________________| |
| |
| |
| |
| |
| |
| |
|Written by Jonathan Bowen |
| Programming Research Group |
| Oxford University Computing Laboratory |
| 8-11 Keble Road |
| Oxford OX1 3QD |
| England |
| |
| Tel +44-865-273840 |
| |
|Created August 1981 |
|Updated April 1985 |
|Issue 1.3 Copyright (C) J.P.Bowen 1985|
----------------------------------------------------------------
----------------------------------------------------------------
|Mnem. |Op|F|Description |Notes |
|------+--+-+----------------------------+---------------------|
|ADC |74|*|Add with Carry |{DF,D}=mx+D+DF |
|ADCI i|7C|*|Add with Carry Immediate |{DF,D}=mp+D+DF,p=p+1 |
|ADD |F4|*|Add |{DF,D}=mx+D |
|ADI i|FC|*|Add Immediate |{DF,D}=mp+D,p=p+1 |
|AND |F2|*|Logical AND |D={mx}&D |
|ANI i|FA|*|Logical AND Immediate |D={mp}&D,p=p+1 |
|B1 a|34|-|Branch if EF1 |If EF1=1 BR else NBR |
|B2 a|35|-|Branch if EF2 |If EF2=1 BR else NBR |
|B3 a|36|-|Branch if EF3 |If EF3=1 BR else NBR |
|B4 a|37|-|Branch if EF4 |If EF4=1 BR else NBR |
|BDF a|33|-|Branch if DF |If DF=1 BR else NBR |
|BGE a|33|-|Branch if Greater or Equal |See BDF |
|BL a|38|-|Branch if Less |See BNF BR else NBR |
|BM a|38|-|Branch if Minus |See BNF |
|BN1 a|3C|-|Branch if Not EF1 |If EF1=0 BR else NBR |
|BN2 a|3D|-|Branch if Not EF2 |If EF2=0 BR else NBR |
|BN3 a|3E|-|Branch if Not EF3 |If EF3=0 BR else NBR |
|BN4 a|3F|-|Branch if Not EF4 |If EF4=0 BR else NBR |
|BNF a|38|-|Branch if Not DF |If DF=0 BR else NBR |
|BNQ a|39|-|Branch if Not Q |If Q=0 BR else NBR |
|BNZ a|3A|-|Branch if D Not Zero |If D=1 BR else NBR |
|BPZ a|33|-|Branch if Positive or Zero |See BDF |
|BQ a|31|-|Branch if Q |If Q=1 BR else NBR |
|BR a|30|-|Branch |pl=mp |
|BZ a|32|-|Branch if D Zero |If D=0 BR else NBR |
|DEC r|2N|-|Decrement register N |n=n-1 |
|DIS |71|-|Disable |{X,P}=mx,x=x+1,IE=0 |
|GHI r|9N|-|Get High register N |D=nh |
|GLO r|8N|-|Get Low register N |D=nl |
|IDL |00|-|Idle (wait for DMA or int.) |Bus=m0 |
|INC r|1N|-|Increment register N |n=n+1 |
|INP d|6N|-|Input (N=d+8=9-F) |mx=Bus,D=Bus,Nlines=d|
|IRX |60|-|Increment register X |x=x+1 |
|LBDF a|C3|-|Long Branch if DF |If DF=1 LBR else LNBR|
|LBNF a|C8|-|Long Branch if Not DF |If DF=0 LBR else LNBR|
|LBNQ a|C9|-|Long Branch if Not Q |If Q=0 LBR else LNBR |
|LBNZ a|CA|-|Long Branch if D Not Zero |If D=1 LBR else LNBR |
|LBQ a|C1|-|Long Branch if Q |If Q=1 LBR else LNBR |
|LBR a|C0|-|Long Branch |p=mp |
|LBZ a|C2|-|Long Branch if D Zero |If D=0 LBR else LNBR |
|LDA r|4N|-|Load advance |D=mn,n=n+1 |
|LDI i|F8|-|Load Immediate |D=mp,p=p+1 |
|LDN r|0N|-|Load via N (except N=0) |D=mn |
|LDX |F0|-|Load via X |D=mx |
|LDXA |72|-|Load via X and Advance |D=mx,x=x+1 |
|LSDF |CF|-|Long Skip if DF |If DF=1 LSKP else NOP|
|LSIE |CC|-|Long Skip if IE |If IE=1 LSKP else NOP|
|LSKP |C8|-|Long Skip |See NLBR |
|LSNF |C7|-|Long Skip if Not DF |If DF=0 LSKP else NOP|
|LSNQ |C5|-|Long Skip if Not Q |If Q=0 LSKP else NOP |
|LSNZ |C6|-|Long Skip if D Not Zero |If D=1 LSKP else NOP |
|LSQ |CD|-|Long Skip if Q |If Q=1 LSKP else NOP |
|LSZ |CE|-|Long Skip if D Zero |If D=0 LSKP else NOP |
|MARK |79|-|Push X,P to stack (T={X,P})|m2={X,P},X=P,r2=r2-1 |
|NBR |38|-|No short Branch (see SKP) |p=p+1 |
|NLBR a|C8|-|No Long Branch (see LSKP) |p=p+2 |
|NOP |C4|-|No Operation |Continue |
|OR |F1|*|Logical OR |D={mx}vD |
|ORI i|F9|*|Logical OR Immediate |D={mp}vD,p=p+1 |
|OUT d|6N|-|Output (N=d=1-7) |Bus=mx,x=x+1,Nlines=d|
|PLO r|AN|-|Put Low register N |nl=D |
|PHI r|BN|-|Put High register N |nh=D |
|REQ |7A|-|Reset Q |Q=0 |
|RET |70|-|Return |{X,P}=mx,x=x+1,IE=1 |
|RSHL |7E|*|Ring Shift Left |See SHLC |
|RSHR |76|*|Ring Shift Right |See SHRC |
|SAV |78|-|Save |mx=T |
|SDB |75|*|Subtract D with Borrow |{DF,D}=mx-D-DF |
|SDBI i|7D|*|Subtract D with Borrow Imm. |{DF,D}=mp-D-DF,p=p+1 |
|SD |F5|*|Subtract D |{DF,D}=mx-D |
|SDI i|FD|*|Subtract D Immediate |{DF,D}=mp-D,p=p+1 |
|SEP r|DN|-|Set P |P=N |
|SEQ |7B|-|Set Q |Q=1 |
|SEX r|EN|-|Set X |X=N |
|SHL |FE|*|Shift Left |{DF,D}={DF,D,0}<- |
|SHLC |7E|*|Shift Left with Carry |{DF,D}={DF,D}<- |
----------------------------------------------------------------
----------------------------------------------------------------
|Mnem. |Op|F|Description |Notes |
|------+--+-+----------------------------+---------------------|
|SHR |F6|*|Shift Right |{D,DF}=->{0,D,DF} |
|SHRC |76|*|Shift Right with Carry |{D,DF}=->{D,DF} |
|SKP |38|-|Short Skip |See NBR |
|SMB |77|*|Subtract Memory with Borrow |{DF,D}=D-mx-{~DF} |
|SMBI i|7F|*|Subtract Mem with Borrow Imm|{DF,D}=D-mp-~DF,p=p+1|
|SM |F7|*|Subtract Memory |{DF,D}=D-mx |
|SMI i|FF|*|Subtract Memory Immediate |{DF,D}=D-mp,p=p+1 |
|STR r|5N|-|Store via N |mn=D |
|STXD |73|-|Store via X and Decrement |mx=D,x=x-1 |
|XOR |F3|*|Logical Exclusive OR |D={mx}.D |
|XRI i|FB|*|Logical Exclusive OR Imm. |D={mp}.D,p=p+1 |
| | |-|Interrupt action |T={X,P},P=1,X=2,IE=0 |
|------+--+-+--------------------------------------------------|
| |??| |8-bit hexadecimal opcode |
| |?N| |Opcode with register/device in low 4/3 bits |
| | |-|DF flag unaffected |
| | |*|DF flag affected |
|-----------+--------------------------------------------------|
| mn |Register addressing |
| mx |Register-indirect addressing |
| mp |Immediate addressing |
| R( ) |Stack addressing (implied addressing) |
|-----------+--------------------------------------------------|
|DFB n(,n) |Define Byte |
|DFS n |Define Storage block |
|DFW n(,n) |Define Word |
|-----------+--------------------------------------------------|
| D |Data register (accumulator, 8-bit) |
| DF |Data Flag (ALU carry, 1-bit) |
| I |High-order instruction digit (4-bit) |
| IE |Interrupt Enable (1-bit) |
| N |Low-order instruction digit (4-bit) |
| P |Designates Program Counter register (4-bit) |
| Q |Output flip-flop (1-bit) |
| R |1 of 16 scratchpad Registers(16-bit) |
| T |Holds old {X,P} after interrupt (X high, 8-bit) |
| X |Designates Data Pointer register (4-bit) |
|-----------+--------------------------------------------------|
| mn |Memory byte addressed by R(N) |
| mp |Memory byte addressed by R(P) |
| mx |Memory byte addressed by R(X) |
| m? |Memory byte addressed by R(?) |
| n |Short form for R(N) |
| nh |High-order byte of R(N) |
| nl |Low-order byte of R(N) |
| p |Short form for R(P) |
| pl |Low-order byte of R(P) |
| r? |Short form for R(?) |
| x |Short form for R(X) |
|-----------+--------------------------------------------------|
| R(N) |Register specified by N |
| R(P) |Current program counter |
| R(X) |Current data pointer |
| R(?) |Specific register |
|-----------+--------------------------------------------------|
| a |Address expression |
| d |Device number (1-7) |
| i |Immediate expression |
| n |Expression |
| r |Register (hex digit or an R followed by hex digit)|
|-----------+--------------------------------------------------|
| + |Arithmetic addition |
| - |Arithmetic subtraction |
| * |Arithmetic multiplication |
| / |Arithmetic division |
| & |Logical AND |
| ~ |Logical NOT |
| v |Logical inclusive OR |
| . |Logical exclusive OR |
| <- |Rotate left |
| -> |Rotate right |
| { } |Combination of operands |
| ? |Hexadecimal digit (0-F) |
| --> |Input pin |
| <-- |Output pin |
| <--> |Input/output pin |
----------------------------------------------------------------
programming/CARDS/2650
+240
View File
@@ -0,0 +1,240 @@
----------------------------------------------------------------
| |
| |
| Signetics |
| |
| 22222 666 5555555 000 |
| 2 2 6 5 0 0 |
| 2 6 5 0 0 0 |
| 222 666666 555555 0 0 0 |
| 2 6 6 5 0 0 0 |
| 2 6 6 5 0 0 |
| 2222222 66666 555555 000 |
| |
| 2650 MICROPROCESSOR Instruction Set Summary |
| |
| |
| |
| |
| |
| _________ _________ |
| _| \__/ |_ |
| --> SENSE |_|1 40|_| FLAG --> |
| _| |_ |
| <-- A12 |_|2 39|_| Vcc |
| _| |_ |
| <-- A11 |_|3 38|_| CLOCK <-- |
| _| |_ _____ |
| <-- A10 |_|4 37|_| PAUSE <-- |
| _| |_ _____ |
| <-- A9 |_|5 36|_| OPACK <-- |
| _| |_ ____ |
| <-- A8 |_|6 35|_| RUN/WAIT --> |
| _| |_ |
| <-- A7 |_|7 34|_| INTACK --> |
| _| |_ |
| <-- A6 |_|8 33|_| D0 <--> |
| _| |_ |
| <-- A5 |_|9 32|_| D1 <--> |
| _| |_ |
| <-- A4 |_|10 2650A 31|_| D2 <--> |
| _| |_ |
| <-- A3 |_|11 30|_| D3 <--> |
| _| |_ |
| <-- A2 |_|12 29|_| D4 <--> |
| _| |_ |
| <-- A1 |_|13 28|_| D5 <--> |
| _| |_ |
| <-- A0 |_|14 27|_| D6 <--> |
| _____ _| |_ |
| --> ADREN |_|15 26|_| D7 <--> |
| _| |_ ______ |
| --> RESET |_|16 25|_| DBUSEN <-- |
| ______ _| |_ |
| --> INTREQ |_|17 24|_| OPREQ --> |
| _ _| |_ _ |
| <-- A14-D/C |_|18 23|_| R/W --> |
| __ _| |_ |
| <-- A13-E/NE |_|19 22|_| WRP --> |
| __ _| |_ |
| <-- M/IO |_|20 21|_| GND |
| |______________________| |
| |
| |
| |
| |
| |
| |
|Written by Jonathan Bowen |
| Programming Research Group |
| Oxford University Computing Laboratory |
| 8-11 Keble Road |
| Oxford OX1 3QD |
| England |
| |
| Tel +44-865-273840 |
| |
|Created March 1982 |
|Updated April 1985 |
|Issue 1.1 Copyright (C) J.P.Bowen 1985|
----------------------------------------------------------------
----------------------------------------------------------------
|Mnemonic|Op|cIOC|~|Description |Notes |
|--------+--+----+-+------------------------------+------------|
|ADDA,r a|8C|****|4|Add Absolute |r=r+a |
|ADDI,r i|84|****|2|Add Immediate |r=r+i |
|ADDR,r l|88|****|3|Add Relative |r=r+l |
|ADDZ,r |80|****|2|Add to register Zero |R0=R0+r |
|ANDA,r a|4C|*---|4|Logical AND Absolute |r=r&a |
|ANDI,r i|44|*---|2|Logical AND Immediate |r=r&i |
|ANDR,r l|48|*---|3|Logical AND Relative |r=r&l |
|ANDZ,r |40|*---|2|Logical AND register Zero |R0=R0&r |
|BCFA,d b|9C|----|3|Branch on Cond. False Absolute|If d#c, PC=b|
|BCFR,d l|98|----|3|Branch on Cond. False Relative|If d#c, PC=l|
|BCTA,d b|1C|----|3|Branch on Cond. True Absolute |If d=c, PC=b|
|BCTR,d l|18|----|3|Branch on Cond. True Relative |If d=c, PC=l|
|BDRA,r b|FC|----|3|Branch on Dec. Reg. Absolute |r=r-1,if r#0|
|BDRR,r l|F8|----|3|Branch on Dec. Reg. Relative |r=r-1,if r#0|
|BIRA,r b|DC|----|3|Branch on Inc. Reg. Absolute |r=r+1,if r#0|
|BIRR,r l|D8|----|3|Branch on Inc. Reg. Relative |r=r+1,if r#0|
|BRNA,r b|5C|----|3|Branch on Reg. Non-zero Abs. |If r#0, PC=b|
|BRNR,r l|58|----|3|Branch on Reg. Non-zero Rel. |If r#0, PC=l|
|BSFA,d b|BC|----|3|Branch to Sub. on False Abs. |If d#c,calla|
|BSFR,d l|B8|----|3|Branch to Sub. on False Rel. |If d#c,callr|
|BSNA,r b|7C|----|3|Branch to Sub. on Non-zero Abs|If d#c,calla|
|BSNR,r l|78|----|3|Branch to Sub. on Non-zero Rel|If d#c,callr|
|BSTA,d b|3C|----|3|Branch to Sub. on True Abs. |If d=c,calla|
|BSTR,d l|38|----|3|Branch to Sub. on True Rel. |If d=c,callr|
|BSXA b|BF|----|3|Branch to Sub. Extended Addr. |calla |
|BXA b|9F|----|3|Branch to Extended Address |PC=b |
|COMA,r a|EC|*---|4|Compare Absolute |r-a |
|COMI,r i|E4|*---|2|Compare Immediate |r-i |
|COMR,r l|E8|*---|3|Compare Relative |r-l |
|COMZ,r |E0|*---|2|Compare with register Zero |R0-r |
|CPSL i|75|----|3|Clear Program Status Lower |If i=1,PSL=0|
|CPSU i|74|----|3|Clear Program Status Upper |PSU=PSU&(~i)|
|DAR,r |94|----|3|Decimal Adjust Register |r=BCD format|
|EORA,r a|2C|*---|4|Logical Exclusive OR Absolute |r=rxa |
|EORI,r i|24|*---|2|Logical Exclusive OR Immediate|r=rxi |
|EORR,r l|28|*---|3|Logical Exclusive OR Relative |r=rxl |
|EORZ,r |20|*---|2|Logical Exclusive OR reg Zero |R0=R0xr |
|HALT |40|----|2|Halt |Wait state |
|IORA,r a|6C|*---|4|Logical Inclusive OR Absolute |r=rva |
|IORI,r i|64|*---|2|Logical Inclusive OR Immediate|r=rvi |
|IORR,r l|68|*---|3|Logical Inclusive OR Relative |r=rvl |
|IORZ,r |60|*---|2|Logical Inclusive OR reg Zero |R0=R0vr |
|LODA,r a|0C|*---|4|Load Absolute |r=a |
|LODI,r i|04|*---|2|Load Immediate |r=i |
|LODR,r l|08|*---|3|Load Relative |r=l |
|LODZ,r |00|*---|2|Load register Zero |R0=r |
|LPSL |93|----|2|Load Program Status Lower |PSL=R0 |
|LPSU |92|----|2|Load Program Status Upper |PSU=R0 |
|NOP |C0|----|2|No Operation | |
|PPSL i|77|----|3|Preset Program Status Lower |If i=1,PSL=1|
|PPSU i|76|----|3|Preset Program Status Upper |If i=1,PSU=1|
|REDC,r |30|*---|2|Read Control |r=statusNE |
|REDD,r |70|*---|2|Read Data |r=dataNE |
|REDE,r p|54|*---|3|Read Extended |r=p |
|RETC,d |14|----|3|Return on Condition |If d=c,ret |
|RETE,d |34|----|3|Return cond, Enable interrupts|ret,II=0 |
|RRL,r |D0|----|2|Rotate Register Left |r=->{rr} |
|RRR,r |50|----|2|Rotate Register Right |r={rr}<- |
|SPSL |13|----|2|Store Program Status Lower |R0=PSL |
|SPSU |12|----|2|Store Program Status Upper |R0=PSU |
|STRA,r a|CC|----|4|Store Absolute |a=r |
|STRR,r l|C8|----|3|Store Relative |l=r |
|STRZ,r |C0|----|2|Store register Zero |r=R0 |
|SUBA,r a|AC|****|4|Subtract Absolute |r=r-a |
|SUBI,r i|A4|****|2|Subtract Immediate |r=r-i |
|SUBR,r l|A8|****|3|Subtract Relative |r=r-l |
|SUBZ,r |A0|****|2|Subtract from register Zero |R0=R0-r |
|TMI,r i|F4|*---|3|Test under Mask Immediate |r&i |
|TPSL,r i|B5|*---|3|Test Program Status Lower |i-PSL |
|TPSU,r i|B4|*---|3|Test Program Status Upper |i-PSU |
|WRTC,r |B0|----|2|Write Control |statusNE=r |
|WRTD,r |F0|----|2|Write Data |dataNE=r |
|WRTE,r p|D4|----|3|Write Extended |p=r |
|ZBRR l|9B|----|3|Zero page Branch |PC=l |
|ZBSR l|BB|----|3|Zero page Branch to Subroutine|callr |
| |XX| |X|8-bit opcode, machine cycles |Hexadecimal |
----------------------------------------------------------------
----------------------------------------------------------------
|Mnemonic |cIOC|Description |
|-----------+----+---------------------------------------------|
| |- |Unaffected |
| |* |Affected |
| |0 |Reset |
| |1 |Set |
| |? |Unknown |
|-----------+----+---------------------------------------------|
| S | |Sense (PSU bit 7) |
| F | |Flag (PSU bit 6) |
| II | |Interrupt Inhibit (PSU bit 5) |
| SP2 | |Stack Pointer two (PSU bit 2) |
| SP1 | |Stack Pointer one (PSU bit 1) |
| SP0 | |Stack Pointer zero (PSU bit 0) |
|-----------+----+---------------------------------------------|
| CC1 |c |Condition Code one (PSL bit 7) |
| CC0 |c |Condition Code zero (PSL bit 6) |
| IDC | I |Inter-Digit Carry status (PSL bit 5) |
| RS | |Register bank Select (R1-R3, PSL bit 4) |
| WC | |With/without Carry (PSL bit 3) |
| OVF | O |Overflow status (PSL bit 2) |
| COM | |Logical/arithmetic Compare (PSL bit 1) |
| C | C|Carry/borrow status (PSL bit 0) |
|----------------+---------------------------------------------|
| a |16-bit extended address |
| b |16-bit absolute address |
| c |2-bit condition codes CC1 and CC0 |
| calla |[SP]+=PC+3,PC=b |
| callr |[SP]+=PC+2,PC=l |
| d |2-bit immediate data unit |
| dataNE |Non-extended data port |
| i |8-bit immediate data unit |
| l |8-bit relative address |
| p |8-bit I/O port number |
| r |Register Rn (n=0-3) |
| ret |If r#0, PC=[SP]- |
| statusNE |Non-extended status port |
|----------------+---------------------------------------------|
| PC |Program Counter |
| PSL |Program Status Lower (8-bit) |
| PSU |Program Status Upper (8-bit) |
| R0 |Register zero - accumulator |
| Rn |Register (n=0-3) |
| SP |Stack pointer |
|----------------+---------------------------------------------|
| + |Arithmetic addition |
| - |Arithmetic subtraction |
| * |Arithmetic multiplication |
| / |Arithmetic division |
| & |Logical AND |
| ~ |Logical NOT |
| v |Logical inclusive OR |
| x |Logical exclusive OR |
| = |Equal or assignment |
| # |Not equal |
| <- |Rotate left |
| -> |Rotate right |
| [ ] |Indirect addressing |
| [ ]+ |Indirect addressing, auto-increment |
| -[ ] |Auto-decrement, indirect addressing |
| { } |Combination of operands |
| {rr} |If WC=1 then {C,r} else {r} |
| --> |Input pin |
| <-- |Output pin |
| <--> |Input/output pin |
|--------------------------------------------------------------|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
----------------------------------------------------------------
programming/CARDS/32016
+240
View File
@@ -0,0 +1,240 @@
----------------------------------------------------------------
| |
| |
| National Semiconductor |
| |
| 33333 22222 1 666 000 |
| 3 3 2 2 11 6 0 0 |
| 3 2 1 6 0 0 0 |
| 33333 222 1 666666 0 0 0 |
| 3 2 1 6 6 0 0 0 |
| 3 3 2 1 6 6 0 0 |
| 33333 2222222 111 66666 000 |
| |
| NS32016 MICROPROCESSOR Instruction Set Summary |
| |
| _________ _________ |
| _| \__/ |_ |
| <-- A22 |_|1 48|_| Vcc |
| _| |_ |
| <-- A21 |_|2 47|_| A23 --> |
| _| |_ ___ |
| <-- A20 |_|3 46|_| INT <-- |
| _| |_ ___ |
| <-- A19 |_|4 45|_| NMI <-- |
| _| |_ ___ |
| <-- A18 |_|5 44|_| ILO --> |
| _| |_ |
| <-- A17 |_|6 43|_| ST0 --> |
| _| |_ |
| <-- A16 |_|7 42|_| ST1 --> |
| _| |_ |
| <--> AD15 |_|8 41|_| ST2 --> |
| _| |_ |
| <--> AD14 |_|9 40|_| ST3 --> |
| _| |_ ___ |
| <--> AD13 |_|10 39|_| PFS --> |
| _| |_ ____ |
| <--> AD12 |_|11 38|_| DDIN --> |
| _| |_ ___ |
| <--> AD11 |_|12 NS32016 37|_| ADS --> |
| _| |_ _ |
| <--> AD10 |_|13 36|_| U/S --> |
| _| |_ __ ___ |
| <--> AD9 |_|14 35|_| AT/SPC <--> |
| _| |_ ___ --- |
| <--> AD8 |_|15 34|_| RST/ABT <-- |
| _| |_ __ ___ |
| <--> AD7 |_|16 33|_| DS/FLT <--> |
| _| |_ ___ |
| <--> AD6 |_|17 32|_| HBE --> |
| _| |_ ____ |
| <--> AD5 |_|18 31|_| HLDA --> |
| _| |_ ____ |
| <--> AD4 |_|19 30|_| HOLD <-- |
| _| |_ |
| <--> AD3 |_|20 29|_| BBG |
| _| |_ |
| <--> AD2 |_|21 28|_| RDY <-- |
| _| |_ |
| <--> AD1 |_|22 27|_| PHI2 <-- |
| _| |_ |
| <--> AD0 |_|23 26|_| PHI1 <-- |
| _| |_ |
| GNDL |_|24 25|_| GNDB |
| |______________________| |
| |
| |
|Written by Jonathan Bowen |
| Programming Research Group |
| Oxford University Computing Laboratory |
| 8-11 Keble Road |
| Oxford OX1 3QD |
| England |
| |
| Tel +44-865-273840 |
| |
|Created October 1982 |
|Updated July 1985 |
|Issue 1.1 Copyright (C) J.P.Bowen 1985|
----------------------------------------------------------------
----------------------------------------------------------------
|Mnemonic |Description |
|---------------+----------------------------------------------|
|ABSi g,g |Take Absolute value |
|ABSf g,g |Take Absolute floating point value |
|ACBi s,g,d |Add 4-bit Constant and Branch if non-zero |
|ADDi g,g |Add |
|ADDf g,g |Add floating point values |
|ADDCi g,g |Add with Carry |
|ADDPi g,g |Add Packed (BCD) |
|ADDQi s,g |Add Quick a 4-bit constant |
|ADDR g,g |Move effective Address |
|ADJSPi g |Adjust Stack Pointer |
|ANDi g,g |Logical AND |
|ASHi g,g |Arithmetic Shift, left or right |
|Bcc d |Branch on condition (cc) |
|BICi g,g |Bit Clear |
|BICPSRi g |Bit Clear Processor Status Register (i=W/D #)|
|BISPSRi g |Bit Set Processor Status Register (i=W/D #)|
|BPT |Breakpoint Trap |
|BR d |Branch (PC relative) |
|BSR d |Branch to Subroutine |
|CASEi g |Case (multiway branch) |
|CATSTn g |Custom Address Test (n=0-1) (#)|
|CBITi g,g |Test and Clear Bit |
|CBITIi g,g |Test and Clear Bit Interlocked |
|CCALnc g,g |Custom Calculate (n=0-3) |
|CCMPc g,g |Custom Compare |
|CCVnci g,g |Custom Convert custom value to integer (n=0-2)|
|CCV3ic g,g |Custom Convert integer to custom value |
|CCV4DQ g,g |Custom Convert double to quad value |
|CCV5QD g,g |Custom Convert quad to double value |
|CHECKi r,g,g |Check index bounds |
|CMPi g,g |Compare |
|CMPf g,g |Compare floating point values |
|CMPMi g,g,d |Compare Multiple: displacement bytes |
|CMPQi s,g |Compare Quick with a 4-bit constant |
|CMPSi ol |Compare Strings |
|CMPSTi ol |Compare Strings, Translating bytes |
|COMi g,g |Complement all bits |
|CMOVnc g,g |Custom Move (n=0-2) |
|CVTP r,g,g |Convert to bit field Pointer |
|CXP d |Call External Procedure |
|CXPD g |Call External Procedure using Descriptor |
|DEIi g,g |Divide Extended Integer |
|DIA |Diagnose (hardware breakpoint) |
|DIVi g,g |Divide, rounding down |
|DIVf g,g |Divide floating point values |
|ENTER (rl),d |Enter procedure (save registers) |
|EXIT (rl) |Exit procedure (restore registers) |
|EXTi r,g,g,d|Extract bit field (array orientated) |
|EXTSi g,g,m,m|Extract Short bit field |
|FLAG |Flag trap |
|FLOORfi g,g |Convert f.p. to largest integer <= value |
|FFSi g,g |Find First Set bit |
|IBITi g,g |Test and Invert Bit |
|INDEXi r,g,g |Recursive Indexing step for N-D arrays |
|INSi r,g,g,d|Insert bit field (array orientated) |
|INSSi g,g,m,m|Insert Short bit field |
|JSR g |Jump to Subroutine |
|JUMP g |Jump |
|LCR cr,g |Load Custom Register (#)|
|LCSR g |Load Custom Status Register |
|LFSR g |Load Floating point Status Register |
|LMR mr,g |Load Memory management Register (#)|
|LPRi ar,g |Load dedicated Register (a=PSR/INTBASE #)|
|LSHi g,g |Logical Shift, left or right |
|MEIi g,g |Multiply to Extended Integer |
|MODi g,g |Modulus (remainder from QUO) |
|MOVi g,g |Move a value |
|MOVif g,g |Move an integer to a floating point value |
|MOVf g,g |Move a floating point value |
|MOVFL g,g |Move and lengthen a floating point value |
|MOVLF g,g |Move and shorten a Long floating point value |
|MOVMi g,g,d |Move Multiple: displacement bytes |
|MOVQi s,g |Move Quick and extend a 4-bit constant |
|MOVSi ol |Move String |
|MOVSTi ol |Move String, Translating bytes |
|MOVSUi g,g |Move value from Supervisor to User space (#)|
----------------------------------------------------------------
----------------------------------------------------------------
|Mnemonic |Description |
|---------------+----------------------------------------------|
|MOVUSi g,g |Move value from User to Supervisor space (#)|
|MOVXiD g,g |Move with sign Extension to Double word |
|MOVXBW g,g |Move with sign Extension Byte to Word |
|MOVZiD g,g |Move with Zero extension to Double word |
|MOVZBW g,g |Move with Zero extension Byte to Word |
|MULi g,g |Multiply |
|MULf g,g |Multiply floating point values |
|NEGi g,g |Negate (2's complement) |
|NEGf g,g |Negate floating point value |
|NOP |No Operation |
|NOTi g,g |Logical NOT (LSB only) |
|ORi g,g |Logical OR |
|QUOi g,g |Quotient (divide, rounding towards zero) |
|RDVAL g |Validate address for Reading (#)|
|REMi g,g |Remainder from QUO |
|RESTORE (rl) |Restore general purpose registers |
|RET d |Return from subroutine |
|RETI |Return from Interrupt (#)|
|RETT d |Return from Trap (#)|
|ROTi g,g |Rotate, left or right |
|ROUNDfi g,g |Round a floating point value to an integer |
|RXP d |Return from External Procedure call |
|Scci g |Save condition code (cc) as a Boolean value |
|SAVE (rl) |Save general purpose registers |
|SBITi g,g |Test and Set Bit |
|SBITIi g,g |Test and Set Bit Interlocked |
|SCR cr,g |Store Custom Register (#)|
|SCSR g |Store Custom Status Register |
|SETCFG (o) |Set Configuration register (#)|
|SFSR g |Store Floating point Status Register |
|SKPSi ol |Skip over String |
|SKPSTi ol |Skip over String, Translating bytes |
|SMR mr,g |Store Memory management Register (#)|
|SPRi ar,g |Store dedicated Register (a=PSR/INTBASE #)|
|SUBi g,g |Subtract |
|SUBf g,g |Subtract floating point values |
|SUBCi g,g |Subtract with Carry (borrow) |
|SUBPi g,g |Subtract Packed (BCD) |
|SVC |Supervisor Call |
|TBITi g,g |Test Bit |
|TRUNCfi g,g |Truncate toward zero floating point to integer|
|WAIT |Wait for interrupt |
|WRVAL g |Validate address for Writing (#)|
|XORi g,g |Logical Exclusive OR |
|---------------+----------------------------------------------|
| CFG |Configuration register (4-bit) |
| EXTERNAL |External link table entry |
| FP |Frame Pointer register (32-bit, top 8 zero) |
| INTBASE |Interrupt Base register (32-bit, top 8 zero) |
| MOD |Module register (16-bit) |
| PC |Program Counter (32-bit, top 8 zero) |
| PSR |Processor Status Register (16-bit) |
| Rn or Fn |General purpose Registers (32-bit, n=0-7) |
| SB |Static Base register (32-bit, top 8 zero) |
| SP0 (SP) |Supervisor Stack Pointer (32-bit, top 8 zero) |
| SP1 (SP) |User Stack Pointer (32-bit, top 8 zero) |
| TOS |Top Of current Stack |
| US |User Status (8-bit, bottom byte of PSR) |
|---------------+----------------------------------------------|
| ar |Dedicated reg. (SP/SB/FP/MOD/INTBASE/PSR/US) |
| c |Custom length (D/Q=double/quad word) |
| cc |(EQ/NE/CS/CC/HI/LS/GT/LE/FS/FC/LO/HS/LT/GE) |
| cr |Custom slave processor register |
| d |Displacement constant (8/16/32-bit) |
| f |Floating point length (F/L=standard/long) |
| g |General operand |
| i |Integer length (B/W/D=byte/word/double word) |
| m |Implied immediate constant (8-bit) |
| mr |Memory management status/control register |
| n |Digit |
| o |Options (B/U/W=backward/until/while) |
| ol |Option list (C/M/F/I=custom/MMU/FPU/interrupt)|
| r |General purpose register (R0-R7/F0-F7) |
| rl |General purpose register list |
| s |Short signed 4-bit value |
| # |Privileged instruction |
----------------------------------------------------------------
programming/CARDS/32032
+240
View File
@@ -0,0 +1,240 @@
----------------------------------------------------------------
| |
| |
| National Semiconductor |
| |
| 33333 22222 000 33333 22222 |
| 3 3 2 2 0 0 3 3 2 2 |
| 3 2 0 0 0 3 2 |
| 33333 222 0 0 0 33333 222 |
| 3 2 0 0 0 3 2 |
| 3 3 2 0 0 3 3 2 |
| 33333 2222222 000 33333 2222222 |
| |
| NS32032 MICROPROCESSOR Instruction Set Summary |
| |
| |
| |
| |
| |
| |
| |
| G |
| ~ ~ ~ N A |
| S S S I N I D D V D D D D D D D D |
| T T T L M N B 3 c 3 2 2 2 2 2 2 2 |
| 2 1 0 O I T 2 1 c 0 9 8 7 6 5 4 3 |
| |
| ^ ^ ^ ^ | | | ^ | ^ ^ ^ ^ ^ ^ ^ ^ |
| | | | | | | | | | | | | | | | | | |
| | | | | v v | v | v v v v v v v v |
| ------------------------------------- |
| |10 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 26| |
| Reserved ---|9 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 27|<-> AD22 |
| ST3 <--|8 28|<-> AD21 |
| ~PFS <--|7 29|<-> AD20 |
| ~DDIN <--|6 30|<-> AD19 |
| Reserved ---|5 31|<-> AD18 |
| Reserved ---|4 32|<-> AD17 |
| PHI1 -->|3 33|<-> AD16 |
| PHI2 -->|2 34|<-> AD15 |
| ~ADS <--|1 NS32032 35|<-> AD14 |
| U/~S <--|68 36|<-> AD13 |
| Reserved ---|67 37|<-> AD12 |
| Reserved ---|66 38|<-> AD11 |
| ~AT/~SPC <->|65 39|<-> AD10 |
| ~DS/~FLT <->|64 40|<-> AD9 |
|~RST/~ABT -->|63 41|<-> AD8 |
| Reserved ---|62 42|<-> AD7 |
| Reserved ---|61 5 5 5 5 5 5 5 5 5 5 4 4 4 4 4 43|<-> AD6 |
| (connect to |60 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 44| |
| Vcc via 4K7 ------------------------------------- |
| resistor) | | | | | | ^ ^ | | | ^ ^ ^ ^ ^ ^ |
| | | | | | | | | | | | | | | | | | |
| | v v v v v | | | | | v v v v v v |
| |
| R ~ ~ ~ ~ ~ ~ R G G B A A A A A A |
| e B B B B H H D N N B D D D D D D |
| s E E E E L O Y D D G 0 1 2 3 4 5 |
| e 0 1 2 3 D L B L |
| r A D 1 |
| v |
| e |
| d |
| |
| |
| |
| |
|Written by Jonathan Bowen |
| Programming Research Group |
| Oxford University Computing Laboratory |
| 8-11 Keble Road |
| Oxford OX1 3QD |
| England |
| |
| Tel +44-865-273840 |
| |
|Created April 1985 |
|Updated May 1985 |
|Issue 1.0 Copyright (C) J.P.Bowen 1985|
----------------------------------------------------------------
----------------------------------------------------------------
|Mnemonic |Description |
|---------------+----------------------------------------------|
|ABSi g,g |Take Absolute value |
|ABSf g,g |Take Absolute floating point value |
|ACBi s,g,d |Add 4-bit Constant and Branch if non-zero |
|ADDi g,g |Add |
|ADDf g,g |Add floating point values |
|ADDCi g,g |Add with Carry |
|ADDPi g,g |Add Packed (BCD) |
|ADDQi s,g |Add Quick a 4-bit constant |
|ADDR g,g |Move effective Address |
|ADJSPi g |Adjust Stack Pointer |
|ANDi g,g |Logical AND |
|ASHi g,g |Arithmetic Shift, left or right |
|Bcc d |Branch on condition (cc) |
|BICi g,g |Bit Clear |
|BICPSRi g |Bit Clear Processor Status Register (i=W/D #)|
|BISPSRi g |Bit Set Processor Status Register (i=W/D #)|
|BPT |Breakpoint Trap |
|BR d |Branch (PC relative) |
|BSR d |Branch to Subroutine |
|CASEi g |Case (multiway branch) |
|CATSTn g |Custom Address Test (n=0-1) (#)|
|CBITi g,g |Test and Clear Bit |
|CBITIi g,g |Test and Clear Bit Interlocked |
|CCALnc g,g |Custom Calculate (n=0-3) |
|CCMPc g,g |Custom Compare |
|CCVnci g,g |Custom Convert custom value to integer (n=0-2)|
|CCV3ic g,g |Custom Convert integer to custom value |
|CCV4DQ g,g |Custom Convert double to quad value |
|CCV5QD g,g |Custom Convert quad to double value |
|CHECKi r,g,g |Check index bounds |
|CMPi g,g |Compare |
|CMPf g,g |Compare floating point values |
|CMPMi g,g,d |Compare Multiple: displacement bytes |
|CMPQi s,g |Compare Quick with a 4-bit constant |
|CMPSi ol |Compare Strings |
|CMPSTi ol |Compare Strings, Translating bytes |
|COMi g,g |Complement all bits |
|CMOVnc g,g |Custom Move (n=0-2) |
|CVTP r,g,g |Convert to bit field Pointer |
|CXP d |Call External Procedure |
|CXPD g |Call External Procedure using Descriptor |
|DEIi g,g |Divide Extended Integer |
|DIA |Diagnose (hardware breakpoint) |
|DIVi g,g |Divide, rounding down |
|DIVf g,g |Divide floating point values |
|ENTER (rl),d |Enter procedure (save registers) |
|EXIT (rl) |Exit procedure (restore registers) |
|EXTi r,g,g,d|Extract bit field (array orientated) |
|EXTSi g,g,m,m|Extract Short bit field |
|FLAG |Flag trap |
|FLOORfi g,g |Convert f.p. to largest integer <= value |
|FFSi g,g |Find First Set bit |
|IBITi g,g |Test and Invert Bit |
|INDEXi r,g,g |Recursive Indexing step for N-D arrays |
|INSi r,g,g,d|Insert bit field (array orientated) |
|INSSi g,g,m,m|Insert Short bit field |
|JSR g |Jump to Subroutine |
|JUMP g |Jump |
|LCR cr,g |Load Custom Register (#)|
|LCSR g |Load Custom Status Register |
|LFSR g |Load Floating point Status Register |
|LMR mr,g |Load Memory management Register (#)|
|LPRi ar,g |Load dedicated Register (a=PSR/INTBASE #)|
|LSHi g,g |Logical Shift, left or right |
|MEIi g,g |Multiply to Extended Integer |
|MODi g,g |Modulus (remainder from QUO) |
|MOVi g,g |Move a value |
|MOVif g,g |Move an integer to a floating point value |
|MOVf g,g |Move a floating point value |
|MOVFL g,g |Move and lengthen a floating point value |
|MOVLF g,g |Move and shorten a Long floating point value |
|MOVMi g,g,d |Move Multiple: displacement bytes |
|MOVQi s,g |Move Quick and extend a 4-bit constant |
|MOVSi ol |Move String |
|MOVSTi ol |Move String, Translating bytes |
|MOVSUi g,g |Move value from Supervisor to User space (#)|
----------------------------------------------------------------
----------------------------------------------------------------
|Mnemonic |Description |
|---------------+----------------------------------------------|
|MOVUSi g,g |Move value from User to Supervisor space (#)|
|MOVXiD g,g |Move with sign Extension to Double word |
|MOVXBW g,g |Move with sign Extension Byte to Word |
|MOVZiD g,g |Move with Zero extension to Double word |
|MOVZBW g,g |Move with Zero extension Byte to Word |
|MULi g,g |Multiply |
|MULf g,g |Multiply floating point values |
|NEGi g,g |Negate (2's complement) |
|NEGf g,g |Negate floating point value |
|NOP |No Operation |
|NOTi g,g |Logical NOT (LSB only) |
|ORi g,g |Logical OR |
|QUOi g,g |Quotient (divide, rounding towards zero) |
|RDVAL g |Validate address for Reading (#)|
|REMi g,g |Remainder from QUO |
|RESTORE (rl) |Restore general purpose registers |
|RET d |Return from subroutine |
|RETI |Return from Interrupt (#)|
|RETT d |Return from Trap (#)|
|ROTi g,g |Rotate, left or right |
|ROUNDfi g,g |Round a floating point value to an integer |
|RXP d |Return from External Procedure call |
|Scci g |Save condition code (cc) as a Boolean value |
|SAVE (rl) |Save general purpose registers |
|SBITi g,g |Test and Set Bit |
|SBITIi g,g |Test and Set Bit Interlocked |
|SCR cr,g |Store Custom Register (#)|
|SCSR g |Store Custom Status Register |
|SETCFG (o) |Set Configuration register (#)|
|SFSR g |Store Floating point Status Register |
|SKPSi ol |Skip over String |
|SKPSTi ol |Skip over String, Translating bytes |
|SMR mr,g |Store Memory management Register (#)|
|SPRi ar,g |Store dedicated Register (a=PSR/INTBASE #)|
|SUBi g,g |Subtract |
|SUBf g,g |Subtract floating point values |
|SUBCi g,g |Subtract with Carry (borrow) |
|SUBPi g,g |Subtract Packed (BCD) |
|SVC |Supervisor Call |
|TBITi g,g |Test Bit |
|TRUNCfi g,g |Truncate toward zero floating point to integer|
|WAIT |Wait for interrupt |
|WRVAL g |Validate address for Writing (#)|
|XORi g,g |Logical Exclusive OR |
|---------------+----------------------------------------------|
| CFG |Configuration register (4-bit) |
| EXTERNAL |External link table entry |
| FP |Frame Pointer register (32-bit, top 8 zero) |
| INTBASE |Interrupt Base register (32-bit, top 8 zero) |
| MOD |Module register (16-bit) |
| PC |Program Counter (32-bit, top 8 zero) |
| PSR |Processor Status Register (16-bit) |
| Rn or Fn |General purpose Registers (32-bit, n=0-7) |
| SB |Static Base register (32-bit, top 8 zero) |
| SP0 (SP) |Supervisor Stack Pointer (32-bit, top 8 zero) |
| SP1 (SP) |User Stack Pointer (32-bit, top 8 zero) |
| TOS |Top Of current Stack |
| US |User Status (8-bit, bottom byte of PSR) |
|---------------+----------------------------------------------|
| ar |Dedicated reg. (SP/SB/FP/MOD/INTBASE/PSR/US) |
| c |Custom length (D/Q=double/quad word) |
| cc |(EQ/NE/CS/CC/HI/LS/GT/LE/FS/FC/LO/HS/LT/GE) |
| cr |Custom slave processor register |
| d |Displacement constant (8/16/32-bit) |
| f |Floating point length (F/L=standard/long) |
| g |General operand |
| i |Integer length (B/W/D=byte/word/double word) |
| m |Implied immediate constant (8-bit) |
| mr |Memory management status/control register |
| n |Digit |
| o |Options (B/U/W=backward/until/while) |
| ol |Option list (C/M/F/I=custom/MMU/FPU/interrupt)|
| r |General purpose register (R0-R7/F0-F7) |
| rl |General purpose register list |
| s |Short signed 4-bit value |
| # |Privileged instruction |
----------------------------------------------------------------
programming/CARDS/6502
+240
View File
@@ -0,0 +1,240 @@
----------------------------------------------------------------
| |
| |
| Rockwell |
| |
| 666 5555555 000 22222 |
| 6 5 0 0 2 2 |
| 6 5 0 0 0 2 |
| 666666 555555 0 0 0 222 |
| 6 6 5 0 0 0 2 |
| 6 6 5 0 0 2 |
| 66666 555555 000 2222222 |
| |
| 6502 MICROPROCESSOR Instruction Set Summary |
| |
| |
| |
| |
| |
| _________ _________ |
| _| \__/ |_ ___ |
| Vss |_|1 40|_| RES <-- |
| _| |_ |
| --> RDY |_|2 39|_| CLK2 --> |
| _| |_ |
| <-- CLK1 |_|3 38|_| NC |
| ___ _| |_ |
| --> IRQ |_|4 37|_| CLK0 <-- |
| _| |_ |
| NC |_|5 36|_| NC |
| ___ _| |_ |
| --> NMI |_|6 35|_| NC |
| _| |_ _ |
| --> SYNC |_|7 34|_| R/W --> |
| _| |_ |
| Vcc |_|8 33|_| DB7 <--> |
| _| |_ |
| <-- A0 |_|9 32|_| DB6 <--> |
| _| |_ |
| <-- A1 |_|10 6502 31|_| DB5 <--> |
| _| |_ |
| <-- A2 |_|11 30|_| DB4 <--> |
| _| |_ |
| <-- A3 |_|12 29|_| DB3 <--> |
| _| |_ |
| <-- A4 |_|13 28|_| DB2 <--> |
| _| |_ |
| <-- A5 |_|14 27|_| DB1 <--> |
| _| |_ |
| <-- A6 |_|15 26|_| DB0 <--> |
| _| |_ |
| <-- A7 |_|16 25|_| A15 --> |
| _| |_ |
| <-- A8 |_|17 24|_| A14 --> |
| _| |_ |
| <-- A9 |_|18 23|_| A13 --> |
| _| |_ |
| <-- A10 |_|19 22|_| A12 --> |
| _| |_ |
| <-- A11 |_|20 21|_| Vss |
| |______________________| |
| |
| |
| |
| |
| |
| |
|Written by Jonathan Bowen |
| Programming Research Group |
| Oxford University Computing Laboratory |
| 8-11 Keble Road |
| Oxford OX1 3QD |
| England |
| |
| Tel +44-865-273840 |
| |
|Created September 1981 |
|Updated April 1985 |
|Issue 1.5 Copyright (C) J.P.Bowen 1985|
----------------------------------------------------------------
----------------------------------------------------------------
|Mnem.|Op|NVBDIZC|A#ZBIRX@|~|Description |Notes |
|-----+--+-------+--------+-+----------------------+-----------|
|ADC s|6D|**---**| XxX X |4|Add with Carry |A=A+s+C %|
|AND s|2D|*----*-| XxX X |4|Logical AND |A=A&s %|
|ASL d|0E|*----**| xx |6|Arithmetic Shift Left |d={C,d,0}<-|
|ASLA |0A|*----**|X |2|Arithmetic Shift Left |A={C,d,0}<-|
|BCC a|90|-------| X |2|Branch if Carry Clear |If C=0(4~)%|
|BCS a|B0|-------| X |2|Branch if Carry Set |If C=1(4~)%|
|BEQ a|F0|-------| X |2|Branch if Equal |If Z=1(4~)%|
|BIT s|2C|**---*-| ** |4|Bit Test |A&s |
|BMI a|30|-------| X |2|Branch if Minus |If N=1(4~)%|
|BNE a|D0|-------| X |2|Branch if Not Equal |If Z=0(4~)%|
|BPL a|10|-------| X |2|Branch if Plus |If N=0(4~)%|
|BRK |00|--+-1--| X |7|Break (-[S]={PC+2,P})|PC=[FFFEH] |
|BVC a|50|-------| X |2|Branch if Overflow Clr|If V=0(4~)%|
|BVS a|70|-------| X |2|Branch if Overflow Set|If V=1(4~)%|
|CLC |18|------0| X |2|Clear Carry flag |C=0 |
|CLD |D8|---0---| X |2|Clear Decimal mode |D=0 |
|CLI |58|----0--| X |2|Clear Int. disable |I=0 |
|CLV |B8|-0-----| X |2|Clear Overflow flag |V=0 |
|CMP s|CD|*----**| XxX X |4|Compare |A-s |
|CPX s|EC|*----**| X** |4|Compare index register|X-s |
|CPY s|CC|*----**| X** |4|Compare index register|Y-s |
|DEC d|CE|*----*-| xx |6|Decrement |d=d-1 |
|DEX |CA|*----*-| X |2|Decrement index reg. |X=X-1 |
|DEY |88|*----*-| X |2|Decrement index reg. |Y=Y-1 |
|EOR s|4D|*----*-| XxX X |4|Logical Exclusive OR |A=Axs %|
|INC d|EE|*----*-| xx |6|Increment |d=d+1 |
|INX |E8|*----*-| X |2|Increment index reg. |X=X+1 |
|INY |C8|*----*-| X |2|Increment index reg. |Y=Y+1 |
|JMP s|4C|-------| * X|3|Jump | !|
|JSR s|20|-------| * |6|Jump to Subroutine |-[S]=PC+2,!|
|LDA s|AD|*----*-| XxX X |4|Load Accumulator |A=s %|
|LDX s|AE|*----*-| Xyy |4|Load index register |X=s %|
|LDY s|AC|*----*-| Xxx |4|Load index register |Y=s %|
|LSR d|4E|0----**| xx |6|Logical Shift Right |d=->{0,d,C}|
|LSRA |4A|0----**|X |2|Logical Shift Right |A=->{0,A,C}|
|NOP |EA|-------| X |2|No Operation | |
|ORA s|0D|*----*-| XxX X |4|Logical Inclusive OR |A=Avs |
|PHA |48|-------| X |3|Push Accumulator |-[S]=A |
|PHP |08|-------| X |3|Push status register |-[S]=P |
|PLA |68|-------| X |4|Pull Accumulator |A=[S]+ |
|PLP |28|*******| X |4|Pull Status Register |P=[S]+ |
|ROL d|2E|*----**| xx |6|Rotate Left |d={C,d}<- |
|ROLA |2A|*----**|X |2|Rotate Left Acc. |A={C,A}<- |
|ROR d|6E|*----**| xx |6|Rotate Right |d=->{C,d} |
|RORA |6A|*----**|X |2|Rotate Right Acc. |A=->{C,A} |
|RTI |40|*******| X |6|Return from Interrupt |{PC,P}=[S]+|
|RTS |60|-------| X |6|Return from Subroutine|PC={[S]+}+1|
|SBC s|ED|*----**| XxX X |4|Subtract with Carry |A=A-s-C %|
|SEC |38|------1| X |2|Set Carry flag |C=1 |
|SED |F8|---1---| X |2|Set Decimal mode |D=1 |
|SEI |78|----1--| X |2|Set Interrupt disable |I=1 |
|STA d|8D|-------| xX X |4|Store Accumulator |d=A |
|STX d|8E|-------| y* |4|Store index register |d=X |
|STY d|8C|-------| x* |4|Store index register |d=Y |
|TAX |AA|*----*-| X |2|Transfer Accumulator |X=A |
|TAY |A8|*----*-| X |2|Transfer Accumulator |Y=A |
|TSX |BA|*----*-| X |2|Transfer Stack pointer|X=S |
|TXA |8A|*----*-| X |2|Transfer index reg. |A=X |
|TXS |9A|-------| X |2|Transfer index reg. |S=X |
|TYA |98|*----*-| X |2|Transfer index reg. |A=Y |
|-----+--+-------+--------+-+----------------------------------|
| |XX| | |X|Hexadecimal opcode/no. of cycles |
|--------+-------+--------+-+----------------------------------|
| |- | | |Flag unaffected |
| |* | | |Flag affected |
| |0 | | |Flag reset |
| |1 | | |Flag set |
| |+ | | |Flag set on stack |
|--------+-------+--------+-+----------------------------------|
| N |N | | |Negative status (Bit 7) |
| V | V | | |Overflow status (Bit 6) |
| B | B | | |Break command indicator (Bit 4) |
| D | D | | |Decimal mode control (Bit 3) |
| I | I | | |Interrupt disable control (Bit 2) |
| Z | Z | | |Zero status (Bit 1) |
| C | C| | |Carry status (Bit 0) |
----------------------------------------------------------------
----------------------------------------------------------------
|Mnemonic |A#ZBIRX@|Description |Opcode| ~s |
|----------------+--------+------------------------+------+----|
| |X |All mode(s) valid | | |
| |* |Non-indexed mode valid | | |
| |x |X/non-indexed mode valid| | |
| |y |Y/non-indexed mode valid| | |
|----------------+--------+------------------------+------+----|
| | |Add XXH to opcode | +XXH | |
| | |Subtract XXH from opcode| -XXH | |
| | |Add X to no. of cycles | | +X |
| | |Subtract X from cycles | | -X |
|----------------+--------+------------------------+------+----|
| A |A |Accumulator | | |
| #n | # |Immediate | -04H | -2 |
| <n | * |Zero page | -08H | -1 |
| n | * |Zero page (DIRECT mode) | -08H | -1 |
| n,X | x |Zero page indexed (X) | +08H | +0 |
| n,Y | y |Zero Page indexed (Y) | +08H | +0 |
| >nn | * |Absolute | +00H | +0 |
| nn | * |Absolute (EXTEND mode) | +00H | +0 |
| nn,X | x |Absolute indexed (X) | +10H | +0 |
| nn,Y | y |Absolute indexed (Y) | +0CH | +0 |
| LDX nn,Y | y | ditto | +10H | +0 |
| | I |Implicit | | |
| a | R |Relative(PC=PC+1+offset)| | +2 |
| [nn,X] | x |Indexed indirect (X) | -0CH | +2 |
| [nn],Y | y |Indirect indexed (Y) | +04H | +1 |
| [nn] | @|Absolute indirect | +20H | +2 |
|-------------------------+------------------------------------|
|BYTE n(,...) |Byte(s) (8-bit) |
|BYTE 'string'(,...) |Byte text string(s) |
|DIRECT |Zero page addressing mode |
|EXTEND |Absolute addressing mode |
|RMB nn(,...) |Reserve Memory Bytes |
|WORD nn(,...) |Word(s) (16-bit) |
|-------------------------+------------------------------------|
| A |Accumulator (8-bit) |
| P |Processor status register (8-bit) |
| PC |Program Counter (16-bit) |
| S |Stack pointer (9-bit, MSB=1) |
| X |Index register X (8-bit) |
| Y |Index register Y (8-bit) |
|-------------------------+------------------------------------|
| a |Relative address (-128 to +127) |
| d |Destination |
| n |8-bit expression (0 to 255) |
| nn |16-bit expression (0 to 65535) |
| s |Source |
| string |String of ASCII characters |
|-------------------------+------------------------------------|
| + |Arithmetic addition |
| - |Arithmetic subtraction |
| * |Arithmetic multiplication |
| / |Arithmetic division |
| & |Logical AND |
| ~ |Logical NOT |
| v |Logical inclusive OR |
| x |Logical exclusive OR |
| <- |Rotate left |
| -> |Rotate right |
| [ ] |Indirect addressing |
| [ ]+ |Indirect addressing, auto-increment |
| -[ ] |Auto-decrement, indirect addressing |
| { } |Combination of operands |
| $ |Program counter content |
| % |~s = ~s+1 if crossing page boundary |
| ! |PC = effective address of source |
| --> |Input pin |
| <-- |Output pin |
| <--> |Input/output pin |
|-------------------------+------------------------------------|
|0000H to 00FFH |Page 0 (see zero page addressing) |
|0100H to 01FFH |Page 1 (stack area, 01FFH = start) |
|XX00H to XXFFH |Page n (where n=XXH) |
|FFFAH to FFFBH |Non maskable interrupt (NMI) vector |
|FFFCH to FFFDH |Reset (RES) vector |
|FFFEH to FFFFH |Interrupt Request (IRQ) vector |
|FFFEH to FFFFH |Break command vector (see BRK) |
----------------------------------------------------------------
programming/CARDS/650x
+240
View File
@@ -0,0 +1,240 @@
----------------------------------------------------------------
| |
| |
| Rockwell |
| |
| 666 5555555 000 X X |
| 6 5 0 0 X X |
| 6 5 0 0 0 X X |
| 666666 555555 0 0 0 X |
| 6 6 5 0 0 0 X X |
| 6 6 5 0 0 X X |
| 66666 555555 000 X X |
| |
| 6501/2/3/4/5 MICROPROCESSOR Instruction Set Summary |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| M M OOOOO SSSSS |
| MM MM O O S S |
| M M M M O O S |
| M M M O O SSSSS |
| M M O O S |
| M M O O S S |
| M M OOOOO SSSSS |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
|Written by Jonathan Bowen |
| Programming Research Group |
| Oxford University Computing Laboratory |
| 8-11 Keble Road |
| Oxford OX1 3QD |
| England |
| |
| Tel +44-865-273840 |
| |
|Created September 1981 |
|Updated April 1985 |
|Issue 1.3 Copyright (C) J.P.Bowen 1985|
----------------------------------------------------------------
----------------------------------------------------------------
|Mnem.|Op|NVBDIZC|A#ZBIRX@|~|Description |Notes |
|-----+--+-------+--------+-+----------------------+-----------|
|ADC s|6D|**---**| XxX X |4|Add with Carry |A=A+s+C %|
|AND s|2D|*----*-| XxX X |4|Logical AND |A=A&s %|
|ASL d|0E|*----**| xx |6|Arithmetic Shift Left |d={C,d,0}<-|
|ASLA |0A|*----**|X |2|Arithmetic Shift Left |A={C,d,0}<-|
|BCC a|90|-------| X |2|Branch if Carry Clear |If C=0(4~)%|
|BCS a|B0|-------| X |2|Branch if Carry Set |If C=1(4~)%|
|BEQ a|F0|-------| X |2|Branch if Equal |If Z=1(4~)%|
|BIT s|2C|**---*-| ** |4|Bit Test |A&s |
|BMI a|30|-------| X |2|Branch if Minus |If N=1(4~)%|
|BNE a|D0|-------| X |2|Branch if Not Equal |If Z=0(4~)%|
|BPL a|10|-------| X |2|Branch if Plus |If N=0(4~)%|
|BRK |00|--+-1--| X |7|Break (-[S]={PC+2,P})|PC=[FFFEH] |
|BVC a|50|-------| X |2|Branch if Overflow Clr|If V=0(4~)%|
|BVS a|70|-------| X |2|Branch if Overflow Set|If V=1(4~)%|
|CLC |18|------0| X |2|Clear Carry flag |C=0 |
|CLD |D8|---0---| X |2|Clear Decimal mode |D=0 |
|CLI |58|----0--| X |2|Clear Int. disable |I=0 |
|CLV |B8|-0-----| X |2|Clear Overflow flag |V=0 |
|CMP s|CD|*----**| XxX X |4|Compare |A-s |
|CPX s|EC|*----**| X** |4|Compare index register|X-s |
|CPY s|CC|*----**| X** |4|Compare index register|Y-s |
|DEC d|CE|*----*-| xx |6|Decrement |d=d-1 |
|DEX |CA|*----*-| X |2|Decrement index reg. |X=X-1 |
|DEY |88|*----*-| X |2|Decrement index reg. |Y=Y-1 |
|EOR s|4D|*----*-| XxX X |4|Logical Exclusive OR |A=Axs %|
|INC d|EE|*----*-| xx |6|Increment |d=d+1 |
|INX |E8|*----*-| X |2|Increment index reg. |X=X+1 |
|INY |C8|*----*-| X |2|Increment index reg. |Y=Y+1 |
|JMP s|4C|-------| * X|3|Jump | !|
|JSR s|20|-------| * |6|Jump to Subroutine |-[S]=PC+2,!|
|LDA s|AD|*----*-| XxX X |4|Load Accumulator |A=s %|
|LDX s|AE|*----*-| Xyy |4|Load index register |X=s %|
|LDY s|AC|*----*-| Xxx |4|Load index register |Y=s %|
|LSR d|4E|0----**| xx |6|Logical Shift Right |d=->{0,d,C}|
|LSRA |4A|0----**|X |2|Logical Shift Right |A=->{0,A,C}|
|NOP |EA|-------| X |2|No Operation | |
|ORA s|0D|*----*-| XxX X |4|Logical Inclusive OR |A=Avs |
|PHA |48|-------| X |3|Push Accumulator |-[S]=A |
|PHP |08|-------| X |3|Push status register |-[S]=P |
|PLA |68|-------| X |4|Pull Accumulator |A=[S]+ |
|PLP |28|*******| X |4|Pull Status Register |P=[S]+ |
|ROL d|2E|*----**| xx |6|Rotate Left |d={C,d}<- |
|ROLA |2A|*----**|X |2|Rotate Left Acc. |A={C,A}<- |
|ROR d|6E|*----**| xx |6|Rotate Right |d=->{C,d} |
|RORA |6A|*----**|X |2|Rotate Right Acc. |A=->{C,A} |
|RTI |40|*******| X |6|Return from Interrupt |{PC,P}=[S]+|
|RTS |60|-------| X |6|Return from Subroutine|PC={[S]+}+1|
|SBC s|ED|*----**| XxX X |4|Subtract with Carry |A=A-s-C %|
|SEC |38|------1| X |2|Set Carry flag |C=1 |
|SED |F8|---1---| X |2|Set Decimal mode |D=1 |
|SEI |78|----1--| X |2|Set Interrupt disable |I=1 |
|STA d|8D|-------| xX X |4|Store Accumulator |d=A |
|STX d|8E|-------| y* |4|Store index register |d=X |
|STY d|8C|-------| x* |4|Store index register |d=Y |
|TAX |AA|*----*-| X |2|Transfer Accumulator |X=A |
|TAY |A8|*----*-| X |2|Transfer Accumulator |Y=A |
|TSX |BA|*----*-| X |2|Transfer Stack Pointer|X=S |
|TXA |8A|*----*-| X |2|Transfer Index Reg. |A=X |
|TXS |9A|-------| X |2|Transfer Index Reg. |S=X |
|TYA |98|*----*-| X |2|Transfer Index Reg. |A=Y |
|-----+--+-------+--------+-+----------------------------------|
| |XX| | |X|Hexadecimal opcode/no. of cycles |
|--------+-------+--------+-+----------------------------------|
| |- | | |Flag unaffected |
| |* | | |Flag affected |
| |0 | | |Flag reset |
| |1 | | |Flag set |
| |+ | | |Flag set on stack |
|--------+-------+--------+-+----------------------------------|
| N |N | | |Negative status (Bit 7) |
| V | V | | |Overflow status (Bit 6) |
| B | B | | |Break command indicator (Bit 4) |
| D | D | | |Decimal mode control (Bit 3) |
| I | I | | |Interrupt disable control (Bit 2) |
| Z | Z | | |Zero status (Bit 1) |
| C | C| | |Carry status (Bit 0) |
----------------------------------------------------------------
----------------------------------------------------------------
|Mnemonic |A#ZBIRX@|Description |Opcode| ~s |
|----------------+--------+------------------------+------+----|
| |X |All mode(s) valid | | |
| |* |Non-indexed mode valid | | |
| |x |X/non-indexed mode valid| | |
| |y |Y/non-indexed mode valid| | |
|----------------+--------+------------------------+------+----|
| | |Add XXH to opcode | +XXH | |
| | |Subtract XXH from opcode| -XXH | |
| | |Add X to no. of cycles | | +X |
| | |Subtract X from cycles | | -X |
|----------------+--------+------------------------+------+----|
| A |A |Accumulator | | |
| #n | # |Immediate | -04H | -2 |
| <n | * |Zero page | -08H | -1 |
| n | * |Zero page (DIRECT mode) | -08H | -1 |
| n,X | x |Zero page indexed (X) | +08H | +0 |
| n,Y | y |Zero Page indexed (Y) | +08H | +0 |
| >nn | * |Absolute | +00H | +0 |
| nn | * |Absolute (EXTEND mode) | +00H | +0 |
| nn,X | x |Absolute indexed (X) | +10H | +0 |
| nn,Y | y |Absolute indexed (Y) | +0CH | +0 |
| LDX nn,Y | y | ditto | +10H | +0 |
| | I |Implicit | | |
| a | R |Relative(PC=PC+1+offset)| | +2 |
| [nn,X] | x |Indexed indirect (X) | -0CH | +2 |
| [nn],Y | y |Indirect indexed (Y) | +04H | +1 |
| [nn] | @|Absolute indirect | +20H | +2 |
|-------------------------+------------------------------------|
|BYTE n(,...) |Byte(s) (8-bit) |
|BYTE 'string'(,...) |Byte text string(s) |
|DIRECT |Zero page addressing mode |
|EXTEND |Absolute addressing mode |
|RMB nn(,...) |Reserve Memory Bytes |
|WORD nn(,...) |Word(s) (16-bit) |
|-------------------------+------------------------------------|
| A |Accumulator (8-bit) |
| P |Status Register (8-bit) |
| PC |Program Counter (16-bit) |
| S |Stack Pointer (9-bit, MSB=1) |
| X Y |Index Registers X and Y (8-bit) |
|-------------------------+------------------------------------|
| a |Relative Address (-128 to +127) |
| d |Destination |
| n |8-bit expression (0 to 255) |
| nn |16-bit expression (0 to 65535) |
| s |Source |
| string |String of ASCII characters |
|-------------------------+------------------------------------|
| + |Arithmetic addition |
| - |Arithmetic subtraction |
| * |Arithmetic multiplication |
| / |Arithmetic division |
| & |Logical AND |
| ~ |Logical NOT |
| v |Logical inclusive OR |
| x |Logical exclusive OR |
| <- |Rotate left |
| -> |Rotate right |
| [ ] |Indirect addressing |
| [ ]+ |Indirect addressing, auto-increment |
| -[ ] |Auto-decrement, indirect addressing |
| { } |Combination of operands |
| $ |Program counter content |
| % |~s = ~s+1 if crossing page boundary |
| ! |PC = effective address of source |
|-------------------------+------------------------------------|
|0000H to 00FFH |Page 0 (see zero page addressing) |
|0100H to 01FFH |Page 1 (stack area, 01FFH = start) |
|XX00H to XXFFH |Page n (where n=XXH) |
|FFFAH to FFFBH |Non maskable interrupt (NMI) vector |
|FFFCH to FFFDH |Reset (RES) vector |
|FFFEH to FFFFH |Interrupt Request (IRQ) vector |
|FFFEH to FFFFH |Break command vector (see BRK) |
|-------------------------+------------------------------------|
| 6501/6502 |16 address lines, 65536 bytes max. |
| 6503/6505 |13 address lines, 8192 bytes max. |
| 6504 |12 address lines, 4096 bytes max. |
----------------------------------------------------------------
programming/CARDS/65c02
+240
View File
@@ -0,0 +1,240 @@
----------------------------------------------------------------
| |
| |
| Rockwell |
| |
| 666 5555555 CCCC 000 22222 |
| 6 5 C C 0 0 2 2 |
| 6 5 C 0 0 0 2 |
| 666666 555555 C 0 0 0 222 |
| 6 6 5 C 0 0 0 2 |
| 6 6 5 C C 0 0 2 |
| 66666 555555 CCCC 000 2222222 |
| |
| 65C02 CMOS MICROPROCESSOR Instruction Set Summary |
| |
| |
| |
| |
| |
| _________ _________ |
| _| \__/ |_ ___ |
| Vss |_|1 40|_| RES <-- |
| _| |_ |
| --> RDY |_|2 39|_| CLK2 --> |
| _| |_ |
| <-- CLK1 |_|3 38|_| NC |
| ___ _| |_ |
| --> IRQ |_|4 37|_| CLK0 <-- |
| _| |_ |
| NC |_|5 36|_| NC |
| ___ _| |_ |
| --> NMI |_|6 35|_| NC |
| _| |_ _ |
| --> SYNC |_|7 34|_| R/W --> |
| _| |_ |
| Vcc |_|8 33|_| DB7 <--> |
| _| |_ |
| <-- A0 |_|9 32|_| DB6 <--> |
| _| |_ |
| <-- A1 |_|10 65C02 31|_| DB5 <--> |
| _| |_ |
| <-- A2 |_|11 30|_| DB4 <--> |
| _| |_ |
| <-- A3 |_|12 29|_| DB3 <--> |
| _| |_ |
| <-- A4 |_|13 28|_| DB2 <--> |
| _| |_ |
| <-- A5 |_|14 27|_| DB1 <--> |
| _| |_ |
| <-- A6 |_|15 26|_| DB0 <--> |
| _| |_ |
| <-- A7 |_|16 25|_| A15 --> |
| _| |_ |
| <-- A8 |_|17 24|_| A14 --> |
| _| |_ |
| <-- A9 |_|18 23|_| A13 --> |
| _| |_ |
| <-- A10 |_|19 22|_| A12 --> |
| _| |_ |
| <-- A11 |_|20 21|_| Vss |
| |______________________| |
| |
| |
| |
| |
| |
| |
|Written by Jonathan Bowen |
| Programming Research Group |
| Oxford University Computing Laboratory |
| 8-11 Keble Road |
| Oxford OX1 3QD |
| England |
| |
| Tel +44-865-273840 |
| |
|Created November 1984 |
|Updated April 1985 |
|Issue 1.1 Copyright (C) J.P.Bowen 1985|
----------------------------------------------------------------
----------------------------------------------------------------
|Mnem. |Op|NVBDIZC|A#ZBIRX@|~|Description |Notes |
|------+--+-------+--------+-+---------------------+-----------|
|ADC s|6D|**---**| XxX XX|4|Add with Carry |A=A+s+C %|
|AND s|2D|*----*-| XxX XX|4|Logical AND |A=A&s %|
|ASL d|0E|*----**| xx |6|Arith. Shift Left |d={C,d,0}<-|
|ASLA |0A|*----**|X |2|Arith. Shift Left |A={C,d,0}<-|
|BBRb z|0F|-------| * X |2|Branch if Bit Reset |If s<b>=0 |
|BBSb z|8F|-------| * X |2|Branch if Bit Set |If s<b>=1 |
|BCC a|90|-------| X |2|Branch if Carry Clear|If C=0(4~)%|
|BCS a|B0|-------| X |2|Branch if Carry Set |If C=1(4~)%|
|BEQ a|F0|-------| X |2|Branch if Equal |If Z=1(4~)%|
|BIT s|2C|**---*-| Xxx |4|Bit Test |A&s $|
|BMI a|30|-------| X |2|Branch if Minus |If N=1(4~)%|
|BNE a|D0|-------| X |2|Branch if Not Equal |If Z=0(4~)%|
|BPL a|10|-------| X |2|Branch if Plus |If N=0(4~)%|
|BRA a|80|-------| X |2|Branch Always |PC=a (4~)%|
|BRK |00|--+-1--| X |7|Break(-[S]={PC+2,P}) |PC=[FFFEH] |
|BVC a|50|-------| X |2|Branch if Overflw Clr|If V=0(4~)%|
|BVS a|70|-------| X |2|Branch if Overflw Set|If V=1(4~)%|
|CLC |18|------0| X |2|Clear Carry flag |C=0 |
|CLD |D8|---0---| X |2|Clear Decimal mode |D=0 |
|CLI |58|----0--| X |2|Clear Int. disable |I=0 |
|CLV |B8|-0-----| X |2|Clear Overflow flag |V=0 |
|CMP s|CD|*----**| XxX XX|4|Compare |A-s |
|CPX s|EC|*----**| X** |4|Compare index reg. |X-s |
|CPY s|CC|*----**| X** |4|Compare index reg. |Y-s |
|DEC d|CE|*----*-| xx |6|Decrement |d=d-1 |
|DECA |3A|*----*-|X |6|Decrement Acc. |A=A-1 |
|DEX |CA|*----*-| X |2|Decrement index reg. |X=X-1 |
|DEY |88|*----*-| X |2|Decrement index reg. |Y=Y-1 |
|EOR s|4D|*----*-| XxX XX|4|Logical Exclusive OR |A=Axs %|
|INC d|EE|*----*-| xx |6|Increment |d=d+1 |
|INCA |1A|*----*-|X |6|Increment Acc. |A=A+1 |
|INX |E8|*----*-| X |2|Increment index reg. |X=X+1 |
|INY |C8|*----*-| X |2|Increment index reg. |Y=Y+1 |
|JMP s|4C|-------| * X|3|Jump |PC=s $|
|JSR s|20|-------| * |6|Jump to Subroutine |-[S]=PC+2=s|
|LDA s|AD|*----*-| XxX XX|4|Load Accumulator |A=s %|
|LDX s|AE|*----*-| Xyy |4|Load index register |X=s $%|
|LDY s|AC|*----*-| Xxx |4|Load index register |Y=s %|
|LSR d|4E|0----**| xx |6|Logical Shift Right |d=->{0,d,C}|
|LSRA |4A|0----**|X |2|Logical Shift Right |A=->{0,A,C}|
|NOP |EA|-------| X |2|No Operation | |
|ORA s|0D|*----*-| XxX XX|4|Logical Inclusive OR |A=Avs |
|PHA |48|-------| X |3|Push Accumulator |-[S]=A |
|PHP |08|-------| X |3|Push status register |-[S]=P |
|PHX |DA|-------| X |2|Push index register |-[S]=X |
|PHY |5A|-------| X |2|Push index register |-[S]=Y |
|PLA |68|-------| X |4|Pull Accumulator |A=[S]+ |
|PLP |28|*******| X |4|Pull status register |P=[S]+ |
|PLX |FA|-------| X |2|Pull index register |X=[S]+ |
|PLY |7A|-------| X |2|Pull index register |Y=[S]+ |
|RMBb d|07|-------| * |5|Reset Memory Bit |d<b>=0 |
|ROL d|2E|*----**| xx |6|Rotate Left |d={C,d}<- |
|ROLA |2A|*----**|X |2|Rotate Left Acc. |A={C,A}<- |
|ROR d|6E|*----**| xx |6|Rotate Right |d=->{C,d} |
|RORA |6A|*----**|X |2|Rotate Right Acc. |A=->{C,A} |
|RTI |40|*******| X |6|Return from Interrupt|{PC,P}=[S]+|
|RTS |60|-------| X |6|Return from Subr. |PC={[S]+}+1|
|SBC s|ED|*----**| XxX XX|4|Subtract with Carry |A=A-s-C %|
|SEC |38|------1| X |2|Set Carry flag |C=1 |
|SED |F8|---1---| X |2|Set Decimal mode |D=1 |
|SEI |78|----1--| X |2|Set Interrupt disable|I=1 |
|SMBb d|87|-------| * |5|Set Memory Bit |d<b>=1 |
|STA d|8D|-------| xX XX|4|Store Accumulator |d=A |
|STX d|8E|-------| y* |4|Store index register |d=X |
|STY d|8C|-------| x* |4|Store index register |d=Y |
|STZ d|9C|-------| xx |4|Store Zero |d=0 $|
|TAX |AA|*----*-| X |2|Transfer Accumulator |X=A |
|TAY |A8|*----*-| X |2|Transfer Accumulator |Y=A |
|TRB d|1C|**---*-| ** |2|Test and Reset Bits |d=~A&d |
|TSB d|0C|**---*-| ** |2|Test and Set Bits |d=Avd |
|TSX |BA|*----*-| X |2|Transfer Stack ptr |X=S |
|TXA |8A|*----*-| X |2|Transfer index reg. |A=X |
|TXS |9A|-------| X |2|Transfer index reg. |S=X |
|TYA |98|*----*-| X |2|Transfer index reg. |A=Y |
|------+--+-------+--------+-+---------------------------------|
| |XX| | |X|Hexadecimal opcode/no. of cycles |
----------------------------------------------------------------
----------------------------------------------------------------
|Mnemonic |NVBDIZC|A#ZBIRX@|Description |
|---------+-------+--------+-----------------------------------|
| P |-*01+ | |Unaff/affected/reset/set/stack set |
| N |N | |Negative status (Bit 7) |
| V | V | |Overflow status (Bit 6) |
| B | B | |Break command indicator (Bit 4) |
| D | D | |Decimal mode control (Bit 3) |
| I | I | |Interrupt disable control (Bit 2) |
| Z | Z | |Zero status (Bit 1) |
| C | C| |Carry status (Bit 0) |
|------------------+--------+----------------------------------|
| |* |Only non-indexed mode valid |
| |x |X and non-indexed mode valid |
| |y |Y and non-indexed mode valid |
| |X |All modes valid |
|-----------------+--------+-----------------------------------|
| | |Add XXH to opcode |+XXH| |
| | |Subtract XXH from opcode |-XXH| |
| | |Add X to number of cycles | |+X|
| | |Subtract X from cycles | |-X|
|-----------------+--------+---------------------------+----+--|
| b | |Bit number (b=0-7) |+b0H| |
| A |A |Accumulator | | |
| #n | # |Immediate |-0CH|-2|
| #n | # | ditto (opcode = XDH) | X9H| 2|
| BIT #n | # | ditto (special case) | 89H| 2|
| <n | Z |Zero page |-08H|-1|
| STZ n | Z | ditto (special case) | 64H| 3|
| n | * |Zero page (direct mode) |-08H|-1|
| n,X | x |Zero page indexed (X) |+08H|+0|
| n,Y | y |Zero Page indexed (Y) |+08H|+0|
| >nn | B |Absolute |+00H|+0|
| nn | * |Absolute (extended mode) |+00H|+0|
| nn,X | x |Absolute indexed (X) |+10H|+0|
| nn,Y | y |Absolute indexed (Y) |+0CH|+0|
| LDX nn,Y | y | ditto (special case) | BEH| 4|
| | I |Implicit | | |
| a | R |Relative (PC=PC+1+offset) | |+2|
| [nn,X] | x |Indexed indirect (X) |-0CH|+2|
| [nn],Y | y |Indirect indexed (Y) |+04H|+1|
| [nn] | @|Absolute indirect |+05H|+1|
| JMP [nn] | @| ditto (special case) | 6CH| 5|
|--------------------------+-----------------------------------|
| A |Accumulator (8-bit) |
| P |Processor status register (8-bit) |
| PC |Program Counter (16-bit) |
| S |Stack pointer (9-bit, MSB=1) |
| X |Index register X (8-bit) |
| Y |Index register Y (8-bit) |
|--------------------------+-----------------------------------|
| a |Relative address (-128 to +127) |
| b |Bit number (0 to 7) |
| d |Destination |
| n |8-bit expression (0 to 255) |
| nn |16-bit expression (0 to 65535) |
| s |Source |
| z |Zero page, relative address (n,a) |
|--------------------------+-----------------------------------|
| + - |Arithmetic addition/subtraction |
| * / |Arithmetic multiplication/division |
| & ~ |Logical AND/NOT |
| v x |Logical inclusive/exclusive OR |
| <- -> |Rotate left/right |
| [ ] |Indirect addressing |
| [ ]+ |Post-increment indirect addressing |
| -[ ] |Pre-decrement indirect addressing |
| { } |Combination of operands |
| < > |Bit number |
| $ |Special case for addressing mode |
| % |~s=~s+1 if crossing page boundary |
|--------------------------+-----------------------------------|
|0000H to 00FFH |Page 0 (see zero page addressing) |
|0100H to 01FFH |Page 1 (stack area, 01FFH = start) |
|XX00H to XXFFH |Page n (where n=XXH) |
|FFFAH to FFFBH |Non maskable interrupt vector(NMI) |
|FFFCH to FFFDH |Reset (RES) vector |
|FFFEH to FFFFH |Interrupt Request vector (IRQ) |
|FFFEH to FFFFH |Break command vector (see BRK) |
----------------------------------------------------------------
programming/CARDS/6800
+240
View File
@@ -0,0 +1,240 @@
----------------------------------------------------------------
| |
| |
| Motorola |
| |
| 666 88888 000 000 |
| 6 8 8 0 0 0 0 |
| 6 8 8 0 0 0 0 0 0 |
| 666666 88888 0 0 0 0 0 0 |
| 6 6 8 8 0 0 0 0 0 0 |
| 6 6 8 8 0 0 0 0 |
| 66666 88888 000 000 |
| |
| 6800 MICROPROCESSOR Instruction Set Summary |
| |
| |
| |
| |
| |
| _________ _________ |
| _| \__/ |_ _____ |
| Vss |_|1 40|_| RESET <-- |
| ____ _| |_ |
| --> HALT |_|2 39|_| TSC <-- |
| _| |_ |
| --> PHI1 |_|3 38|_| NC |
| ___ _| |_ |
| --> IRQ |_|4 37|_| PHI2 <-- |
| _| |_ |
| <-- VMA |_|5 36|_| DBE <-- |
| ___ _| |_ |
| --> NMI |_|6 35|_| NC |
| _| |_ _ |
| <-- BA |_|7 34|_| R/W --> |
| _| |_ |
| Vcc |_|8 33|_| D0 <--> |
| _| |_ |
| <-- A0 |_|9 32|_| D1 <--> |
| _| |_ |
| <-- A1 |_|10 6800 31|_| D2 <--> |
| _| |_ |
| <-- A2 |_|11 30|_| D3 <--> |
| _| |_ |
| <-- A3 |_|12 29|_| D4 <--> |
| _| |_ |
| <-- A4 |_|13 28|_| D5 <--> |
| _| |_ |
| <-- A5 |_|14 27|_| D6 <--> |
| _| |_ |
| <-- A6 |_|15 26|_| D7 <--> |
| _| |_ |
| <-- A7 |_|16 25|_| A15 --> |
| _| |_ |
| <-- A8 |_|17 24|_| A14 --> |
| _| |_ |
| <-- A9 |_|18 23|_| A13 --> |
| _| |_ |
| <-- A10 |_|19 22|_| A12 --> |
| _| |_ |
| <-- A11 |_|20 21|_| Vss |
| |______________________| |
| |
| |
| |
| |
| |
| |
|Written by Jonathan Bowen |
| Programming Research Group |
| Oxford University Computing Laboratory |
| 8-11 Keble Road |
| Oxford OX1 3QD |
| England |
| |
| Tel +44-865-273840 |
| |
|Created August 1981 |
|Updated April 1985 |
|Issue 1.4 Copyright (C) J.P.Bowen 1985|
----------------------------------------------------------------
----------------------------------------------------------------
|Mnem. |Op|HINZVC|IEXD#R|~|Description |Notes |
|------+--+------+------+-+-----------------------+------------|
|ABA |1B|*-****|X |2|Add accumulators |A=A+B |
|ADCA s|B9|*-****| XXXX |4|Add with Carry |A=A+s+C |
|ADCB s|F9|*-****| XXXX |4|Add with Carry |B=B+s+C |
|ADDA s|BB|*-****| XXXX |4|Add |A=A+s |
|ADDB s|FB|*-****| XXXX |4|Add |B=B+s |
|ANDA s|B4|--**0-| XXXX |4|Logical AND |A=A&s |
|ANDB s|F4|--**0-| XXXX |4|Logical AND |B=B&s |
|ASL d|78|--****| XX |6|Arithmetic Shift Left |d=d*2 |
|ASLA |48|--****|X |2|Arithmetic Shift Left |A=A*2 |
|ASLB |58|--****|X |2|Arithmetic Shift Left |B=B*2 |
|ASR d|77|--****| XX |6|Arithmetic Shift Right |d=d/2 |
|ASRA |47|--****|X |2|Arithmetic Shift Right |A=A/2 |
|ASRB |57|--****|X |2|Arithmetic Shift Right |B=B/2 |
|BCC a|24|------| X|4|Branch if Carry Clear |If C=0 |
|BCS a|25|------| X|4|Branch if Carry Set |If C=1 |
|BEQ a|27|------| X|4|Branch if Equal |If Z=1 |
|BGE a|2C|------| X|4|Branch if Greater or Eq|If NxV=0 |
|BGT a|2E|------| X|4|Branch if Greater Than |If Zv{NxV}=0|
|BHI a|22|------| X|4|Branch if Higher |If CvZ=0 |
|BITA s|B5|--**0-| XXXX |4|Bit Test |A&s |
|BITB s|F5|--**0-| XXXX |4|Bit Test |B&s |
|BLE a|2F|------| X|4|Branch if Less or Equal|If Zv{NxV}=0|
|BLS a|23|------| X|4|Branch if Lower or Same|If CvZ=1 |
|BLT a|2D|------| X|4|Branch if Less Than |If NxV=1 |
|BMI a|2B|------| X|4|Branch if Minus |If N=1 |
|BNE a|26|------| X|4|Branch if Not Equal |If Z=0 |
|BPL a|2A|------| X|4|Branch if Plus |If N=0 |
|BRA a|20|------| X|4|Branch Always |PC=a |
|BSR a|8D|------| X|8|Branch to Subroutine |-[S]=PC,PC,a|
|BVC a|28|------| X|4|Branch if Overflow Clr |If V=0 |
|BVS a|29|------| X|4|Branch if Overflow Set |If V=1 |
|CBA |11|--****|X |2|Compare accumulators |A-B |
|CLC |0C|-----0|X |2|Clear Carry |C=0 |
|CLI |0E|-0----|X |2|Clear Interrupt Mask |I=0 |
|CLR d|7F|--0100| XX |6|Clear |d=0 |
|CLRA |4F|--0100|X |2|Clear accumulator |A=0 |
|CLRB |5F|--0100|X |2|Clear accumulator |B=0 |
|CLV |0A|----0-|X |2|Clear Overflow |V=0 |
|CMPA s|B1|--****| XXXX |4|Compare |A-s |
|CMPB s|F1|--****| XXXX |4|Compare |B-s |
|COM d|63|--**01| XX |7|Complement |d=~d |
|COMA |43|--**01|X |2|Complement accumulator |A=~A |
|COMB |53|--**01|X |2|Complement accumulator |B=~B |
|CPX s|BC|--****| XXX* |5|Compare Index Register |X-s |
|DAA |19|--****|X |2|Decimal Adjust Acc. |A=BCD format|
|DEC d|7A|--**?-| XX |6|Decrement |d=d-1 |
|DECA |4A|--**?-|X |2|Decrement accumulator |A=A-1 |
|DECB |5A|--**?-|X |2|Decrement accumulator |B=B-1 |
|DES |34|------|X |4|Decrement Stack Pointer|S=S-1 |
|DEX |09|---*--|X |4|Decrement Index Reg. |X=X-1 |
|EORA s|B8|--**0-| XXXX |4|Logical Exclusive OR |A=Axs |
|EORB s|F8|--**0-| XXXX |4|Logical Exclusive OR |B=Bxs |
|INC d|7C|--**?-| XX |6|Increment |d=d+1 |
|INCA |4C|--**?-|X |2|Increment accumulator |A=A+1 |
|INCB |5C|--**?-|X |2|Increment accumulator |B=B+1 |
|INS |31|------|X |4|Increment Stack Pointer|S=S+1 |
|INX |08|---*--|X |4|Increment Index Reg. |X=X+1 |
|JMP d|7E|------| XX |3|Jump |PC=d |
|JSR d|BD|------| XX |9|Jump to Subroutine |-[S]=PC,PC=d|
|LDAA s|B6|--**0-| XXXX |4|Load Accumulator |A=s |
|LDAB s|F6|--**0-| XXXX |4|Load Accumulator |B=s |
|LDS s|BE|--**0-| XXX* |5|Load Stack Pointer |S=s |
|LDX s|FE|--**0-| XXX* |5|Load Index Register |X=s |
|LSR d|74|--0***| XX |6|Logical Shift Right |d=->{0,d,C} |
|LSRA |44|--0***|X |2|Logical Shift Right |A=->{0,A,C} |
|LSRB |54|--0***|X |2|Logical Shift Right |B=->{0,B,C} |
|NEG d|70|--****| XX |6|Negate |d=-d |
|NEGA |40|--****|X |2|Negate accumulator |A=-A |
|NEGB |50|--****|X |2|Negate accumulator |B=-B |
|NOP |01|------|X |2|No Operation | |
|ORAA s|BA|--**0-| XXXX |4|Logical inclusive OR |A=Avs |
|ORAB s|FA|--**0-| XXXX |4|Logical inclusive OR |B=Bvs |
|PSHA |36|------|X |4|Push |-[S]=A |
|PSHB |37|------|X |4|Push |-[S]=B |
|PULA |32|------|X |4|Pull |A=[S]+ |
|PULB |33|------|X |4|Pull |B=[S]+ |
----------------------------------------------------------------
----------------------------------------------------------------
|Mnem. |Op|HINZVC|IEXD#R|~|Description |Notes |
|------+--+------+------+-+-----------------------+------------|
|ROL d|79|--**?*| XX |6|Rotate Left |d={C,d}<- |
|ROLA |49|--**?*|X |2|Rotate Left accumulator|A={C,A}<- |
|ROLB |59|--**?*|X |2|Rotate Left accumulator|B={C,B}<- |
|ROR d|76|--**?*| XX |6|Rotate Right |d=->{C,d} |
|RORA |46|--**?*|X |2|Rotate Right acc. |A=->{C,A} |
|RORB |56|--**?*|X |2|Rotate Right acc. |B=->{C,B} |
|RTI |3B|??????|X |A|Return from Interrupt |{regs}=[S]+ |
|RTS |39|------|X |5|Return from Subroutine |PC=[S]+ |
|SBA |10|--****|X |2|Subtract accumulators |A=A-B |
|SBCA s|B2|--****| XXXX |4|Subtract with Carry |A=A-s-C |
|SBCB s|F2|--****| XXXX |4|Subtract with Carry |B=B-s-C |
|SEC |0D|-----1|X |2|Set Carry |C=1 |
|SEI |0F|-1----|X |2|Set Interrupt Mask |I=1 |
|SEV |0B|----1-|X |2|Set Overflow |V=1 |
|STAA d|B7|--**0-| XXX |5|Store Accumulator |d=A |
|STAB d|F7|--**0-| XXX |5|Store Accumulator |d=B |
|STS d|BF|--**0-| XXX |6|Store Stack Pointer |d=S |
|STX d|FF|--**0-| XXX |6|Store Index Register |d=X |
|SUBA s|B0|--****| XXXX |4|Subtract |A=A-s |
|SUBB s|F0|--****| XXXX |4|Subtract |B=B-s |
|SWI |3F|-1----|X |C|Software Interrupt |-[S]={regs} |
|TAB |17|--**0-|X |2|Transfer accumulators |B=A |
|TAP |06|******|X |2|Transfer to CCR |P=A |
|TBA |17|--**0-|X |2|Transfer accumulators |A=B |
|TPA |07|------|X |2|Transfer from CCR |A=P |
|TST s|7D|--**00| XX |6|Test |s |
|TSTA |4D|--**00|X |2|Test accumulator |A |
|TSTB |5D|--**00|X |2|Test accumulator |B |
|TSX |30|------|X |4|Transfer Stack Pointer |X=S |
|TXS |35|------|X |4|Transfer Index Register|S=X |
|WAI |3E|-*----|X |9|Wait for Interrupt |-[S]={regs} |
|---------+------+------+-+------------------------------------|
| CCR |-*01? | | |Unaffect/affected/reset/set/unknown |
| H |H | | |Half carry (Bit 5) |
| I | I | | |Interrupt mask (Bit 4) |
| N | N | | |Negative (Bit 3) |
| Z | Z | | |Zero (Bit 2) |
| V | V | | |Overflow (Bit 1) |
| C | C| | |Carry (Bit 0) |
|----------------+------+-+------------------------------------|
| |I | |Inherent |
| nn,E | E | |Extended (Op=E, ~s=e) |
| nn,X | X | |Index (Op=E-10H, ~s=e+1, JSR ~s=e-1)|
| n,D | D | |Direct (Op=E-20H, ~s=e-1) |
| #n | # | |Immediate (8-bit, Op=E-30H, ~s=e-2) |
| #nn | * | |Immediate (16-bit, Op=E-30H, ~s=e-2)|
| a | R| |Relative (PC=PC+2+offset) |
|-------------------------+------------------------------------|
|DIRECT |Direct addressing mode |
|EXTEND |Extended addressing mode |
|FCB n |Form Constant Byte |
|FCC 'string' |Form Constant Characters |
|FDB nn |Form Double Byte |
|RMB nn |Reserve Memory Bytes |
|-------------------------+------------------------------------|
| A B |Accumulators (8-bit) |
| P |Condition Code Register (CCR, 8-bit)|
| PC |Program Counter (16-bit) |
| S |Stack Pointer (16-bit) |
| X |Index Register (16-bit) |
|-------------------------+------------------------------------|
| a |Relative address (-125 to +129) |
| d s |Destination/source |
| n nn |8/16-bit expression (0 to 255/65535)|
| + - * / |Add/subtract/multiply/divide |
| & ~ v x |AND/NOT/inclusive OR/exclusive OR |
| <- -> |Rotate left/right |
| [ ] |Indirect addressing |
| [ ]+ -[ ] |Indirect auto-increment/decrement |
| { } |Combination of operands |
| {regs} |All registers {PC,X,A,B,P} |
|-------------------------+------------------------------------|
| FFF8H to FFF9H |Hardware interrupt vector |
| FFFAH to FFFBH |SWI instruction interrupt vector |
| FFFCH to FFFDH |Non-maskable interrupt vector |
| FFFEH to FFFFH |Reset vector |
----------------------------------------------------------------
programming/CARDS/68000
+240
View File
@@ -0,0 +1,240 @@
----------------------------------------------------------------
| |
| |
| Motorola |
| |
| 666 88888 000 000 000 |
| 6 8 8 0 0 0 0 0 0 |
| 6 8 8 0 0 0 0 0 0 0 0 0 |
| 666666 88888 0 0 0 0 0 0 0 0 0 |
| 6 6 8 8 0 0 0 0 0 0 0 0 0 |
| 6 6 8 8 0 0 0 0 0 0 |
| 66666 88888 000 000 000 |
| |
| 68000 MICROPROCESSOR Instruction Set Summary |
| |
| |
| |
| |
| |
| |
| |
| |
| _________ _________ |
| | \__/ | |
| <--> D4 -|1 64|- D5 <--> |
| <--> D3 -|2 63|- D6 <--> |
| <--> D2 -|3 62|- D7 <--> |
| <--> D1 -|4 61|- D8 <--> |
| <--> D0 -|5 60|- D9 <--> |
| <-- ~AS -|6 59|- D10 <--> |
| <-- ~UDS -|7 58|- D11 <--> |
| <-- ~LDS -|8 57|- D12 <--> |
| <-- R/~W -|9 56|- D13 <--> |
| --> ~DTACK -|10 55|- D14 <--> |
| <-- ~BG -|11 54|- D15 <--> |
| --> ~BGACK -|12 53|- GND |
| --> ~BR -|13 52|- A23 --> |
| Vcc -|14 51|- A22 --> |
| --> CLK -|15 50|- A21 --> |
| GND -|16 68000 49|- Vcc |
| <--> ~HALT -|17 48|- A20 --> |
| <--> ~RESET -|18 47|- A19 --> |
| <-- ~VMA -|19 46|- A18 --> |
| <-- E -|20 45|- A17 --> |
| --> ~VPA -|21 44|- A16 --> |
| --> ~BERR -|22 43|- A15 --> |
| --> ~IPL2 -|23 42|- A14 --> |
| --> ~IPL1 -|24 41|- A13 --> |
| --> ~IPL0 -|25 40|- A12 --> |
| <-- FC2 -|26 39|- A11 --> |
| <-- FC1 -|27 38|- A10 --> |
| <-- FC0 -|28 37|- A9 --> |
| <-- A1 -|29 36|- A8 --> |
| <-- A2 -|30 35|- A7 --> |
| <-- A3 -|31 34|- A6 --> |
| <-- A4 -|32 33|- A5 --> |
| |______________________| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
|Written by Jonathan Bowen |
| Programming Research Group |
| Oxford University Computing Laboratory |
| 8-11 Keble Road |
| Oxford OX1 3QD |
| England |
| |
| Tel +44-865-273840 |
| |
|Created January 1983 |
|Updated April 1985 |
|Issue 1.4 Copyright (C) J.P.Bowen 1985|
----------------------------------------------------------------
----------------------------------------------------------------
|Mnemonic |XNZVC|BWL|Description |Notes |
|-----------+-----+---+----------------------+-----------------|
|ABCD s,d |*?*?*|X |Add BCD format |d=BCD{d+s+X} |
|ADD s,d |*****|XXX|Add binary |d=d+s |
|ADDA s,An |-----| XX|Add Address |An=An+s |
|ADDI #e,d |*****|XXX|Add Immediate |d=d+e |
|ADDQ #q,d |*****|XXX|Add Quick |d=d+q |
|ADDX s,d |*****|XXX|Add Extended |d=d+s+X |
|AND s,d |-**00|XXX|Logical AND |d=d&s |
|ANDI #e,d |-**00|XXX|Logical AND Immediate |d=d&e |
|ASlr d |*****|XXX|Arithmetic Shift |d=d*2 or d=d/2 |
|Bcc l |-----|XX |Branch conditionally |If cc BRA |
|BCHG s,d |--*--| XX|Bit test and Change |BTST,d<s>=Z |
|BCLR d |--*--| XX|Bit test and Clear |BTST,d<s>=0 |
|BRA l |-----|XX |Branch Always |PC=l |
|BSET d |--*--| XX|Bit test and Set |BTST,d<s>=1 |
|BSR l |-----|XX |Branch to Subroutine |-[SP]=PC,PC=l |
|BTST d |--*--| XX|Bit Test |Z=~d<s> |
|CHK s,Dn |-*???| X |Check register |If 0>Dn>s $[18H] |
|CLR d |-0100|XXX|Clear operand |d=0 |
|CMP s,Dn |-****|XXX|Compare |Dn-s |
|CMPA s,An |-****|XXX|Compare Address |An-s |
|CMPI #e,d |-****|XXX|Compare Immediate |d-e |
|CMPM s,d |-****|XXX|Compare Memory |d-s |
|DBcc Dn,l |-----| |Decrement and Branch |If~cc&Dn-1~-1 BRA|
|DIVS s,Dn |-***0| X |Signed Division |Dn={Dn%s,Dn/s} |
|DIVU s,Dn |-***0| X |Unsigned Division |Dn={Dn%s,Dn/s} |
|EOR Dn,d |-**00|XXX|Exclusive OR |d=dxDn |
|EORI #e,d |-**00|XXX|Exclusive OR Immediate|d=dxe |
|EXG r,r |-----| X|Exchange registers |r<->r |
|EXT Dn |-**00| XX|Extend sign |Dn<hi>=Dn<7or15> |
|JMP d |-----| |Jump |PC=d |
|JSR d |-----| |Jump to Subroutine |-[SP]=PC,PC=d |
|LEA s,An |-----| X|Load Effective Address|An=EA{s} |
|LINK An,#nn|-----| |Link and allocate |-[SP]=An=SP=SP+nn|
|LSlr d |***0*|XXX|Logical Shift |d=->{C,d,0}<- |
|MOVE s,d |-**00|XXX|Move data |d=s |
|MOVE s,CCR|*****| X |Move to CCR |CCR=s |
|MOVE s,SR |*****| X |Move to SR |SR=s |
|MOVE SR,d |-----| X |Move from SR |d=SR |
|MOVE USP,An|-----| X|Move User SP |USP=An or An=USP |
|MOVEA s,An |-----| XX|Move Address |An=s |
|MOVEM s,d |-----| XX|Move Multiple register|rr=s or d=rr |
|MOVEP s,d |-----| XX|Move Peripheral data |d=Dn or Dn=s |
|MOVEQ #q,d |-**00| X|Move Quick |d=q |
|MULS s,Dn |-**00| X |Signed Multiply |Dn<0:31>=Dn*s |
|MULU s,Dn |-**00| X |Unsigned Multiply |Dn<0:31>=Dn*s |
|NBCD d |*?*?*|X |Negate BCD format |d=BCD{-d-X} |
|NEG d |*****|XXX|Negate |d=-d |
|NEGX d |*****|XXX|Negate with Extend |d=-d-X |
|NOP |-----| |No Operation | |
|NOT d |-**00|XXX|Logical NOT |d=~d |
|OR s,d |-**00|XXX|Inclusive OR |d=dvs |
|ORI #e,d |-**00|XXX|Inclusive OR Immediate|d=dve |
|PEA s |-----| X|Push Effective Address|-[SP]=EA{s} |
|RESET |-----| |Reset external devices|Reset line=0 |
|ROlr d |-**0*|XXX|Rotate |d=->{d}<- |
|ROXlr d |***0*|XXX|Rotate with Extend |d=->{d}<-,X=C |
|RTE |*****| |Return from Exception |SR=[SSP]+,RTS |
|RTR |*****| |Return and Restore |SR<0:4>=[SP]+,RTS|
|RTS |-----| |Return from Subroutine|PC=[SP]+ |
|SBCD s,d |*?*?*|X |Subtract BCD format |d=BCD{d-s-X} |
|Scc d |-----|X |Set conditionally |d=0 or d=-1 |
|STOP #nn |*****| |Load status and Stop |SR=nn, wait |
|SUB s,d |*****|XXX|Subtract binary |d=d-s |
|SUBA s,An |-----| XX|Subtract Address |An=An-s |
|SUBI #e,d |*****|XXX|Subtract Immediate |d=d-e |
|SUBQ #q,d |*****|XXX|Subtract Quick |d=d-q |
|SUBX s,d |*****|XXX|Subtract with Extend |d=d-s-X |
|SWAP Dn |-**00| X |Swap register halves |Dn<hi><->Dn<lo> |
|TAS d |-**00|X |Test And Set |d<7>=1 |
|TRAP #n |-----| |Trap (n=0-15)|$[80H+4*n] |
|TRAPV |-----| |Trap on Overflow |If V=1 $[1CH] |
|TST d |-**00|XXX|Test |d |
|UNLK An |-----| |Unlink |SP=An,An=[SP]+ |
|-----------------+---+----------------------------------------|
|DC e(,...) |XXX|Define Constant |
|DS e |XXX|Define Storage |
----------------------------------------------------------------
----------------------------------------------------------------
|Mnemonic |XNZVC|BWL|Description |
|-----------+-----+---+----------------------------------------|
| CCR |-*01?| |Unaffected/affected/reset/set/unknown |
| T | | |Trace mode flag (Bit 15) |
| S | | |Supervisor/user mode select (Bit 13) |
| In | | |Interrupt mask flag #n (Bits 8-10,n=0-2)|
| X |X | |Extend flag (Bit 4) |
| N | N | |Negative flag (Bit 3) |
| Z | Z | |Zero flag (Bit 2) |
| V | V | |Overflow flag (Bit 1) |
| C | C| |Carry flag (Bit 0) |
|-----------------+---+----------------------------------------|
| .B |X |Byte attribute (8-bit, .S for branch) |
| .W | X |Word attribute (16-bit) |
| .L | X|Long word attribute (32-bit) |
|---------------------+----------------------------------------|
| Dn |Data register direct addressing |
| An |Address register direct addressing |
| [An] |Register indirect addressing |
| [An]+ |Post-increment register indirect addr. |
| -[An] |Pre-decrement register indirect addr. |
| n[An] |Offset register indirect addressing |
| n[An,r] |Index register indirect addressing |
| nn |Short absolute data addressing |
| nnnn |Long absolute data addressing |
| nn |Program counter relative addressing |
| nn[r] |Program counter with index addressing |
| #e |Immediate data addressing |
|---------------------+----------------------------------------|
|ABSOLUTE_LONG |Long Absolute addressing (or ABS_LONG)|
|ABSOLUTE_SHORT |Short Absolute addressing (or ABS_SHORT)|
|EVEN |Set program counter to Even address |
|NO_RORG |Disable Relative addressing (or PC_DEP)|
|RORG |Enable Relative addressing (or PC_INDEP)|
|---------------------+----------------------------------------|
| An |Address register (16/32-bit, n=0-7) |
| CCR |Condition Code Register (8-bit, low SR) |
| Dn |Data register (8/16/32-bit, n=0-7) |
| PC |Program Counter (24-bit) |
| SP |Active Stack Pointer (equivalent to A7) |
| SR |Status Register (16-bit) |
| SSP |Supervisor Stack Pointer (32-bit) |
| USP |User Stack Pointer (32-bit) |
|---------------------+----------------------------------------|
| BCD{ } EA{ } |Binary Coded Decimal/Effective Address |
| cc |Condition = (T/F/HI/LS/CC/CS/NE/EQ/ |
| | VC/VS/PL/MI/GE/LT/GT/LE) |
| d s |Destination/source |
| e n nn nnnn |Any/8-bit/16-bit/32-bit expression |
| l |Branch displacement label (8/16-bit) |
| lr |Left/right direction = (L/R) |
| q |Quick expression (1-8) |
| r |Any register An or Dn |
| rr |Multiple registers (-=range,/=separator)|
| + - * / % |Add/subtract/multiply/divide/remainder |
| & ~ v x |AND/NOT/inclusive OR/exclusive OR |
| ->{ }<- <-> |Rotate left or right/exchange operands |
| [ ] -[ ] [ ]+ |Indirect/autoincrement/autodecr. address|
| < > <:> <hi> <lo>|Bit number/bit range/high half/low half |
| { } {,} |Combination of operands |
| $ |Software trap -[SP]=PC,-[SP]=SR,PC=... |
|---------------------+----------------------------------------|
| 0000H to 0007H |Reset vector (initial SSP and PC) (0-1)|
| 0008H to 000BH |Bus error vector (2)|
| 000CH to 000FH |Address error vector (3)|
| 0010H to 0013H |Illegal instruction vector (4)|
| 0014H to 0017H |Zero divide vector (5)|
| 0018H to 001BH |CHK instruction vector (6)|
| 001CH to 001FH |TRAPV instruction vector (7)|
| 0020H to 0023H |Privilege violation vector (8)|
| 0024H to 0027H |Trace vector (9)|
| 0028H to 002FH |Line 1010/1111 emulator vectors (10-11)|
| 003CH to 003FH |Uninitialised interrupt vector (15)|
| 0060H to 0063H |Spurious interrupt vector (24)|
| 0064H to 007FH |Level 1-7 interrupt auto-vectors (25-31)|
| 0080H to 00BFH |TRAP #0-15 instruction vectors (32-47)|
| |Unassigned, reserved (12-14,16-23,48-63)|
| 0100H to 03FFH |User interrupt vectors (64-255)|
----------------------------------------------------------------
programming/CARDS/68008
+240
View File
@@ -0,0 +1,240 @@
----------------------------------------------------------------
| |
| |
| Motorola |
| |
| 666 88888 000 000 88888 |
| 6 8 8 0 0 0 0 8 8 |
| 6 8 8 0 0 0 0 0 0 8 8 |
| 666666 88888 0 0 0 0 0 0 88888 |
| 6 6 8 8 0 0 0 0 0 0 8 8 |
| 6 6 8 8 0 0 0 0 8 8 |
| 66666 88888 000 000 88888 |
| |
| 68008 MICROPROCESSOR Instruction Set Summary |
| |
| _________ _________ |
| _| \__/ |_ |
| <-- A3 |_|1 48|_| A2 --> |
| _| |_ |
| <-- A4 |_|2 47|_| A1 --> |
| _| |_ |
| <-- A5 |_|3 46|_| A0 --> |
| _| |_ |
| <-- A6 |_|4 45|_| FC0 --> |
| _| |_ |
| <-- A7 |_|5 44|_| FC1 --> |
| _| |_ |
| <-- A8 |_|6 43|_| FC2 --> |
| _| |_ ____ _ |
| <-- A9 |_|7 42|_| IPL2/0 <-- |
| _| |_ ____ |
| <-- A10 |_|8 41|_| IPL1 <-- |
| _| |_ ____ |
| <-- A11 |_|9 40|_| BERR <-- |
| _| |_ ___ |
| <-- A12 |_|10 39|_| VPA <-- |
| _| |_ |
| <-- A13 |_|11 38|_| E --> |
| _| |_ _____ |
| <-- A14 |_|12 68008 37|_| RESET <--> |
| _| |_ ____ |
| Vcc |_|13 36|_| HALT <--> |
| _| |_ |
| <-- A15 |_|14 35|_| GND |
| _| |_ |
| GND |_|15 34|_| CLK <-- |
| _| |_ __ |
| <-- A16 |_|16 33|_| BR <-- |
| _| |_ __ |
| <-- A17 |_|17 32|_| BG --> |
| _| |_ _____ |
| <-- A18 |_|18 31|_| DTACK --> |
| _| |_ _ |
| <-- A19 |_|19 30|_| R/W --> |
| _| |_ __ |
| <--> D7 |_|20 29|_| DS --> |
| _| |_ __ |
| <--> D6 |_|21 28|_| AS --> |
| _| |_ |
| <--> D5 |_|22 27|_| D0 <--> |
| _| |_ |
| <--> D4 |_|23 26|_| D1 <--> |
| _| |_ |
| <--> D3 |_|24 25|_| D2 <--> |
| |______________________| |
| |
| |
|Written by Jonathan Bowen |
| Programming Research Group |
| Oxford University Computing Laboratory |
| 8-11 Keble Road |
| Oxford OX1 3QD |
| England |
| |
| Tel +44-865-273840 |
| |
|Created November 1984 |
|Updated April 1985 |
|Issue 1.1 Copyright (C) J.P.Bowen 1985|
----------------------------------------------------------------
----------------------------------------------------------------
|Mnemonic |XNZVC|BWL|Description |Notes |
|-----------+-----+---+----------------------+-----------------|
|ABCD s,d |*?*?*|X |Add BCD format |d=BCD{d+s+X} |
|ADD s,d |*****|XXX|Add binary |d=d+s |
|ADDA s,An |-----| XX|Add Address |An=An+s |
|ADDI #e,d |*****|XXX|Add Immediate |d=d+e |
|ADDQ #q,d |*****|XXX|Add Quick |d=d+q |
|ADDX s,d |*****|XXX|Add Extended |d=d+s+X |
|AND s,d |-**00|XXX|Logical AND |d=d&s |
|ANDI #e,d |-**00|XXX|Logical AND Immediate |d=d&e |
|ASlr d |*****|XXX|Arithmetic Shift |d=d*2 or d=d/2 |
|Bcc l |-----|XX |Branch conditionally |If cc BRA |
|BCHG s,d |--*--| XX|Bit test and Change |BTST,d<s>=Z |
|BCLR d |--*--| XX|Bit test and Clear |BTST,d<s>=0 |
|BRA l |-----|XX |Branch Always |PC=l |
|BSET d |--*--| XX|Bit test and Set |BTST,d<s>=1 |
|BSR l |-----|XX |Branch to Subroutine |-[SP]=PC,PC=l |
|BTST d |--*--| XX|Bit Test |Z=~d<s> |
|CHK s,Dn |-*???| X |Check register |If 0>Dn>s $[18H] |
|CLR d |-0100|XXX|Clear operand |d=0 |
|CMP s,Dn |-****|XXX|Compare |Dn-s |
|CMPA s,An |-****|XXX|Compare Address |An-s |
|CMPI #e,d |-****|XXX|Compare Immediate |d-e |
|CMPM s,d |-****|XXX|Compare Memory |d-s |
|DBcc Dn,l |-----| |Decrement and Branch |If~cc&Dn-1~-1 BRA|
|DIVS s,Dn |-***0| X |Signed Division |Dn={Dn%s,Dn/s} |
|DIVU s,Dn |-***0| X |Unsigned Division |Dn={Dn%s,Dn/s} |
|EOR Dn,d |-**00|XXX|Exclusive OR |d=dxDn |
|EORI #e,d |-**00|XXX|Exclusive OR Immediate|d=dxe |
|EXG r,r |-----| X|Exchange registers |r<->r |
|EXT Dn |-**00| XX|Extend sign |Dn<hi>=Dn<7or15> |
|JMP d |-----| |Jump |PC=d |
|JSR d |-----| |Jump to Subroutine |-[SP]=PC,PC=d |
|LEA s,An |-----| X|Load Effective Address|An=EA{s} |
|LINK An,#nn|-----| |Link and allocate |-[SP]=An=SP=SP+nn|
|LSlr d |***0*|XXX|Logical Shift |d=->{C,d,0}<- |
|MOVE s,d |-**00|XXX|Move data |d=s |
|MOVE s,CCR|*****| X |Move to CCR |CCR=s |
|MOVE s,SR |*****| X |Move to SR |SR=s |
|MOVE SR,d |-----| X |Move from SR |d=SR |
|MOVE USP,An|-----| X|Move User SP |USP=An or An=USP |
|MOVEA s,An |-----| XX|Move Address |An=s |
|MOVEM s,d |-----| XX|Move Multiple register|rr=s or d=rr |
|MOVEP s,d |-----| XX|Move Peripheral data |d=Dn or Dn=s |
|MOVEQ #q,d |-**00| X|Move Quick |d=q |
|MULS s,Dn |-**00| X |Signed Multiply |Dn<0:31>=Dn*s |
|MULU s,Dn |-**00| X |Unsigned Multiply |Dn<0:31>=Dn*s |
|NBCD d |*?*?*|X |Negate BCD format |d=BCD{-d-X} |
|NEG d |*****|XXX|Negate |d=-d |
|NEGX d |*****|XXX|Negate with Extend |d=-d-X |
|NOP |-----| |No Operation | |
|NOT d |-**00|XXX|Logical NOT |d=~d |
|OR s,d |-**00|XXX|Inclusive OR |d=dvs |
|ORI #e,d |-**00|XXX|Inclusive OR Immediate|d=dve |
|PEA s |-----| X|Push Effective Address|-[SP]=EA{s} |
|RESET |-----| |Reset external devices|Reset line=0 |
|ROlr d |-**0*|XXX|Rotate |d=->{d}<- |
|ROXlr d |***0*|XXX|Rotate with Extend |d=->{d}<-,X=C |
|RTE |*****| |Return from Exception |SR=[SSP]+,RTS |
|RTR |*****| |Return and Restore |SR<0:4>=[SP]+,RTS|
|RTS |-----| |Return from Subroutine|PC=[SP]+ |
|SBCD s,d |*?*?*|X |Subtract BCD format |d=BCD{d-s-X} |
|Scc d |-----|X |Set conditionally |d=0 or d=-1 |
|STOP #nn |*****| |Load status and Stop |SR=nn, wait |
|SUB s,d |*****|XXX|Subtract binary |d=d-s |
|SUBA s,An |-----| XX|Subtract Address |An=An-s |
|SUBI #e,d |*****|XXX|Subtract Immediate |d=d-e |
|SUBQ #q,d |*****|XXX|Subtract Quick |d=d-q |
|SUBX s,d |*****|XXX|Subtract with Extend |d=d-s-X |
|SWAP Dn |-**00| X |Swap register halves |Dn<hi><->Dn<lo> |
|TAS d |-**00|X |Test And Set |d<7>=1 |
|TRAP #n |-----| |Trap (n=0-15)|$[80H+4*n] |
|TRAPV |-----| |Trap on Overflow |If V=1 $[1CH] |
|TST d |-**00|XXX|Test |d |
|UNLK An |-----| |Unlink |SP=An,An=[SP]+ |
|-----------------+---+----------------------------------------|
|DC e(,...) |XXX|Define Constant |
|DS e |XXX|Define Storage |
----------------------------------------------------------------
----------------------------------------------------------------
|Mnemonic |XNZVC|BWL|Description |
|-----------+-----+---+----------------------------------------|
| CCR |-*01?| |Unaffected/affected/reset/set/unknown |
| T | | |Trace mode flag (Bit 15) |
| S | | |Supervisor/user mode select (Bit 13) |
| In | | |Interrupt mask flag #n (Bits 8-10,n=0-2)|
| X |X | |Extend flag (Bit 4) |
| N | N | |Negative flag (Bit 3) |
| Z | Z | |Zero flag (Bit 2) |
| V | V | |Overflow flag (Bit 1) |
| C | C| |Carry flag (Bit 0) |
|-----------------+---+----------------------------------------|
| .B |X |Byte attribute (8-bit, .S for branch) |
| .W | X |Word attribute (16-bit) |
| .L | X|Long word attribute (32-bit) |
|---------------------+----------------------------------------|
| Dn |Data register direct addressing |
| An |Address register direct addressing |
| [An] |Register indirect addressing |
| [An]+ |Post-increment register indirect addr. |
| -[An] |Pre-decrement register indirect addr. |
| n[An] |Offset register indirect addressing |
| n[An,r] |Index register indirect addressing |
| nn |Short absolute data addressing |
| nnnn |Long absolute data addressing |
| nn |Program counter relative addressing |
| nn[r] |Program counter with index addressing |
| #e |Immediate data addressing |
|---------------------+----------------------------------------|
| An |Address register (16/32-bit, n=0-7) |
| CCR |Condition Code Register (8-bit, low SR) |
| Dn |Data register (8/16/32-bit, n=0-7) |
| PC |Program Counter (24-bit) |
| SP |Active Stack Pointer (equivalent to A7) |
| SR |Status Register (16-bit) |
| SSP |Supervisor Stack Pointer (32-bit) |
| USP |User Stack Pointer (32-bit) |
|---------------------+----------------------------------------|
| BCD{ } |Binary Coded Decimal value of operand |
| EA{ } |Effective Address of operand |
| cc |Condition = (T/F/HI/LS/CC/CS/NE/EQ/ |
| | VC/VS/PL/MI/GE/LT/GT/LE) |
| d s |Destination/source |
| e n nn nnnn |Any/8-bit/16-bit/32-bit expression |
| l |Branch displacement label (8/16-bit) |
| lr |Left/right direction = (L/R) |
| q |Quick expression (1-8) |
| r |Any register An or Dn |
| rr |Multiple registers (-=range,/=separator)|
| + - * / % |Add/subtract/multiply/divide/remainder |
| & ~ v x |AND/NOT/inclusive OR/exclusive OR |
| ->{ }<- |Rotate operand(s) left or right |
| <-> |Exchange operands |
| [ ] |Indirect addressing |
| -[ ] [ ]+ |Autoincrement/decrement indirect address|
| < > < : > |Bit number/bit range |
| <hi> <lo> |High half/low half of value |
| { } { , } |Combination of operands |
| $ |Software trap -[SP]=PC,-[SP]=SR,PC=... |
|---------------------+----------------------------------------|
| 0000H to 0007H |Reset vector (initial SSP and PC) (0-1)|
| 0008H to 000BH |Bus error vector (2)|
| 000CH to 000FH |Address error vector (3)|
| 0010H to 0013H |Illegal instruction vector (4)|
| 0014H to 0017H |Zero divide vector (5)|
| 0018H to 001BH |CHK instruction vector (6)|
| 001CH to 001FH |TRAPV instruction vector (7)|
| 0020H to 0023H |Privilege violation vector (8)|
| 0024H to 0027H |Trace vector (9)|
| 0028H to 002FH |Line 1010/1111 emulator vectors (10-11)|
| 0030H to 003BH |Unassigned (reserved) (12-14)|
| 003CH to 003FH |Uninitialised interrupt vector (15)|
| 0040H to 005FH |Unassigned (reserved) (16-23)|
| 0060H to 0063H |Spurious interrupt vector (24)|
| 0064H to 007FH |Level 1-7 interrupt auto-vectors (25-31)|
| 0080H to 00BFH |TRAP #0-15 instruction vectors (32-47)|
| 00C0H to 00FFH |Unassigned (reserved) (48-63)|
| 0100H to 03FFH |User interrupt vectors (64-255)|
----------------------------------------------------------------
programming/CARDS/6801
+240
View File
@@ -0,0 +1,240 @@
----------------------------------------------------------------
| |
| |
| Motorola |
| |
| 666 88888 000 1 |
| 6 8 8 0 0 11 |
| 6 8 8 0 0 0 1 |
| 666666 88888 0 0 0 1 |
| 6 6 8 8 0 0 0 1 |
| 6 6 8 8 0 0 1 |
| 66666 88888 000 111 |
| |
| 6801/68701 Single-Chip MICROCOMPUTER |
| Instruction Set Summary |
| |
| |
| |
| |
| _________ _________ |
| _| \__/ |_ |
| Vcc |_|1 40|_| E --> |
| _| |_ |
| Vcc Standby |_|2 39|_| SC1 <--> |
| _| |_ |
| --> CC1 |_|3 38|_| SC2 --> |
| _| |_ |
| --> CC2 |_|4 37|_| P30 <--> |
| _____ _| |_ |
| --> Reset |_|5 36|_| P31 <--> |
| ___ _| |_ |
| --> IRQ |_|6 35|_| P32 <--> |
| ___ _| |_ |
| --> NMI |_|7 34|_| P33 <--> |
| _| |_ |
| <--> P10 |_|8 33|_| P34 <--> |
| _| |_ |
| <--> P11 |_|9 32|_| P35 <--> |
| _| |_ |
| <--> P12 |_|10 6801 31|_| P36 <--> |
| _| |_ |
| <--> P13 |_|11 30|_| P37 <--> |
| _| |_ |
| <--> P14 |_|12 29|_| P41 <--> |
| _| |_ |
| <--> P15 |_|13 28|_| P41 <--> |
| _| |_ |
| <--> P16 |_|14 27|_| P42 <--> |
| _| |_ |
| <--> P17 |_|15 26|_| P43 <--> |
| _| |_ |
| <--> P20 |_|16 25|_| P44 <--> |
| _| |_ |
| <--> P21 |_|17 24|_| P45 <--> |
| _| |_ |
| <--> P22 |_|18 23|_| P46 <--> |
| _| |_ |
| <--> P23 |_|19 22|_| P47 <--> |
| _| |_ |
| <--> P24 |_|20 21|_| Vss |
| |______________________| |
| |
| |
| |
| |
| |
| |
|Written by Jonathan Bowen |
| Programming Research Group |
| Oxford University Computing Laboratory |
| 8-11 Keble Road |
| Oxford OX1 3QD |
| England |
| |
| Tel +44-865-273840 |
| |
|Created September 1981 |
|Updated April 1985 |
|Issue 1.5 Copyright (C) J.P.Bowen 1985|
----------------------------------------------------------------
----------------------------------------------------------------
|Mnem. |Op|HINZVC|IEXD#R|Description |Notes |
|------+--+------+------+-------------------------+------------|
|ABA |1B|*-****|X |Add accumulators |A=A+B |
|ABX |3A|------|X |Add registers |X=X+B |
|ADCr s|B9|*-****| XXXX |Add with Carry |r=r+s+C |
|ADDr s|BB|*-****| XXXX |Add |r=r+s |
|ADDD s|F3|--****| XXX* |Add Double accumulator |D=D+s |
|ANDr s|B4|--**0-| XXXX |Logical AND |r=r&s |
|ASL d|78|--****| XX |Arithmetic Shift Left |d=d*2 |
|ASLr |48|--****|X |Arithmetic Shift Left |r=r*2 |
|ASLD |05|--****|X |Arithmetic Shift Left |D=D*2 |
|ASR d|77|--****| XX |Arithmetic Shift Right |d=d/2 |
|ASRr |47|--****|X |Arithmetic Shift Right |r=r/2 |
|BCC a|24|------| X|Branch if Carry Clear |If C=0 |
|BCS a|25|------| X|Branch if Carry Set |If C=1 |
|BEQ a|27|------| X|Branch if Equal |If Z=1 |
|BGE a|2C|------| X|Branch if Greater/Equal |If NxV=0 |
|BGT a|2E|------| X|Branch if Greater Than |If Zv{NxV}=0|
|BHI a|22|------| X|Branch if Higher |If CvZ=0 |
|BHS a|24|------| X|Branch if Higher or Same |If C=0 |
|BITr s|B5|--**0-| XXXX |Bit Test |r&s |
|BLE a|2F|------| X|Branch if Less or Equal |If Zv{NxV}=0|
|BLO a|25|------| X|Branch if Lower |If C=1 |
|BLS a|23|------| X|Branch if Lower or Same |If CvZ=1 |
|BLT a|2D|------| X|Branch if Less Than |If NxV=1 |
|BMI a|2B|------| X|Branch if Minus |If N=1 |
|BNE a|26|------| X|Branch if Not Equal |If Z=0 |
|BPL a|2A|------| X|Branch if Plus |If N=0 |
|BRA a|20|------| X|Branch Always |PC=a |
|BRN a|21|------| X|Branch Never |No op |
|BSR a|8D|------| X|Branch to Subroutine |-[S]=PC,PC=a|
|BVC a|28|------| X|Branch if Overflow Clear |If V=0 |
|BVS a|29|------| X|Branch if Overflow Set |If V=1 |
|CBA |11|--****|X |Compare accumulators |A-B |
|CLC |0C|-----0|X |Clear Carry |C=0 |
|CLI |0E|-0----|X |Clear Interrupt Mask |I=0 |
|CLR d|7F|--0100| XX |Clear |d=0 |
|CLRr |4F|--0100|X |Clear accumulator |r=0 |
|CLV |0A|----0-|X |Clear Overflow |V=0 |
|CMPr s|B1|--****| XXXX |Compare |r-s |
|COM d|63|--**01| XX |Complement |d=~d |
|COMr |43|--**01|X |Complement accumulator |r=~r |
|CPX s|BC|--****| XXX* |Compare Index Register |X-s |
|DAA |19|--****|X |Decimal Adjust Acc. |A=BCD format|
|DEC d|7A|--**?-| XX |Decrement |d=d-1 |
|DECr |4A|--**?-|X |Decrement accumulator |r=r-1 |
|DES |34|------|X |Decrement Stack Pointer |S=S-1 |
|DEX |09|---*--|X |Decrement Index Register |X=X-1 |
|EORr s|B8|--**0-| XXXX |Logical Exclusive OR |r=rxs |
|INC d|7C|--**?-| XX |Increment |d=d+1 |
|INCr |4C|--**?-|X |Increment accumulator |r=r+1 |
|INS |31|------|X |Increment Stack Pointer |S=S+1 |
|INX |08|---*--|X |Increment Index Register |X=X+1 |
|JMP d|7E|------| XX |Jump |PC=d |
|JSR d|BD|------| XX |Jump to Subroutine |-[S]=PC,PC=d|
|LDAr s|B6|--**0-| XXXX |Load Accumulator |r=s |
|LDD s|FC|--**0-| XXX* |Load Double accumulator |D=s |
|LDS s|BE|--**0-| XXX* |Load Stack Pointer |S=s |
|LDX s|FE|--**0-| XXX* |Load Index Register |X=s |
|LSR d|74|--0***| XX |Logical Shift Right |d=->{0,d,C} |
|LSRr |44|--0***|X |Logical Shift Right |r=->{0,r,C} |
|LSRD |04|--0***|X |Logical Shift Right |D=->{0,D,C} |
|MUL |3D|-----*|X |Multiply |D=A*B |
|NEG d|70|--****| XX |Negate |d=-d |
|NEGr |40|--****|X |Negate accumulator |r=-r |
|NOP |01|------|X |No Operation | |
|ORAr s|BA|--**0-| XXXX |Logical inclusive OR |r=rvs |
|PSHA |36|------|X |Push |-[S]=A |
|PSHB |37|------|X |Push |-[S]=B |
|PSHX |3C|------|X |Push Index Register |-[S]=X |
|PULA |32|------|X |Pull |A=[S]+ |
|PULB |33|------|X |Pull |B=[S]+ |
|PULX |38|------|X |Pull Index Register |X=[S]+ |
|ROL d|79|--**?*| XX |Rotate Left |d={C,d}<- |
|ROLr |49|--**?*|X |Rotate Left accumulator |r={C,r}<- |
|ROR d|76|--**?*| XX |Rotate Right |d=->{C,d} |
|RORr |46|--**?*|X |Rotate Right accumulator |r=->{C,r} |
|RTI |3B|??????|X |Return from Interrupt |{regs}=[S]+ |
----------------------------------------------------------------
----------------------------------------------------------------
|Mnem. |Op|HINZVC|IEXD#R|Description |Notes |
|------+--+------+------+-+-----------------------+------------|
|RTS |39|------|X |Return from Subroutine |PC=[S]+ |
|SBA |10|--****|X |Subtract accumulators |A=A-B |
|SBCr s|B2|--****| XXXX |Subtract with Carry |r=r-s-C |
|SEC |0D|-----1|X |Set Carry |C=1 |
|SEI |0F|-1----|X |Set Interrupt Mask |I=1 |
|SEV |0B|----1-|X |Set Overflow |V=1 |
|STAr d|B7|--**0-| XXX |Store Accumulator |d=r |
|STD d|FD|--**0-| XXX |Store Double accumulator |D=r |
|STS d|BF|--**0-| XXX |Store Stack Pointer |d=S |
|STX d|FF|--**0-| XXX |Store Index Register |d=X |
|SUBr s|B0|--****| XXXX |Subtract |r=r-s |
|SUBD s|B3|--****| XXX* |Subtract Double acc. |D=D-s |
|SWI |3F|-1----|X |Software Interrupt |-[S]={regs} |
|TAB |17|--**0-|X |Transfer accumulators |B=A |
|TAP |06|******|X |Transfer to CCR |P=A |
|TBA |17|--**0-|X |Transfer accumulators |A=B |
|TPA |07|------|X |Transfer from CCR |A=P |
|TST s|7D|--**00| XX |Test |s |
|TSTr |4D|--**00|X |Test accumulator |r |
|TSX |30|------|X |Transfer Stack Pointer |X=S |
|TXS |35|------|X |Transfer Index Register |S=X |
|WAI |3E|-*----|X |Wait for Interrupt |-[S]={regs} |
|---------+------+------+--------------------------------------|
| CCR |-*01? | |Unaffected/affected/reset/set/unknown |
| H |H | |Half carry (Bit 5) |
| I | I | |Interrupt mask (Bit 4) |
| N | N | |Negative (Bit 3) |
| Z | Z | |Zero (Bit 2) |
| V | V | |Overflow (Bit 1) |
| C | C| |Carry (Bit 0) |
|----------------+------+--------------------------------------|
| r |I |Inherent (A:Op=4XH/BXH, B:Op=5XH/FXH) |
| nn,E | E |Extended (Op=E, ~s=e) |
| nn,X | X |Index (Op=E-10H, ~s=e+1, JSR ~s=e-1) |
| n,D | D |Direct (Op=E-20H, ~s=e-1) |
| #n | # |Immediate (8-bit, Op=E-30H, ~s=e-2) |
| #nn | * |Immediate (16-bit, Op=E-30H, ~s=e-2) |
| a | R|Relative (PC=PC+2+offset) |
| r | |Inherent (r=A,Op=BXH, r=B,Op=FXH) |
|-----------------------+--------------------------------------|
|DIRECT |Direct addressing mode |
|EXTEND |Extended addressing mode |
|FCB n |Form Constant Byte |
|FCC 'string' |Form Constant Characters |
|FDB nn |Form Double Byte |
|RMB nn |Reserve Memory Bytes |
|-----------------------+--------------------------------------|
| A B |Accumulators (8-bit, r=A/B,Op=BXH/FXH)|
| D |A and B combined (16-bit, A hi, B lo) |
| P |Condition Code Register (8-bit, CCR) |
| PC |Program Counter (16-bit) |
| S |Stack Pointer (16-bit) |
| X |Index Register (16-bit) |
|-----------------------+--------------------------------------|
| a |Relative address (-125 to +129) |
| d s |Destination/source |
| n nn |8/16-bit expression (0 to 255/65535) |
| r |Accumulator register A or B |
| + - * / |Add/subtract/multiply/divide |
| & ~ v x |AND/NOT/inclusive OR/exclusive OR |
| <- -> |Rotate left/right |
| [ ] [ ]+ -[ ] |Indirect address/increment/decrement |
| { } {regs} |Combination of operands/{PC,X,A,B,P} |
|-----------------------+--------------------------------------|
| 0000H to 001FH |Internal registers |
| 0080H to 00FFH |128 bytes of internal RAM |
| F800H to FFFFH |2K bytes of internal ROM/EPROM |
| FFF0H to FFFFH |Interrupt vectors |
| FFF0H to FFF1H |IRQ2 serial I/O interrupt vector |
| FFF2H to FFF3H |IRQ2 timer overflow vector |
| FFF4H to FFF5H |IRQ2 timer output compare vector |
| FFF6H to FFF7H |IRQ2 timer input capture vector |
| FFF8H to FFF9H |IRQ1 interrupt strobe 3 vector |
| FFFAH to FFFBH |SWI instruction interrupt vector |
| FFFCH to FFFDH |Non-maskable interrupt vector |
| FFFEH to FFFFH |Reset vector |
----------------------------------------------------------------
programming/CARDS/68010
+240
View File
@@ -0,0 +1,240 @@
----------------------------------------------------------------
| |
| |
| Motorola |
| |
| 666 88888 000 1 000 |
| 6 8 8 0 0 11 0 0 |
| 6 8 8 0 0 0 1 0 0 0 |
| 666666 88888 0 0 0 1 0 0 0 |
| 6 6 8 8 0 0 0 1 0 0 0 |
| 6 6 8 8 0 0 1 0 0 |
| 66666 88888 000 111 000 |
| |
| 68010 MICROPROCESSOR Instruction Set Summary |
| |
| |
| |
| |
| |
| |
| |
| |
| _________ _________ |
| | \__/ | |
| <--> D4 -|1 64|- D5 <--> |
| <--> D3 -|2 63|- D6 <--> |
| <--> D2 -|3 62|- D7 <--> |
| <--> D1 -|4 61|- D8 <--> |
| <--> D0 -|5 60|- D9 <--> |
| <-- ~AS -|6 59|- D10 <--> |
| <-- ~UDS -|7 58|- D11 <--> |
| <-- ~LDS -|8 57|- D12 <--> |
| <-- R/~W -|9 56|- D13 <--> |
| --> ~DTACK -|10 55|- D14 <--> |
| <-- ~BG -|11 54|- D15 <--> |
| --> ~BGACK -|12 53|- GND |
| --> ~BR -|13 52|- A23 --> |
| Vcc -|14 51|- A22 --> |
| --> CLK -|15 50|- A21 --> |
| GND -|16 68010 49|- Vcc |
| <--> ~HALT -|17 48|- A20 --> |
| <--> ~RESET -|18 47|- A19 --> |
| <-- ~VMA -|19 46|- A18 --> |
| <-- E -|20 45|- A17 --> |
| --> ~VPA -|21 44|- A16 --> |
| --> ~BERR -|22 43|- A15 --> |
| --> ~IPL2 -|23 42|- A14 --> |
| --> ~IPL1 -|24 41|- A13 --> |
| --> ~IPL0 -|25 40|- A12 --> |
| <-- FC2 -|26 39|- A11 --> |
| <-- FC1 -|27 38|- A10 --> |
| <-- FC0 -|28 37|- A9 --> |
| <-- A1 -|29 36|- A8 --> |
| <-- A2 -|30 35|- A7 --> |
| <-- A3 -|31 34|- A6 --> |
| <-- A4 -|32 33|- A5 --> |
| |______________________| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
|Written by Jonathan Bowen |
| Programming Research Group |
| Oxford University Computing Laboratory |
| 8-11 Keble Road |
| Oxford OX1 3QD |
| England |
| |
| Tel +44-865-273840 |
| |
|Created November 1984 |
|Updated April 1985 |
|Issue 1.1 Copyright (C) J.P.Bowen 1985|
----------------------------------------------------------------
----------------------------------------------------------------
|Mnemonic |XNZVC|BWL|Description |Notes |
|-----------+-----+---+----------------------+-----------------|
|ABCD s,d |*?*?*|X |Add BCD format |d=BCD{d+s+X} |
|ADD s,d |*****|XXX|Add binary |d=d+s |
|ADDA s,An |-----| XX|Add Address |An=An+s |
|ADDI #e,d |*****|XXX|Add Immediate |d=d+e |
|ADDQ #q,d |*****|XXX|Add Quick |d=d+q |
|ADDX s,d |*****|XXX|Add Extended |d=d+s+X |
|AND s,d |-**00|XXX|Logical AND |d=d&s |
|ANDI #e,d |-**00|XXX|Logical AND Immediate |d=d&e |
|ASlr d |*****|XXX|Arithmetic Shift |d=d*2 or d=d/2 |
|Bcc l |-----|XX |Branch conditionally |If cc BRA |
|BCHG s,d |--*--| XX|Bit test and Change |BTST,d<s>=Z |
|BCLR d |--*--| XX|Bit test and Clear |BTST,d<s>=0 |
|BRA l |-----|XX |Branch Always |PC=l |
|BSET d |--*--| XX|Bit test and Set |BTST,d<s>=1 |
|BSR l |-----|XX |Branch to Subroutine |-[SP]=PC,PC=l |
|BTST d |--*--| XX|Bit Test |Z=~d<s> |
|CHK s,Dn |-*???| X |Check register |If 0>Dn>s $[18H] |
|CLR d |-0100|XXX|Clear operand |d=0 |
|CMP s,Dn |-****|XXX|Compare |Dn-s |
|CMPA s,An |-****|XXX|Compare Address |An-s |
|CMPI #e,d |-****|XXX|Compare Immediate |d-e |
|CMPM s,d |-****|XXX|Compare Memory |d-s |
|DBcc Dn,l |-----| |Decrement and Branch |If~cc&Dn-1~-1 BRA|
|DIVS s,Dn |-***0| X |Signed Division |Dn={Dn%s,Dn/s} |
|DIVU s,Dn |-***0| X |Unsigned Division |Dn={Dn%s,Dn/s} |
|EOR Dn,d |-**00|XXX|Exclusive OR |d=dxDn |
|EORI #e,d |-**00|XXX|Exclusive OR Immediate|d=dxe |
|EXG r,r |-----| X|Exchange registers |r<->r |
|EXT Dn |-**00| XX|Extend sign |Dn<hi>=Dn<7or15> |
|JMP d |-----| |Jump |PC=d |
|JSR d |-----| |Jump to Subroutine |-[SP]=PC,PC=d |
|LEA s,An |-----| X|Load Effective Address|An=EA{s} |
|LINK An,#nn|-----| |Link and allocate |-[SP]=An=SP=SP+nn|
|LSlr d |***0*|XXX|Logical Shift |d=->{C,d,0}<- |
|MOVE s,d |-**00|XXX|Move data |d=s |
|MOVE s,cs |*****|XX |Move to status reg |cs=s |
|MOVE cs,d |-----|XX |Move from status reg |d=cs |
|MOVE USP,An|-----| X|Move User SP |USP=An or An=USP |
|MOVEA s,An |-----| XX|Move Address |An=s |
|MOVEC Cr,An|-----| X|Move Control register |Cr=An or An=Cr |
|MOVEM s,d |-----| XX|Move Multiple register|rr=s or d=rr |
|MOVEP s,d |-----| XX|Move Peripheral data |d=Dn or Dn=s |
|MOVEQ #q,d |-**00| X|Move Quick |d=q |
|MOVES s,d |-----| X|Move alternate Space |d=An or An=s |
|MULS s,Dn |-**00| X |Signed Multiply |Dn<0:31>=Dn*s |
|MULU s,Dn |-**00| X |Unsigned Multiply |Dn<0:31>=Dn*s |
|NBCD d |*?*?*|X |Negate BCD format |d=BCD{-d-X} |
|NEG d |*****|XXX|Negate |d=-d |
|NEGX d |*****|XXX|Negate with Extend |d=-d-X |
|NOP |-----| |No Operation | |
|NOT d |-**00|XXX|Logical NOT |d=~d |
|OR s,d |-**00|XXX|Inclusive OR |d=dvs |
|ORI #e,d |-**00|XXX|Inclusive OR Immediate|d=dve |
|PEA s |-----| X|Push Effective Address|-[SP]=EA{s} |
|RESET |-----| |Reset external devices|Reset line=0 |
|ROlr d |-**0*|XXX|Rotate |d=->{d}<- |
|ROXlr d |***0*|XXX|Rotate with Extend |d=->{d}<-,X=C |
|RTE |*****| |Return from Exception |SR=[SSP]+,RTS |
|RTR |*****| |Return and Restore |SR<0:4>=[SP]+,RTS|
|RTS |-----| |Return from Subroutine|PC=[SP]+ |
|SBCD s,d |*?*?*|X |Subtract BCD format |d=BCD{d-s-X} |
|Scc d |-----|X |Set conditionally |d=0 or d=-1 |
|STOP #nn |*****| |Load status and Stop |SR=nn, wait |
|SUB s,d |*****|XXX|Subtract binary |d=d-s |
|SUBA s,An |-----| XX|Subtract Address |An=An-s |
|SUBI #e,d |*****|XXX|Subtract Immediate |d=d-e |
|SUBQ #q,d |*****|XXX|Subtract Quick |d=d-q |
|SUBX s,d |*****|XXX|Subtract with Extend |d=d-s-X |
|SWAP Dn |-**00| X |Swap register halves |Dn<hi><->Dn<lo> |
|TAS d |-**00|X |Test And Set |d<7>=1 |
|TRAP #n |-----| |Trap (n=0-15)|$[80H+4*n] |
|TRAPV |-----| |Trap on Overflow |If V=1 $[1CH] |
|TST d |-**00|XXX|Test |d |
|UNLK An |-----| |Unlink |SP=An,An=[SP]+ |
|DC e(,...) |?????|XXX|Define Constant |**NOT an opcode**|
|DS e |?????|XXX|Define Storage |**NOT an opcode**|
----------------------------------------------------------------
----------------------------------------------------------------
|Mnemonic |XNZVC|BWL|Description |
|-----------+-----+---+----------------------------------------|
| CCR |-*01?| |Unaffected/affected/reset/set/unknown |
| T | | |Trace mode flag (Bit 15) |
| S | | |Supervisor/user mode select (Bit 13) |
| In | | |Interrupt mask flag #n (Bits 8-10,n=0-2)|
| X |X | |Extend flag (Bit 4) |
| N | N | |Negative flag (Bit 3) |
| Z | Z | |Zero flag (Bit 2) |
| V | V | |Overflow flag (Bit 1) |
| C | C| |Carry flag (Bit 0) |
|-----------------+---+----------------------------------------|
| .B |X |Byte attribute (8-bit, .S for branch) |
| .W | X |Word attribute (16-bit) |
| .L | X|Long word attribute (32-bit) |
|---------------------+----------------------------------------|
| Dn |Data register direct addressing |
| An |Address register direct addressing |
| [An] |Register indirect addressing |
| [An]+ |Post-increment register indirect addr. |
| -[An] |Pre-decrement register indirect addr. |
| n[An] |Offset register indirect addressing |
| n[An,r] |Index register indirect addressing |
| nn |Short absolute data addressing |
| nnnn |Long absolute data addressing |
| nn |Program counter relative addressing |
| nn[r] |Program counter with index addressing |
| #e |Immediate data addressing |
|---------------------+----------------------------------------|
| An |Address register (16/32-bit, n=0-7) |
| CCR |Condition Code Register (8-bit, low SR) |
| Dn |Data register (8/16/32-bit, n=0-7) |
| PC |Program Counter (24-bit) |
| SFC DFC |Alternative Function Code regs (3-bits) |
| SP |Active Stack Pointer (equivalent to A7) |
| SR |Status Register (16-bit) |
| SSP |Supervisor Stack Pointer (32-bit) |
| USP |User Stack Pointer (32-bit) |
| VBR |Vector Base Register (32-bit) |
|---------------------+----------------------------------------|
| BCD{ } EA{ } |Binary Coded Decimal/Effective Address |
| cc |Condition = (T/F/HI/LS/CC/CS/NE/EQ/ |
| | VC/VS/PL/MI/GE/LT/GT/LE) |
| cs |Register CCR or SR |
| d s |Destination/source |
| e n nn nnnn |Any/8-bit/16-bit/32-bit expression |
| l |Branch displacement label (8/16-bit) |
| lr |Left/right direction = (L/R) |
| q |Quick expression (1-8) |
| r |Any register An or Dn |
| rr |Multiple registers (-=range,/=separator)|
| + - * / % |Add/subtract/multiply/divide/remainder |
| & ~ v x |AND/NOT/inclusive OR/exclusive OR |
| ->{ }<- <-> |Rotate left or right/exchange operands |
| [ ] -[ ] [ ]+ |Indirect/autoincrement/autodecr. address|
| < > <:> <hi> <lo>|Bit number/bit range/high half/low half |
| { } {,} |Combination of operands |
| $ |Software trap -[SP]=PC,-[SP]=SR,PC=... |
|---------------------+----------------------------------------|
| 0000H to 0007H |Reset vector (initial SSP and PC) (0-1)|
| 0008H to 000BH |Bus error vector (2)|
| 000CH to 000FH |Address error vector (3)|
| 0010H to 0013H |Illegal instruction vector (4)|
| 0014H to 0017H |Zero divide vector (5)|
| 0018H to 001BH |CHK instruction vector (6)|
| 001CH to 001FH |TRAPV instruction vector (7)|
| 0020H to 0023H |Privilege violation vector (8)|
| 0024H to 0027H |Trace vector (9)|
| 0028H to 002FH |Line 1010/1111 emulator vectors (10-11)|
| 0030H to 0037H |Unassigned (reserved) (12-13)|
| 0038H to 003BH |Format error vector (14)|
| 003CH to 003FH |Uninitialised interrupt vector (15)|
| 0040H to 005FH |Unassigned (reserved) (16-23)|
| 0060H to 0063H |Spurious interrupt vector (24)|
| 0064H to 007FH |Level 1-7 interrupt auto-vectors (25-31)|
| 0080H to 00BFH |TRAP #0-15 instruction vectors (32-47)|
| 00C0H to 00FFH |Unassigned (reserved) (48-63)|
| 0100H to 03FFH |User interrupt vectors (64-255)|
----------------------------------------------------------------
programming/CARDS/6802
+240
View File
@@ -0,0 +1,240 @@
----------------------------------------------------------------
| |
| |
| Motorola |
| |
| 666 88888 000 22222 |
| 6 8 8 0 0 2 2 |
| 6 8 8 0 0 0 2 |
| 666666 88888 0 0 0 222 |
| 6 6 8 8 0 0 0 2 |
| 6 6 8 8 0 0 2 |
| 66666 88888 000 2222222 |
| |
| 6802 MICROPROCESSOR Instruction Set Summary |
| |
| |
| |
| |
| |
| _________ _________ |
| _| \__/ |_ _____ |
| Vss |_|1 40|_| Reset <-- |
| ____ _| |_ |
| --> Halt |_|2 39|_| XTAL <-- |
| _| |_ |
| --> MR |_|3 38|_| EXTAL <-- |
| ___ _| |_ |
| --> IRQ |_|4 37|_| E --> |
| _| |_ |
| <-- VMA |_|5 36|_| RE <-- |
| ___ _| |_ |
| --> NMI |_|6 35|_| Vcc Standby |
| _| |_ _ |
| <-- BA |_|7 34|_| R/W --> |
| _| |_ |
| Vcc |_|8 33|_| D0 <--> |
| _| |_ |
| <-- A0 |_|9 32|_| D1 <--> |
| _| |_ |
| <-- A1 |_|10 6802 31|_| D2 <--> |
| _| |_ |
| <-- A2 |_|11 30|_| D3 <--> |
| _| |_ |
| <-- A3 |_|12 29|_| D4 <--> |
| _| |_ |
| <-- A4 |_|13 28|_| D5 <--> |
| _| |_ |
| <-- A5 |_|14 27|_| D6 <--> |
| _| |_ |
| <-- A6 |_|15 26|_| D7 <--> |
| _| |_ |
| <-- A7 |_|16 25|_| A15 --> |
| _| |_ |
| <-- A8 |_|17 24|_| A14 --> |
| _| |_ |
| <-- A9 |_|18 23|_| A13 --> |
| _| |_ |
| <-- A10 |_|19 22|_| A12 --> |
| _| |_ |
| <-- A11 |_|20 21|_| Vss |
| |______________________| |
| |
| |
| |
| |
| |
| |
|Written by Jonathan Bowen |
| Programming Research Group |
| Oxford University Computing Laboratory |
| 8-11 Keble Road |
| Oxford OX1 3QD |
| England |
| |
| Tel +44-865-273840 |
| |
|Created August 1981 |
|Updated April 1985 |
|Issue 1.4 Copyright (C) J.P.Bowen 1985|
----------------------------------------------------------------
----------------------------------------------------------------
|Mnem. |Op|HINZVC|IEXD#R|~|Description |Notes |
|------+--+------+------+-+-----------------------+------------|
|ABA |1B|*-****|X |2|Add accumulators |A=A+B |
|ADCA s|B9|*-****| XXXX |4|Add with Carry |A=A+s+C |
|ADCB s|F9|*-****| XXXX |4|Add with Carry |B=B+s+C |
|ADDA s|BB|*-****| XXXX |4|Add |A=A+s |
|ADDB s|FB|*-****| XXXX |4|Add |B=B+s |
|ANDA s|B4|--**0-| XXXX |4|Logical AND |A=A&s |
|ANDB s|F4|--**0-| XXXX |4|Logical AND |B=B&s |
|ASL d|78|--****| XX |6|Arithmetic Shift Left |d=d*2 |
|ASLA |48|--****|X |2|Arithmetic Shift Left |A=A*2 |
|ASLB |58|--****|X |2|Arithmetic Shift Left |B=B*2 |
|ASR d|77|--****| XX |6|Arithmetic Shift Right |d=d/2 |
|ASRA |47|--****|X |2|Arithmetic Shift Right |A=A/2 |
|ASRB |57|--****|X |2|Arithmetic Shift Right |B=B/2 |
|BCC a|24|------| X|4|Branch if Carry Clear |If C=0 |
|BCS a|25|------| X|4|Branch if Carry Set |If C=1 |
|BEQ a|27|------| X|4|Branch if Equal |If Z=1 |
|BGE a|2C|------| X|4|Branch if Greater or Eq|If NxV=0 |
|BGT a|2E|------| X|4|Branch if Greater Than |If Zv{NxV}=0|
|BHI a|22|------| X|4|Branch if Higher |If CvZ=0 |
|BITA s|B5|--**0-| XXXX |4|Bit Test |A&s |
|BITB s|F5|--**0-| XXXX |4|Bit Test |B&s |
|BLE a|2F|------| X|4|Branch if Less or Equal|If Zv{NxV}=0|
|BLS a|23|------| X|4|Branch if Lower or Same|If CvZ=1 |
|BLT a|2D|------| X|4|Branch if Less Than |If NxV=1 |
|BMI a|2B|------| X|4|Branch if Minus |If N=1 |
|BNE a|26|------| X|4|Branch if Not Equal |If Z=0 |
|BPL a|2A|------| X|4|Branch if Plus |If N=0 |
|BRA a|20|------| X|4|Branch Always |PC=a |
|BSR a|8D|------| X|8|Branch to Subroutine |-[S]=PC,PC,a|
|BVC a|28|------| X|4|Branch if Overflow Clr |If V=0 |
|BVS a|29|------| X|4|Branch if Overflow Set |If V=1 |
|CBA |11|--****|X |2|Compare accumulators |A-B |
|CLC |0C|-----0|X |2|Clear Carry |C=0 |
|CLI |0E|-0----|X |2|Clear Interrupt Mask |I=0 |
|CLR d|7F|--0100| XX |6|Clear |d=0 |
|CLRA |4F|--0100|X |2|Clear accumulator |A=0 |
|CLRB |5F|--0100|X |2|Clear accumulator |B=0 |
|CLV |0A|----0-|X |2|Clear Overflow |V=0 |
|CMPA s|B1|--****| XXXX |4|Compare |A-s |
|CMPB s|F1|--****| XXXX |4|Compare |B-s |
|COM d|63|--**01| XX |7|Complement |d=~d |
|COMA |43|--**01|X |2|Complement accumulator |A=~A |
|COMB |53|--**01|X |2|Complement accumulator |B=~B |
|CPX s|BC|--****| XXX* |5|Compare Index Register |X-s |
|DAA |19|--****|X |2|Decimal Adjust Acc. |A=BCD format|
|DEC d|7A|--**?-| XX |6|Decrement |d=d-1 |
|DECA |4A|--**?-|X |2|Decrement accumulator |A=A-1 |
|DECB |5A|--**?-|X |2|Decrement accumulator |B=B-1 |
|DES |34|------|X |4|Decrement Stack Pointer|S=S-1 |
|DEX |09|---*--|X |4|Decrement Index Reg |X=X-1 |
|EORA s|B8|--**0-| XXXX |4|Logical Exclusive OR |A=Axs |
|EORB s|F8|--**0-| XXXX |4|Logical Exclusive OR |B=Bxs |
|INC d|7C|--**?-| XX |6|Increment |d=d+1 |
|INCA |4C|--**?-|X |2|Increment accumulator |A=A+1 |
|INCB |5C|--**?-|X |2|Increment accumulator |B=B+1 |
|INS |31|------|X |4|Increment Stack Pointer|S=S+1 |
|INX |08|---*--|X |4|Increment Index Reg |X=X+1 |
|JMP d|7E|------| XX |3|Jump |PC=d |
|JSR d|BD|------| XX |9|Jump to Subroutine |-[S]=PC,PC=d|
|LDAA s|B6|--**0-| XXXX |4|Load Accumulator |A=s |
|LDAB s|F6|--**0-| XXXX |4|Load Accumulator |B=s |
|LDS s|BE|--**0-| XXX* |5|Load Stack Pointer |S=s |
|LDX s|FE|--**0-| XXX* |5|Load Index Register |X=s |
|LSR d|74|--0***| XX |6|Logical Shift Right |d=->{0,d,C} |
|LSRA |44|--0***|X |2|Logical Shift Right |A=->{0,A,C} |
|LSRB |54|--0***|X |2|Logical Shift Right |B=->{0,B,C} |
|NEG d|70|--****| XX |6|Negate |d=-d |
|NEGA |40|--****|X |2|Negate accumulator |A=-A |
|NEGB |50|--****|X |2|Negate accumulator |B=-B |
|NOP |01|------|X |2|No Operation | |
|ORAA s|BA|--**0-| XXXX |4|Logical inclusive OR |A=Avs |
|ORAB s|FA|--**0-| XXXX |4|Logical inclusive OR |B=Bvs |
|PSHA |36|------|X |4|Push |-[S]=A |
|PSHB |37|------|X |4|Push |-[S]=B |
|PULA |32|------|X |4|Pull |A=[S]+ |
|PULB |33|------|X |4|Pull |B=[S]+ |
----------------------------------------------------------------
----------------------------------------------------------------
|Mnem. |Op|HINZVC|IEXD#R|~|Description |Notes |
|------+--+------+------+-+-----------------------+------------|
|ROL d|79|--**?*| XX |6|Rotate Left |d={C,d}<- |
|ROLA |49|--**?*|X |2|Rotate Left accumulator|A={C,A}<- |
|ROLB |59|--**?*|X |2|Rotate Left accumulator|B={C,B}<- |
|ROR d|76|--**?*| XX |6|Rotate Right |d=->{C,d} |
|RORA |46|--**?*|X |2|Rotate Right acc. |A=->{C,A} |
|RORB |56|--**?*|X |2|Rotate Right acc. |B=->{C,B} |
|RTI |3B|??????|X |A|Return from Interrupt |{regs}=[S]+ |
|RTS |39|------|X |5|Return from Subroutine |PC=[S]+ |
|SBA |10|--****|X |2|Subtract accumulators |A=A-B |
|SBCA s|B2|--****| XXXX |4|Subtract with Carry |A=A-s-C |
|SBCB s|F2|--****| XXXX |4|Subtract with Carry |B=B-s-C |
|SEC |0D|-----1|X |2|Set Carry |C=1 |
|SEI |0F|-1----|X |2|Set Interrupt Mask |I=1 |
|SEV |0B|----1-|X |2|Set Overflow |V=1 |
|STAA d|B7|--**0-| XXX |5|Store Accumulator |d=A |
|STAB d|F7|--**0-| XXX |5|Store Accumulator |d=B |
|STS d|BF|--**0-| XXX |6|Store Stack Pointer |d=S |
|STX d|FF|--**0-| XXX |6|Store Index Register |d=X |
|SUBA s|B0|--****| XXXX |4|Subtract |A=A-s |
|SUBB s|F0|--****| XXXX |4|Subtract |B=B-s |
|SWI |3F|-1----|X |C|Software Interrupt |-[S]={regs} |
|TAB |17|--**0-|X |2|Transfer accumulators |B=A |
|TAP |06|******|X |2|Transfer to CCR |P=A |
|TBA |17|--**0-|X |2|Transfer accumulators |A=B |
|TPA |07|------|X |2|Transfer from CCR |A=P |
|TST s|7D|--**00| XX |6|Test |s |
|TSTA |4D|--**00|X |2|Test accumulator |A |
|TSTB |5D|--**00|X |2|Test accumulator |B |
|TSX |30|------|X |4|Transfer Stack Pointer |X=S |
|TXS |35|------|X |4|Transfer Index Register|S=X |
|WAI |3E|-*----|X |9|Wait for Interrupt |-[S]={regs} |
|---------+------+------+-+------------------------------------|
| CCR |-*01? | | |Unaffect/affected/reset/set/unknown |
| H |H | | |Half carry (Bit 5) |
| I | I | | |Interrupt mask (Bit 4) |
| N | N | | |Negative (Bit 3) |
| Z | Z | | |Zero (Bit 2) |
| V | V | | |Overflow (Bit 1) |
| C | C| | |Carry (Bit 0) |
|----------------+------+-+------------------------------------|
| |I | |Inherent |
| nn,E | E | |Extended (Op=E, ~s=e) |
| nn,X | X | |Index (Op=E-10H, ~s=e+1, JSR ~s=e-1)|
| n,D | D | |Direct (Op=E-20H, ~s=e-1) |
| #n | # | |Immediate (8-bit, Op=E-30H, ~s=e-2) |
| #nn | * | |Immediate (16-bit, Op=E-30H, ~s=e-2)|
| a | R| |Relative (PC=PC+2+offset) |
|-------------------------+------------------------------------|
|DIRECT |Direct addressing mode |
|EXTEND |Extended addressing mode |
|FCB n |Form Constant Byte |
|FCC 'string' |Form Constant Characters |
|FDB nn |Form Double Byte |
|RMB nn |Reserve Memory Bytes |
|-------------------------+------------------------------------|
| A B |Accumulators (8-bit) |
| P |Condition Code Register (CCR, 8-bit)|
| PC |Program Counter (16-bit) |
| S |Stack Pointer (16-bit) |
| X |Index Register (16-bit) |
|-------------------------+------------------------------------|
| a |Relative address (-125 to +129) |
| d s |Destination/source |
| n nn |8/16-bit expression (0 to 255/65535)|
| + - * / |Add/subtract/multiply/divide |
| & ~ v x |AND/NOT/inclusive OR/exclusive OR |
| <- -> |Rotate left/right |
| [ ] [ ]+ -[ ] |Indirect address/increment/decrement|
| { } {regs} |Combined operands/{PC,X,A,B,P} |
|-------------------------+------------------------------------|
| 0000H to 007FH |128 bytes of on-chip RAM |
| 0000H to 001FH |32 bytes of RAM using Vcc standby |
| FFF8H to FFF9H |Hardware interrupt vector |
| FFFAH to FFFBH |SWI instruction interrupt vector |
| FFFCH to FFFDH |Non-maskable interrupt vector |
| FFFEH to FFFFH |Reset vector |
----------------------------------------------------------------
programming/CARDS/6803
+240
View File
@@ -0,0 +1,240 @@
----------------------------------------------------------------
| |
| |
| Motorola |
| |
| 666 88888 000 33333 |
| 6 8 8 0 0 3 3 |
| 6 8 8 0 0 0 3 |
| 666666 88888 0 0 0 33333 |
| 6 6 8 8 0 0 0 3 |
| 6 6 8 8 0 0 3 3 |
| 66666 88888 000 33333 |
| |
| 6803/6803NR Single-Chip MICROCOMPUTER |
| Instruction Set Summary |
| |
| |
| |
| |
| _________ _________ |
| _| \__/ |_ |
| Vss |_|1 40|_| E --> |
| _| |_ |
| --> XTAL1 |_|2 39|_| AS |
| _| |_ _ |
| --> EXTAL2 |_|3 38|_| R/W --> |
| ___ _| |_ |
| --> NMI |_|4 37|_| D0/A0 <--> |
| ___ _| |_ |
| --> IRQ1 |_|5 36|_| D1/A1 <--> |
| _| |_ |
| --> Reset |_|6 35|_| D2/A2 <--> |
| _| |_ |
| Vcc |_|7 34|_| D3/A3 <--> |
| _| |_ |
| <--> P20 |_|8 33|_| D4/A4 <--> |
| _| |_ |
| <--> P21 |_|9 32|_| D5/A5 <--> |
| _| |_ |
| <--> P22 |_|10 6803 31|_| D6/A6 <--> |
| _| |_ |
| <--> P23 |_|11 30|_| D7/A7 <--> |
| _| |_ |
| <--> P24 |_|12 29|_| A8 --> |
| _| |_ |
| <--> P10 |_|13 28|_| A9 --> |
| _| |_ |
| <--> P11 |_|14 27|_| A10 --> |
| _| |_ |
| <--> P12 |_|15 26|_| A11 --> |
| _| |_ |
| <--> P13 |_|16 25|_| A12 --> |
| _| |_ |
| <--> P14 |_|17 24|_| A13 --> |
| _| |_ |
| <--> P15 |_|18 23|_| A14 --> |
| _| |_ |
| <--> P16 |_|19 22|_| A15 --> |
| _| |_ |
| <--> P17 |_|20 21|_| Vcc Standby |
| |______________________| |
| |
| |
| |
| |
| |
| |
|Written by Jonathan Bowen |
| Programming Research Group |
| Oxford University Computing Laboratory |
| 8-11 Keble Road |
| Oxford OX1 3QD |
| England |
| |
| Tel +44-865-273840 |
| |
|Created September 1981 |
|Updated April 1985 |
|Issue 1.5 Copyright (C) J.P.Bowen 1985|
----------------------------------------------------------------
----------------------------------------------------------------
|Mnem. |Op|HINZVC|IEXD#R|Description |Notes |
|------+--+------+------+-------------------------+------------|
|ABA |1B|*-****|X |Add accumulators |A=A+B |
|ABX |3A|------|X |Add registers |X=X+B |
|ADCr s|B9|*-****| XXXX |Add with Carry |r=r+s+C |
|ADDr s|BB|*-****| XXXX |Add |r=r+s |
|ADDD s|F3|--****| XXX* |Add Double accumulator |D=D+s |
|ANDr s|B4|--**0-| XXXX |Logical AND |r=r&s |
|ASL d|78|--****| XX |Arithmetic Shift Left |d=d*2 |
|ASLr |48|--****|X |Arithmetic Shift Left |r=r*2 |
|ASLD |05|--****|X |Arithmetic Shift Left |D=D*2 |
|ASR d|77|--****| XX |Arithmetic Shift Right |d=d/2 |
|ASRr |47|--****|X |Arithmetic Shift Right |r=r/2 |
|BCC a|24|------| X|Branch if Carry Clear |If C=0 |
|BCS a|25|------| X|Branch if Carry Set |If C=1 |
|BEQ a|27|------| X|Branch if Equal |If Z=1 |
|BGE a|2C|------| X|Branch if Greater/Equal |If NxV=0 |
|BGT a|2E|------| X|Branch if Greater Than |If Zv{NxV}=0|
|BHI a|22|------| X|Branch if Higher |If CvZ=0 |
|BHS a|24|------| X|Branch if Higher or Same |If C=0 |
|BITr s|B5|--**0-| XXXX |Bit Test |r&s |
|BLE a|2F|------| X|Branch if Less or Equal |If Zv{NxV}=0|
|BLO a|25|------| X|Branch if Lower |If C=1 |
|BLS a|23|------| X|Branch if Lower or Same |If CvZ=1 |
|BLT a|2D|------| X|Branch if Less Than |If NxV=1 |
|BMI a|2B|------| X|Branch if Minus |If N=1 |
|BNE a|26|------| X|Branch if Not Equal |If Z=0 |
|BPL a|2A|------| X|Branch if Plus |If N=0 |
|BRA a|20|------| X|Branch Always |PC=a |
|BRN a|21|------| X|Branch Never |No op |
|BSR a|8D|------| X|Branch to Subroutine |-[S]=PC,PC=a|
|BVC a|28|------| X|Branch if Overflow Clear |If V=0 |
|BVS a|29|------| X|Branch if Overflow Set |If V=1 |
|CBA |11|--****|X |Compare accumulators |A-B |
|CLC |0C|-----0|X |Clear Carry |C=0 |
|CLI |0E|-0----|X |Clear Interrupt Mask |I=0 |
|CLR d|7F|--0100| XX |Clear |d=0 |
|CLRr |4F|--0100|X |Clear accumulator |r=0 |
|CLV |0A|----0-|X |Clear Overflow |V=0 |
|CMPr s|B1|--****| XXXX |Compare |r-s |
|COM d|63|--**01| XX |Complement |d=~d |
|COMr |43|--**01|X |Complement accumulator |r=~r |
|CPX s|BC|--****| XXX* |Compare Index Register |X-s |
|DAA |19|--****|X |Decimal Adjust Acc. |A=BCD format|
|DEC d|7A|--**?-| XX |Decrement |d=d-1 |
|DECr |4A|--**?-|X |Decrement accumulator |r=r-1 |
|DES |34|------|X |Decrement Stack Pointer |S=S-1 |
|DEX |09|---*--|X |Decrement Index Register |X=X-1 |
|EORr s|B8|--**0-| XXXX |Logical Exclusive OR |r=rxs |
|INC d|7C|--**?-| XX |Increment |d=d+1 |
|INCr |4C|--**?-|X |Increment accumulator |r=r+1 |
|INS |31|------|X |Increment Stack Pointer |S=S+1 |
|INX |08|---*--|X |Increment Index Register |X=X+1 |
|JMP d|7E|------| XX |Jump |PC=d |
|JSR d|BD|------| XX |Jump to Subroutine |-[S]=PC,PC=d|
|LDAr s|B6|--**0-| XXXX |Load Accumulator |r=s |
|LDD s|FC|--**0-| XXX* |Load Double accumulator |D=s |
|LDS s|BE|--**0-| XXX* |Load Stack Pointer |S=s |
|LDX s|FE|--**0-| XXX* |Load Index Register |X=s |
|LSR d|74|--0***| XX |Logical Shift Right |d=->{0,d,C} |
|LSRr |44|--0***|X |Logical Shift Right |r=->{0,r,C} |
|LSRD |04|--0***|X |Logical Shift Right |D=->{0,D,C} |
|MUL |3D|-----*|X |Multiply |D=A*B |
|NEG d|70|--****| XX |Negate |d=-d |
|NEGr |40|--****|X |Negate accumulator |r=-r |
|NOP |01|------|X |No Operation | |
|ORAr s|BA|--**0-| XXXX |Logical inclusive OR |r=rvs |
|PSHA |36|------|X |Push |-[S]=A |
|PSHB |37|------|X |Push |-[S]=B |
|PSHX |3C|------|X |Push Index Register |-[S]=X |
|PULA |32|------|X |Pull |A=[S]+ |
|PULB |33|------|X |Pull |B=[S]+ |
|PULX |38|------|X |Pull Index Register |X=[S]+ |
|ROL d|79|--**?*| XX |Rotate Left |d={C,d}<- |
|ROLr |49|--**?*|X |Rotate Left accumulator |r={C,r}<- |
|ROR d|76|--**?*| XX |Rotate Right |d=->{C,d} |
|RORr |46|--**?*|X |Rotate Right accumulator |r=->{C,r} |
|RTI |3B|??????|X |Return from Interrupt |{regs}=[S]+ |
----------------------------------------------------------------
----------------------------------------------------------------
|Mnem. |Op|HINZVC|IEXD#R|Description |Notes |
|------+--+------+------+-+-----------------------+------------|
|RTS |39|------|X |Return from Subroutine |PC=[S]+ |
|SBA |10|--****|X |Subtract accumulators |A=A-B |
|SBCr s|B2|--****| XXXX |Subtract with Carry |r=r-s-C |
|SEC |0D|-----1|X |Set Carry |C=1 |
|SEI |0F|-1----|X |Set Interrupt Mask |I=1 |
|SEV |0B|----1-|X |Set Overflow |V=1 |
|STAr d|B7|--**0-| XXX |Store Accumulator |d=r |
|STD d|FD|--**0-| XXX |Store Double accumulator |D=r |
|STS d|BF|--**0-| XXX |Store Stack Pointer |d=S |
|STX d|FF|--**0-| XXX |Store Index Register |d=X |
|SUBr s|B0|--****| XXXX |Subtract |r=r-s |
|SUBD s|B3|--****| XXX* |Subtract Double acc. |D=D-s |
|SWI |3F|-1----|X |Software Interrupt |-[S]={regs} |
|TAB |17|--**0-|X |Transfer accumulators |B=A |
|TAP |06|******|X |Transfer |P=A |
|TBA |17|--**0-|X |Transfer accumulators |A=B |
|TPA |07|------|X |Transfer |A=P |
|TST s|7D|--**00| XX |Test |s |
|TSTr |4D|--**00|X |Test accumulator |r |
|TSX |30|------|X |Transfer |X=S |
|TXS |35|------|X |Transfer |S=X |
|WAI |3E|-*----|X |Wait for Interrupt |-[S]={regs} |
|---------+------+------+--------------------------------------|
| CCR |-*01? | |Unaffected/affected/reset/set/unknown |
| H |H | |Half carry (Bit 5) |
| I | I | |Interrupt mask (Bit 4) |
| N | N | |Negative (Bit 3) |
| Z | Z | |Zero (Bit 2) |
| V | V | |Overflow (Bit 1) |
| C | C| |Carry (Bit 0) |
|----------------+------+--------------------------------------|
| r |I |Inherent (r=A,Op=4XH, r=B,Op=5XH) |
| nn,E | E |Extended (Op=E, ~s=e) |
| nn,X | X |Index (Op=E-10H, ~s=e+1, JSR ~s=e-1) |
| n,D | D |Direct (Op=E-20H, ~s=e-1) |
| #n | # |Immediate (8-bit, Op=E-30H, ~s=e-2) |
| #nn | * |Immediate (16-bit, Op=E-30H, ~s=e-2) |
| a | R|Relative (PC=PC+2+offset) |
| r | |Inherent (r=A,Op=BXH, r=B,Op=FXH) |
|-----------------------+--------------------------------------|
|DIRECT |Direct addressing mode |
|EXTEND |Extended addressing mode |
|FCB n |Form Constant Byte |
|FCC 'string' |Form Constant Characters |
|FDB nn |Form Double Byte |
|RMB nn |Reserve Memory Bytes |
|-----------------------+--------------------------------------|
| A |Accumulator A (8-bit, Op=BXH) |
| B |Accumulator B (8-bit, Op=FXH) |
| D |A and B combined (16-bit, A hi, B lo) |
| P |Condition Code Register (8-bit, CCR) |
| PC |Program Counter (16-bit) |
| S |Stack Pointer (16-bit) |
| X |Index Register (16-bit) |
|-----------------------+--------------------------------------|
| a |Relative address (-125 to +129) |
| d s |Destination/source |
| n nn |8/16-bit expression (0 to 255/65535) |
| r |Accumulator register A or B |
| + - * / |Add/subtract/multiply/divide |
| & ~ v x |AND/NOT/inclusive OR/exclusive OR |
| <- -> |Rotate left/right |
| [ ] [ ]+ -[ ] |Indirect address/increment/decrement |
| { } {regs} |Combination of operands/{PC,X,A,B,P} |
|-----------------------+--------------------------------------|
| 0000H to 001FH |Internal registers |
| 0080H to 00FFH |128 bytes of internal RAM (not 6803NR)|
| FFF0H to FFFFH |Interrupt vectors |
| FFF0H to FFF1H |IRQ2 serial I/O interrupt vector |
| FFF2H to FFF3H |IRQ2 timer overflow vector |
| FFF4H to FFF5H |IRQ2 timer output compare vector |
| FFF6H to FFF7H |IRQ2 timer input capture vector |
| FFF8H to FFF9H |IRQ1 interrupt strobe 3 vector |
| FFFAH to FFFBH |SWI instruction interrupt vector |
| FFFCH to FFFDH |Non-maskable interrupt vector |
| FFFEH to FFFFH |Reset vector |
----------------------------------------------------------------
programming/CARDS/6805
+240
View File
@@ -0,0 +1,240 @@
----------------------------------------------------------------
| |
| |
| Motorola |
| |
| 666 88888 000 5555555 |
| 6 8 8 0 0 5 |
| 6 8 8 0 0 0 5 |
| 666666 88888 0 0 0 555555 |
| 6 6 8 8 0 0 0 5 |
| 6 6 8 8 0 0 5 |
| 66666 88888 000 555555 |
| |
| 6805 MICROPROCESSOR Instruction Set Summary |
| |
| |
| |
| |
| |
| _________ _________ |
| _| \__/ |_ |
| Vss |_|1 40|_| PA7 <--> |
| _____ _| |_ |
| --> RESET |_|2 39|_| PA6 <--> |
| ___ _| |_ |
| --> INT |_|3 38|_| PA5 <--> |
| _| |_ |
| Vcc |_|4 37|_| PA4 <--> |
| _| |_ |
| --> EXTAL |_|5 36|_| PA3 <--> |
| _| |_ |
| --> XTAL |_|6 35|_| PA2 <--> |
| _| |_ |
| NUM |_|7 34|_| PA1 <--> |
| _| |_ |
| --> TIMER |_|8 33|_| PA0 <--> |
| _| |_ |
| <--> PC0 |_|9 32|_| PB7 <--> |
| _| |_ |
| <--> PC1 |_|10 MC6805U2 31|_| PB6 <--> |
| _| |_ |
| <--> PC2 |_|11 30|_| PB5 <--> |
| _| |_ |
| <--> PC3 |_|12 29|_| PB4 <--> |
| _| |_ |
| <--> PC4 |_|13 28|_| PB3 <--> |
| _| |_ |
| <--> PC5 |_|14 27|_| PB2 <--> |
| _| |_ |
| <--> PC6 |_|15 26|_| PB1 <--> |
| _| |_ |
| <--> PC7 |_|16 25|_| PB0 <--> |
| _| |_ |
| <--> PD7 |_|17 24|_| PD0 <--> |
| ____ _| |_ |
| <--> PD6/INT2 |_|18 23|_| PD1 <--> |
| _| |_ |
| <--> PD5 |_|19 22|_| PD2 <--> |
| _| |_ |
| <--> PD4 |_|20 21|_| PD3 <--> |
| |______________________| |
| |
| |
| |
| |
| |
| |
|Written by Jonathan Bowen |
| Programming Research Group |
| Oxford University Computing Laboratory |
| 8-11 Keble Road |
| Oxford OX1 3QD |
| England |
| |
| Tel +44-865-273840 |
| |
|Created August 1981 |
|Updated April 1985 |
|Issue 1.1 Copyright (C) J.P.Bowen 1985|
----------------------------------------------------------------
----------------------------------------------------------------
|Mnemon.|Op|HINZC|IXED#RBT|Description |Notes |
|-------+--+-----+--------+-----------------------+------------|
|ADC s|F9|*-***| XXXX |Add with Carry |A=A+s+C |
|ADD s|FB|*-***| XXXX |Add |A=A+s |
|AND s|F4|--**-| XXXX |Logical AND |A=A&s |
|ASL d|78|--***| X X |Arithmetic Shift Left |d=d*2 |
|ASLA |48|--***|X |Arithmetic Shift Left |A=A*2 |
|ASLX |58|--***|X |Arithmetic Shift Left |X=X*2 |
|ASR d|77|--***| X X |Arithmetic Shift Right |d=d/2 |
|ASRA |47|--***|X |Arithmetic Shift Right |A=A/2 |
|ASRX |57|--***|X |Arithmetic Shift Right |X=X/2 |
|BCC a|24|-----|X |Branch if Carry Clear |If C=0 |
|BCLR b|11|-----| X |Bit Clear |b=0 |
|BCS a|25|-----| X |Branch if Carry Set |If C=1 |
|BEQ a|27|-----| X |Branch if Equal |If Z=1 |
|BHCC a|28|-----| X |Branch if Half C. Clear|If H=0 |
|BHCS a|29|-----| X |Branch if Half C. Set |If H=1 |
|BHI a|22|-----| X |Branch if Higher |If CvZ=0 |
|BHS a|24|-----| X |Branch if Higher/Same |If C=0 |
|BIH a|2F|-----| X |Branch if Int. High |If I=1 |
|BIL a|2E|-----| X |Branch if Int. Low |If I=0 |
|BIT s|F5|--**-| XXXX |Bit Test |A&s |
|BLO a|25|-----| X |Branch if Lower |If C=1 |
|BLS a|23|-----| X |Branch if Lower or Same|If CvZ=1 |
|BMC a|2C|-----| X |Branch if Mask Clear |If I=0 |
|BMI a|2B|-----| X |Branch if Minus |If N=1 |
|BMS a|2D|-----| X |Branch if Mask Set |If I=1 |
|BNE a|26|-----| X |Branch if Not Equal |If Z=0 |
|BPL a|2A|-----| X |Branch if Plus |If N=0 |
|BRA a|20|-----| X |Branch Always |PC=a |
|BRN a|21|-----| X |Branch Never |No operation|
|BRCLR c|01|-----| X|Test for Bit Clear |If b=0 |
|BRSET c|00|-----| X|Test for Bit Set |If b=1 |
|BSET b|10|-----| X |Bit Set |b=1 |
|BSR a|AD|-----|X |Branch to Subroutine |-[SP]=PC,BRA|
|CLC |98|----0|X |Clear Carry |C=0 |
|CLI |9A|-0---|X |Clear Interrupt Mask |I=0 |
|CLR d|7F|--010| X X |Clear |d=0 |
|CLRA |4F|--010|X |Clear Accumulator |A=0 |
|CLRX |5F|--010|X |Clear Index register |X=0 |
|CMP s|F1|--***| XXXX |Compare |A-s |
|COM d|73|--**1| X X |Complement |d=~d |
|COMA |43|--**1|X |Complement Accumulator |A=~A |
|COMX |43|--**1|X |Complement Index reg. |X=~X |
|CPX s|F3|--***|X |Compare Index register |X-s |
|DEC d|7A|--**-| X X |Decrement |d=d-1 |
|DECA |4A|--**-|X |Decrement Accumulator |A=A-1 |
|DECX |5A|--**-|X |Decrement Index reg. |X=X-1 |
|EOR s|F8|--**-| XXXX |Logical Exclusive OR |A=Axs |
|INC d|7C|--**-| X X |Increment |d=d+1 |
|INCA |4C|--**-|X |Increment Accumulator |A=A+1 |
|INCX |5C|--**-|X |Increment Index reg. |X=X+1 |
|JMP d|FC|-----| XXX |Jump |PC=d |
|JSR d|FD|-----| XXX |Jump to Subroutine |-[SP]=PC,JMP|
|LDA s|F6|--**-| XXXX |Load Accumulator |A=s |
|LDX s|FE|--**-| XXXX |Load Index register |X=s |
|LSL d|78|--0**| X X |Logical Shift Left |d={C,d,0}<- |
|LSLA |48|--0**|X |Logical Shift Left |A={C,A,0}<- |
|LSLX |58|--0**|X |Logical Shift Left |X={C,X,0}<- |
|LSR d|74|--0**| X X |Logical Shift Right |d=->{C,d,0} |
|LSRA |44|--0**|X |Logical Shift Right |A=->{C,A,0} |
|LSRX |54|--0**|X |Logical Shift Right |X=->{C,X,0} |
|NEG d|70|?-***| X X |Negate |d=-d |
|NEGA |40|?-***|X |Negate Accumulator |A=-A |
|NEGX |50|?-***|X |Negate Index register |X=-X |
|NOP |9D|-----|X |No Operation | |
|ORA s|FA|--**-| XXXX |Logical inclusive OR |A=Avs |
|ROL d|79|--***| X X |Rotate Left |d={C,d}<- |
|ROLA |49|--***|X |Rotate Left Accumulator|A={C,A}<- |
|ROLX |59|--***|X |Rotate Left Index reg. |X={C,X}<- |
|ROR d|76|--***| X X |Rotate Right |d=->{C,d} |
|RORA |46|--***|X |Rotate Right Acc. |A=->{C,A} |
|RORX |56|--***|X |Rotate Right Index reg.|X=->{C,X} |
|RSP |9C|-----|X |Reset Stack Pointer |SP=007EH |
|RTI |80|?????|X |Return from Interrupt |{regs}=[SP]+|
|RTS |81|-----|X |Return from Subroutine |PC=[SP]+ |
|SBC s|F2|--***| XXXX |Subtract with Carry |A=A-s-C |
|SEC |99|----0|X |Set Carry |C=1 |
----------------------------------------------------------------
----------------------------------------------------------------
|Mnemon.|Op|HINZC|I#DEXRBT|Description |Notes |
|-------+--+-----+--------+-----------------------+------------|
|SEI |9B|-0---|X |Set Interrupt Mask |I=1 |
|STA d|F7|--**-| XXX |Store Accumulator |d=A |
|STX d|FF|--**-| XXX |Store Index register |d=X |
|SUB s|F0|--***| XXXX |Subtract |A=A-s |
|SWI |83|-----|X |Software Interrupt | |
|TAX |97|-----|X |Transfer Acc. to Index |X=A |
|TST s|7D|--**-| X X |Test zero or minus |s |
|TSTA |4D|--**-|X |Test Accumulator |A |
|TSTX |5D|--**-|X |Test Index register |X |
|TXA |9F|-----|X |Transfer Index to Acc. |A=X |
|----------+-----+--------+------------------------------------|
| CC |-*01?| |Unaffect/affected/reset/set/unknown |
| H |H | |Half carry (Bit 4) |
| I | I | |IRQ interrupt mask (Bit 3) |
| N | N | |Negative (Bit 2) |
| Z | Z | |Zero (Bit 1) |
| C | C| |Carry/borrow (Bit 0) |
|----------------+--------+------------------------------------|
| |I |Inherent |
| X | X |Index (no offset, Op=X) |
| n,X | X |Index (8-bit offset, Op=X-10H) |
| nn,X | X |Index (16-bit offset, Op=X-20H) |
| nn,E | E |Extended (Op=X-30H) |
| nn | E | ditto when EXTEND is default |
| n,D | D |Direct (Op=X-40H) |
| n | D | ditto when DIRECT is default |
| #n | # |Immediate (Op=X-50H) |
| a | R |Relative (PC=PC+2+offset) |
| b | B |Bit set/clear |
| c | T|Bit test and branch |
|-------------------------+------------------------------------|
|DIRECT |Direct addressing mode |
|EXTEND |Extended addressing mode |
|FCB n |Form Constant Byte |
|FCC 'string' |Form Constant Characters |
|FDB nn |Form Double Byte |
|RMB nn |Reserve Memory Bytes |
|-------------------------+------------------------------------|
| A |Accumulator (8-bit) |
| CC |Condition Code register (8-bit) |
| PC |Program Counter (11-bit) |
| SP |Stack Pointer (11-bit, 61H to 7FH) |
| X |Index register (8-bit) |
|-------------------------+------------------------------------|
| a |Relative address (-125 to +129) |
| b |Bit (0 to 7), byte (0 to 255) |
| c |Bit, byte, relative address |
| d |Destination |
| n |8-bit expression (0 to 255) |
| nn |16-bit expression (0 to 65535) |
| r |Register A or X |
| s |Source |
| string |String of ASCII characters |
|-------------------------+------------------------------------|
| + |Arithmetic addition |
| - |Arithmetic subtraction |
| * |Arithmetic multiplication |
| / |Arithmetic division |
| & |Logical AND |
| ~ |Logical NOT |
| v |Logical inclusive OR |
| x |Logical exclusive OR |
| <- |Rotate left |
| -> |Rotate right |
| [ ] |Indirect addressing |
| [ ]+ |Indirect addressing, auto-increment |
| -[ ] |Auto-decrement, indirect addressing |
| { } |Combination of operands |
| {regs} |All registers {PC,X,A,CC} |
| $ |Program Counter content |
|-------------------------+------------------------------------|
| 0061H to 007FH |Reserved for stack (see RSP) |
| FFF8H to FFF9H |Hardware interrupt vector |
| FFFAH to FFFBH |SWI instruction interrupt vector |
| FFFCH to FFFDH |Non-maskable interrupt vector |
| FFFEH to FFFFH |Reset vector |
---------------------------------------------------------------
programming/CARDS/6808
+240
View File
@@ -0,0 +1,240 @@
----------------------------------------------------------------
| |
| |
| Motorola |
| |
| 666 88888 000 88888 |
| 6 8 8 0 0 8 8 |
| 6 8 8 0 0 0 8 8 |
| 666666 88888 0 0 0 88888 |
| 6 6 8 8 0 0 0 8 8 |
| 6 6 8 8 0 0 8 8 |
| 66666 88888 000 88888 |
| |
| 6808 MICROPROCESSOR Instruction Set Summary |
| |
| |
| |
| |
| |
| _________ _________ |
| _| \__/ |_ _____ |
| Vss |_|1 40|_| Reset <-- |
| ____ _| |_ |
| --> Halt |_|2 39|_| XTAL <-- |
| _| |_ |
| --> MR |_|3 38|_| EXTAL <-- |
| ___ _| |_ |
| --> IRQ |_|4 37|_| E --> |
| _| |_ |
| <-- VMA |_|5 36|_| Vss |
| ___ _| |_ |
| --> NMI |_|6 35|_| N/C |
| _| |_ _ |
| <-- BA |_|7 34|_| R/W --> |
| _| |_ |
| Vcc |_|8 33|_| D0 <--> |
| _| |_ |
| <-- A0 |_|9 32|_| D1 <--> |
| _| |_ |
| <-- A1 |_|10 6808 31|_| D2 <--> |
| _| |_ |
| <-- A2 |_|11 30|_| D3 <--> |
| _| |_ |
| <-- A3 |_|12 29|_| D4 <--> |
| _| |_ |
| <-- A4 |_|13 28|_| D5 <--> |
| _| |_ |
| <-- A5 |_|14 27|_| D6 <--> |
| _| |_ |
| <-- A6 |_|15 26|_| D7 <--> |
| _| |_ |
| <-- A7 |_|16 25|_| A15 --> |
| _| |_ |
| <-- A8 |_|17 24|_| A14 --> |
| _| |_ |
| <-- A9 |_|18 23|_| A13 --> |
| _| |_ |
| <-- A10 |_|19 22|_| A12 --> |
| _| |_ |
| <-- A11 |_|20 21|_| Vss |
| |______________________| |
| |
| |
| |
| |
| |
| |
|Written by Jonathan Bowen |
| Programming Research Group |
| Oxford University Computing Laboratory |
| 8-11 Keble Road |
| Oxford OX1 3QD |
| England |
| |
| Tel +44-865-273840 |
| |
|Created June 1982 |
|Updated April 1985 |
|Issue 1.1 Copyright (C) J.P.Bowen 1985|
----------------------------------------------------------------
----------------------------------------------------------------
|Mnem. |Op|HINZVC|IEXD#R|~|Description |Notes |
|------+--+------+------+-+-----------------------+------------|
|ABA |1B|*-****|X |2|Add accumulators |A=A+B |
|ADCA s|B9|*-****| XXXX |4|Add with Carry |A=A+s+C |
|ADCB s|F9|*-****| XXXX |4|Add with Carry |B=B+s+C |
|ADDA s|BB|*-****| XXXX |4|Add |A=A+s |
|ADDB s|FB|*-****| XXXX |4|Add |B=B+s |
|ANDA s|B4|--**0-| XXXX |4|Logical AND |A=A&s |
|ANDB s|F4|--**0-| XXXX |4|Logical AND |B=B&s |
|ASL d|78|--****| XX |6|Arithmetic Shift Left |d=d*2 |
|ASLA |48|--****|X |2|Arithmetic Shift Left |A=A*2 |
|ASLB |58|--****|X |2|Arithmetic Shift Left |B=B*2 |
|ASR d|77|--****| XX |6|Arithmetic Shift Right |d=d/2 |
|ASRA |47|--****|X |2|Arithmetic Shift Right |A=A/2 |
|ASRB |57|--****|X |2|Arithmetic Shift Right |B=B/2 |
|BCC a|24|------| X|4|Branch if Carry Clear |If C=0 |
|BCS a|25|------| X|4|Branch if Carry Set |If C=1 |
|BEQ a|27|------| X|4|Branch if Equal |If Z=1 |
|BGE a|2C|------| X|4|Branch if Greater or Eq|If NxV=0 |
|BGT a|2E|------| X|4|Branch if Greater Than |If Zv{NxV}=0|
|BHI a|22|------| X|4|Branch if Higher |If CvZ=0 |
|BITA s|B5|--**0-| XXXX |4|Bit Test |A&s |
|BITB s|F5|--**0-| XXXX |4|Bit Test |B&s |
|BLE a|2F|------| X|4|Branch if Less or Equal|If Zv{NxV}=0|
|BLS a|23|------| X|4|Branch if Lower or Same|If CvZ=1 |
|BLT a|2D|------| X|4|Branch if Less Than |If NxV=1 |
|BMI a|2B|------| X|4|Branch if Minus |If N=1 |
|BNE a|26|------| X|4|Branch if Not Equal |If Z=0 |
|BPL a|2A|------| X|4|Branch if Plus |If N=0 |
|BRA a|20|------| X|4|Branch Always |PC=a |
|BSR a|8D|------| X|8|Branch to Subroutine |-[S]=PC,PC,a|
|BVC a|28|------| X|4|Branch if Overflow Clr |If V=0 |
|BVS a|29|------| X|4|Branch if Overflow Set |If V=1 |
|CBA |11|--****|X |2|Compare accumulators |A-B |
|CLC |0C|-----0|X |2|Clear Carry |C=0 |
|CLI |0E|-0----|X |2|Clear Interrupt Mask |I=0 |
|CLR d|7F|--0100| XX |6|Clear |d=0 |
|CLRA |4F|--0100|X |2|Clear accumulator |A=0 |
|CLRB |5F|--0100|X |2|Clear accumulator |B=0 |
|CLV |0A|----0-|X |2|Clear Overflow |V=0 |
|CMPA s|B1|--****| XXXX |4|Compare |A-s |
|CMPB s|F1|--****| XXXX |4|Compare |B-s |
|COM d|63|--**01| XX |7|Complement |d=~d |
|COMA |43|--**01|X |2|Complement accumulator |A=~A |
|COMB |53|--**01|X |2|Complement accumulator |B=~B |
|CPX s|BC|--****| XXX* |5|Compare Index Register |X-s |
|DAA |19|--****|X |2|Decimal Adjust Acc. |A=BCD format|
|DEC d|7A|--**?-| XX |6|Decrement |d=d-1 |
|DECA |4A|--**?-|X |2|Decrement accumulator |A=A-1 |
|DECB |5A|--**?-|X |2|Decrement accumulator |B=B-1 |
|DES |34|------|X |4|Decrement Stack Pointer|S=S-1 |
|DEX |09|---*--|X |4|Decrement Index Reg |X=X-1 |
|EORA s|B8|--**0-| XXXX |4|Logical Exclusive OR |A=Axs |
|EORB s|F8|--**0-| XXXX |4|Logical Exclusive OR |B=Bxs |
|INC d|7C|--**?-| XX |6|Increment |d=d+1 |
|INCA |4C|--**?-|X |2|Increment accumulator |A=A+1 |
|INCB |5C|--**?-|X |2|Increment accumulator |B=B+1 |
|INS |31|------|X |4|Increment Stack Pointer|S=S+1 |
|INX |08|---*--|X |4|Increment Index Reg |X=X+1 |
|JMP d|7E|------| XX |3|Jump |PC=d |
|JSR d|BD|------| XX |9|Jump to Subroutine |-[S]=PC,PC=d|
|LDAA s|B6|--**0-| XXXX |4|Load Accumulator |A=s |
|LDAB s|F6|--**0-| XXXX |4|Load Accumulator |B=s |
|LDS s|BE|--**0-| XXX* |5|Load Stack Pointer |S=s |
|LDX s|FE|--**0-| XXX* |5|Load Index Register |X=s |
|LSR d|74|--0***| XX |6|Logical Shift Right |d=->{0,d,C} |
|LSRA |44|--0***|X |2|Logical Shift Right |A=->{0,A,C} |
|LSRB |54|--0***|X |2|Logical Shift Right |B=->{0,B,C} |
|NEG d|70|--****| XX |6|Negate |d=-d |
|NEGA |40|--****|X |2|Negate accumulator |A=-A |
|NEGB |50|--****|X |2|Negate accumulator |B=-B |
|NOP |01|------|X |2|No Operation | |
|ORAA s|BA|--**0-| XXXX |4|Logical inclusive OR |A=Avs |
|ORAB s|FA|--**0-| XXXX |4|Logical inclusive OR |B=Bvs |
|PSHA |36|------|X |4|Push |-[S]=A |
|PSHB |37|------|X |4|Push |-[S]=B |
|PULA |32|------|X |4|Pull |A=[S]+ |
|PULB |33|------|X |4|Pull |B=[S]+ |
----------------------------------------------------------------
----------------------------------------------------------------
|Mnem. |Op|HINZVC|IEXD#R|~|Description |Notes |
|------+--+------+------+-+-----------------------+------------|
|ROL d|79|--**?*| XX |6|Rotate Left |d={C,d}<- |
|ROLA |49|--**?*|X |2|Rotate Left accumulator|A={C,A}<- |
|ROLB |59|--**?*|X |2|Rotate Left accumulator|B={C,B}<- |
|ROR d|76|--**?*| XX |6|Rotate Right |d=->{C,d} |
|RORA |46|--**?*|X |2|Rotate Right acc. |A=->{C,A} |
|RORB |56|--**?*|X |2|Rotate Right acc. |B=->{C,B} |
|RTI |3B|??????|X |A|Return from Interrupt |{regs}=[S]+ |
|RTS |39|------|X |5|Return from Subroutine |PC=[S]+ |
|SBA |10|--****|X |2|Subtract accumulators |A=A-B |
|SBCA s|B2|--****| XXXX |4|Subtract with Carry |A=A-s-C |
|SBCB s|F2|--****| XXXX |4|Subtract with Carry |B=B-s-C |
|SEC |0D|-----1|X |2|Set Carry |C=1 |
|SEI |0F|-1----|X |2|Set Interrupt Mask |I=1 |
|SEV |0B|----1-|X |2|Set Overflow |V=1 |
|STAA d|B7|--**0-| XXX |5|Store Accumulator |d=A |
|STAB d|F7|--**0-| XXX |5|Store Accumulator |d=B |
|STS d|BF|--**0-| XXX |6|Store Stack Pointer |d=S |
|STX d|FF|--**0-| XXX |6|Store Index Register |d=X |
|SUBA s|B0|--****| XXXX |4|Subtract |A=A-s |
|SUBB s|F0|--****| XXXX |4|Subtract |B=B-s |
|SWI |3F|-1----|X |C|Software Interrupt |-[S]={regs} |
|TAB |17|--**0-|X |2|Transfer accumulators |B=A |
|TAP |06|******|X |2|Transfer to CCR |P=A |
|TBA |17|--**0-|X |2|Transfer accumulators |A=B |
|TPA |07|------|X |2|Transfer from CCR |A=P |
|TST s|7D|--**00| XX |6|Test |s |
|TSTA |4D|--**00|X |2|Test accumulator |A |
|TSTB |5D|--**00|X |2|Test accumulator |B |
|TSX |30|------|X |4|Transfer Stack Pointer |X=S |
|TXS |35|------|X |4|Transfer Index Register|S=X |
|WAI |3E|-*----|X |9|Wait for Interrupt |-[S]={regs} |
|---------+------+------+-+------------------------------------|
| CCR |-*01? | | |Unaffect/affected/reset/set/unknown |
| H |H | | |Half carry (Bit 5) |
| I | I | | |Interrupt mask (Bit 4) |
| N | N | | |Negative (Bit 3) |
| Z | Z | | |Zero (Bit 2) |
| V | V | | |Overflow (Bit 1) |
| C | C| | |Carry (Bit 0) |
|----------------+------+-+------------------------------------|
| |I | |Inherent |
| nn,E | E | |Extended (Op=E, ~s=e) |
| nn,X | X | |Index (Op=E-10H, ~s=e+1, JSR ~s=e-1)|
| n,D | D | |Direct (Op=E-20H, ~s=e-1) |
| #n | # | |Immediate (8-bit, Op=E-30H, ~s=e-2) |
| #nn | * | |Immediate (16-bit, Op=E-30H, ~s=e-2)|
| a | R| |Relative (PC=PC+2+offset) |
|-------------------------+------------------------------------|
|DIRECT |Direct addressing mode |
|EXTEND |Extended addressing mode |
|FCB n |Form Constant Byte |
|FCC 'string' |Form Constant Characters |
|FDB nn |Form Double Byte |
|RMB nn |Reserve Memory Bytes |
|-------------------------+------------------------------------|
| A B |Accumulators (8-bit) |
| P |Condition Code Register (CCR, 8-bit)|
| PC |Program Counter (16-bit) |
| S |Stack Pointer (16-bit) |
| X |Index Register (16-bit) |
|-------------------------+------------------------------------|
| a |Relative address (-125 to +129) |
| d s |Destination/source |
| n nn |8/16-bit expression (0 to 255/65535)|
| + - |Add/subtract |
| * / |Multiply/divide |
| & ~ |Logical AND/NOT |
| v x |Logical inclusive/exclusive OR |
| <- -> |Rotate left/right |
| [ ] [ ]+ -[ ] |Indirect address/increment/decrement|
| { } {regs} |Combined operands/{PC,X,A,B,P} |
|-------------------------+------------------------------------|
| FFF8H to FFF9H |Hardware interrupt vector |
| FFFAH to FFFBH |SWI instruction interrupt vector |
| FFFCH to FFFDH |Non-maskable interrupt vector |
| FFFEH to FFFFH |Reset vector |
----------------------------------------------------------------

Some files were not shown because too many files have changed in this diff Show More