Megalextoria
Retro computing and gaming, sci-fi books, tv and movies and other geeky stuff.

Home » Digital Archaeology » Computer Arcana » Apple » Apple II Emulation » Klaus 65C02 tests
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
Klaus 65C02 tests [message #355375] Wed, 15 November 2017 00:00 Go to next message
anthonypaulo is currently offline  anthonypaulo
Messages: 531
Registered: September 2013
Karma: 0
Senior Member
Hello world!

I've been tearing my hair out of my head trying to wrap my head around a part of Klaus's functional test.

https://github.com/Klaus2m5/6502_65C02_functional_tests/blob /master/bin_files/6502_functional_test.lst

Starting at $0415 :

;testing relative addressing with BEQ
0415 : a0fe ldy #$fe ;testing maximum range, not -1/-2 (invalid/self adr)
0417 : range_loop
0417 : 88 dey ;next relative address
0418 : 98 tya
0419 : aa tax ;precharge count to end of loop
041a : 1003 bpl range_fw ;calculate relative address
041c : 18 clc ;avoid branch self or to relative address of branch
041d : 6902 adc #2
041f : range_fw
041f : 497f eor #$7f ;complement except sign
0421 : 8da804 sta range_adr ;load into test target
0424 : a900 lda #0 ;should set zero flag in status register
0426 : 4ca704 jmp range_op

At this point we have $FD XOR $7F = $82 stored in range_adr and $FD in X register. Note that Zero flag is set and then the jmp occurs to range_op :

049f : ca dex ;-10
04a0 : ca dex
04a1 : ca dex
04a2 : ca dex
04a3 : ca dex
04a4 : ca dex
04a5 : ca dex
04a6 : ca dex ;-3
04a7 : range_op ;test target with zero flag=0, z=1 if previous dex
04a8 = range_adr = *+1 ;modifiable relative address
04a7 : f03e beq *+64 ;if called without modification
04a9 : ca dex ;+0
04aa : ca dex
04ab : ca dex
04ac : ca dex
04ad : ca dex
04ae : ca dex
04af : ca dex
04b0 : ca dex
04b1 : ca dex
04b2 : ca dex
04b3 : ca dex ;+10

All range_op does is beq $82 ($82 was stored here previously from XOR operation). Now if I understand branching correctly, I presume you do $100 - $82 = $7e (or -126) and since zero flag is set it proceeds to BEQ to $4A9 (where the PC is after instruction is has been parsed) - $7E = $42B.

At $42B you see a slew of 'dex' instructions and the idea is it's supposed to dex all the way down to zero :

0521 : ca dex ;+120
0522 : ca dex
0523 : ca dex
0524 : ca dex
0525 : ca dex
0526 : ca dex
0527 : ca dex
0528 : f003 beq range_ok ;+127 - max forward
trap ; bad range
052a : 4c2a05 > jmp * ;failed anyway

052d : range_ok

However, when I perform the calculation manually I find that when reaching $528 : BEQ range_ok the X register is still at $02, and it falls into the trap and fails.

I've been going through this for hours but the test suite can't be wrong since it's been vetted and many emulators have passed it. What the heck am I doing wrong??!!
Re: Klaus 65C02 tests [message #355376 is a reply to message #355375] Wed, 15 November 2017 02:34 Go to previous messageGo to next message
Michael J. Mahon is currently offline  Michael J. Mahon
Messages: 1767
Registered: October 2012
Karma: 0
Senior Member
Anthony Ortiz <anthonypaulo@gmail.com> wrote:
> Hello world!
>
> I've been tearing my hair out of my head trying to wrap my head around a
> part of Klaus's functional test.
>
> https://github.com/Klaus2m5/6502_65C02_functional_tests/blob /master/bin_files/6502_functional_test.lst
>
> Starting at $0415 :
>
> ;testing relative addressing with BEQ
> 0415 : a0fe ldy #$fe ;testing maximum range,
> not -1/-2 (invalid/self adr)
> 0417 : range_loop
> 0417 : 88 dey ;next relative address
> 0418 : 98 tya
> 0419 : aa tax ;precharge count to end of loop
> 041a : 1003 bpl range_fw ;calculate relative address
> 041c : 18 clc ;avoid branch self or to
> relative address of branch
> 041d : 6902 adc #2
> 041f : range_fw
> 041f : 497f eor #$7f ;complement except sign
> 0421 : 8da804 sta range_adr ;load into test target
> 0424 : a900 lda #0 ;should set zero flag in status register
> 0426 : 4ca704 jmp range_op
>
> At this point we have $FD XOR $7F = $82 stored in range_adr and $FD in X
> register. Note that Zero flag is set and then the jmp occurs to range_op :
>
> 049f : ca dex ;-10
> 04a0 : ca dex
> 04a1 : ca dex
> 04a2 : ca dex
> 04a3 : ca dex
> 04a4 : ca dex
> 04a5 : ca dex
> 04a6 : ca dex ;-3
> 04a7 : range_op ;test target with zero
> flag=0, z=1 if previous dex
> 04a8 = range_adr = *+1 ;modifiable relative address
> 04a7 : f03e beq *+64 ;if called without modification
> 04a9 : ca dex ;+0
> 04aa : ca dex
> 04ab : ca dex
> 04ac : ca dex
> 04ad : ca dex
> 04ae : ca dex
> 04af : ca dex
> 04b0 : ca dex
> 04b1 : ca dex
> 04b2 : ca dex
> 04b3 : ca dex ;+10
>
> All range_op does is beq $82 ($82 was stored here previously from XOR
> operation). Now if I understand branching correctly, I presume you do
> $100 - $82 = $7e (or -126) and since zero flag is set it proceeds to BEQ
> to $4A9 (where the PC is after instruction is has been parsed) - $7E = $42B.
>
> At $42B you see a slew of 'dex' instructions and the idea is it's
> supposed to dex all the way down to zero :
>
> 0521 : ca dex ;+120
> 0522 : ca dex
> 0523 : ca dex
> 0524 : ca dex
> 0525 : ca dex
> 0526 : ca dex
> 0527 : ca dex
> 0528 : f003 beq range_ok ;+127 - max forward
> trap ; bad range
> 052a : 4c2a05 > jmp * ;failed anyway
>
> 052d : range_ok
>
> However, when I perform the calculation manually I find that when
> reaching $528 : BEQ range_ok the X register is still at $02, and it falls
> into the trap and fails.
>
> I've been going through this for hours but the test suite can't be wrong
> since it's been vetted and many emulators have passed it. What the heck
> am I doing wrong??!!
>
>

For one thing, the zero flag is only set when the result of an operation,
load, or transfer is zero.

If a result is $82, the zero flag is *not* set.

--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
Re: Klaus 65C02 tests [message #355377 is a reply to message #355376] Wed, 15 November 2017 03:17 Go to previous messageGo to next message
Michael J. Mahon is currently offline  Michael J. Mahon
Messages: 1767
Registered: October 2012
Karma: 0
Senior Member
Michael J. Mahon <mjmahon@aol.com> wrote:
> Anthony Ortiz <anthonypaulo@gmail.com> wrote:
>> Hello world!
>>
>> I've been tearing my hair out of my head trying to wrap my head around a
>> part of Klaus's functional test.
>>
>> https://github.com/Klaus2m5/6502_65C02_functional_tests/blob /master/bin_files/6502_functional_test.lst
>>
>> Starting at $0415 :
>>
>> ;testing relative addressing with BEQ
>> 0415 : a0fe ldy #$fe ;testing maximum range,
>> not -1/-2 (invalid/self adr)
>> 0417 : range_loop
>> 0417 : 88 dey ;next relative address
>> 0418 : 98 tya
>> 0419 : aa tax ;precharge count to end of loop
>> 041a : 1003 bpl range_fw ;calculate relative address
>> 041c : 18 clc ;avoid branch self or to
>> relative address of branch
>> 041d : 6902 adc #2
>> 041f : range_fw
>> 041f : 497f eor #$7f ;complement except sign
>> 0421 : 8da804 sta range_adr ;load into test target
>> 0424 : a900 lda #0 ;should set zero flag in status register
>> 0426 : 4ca704 jmp range_op
>>
>> At this point we have $FD XOR $7F = $82 stored in range_adr and $FD in X
>> register. Note that Zero flag is set and then the jmp occurs to range_op :
>>
>> 049f : ca dex ;-10
>> 04a0 : ca dex
>> 04a1 : ca dex
>> 04a2 : ca dex
>> 04a3 : ca dex
>> 04a4 : ca dex
>> 04a5 : ca dex
>> 04a6 : ca dex ;-3
>> 04a7 : range_op ;test target with zero
>> flag=0, z=1 if previous dex
>> 04a8 = range_adr = *+1 ;modifiable relative address
>> 04a7 : f03e beq *+64 ;if called without modification
>> 04a9 : ca dex ;+0
>> 04aa : ca dex
>> 04ab : ca dex
>> 04ac : ca dex
>> 04ad : ca dex
>> 04ae : ca dex
>> 04af : ca dex
>> 04b0 : ca dex
>> 04b1 : ca dex
>> 04b2 : ca dex
>> 04b3 : ca dex ;+10
>>
>> All range_op does is beq $82 ($82 was stored here previously from XOR
>> operation). Now if I understand branching correctly, I presume you do
>> $100 - $82 = $7e (or -126) and since zero flag is set it proceeds to BEQ
>> to $4A9 (where the PC is after instruction is has been parsed) - $7E = $42B.
>>
>> At $42B you see a slew of 'dex' instructions and the idea is it's
>> supposed to dex all the way down to zero :
>>
>> 0521 : ca dex ;+120
>> 0522 : ca dex
>> 0523 : ca dex
>> 0524 : ca dex
>> 0525 : ca dex
>> 0526 : ca dex
>> 0527 : ca dex
>> 0528 : f003 beq range_ok ;+127 - max forward
>> trap ; bad range
>> 052a : 4c2a05 > jmp * ;failed anyway
>>
>> 052d : range_ok
>>
>> However, when I perform the calculation manually I find that when
>> reaching $528 : BEQ range_ok the X register is still at $02, and it falls
>> into the trap and fails.
>>
>> I've been going through this for hours but the test suite can't be wrong
>> since it's been vetted and many emulators have passed it. What the heck
>> am I doing wrong??!!
>>
>>
>
> For one thing, the zero flag is only set when the result of an operation,
> load, or transfer is zero.
>
> If a result is $82, the zero flag is *not* set.
>

Never mind. ;-)
I should have read more closely.

--
-michael - NadaNet 3.1 and AppleCrate II: http://michaeljmahon.com
Re: Klaus 65C02 tests [message #355378 is a reply to message #355375] Wed, 15 November 2017 05:18 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: John Brooks

On Tuesday, November 14, 2017 at 9:00:19 PM UTC-8, Anthony Ortiz wrote:
> Hello world!
>
> I've been tearing my hair out of my head trying to wrap my head around a part of Klaus's functional test.
>
> https://github.com/Klaus2m5/6502_65C02_functional_tests/blob /master/bin_files/6502_functional_test.lst
>
> Starting at $0415 :
>
> ;testing relative addressing with BEQ
> 0415 : a0fe ldy #$fe ;testing maximum range, not -1/-2 (invalid/self adr)
> 0417 : range_loop
> 0417 : 88 dey ;next relative address
> 0418 : 98 tya
> 0419 : aa tax ;precharge count to end of loop
> 041a : 1003 bpl range_fw ;calculate relative address
> 041c : 18 clc ;avoid branch self or to relative address of branch
> 041d : 6902 adc #2
> 041f : range_fw
> 041f : 497f eor #$7f ;complement except sign
> 0421 : 8da804 sta range_adr ;load into test target
> 0424 : a900 lda #0 ;should set zero flag in status register
> 0426 : 4ca704 jmp range_op
>
> At this point we have $FD XOR $7F = $82 stored in range_adr and $FD in X register. Note that Zero flag is set and then the jmp occurs to range_op :
>
> 049f : ca dex ;-10
> 04a0 : ca dex
> 04a1 : ca dex
> 04a2 : ca dex
> 04a3 : ca dex
> 04a4 : ca dex
> 04a5 : ca dex
> 04a6 : ca dex ;-3
> 04a7 : range_op ;test target with zero flag=0, z=1 if previous dex
> 04a8 = range_adr = *+1 ;modifiable relative address
> 04a7 : f03e beq *+64 ;if called without modification
> 04a9 : ca dex ;+0
> 04aa : ca dex
> 04ab : ca dex
> 04ac : ca dex
> 04ad : ca dex
> 04ae : ca dex
> 04af : ca dex
> 04b0 : ca dex
> 04b1 : ca dex
> 04b2 : ca dex
> 04b3 : ca dex ;+10
>
> All range_op does is beq $82 ($82 was stored here previously from XOR operation). Now if I understand branching correctly, I presume you do $100 - $82 = $7e (or -126) and since zero flag is set it proceeds to BEQ to $4A9 (where the PC is after instruction is has been parsed) - $7E = $42B.
>
> At $42B you see a slew of 'dex' instructions and the idea is it's supposed to dex all the way down to zero :
>
> 0521 : ca dex ;+120
> 0522 : ca dex
> 0523 : ca dex
> 0524 : ca dex
> 0525 : ca dex
> 0526 : ca dex
> 0527 : ca dex
> 0528 : f003 beq range_ok ;+127 - max forward
> trap ; bad range
> 052a : 4c2a05 > jmp * ;failed anyway
>
> 052d : range_ok
>
> However, when I perform the calculation manually I find that when reaching $528 : BEQ range_ok the X register is still at $02, and it falls into the trap and fails.
>
> I've been going through this for hours but the test suite can't be wrong since it's been vetted and many emulators have passed it. What the heck am I doing wrong??!!

The test looks good:
1) It sets Y=$FD, A=$FD, A=$FD at 0419
2) ADC #2 = $FF
3) EOR #$7F = $80 (max neg rel branch), self-mod the branch
4) LDA #0 sets Z=1 & JMP to branch at 04A7
5) 04A7 branches back -128 to 0429 which does DEX 253 ($FD) times
6) X=0 so BEQ at 0528 skips over trap jmp at 052A

