Acid800: An Atari test suite

[Mclaneinc]

@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.

 

 

Sorry, I should have made it a little more clear that it was a joke, back in the time of the start of Atari++ there was a mini war of words that large chunks of the code were from atari800, eventually the war was settled (I think).

 

Poor brit humour

[phaeron]

Updated version attached... I got a request for SAP format player support, so I hacked up the core a bit with ifdefs and there are now Acid5200 and AcidSAP versions. In addition, there are now standalone XEX versions of each test, source code is included, and I've added an ANTIC DMA pattern test.

 

One thing I should have made more clear: it's not unusual for the XL banking test to fail if you have certain types of RAM expansions that steal the BASIC bit in PIA port B.

Acid800-0.4.7z.zip

[xxl]

GTIA: Special modes collision test...FAIL.

GR.10 $1 collision incorrect: $02

 

[phaeron]

I'd like verification of that behavior on another physical machine before trying to dig into it further; I'm not seeing that on either my 800XL or 130XE, so I can't dig into it here, and I can't think of a good reason as to why only P1 would trip a PF1 collision.

[+Stephen]

Just tested on my NTSC 130XE. It was running the APE Warp OS and a 320KB Peterson upgrade. All 39 tests passed.

[xxl]

i have two atari 130xe (one with vbxe) - both:

 

GTIA: Special modes collision test...FAIL.

GR.10 $1 collision incorrect: $02

 

and one atari 65xe - test pass

[Sheddy]

There were quite a lot of buggy GTIA PAL chips released (GTIA modes show as partly corrupted). I used to have one in my 130XE. If anyone still has a machine with one in, just wondering whether the buggy chips pass the test or not?

[xxl]

Stryker: 800XE

 

GTIA: Special modes collision test...FAIL.

GR.10 $1 collision incorrect: $02

[zaxon]

ok, i do test again, my Atari config exactly like previous but i replace cpu from 816 and back to 6502, all test done without:

 

 

cpu illegal instructions, test failed: a-33 x=55 y=01 p=30 m=11

 

MMU xl banking fail, unable to bank in basic ROM

 

Unfortunatelly i don't have any failed GTIA for test.

[phaeron]

Sheesh... it looks like we're starting to shoot holes in the advice "you need to run your program on a real Atari to make sure it works." It needs to be revised to "many real Ataris...."

 

Again, thanks everyone for all the testing.

 

@xxl:

It seems that this problem is definitely not specific to your hardware. Do you know whether the affected machines display Gr.10 modes properly? It would be excellent if we actually caught bad hardware here, but so far we don't have enough information to say that this is broken behavior. If you need a Gr.10 display test I can whip one up. I tried to figure out what might be going on here, but it escapes me so far. I thought that this might be caused by a bad ANx shifter, i.e. xx01 -> 0101 (PF1), but if that were the case, we should have seen $3 throw a PF3 collision as well (xx11 -> 1111).

 

@zaxon:

Looks like you've managed to expose a weirdness on the 6502 side. If you have time and are so inclined, could you re-run the CPU: illegal instructions test and tell me what the next line says? It should be something like:

 Insn: 93 c4 60

I need this to confirm what specific instruction test failed. It looks like the instruction that failed was $93 SHA (zp),Y. This instruction is commonly thought to involve ANDing against $07, and that's what both Atari800 and my Ataris show, but it looks like that may not be stable/consistent behavior.

[xxl]

i think this is all know in europe GTIA BUG, many 800XE and some last produced ataris has GTIA with corrupt GR.9,10,11.

 

GR.10

colpm0 - color of background (no one gtias can check collision with background)

colpm1 - color1

colpm2 - color2

colpm3 - color3

 

good GTIA can't check collision between this color and PMG but GTIA with bug can. you can check collision between eg. color3 and PM3 or PM0 with color1...

[thorfdbg]

I need this to confirm what specific instruction test failed. It looks like the instruction that failed was $93 SHA (zp),Y. This instruction is commonly thought to involve ANDing against $07, and that's what both Atari800 and my Ataris show, but it looks like that may not be stable/consistent behavior.

This is an unstable instruction, don't count on it. That it ands with 0x07 on some 6502s is just a matter of the fan-out of the games and which gate wins the conflict. Temperature and production variance processes might be included.

 

