6502.org Forum Projects Code Documents Tools Forum
It is currently Sun Apr 28, 2024 10:06 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 6 of 14
  [ 203 posts ]  Go to page Previous  1 ... 3, 4, 5, 6, 7, 8, 9 ... 14  Next
  Previous topic | Next topic 
Author Message
redline6561
PostPosted: Mon Jun 24, 2013 1:53 pm 
Offline

Joined: Wed May 22, 2013 5:24 pm
Posts: 2
Thanks, BigEd! I actually spent the last two weeks optimizing and performance has improved by a factor of 4. So instead of 13 seconds to run the test suite, it takes about 2 and a half. I'm still nowhere near lib6502 but I'm gonna take a break for a few weeks. At 762 lines, I think I've at least got the smallest implementation. Oh, there's also a readable book of the source now. http://redlinernotes.com/docs/cl-6502.pdf

Happy hacking! :)
Top
 Profile  
Reply with quote  
BigEd
PostPosted: Mon Jun 24, 2013 2:15 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10793
Location: England
I saw the book - nicely done. Thanks for the credit too!
Top
 Profile  
Reply with quote  
Klaus2m5
PostPosted: Fri Jul 19, 2013 9:07 am 
Offline

Joined: Sat Jul 28, 2012 11:41 am
Posts: 442
Location: Wiesbaden, Germany
I have written two additional tests. However, they have only been verified with a self written emulator and not with real hardware and may therefore contain bugs. So I am eager to hear of your experience with these tests to help me improve them.

The first added test is aimed at verifying the interrupt system in both the classic NMOS 6502 and the newer 65C02. It requires a feedback register to self-inject IRQ and optionally NMI requests. A register port and optionally a DDR address must be configured. In addition you can choose wether the output is push/pull or totem pole (inverted, driving the DDR if present). 3 handloops with usage instructions assist in testing the WAI and the STP instruction.

The second added test verifies the extended functionality of the 65C02. There are options to configure testing of the additional opcodes not present on all versions of the 65C02. The basic funtional test for the NMOS cpu is a prerequisite to the 65C02 test as it tests only the added opcodes, addressing modes and functional differences.

As always, the tests can be downloaded here: http://2m5.de/6502_Emu/6502_functional_tests.zip

Good luck debugging your emulator, simulator, vhdl core, discrete logic implementation or whatever you have!

_________________
6502 sources on GitHub: https://github.com/Klaus2m5
Top
 Profile  
Reply with quote  
8BIT
PostPosted: Fri Jul 19, 2013 12:57 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1681
Location: Sacramento, CA
Thanks for creating those tests Klaus! 8)

I will have to run both on my AVR65C02 Emulator, as soon as I get some time.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/
Top
 Profile  
Reply with quote  
8BIT
PostPosted: Sun Jul 21, 2013 12:56 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1681
Location: Sacramento, CA
Hi Klaus,

I tried the 65c02 extended opcode test today. I pasted in the same trap macros that I used from the original test. That provides a BRK for each trap which dumps the registers to the screen. However, I'm getting "branch too far" errors at the BRA commands just after label bra2 and bra0. I presume this is because my macros consume more bytes that yours did.

Here are my macros:

Code:
trap    macro
        brk           ;failed anyway
        endm
trap_eq macro
   local trend
   code
        bne trend           ;failed equal (zero)
   brk
trend
        endm
trap_ne macro
   local trend
   code
        beq trend           ;failed not equal (non zero)
   brk
trend
        endm
trap_cs macro
   local trend
   code
        bcc trend           ;failed carry set
   brk
trend
        endm
trap_cc macro
   local trend
   code
        bcs trend           ;failed carry clear
   brk
trend
        endm
trap_mi macro
   local trend
   code
        bpl trend           ;failed minus (bit 7 set)
   brk
trend
        endm
trap_pl macro
   local trend
   code
        bmi trend           ;failed plus (bit 7 clear)
   brk
trend
        endm
trap_vs macro
   local trend
   code
        bvc trend           ;failed overflow set
   brk
trend
        endm
trap_vc macro
   local trend
   code
        bvs trend           ;failed overflow clear
   brk
trend
        endm
success macro
        brk               ;test passed, no errors
        endm


Any ideas for a workaround?

thanks!

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/
Top
 Profile  
Reply with quote  
Klaus2m5
PostPosted: Sun Jul 21, 2013 7:03 am 
Offline

Joined: Sat Jul 28, 2012 11:41 am
Posts: 442
Location: Wiesbaden, Germany
Hi Daryl,

