Different SHIFTER versions

[czietz]

In this case the bands are more clear, those are not just glitches. I believe however that the cause is very different on the IMP Shifter than on the -38 (or -20) one. It would be interesting to see if adding the diode at the VCC pin fixes the problem. I suspect it might.

Sorry, it doesn't. So, (given that my TT is sadly down for repair) today I had some time to play with my IMP STfm. I confirmed that by default there is no diode between +5V and the Shifter's Vcc pin -- I measure 5 V on the IMP Shifter. Then I added the diode, dropping the Vcc of the IMP Shifter to approx. 4.4 V. However the artifacts in "Let's Do The Twist Again" are still present. Also, I retested the SNDH Update Demo, where I had previously noticed artifacts with the IMP Shifter. They are still present as well at 4.4 V.

Anything else you want to have tested?

I will repeat the test with the -20 Shifter now. And after that, maybe already tomorrow, I can do the measurements on the IMP Shifter (without diode) you asked for.

[czietz]

And this is a screen capture for "Let's Do The Twist Again" with the -20 Shifter -- artifacts as expected:

IMG_2964.JPG

[ijor]

Sorry, it doesn't. So, (given that my TT is sadly down for repair) today I had some time to play with my IMP STfm. I confirmed that by default there is no diode between +5V and the Shifter's Vcc pin -- I measure 5 V on the IMP Shifter. Then I added the diode, dropping the Vcc of the IMP Shifter to approx. 4.4 V. However the artifacts in "Let's Do The Twist Again" are still present. Also, I retested the SNDH Update Demo, where I had previously noticed artifacts with the IMP Shifter. They are still present as well at 4.4 V.

Interesting. I think I have a pretty good idea about the incompatibility with the older SHIFTER versions (-20 and -38). But not so sure yet about what's happening with the IMP part. Let's wait to see the traces, they might give us some clues.

[czietz]

These are the LA traces with the IMP Shifter (as is, i.e. without diode) for medium and low resolution. The timing markers give the delay between first falling edge of LOAD in a scanline and first change of the RGB line.

imp_shifter_med_res.png

imp_shifter_low_res.png

Note that because of the maximum sample rate of 100 MS/s of my logic analyzer the 16 MHz clock looks a bit uneven. In reality, it isn't. As mentioned earlier, DE has been excluded from the trace to have the full 100 MS/s (= 10 ns resolution) available.
Would be nice to know which conclusions you draw from these measurements.

PS: PM me if you want the full traces, to be opened with the Saleae software.

[ijor]

Thanks a lot!

Well, that's strange. Are you sure that the RGB signal traced starts right on the left border? Because it is quite late. If indeed that's the left border, then the logic must have been changed in comparison to the -38A version.

At low res the exact delay depends on the SHIFTER wakestate, but at med rez is fixed. Here it is one 16MHz cycle later than at the -38A. Of course, I have no way to be sure if the extra delay is at the initial phase of the processing or at the very end. At the end, after palette lookup, the delay is not relevant, it will just shift slightly the display. But considering that we are seeing some incompatibilities with the demos, it is almost sure that the extra delay is at an earlier stage.

I am hopefully getting an IMP SHIFTER myself to make more tests. It would be interesting to trace all the SHIFTER wakestates.

[czietz]

The traced RGB signal is one line of the (solid) background of the Desktop. I can confirm from my trace that it is indeed low for 640 pixels in medium res. So I'm quite sure that where you see it going low is indeed the left border.

[tin]

Here's a first baseline test with the 38A shifter in a non-IMP environment (100Mhz sampling, beginning of a solid green desktop line):

38a_la.png

Now that the Test Clip is set up, churning out more traces gets pretty easy and changing the shifter is a matter of seconds. Let me know if these traces are OK and I will produce the others in the next days.

