ijor wrote: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

ijor wrote: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?

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

Steven Seagal wrote: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 wrote: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.

Steven Seagal wrote: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.

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.

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

You do not have the required permissions to view the files attached to this post.

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.

You do not have the required permissions to view the files attached to this post.

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.

Last edited by troed on Sat Jan 06, 2018 3:55 pm, edited 1 time in total.

troed wrote: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.

troed wrote: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.

troed wrote: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.

ijor wrote: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.

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.

troed wrote: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.

ijor wrote: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 cyclesWS3 = DL5WS1 = DL6

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

You do not have the required permissions to view the files attached to this post.

troed wrote: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.

ijor wrote: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

Last edited by troed on Mon Jan 08, 2018 6:06 pm, edited 1 time in total.

troed wrote: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.

ijor wrote: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.

troed wrote: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.

ijor wrote: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 ...

You do not have the required permissions to view the files attached to this post.

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.