LA traces on interesting video signals

[troed]

One thing that I yet don't fully understand, is how and why GLUE-MMU wakestates affect the shifter. I need to redo some of my old research, because I did it based on two wakeup modes only. Somebody have the LA traces performed by DIO capturing the four wakestates? They don't seem to be here in the forum. He posted a few traces, but not the ones that show the different wakestates.

What signals do you want captured? A while back I decided it would be fun to have an LA so I bought one. I've captured WS1 and WS2 from my Mega ST below, it's a bit difficult to get it into WS3 and WS4 but I will power cycle until I succeed once I know what signals are of interest

Examples attached. At 400MHz I can only capture four signals, then I need to go down some in speed for every new block of signals I add until I reach the maximum of 16 at 100MHz. Of course, if the 32MHz clock isn't interesting then it should accurately get 8MHz and below with all probes used.

The .dsl files (64k captures) should be loadable in DSview* - I guess you might want to look at the end of lines instead of just the beginning as in the screenshots. Also, these were just standard medium resolution desktop lines, no fullscreens etc. I can of course do those

WS2_cold.png

WS1.png

DE-to-LOAD 3 CPU cycles (WS2) and 6 (WS1) respectively easily seen.

/Troed

*) http://www.dreamsourcelab.com/download.html

[ijor]

What signals do you want captured? A while back I decided it would be fun to have an LA so I bought one. I've captured WS1 and WS2 from my Mega ST below ...

Many thanks Troed. But to be honest, I got full captures of all the wake states since the message you quoted.

At this time I might be more interested in some Shifter wakeup traces. Do you happen to have an IMP Shifter? Seems it is slightly different than older Shifter chip.

[troed]

Many thanks Troed. But to be honest, I got full captures of all the wake states since the message you quoted.

At this time I might be more interested in some Shifter wakeup traces. Do you happen to have an IMP Shifter? Seems it is slightly different than older Shifter chip.

Ah, great to hear you already have them My Mega ST has the regular -38 Shifter, but it's socketed so I could always get an IMP (atarifreakz has them) and play around with. I guess it would need to be the R,G,B outputs that would have to be timed to see Shifter wakeups?

[Steven Seagal]

DE-to-LOAD 3 CPU cycles (WS2) and 6 (WS1) respectively easily seen.

Thx, up to now only one such graph was "generally" available I think, and less precise.
It seems to be multiples of 8mhz cycles too, I thought there could be some fraction.
LOAD is in fact the MMU's DCYC, right? It is simultaneous.
It seems to last 1.5 cycle, I thought it was 1...

[troed]

Thx, up to now only one such graph was "generally" available I think, and less precise.
It seems to be multiples of 8mhz cycles too, I thought there could be some fraction.
LOAD is in fact the MMU's DCYC, right? It is simultaneous.
It seems to last 1.5 cycle, I thought it was 1...

Yeah LOAD and DCYC are the same thing. Since MMU runs at 16MHz it indeed looks to be three 16MHz cycles long (6 32MHz Shifter cycles).

