phaeron Posted October 21, 2010 Share Posted October 21, 2010 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? 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 3 Quote Link to comment Share on other sites More sharing options...
xxl Posted October 23, 2010 Share Posted October 23, 2010 Atari 130 XE + VBXE: GTIA: Special modes collision test...FAIL. GR.10 $1 collision incorrect: $02 Quote Link to comment Share on other sites More sharing options...
rchennau Posted October 23, 2010 Share Posted October 23, 2010 Just wanted to say good work and thanks. It is efforts like this that keep the Atari community alive. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted October 23, 2010 Share Posted October 23, 2010 I'll second that: this is a great idea, and well executed. Altirra certainly mops up the floor with Atari800+. Quote Link to comment Share on other sites More sharing options...
phaeron Posted October 23, 2010 Author Share Posted October 23, 2010 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. Quote Link to comment Share on other sites More sharing options...
candle Posted October 23, 2010 Share Posted October 23, 2010 (edited) Phaeron: You're correct, problem is elsewhere i guess, i'll recheck this on my machines Edited October 23, 2010 by candle Quote Link to comment Share on other sites More sharing options...
xxl Posted October 24, 2010 Share Posted October 24, 2010 @phaeron: Electron says that VBXE has nothing to do with it Quote Link to comment Share on other sites More sharing options...
zaxon Posted October 24, 2010 Share Posted October 24, 2010 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, Quote Link to comment Share on other sites More sharing options...
miker Posted October 24, 2010 Share Posted October 24, 2010 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. Quote Link to comment Share on other sites More sharing options...
phaeron Posted October 24, 2010 Author Share Posted October 24, 2010 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 Quote Link to comment Share on other sites More sharing options...
xxl Posted October 24, 2010 Share Posted October 24, 2010 (edited) both of the tests fail --- with vbxe off fails too Edited October 24, 2010 by xxl Quote Link to comment Share on other sites More sharing options...
phaeron Posted October 24, 2010 Author Share Posted October 24, 2010 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 Quote Link to comment Share on other sites More sharing options...
zaxon Posted October 24, 2010 Share Posted October 24, 2010 new test, Phantom PMG DMA fail, MMU xl banking fail rest done, 2 skipping Quote Link to comment Share on other sites More sharing options...
xxl Posted October 24, 2010 Share Posted October 24, 2010 atari 130 xe pal, stock os. MxPF: 02 02 02 02 Quote Link to comment Share on other sites More sharing options...
tebe Posted October 24, 2010 Share Posted October 24, 2010 (edited) acid800-0.1 Passed 38, Failed 0, Skipped 0 MxPF: 00 00 00 00 VBXE 1.20, 65XE Edited October 24, 2010 by tebe Quote Link to comment Share on other sites More sharing options...
phaeron Posted October 24, 2010 Author Share Posted October 24, 2010 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? Quote Link to comment Share on other sites More sharing options...
laoo Posted October 25, 2010 Share Posted October 25, 2010 Actually AFAIK there shouldn't be any differences in timings between Sally and 65c816. Of course it does not apply to 65C02. Quote Link to comment Share on other sites More sharing options...
phaeron Posted October 25, 2010 Author Share Posted October 25, 2010 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. Quote Link to comment Share on other sites More sharing options...
Mclaneinc Posted October 25, 2010 Share Posted October 25, 2010 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 Quote Link to comment Share on other sites More sharing options...
fox Posted October 25, 2010 Share Posted October 25, 2010 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. Quote Link to comment Share on other sites More sharing options...
phaeron Posted October 25, 2010 Author Share Posted October 25, 2010 @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. :-/ Quote Link to comment Share on other sites More sharing options...
Rybags Posted October 25, 2010 Share Posted October 25, 2010 Shouldn't INC WSYNC behaviour depend on whether the next cycle is DMA after the initial writeback? Quote Link to comment Share on other sites More sharing options...
phaeron Posted October 25, 2010 Author Share Posted October 25, 2010 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. :-/ Quote Link to comment Share on other sites More sharing options...
laoo Posted October 26, 2010 Share Posted October 26, 2010 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. Quote Link to comment Share on other sites More sharing options...
phaeron Posted October 26, 2010 Author Share Posted October 26, 2010 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.