Greetings,

Thomas

[phaeron]

I need this to confirm what specific instruction test failed. It looks like the instruction that failed was $93 SHA (zp),Y. This instruction is commonly thought to involve ANDing against $07, and that's what both Atari800 and my Ataris show, but it looks like that may not be stable/consistent behavior.

This is an unstable instruction, don't count on it. That it ands with 0x07 on some 6502s is just a matter of the fan-out of the games and which gate wins the conflict. Temperature and production variance processes might be included.

 

Greetings,

Thomas

Thanks, that makes sense. It's remarkably odd how consistent it is between groups of machines, but I'll just disable that instruction test.

[jacobus]

Phaeron - excellent utility - thanks very much!

 

I think you might find this interesting...

 

 

I tested my CTIA 800 and got the following error messages:

 

ANTIC: P/M Graphics DMA

One time P0 data bad at line 8: $04

 

GTIA: Phantom PMG DMA

Phantom DMA byte #1 was not $AD (was $4D)

 

GTIA: Special modes collision test

Playfield collisions detected in Gr.9.

 

GTIA: Psuedo moed E

Cycle 15 test failed = 04

[phaeron]

I declare this a pass, since your machine successfully failed all of the tests that require GTIA modes.

[thorfdbg]

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.

 

 

Sorry to dig out this old topic. I'm just going through the acid test - but I afraid I found some problems here. For example, the test for the invalid opcode 0x0B (ANC) is incorrect (or at least does not correspond to what my hardware does).The test loads A with 0xff, then executes ANC #$55, and tests for carry. Carry is not set on real hardware, but is expected to be set in the acid test. The way how "ANC" works suggests, however, that the result should be C=0. It's simply a combination of AND with ASL, and the C=1 if the result of the AND with the accumulator is negative, not if the result of the ASL is negative.

More trouble: The test suggests that the VCOUNT maximum value should be something different than #$9C (do I misread the text)? Actually, it is here $9c on real hardware (PAL), and this coincides what Atari++ does.

Is there a newer version of the test?

Greetings,Thomas

Edited December 25, 2012 by thorfdbg

[Xuel]

According to the Altirra Hardware Reference Manual section 4.9, the maximum value of VCOUNT, #$9C, can only be observed on cycle 110 of the last line. Is that what you mean?

[phaeron]

Sorry to dig out this old topic. I'm just going through the acid test - but I afraid I found some problems here. For example, the test for the invalid opcode 0x0B (ANC) is incorrect (or at least does not correspond to what my hardware does).The test loads A with 0xff, then executes ANC #$55, and tests for carry. Carry is not set on real hardware, but is expected to be set in the acid test. The way how "ANC" works suggests, however, that the result should be C=0. It's simply a combination of AND with ASL, and the C=1 if the result of the AND with the accumulator is negative, not if the result of the ASL is negative.

 

This is the error that Acid800 reports in the illegal instruction test on Atari++ 1.60:

CPU: Illegal instructions... FAIL.
Test failed: A=55 X=00 Y=00 P=B0 M=00
Insn: 0B 55 60

This is the reference test data:

; insn		 A X Y P M A X Y P M
;AAC #imm (modified AND)
dta $0b,$55,$60, $ff,$00,$00,$30,$00, $55,$00,$00,$30,$00

 

The problem is the P flag, which should be $30 after the instruction and is $B0 in Atari++. The N flag should be the same as the C flag.

 

More trouble: The test suggests that the VCOUNT maximum value should be something different than #$9C (do I misread the text)? Actually, it is here $9c on real hardware (PAL), and this coincides what Atari++ does.

Greetings,Thomas

 

PAL has 312 scanlines, so by the book VCOUNT should count up to 311/2 = $9B, and due to the ANTIC bug it will be $9C for exactly one cycle. If Atari++ has code to return $9C, then this suggests a timing problem.

 

Atari++ 1.60 is failing an earlier timing subtest in the antic_vcount module, so I can't see what might be going on with your dev build. The rollover subtest that checks the end of frame value has two phases. The #1 check is the one that should see the $9C value, and the #2 check should see $00 one cycle later. If the #2 test is failing with $9C it means that Atari++ is reporting the anomalous value too late.

 

Is there a newer version of the test?

 

