32768 color dual Shifter ST mod - schematics lost?

[mrbombermillzy]

You might be confusing Shifter wakeups with GLUE-MMU wakeups.

Yep. I am. :D That sort of changes things a bit then.

As opposed to GLUE-MMU wakeups, Shifter wakeups can't be tested programmatically, if that's what you mean.

That's not great news, but if a test pattern/image can be displayed and is wrong, that's a test, I guess.

I'm convinced that, at least, Atari was aware about wakeups. They just didn't care because it doesn't affect normal software. But I suspect that in this case it is more likely what I said in the previous message. Probably two identical Shifter chips will tend to wakeup in the same state for a given power cycle on the same computer. So it worked fine, most of the time.

Well, it's a start. We can possibly improve things from here.

No JRI4096 board survived?

Well, I don't know about anyone else here, but I've been looking for one for the last 5+ years. Haven't seen any, Ebay or otherwise.

Same for the Barry Orlando board. Absolutely no one seems to have taken the time to build/show it over the last ~30 years it's been known about, so who knows really.

[troed]

A better phrasing would be that It won't always work correctly. Or if you want, that correct behavior is not always guaranteed.

Are you thinking about the physical placement of the pixels on screen or something a bit more tricky involving the timing towards the MMU / latching of memory? The first case I think would only manifest itself as a slightly fuzzier picture. Maybe not that noticeable on old screens.

/Troed

[ijor]

Are you thinking about the physical placement of the pixels on screen or something a bit more tricky involving the timing towards the MMU / latching of memory?

Yes, it is mostly about the RGB output, the pixel placement if you want. Regarding the interaction with the MMU, I would need to double check to be completely sure, but I think that should be ok. Yeah, such things as unsafe Spectrum 512 effects might be affected. But this would have issues in a standard, single Shifter, setup as well. Only that here they might behave slightly different, not necessarily worse.

The first case I think would only manifest itself as a slightly fuzzier picture. Maybe not that noticeable on old screens.

Well, may be. But the displacement may be up to three 32 MHz cycles. Don't know, if using the modulator (or even Video Composite) might indeed be hard to detect. But on a RGB monitor?

May be again it is just a matter of odds. If we assume that, perhaps, most of the time both Shifter chips would wake up in the same state, then on those rare occasions that they don't, you have to be very unlucky to get one of the worst combinations with three cycles separation. It would be curious to see :)

[mrbombermillzy]

Are you talking about a [x amount] px wide convergence of the colours (sort of like when a CRT beams are not aligned, you get 3 spread out RGB dots instead of a white pixel)?

If so, this can maybe be compensated for with palette colour adjustment algorithms once the erraneous colours/overlap size are established.

(I'm hoping it's as simple as that). :D

[ijor]

In making the pcb, I used a 4 layers stack with ground and power planes in the hope to have a "not so noisy" pcb, so that signal propagation is not delayed too much.

I was checking your schematics, and I think there might be a couple of issues. But the most important, am I missing something or you forgot to include CS in the logic that controls the '257 mux?

Anyway, do you really need an "experimental" mux? You can infer the exact location of each register from the well known address map.

[ijor]

Are you talking about a [x amount] px wide convergence of the colours (sort of like when a CRT beams are not aligned, you get 3 spread out RGB dots instead of a white pixel)?

No. One of the consequences of Shifter wakeups is the exact timing when the video starts. This means that each Shifter might start the video in a different cycle (of the 32 MHz clock). And then the whole display output from one Shifter will not be aligned with the other one.

Perhaps it might be more intuitive using troed's wording. Similary as GLUE-MMU wakeups, Shifter wakeups also affect the placement of pixels on the screen.

[sporniket]

I was checking your schematics, and I think there might be a couple of issues. But the most important, am I missing something or you forgot to include CS in the logic that controls the '257 mux?

The purpose of the '257 mux is to flip the respective target of a5 and "not a5" to enable/disable the bit manipulation of the word received by the second shifter.

Anyway, do you really need an "experimental" mux? You can infer the exact location of each register from the well known address map.

If I was alone on my own to build AND test, I could check that my inference is correct. I have no working STF, and @mrbombermillzy that will test it is not at ease with soldering. So I added this mux to allow the possibility of flipping.

What are the next issues you could see ?

[ijor]

The purpose of the '257 mux is to flip the respective target of a5 and "not a5" to enable/disable the bit manipulation of the word received by the second shifter.

But A5 is not valid when Shifter loads video memory.

If I was alone on my own to build AND test, I could check that my inference is correct. I have no working STF, and @mrbombermillzy that will test it is not at ease with soldering. So I added this mux to allow the possibility of flipping.

Oh, I see.

[sporniket]

The purpose of the '257 mux is to flip the respective target of a5 and "not a5" to enable/disable the bit manipulation of the word received by the second shifter.

But A5 is not valid when Shifter loads video memory.

... ... ... ho :oops: indeed. Well, for testing, I guess it will be ok on solid surfaces because bit 15..10 are untouched, so at least we can prove a part of the montage.

And in the mean time, I will have to address that so that "no bit manipulation when load is low" for the next spin.

[ijor]

And in the mean time, I will have to address that so that "no bit manipulation when load is low" for the next spin.

Might make more sense to do it "only when CS is asserted". This would avoid unnecessarily switching the transceivers on every A5 toggle.

But more important, you should perform a small timing analysis. You probably need faster parts. Why are you using HC parts for the 245's? But putting very fast parts blindly might not be a good idea either. Note that using CS vs LOAD for the control logic would significantly affect the timing. Not necessarily one better than the other in this regard. You have to perform a timing analysis to be sure.