Jump to content
phaeron

Acid800: An Atari test suite

Recommended Posts

This has been loafing around my hard drive for a while, but I thought I'd kick it out in public and see what people thought.

 

Acid800 is a test suite to stress Atari 800/XL emulators. 8-bit emulation has been around long enough now that all of the major emulators run the majority of available Atari software, but each has its weaknesses and from time to time coders still find new cases where software works fine on an emulator and fails on the real hardware. The point of Acid800 is to reliably identify those cases and to help raise the bar for emulation accuracy, as the Acid tests have done for CSS compliance in web browsers.

 

It's a simple test to run, just boot a disk. A README with details is included. The test suite should pass on real hardware, with a couple of caveats noted in the README; however, no released emulator that I know of passes it, including Altirra 1.7 (31 pass, 7 fail). However, I intend to change that with the next release, as 1.8 test-13 is currently 38-0. Nothing wrong with a little friendly competition, right? :D

 

Any comments are welcome. There are some more tests I want to add when I get the chance, such as more CPU instruction tests, and some more odd ANTIC behavior that I've been notified about recently. I'd also like to do a 5200 version, although I'll have to rip out the SIO/CIO dependencies.

acid800-0.1.zip

  • Like 3

Share this post


Link to post
Share on other sites

Atari 130 XE + VBXE:

GTIA: Special modes collision test...FAIL.

GR.10 $1 collision incorrect: $02

 

Hmm... this means that the test detected a collision between missile 1 and the player 1 color of Gr. 10 mode, which isn't supposed to happen. Do you know how VBXE interacts with GTIA read registers? I thought collision registers were handled by the regular GTIA and not emulated by the core.

Share this post


Link to post
Share on other sites

cpu bugs skipped

antic hires bug fail, collision not found with bug 00

Phantom DMA byte 1 was not AD (was00)

GTIA collisions test Fail M/P collisions were not correct in total case

GTIA P/M retriggering Fail Player did not retrigger properly

GTIA pseudo mode E Fail cycle 14 test failed: 00

MMU XL banking Fail unable to bank in BASIC ROM

 

65 xe 1088 ram, 816 cpu, vbxe 1.20,

Share this post


Link to post
Share on other sites

No VBXE here (at least on this test):

 

- 800 XE (PAL) with 320kB of RAM (without separate ANTIC access to ext-RAM) - no errors

 

- 130 XE (PAL) with 1088kB of RAM (without separate ANTIC access to ext-RAM as well): MMU XL banking Fail unable to bank in BASIC ROM

 

Interesting thing is that above error occurs also in latest Altirra (test13) and any other emulator with 1088kB of memory selected.

Share this post


Link to post
Share on other sites

Yeah, that's what I figured... because if VBXE handled GTIA reads, it would also have to handle switch and trigger I/O too.

 

xxl, if you have time, can you run these versions of the tests and see if any of them still fail for you? I did find one bug in the test, which is that it wasn't clearing GRACTL before invoking the test, but that shouldn't have given a false positive -- at most, it would have given a false negative. Anyway, there are two standalone versions in the test directory, one which uses missiles and another which uses players. I'm curious about this.

acid800_gtiatest.zip

Share this post


Link to post
Share on other sites

Same message as last time, I presume? Odd, this is the first time I've seen this -- never seen it on my NTSC 800XL or 130XE, nor have people reported it with their PAL machines. I assume you are running a stock XL OS?

 

Could I trouble you to run one more test? This one just spreads all missiles across all of the player playfield colors ($0-$3) and reports what the four MxPF values. What's especially odd here is that your hardware is reporting a missile 1 to PF1 collision but not a missile 0 to PF0 collision, which makes no sense to me. I'd like to know what collisions your hardware is reporting.

acid800_mxpftest.zip

Share this post


Link to post
Share on other sites

Hey, thanks for the extra reports.

 

@zaxon:

