Has anyone Genlocked 2 Ataris together?

[peteym5]

You would probably have to get the computers to network through a PBI/ECI or a cart device to monitor the vsync and when one is about to start generating a new frame, the other machine will start one on like a reset. Have to look at the Antic/GTIA specs and see if there is a way to halt the output from these chips and restart it at a desired time. Both computers need need the video timed exactly. However, like Rybags stated, one Atari can easily fall out of sync from another. Another ideal is do some internal modifications and network the Antic/GTIAs from each machine similar to the dual Antic/GTIA circuits. Think they did some type of Exlusive OR operation to synchronize them.

[Rybags]

 

Well, so much for that idea.

 

Looks like I've established 2 things here...

 

- Holding RESET on the 800XL appears to make absolutely no difference to the VSync timing. Bottom graph is 800XL during/after holding Reset button for a few seconds.

 

- The timing between my 130XE and 800XL appears to drift... gotta run a 5 minute sampling and I'll get back with confirmation or otherwise on that one.

 

I think to verify this properly, I need to rig up both machines simultaneously being sampled in "stereo" - I'm feeding Luma output into the sound card input. At least having 2 going at once would guarantee that if any funny business was happining at the PC side that it'd have the same effect on both samples.

[ijor]

I am not sure if you were joking or not.

 

Do you really expect that the clocks in two computers wouldn't drift just because their crystal has the same nominal value?

[Rybags]

I was expecting some drift, but not as pronouced as I noticed.

 

Then again, it's all inconsequential since Resetting the machine has no effect on the frame timing.

[JayoK]

Here is some crap Ive been working on to document the "phase 2 clock enigma" that seems to plague various atari expansion configurations..

 

Off Topic...

 

What's the enigma here? Is it the drift between each of the clock phases on each expansion? If it is, isn't that to be expected? As the signal passes though different logic, different PCB tracks (capacitance) will the signal vary anyway?

 

(BTW Not being smart just trying to understand the diagrams. Thanks)

[MEtalGuy66]

Here is some crap Ive been working on to document the "phase 2 clock enigma" that seems to plague various atari expansion configurations..

 

Off Topic...

 

What's the enigma here? Is it the drift between each of the clock phases on each expansion? If it is, isn't that to be expected? As the signal passes though different logic, different PCB tracks (capacitance) will the signal vary anyway?

 

(BTW Not being smart just trying to understand the diagrams. Thanks)

 

Variations in the phase 2 clock from one machine to another has long been known to cause various stability & functional related problems with various hardware devices. You can read Bob Puff's "XL/XE Stability" doc on CSS website, as a starting point. But What I am doing is comparing the phase 2 clock signal at various points throughout the system on various models of XL/XE machines, with various expansions installed, and with various CPU part numbers installed. Im not saying anything definitive about it at this point, becuase I havent tested enough varying configurations. The reason I uploaded the picture here, was to show an example of how close/consistant the clock signals appear from one machine to another. You can however read in the "auto-meaurement" pane in the top of each screen shot that the frequency does vary by several khz from one machine to another.

[+poobah]

Also worthy of note,

 

Different machine designs derivie their clock in various ways,

The XEs use freddie to divide down a 14.318 something MHz clock, older machines use the NTSC colorburst crystal and divide it by 2

 

These divisions aren't going to match exactly.

[Rybags]

But the (desired) resultant clock rate is ~ the same.

 

It's kinda moot now given the barriers already mentioned.

 

 

Just think of it as me having a "Carmel moment".

[ijor]

Variations in the phase 2 clock from one machine to another has long been known to cause various stability & functional related problems with various hardware devices. You can read Bob Puff's "XL/XE Stability" doc on CSS website, as a starting point. But What I am doing is comparing the phase 2 clock signal at various points throughout the system on various models of XL/XE machines, with various expansions installed, and with various CPU part numbers installed. Im not saying anything definitive about it at this point, becuase I havent tested enough varying configurations.

 

Your scope is showing a very significant delay at the PLL output. The first trailing edge on the first capture has more than 50ns delay between the CPU and PLL outputs.

 

However the most important measurement is missing. The clock skew is not important by itself, what is important is the relation between data and clock. It is ok if the clock arrives 100ns later, as long as the data arrives similarly later as well. If the problem is what Bob mentions at the CSS website, then the main issue is the data hold time. So you need to measure both data and clock at the same time, ideally at the same chip.

 

