Acid800: An Atari test suite

[phaeron]

Yeah, I don't use insert/delete line in Acid800 and go directly to K: instead of E: for input, so that isn't a problem. I didn't realize that it was possible to crash the Atari by just pushing an 80-char logical line below the screen, though. My OS doesn't have this bug either. Since my terminal needs are minimal and I don't have the spare RAM in 16K for a full S: replacement, I'm just going to swap in a small putchar module in this configuration.

[St(r)yker]

;>

[foft]

Please may I have some help with INC WSYNC? I'm struggling to understand this from a hardware perspective.

 

My understanding:

i) INC does two back to back writes. The first causes RDY to drop. The second instruction still goes ahead next cycle since the 6502 ignores RDY on writes.

ii) The 6502 begins to fetch the start of the next instruction - this is a read so has to wait for RDY to complete.

iii) RDY is raised on cycle 104, so instruction fetch completes then.

iv) The instruction begins execution on cycle 105.

 

I'm hitting this in the acid 800 test 'Antic wsync timing' where it does the INC:

50 2031 85 C9 sta d1 ;108, 109, 110

51 2033 EE 0A D4 inc wsync ;111, 112, 113, 0, 1, 2

52 2036 AD 0A D2 lda random ;3-6

53 2039 85 CA sta d2

 

Now here I'd expect the INC WSYNC to freeze until the next scanline, so the LDA random starts at cycle 104 and reads from RANDOM at cycle 107. I believe the comments in the acid800 source are not correct and wsync is triggered. However it appears that the LDA instruction fetch completes on cycle 105 instead of cycle 104.

 

I see random values of 104-108 as:DE,6F,37,1B,0D and the test is expecting 0D.

 

The Altirra hardware reference manual refers to this somewhat in saying that an INC causes it to always restart at 105, DMA or not. Which ties in, but I'm doubly confused since I can not see how the CPU/RDY affect DMA in the least. Since the DMA is done by stopping the 6502 CLK clock with HALT.

[phaeron]

Yes, the comments are incorrect. The code is checked against a real Atari, but the comments aren't. The 9-bit PRNG sequence is documented in my hardware manual in the Reference section under RANDOM [D20A, R], and the sequence indices for the first three test bytes are 243, 357 (+114), and 472 (+115).

 

The reason that INC WSYNC works to remove this variance is that there is a one-cycle delay before RDY is pulled. That delay is on ANTIC's side, so it is one cycle regardless of whether the next cycle is a DMA or CPU cycle. INC WSYNC's second write cycle either drops into this delay slot or proceeds on the next CPU cycle under RDY.

[foft]

Thank

The reason that INC WSYNC works to remove this variance is that there is a one-cycle delay before RDY is pulled. That delay is on ANTIC's side, so it is one cycle regardless of whether the next cycle is a DMA or CPU cycle. INC WSYNC's second write cycle either drops into this delay slot or proceeds on the next CPU cycle under RDY.

 

Do you mean the second wsync write at the start of the line somehow stops antic from raising the RDY line by 1 cycle?

[phaeron]

No, there's always a one-cycle delay until RDY is asserted (goes active).

[foft]

I'm still confused. More concrete example:

 

Say I do Inc wsync at cycle 27

27: Instruction fetch - reads 0xEE

28: Read address low - 0x0A

29: Read address high - 0xD4

30: Read 0xD40A into reg

31: ALU increases reg. First write cycle of original value to 0xD40A

 

No DMA on cycle 32:

32: Write back reg to 0xD40A

33: fetch next instruction - halted by RDY low.

104:Instruction fetch completes

 

DMA on cycle 32:

33: Write back reg to 0xD40A

35: fetch next instruction - halted by RDY low.

104:Instruction fetch completes

 

So not sure how inc leads to starting up again on cycle 105

 

Sure I'm fundamentally missing the point since I'm not enlightened by a 1 cycle delay in Antic:(

[phaeron]

I think the confusion here is just over cycle numbering: current versions of Acid800 and my Hardware Manual use cycle number 105 as the cycle at which RDY is deasserted and 0 as where missile DMA occurs. I did switch to 104 for !RDY and 113 for missile DMA for a short time, but switched it back due to confusion and because we discovered that using 104 didn't have any better basis in hardware reality (ANTIC's internal counter is actually ~6 off). I fixed up most of the comments, but you might find one or two there that still show execution resuming at 104. The sequences you have are correct and just need the 104s changed to 105s.

[foft]

Ah. I'm doing missile dma at cycle 0 and de asserting RDY at 104. I'll move the RDY de assertion to 105 and see if I get closer...

[foft]

I connected the logic analyser up to my XE and now I see exactly what you mean about the 1 cycle delay.

 

STA addr:

0: read instruction

1: read addr low

2: read addr high

3: write to wsync

4: rdy still high - reads next instruction

5: rdy low - starts reading first parameter of next instruction

 

INC addr:

0: read instruction

1: read addr low

2: read addr high

3: read wsync

4: inc value/write original value to wsync

5: write new value to wsync/rdy still high

6: rdy low - starts reading next instruction

[Faicuai]

Alright, I beefed up the player/missile resizing test in Acid800 to test for the lockup condition. I discovered in the process of doing this that the test didn't actually test the 1x-to-2x and 1x-to-4x cases, which I've added in addition to the new 2x-to-1xalt and 4x-to-1xalt cases. I'd appreciate it if people with XEs tried this version to double-check that this isn't machine-sensitive; I would check it myself except that right now it is too cold in the house for my XE to show alternate timing (no, I am not joking). Tomorrow I might try shoving my XE under a sofa cushion.

 