(I'll probably make some more captures since I have everything connected up at the moment)

/Troed

[ijor]

Ah, great to hear you already have them My Mega ST has the regular -38 Shifter, but it's socketed so I could always get an IMP (atarifreakz has them) and play around with. I guess it would need to be the R,G,B outputs that would have to be timed to see Shifter wakeups?

Well, if it is not too much trouble to get an IMP Shifter and capture some traces that would be nice.

Yes, you need one RGB signal (anyone that you know it changes at the left border is good enough), LOAD, DE, plus the 16 MHz clock. One trace at low rez, other at med. A third trace at hi rez capturing the mono signal could be also useful. Of course, each full set of traces has to be done without power cycling.

[ijor]

Thx, up to now only one such graph was "generally" available I think, and less precise.
It seems to be multiples of 8mhz cycles too, I thought there could be some fraction.

There should be traces I posted long ago. They didn't include the end of the line though, only the start.

I'm not sure what you mean by multiples of 8MHz cycles. Do you mean the relation between each wakestate or the DE-to-LOAD delay? Or what?

LOAD ... It seems to last 1.5 cycle, I thought it was 1...

It depends on the MMU version, but that doesn't matter too much. What matters is the raising edge, not the width of the pulse. The pulse width might have some relevance on the issue with Spectrum 512 phantom pixels. Other than that it shouldn't matter.

[troed]

Posting as a new topic since some of these will be important to different concurrent projects. Feel free to suggest signals and methodology. I'm currently using my Mega ST with a non-IMP Shifter. An IMP Shifter has been ordered and I will trace it as well.

I've currently hooked up 8 signals: /LOAD, 8MHz CPU, 16MHz Shifter, DE, HSYNC, VSYNC, Blue bit 2 and /BLANK

[troed]

Attached are traces from a regular low resolution screen where border color is #000 and the whole screen is filled with #777 graphics. I.e, blue bit 2 will be set when graphics are displayed, otherwise not.

Also attached is exactly the same, but with a {Closure} fullscreen line.

Both of these were made in Wakestate 1.

1 million samples were done, which means that more than a full frame has been captured (i.e, the behaviour and timing of VSYNC has been captured as well). Currently this meant I had to capture at 25MHz. I should be able to capture at higher speed with RLE encoded buffer but didn't manage to get it working right now.

The attached screenshot is just an example, use DSView to browse around in the captured data.

Screen Shot 2018-01-06 at 14.15.07.png

[troed]

Unfortunately it seems the built in RLE compression of the LA won't help out in this case since the signals change state too often. I'm only able to acquire ~51000-56000 samples at 100MHz, and anything lower won't accurately reflect the 8 and 16MHz cycles.

New captures made, in WS2 and at 100MHz. None covers a whole frame of course, but around ~8 scanlines each. I've made sure to capture some including the VSYNC pulse though.

As a bonus, I also captured the end of a Closure-style fullscreen enabling all 277 lines of graphics possible on the ST. Only a few pixels to the extreme left of scanline 277 are visible until VSYNC kicks in.

[troed]

Trivia: In the Mega ST schematics by Atari from 1986, there are three different Video out circuits detailed.

1) PIN C101608 FULL CUSTOM W/. D TO A CONVERTER
2) PIN C070713 FULL CUSTOM W/O D TO A CONVERTER
3) PIN C025914 GATE ARRAY W/O D TO A CONVERTER

For cases 1 & 2 - BLANK is connected to pin 1 of the Shifter (XTL0). Since my Mega ST has the C025914 Shifter I had to go find it easily accessible at one end of the D9-D11 diodes instead. I'm actually unsure, looking quickly at the diagrams, how BLANK is working on this Shifter revision.

If we go to the service manual, it has this to say:

NOTE : this resistor network is incorporated into the full custom chip in later versions of the video shifter (C101608). Video shifter which has part nunber C101608 or C070713 has pin 1 connected to to signal line BLANK. Shifter with part number C025914 will have pin 1 connected to a pull-down resistor R144,10K, and signal line BLANK will be connected to diodes D9, D10, D11.

I was under the impression that the different Shifters were drop in replaceable, but it seems I might be wrong about this.

[czietz]

For cases 1 & 2 - BLANK is connected to pin 1 of the Shifter (XTL0). Since my Mega ST has the C025914 Shifter I had to go find it easily accessible at one end of the D9-D11 diodes instead. I'm actually unsure, looking quickly at the diagrams, how BLANK is working on this Shifter revision.

Which one do you mean by "this" revision? C025914? There the external diodes simply blank the output signals by pulling them down.

If we go to the service manual, it has this to say:

NOTE : this resistor network is incorporated into the full custom chip in later versions of the video shifter (C101608). Video shifter which has part nunber C101608 or C07O713 has pin 1 connected to to signal line BLANK. Shifter with part nunber C025914 will have pin 1 connected to a pull-down resistor R144,10K, and signal line BLANK will be connected to diodes D9, D10, D11.

I was under the impression that the different Shifters were drop in replaceable, but it seems I might be wrong about this.