Assuming the clock delay is indeed too much, then the ideal solution is probably to phase shift the PLL output a few nanoseconds backwards. Another possible solution for hold violations could be to delay the data.

 

The reason I uploaded the picture here, was to show an example of how close/consistant the clock signals appear from one machine to another. You can however read in the "auto-meaurement" pane in the top of each screen shot that the frequency does vary by several khz from one machine to another.

 

Yeah, seems people misinterpreted Ken's post. He is measuring clock skew, this has nothing to do with clock drift.

[MEtalGuy66]

Variations in the phase 2 clock from one machine to another has long been known to cause various stability & functional related problems with various hardware devices. You can read Bob Puff's "XL/XE Stability" doc on CSS website, as a starting point. But What I am doing is comparing the phase 2 clock signal at various points throughout the system on various models of XL/XE machines, with various expansions installed, and with various CPU part numbers installed. Im not saying anything definitive about it at this point, becuase I havent tested enough varying configurations.

 

Your scope is showing a very significant delay at the PLL output. The first trailing edge on the first capture has more than 50ns delay between the CPU and PLL outputs.

 

However the most important measurement is missing. The clock skew is not important by itself, what is important is the relation between data and clock. It is ok if the clock arrives 100ns later, as long as the data arrives similarly later as well. If the problem is what Bob mentions at the CSS website, then the main issue is the data hold time. So you need to measure both data and clock at the same time, ideally at the same chip.

 

Assuming the clock delay is indeed too much, then the ideal solution is probably to phase shift the PLL output a few nanoseconds backwards. Another possible solution for hold violations could be to delay the data.

 

The reason I uploaded the picture here, was to show an example of how close/consistant the clock signals appear from one machine to another. You can however read in the "auto-meaurement" pane in the top of each screen shot that the frequency does vary by several khz from one machine to another.

 

Yeah, seems people misinterpreted Ken's post. He is measuring clock skew, this has nothing to do with clock drift.

 

Yeah Im more intetrested in knowing what happens to PHI2 (in relation to PHI0) with various CPUs, Machine types, and installed expansions.. Its not my responsibility to "fix anyones machine"... I just want to Identify the "worst offenders.." so I can know not to blame the PBI device..

 

The MIO works perfectly stable with all the systems shown in those diagrams.. Those are not "problem configurations" so to speak.. As I said.. Im still testing.. and I have MANY combinations left to test...

[GameEngine]

That is mine ...

Rick D.

 

http://www.a8maestro.com/atari/info/studio/studio.htm

Allan

 

Would it be possible that you take a picture of the innards?

[ijor]

Yeah Im more intetrested in knowing what happens to PHI2 (in relation to PHI0) with various CPUs, Machine types, and installed expansions.. Its not my responsibility to "fix anyones machine"... I just want to Identify the "worst offenders.." so I can know not to blame the PBI device..

 

I see. But again, I don't think the relation between PHI0 and PHI2 is important. The whole system, and the bus in particular is driven by PHI2, not by PHI0. As far as I can see, PHI0 doesn't drive anything at all except the CPU, and the CPU timing is based on reference to PHI2 (and PHI1), not on PHI0.

 

Anyway, I wouldn't expect different CPUs to produce significant differences on the clock generation. Do you have scope captures of those "problematic configurations" ? Conceivable, different systems might exhibit a somewhat significant difference in the raise/fall times. But what I would expect to be much more significant is different CPU data hold times.

 

The 6502 minimal hold time specification is quite small (30ns), possibly too short in many cases. It works because the typical case is much bigger and normally it is never as small as the 30ns minimum. But some CPUs might produce a hold time closer to the min specification, and then it might be problematic.

[MEtalGuy66]

Yeah Im more intetrested in knowing what happens to PHI2 (in relation to PHI0) with various CPUs, Machine types, and installed expansions.. Its not my responsibility to "fix anyones machine"... I just want to Identify the "worst offenders.." so I can know not to blame the PBI device..

 

I see. But again, I don't think the relation between PHI0 and PHI2 is important. The whole system, and the bus in particular is driven by PHI2, not by PHI0. As far as I can see, PHI0 doesn't drive anything at all except the CPU, and the CPU timing is based on reference to PHI2 (and PHI1), not on PHI0.

 