Other changes in this version are that I've reorganized the memory layout to raise the MEMLO requirement for the standalone tests from $1000 to $1A00 and sped up the annoying ANTIC: DMA pattern test so it doesn't blank out the screen for so long.

 

Thanks for this build...

 

Just a quick question (sorry if it has been already answered):

 

I am working here with Eclipse/WUDSN... and I wonder what Assembler-version/build would be appropriate for changing a couple of lines on Menu.s and re-assembling.

 

All I want to do is to be able to auto-loop to infinity without user intervention, on either one (1) specific tests or all of them. Seems pretty easy to accomplish in Menu.s but I cannot assemble it properly with MADS (nor ASM6).

 

Thanks in advance!

[phaeron]

You should use the included Makefile, if possible. It uses a multi-stage build process with MADS with include paths and defines, so it's not just a matter of loading the .s files and assembling them directly.

[phaeron]

I finally cleaned things up enough to push out version 1.1 final:

 

http://www.virtualdub.org/downloads/Acid800-1.1.7z

 

In addition to updates to Acid800, this now adds a new AcidOS test suite for testing the OS kernel. Currently, it has some tests for the math pack and for CIO.

[Xuel]

The following sequence hangs for me in Altirra 2.50-test5:

 

1) Boot acid800.atr

2) Press a key

3) Press F for "Wait after test failure"

4) Press X for "Exit and run tests"

5) Press a key after "Blocked NMIs...FAIL"

6) Press a key after "Serial Status...FAIL"

 

At this point there doesn't seem to be a way to continue the tests without rebooting.

 

[serj]

beta 11 gives "Serial Status ... PASS"
Use the latest beta.

 

but if before starting the test include the following options:

F for "Wait after test failure"

W for "Wait after each test"

 

emulator hangs after "POKEY: Serial status".

[phaeron]

Amazing how the keyboard doesn't respond when interrupts are masked. Fixed version:

 

http://virtualdub.org/beta/Acid800-1.2beta1.7z

 

[serj]

Avery, planned new update acid test for the emulator?

I noticed an interesting error.

in a stable version 2.60 test passed completely.

in the latest version 2.70 test 20 - one point wrong.

 

error occurs, starting with version 2.70 beta 16.

exactly the same settings.

Edited July 26, 2015 by serj

[phaeron]

This is a bug in 2.70-test -- the code to drop bytes due to missing external clocking is also blocking the SKSTAT input bit. The test is correct. I'll fix it in a later update.

[Caterpiggle]

Hello to phaeron,

 

I was recently tested your best software , ACID800 on my real Atari 800XL NTSC and it only failed at GTIA : Player Overlap. Yes, I was sampled test on PAC-MAN and it seems passed ?? Can you give me more specific games to test on Player Overlap issue ? Thank you for read out...

[phaeron]

5 hours ago, Caterpiggle said:

Hello to phaeron,

 

I was recently tested your best software , ACID800 on my real Atari 800XL NTSC and it only failed at GTIA : Player Overlap. Yes, I was sampled test on PAC-MAN and it seems passed ?? Can you give me more specific games to test on Player Overlap issue ? Thank you for read out...

Do you have the detailed error message? This test checks a case that you're not likely to see in most games, retriggering a player more than once on the same scanline. The impetus for this test was an earlier version of RastaConverter, which was occasionally producing images that didn't display as expected on emulators or real hardware.

 

[Caterpiggle]

ACID800 version 1.1 Beta.

 

1 Failed

GTIA: Player overlap ....FAIL.

 

What is the latest version for ACID800 ? 1.1 Beta or 1.3 ?

[Caterpiggle]

Updated ! I recently forced to change from Altirra ACID800 1.1 Beta to ACID800 1.1 (no BETA AT THIS TIME). It is all PASSED ! Included GTIA: Player Overlap ... Pass.

 

Finally ! So I learned my lesson for today. At least I learned something new for your ACID800 1.1 !

[Mclaneinc]

Here's a newer one, think its the latest..

 

1.2 beta 1

 

 

acid800.atr

 

Link to the full release inc source etc

 

http://virtualdub.org/beta/Acid800-1.2beta1.7z

Edited August 8, 2019 by Mclaneinc

[phaeron]

Acid800 updated to v1.2 on the Altirra website, also attached here. Changes since v1.1:

• Acid800: ANTIC DLI timing test now checks for instruction timing after a DLI is delayed by STA WSYNC.
• Acid800: Fixed some incorrect error messages in the ANTIC P/M graphics DMA test. The tests themselves were OK, but the specific test error was wrong.
• Acid800: Added CPU: Illegal insn timing test.
• Acid800: 65C816 test can now be run on Veronica, if enabled in Options.
• Acid800: Fixed a couple of broken 65C816 indirect addressing tests and also added a check for the WDM instruction and stack page crossing tests.
• Acid800: POKEY init timing test now checks for 1 bits being shifted out when exiting init mode.
• Acid800: Expanded timer timing test to check cycle deadlines around writes to AUDF1-4 and STIMER, as well as two-tone mode resync timing.
• Acid800: Fixed an issue with PIA test not clearing stray interrupts.
• AcidOS: Added more FASC tests.
• AcidOS: Added EXP/LOG tests.
• AcidOS: Added math pack ZP usage checks.
• AcidOS: Added CIO permission tests.

Acid800-1.2.7z

[Irgendwer]

Could someone try this on "THE400 Mini" and post the results here?