At least you can put an IMP Shifter (C070713 or C07013(sic!) w/ BLANK input) into a PCB that was made for a Ricoh/Universal Semiconductor Shifter (C025914-38/-20) as I've tested myself. I didn't try it the other way around because I don't have an Atari with /BLANK connected to the Shifter on the PCB.
We had this some time ago, see this string of posts:
http://atari-forum.com/viewtopic.php?f= ... nk#p299921
http://atari-forum.com/viewtopic.php?f= ... nk#p299966
http://atari-forum.com/viewtopic.php?f= ... nk#p299992
http://atari-forum.com/viewtopic.php?f= ... nk#p303218

Particularly, the last post explains why the IMP Shifter still works with a pull-down resistor at the BLANK input.

[troed]

Which one do you mean by "this" revision? C025914? There the external diodes simply blank the output signals by pulling them down.

Ah. The scan of the old schematics is simply of such low quality that I didn't see the crossed lines as being connected

Thanks for the links - I remember now that I read all those posts back then ...

/Troed

[ijor]

I've currently hooked up 8 signals: /LOAD, 8MHz CPU, 16MHz Shifter, DE, HSYNC, VSYNC, Blue bit 2 and /BLANK
...
Unfortunately it seems the built in RLE compression of the LA won't help out in this case since the signals change state too often. I'm only able to acquire ~51000-56000 samples at 100MHz, and anything lower won't accurately reflect the 8 and 16MHz cycles.

Not sure if that would help, but there is no need to capture both clocks, certainly not for the whole frame.

Btw, I moved your old posts with traces to this topic.

[troed]

Not sure if that would help, but there is no need to capture both clocks, certainly not for the whole frame.

Btw, I moved your old posts with traces to this topic.

Yeah I tried skipping 16MHz but (strangely, I thought) it didn't help much. I'm going to see what advanced modes there are to help out a bit, else I will just have to do more and shorter captures (VSYNC to screen start, line end/start and screen end to VSYNC).

I will get to the other resolutions and regular fullscreen lines later (for one, {Closure} lines uses 60Hz BLANK end which is unusual). The traces will hopefully be of use for emulators, including Smonson's Shifter replacement.

(Thanks)

[troed]

So I was going to post new captures but just saw that I managed to lose DE for some reason. Anyway, for the cases where only relation to CPU clock is of interest I've now managed to clock my LA from the CPU clock, which means I can stream all other signals at 50MHz and capture as many frames as I want. This will give good data on the exact relation between vsync, blank, first graphics etc.

For more Shifter related things where I need much higher resolution I will need to do smaller captures.

