Re: Apple IIe Enhancement Kit

["John B. Matthews" <nospam@nospam.com>]

In article <Lb2dndJnPpxvxMnfRVn-qA@comcast.com>,
 "Michael J. Mahon" <mjmahon@aol.com> wrote:

> Don Bruder wrote:
> > In article <eKadna7a37l4_87fRVn-pw@comcast.com>,
> >  "Bill Garber" <willy46pa@comcast.net> wrote:
> > 
> > 
> >>"Michael J. Mahon" <mjmahon@aol.com> wrote in message
> >>HoqdnVrIzOsaws7fRVn-pg@comcast.com">news:HoqdnVrIzOsaws7fRVn-pg@comcast.com...
> >>: Don Bruder wrote:
> >>: > In article <1112745624.538457.263650@o13g2000cwo.googlegroups.com>,
> >>:
> >>: [ snipped ]
> >>:
> >>: > Character ROM chip (for the "Mousetext" characters), 2 monitor ROM chips
> >>: > that include a couple of bug-fixes and the return of the
> >>: > "mini-assembler", plus a 65C02 processor with several machine-language
> >>: > instructions that the "regular" 6502 didn't have.
> >>:
> >>: Most of my machines have 65C02's, but some don't.  I have never found
> >>: the additional instructions of the 65C02 sufficiently compelling to
> >>: warrant writing programs that are incompatible with 6502s.
> >>:
> >>: It isn't like they added a multiply or something!  ;-)
> >>
> >>They don't really do much more than make the code incompatible
> >>with the 6502, and btw, the "C" stands for "C" if you can make
> >>my extra codes worthwhile.   :o)
> > 
> > 
> > It's been a while since I did anything in 6502/65C02 assembly, so my 
> > memory is foggy (and that's putting it nicely!) but I seem to recall one 
> > of them being *EXTREMELY* useful for a project I worked on. Can't 
> > rememebr which one it was, though. Without that instruction, code size 
> > would have been quite a bit bigger, and a WHOLE BUNCH (to the tune of 
> > "completely unacceptable") slower, since replacing it with "straight" 
> > 6502 instructions to accomplish the same task would have been about a 
> > 12-byte-per-replacement proposition. Never mind the "spaghetti" effect 
> > that would have crept in due to the "substitution".
> > 
> > It *COULD* have been done in "pure" 6502, I'm quite sure, but doing so 
> > would have been majorly ugly.
> 
> Well, if you wanted to push the X or Y register onto the stack and
> didn't want to disturb the A register, then the 65C02 provides that
> function directly.  This need sometimes arises when patching existing
> code.  The same can be said for STZ for clearing a memory variable
> while leaving the A register intact.
> 
> But in almost every case, _new_ code can be written so that there is
> a marginal advantage to using 65C02 instructions.
> 
> If I need to set or clear a memory flag on the fly, while the A
> register is "in play", I often find a way to do it with INC or DEC.
> This usually can be done if the current state of the flag is known.
> 
> In assembly language, there is an elegant approach to handling almost
> everything, and it is rare that the addition of a data movement
> instruction or two makes the difference between ugly and elegant.
> Sometimes a page-zero temporary is handy.

Michael makes several excellent points. Occasionally,  the new 
opcodes are marginally useful. They are most powerful in writing 
interpreters and run-time libraries, where the benefit is amortized 
over many executions.

For example, I added the new opcodes to a popular Forth assembler, 
but never actually used them in practice. In contrast, stz, ina, 
dea, phx, plx, phy, ply etc. saved considerably on stack-frame 
maintenance in a Kyan Pascal run-time library. The same applied to 
Randy Hyde's p-code interpreter optimizations.

-- 
John
jmatthews at wright dot edu
www dot wright dot edu/~john.matthews/

> -michael
> 
> New Applesoft BASIC interface for NadaNet networking!
> Home page:  http://members.aol.com/MJMahon/