Anyway, I wouldn't expect different CPUs to produce significant differences on the clock generation. Do you have scope captures of those "problematic configurations" ? Conceivable, different systems might exhibit a somewhat significant difference in the raise/fall times. But what I would expect to be much more significant is different CPU data hold times.

 

The 6502 minimal hold time specification is quite small (30ns), possibly too short in many cases. It works because the typical case is much bigger and normally it is never as small as the 30ns minimum. But some CPUs might produce a hold time closer to the min specification, and then it might be problematic.

 

Yep.. Thats a good point, indeed. The obvious problem is the relationship between clock & data.... not clock & modfied clock.. And Ill definitely go there next... But for completeness sake, and since CSS really started this whole "ballgame" by "anding" PHI0 with PHI2, I really want to fill in this part of the "big picture" as well... You see, Ive seen/heard of quite a few instances where the CSS reccomended "Stability Mod" did not improve things.. So, in the interest of fully documenting it from both ends, and with the hopes of clarifying the exact true nature of the issue, "across the board" on the XL/XE range of machines & related expansions.... And possibly with the hope of comming up with a "sure thing" fix.... Or at least a really good definition of the exact range & nature of the problem and effected machines/CPUs/configurations... This is the first comparisson Im doing...

 

I'll be sure and publish ALL the results I get, for everyone's analysis/consideration/benefit...

Edited August 29, 2008 by MEtalGuy66

[dmlloyd]

You would probably have to get the computers to network through a PBI/ECI or a cart device to monitor the vsync and when one is about to start generating a new frame, the other machine will start one on like a reset. Have to look at the Antic/GTIA specs and see if there is a way to halt the output from these chips and restart it at a desired time. Both computers need need the video timed exactly. However, like Rybags stated, one Atari can easily fall out of sync from another. Another ideal is do some internal modifications and network the Antic/GTIAs from each machine similar to the dual Antic/GTIA circuits. Think they did some type of Exlusive OR operation to synchronize them.

 

That's the only way to put two Ataris in to hard sync. The "slave" phi2 would be forced high whenever a clock occurs during a time period when the composite-sync outputs differ.

[+bob1200xl]

The only way to put two Ataris in sync is to use one clock for both and clip one PH0 to match the other at vertcal sync time. You just can't use both clocks unless you phase lock them, somehow. Why bother? Use one clock...

 

As for this system timing stuff, you have four possible modes of data transfer during eight different clock periods from four main sources, CPU, I/O chips, cartridge, and memory. (you could throw the PBI in there, too) When reading, the source has to keep the data on the buss long enough for the destination to 'catch' it. And, all the other sources have to stay off the buss so they don't collide with the legitimate sender. And,,, a million other things. There are 'many' possible conflicts and opportunities to step on the data and address.

 

Bob

 

 

You would probably have to get the computers to network through a PBI/ECI or a cart device to monitor the vsync and when one is about to start generating a new frame, the other machine will start one on like a reset. Have to look at the Antic/GTIA specs and see if there is a way to halt the output from these chips and restart it at a desired time. Both computers need need the video timed exactly. However, like Rybags stated, one Atari can easily fall out of sync from another. Another ideal is do some internal modifications and network the Antic/GTIAs from each machine similar to the dual Antic/GTIA circuits. Think they did some type of Exlusive OR operation to synchronize them.

 

That's the only way to put two Ataris in to hard sync. The "slave" phi2 would be forced high whenever a clock occurs during a time period when the composite-sync outputs differ.

[ijor]

That's the only way to put two Ataris in to hard sync. The "slave" phi2 would be forced high whenever a clock occurs during a time period when the composite-sync outputs differ.

 

That is a very good idea.

 

I wonder however what would be the exact behavior if you would stop the clock for a full frame or so. These chips, including the CPU, are not fully static and the behavior might be not 100% predictable if you stop the clock for too long. But of course, instead of stopping the clock in one long period, you could do that in small steps.

 

This still doesn't give you a perfect sync between two computers. You sync the video signals, but you still don't know if the frame displayed by one corresponds to exacly the frame displayed by the other. In some cases you might not care, but you definitely do if you want to do some of the ideas raised here, such as interlacing even/odd frames.

 

Btw, I guess you mean the Oscilator signal, and not Phi2.