scott@geowhiz.UUCP (Scott Kempf) (08/19/87)
In a recent article Doug Pardee named a number of "bugs" and
problems with the 6502. It may come as a surprise to some, but as all
//gs owners know there are 65xx compatible processors beyond 65C02.
These are 65816 and 65802. The former is the micro-processor used in the
Apple //gs.
The 65802 can directly replace a 6502. It has 99.9% compatibility
with existing hardware and software, and allows programs to use most of
the 65816 commands. Although, because the 65802 has the same pin-outs as
the 6502, the 24 bit addressing ability of the 65816 is not available in
the 65802.
The 65816 (and the 65802) starts at power up in emulation mode.
Emulation mode is a special mode for the 65816, where it acts like a 6502
(actually a cross between the 6502 and 65C02). In emulation JMP (xxFF)
is fixed and since there are 256 instructions there are no unused codes
to do "strange things". The D (decimal mode) flag is still not cleared
on interrupts (for compatibility I believe, since it is cleared in native
mode). Emulation mode does all 65C02 instructions.
In native mode, many new features are added: 24 bit addressing, 16
bit registers, page zero (now call direct page) can be moved, the stack
is also mobile. There are new op-codes, new addressing modes, and new of
the two.
New 65816 Instructions:
op-code name
BRL branch always long
COP co-processor (not supported on //gs, yet)
JML jump long (24 bit)
JSL jump subroutine long
MVN move block negative
MVP move block positive
PEA push effective absolute address (push any 16 bit value)
PEI push indirect address
PER push effective program counter relative address
PHB push data bank register
PHD push direct page register
PHK push program bank register
PLB pull data bank register
PLD pull direct page register
REP reset status register bits
RTL return from subroutine long
SEP set status register bits
STP stop the processor (saves power, for portables)
TCD transfer accumulator to direct page register
TCS transfer accumulator to stack pointer
TDC transfer direct page register to accumulator
TSC transfer stack pointer to accumulator
TXY transfer index register X to Y
TYX transfer index register Y to X
WAI wait for interrupt
WDM resvd for future two-byte op-codes (for William D. Mensch jr.)
XBA exchange the B and A accumulators
XCE exchange carry and emulation bits
New 65816 Addressing Modes:
Addressing Mode Example
program counter relative long BRL address (16 bits)
stack relative LDA 3,S
stack relative indirect indexed with Y LDA (7,S),Y
block move MVN E0,0
absolute long LDA $E0C035
absolute long indexed with X LDA $E10004,X
absolute indirect long JMP [$0300]
direct page indirect long LDA [$06]
direct page indirect long indexed with Y LDA [$08],Y
While the 65816 does not solve all of Doug Pardee's complaints, it
solve most of them and adds many needed features. For those of you who
own 6502s and don't want a //gs, think about replacing your 6502 with a
65802. Only programs that use non-6502 instructions will be
incompatible, and you can write your own 16 bit code.
For more information on the 65816 get:
_Programming_the_65816_, by David Eyes and Ron Lichty. New York: Brandy
Communications (a division of Simon & Schuster), 1986. Prentice Hall
Press.
I strongly suggest this book, even Apple suggests it, as I copied the
above line from the _From_Apple_][e_to_Apple_][gs_Performance_Update_.
The Usual Non-Association Disclaimer--I am not associated with Prentice
Hall Press in anyway other than living in the same country and owning one
of there books.
As soon as I get my upgrade done, I will post the version numbers for all the
tools (before and after) and any other changes I can find.
_____________________________________________________________________________
Scott Kempf 1302 Rutledge St
uwvax!geowhiz!scott Madison WI 53703
scott@geowhiz.wisc.edu (608) 255-6205kamath@reed.UUCP (Sean Kamath) (08/20/87)
In article <572@geowhiz.UUCP> scott@geowhiz.UUCP (Scott Kempf) writes: > > The 65802 can directly replace a 6502. It has 99.9% compatibility > with existing hardware and software, and allows programs to use most of > the 65816 commands. Although, because the 65802 has the same pin-outs as > the 6502, the 24 bit addressing ability of the 65816 is not available in > the 65802. Note that I hit that .1% When I tried to put SMT's No-Slot Clock in my 65802ed //e, it wouldn't work. I put in the 65c02 and it worked. Worked with a 6502 also. I switched to my othe //e. It works (i'm using it now) with the clock. The only thing that didn't work was trying to use the clock. I don't know why. Turns out Jim Sather, author of Understanding the ][ and Understanding the //e, works for SMT now. I told him about my problem, so at least they know. I doubt if anyone is going to have a similar problem. It may be a bad chip, but then why does t work in one and not the other. Probably bad tolerences. > While the 65816 does not solve all of Doug Pardee's complaints, it > solve most of them and adds many needed features. For those of you who > own 6502s and don't want a //gs, think about replacing your 6502 with a > 65802. Only programs that use non-6502 instructions will be > incompatible, and you can write your own 16 bit code. Yeah, like copy protection that used an undocumentd opcode for fetch zeropage offset something or other. I know that Apple Assembly line ran an article about these undocumented opcodes. Anyone know about it? like, what issue? Or better yet, anyone got a list of them? I'd really like to see them. > For more information on the 65816 get: > > _Programming_the_65816_, by David Eyes and Ron Lichty. New York: Brandy > Communications (a division of Simon & Schuster), 1986. Prentice Hall > Press. A really good book, since it covers all 65xx series. I got it free from APDA and it was well worth it! (;-) >_____________________________________________________________________________ >Scott Kempf 1302 Rutledge St Sean Kamath -- UUCP: {decvax allegra ucbcad ucbvax hplabs ihnp4}!tektronix!reed!kamath CSNET: reed!kamath@Tektronix.CSNET || BITNET: reed!kamath@Berkeley.BITNET ARPA: tektronix!reed!kamath@Berkeley <or> reed!kamath@hplabs US Snail: 3934 SE Boise, Portland, OR 97202 (I hate 4 line .sigs!)