The latest version of the test is always available at:

http://www.virtualdub.org/altirra.html

 

All tests in the V1.0 test suite pass successfully on real NTSC and PAL machines. I've attached V1.1 beta, which doesn't have changes to the existing tests but does add some new ones.

Acid800-1.1beta.7z.zip

[candle]

Avery, I wouldn't call this ($9c for one cycle) a bug, just a feature of clocked logic

[thorfdbg]

This is the error that Acid800 reports in the illegal instruction test on Atari++ 1.60:

CPU: Illegal instructions... FAIL.
Test failed: A=55 X=00 Y=00 P=B0 M=00
Insn: 0B 55 60

This is the reference test data:

; insn		 A X Y P M A X Y P M
;AAC #imm (modified AND)
dta $0b,$55,$60, $ff,$00,$00,$30,$00, $55,$00,$00,$30,$00

 

The problem is the P flag, which should be $30 after the instruction and is $B0 in Atari++. The N flag should be the same as the C flag.

 

I'm not quite sure what this instruction does. The output doesn't seem to be consistent, at least it doesn't seem to follow a logic I'm right now able to follow. In some cases, the instruction does modify A, in others it does not. Unclear to me.

 

 

PAL has 312 scanlines, so by the book VCOUNT should count up to 311/2 = $9B, and due to the ANTIC bug it will be $9C for exactly one cycle. If Atari++ has code to return $9C, then this suggests a timing problem.

At least it can be $9c, on real hardware. You say this only happens for one cycle, and it is afterwards zero?

[thorfdbg]

The latest version of the test is always available at:

http://www.virtualdub.org/altirra.html

 

All tests in the V1.0 test suite pass successfully on real NTSC and PAL machines. I've attached V1.1 beta, which doesn't have changes to the existing tests but does add some new ones.

 

Thanks for the new test. A couple of comments from my side:

There is at least one problem in the serial input test - you try to provoke a Device NAK by a sector read from sector zero. However, this is not necessarily a NAK. If the floppy is equipped with a "Speedy" floppy enhancer, this will read the zero page of the speedy RAM and will not create an error. However, what is worse that the DISKINTERF vector of the status test before will load the address of DVSTAT (0x2ea) into DSKBUF (0x304,05), and hence SIO will erase 128 bytes in page 2. At least, DSKBUF should be re-loaded.

A second problem is the "NMI disable" test, i.e. the test where a VBI can occur even though bit 6 of NMISTAT is zero. This test is in so far dangerous as it will trigger a reset on the old (non-XL) machines. The reason for this is that OsA/B will first check for an DLI, then for a VBI, but if both fails, the Os assumes that it is a signal coming from the Antic reset input. Thus, this test is not save as the Os does not guarantee to propagate such a VBI at all. There is no good solution, probably copy the Os to RAM (on XL machines), and reprogram the NMI vector yourself.

Also, I personally found that the CPU instructions 0B and 2B do not generate consistent results. I thus decided not to emulate them anymore - not a problem of the test, though.

Last but not least, I'm not quite sure how the player "resizing" actually works. Results on my hardware show rather erratic behaivour, and it is surely not correct that the output of the P/M shift register just continues from where it was left before the resizing attempt. With a bit of luck, one can even enforce GTIA to continue generating data for the player and disabling the shift register alltogether, thus extending the player to all the far right. The bits are then of course simply replicated and no "pattern" can be generated by this. This seems to happen when switching to SIZEP0 3 (4x extension) to SIZEP0 2 (not zero!) which is "officially" simply a 1x extension, but somehow does to seem to do something different. While I seem to be able to reproduce here in my software the effects of my hardware (except for the above wierdo) this does not seem to agree with the output of the acid test. I'm not yet sure exactly what happens there

Otherwise, thanks a lot for the test, many good things in there.

Greetings, and a Happy New Year!

Thomas

[xxl]

I personally found that the CPU instructions 0B and 2B do not generate consistent results.

 

 

what kind of cpu? 6502C? (Sally). What Atari XL/XE you have?

[phaeron]