-JB
@JBrooksBSI
Re: Klaus 65C02 tests [message #355379 is a reply to message #355378] Wed, 15 November 2017 06:46 Go to previous messageGo to next message
anthonypaulo is currently offline  anthonypaulo
Messages: 531
Registered: September 2013
Karma: 0
Senior Member
But zero flag is set by LDA 0 right before jump, no?
Re: Klaus 65C02 tests [message #355380 is a reply to message #355378] Wed, 15 November 2017 06:50 Go to previous messageGo to next message
anthonypaulo is currently offline  anthonypaulo
Messages: 531
Registered: September 2013
Karma: 0
Senior Member
@John : how does it branch to that location? Branches occur from the end of the instruction, so max negative branch should fall 2 bytes short of the max (-128 + 2 = -126)
Re: Klaus 65C02 tests [message #355381 is a reply to message #355380] Wed, 15 November 2017 06:55 Go to previous messageGo to next message
anthonypaulo is currently offline  anthonypaulo
Messages: 531
Registered: September 2013
Karma: 0
Senior Member
> 04A7 branches back -128 to 0429 which does DEX 253 ($FD) times

To be clear, 04A7 contains two-byte BEQ instruction, so upon execution PC will end up becoming 04A9 at which point the branch -128 occurs, which is to 042B.
Re: Klaus 65C02 tests [message #355593 is a reply to message #355378] Wed, 15 November 2017 07:10 Go to previous message
anthonypaulo is currently offline  anthonypaulo
Messages: 531
Registered: September 2013
Karma: 0
Senior Member
> ADC #2 = $FF

Oh boy... I feel sheepish! Somehow I missed this, I thought the bpl before it would branch over the add since in my mind $FD is positive and -$FD is negative, lol! Of course $FD is negative!

Please ignore this thread as I go hide under a rock.
  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: Kickstarter for our Apple IIe emulator + magazine
Next Topic: Losing 5.25" disk images in AppleWin v1.26.3.4
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Tue Mar 19 03:15:52 EDT 2024

Total time taken to generate the page: 0.55628 seconds