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-6205
kamath@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!)