6502.org Forum Projects Code Documents Tools Forum
It is currently Mon Apr 29, 2024 11:23 am

View unanswered posts | View active topics


Board index » 6502.org Users Forum » Programming

All times are UTC




Post new topic Reply to topic  Page 12 of 14
  [ 203 posts ]  Go to page Previous  1 ... 9, 10, 11, 12, 13, 14  Next
  Previous topic | Next topic 
Author Message
BigEd
PostPosted: Mon Jul 01, 2019 1:11 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10793
Location: England
Could you perhaps share your code? It seems that something is misbehaving, because Klaus' testsuite tells you so. If by reading the code we can see what's going wrong, it will then be easier to see why your subsequent tests are not failing as you expect.
Top
 Profile  
Reply with quote  
Chromatix
PostPosted: Mon Jul 01, 2019 1:20 pm 
Offline

Joined: Mon May 21, 2018 8:09 pm
Posts: 1462
In case it helps, here's a trace of the first couple of dozen instructions from Klaus' test, from my sim with all the CPU state and memory activity exposed:
Code:
0400: CLD             ; A=00 X=00 Y=00 S=00    I  ; 0 cyc       fetch 0400 -> D8
0401: LDX #$FF        ; A=00 X=00 Y=00 S=00    I  ; 2 cyc       fetch 0401 -> A2        fetch 0402 -> FF
0403: TXS             ; A=00 X=FF Y=00 S=00 N  I  ; 4 cyc       fetch 0403 -> 9A
0404: LDA #$00        ; A=00 X=FF Y=00 S=FF N  I  ; 6 cyc       fetch 0404 -> A9        fetch 0405 -> 00
0406: STA  $0200      ; A=00 X=FF Y=00 S=FF    IZ ; 8 cyc       fetch 0406 -> 8D        fetch 0407 -> 00        fetch 0408 -> 02        store 0200 <- 00
0409: LDX #$05        ; A=00 X=FF Y=00 S=FF    IZ ; 12 cyc      fetch 0409 -> A2        fetch 040A -> 05
040B: JMP  $0433      ; A=00 X=05 Y=00 S=FF    I  ; 14 cyc      fetch 040B -> 4C        fetch 040C -> 33        fetch 040D -> 04
0433: BNE *-10        ; A=00 X=05 Y=00 S=FF    I  ; 18 cyc      fetch 0433 -> D0        fetch 0434 -> F4
0429: DEX             ; A=00 X=05 Y=00 S=FF    I  ; 21 cyc      fetch 0429 -> CA
042A: DEX             ; A=00 X=04 Y=00 S=FF    I  ; 23 cyc      fetch 042A -> CA
042B: DEX             ; A=00 X=03 Y=00 S=FF    I  ; 25 cyc      fetch 042B -> CA
042C: DEX             ; A=00 X=02 Y=00 S=FF    I  ; 27 cyc      fetch 042C -> CA
042D: DEX             ; A=00 X=01 Y=00 S=FF    I  ; 29 cyc      fetch 042D -> CA
042E: BEQ *-32        ; A=00 X=00 Y=00 S=FF    IZ ; 31 cyc      fetch 042E -> F0        fetch 042F -> DE
040E: LDY #$05        ; A=00 X=00 Y=00 S=FF    IZ ; 34 cyc      fetch 040E -> A0        fetch 040F -> 05
0410: BNE *+10        ; A=00 X=00 Y=05 S=FF    I  ; 36 cyc      fetch 0410 -> D0        fetch 0411 -> 08
041A: DEY             ; A=00 X=00 Y=05 S=FF    I  ; 39 cyc      fetch 041A -> 88
041B: DEY             ; A=00 X=00 Y=04 S=FF    I  ; 41 cyc      fetch 041B -> 88
041C: DEY             ; A=00 X=00 Y=03 S=FF    I  ; 43 cyc      fetch 041C -> 88
041D: DEY             ; A=00 X=00 Y=02 S=FF    I  ; 45 cyc      fetch 041D -> 88
041E: DEY             ; A=00 X=00 Y=01 S=FF    I  ; 47 cyc      fetch 041E -> 88
041F: BEQ *+25        ; A=00 X=00 Y=00 S=FF    IZ ; 49 cyc      fetch 041F -> F0        fetch 0420 -> 17
0438: LDA  $0200      ; A=00 X=00 Y=00 S=FF    IZ ; 52 cyc      fetch 0438 -> AD        fetch 0439 -> 00        fetch 043A -> 02        fetch 0200 -> 00
043B: CMP #$00        ; A=00 X=00 Y=00 S=FF    IZ ; 56 cyc      fetch 043B -> C9        fetch 043C -> 00
043D: BNE *+0         ; A=00 X=00 Y=00 S=FF    IZC; 58 cyc      fetch 043D -> D0        fetch 043E -> FE
043F: LDA #$01        ; A=00 X=00 Y=00 S=FF    IZC; 60 cyc      fetch 043F -> A9        fetch 0440 -> 01
0441: STA  $0200      ; A=01 X=00 Y=00 S=FF    I C; 62 cyc      fetch 0441 -> 8D        fetch 0442 -> 00        fetch 0443 -> 02        store 0200 <- 01
This includes several taken branches both forward and backward; note the relationship between the target address, branch instruction address, and the actual encoding of the branch target opcode. Also beware: the branch offsets are in decimal in the listing, but everything else is in hex.
Top
 Profile  
