Running test6502.a65 on Py65

[kc5tja]

8BIT wrote:

I have not followed this thread too closely, but if you can provide the code, I can run it on my SBC-3 (65816).

I also have a 65C02 SBC-2 I can try.

Daryl

The code was posted above by BigEd.

[8BIT]

Yes, it was. Forgive me, I have been rushing all day.

My test results:

65816 Emulation mode: $32
65816 native mode: $32
WDC 65c02: $32

hope that helps

Daryl

[BigEd]

That's great - thanks! I'm reassured to see them all acting the same. It looks like we have 3 emulators which need tweaks to their handling of the 2 special 6502 status bits (both bits are physically absent on 6502, so always read as 1. But IRQ pushes a value with a 0 in the B position. 65816 in E mode acts the same as 6502, even though it has bits in those positions when not in E mode.)

For completeness, I tweaked the test a little, to force the bits in both directions:

Code: Select all

1388 A9 00    LDA#0
138A 48       PHA
138B 28       PLP
138C A9 00    LDA#0
138E 08       PHP
138F 68       PLA
1390 8D 87 13 STA 4999
1393 A9 FF    LDA#255
1395 48       PHA
1396 28       PLP
1397 A9 00    LDA#0
1399 08       PHP
139A 68       PLA
139B 8D 86 13 STA 4998
139E 60       RTS

I find that the first part gives $32 and the second part gives $7f, on both 6502 and 65816.

[8BIT]

I ran in on the WDC 65C02, with the same results - $32, $7F

I'm also happy to report that my 65C02 Simulator for Windows also has these results. Its core was taken from the AppleWin Simulator.

Daryl

[BigEd]

8BIT wrote:

I'm also happy to report that my 65C02 Simulator for Windows also has these results. Its core was taken from the AppleWin Simulator.

Nice! Mike now has a fix for py65, and Samuel has fixed up lib65816. All this was fallout really from trying to run a small part of the 6510 test suite - I still need to construct some sources so I can work with that.

[BigEd]

BigEd wrote:

An earlier thread points us to Wolfgang Lorenz' C64 testsuite

edit: Good news, it is in public domain. Bad news, it is in the form of p00 files (a pc64 format.) Good news, if a p00 file is binary and supposed to load at 0801 (see here) then we can load at 7e5 into py65 and jump to 0801 to ignore the header. Bad news, need to patch the i/o to suit py65. Good news, that shouldn't be too hard (see c64 rom)

Good news: Tom Seddon preserved a copy of the full archive with ASCII sources, on his site

Christer Palm explains how to stub out the C64 OS in this posting.

[BigEd]

BigEd wrote:

Here's the test section for SBC ... fails on lib6502 ...

I notice Ian has updated lib6502 with a one-line fix to SBC - and it now passes!

Quote:

2010-07-23 (v1.1) Many thanks to Steve Flintham for spotting a bug in SBC that set C and V incorrectly.

[BigEd]

Hi Bruce

dclxvi wrote:

There's a decimal mode checking program in Appendix B of my Decimal Mode write-up. As written, it tests documented and undocumented behavior on an NMOS 6502.

I've finally managed to write some improved decimal routines for Mike N's py65 - it now passes your suite in 6502 mode. This might be the first non-GPL freely redistributable decimal code. (*)

I modelled my code on an explanation by Segher B and on Ijor's document - I'm fairly sure but not certain that it's right for all the flags. To get the flags right for the NMOS 6502, you have to model the ALU as two nibbles of binary ALU, with a decimally-adjusted half carry, the byte-wide output of which produces the N V and Z flags, a decimally-adjusted carry which makes the C flag, and a decimally-adjusted result (both nibbles independently adjusted) which goes into A.

