Jump to content
phaeron

Acid800: An Atari test suite

Recommended Posts

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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:(

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

  • Like 1

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

 

post-21021-0-38234400-1385955111_thumb.png

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

post-29967-0-80379500-1437931887_thumb.jpg

post-29967-0-24272800-1437931909_thumb.jpg

Edited by serj

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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.

 

Share this post


Link to post
Share on other sites

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 !

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.
Note: Your post will require moderator approval before it will be visible.

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