cas files not working in atirra

[ijor]

 

Sure, but sometimes those absolute cycles numbers are quite helpful so you don't have to add all relative cycles by yourself . For me, the most confusing part about this is that the docs use different numbering/reference schemes and often don't mention which scheme they actually employed.

 

Yes, I agree. When I'm saying relative numbers, I don't mean that you must use only the distance between subsequent events, and then needing to add all the cycles. It is correct to have a chart or a table with all cycle numbers specyfing a distance to a common reference event. But because the reference (which you might call cycle 0 or not) is just conventional, this still means relative and not absolute.

 

Furthermore, there is only one way to have unambiguous timing. Is to use waveforms. Even relative cycle numbers are sometimes ambiguous. Relative cycles are ok to separate two events of an indentical type. Say, it is unambiguous to specify that player 0 DMA happens two cycles later than missiles DMA. But once you start to relate different type of events, you are calling for trouble. e.g., let say you want to specify how many cycles are between end of wsync, and say, missile DMA. It is a problem. Exactly which cycle do you mean when you say "end of wsync"? . It is open to interpretation, there is more than just one unique valid answer.

 

 

I was interested where the 1-cycle shift in the timing charts could have come from. Without having a closer look at GTIA or ANTIC internals I'd just blame most of the ~400ns delay on GTIA and/or the communication between ANTIC and GTIA.

 

Well, I beg to differ. But I blame it that you are trying to find a relation that doesn't exist.

 

Why do you care about that ~400ns delay? It has no significance whatsoever. Let's assume that some versions of GTIA exhibit a delay of 4.000 ns (4 ms) instead of 400ns. That's 10 times as big. Does it matters? Not at all. There is no way that you could detect the different delay by software. It won't affect the display in anyway, and you couldn't note it at all.

 

Furthermore, why do you measure SYNC at the GTIA output? Why not to measure at the modulator output (surely will have additional delay)? Why do you think one is more correct than the other? I would say that none is correct.

 

What I am trying to say, is that there is no interesting or relevant timing relation between the video output signals and the signals at the main bus.

 

antic.pdf page 5 mentions that HSYNC is active (LOW) in color clocks 0-15. In the CPU cycle where CSYNC goes low ANTIC does it's first PM DMA.

 

You are again mixing oranges and apples. It is, IMHO, wrong to consider that CSYNC goes low in any CPU cycle. CSYNC is not clocked by the the cpu clock. And, again, it doesn't matter at all when CSYNC changes in relation to the activity in the CPU bus.

[ijor]

That would be true, except that Atari also put the ending position for STA WSYNC on the chart as well,...

 

You are very right. But I think that Atari made a mistake there. WSYNC stuff, IMHO, doesn't belong to this chart. It makes more sense in the other chart that includes DMA and NMI timing. And mixing both charts is the wrong approach.

 

What isn't clear to me is whether the association between the display coordinates and the DMA/WSYNC cycles is correct in any way.

 

What I am saying is that, simply, there is no direct way to associate them. There is no meaningful timing relation between what happens at the CPU bus (DMA, WSYNC, NMI) and what happens at the video output.

 

Wow... this ties lots of things together nicely. If I understand it, what we've got is:

• The vertical counter increments at the start of horizontal blank.
  
• Special DMA starts at the beginning of horizontal sync.
  
• Special DMA ends and DLIs are triggered at the end of horizontal sync.

l feel a bit guilty that I am the "contrarian" here , but i think this is more a wishful thinking (to tie things nicely), than an actual scientific fact.

 

What do you mean by the exact cycle where the vertical counter increments? There isn't an unique answer to this question. I can consider several cycles that would all qualify as correct answers. I know you like to use the concept of "observable behaviour". That is a great concept, and it is extremely useful because it reflects the programmer point of view. So, using observable behaviour, you might define that the cycle where vcount increments, as the first cycle that ANTIC would output the new value on the bus, when read by the CPU. But what is the "observable behaviour" of the horizontal blank? I would say there is no direct observable behaviour because blanking doesn't happen on the cpu bus. Then, I ask, how can you say that both events happen at the same cycle? It doesn't make sense to me.

 

