6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Thu Mar 28, 2024 9:56 pm

All times are UTC




Post new topic Reply to topic  [ 203 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6 ... 14  Next
Author Message
PostPosted: Wed Aug 01, 2012 4:40 pm 
Offline

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

a new version of the test now includes macros to insert custom error handling.
I did a bit of cleanup, as this is going to be the final version for now.

Next on my list is a test to check IRQ, NMI and reset. However, this will be a separate program as it requires some minimal hardware to allow the test to wiggle the CPUs interrupt and reset lines.

Once again, thank you very much for your continuous support, Big Ed.

cheers, Klaus


Attachments:
File comment: version 1-aug-2012
6502_functional_test.zip [29.08 KiB]
Downloaded 151 times

_________________
6502 sources on GitHub: https://github.com/Klaus2m5
Top
 Profile  
Reply with quote  
PostPosted: Wed Aug 01, 2012 4:49 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10760
Location: England
Thanks Klaus - great to have such a program. I will bring it to the attention of the good people at StarDot.org.uk
Cheers
Ed


Top
 Profile  
Reply with quote  
PostPosted: Wed Aug 01, 2012 10:22 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10760
Location: England
Good news - user 'sweh' has run your test on an original beeb with NMOS 6502 and it passed!
http://stardot.org.uk/forums/viewtopic. ... 874#p49874

Cheers
Ed


Top
 Profile  
Reply with quote  
PostPosted: Sun Aug 12, 2012 6:00 am 
Offline
User avatar

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands
I'm testing the code with my verilog implementation, and discovered a bunch of mistakes (in my code, not in the test program!)

First one was because bit 4 and bit 5 of the P register default to "0" rather than "1". It can be argued whether they should be tested, because bit 5 is reserved for future use, and the value is undefined. As far as I understand, bit 4 (the BRK bit) is also undefined, since the code isn't running as part of a BRK/IRQ handler. I changed my code to default these bits to "1". It requires the same amount of logic, and there's no harm in matching the NMOS 6502 better.

Second trap was due to overzealous 'load_reg' pattern match. Specifically, the IR=xxxx_10x0 also includes the NOP instruction, which caused the Z/N flags to be modified.

Third trap was due to a mistake in the ALU for the "V" flag calculation. Instead of BI[7], it should use temp_BI[7].

Fourth trap was in decimal ADC with (ind, X) addressing mode. Adding the X register was accidentally done in decimal mode.

After fixing these, the latest test ran successfully. I've pushed the fixes to github.


Top
 Profile  
Reply with quote  
PostPosted: Sun Aug 12, 2012 8:10 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10760
Location: England
Great - I've merged into my fork's 65Org16-master branch, although without any testing.
Did you test with RDY randomly activating?
Cheers
Ed


Top
 Profile  
Reply with quote  
PostPosted: Sun Aug 12, 2012 8:28 am 
Offline
User avatar

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands
BigEd wrote:
Did you test with RDY randomly activating?

No, but I'll do that right now.

Update: simulation just finished successfully, with RDY toggling randomly.


Top
 Profile  
Reply with quote  
PostPosted: Sun Aug 12, 2012 9:27 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10760
Location: England
Excellent. This testsuite has really helped!


Top
 Profile  
Reply with quote  
PostPosted: Sun Aug 12, 2012 9:47 am 
Offline

Joined: Sat Jul 28, 2012 11:41 am
Posts: 442
Location: Wiesbaden, Germany
Good to hear that the program is of some use...
Arlet wrote:
First one was because bit 4 and bit 5 of the P register default to "0" rather than "1". It can be argued whether they should be tested, because bit 5 is reserved for future use, and the value is undefined. As far as I understand, bit 4 (the BRK bit) is also undefined, since the code isn't running as part of a BRK/IRQ handler. I changed my code to default these bits to "1". It requires the same amount of logic, and there's no harm in matching the NMOS 6502 better.
As for the flags I am not absolutely sure, if I should impose the unused/break bits to be read back as 1 when they have been pushed by PHP. The programming manual states:
Quote:
3.5 EXPANSION BIT
The next bit in the flag register is an unused bit. It is most likely that this bit will appear to be on when one is analysing the bit pattern in the processor status register; however, no guarantee as to its state is made as this bit will be used in expanded versions of the microprocessor
The break bit behavior during a PHP is not documented in the manual. However, it is also an unused flag in the processor status register and should behave the same as the other unused bit if not modified. Visual6502 sheds some light onto why the break bit is only off during hardware IRQ or NMI. http://visual6502.org/wiki/index.php?ti ... _and_B_bit
Only during a hardware interrupt, bit 4 of the data bus is pulled low during the cycle when the CPU writes the processor flags to the stack.

All of this is not strictly a "documented" behavior of the 6502. Should I put in an option to disable the checking of the unused and break bits? I think, at least they should be consistant - always one or always zero after PHP.

cheers, Klaus

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


Top
 Profile  
Reply with quote  
PostPosted: Sun Aug 12, 2012 10:06 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10760
Location: England
I think the present check is perfect - it matches the NMOS 6502, and thanks to visual6502, we know why. Sometimes a program might do PHP/PLA and so passing such a test does improve a model.

That said, it is extra work to model these bits correctly! I still haven't fixed up a6502.


Top
 Profile  
Reply with quote  
PostPosted: Sun Aug 12, 2012 12:08 pm 
Offline
User avatar

Joined: Tue Nov 16, 2010 8:00 am
Posts: 2353
Location: Gouda, The Netherlands
BigEd wrote:
I think the present check is perfect - it matches the NMOS 6502, and thanks to visual6502, we know why. Sometimes a program might do PHP/PLA and so passing such a test does improve a model


Agreed. It's just a small change to correct the default value to match the NMOS 6502, and no good reason not to do it.


Top
 Profile  
Reply with quote  
PostPosted: Tue Aug 14, 2012 6:15 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10760
Location: England
I found and fixed some problems in the easy6502 simulator, which Nick has now updated.
http://skilldrick.github.com/easy6502/#first-program


Top
 Profile  
Reply with quote  
PostPosted: Fri Sep 14, 2012 4:41 am 
Offline

Joined: Fri Sep 14, 2012 4:30 am
Posts: 3
Hey, thanks Klaus for the test code! Also thanks to Ed for pointing me this way.

I wrote a test harness to run this against the 65c02 emulation in Jace (java apple computer emulator) and I was able to iron out some mishandling of the B and I flags that have always eluded me to some extent.

I know that this test is for vanilla 6502, but my 65c02 emulator code passes the test also just as long as I do not touch the D flag on BRK (the 65c02 also resets D on the BRK opcode)


Top
 Profile  
Reply with quote  
PostPosted: Fri Sep 14, 2012 5:08 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10760
Location: England
Jace passes now? Excellent! Glad to be of service.
(I've just posted a new thread about it)
Klaus has given the community something really valuable here - thanks Klaus!
(I added a link to the collection on the visual6502 wiki - we should perhaps have a reference section on this site too.)
Cheers
Ed


Top
 Profile  
Reply with quote  
PostPosted: Thu Feb 28, 2013 6:37 am 
Offline

Joined: Thu Feb 28, 2013 6:34 am
Posts: 16
Location: San Francisco, California
Just FYI, I managed to pass the latest version of the 6502 functional tests with a broken PLA opcode: it was not changing the NZ flags at all.

Makes for weird errors: boots an Apple ][+ just fine, lets you enter basic programs, but can't list them :-)

Once again, thanks for the fantastic tests!

Zellyn


Top
 Profile  
Reply with quote  
PostPosted: Thu Feb 28, 2013 10:26 am 
Offline

Joined: Sat Jul 28, 2012 11:41 am
Posts: 442
Location: Wiesbaden, Germany
Hi Zellyn, thank you for the bug report. I am going to fix it over the weekend.

_________________
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  [ 203 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6 ... 14  Next

All times are UTC


Who is online

Users browsing this forum: Google [Bot] and 1 guest


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: