6502.org

It passes!
My mistake was not to have disabled the interrupts from the system VIA. Although I start with an SEI, the various PLP instructions will sometimes perform an implicit CLI.

Cheers
Ed

To get diagnostics in the absence of a monitor, I changed all the self-looping traps to macro calls. In my case I write out the (stacked) PC to the UART, but writing to screen RAM would be another approach.
and so on for the other branch types.

Oh, good! I am currently working on a version that has an option for I-flag behavior. You can then choose to force interrupts disabled or enabled or even keep the current status of the I-flag. Of course SEI & CLI can only be tested with the old behavior as the preferred option.

And yes, the test tries to see, wether flags interfere with each other. So in the old behavior it turns all flags off (including I, enabling interrupts), runs some test instructions, turns all flags on, runs the same instructions again. The reason for this lies in the original target of this test. Emulators have to shuffle their own CPUs flags and some purely emulated flags to form the 6502 flags. A lot of things could go wrong with this...

Thanx for the good news!

cheers, Klaus

I'd be very interested in the results on Py65. Through the work of Ed and a few others, Py65 is complete enough to run many programs like EhBASIC but it may still have some issues. Py65 mostly uses the same memory mapped I/O as the Kowalski simulator so one binary should be able to test both.

I just started it running, but I'm not sure how long it might take.
Cheers
Ed

oh - it's finished, and passed!
(I didn't set the ROM vector function, because py65 treats BRK as a stop, therefore BRK isn't tested.)

Hi all,

a new version of the source is available.

added a code switch to control, how the interrupt flag should be handled.
added a code switch to control, wether the code will be build as a single image or as separate records for zero page and data space.
Needless to say, that all options ran successfully on my little emulator.

cheers, Klaus

Wow, that was unexpected.

Has anyone ported this to an assembler that doesn't run on Windows? My own assembler doesn't support the expressions (notably the logical operators), nor is it a macro assembler (but I used m4 for that). I tried another assembler, a java based one, and it just fails with an null pointer exception.

I've been working exclusively on linux. I looked around for a suitable assembler, and then noticed that Klaus had given directions in the header of the file. It's not open source but it does have a binary for linux.
Cheers
Ed

Yea I saw that too, but being on a Mac, a Linux binary doesn't do me much good.

Thanks, though.

Ah! A virtual machine might be the answer - VirtualBox or Qemu perhaps. (Or Parallels if $80 isn't an obstacle)

But: apparently WINE works on Mac these days - that must be the first port of call. I use WINE (on linux) even for GUI applications (such as Kowalski) but it's particularly likely to work for command line ones - I just checked and it's fine for Kingswood's as65.exe

Cheers
Ed

BTW, I just ran Klaus' test on Kowalski, both version 1.2.6 from last year, and the latest version as of today, and both pass. Like py65, BRK is treated as a stop, so that's not tested.
Cheers
Ed

Tested the newest (above mentioned) version and it passed. However, in the simulator options 1st tab you can change the instruction which causes the simulator to stop to something else than BRK.

So I ran the full test and it failed in the BRK test while checking the flags pushed onto the stack by LDA from page $100, expected $30 - actual $10. It expects to see the unused bit on but it isn't.

For the test I will pick up Eds idea to implement all traps as macros, so one can change the way the test reacts to a bug or even successfull completion.

cheers, Klaus

Ah, nicely found. My a6502 flags handling also needs attention, but to get to the bottom of it I need to improve the tracing control.