And it does even less sense when we talk about horizontal sync. Of course that there is no observable behaviour of the horizontal sync whatsoever. Horizontal sync isn't actually an ANTIC concept at all. It is a pure GTIA internal concept and you couldn't care less about the exact timing relation between horizontal sync and DMA.

 

As I said in my reply to Hias. You could shift GTIA video output timing (including sync) by many cycles, and nothing would change at all. Certainly there is no observable behaviour of the timing relation between the video output and the CPU bus activity.

[HiassofT]

It is correct to have a chart or a table with all cycle numbers specyfing a distance to a common reference event. But because the reference (which you might call cycle 0 or not) is just conventional, this still means relative and not absolute.

Sure, I totally agree with you, and actually it's all about convention. I was just wondering if there was some rationale behind (previously) choosing "cycle 0" or if that was choosen arbitrarily.

 

Other areas have similar issues, just consider the definition of 0° longitude (obviously choosen absolutely arbitrarily, just by convention), or the definition of 0° celsius (historically backed up by freezing point of water).

 

I was hoping that I could find some facts that would back up the one definition (missile DMA = 0) or the other (display list DMA = 0), for example if the falling edge of some signal would have been within some, lets say, +/- 50ns area around the falling edge of PHI2. In this case we could have easily said: well, it would be natural to call that cycle to be cycle 0. Of course, if no tight match can be found (like the 400ns delay on CSYNC) the setting of "cycle 0" would be quite arbitrary.

 

I was interested where the 1-cycle shift in the timing charts could have come from. Without having a closer look at GTIA or ANTIC internals I'd just blame most of the ~400ns delay on GTIA and/or the communication between ANTIC and GTIA.

 

Well, I beg to differ. But I blame it that you are trying to find a relation that doesn't exist.

Sorry, my fault. For some reason I thought that ANTIC would control HSYNC directly, but I was wrong (ANTIC sends a HBLANK command to GTIA, GTIA generates front porch, sync and back porch).

 

But, still, video and CPU timing aren't completely unrelated:

 

The datasheets specify maximum delays from OSC to F0O and from F0O to PHI0 (each 130ns max). With a typical delay of ~20nS from PHI0 to PHI2 (no specs here, sorry), this matches quite exactly what I've seen on my Atari - falling edges of OSC and PHI2 are in sync. Of course, on other Ataris the phase might be shifted a little bit, as the 130ns is a max spec.

 

This leaves us with the delays inside ANTIC and GTIA, which are predictable. Sure, they aren't specced in any way, and Atari could have changed them without breaking too much, but it looks like they didn't do that, so they seem to be constant on all Ataris.

 

Furthermore, why do you measure SYNC at the GTIA output? Why not to measure at the modulator output (surely will have additional delay)? Why do you think one is more correct than the other? I would say that none is correct.

Well, because my logic analyzer can't really cope with RF output :-)

 

I ran a test this weekend and checked the luminance output of the monitor jack (triggering at the beginning of HSYNC) against PHI2 with my scope: I observed a phase shift of 460ns +/- 20ns on 3 of my Ataris (460nS on my 800XL, 440ns on a 600XL and 480ns on a 130XE). This is what I had expected, 400ns at CSYNC of GTIA plus ~60ns delay from the 4050.

 

Since we both like waveforms so much, let's have a look at the first pixels in ANTIC mode E, in standard width, and try to identify which CPU clock cycle could be the "color clock 48" (first pixel). I've aligned my old traces (including the LUMA lines on GTIA) with the later traces (including ANx and OSC):

For convenience, I'll just number the cycles with the ones visible in the screenshot, cycle 0 being the first visible one (so they aren't absolute, just relative numbers).

0: CPU cycle

1: ANTIC fetches data for color clocks 48-51