Dang that the wiki is still broken (does that like have it's 10th anniversary soon?). Would be nice to gather the full traces there...

[ijor]

Here's a first baseline test with the 38A shifter in a non-IMP environment (100Mhz sampling, beginning of a solid green desktop line):
38a_la.png

Now that the Test Clip is set up, churning out more traces gets pretty easy and changing the shifter is a matter of seconds. Let me know if these traces are OK and I will produce the others in the next days.

Thanks again. Please include the 16MHz clock. The 32 MHz one is not very important, you can remove it. The phase of the 16MHz clock is more important.

Btw, note how the RGB signal here starts before the raising (trailing) edge of the 5th LOAD pulse, while at the traces provided by czietz taken with an IMP SHIFTER, it starts after it!

[Smonson]

It also starts after the 5th LOAD in Troed's LE captures.

[ijor]

It also starts after the 5th LOAD in Troed's LE captures.

But Troed's captures are at LOW rez, not at MED rez. Low rez always starts later than med rez, and the delay (at LOW rez) is variable and depends on the SHIFTER wakeup.

[tin]

Just a quick status update. I don‘t have the traces yet (ah, the joys of getting sidetracked!) but I plan to bring the IMP board etc. to Nordlicht party and do traces there. There’s nothing like a quiet partyplace to do these things
Monday there shall be traces.

[tin]

Here are the shifter traces:

http://www.absencehq.de/atari/shiftercaptures_c025914-38_38A_c025914-002_cboard.zip

The package has traces C025914-38/38A and C025914-002 shifters on a C070523-001 Rev D board (non-IMP chipset)in med and low rez. It contains Screenshots and also CSV/VCD files of the traces, traces where made at 8ns resolution. Don't mind the HSYNC/VSYNC/BLANK traces in that data, I need these for my own research.
Unfortunately I can't trace the full IMP today, as I somehow managed to fry VSYNC on this board. Have to have a look at that.

Let me know if there's anything to improve on the above package or anythings amiss.

[ijor]

Here are the shifter traces: ... Let me know if there's anything to improve on the above package or anythings amiss.

This is just awesome! I am currently on a trip. Will check your traces in a few days. Many thanks!

[ijor]

The package has traces C025914-38/38A and C025914-002 shifters on a C070523-001 Rev D board (non-IMP chipset)in med and low rez.

I am starting to check your traces. Thanks a lot once more again.

But just to be sure, that's indeed the code of the IMP Shifter (C025914-002) or it's a typo? If so, would you be so kind to post a picture? I thought IMP Shifter parts have a completely different code (C070713 or C07013).

[tin]

But just to be sure, that's indeed the code of the IMP Shifter (C025914-002) or it's a typo?

I'm pretty sure it's a typo and the shifter is a C070713-002 model. I can't check atm -- but will do in a few days and fix the package accordingly. It was probably just too hot.

[ijor]

I'm pretty sure it's a typo and the shifter is a C070713-002 model. I can't check atm -- but will do in a few days and fix the package accordingly.

Ah, ok, no problem at all. The only interesting thing remaining at this point might be to measure Shifter wakestates with the IMP Shifter. But this might be better done on the full IMP chipset system. So I won't bother you anymore for the time being

I'll try to post a resume later.

[tin]

Ah, ok, no problem at all. The only interesting thing remaining at this point might be to measure Shifter wakestates with the IMP Shifter. But this might be better done on the full IMP chipset system. So I won't bother you anymore for the time being

You don't

Well, since you mention wakestates: I can indeed start specific wakestates - nothing fancy like Troeds wakestate nudger, just a chain of relais, CE, pi and some Software and a thousand automated powercycles :p

But first I have to have a look whats pulling vsync high on that specific IMP board I'd need.

I'll try to post a resume later.

Please do

[troed]

nothing fancy like Troeds wakestate nudger

Ijor's. I only made an implementation

[ijor]

Unfortunately Shifter wakestates are more complicated. In first place, the current wakestate can't be tested by software. Nothing that the wakestate affects gives any feedback to the CPU directly or indirectly, only the display is altered and the internal Shifter state that can't be tested. The wakestate can be measured with a LA or a Scope. And some visual effects can be used as well, of course.

In second place it is not that simple to implement a "nudger". Shifter mechanism for power up detection is more complicated to simulate (although not impossible) and even if you could do it precisely, some wakestates can't be forced with this mechanism.

To determine the wakestate measure the time elapsed since the edge of the LOAD pulse to the start of the screen on low rez. Doesn't matter exactly which LOAD edge you use as long as you always use the same for a given computer. Technically the relevant edge is the raising edge of the fourth LOAD pulse after DE is asserted (the right border of the screen). I find it easier to measure since the raising edge of the fifth LOAD pulse because the display always starts after it, at least at low rez.

On older Shifter chips (pre IMP), there are 4 wakestates. Each wakestate is half 16 MHz cycle (one 32 MHz cycle) apart from the other. I wasn't sure how many wakestates the IMP Shifter has. Any Shifter must have at least two, but depending on the logic it might avoid the other two. But from the traces I've seen so far it seems it has 4 wakestates as well.

[ijor]

The two captures with an IMP SHIFTER on low rez, one by Tin the other by Czietz. Each shows a different SHIFTER wakestate. See the different distance from the raising edge of LOAD to BLUE. In one case is two 16 MHz cycles and a half, in the other is three full cycles:

TinLow.png

CzietzLow.png

It is not that the actual video start is very important. By itself this would only shift the display and change slightly the alignment if you mix low rez and med rez scans in the same frame.

What matters is that the internal SHIFTER state timing is changed, especially the timing relation between med and low rez. Med rez timing is fixed, doesn't depend on wakestate as low rez. This would affect stabilization, 4-bit sync scroll, "destable" scroll as in Closure, etc.

[ijor]

SHIFTER versions

AFAIK there are five different versions of SHIFTER, chronologically they are:

C025914-20

All the chipset with the -20 suffix belongs to the first generation. They are assumed to be ULM gate arrays and they are quite rare. Probably used for the first few months only. Probably only on the US.

C025914-38

Second generation. Ricoh gate array. Not as rare as the -20 part but still pretty scarce. I am not 100% sure but there is reason to believe the logic is identical to the earlier version (with the -20 suffix) just on a different gate array manufacturer.

C025914-38A

Second version of the second generation. This is by far the most common version of Shifter. Probably most demos were tested with this version. The reload logic was slightly modified. I'll elaborate more below.

C070713
C07013

IMP full custom version(s). I'm not quite sure about the difference between both IMP parts, and if there is any difference at all and it is not just a labeling mistake. The reload logic was modified again. Besides this change the BLANK logic was integrated in the chip, although I'm not aware any motherboard was produced to take advantage of this feature.

Some Atari schematics mention a mixed signal version of SHIFTER with integrated DAC for the RGB outputs. Doesn't seem it was ever produced or at least it wasn't distributed.

Regarding the modified reload logic, especially between SHIFTER C025914-38 and C025914-38A. The reload timing at med and high resolutions was changed. This alters the relation between the timing at different resolutions and in turn this affects all Shifter tricks and effects that depend on a resolution change.

Spectrum 512 effects are not affected. The standard method of opening the left border is not affected either because this is actually more a GLUE effect and by the time the reload logic is activated Shifter is already back at low res. Both standard stabilization methods seem to tolerate the change and then work ok on both versions.

Heavier tricks as we seen in this thread do are affected and because the -38A version was the most common, sometimes it works correctly only on this version and it breaks on the others. It is very possible that some still work on the other SHIFTER versions but only on specific SHIFTER wakeups.

I'm still not completely sure about the change introduced in the IMP version, but so far it seems the timing is more similar to the one in the earliest versions (-20 and -38). That would again, be not fully compatible with the most common -38A version.

[troed]

Great stuff Ijor, as always.

edit: For Closure specifically I've seen effects that are surely due to Shifter wakeup. With enough time I can use my LA to document which chips and wakeups where there are no issues, and maybe where they are (bugs only happen on machines I don't own myself, typically )