Reply with quote  
Klaus2m5
PostPosted: Wed Jul 03, 2019 6:58 am 
Offline

Joined: Sat Jul 28, 2012 11:41 am
Posts: 442
Location: Wiesbaden, Germany
May I remind you of a little disclaimer that I have in the program's source code header:
Code:
; Please note that in early tests some instructions will have to be used before
; they are actually tested!
So if you are absolutely sure that relative addressing works correctly in your emulator/simulator then you should consider skipping the test in question and run the remainder of the tests. Simply hack a JMP into the object code that skips the program between the two enclosing calls to the next_test macro.

_________________
6502 sources on GitHub: https://github.com/Klaus2m5
Top
 Profile  
Reply with quote  
Jokse
PostPosted: Wed Jul 03, 2019 4:35 pm 
Offline

Joined: Fri Nov 29, 2013 7:08 am
Posts: 15
Location: Denmark
I did manage to figure it out... I misread the listing and just ignored BPL, which was the culprit here... So I fixed that... More errors to fix, but that's for another day. Thanks Klaus for making a piece of very useful software :)
Top
 Profile  
Reply with quote  
ashkalov
PostPosted: Tue May 05, 2020 6:48 pm 
Offline

Joined: Tue May 05, 2020 6:34 pm
Posts: 4
Hi.
Excuse me for my English.
This is a translation, since I am Russian.
I am currently performing a Dormann functional test. There is a problem with the JSR instruction. My emulator puts the address of the instruction that goes directly after JSR on the stack. Since JSR has absolute addressing, the argument also has a size of 2 bytes. So I get the address of the next instruction so [current address] + 1 byte JSR + 2 bytes argument.
I do not understand why the following happens in Easy6502 and in everyone who has passed the Dormann test:
the RTS statement extracts the address and adds 1 to it. Why add 1? shouldn't the stack have the correct address?
Here is a piece of code Easy6502:

Code:
i60: function () {
 regPC = (stackPop () | (stackPop() << 8)) + 1;
 //RTS
}
Top
 Profile  
Reply with quote  
Dr Jefyll
PostPosted: Tue May 05, 2020 6:52 pm 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3349
Location: Ontario, Canada
Welcome, ashkalov :)

ashkalov wrote:
Why add 1? shouldn't the stack have the correct address?
No. Strangely, that's the way 65xx JSR and RTS instructions work. When they were designing the chip back in the 1970's they found it was easier to do it this way.

(Easier for them. Harder for us! :lol: )

Cheers,
Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html
Top
 Profile  
Reply with quote  
ashkalov
PostPosted: Tue May 05, 2020 7:13 pm 
Offline

Joined: Tue May 05, 2020 6:34 pm
Posts: 4
What was the difficulty in adding the correct address to the stack right away? Isn't adding 1 an additional operation?
Top
 Profile  