There is at least one problem in the serial input test - you try to provoke a Device NAK by a sector read from sector zero. However, this is not necessarily a NAK. If the floppy is equipped with a "Speedy" floppy enhancer, this will read the zero page of the speedy RAM and will not create an error. However, what is worse that the DISKINTERF vector of the status test before will load the address of DVSTAT (0x2ea) into DSKBUF (0x304,05), and hence SIO will erase 128 bytes in page 2. At least, DSKBUF should be re-loaded.

 

Oops, good catch -- I'll fix that. This issue is the reason that the test falls back to command $00 if the sector 0 read succeeds, btw.

 

A second problem is the "NMI disable" test, i.e. the test where a VBI can occur even though bit 6 of NMISTAT is zero. This test is in so far dangerous as it will trigger a reset on the old (non-XL) machines. The reason for this is that OsA/B will first check for an DLI, then for a VBI, but if both fails, the Os assumes that it is a signal coming from the Antic reset input. Thus, this test is not save as the Os does not guarantee to propagate such a VBI at all. There is no good solution, probably copy the Os to RAM (on XL machines), and reprogram the NMI vector yourself.

 

No, OS A/B handle this fine as they check for the absence of the reset NMI rather than the presence of the VBI.

 

E791: BIT NMIST	 ;check DLI and VBI bits
E794: BPL $E799	 ;skip if not DLI
E796: JMP (VDSLST) ;dispatch DLI
E799: PHA
E79A: LDA NMIST	 ;load NMI status
E79D: AND #$20	 ;check if reset
E79F: BEQ $E7A4	 ;skip if not
E7A1: JMP WARMSV	 ;do warm start
E7A4: TXA
E7A5: PHA
E7A6: TYA
E7A7: PHA
E7A8: STA NMIRES
E7AB: JMP (VVBLKI) ;dispatch VBI

 

Also, I personally found that the CPU instructions 0B and 2B do not generate consistent results. I thus decided not to emulate them anymore - not a problem of the test, though.

 

Word from the C64 camp is that $0B is sensitive to the data bus -- it appeared to be stable on Ataris from what I've seen, but I could easily disable that part of the test. Acid800 doesn't test $2B. Are you seeing at least deterministic results?

 

I'd recommend still emulating these instructions even if they are unstable, as a real 6502 still runs a deterministic number of cycles and instruction bytes. Quite a number of games accidentally run garbage for short amounts of time even though they don't intend to or use the results and signaling a crash would definitely be an emulation bug.

 

Last but not least, I'm not quite sure how the player "resizing" actually works. Results on my hardware show rather erratic behaivour, and it is surely not correct that the output of the P/M shift register just continues from where it was left before the resizing attempt. With a bit of luck, one can even enforce GTIA to continue generating data for the player and disabling the shift register alltogether, thus extending the player to all the far right. The bits are then of course simply replicated and no "pattern" can be generated by this. This seems to happen when switching to SIZEP0 3 (4x extension) to SIZEP0 2 (not zero!) which is "officially" simply a 1x extension, but somehow does to seem to do something different. While I seem to be able to reproduce here in my software the effects of my hardware (except for the above wierdo) this does not seem to agree with the output of the acid test. I'm not yet sure exactly what happens there

 

The effect is easier to see with the attached test program. What I see on my 800XL and 130XE is that when switching between 2x and 4x sizes, the construction of the shift clock register results in uneven timing for when the shift register begins clocking at the new rate. Haven't heard of a failure on this yet, even with PAL GTIAs, although if you're seeing something different on your hardware I'd be interested in that.

midsprite2a.zip

[thorfdbg]

what kind of cpu? 6502C? (Sally). What Atari XL/XE you have?

 

Yes, it's a standard brand "Sally" in a PAL 800XL. Must be one of the earlier models, chips still have all sockets. "Made in Hong Kong". The instructions are really interesting - sometimes they take the AND of the A register with the immediate opcode, sometimes they don't. This does not at all depend on the processor status. Just load all the registers with identical values, and run over the instruction. Result is *either* AND'ed with the immediate code, and flags are set according to the shift, or the AND'd result never shows up in A.

 

Thus, I classified them as one of the "unstable" opcodes, there are quite a couple of them in the xB family.

 

Greetings, Thomas

[xxl]

Yes, it's a standard brand "Sally" in a PAL 800XL. Must be one of the earlier models, chips still have all sockets. "Made in Hong Kong"

 

 

may I ask you to take a picture of mainboard?