Re: 5.25" PROM MisMatch Between II+ & IIgs

[dempson@actrix.gen.nz (David Empson)]

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