3: ANTIC fetches data for color clocks 52-55

4 + 230ns: ANTIC sets ANx to display PF0

4 + 390ns: OSC rises, GTIA picks up AN data

5 + 400ns: GTIA sets LUMx output change from background to PF0 value

5 + ~460ns (approximately, guessed): luminance output of monitor jack changes from background to PF0

 

So, yes, it's really hard to find out which CPU cycle could correspond to color clock cycle 48. We could pick almost any of 1-6 (6 because 5+ ~460ns is almost 6). The closest match, display-wise, would be 4+230ns, which is almost the center of cycle 4, but this makes things even worse since aligning to the middle of a cycle is prone to one person rounding up (5) and the other rounding down (4).

 

This means: the tests lead to nothing. So far we also don't have any hard evidence what Atari could have meant with the numbers in the Hardware Manual, and several interesting pages in ANTIC.PDF, which might (or might not) have helped are missing.

 

I'm also quite unsure what to do with a lot of the information I've previously read (here on the forum and elsewhere), most of the info now seems to have a +/- 1 cycle error: IIRC most people had cycle 105 (as mentioned in Antic_Timings.txt) as the first unhalted cycle after WSYNC, but then also referenced cycle 9 to be the one where the NMI starts off.

 

I could remember wrongly, or also be confused, but this doesn't seem to be correct. It looks like Antic_Timings.txt has the "special" DMA cycles (PM, display list) one cycles too early, but the relation between WSYNC (105) and display/refresh cycles is correct.

 

The cycle numbers in the Antic_Timings.txt (with exception of the wrong "special" cycles) also seem to match the numbers in the old (04/25/10) Altirra Hardware Reference Manual (I only checked the ANTIC E timings, though, so I could be wrong).

 

The conclusion of all this?

 

Yes, ijor was correct from the beginning, there's no direct relation between ANTIC and CPU timing that can be observed to be some kind of "natural". So any mapping is somewhat arbitrary.

 

@phaeron: feel free to return to the older numbering scheme (missile DMA = 0) in your hardware reference manual. It's the most accurate description we've got (lots of kudos for it, BTW, I really like and use it a lot!), and putting it in sync with Altirra sure should help you a lot.

 

BTW: could you maybe add ticks to the horizontal scale, or even better, put a raster grid at the background of your DMA timing charts in the manual? This would make manual cycle counting a lot more easier.

 

BTW2: sorry for derailing this thread so much, my ramblings didn't have to do anything with CAS files...

 

so long,

 

Hias

[ijor]

But, still, video and CPU timing aren't completely unrelated:

 

Of course they are. What I meant is that the relation is not relevant and isn't really meaningful for our purposes.

 

Since we both like waveforms so much, ...

 

Indeed I do And I thank you very much for your very useful traces.

 

This means: the tests lead to nothing. So far we also don't have any hard evidence what Atari could have meant with the numbers in the Hardware Manual, and several interesting pages in ANTIC.PDF, which might (or might not) have helped are missing.

 

@phaeron: feel free to return to the older numbering scheme (missile DMA = 0) in your hardware reference manual.

 

My point is that, even if we find some evidence about why exactly Atari used those numbers, it would still be arbitrary.

 

There are (should be) two separated horizontal timing tables. One is related to the CPU bus activity, the other to the GTIA video output. You do can mix them in a single chart if you insist (not sure how useful it would be). But if you do so, they still need to be distinguished one from the other (say, using two different colors), and it must be clear to the reader than the relation is, at best, conventional (even if it is a convention used by Atari).

 

(Altirra hardware reference manual ... It's the most accurate description we've got (lots of kudos for it, BTW, I really like and use it a lot!)

...

BTW2: sorry for derailing this thread so much, my ramblings didn't have to do anything with CAS files...

 

+1 to both

[DutchC64]

wow dudes, You are really getting in to this....nice.

 

I wish I had more knowledge when it comes to the Atari....