[alien]

Here are a few quick video captures (50Hz, no sound, direct ST RGB feed). All done on same MB with -38 and re-verified to run OK with -38A. Unfortunately I didn't log the respective wakestates.
PYM:

Also checked with an IMP shifter on the board used above, but that one doesn't behave nice with a non-IMP chipset in general, it seems. Also got the banded effect with the 4-bit scroll with full IMP chipset on different MB (no recording, sry) - probably a wakestate issue, since this didn't happen on retry. But IMP is probably another story.

Thanks for the video tin. That's really interesting (and a bit of a shame). I guess most of the French STf's I had access to at the time must have used the -38A version -- As far as I know, it was tested on many machines, including Belzebub's old "load the OS from a floppy" machine, and I only ever heard of one report through the grapevine of a ST that didn't run the demo... But I was also told that machine also had power supply issues so I dismissed it. Perhaps it was a -38.

Also thanks Ijor for your summary of Shifter versions. I didn't realise there were that many. By "both standard stabilization methods" do you mean the medium rez one ULM used in for e.g. the Dark Side of the Spoon too?

[ijor]

Hi Alien,

As far as I know, it was tested on many machines, including Belzebub's old "load the OS from a floppy" machine, and I only ever heard of one report through the grapevine of a ST that didn't run the demo... But I was also told that machine also had power supply issues so I dismissed it. Perhaps it was a -38.

I'm not sure, but it is possible that your code still runs correctly on a SHIFTER -38 (and -20) but only on some and not all SHIFTER wakestates. Possibly it's the same with an IMP SHIFTER.

By "both standard stabilization methods" do you mean the medium rez one ULM used in for e.g. the Dark Side of the Spoon too?

Yes. I didn't test all the combinations of wakestates, but I think they work correctly in every case on all older SHIFTER versions. I'm less sure about IMP SHIFTER. But I suspect it is the same. The reason that your code is more sensitive, is that in your case SHIFTER actually starts shifting in a different resolution. And that's precisely what has different timing depending on the specific SHIFTER version.

Don't be ashamed, it doesn't detract from your amazing achievement

[ijor]

A couple of corrections:

It might be possible to identify by software some of the SHIFTER versions. I would need to perform some tests. But unfortunately I still don't see how to identify the SHIFTER wakestate regardless.

When I said that the changes across different SHIFTER versions doesn't affect Spectrum 512 effects, I was talking about the change in the reload logic that we analyzed and tried to measure with the traces. This shouldn't be relevant at all for Spectrum 512 because the timing for LOW rez doesn't seem to be changed (again, I am less sure about the changes on the IMP version of SHIFTER).

But this doesn't mean that different SHIFTER versions don't behave slightly different, especially regarding analog effects (black or unstable pixels) when using so called "unsafe" timing that changes one palette register right when it is being accessed. Probably all the gate array versions are very similar in this regard. But might be different on the IMP version that has a faster CMOS process.