Reply with quote  
BigEd
PostPosted: Tue May 05, 2020 7:20 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10793
Location: England
If the 6502 had a temporary register like the 6800 did, it might have been able to stack the expected PC value. But note that the machine is entirely correct - the RTS compensates for the JSR. The problem with stacking the expected value is that the machine would need to hold both operand bytes somewhere while it did the stack manipulation, and it has nowhere to store two bytes. Instead, it stores the first operand byte in the stack pointer register, while the value from there is passing through the ALU to be decremented. At this time the second operand byte has not been read and the final PC increment has not occurred. When the stack business is done, the stack pointer goes back to S and the first operand byte comes out of S and passes through the ALU while the second operand byte is fetched. Finally, the machine has both bytes at the same instant, as it puts them onto the address bus to fetch the first instruction of the subroutine.

Edit: some previous posts on this oddity:
viewtopic.php?p=11932#p11932
viewtopic.php?p=66175#p66175
viewtopic.php?p=41557#p41557

Edit: the 6502 was made as small as it could be, so that temporary register might have been considered but the designers would have been very pleased to see a way to do without it.
Top
 Profile  
Reply with quote  
ashkalov
PostPosted: Tue May 05, 2020 7:32 pm 
Offline

Joined: Tue May 05, 2020 6:34 pm
Posts: 4
Thanks, BigED! Everything fell into place!
Top
 Profile  
Reply with quote  
ashkalov
PostPosted: Sat May 09, 2020 1:10 pm 
Offline

Joined: Tue May 05, 2020 6:34 pm
Posts: 4
Thank you very much, Klaus!
What would we do without You!
The test was completed successfully in 48 seconds.
Top
 Profile  
Reply with quote  
nelbr
PostPosted: Mon Nov 30, 2020 9:31 pm 
Offline

Joined: Tue Apr 19, 2005 7:25 pm
Posts: 15
Hello all,

I have written my own 6502 emulator from scratch in C (Linux gcc), with the sole objective of teaching me about 6502 working and also improve my programming skills. But let me warn you that my code is not clean, nor fast, nor efficient. I hope to improve as I learn more, and have spare time to dedicate to it. I am not a professional programmer, and I am doing this as a personal hobby, also as a way to develop my own Apple 2+ emulator using SDL 2.0.

Anyways, I am running Klaus Dormann's test suite, and yes, thank you so much Klaus for having created these. For now, I am running only the functional tests, and despite struggling a bit on how to interpret them, I have advanced significantly. From memory, I detected and fixed errors on BRK setting the B flag, setting of overflow flag and decimal mode calculation. This has been incredible useful, so thank you many times.

I have come to the point that I can use my 6502 to emulate an Apple 2 at native speed, so quite happy.

However, I am still struggling to finalize the functional test suite, so probably I still have some issues. My test runs for about 1m30s , and then it falls into an infinite loop. I output the current test number, as well as the contents of memory 0x200, 0x203 and 0x204 using printf() and here is what I get:

Teste numero F0 0 99
Teste numero F0 0 99
Teste numero F0 0 99
Teste numero F0 0 99
Teste numero F0 0 99
...

This repeats forever or for how long I managed to wait :-)

Would anyone be able to help me understand where to look to fix this ? Not sure what test F0 does (and I tried to check on the assembly code but really didn grasp it). I know I am close to the end of the testing, but thought that it would restart if finished, so I am guessing I am not quite there yet.

My code is here in case any of you are curious or would like to check and help me?

https://github.com/nelbr/6502

Thank you all,
Nelbr
Top
 Profile  
Reply with quote  
Chromatix
PostPosted: Tue Dec 01, 2020 3:16 am 
Offline

Joined: Mon May 21, 2018 8:09 pm
Posts: 1462
A test code of $F0 indicates that all the tests ran to completion successfully. The test suite is designed to run on bare hardware with no OS or monitor or I/O, so the only thing it can do is go into an infinite loop.
Code:
        lda #$f0        ;mark opcode testing complete
        sta test_case
Top
 Profile  
Reply with quote  
nelbr
PostPosted: Tue Dec 01, 2020 7:45 pm 
Offline