In summary: N V and Z are simple functions of the ALU output, which is almost but not quite the unadjusted binary result, the difference being in the forced half-carry for appropriate decimal additions. (Edit: ah, I see you've written about V including the decimal case, so you probably know this!)

If would be great if you could add the modelling of N, V and Z to your testsuite - perhaps I could help? We can validate the new testsuite on a real 6502, and then I can check the various emulators. (Edit: I was entirely confused, and Bruce enlightened me - see below. His testsuite is exhaustive and models all flags. I've now got py65 passing - there were a couple of bugs.)

Cheers
Ed

(*) I'm generally a fan of the GPL

[faybs]

Just chiming in to say thanks to the guys maintaining the different emulator libraries. I like to simulate everything in software before building anything, so it's great to know that I can count on you guys to keep refining your code. It lets guys like me not worry about the CPU so we can concentrate on the other stuff.

[dclxvi]

BigEd wrote:

If would be great if you could add the modelling of N, V and Z to your testsuite - perhaps I could help? We can validate the new testsuite on a real 6502, and then I can check the various emulators.

Unless I am misunderstanding you here, the code in appendix B already tests everything. ADC & SBC, valid & invalid BCD values, the accumulator, and the N, V, Z, C flags. It's basically just an implementation of the formulas from appendix A (which despite its title, actually covers everything, not just undocumented cases).

You'd have to modify the Appendix B program to test the 65C02 or (8-bit) 65816. You'd also have to modify it (specifically the COMPARE routine) to check only valid BCD numbers (steps 1-6) or remove tests (steps 7 and 8 )

Looking at it now, the documentation is rather skimpy -- probably a combination of (a) being close to the end and being somewhat sick and tired of writing about decimal mode (b) adding comments to the code which was written long before the article -- the code was written a short time after the V flag article was written, in fact -- the actual source file to this day is still uncommented, and (c) what I will call the Hemingway method of writing probably didn't help.

• AR is the correct value of the accumulator calculated using binary arithmetic
• NF, VF, ZF, and CF are the correct values of N, V, Z, and C flags calculated using binary arithmetic (these are in their respective positions in the P register, i.e. V in bit 6 of VF, but not masked off, i.e. the other bits of VF can be whatever, since they are ignored)
• DA is the value of the accumulator that the processor/simulator produced in decimal mode
• DNVZC is the value of the flags (all of them, including N, V, Z, and C) that the processor/simulator produced in decimal mode.

Then COMPARE, just compares the first group (AR, NF, VF, ZF, and CF) to the second group (DA and DNVZC). The idea is that it's fairly easy to modify COMPARE (the first three instructions, i.e. up to and including the first BNE C1, check the accumulator, the next four instructions, i.e. up to and including the second BNE C1, check the N flag, and so on) so that it doesn't check things you don't care about (for example, there isn't any benefit that I know of for a simulator to replicate the V flag exactly). If you care about everything, you don't have to modify COMPARE at all.

[BigEd]

Oh goodness, sorry about that. I'd read the advice about modifying COMPARE for checking 6502 as meaning that you weren't calculating all 4 flags. But you meant that a partial check could be done and for most emulators should be done because they don't even try to get all flags right.

I confess I hadn't scrutinised your code. I've had a better look now. I dare say I'll need to study a bit more before I'm done!

Thanks for the solid work behind those two documents - I can well understand how tedious and exacting it must have been to nail everything down definitively. Much appreciated.

Cheers
Ed

[Mindiell]

Hi there,

Since I'm writing my own 6502 simulator, I'm very interested by all test suites I can find.

How are you saying that a test is failed (I saw a source code in which an infinite loop was done) ?

By the way, your source code would be more than interesting since I'm fighting against the C and V flags right now

[BigEd]

Hi Mindiell
Welcome!

The py65 models are found here and the test suite here - because it's python code which runs the emulator functions for each test, it doesn't need any specific termination. As you say, it's relatively common to go into an infinite loop, so the PC tells you which test failed or if you reached the end. In some situations a BRK is a good way to finish, and in others RTS is right because you're returning to parent code. For visual6502, I have some short tests which don't finish but I choose to step the simulation just for some specific number of steps.

I've collected the test suites I know about, with some notes, on the visual6502 wiki - this page also contains a link to a collection of short decimal-mode tests for visual6502. Bruce's test program is exhaustive, so that's a better test if you can run it.

For information on how the flags behave, I recommend both of Bruce's tutorials mentioned earlier, plus others in that collection.

Cheers
Ed

[dclxvi]

To save people the trouble of hunting for my posts in this thread, I have added an errata page to the wiki for the Decimal Mode tutorial which captures that information.

http://6502org.wikidot.com/errata-other-decmode