you can remove the crazy branch test for now until I find a way to dynamically limit the BRA range.

Simply remove the code lines including the next_test macro just ahead of the crazy branch test comment until the next occurence of the next_test macro. There is still enough code left (BRA integrity, BRA shortrange) to test the opcode.

Thank you for letting me know!

cheers, Klaus

_________________
6502 sources on GitHub: https://github.com/Klaus2m5


Last edited by Klaus2m5 on Sun Jul 21, 2013 2:27 pm, edited 1 time in total.

Top
 Profile  
Reply with quote  
8BIT
PostPosted: Sun Jul 21, 2013 2:14 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1681
Location: Sacramento, CA
Thanks for the work around. I will give that a try.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/
Top
 Profile  
Reply with quote  
Klaus2m5
PostPosted: Sun Jul 21, 2013 3:30 pm 
Offline

Joined: Sat Jul 28, 2012 11:41 am
Posts: 442
Location: Wiesbaden, Germany
Hi Daryl,

I have an intermediate version of the test now with the BRA test shrunk to allow that the trap macros could at least contain a JSR plus a skipping branch. It is now on my list of things to test prior to any new release.

The test also has a new RAM integrity test which should detect unintentional RAM writes during the opcode tests. However, it is by default disabled since it requires that absolutely no other program in the background will write to RAM while the test is running. And it is going to be a pain to debug if you find a problem with it. :shock:

Attachment:
65C02_extended_opcodes_test.zip [13.4 KiB]
Downloaded 90 times

cheers, Klaus

_________________
6502 sources on GitHub: https://github.com/Klaus2m5


Last edited by Klaus2m5 on Sun Jul 21, 2013 5:37 pm, edited 1 time in total.

Top
 Profile  
Reply with quote  
Arlet
PostPosted: Sun Jul 21, 2013 4:43 pm 
Offline
User avatar

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands
Klaus2m5 wrote:
And it is going to be a pain to debug if you find a problem with it.

It's going to be an even bigger pain without the test suite to point it out.
Top
 Profile  
Reply with quote  
8BIT
PostPosted: Mon Jul 22, 2013 5:37 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1681
Location: Sacramento, CA
Hi again Klaus,

Your BRA fixes did not cause errors - good news.

The test ran down to the BBR/BBS tests and pointed out some bugs in my emulator. Those fixed, it proceeded to the BIT tests. I had trouble with the BIT # code. After some studying, I think the error is in your code: (see the label at the bottom for a positive location in the source file)

Code:
        set_a $ff,0
        bit #$00    ;00 - should set Z
        tst_a $ff,fz
        dex
        set_a 1,0
        bit #$41    ;41 - should clear Z
;        tst_a 1,0
   tst_a 1,fv  ; should set v bit
        dex
        set_a 1,0
        bit #$82    ;82 - should set Z
;        tst_a 1,fz
        tst_a 1,fnz  ; should set n&z bit
        dex
        set_a 1,0
        bit #$c3    ;c3 - should clear Z
;        tst_a 1,0
        tst_a 1,fnv  ; should set n&v bit
       
        set_a 1,$ff
        bit #$c3    ;c3 - clear Z
        tst_a 1,~fz
        inx
        set_a 1,$ff
        bit #$82    ;82 - should set Z
;        tst_a 1,$ff
        tst_a 1,~fv  ; should clear v bit
        inx
        set_a 1,$ff
        bit #$41    ;41 - should clear Z
;        tst_a 1,~fz
        tst_a 1,~fnz  ; should clear n&z bit
        inx
        set_a $ff,$ff
        bit #$00   ;00 - should set Z
;        tst_a $ff,$ff
        tst_a $ff,~fnv  ; should clear n&v bit
       
        cpx #3
        trap_ne     ;x altered during test
        cpy #$42
        trap_ne     ;y altered during test
        tsx
        cpx #$ff
        trap_ne     ;sp push/pop mismatch

; testing TRB, TSB - zp / abs

trbt    macro       ;\1 = memory, \2 = flags   


I commented out some tst_a macro calls with inaccurate parameters and replaced with ones I think have the correct parameters. Please check me - my tests now pass through to the TRB code. I probably have more errors in my emulator but that will have to wait for another day.

Great work by the way. This kind of code is very hard and tedious to write. My thanks to you for your hard work!

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/
Top
 Profile  
Reply with quote  
Klaus2m5
PostPosted: Mon Jul 22, 2013 6:59 am 
Offline

