Re: 5.25" PROM MisMatch Between II+ & IIgs

[jon@i-manila.com (Jon Co)]

I tested the code on an enhanced IIe (with a 65c02 processor) and BEQ
gets executed as well.

By the way, doesnt BIT do the AND between the accumulator and
memory????  In your program you have loaded the X register with the
values and the Accumulator would contain whatever it did when you ran
the code so this doesnt prove anything at all.

Adding a TXA in $2009 (and moving everything down) would put #$6 in
the accumulator and BEQ did not execute on both the IIe and the IIGS.

"Bryan Parkoff" <BParkoff@satx.rr.com> wrote in message news:<y8qdnUv1xbTmY86jXTWQkQ@giganews.com>...
> David,
> 
>     I think that you don't understand my saying.  You will need to compare
> BIT on both Apple II+ and Apple IIgs.  Look at my code below.
> 
> 2000: JSR FC58
> 2003: LDX #03
> 2005: STX 3C
> 2007: LDX #06
> 2009: BIT 3C
> 200B: BEQ 2012
> 200D: LDY #C1
> 200F: STY 0400
> 2012: LDY #C2
> 2014: STY 0401
> 2017: RTS
> 
>     Hex 03 shows 011 and Hex 06 shows 110.  Bit's Hex 02 shows 010.  This
> answer is correct because second bit shows 1.  BIT should tell BEQ not to
> branch because it is nonzero bit.  On Apple II+, it reports "AB", but on
> Apple IIgs, it reports "B".  Apple II+ is to be correct.  Apple IIgs should
> not execute BEQ.  Please compare my code above on your real Apple II+ and
> Apple IIgs.  You will notice the difference.
>     It may prove that Apple IIgs gives the wrong value.
> 
> 
> --
> Yours Truly,
> 
> Bryan Parkoff
> BParkoff@satx.rr.com
> "David Empson" <dempson@actrix.gen.nz> wrote in message
> 1fqnmoj.lgym7t11hbjgaN%dempson@actrix.gen.nz">news:1fqnmoj.lgym7t11hbjgaN%dempson@actrix.gen.nz...
> > Bryan Parkoff <BParkoff@satx.rr.com> wrote:
> >
> > >     I find an interesting disasembly that is not doing correct.  For
> > > example: BEQ should be even and BNE should be odd.  Look at my code
>  below.
> > > I have copied PROM from Apple II+ to Apple IIgs for testing.
> > >
> > > C600: A2 20        LDX #20
> > > C602: A0 00        LDY #00
> > > C604: A2 03        LDX #03
> > > C606: 86 3C        STX 3C
> > > C608: 8A           TXA
> > > C609: 0A           ASL
> > > C60A: 24 3C        BIT 3C
> > > C60C: F0 10        BEQ C61E {+10}
> > > C60E: 05 3C        ORA 3C
> > >
> > >     On Apple II+, 6 is even.  BEQ should state, "6 is equal to even".
>  BEQ
> > > should report TRUE, but Apple II+ reports false.  Apple IIgs reports
>  true.
> > > C60E is not supposed to be executed on Apple II+, but Apple IIgs did
>  execute
> > > C61E.
> >
> > After the ASL, the accumulator contains #$06, while location $3C
> > contains #$03 (from the STX at C606).
> >
> > The BIT instruction does a logical AND operation between the accumulator
> > and the specified memory location.  It discards the result of the AND
> > (the accumulator is not modified) but sets the Z flag to indicate
> > whether the result of the AND was zero.  (It also copies bits 6 and 7 of
> > the memory location into the V and N flags.)
> >
> > In this case, we are ANDing #$06 with #$03.  They have a bit in common
> > (#$02), so the result is not zero, the BEQ instruction should NOT
> > branch, and the code should continue executing from C60E.
> >
> > >     Please compare my example on your both real Apple II+ and Apple
>  IIgs.
> > > It is possible that emulator is not doing correct for manipulating odd
>  and
> > > even like using to test PARITY.
> >
> > The BIT instruction has nothing to do with testing for odd or even
> > values, unless the accumulator happens to contain #$01.  (The 6502
> > doesn't have any kind of special support for parity, unlike the 8080,
> > Z80, 8088 etc.)
> >
> > --
> > David Empson
> > dempson@actrix.gen.nz