Joined: Tue Apr 19, 2005 7:25 pm
Posts: 15
Chromatix wrote:
A test code of $F0 indicates that all the tests ran to completion successfully. The test suite is designed to run on bare hardware with no OS or monitor or I/O, so the only thing it can do is go into an infinite

I see.

Thanks so much for your answer, this is good news then. I guess I was confused by this line below in the code which made me think a successful test would restart from the beginning.

Code:
; S U C C E S S ************************************************
        jmp start       ;run again     


Top
 Profile  
Reply with quote  
Chromatix
PostPosted: Tue Dec 01, 2020 8:39 pm 
Offline

Joined: Mon May 21, 2018 8:09 pm
Posts: 1462
It is entirely possible that the source code doesn't precisely match the supplied binary image. In my copy of the latter, there is a tight loop which my simulator's test harness interprets as a cue to exit - the "JMP start" is replaced with "JMP *":
Code:
[...]
3452: BNE *+0         ; A=10 X=0E Y=FF S=FC  VD ZC; 96571846 cyc   fetch 3452 -> D0   fetch 3453 -> FE
3454: RTI             ; A=10 X=0E Y=FF S=FC  VD ZC; 96571848 cyc   fetch 3454 -> 40   fetch 01FD -> 70   fetch 01FE -> 55   fetch 01FF -> 34
3455: LDA #$55        ; A=10 X=0E Y=FF S=FF  V    ; 96571854 cyc   fetch 3455 -> A9   fetch 3456 -> 55
3457: ADC #$55        ; A=55 X=0E Y=FF S=FF  V    ; 96571856 cyc   fetch 3457 -> 69   fetch 3458 -> 55
3459: CMP #$AA        ; A=AA X=0E Y=FF S=FF NV    ; 96571858 cyc   fetch 3459 -> C9   fetch 345A -> AA
345B: BNE *+0         ; A=AA X=0E Y=FF S=FF  V  ZC; 96571860 cyc   fetch 345B -> D0   fetch 345C -> FE
345D: LDA  $0200      ; A=AA X=0E Y=FF S=FF  V  ZC; 96571862 cyc   fetch 345D -> AD   fetch 345E -> 00   fetch 345F -> 02   fetch 0200 -> 2B
3460: CMP #$2B        ; A=2B X=0E Y=FF S=FF  V   C; 96571866 cyc   fetch 3460 -> C9   fetch 3461 -> 2B
3462: BNE *+0         ; A=2B X=0E Y=FF S=FF  V  ZC; 96571868 cyc   fetch 3462 -> D0   fetch 3463 -> FE
3464: LDA #$F0        ; A=2B X=0E Y=FF S=FF  V  ZC; 96571870 cyc   fetch 3464 -> A9   fetch 3465 -> F0
3466: STA  $0200      ; A=F0 X=0E Y=FF S=FF NV   C; 96571872 cyc   fetch 3466 -> 8D   fetch 3467 -> 00   fetch 3468 -> 02   store 0200 <- F0
3469: JMP  $3469      ; A=F0 X=0E Y=FF S=FF NV   C; 96571876 cyc   fetch 3469 -> 4C   fetch 346A -> 69   fetch 346B -> 34
3469: A=F0 X=0E Y=FF S=FF NV   C
Top
 Profile  
Reply with quote  
nelbr
PostPosted: Tue Dec 01, 2020 9:35 pm 
Offline

Joined: Tue Apr 19, 2005 7:25 pm
Posts: 15
Actually, just wanted to add that now that I know "F0" is successful completion, I added a check on my test program so it will exit once it sees 0xF0 in memory address 0x200 and I removed the printf command that displayed which test was being run, which reduced execution time on my emulator to 1s (from the 90s I posted above).

So, seems my library is actually performing pretty fast :-)
Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  Page 12 of 14
  [ 203 posts ]  Go to page Previous  1 ... 9, 10, 11, 12, 13, 14  Next

Board index » 6502.org Users Forum » Programming

All times are UTC


Who is online

Users browsing this forum: No registered users and 18 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
6502.org is an ongoing project by Mike Naberezny and contributors.