(Will attach captures once I've managed to find my missing DE)

[ijor]

Anyway, for the cases where only relation to CPU clock is of interest I've now managed to clock my LA from the CPU clock, which means I can stream all other signals at 50MHz and capture as many frames as I want.

Sync capture is great. But if you can and you still get one full frame, try using the 16MHz clock instead. Actually if you can combine RLE compression with sync clocking, then the clock frequency shouldn't reduce the amount of samples too much if at all.

[troed]

Sync capture is great. But if you can and you still get one full frame, try using the 16MHz clock instead. Actually if you can combine RLE compression with sync clocking, then the clock frequency shouldn't reduce the amount of samples too much if at all.

I thought I had tried that and decided 16MHz was too fast an external clock for the LA, but that turned out to be where I mixed up the DE and 16MHZ probes instead

Attached are full frames of a regular low resolution screen in WS1, WS2 and WS3. LA is clocked at 16MHz so it's easy to count cycles in DSView. I tried getting into WS4 for a good 10 minutes or so without success (I really need to build that automatic circuit that will power cycle until a set WS .. ).

remember:
WS2 = DE-to-LOAD 3 cycles
WS3 = DL5
WS1 = DL6

These captures should be valid for timing regular BLANK, SYNC, DE and pixel output.

[ijor]

Attached are full frames of a regular low resolution screen in WS1, WS2 and WS3.

Just great. Many thanks

(I really need to build that automatic circuit that will power cycle until a set WS .. ).

Well, as I commented some time ago in other thread, it is possible (at least in theory) to build a small circuit to force a specific wakestate without even power cycling. But you need somehow to intercept GLUE TEST pin.

These captures should be valid for timing regular BLANK, SYNC, DE and pixel output.

RGB output actually depends on the Shifter wakeup. Might be it even depends on the Shifter version. And, as you know, top and bottom borders depend on the GLUE version as well. Just noting for the relativity of the "regular timing" concept in this context.

[troed]

Well, as I commented some time ago in other thread, it is possible (at least in theory) to build a small circuit to force a specific wakestate without even power cycling. But you need somehow to intercept GLUE TEST pin.

Interesting. Looking at the PIN schematics at https://www.exxoshost.co.uk/forum/viewt ... f=31&t=149 the pin between /SNDCS and /MFPCS is named GND on the PLCC* version and TEST on SMD However, looking at the Mega ST schematic pin 52 is indeed marked as "TEST", and wired to GND.

As long as there's a trace I can cut on the motherboard I can of course intercept it easily. What would be the method? Just pulling it high for some cycles?

/Troed

(I hadn't thought about looking for the Shifter wakeup in these traces, will do. I'm assuming you mean it would be one 16MHz cycle difference)

*edit: corrected

[ijor]

Interesting. Looking at the PIN schematics at https://www.exxoshost.co.uk/forum/viewt ... f=31&t=149 the pin between /SNDCS and /MFPCS is named GND on the DIP version and TEST on SMD However, looking at the Mega ST schematic pin 52 is indeed marked as "TEST", and wired to GND.

That it is either plain wrong, or at the very least it is the other way around. Certainly the PLCC version (the old original one) has the TEST pin.

What would be the method? Just pulling it high for some cycles?

Yes, that should reset the 2MHz clock divisor. Pulling it high for a single 8MHz cycle will cycle for the "next" WS. You should do it only during Reset.

A more sophisticated circuit could sense the current WS and automatically pull the signal high for the required number of cycles. You would need to bring some signals from MMU to be able to sense the WS.

(I hadn't thought about looking for the Shifter wakeup in these traces, will do. I'm assuming you mean it would be one 16MHz cycle difference)

It could be also half, or one an a half cycle. That is, one or more 32 MHz cycles. What I meant is that depending on the Shifter WS, the RGB timing could be different than the one seen at the traces.

[troed]

It could be also half, or one an a half cycle. That is, one or more 32 MHz cycles. What I meant is that depending on the Shifter WS, the RGB timing could be different than the one seen at the traces.

Well the B2 trace is of the output blue bit 2 so any Shifter wakeup should be visible there? (Come to think of it, maybe I should see if I can clock the LA at 32MHz while still accurately detecting the other signals)

I'll ponder about how to build such a WS cycling circuit. Might just go for randomization to start with. It's better than leaving it to regular cold boot chance. All STs I have are attracted either to one WS or to one when warm and another when cold, and all other are quite uncommon to stumble upon. A forced randomization will increase the odds of getting into any of them.

[ijor]

Well the B2 trace is of the output blue bit 2 so any Shifter wakeup should be visible there? (Come to think of it, maybe I should see if I can clock the LA at 32MHz while still accurately detecting the other signals)

You might get an estimate. But without comparing with the output at med rez, is not conclusive.

I think that at least in some computers, the 32 MHz is not a reliable direct clocking source.

[troed]

I think that at least in some computers, the 32 MHz is not a reliable direct clocking source.

I might be in luck. The attached trace is of WS2 with the LA clocked using the 32MHz source. I've briefly looked at it and the resolution does seem to have been increased - the LOAD pulses are 5 32MHz clock cycles in this trace. Unless that's strange since they come from 16MHz MMU ...

[ijor]

the LOAD pulses are 5 32MHz clock cycles in this trace. Unless that's strange since they come from 16MHz MMU ...

That's correct. It is 2 and a half cycles on the OLD MMU versions. It combines the output of two flip flops working at the opposite edge of the clock to get half cycle resolution.

Btw, this is really not very good. It might glitch. And probably this is the reason that the IMP MMU shortened the pulse width to just two cycles. I was thinking that this might be precisely the problem with the IMP Shifter that we know Atari tried to slow down. So conceivable, you might have problems installing an IMP Shifter connected to an old MMU.