I think I read on the atari.area forum that you have a 65C816? I might need to put a big warning on screen for a 65C02 or 65C816 since it looks like a bunch of the tests are too timing sensitive to run reliably with an '816, especially if running faster than 1.79MHz. I used the INC WSYNC trick in a bunch of places and that might not work with the CMOS variants.

 

@xxl:

Wow... your hardware is reporting all PF1 collisions in mode 10 for the player colors. I can't explain that. I wonder if it has to do with a timing glitch in the mode 10 hardware, which seems to be a bit sketchy timing-wise. Anyone else seeing this?

Share this post


Link to post
Share on other sites

Actually AFAIK there shouldn't be any differences in timings between Sally and 65c816. Of course it does not apply to 65C02.

 

I don't have a 65C816-based system so I can't be sure, but I thought there was a difference between the NMOS and CMOS variants with regard to RDY during write cycles. I use INC WSYNC in a number of places in the test suite, to reduce variance in cycle timing.

Share this post


Link to post
Share on other sites

One thing made me laugh, I tested Atari800win Plus (last version) and then Atari++, well what do you know, both had the same score fail 22 16. Whoever said ++ was based upon Win Plus code ;)

 

Not me :)

Share this post


Link to post
Share on other sites

I don't have a 65C816-based system so I can't be sure, but I thought there was a difference between the NMOS and CMOS variants with regard to RDY during write cycles. I use INC WSYNC in a number of places in the test suite, to reduce variance in cycle timing.

AFAIK CMOS 65xx have single write cycle in read-modify-write instructions.

Share this post


Link to post
Share on other sites

@Mclaneinc:

You can't draw that conclusion from this test suite -- Atari++ and Atari800WinPlus fail tests for different reasons. Until recently, Atari++ used to fail a couple of the CPU tests, whereas Atari800WinPlus has a solid CPU core but fails the serial output complete test. I wouldn't be surprised to see similar numbers just because Atari800 is generally considered the gold standard with regard to Atari emulation.

 

@fox:

I completely forgot about that. That means that INC WSYNC on a 65C02/65C816 probably behaves the same as STA WSYNC,X on a 6502, which definitely won't have the same effect. :-/

Share this post


Link to post
Share on other sites

No -- on an NMOS 6502, INC WSYNC prevents that. It does two write cycles in a row, so the first one causes ANTIC to pull RDY, and the second one eats the extra cycle if no DMA occurs (it's a write cycle, so RDY doesn't stop it). I use it everywhere to avoid that one cycle variance. However, it probably doesn't work on a CMOS variant. :-/

Share this post


Link to post
Share on other sites

Really. I don't know where this rumour is from. I can't find the version of 65C816 documentation where this is clearly stated in table, but here you are: http://65c816.com/wdc/documentation/w65c816s.pdf page 45 footnote 17 says, that "In the emulation mode, during a R-M-W instruction the RWB is low during both write and modify cycles." Only when in native mode the 65c816 behaves like 65c02 i.e. performs read in the "modify cycle". I hope it is implemented correctly in Altirra.

Share this post


Link to post
Share on other sites

I have the version with the chart you're thinking of, included in the back of "Programming the 65816" by Eyes / Lichty. You're right, in emulation mode, the 65C816 does read/write/write like the 6502, versus read/read/write for the 65C02 or native mode -- forgot that too. However, if you check the bottom of the chart on page 51 of the doc you linked, or footnote 7.17 on page 54, it notes that the 65C816 will stop when ready is pulled on a write cycle regardless of E mode. (The doc I have also says that the 65C802 does change RDY-on-write behavior based on E, for all three people who had one.) I still think there's a possibility for INC WSYNC to act differently here.

 

As for Altirra, I'm pretty sure it's not entirely cycle correct for 65C816. Besides my being unable to test on real hardware, there are an awful lot of cases to cover. Besides the five base modes (E=1, E=0 with M/X modes), there's also the change in dp modes for DL=0 and DL!=0, and IIRC I read something about '816-specific instructions not always following the emulation rules when executed with E=1. The docs aren't even very good about saying which accesses use PBR or DBR and under which circumstances can cross banks.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...