6502.org

The code was posted above by BigEd.

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

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: I find that the first part gives $32 and the second part gives $7f, on both 6502 and 65816.

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

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.

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.

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

Hi BruceI'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

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.

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.

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

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

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

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