Joined: Sat Jul 28, 2012 11:41 am
Posts: 442
Location: Wiesbaden, Germany
Hi Daryl,

thank you, for taking the time to run the test and reporting the problems with it.

The BIT immediate tests also failed initially on my emulator - and they fail on the Kowalski simulator. But I checked again against WDCs programming reference manual http://www.westerndesigncenter.com/wdc/ ... manual.pdf and it states on page 333:
Quote:
When the BIT instruction is used with the immediate addressing mode, the n and v flags are unaffected.
and
Quote:
Flags Affected: n v - - - - z - (Other than immediate addressing)
_____________ - - - - - - z - (Immediate addressing only)
This is consistent with Bruce Clarks' tutorial about 65C02 opcodes on this website: http://www.6502.org/tutorials/65c02opcodes.html#2

It seems, the BIT immediate opcode is an exception in that it effects different flags than the rest of the BIT addressing modes. This makes perfect sense since on an immediate operand you always know what bit 7 & 6 are going to be. At this time I don't think it's a bug in the test.

cheers, Klaus

update: I have browsed a few more datasheets now and the result is ambiguous. Rockwell said M7 & M6 (N & V) is undefined after BIT #. GTE said no change of N & V. Some others, even WDCs' own datasheet didn't mark any deviation between the addressing modes. I may put in a switch to select which behavior you like best. :?: ... and make you sign a "proceed at your own risk agreement" of course.

_________________
6502 sources on GitHub: https://github.com/Klaus2m5
Top
 Profile  
Reply with quote  
8BIT
PostPosted: Mon Jul 22, 2013 12:19 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1681
Location: Sacramento, CA
Wow, you have really done your homework! It does make sense that an immediate value is known and setting bits 6&7 is useless. I had that same thought while figuring out the mismatches.

Thanks for the great explanation! I will make the changes on my emulator.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/
Top
 Profile  
Reply with quote  
8BIT
PostPosted: Tue Jul 23, 2013 3:46 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 9:02 pm
Posts: 1681
Location: Sacramento, CA
I made more progress last night. I corrected the BIT # handling in my Emulator and moved on to the TRB/TSB problems. This time I looked them up on the programming reference and found that the Z flag is set according to the results of the memory location and accumulator being AND'ed -even though the results of the AND are not stored. I has assumed the Z flag was set with the results of the ~A^M (TRB) or the AvM (TSB) operation. I corrected that in my emulator also.

The next problem occurred with the EOR (zp) test. I will look into that further next time. Again, great work with this test suite Klaus!

I am planning to dust off my SBC-4 and play with these tests on the 65816 using both emulation and native modes. I don't have any of my 65c02 boards anymore or I would try them on a WDC 65c02 also.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/
Top
 Profile  
Reply with quote  
Klaus2m5
PostPosted: Tue Jul 23, 2013 5:07 pm 
Offline

Joined: Sat Jul 28, 2012 11:41 am
Posts: 442
Location: Wiesbaden, Germany
8BIT wrote:
I am planning to dust off my SBC-4 and play with these tests on the 65816 using both emulation and native modes. I don't have any of my 65c02 boards anymore or I would try them on a WDC 65c02 also.

It would be really great, if the test could be verified with the real thing. On the 65816 I would only expect the emulation mode to be compatible with the test as long as you remove the NOP tests. Additionally in native mode the load_flag macros must be changed to force the M & X bits always set to 8-bit mode. I don't know the 65816 well enough to anticipate further obstacles.

good luck, Klaus

_________________
6502 sources on GitHub: https://github.com/Klaus2m5
Top
 Profile  
Reply with quote  
Klaus2m5
PostPosted: Tue Jul 23, 2013 6:35 pm 
Offline

Joined: Sat Jul 28, 2012 11:41 am
Posts: 442
Location: Wiesbaden, Germany
8BIT wrote:
The next problem occurred with the EOR (zp) test.

If you compare
Code:
_EOR_IND:            ;52
   movw   zl, XL
   _IZPG
   _EORZ
   EXEC
with
Code:
_AND_IND:            ;32
   movw   zl, XL
   _IZPG
   _AND
   EXEC

_________________
6502 sources on GitHub: https://github.com/Klaus2m5
Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  Page 6 of 14
  [ 203 posts ]  Go to page Previous  1 ... 3, 4, 5, 6, 7, 8, 9 ... 14  Next

Board index » 6502.org Users Forum » Programming

All times are UTC


Who is online

Users browsing this forum: No registered users and 21 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.