DMACTL playfield start timing on 800s

[phaeron]

Can I impose on some people who have 800s?

 

While working on some updates to Acid800, I've run into an odd issue with the playfield start timing test running differently on 800 vs the XL/XE/400 machines that I have. Specifically, the deadline for changing the low two bits of DMACTL near the start of playfield DMA seems to be one clock earlier on the 800 vs. the two 800XLs, one 130XE, and one 400 machine that I have. Now, the 800 is slightly unstable, but this failure is odd because it's deterministic and none of the other tests fail, so it's not clear whether this is an actual difference or a hardware stability problem. If it isn't an unstable hardware problem, it implies a timing issue in ANTIC which would be more odd, but not unprecedented. The playfield stop tests don't show the same problem, interestingly.

 

Could people run the two attached tests and see which ones pass on their hardware? It runs a series of cycle-precise DMACTL write tests one cycle apart using collision detection and prints pass/fail depending on the result. The _late test is the one that Acid800 has used for a long time and which passes on the 800XLs/130XE/400, but fails on my 800. The _early test is adjusted one cycle earlier and passes on the 800 but fails on the 400/XL/XEs. I'm interested in finding out if other 800s show similar behavior. Thanks in advance.

 

antic_pfstarttiming_early.xex antic_pfstarttiming_late.xex

[_The Doctor__]

I'd take it a step further and test on an 800 with Sally and one without, this would help determine a hardware and OS combination issue perhaps.

[TGB1718]

Ran the tests on my 800 which has Incognito installed.

 

Antic_late :- Antic: Playfield start timing...Pass

 

Antic_early:-Antic:Playfield start timing (early).

..FAIL.

Character mode DMACTL late test failed: stride=16

hope this helps,

my 800 is a late 1981 model

 

[glurk]

My results are same as TGB's above.  And it's the same result on both my old 800 and my newer 130XE.

 

[ijor]

Antic does have some synchronization issues that might lead, conceivable, to variable timing, or even a non-deterministic behavior. But I don't think this can happen in this particular case.

 

In the first place I would swap ANTIC to see if the different timing follows this particular chip or the computer. Even though I assume there isn't any timing difference between ANTIC revisions, it might still be interesting to check.

 

Perhaps most important, especially considering the stability issues on that 800, is to confirm the hardware behavior without relying on something like collision. I am thinking that, perhaps, something might be affecting GTIA, or the ANTIC-GTIA interface, and not exactly the playfield DMA start timing. If the computer have clocking issues, this is more likely to be affected. I seem to remember that you have a logic analyzer, so you should be able to check the timing directly.

[phaeron]

It's definitely an ANTIC issue. The test works by measuring the displacement in the memory scan counter in a subsequent line using collision detection. The visual mode of the test shows an obvious shift in the lines displayed on screen, which is more than would be expected if the ANx interface were involved. At least it looks pretty likely that this is an issue specific to this machine, so I can proceed with releasing the updated tests.

 

The issue with probing the 800 is that I have to disassemble the whole fricking machine to get to the CPU board, but swapping chips with one of the XL/XE machines probably next to track this down.

 

[_The Doctor__]

two different antics with different refresh timing to choose from and two different cpu type boards to choose from.

[Irgendwer]

2 hours ago, phaeron said:

It's definitely an ANTIC issue. The test works by measuring the displacement in the memory scan counter in a subsequent line using collision detection. The visual mode of the test shows an obvious shift in the lines displayed on screen, which is more than would be expected if the ANx interface were involved. At least it looks pretty likely that this is an issue specific to this machine, so I can proceed with releasing the updated tests.

I just like to show my appreciation how pedantic you track down causes for every detail of the machine.

This is more than outstanding and goes far beyond what is the usual standard for emulator creators (if there is something like that... ).

Edited November 28, 2022 by Irgendwer

[Faicuai]

On 11/26/2022 at 7:45 PM, phaeron said:

Can I impose on some people who have 800s?

 

While working on some updates to Acid800, I've run into an odd issue with the playfield start timing test running differently on 800 vs the XL/XE/400 machines that I have. Specifically, the deadline for changing the low two bits of DMACTL near the start of playfield DMA seems to be one clock earlier on the 800 vs. the two 800XLs, one 130XE, and one 400 machine that I have. Now, the 800 is slightly unstable, but this failure is odd because it's deterministic and none of the other tests fail, so it's not clear whether this is an actual difference or a hardware stability problem. If it isn't an unstable hardware problem, it implies a timing issue in ANTIC which would be more odd, but not unprecedented. The playfield stop tests don't show the same problem, interestingly.

 

Could people run the two attached tests and see which ones pass on their hardware? It runs a series of cycle-precise DMACTL write tests one cycle apart using collision detection and prints pass/fail depending on the result. The _late test is the one that Acid800 has used for a long time and which passes on the 800XLs/130XE/400, but fails on my 800. The _early test is adjusted one cycle earlier and passes on the 800 but fails on the 400/XL/XEs. I'm interested in finding out if other 800s show similar behavior. Thanks in advance.

 

antic_pfstarttiming_early.xex 2.54 kB · 7 downloads antic_pfstarttiming_late.xex 2.53 kB · 6 downloads

 

Early-version fails on all of my 800 units. Late-version passes on all.

[ijor]

16 hours ago, phaeron said:

It's definitely an ANTIC issue ... The issue with probing the 800 is that I have to disassemble the whole fricking machine to get to the CPU board, but swapping chips with one of the XL/XE machines probably next to track this down.

Would be interesting to see what happens when you swap ANTIC chips.

 

14 hours ago, _The Doctor__ said:

two different antics with different refresh timing to choose from and two different cpu type boards to choose from.

AFAIK all ANTIC versions have the same refresh timing. The difference between the "old" and the "new" ANTIC (if that's what you meant) is the width of the refresh address counter.

[Rybags]

Yeah, different refresh timing would screw up plenty of software.

 

Next questions from me would be does this difference cause any glitches or different behaviour with existing software and could it be exploited for any useful purpose - e.g. the legendary shifted GTIA pixels trick.

[VinsCool]

I tried the tests on all my machines: NTSC 800, NTSC 800xl, PAL 800xl.

They all passed the Late Test, and failed the Early Test.

I made sure to test each machine at least twice, just in case of a fluke, but they all gave the exact same result each time.