exxos's Atari, Amiga & retro forum

Your work is progressing and looks good until now.

Good job. I'm curious as to the switchable address range. @sporniket could you explain more? :)

mrbombermillzy wrote: 24 Feb 2022 08:41 Good job. I'm curious as to the switchable address range. @sporniket could you explain more? :)

The shifter has 32 registers (words) (5bits address A[5..1]), and I want to trick the secondary shifter only when writing to the palette registers, so that it outputs the suplemental bits.

I hope (some verilog code posted previously hint at it) that the palette registers are the 16 first registers, but if it is wrong, we overwrite some critical registers (display mode, etc...) and I guess that the rendering will most likely be weird. So as an experimental feature, I put a selector (U5) and a switch.

When the switch is on the '0xxxx' side, the 16 first registers will receive modified data, and the 16 last will receive unmodified data. When the switch is on the '1xxxx', then it is the contrary : the 16 first registers will receive unmodified data, and the 16 last will receive modified data.

Once we are sure which address range is for the palette, I will remove the selector and the switch, and wire directly a5 and "not a5" the their respective buffer.

edit: in software, it would be a "feature flip" :D

Honestly, I don't see how this could work. You can't put two Shifter chips in parallel just like that because the RGB output will not be synchronized. In first place because different Shifter revisions have slightly different output delays. But even if you put two exact same shifters they might still be not synchronized because Shifter has wakeup modes, and each Shifter might wakeup with its own different mode.

ijor wrote: 24 Feb 2022 12:02 Honestly, I don't see how this could work. You can't put two Shifter chips in parallel just like that because the RGB output will not be synchronized. In first place because different Shifter revisions have slightly different output delays. But even if you put two exact same shifters they might still be not synchronized because Shifter has wakeup modes, and each Shifter might wakeup with its own different mode.

I was only worried about being able to write into the second shifter in time and the ability of the 32MHz oscillator to drive 2 shifters instead of one (because I recall that @exxos telling that it is quite weak), but what you say is also another worry.

Well, there is this text that describe the mod, and there is also an extension by "JRI" that do the same to get RGB444 like the STe.

On another hand I saw people asking about this mod, so nobody online nowadays seems to have tried to do it. So may be it's a scam, maybe not.

Anyway I started working on it as an exercise, and a little push by @mrbombermillzy made me route and build it. As soon as he will receive the mod and test it, he will show us what he get.

sporniket wrote: 24 Feb 2022 09:32 The shifter has 32 registers (words) (5bits address A[5..1]) ...

There are only 17 in there. The 16 palette entries (address 0-15) plus the shifter's mode register (address 16). The other addresses aren't hooked up to anything. Although there is another video register in that range on the TT.

sporniket wrote: 24 Feb 2022 13:44 On another hand I saw people asking about this mod, so nobody online nowadays seems to have tried to do it. So may be it's a scam, maybe not.

I think that scam might be an overstatement. And I might have expressed myself imprecisely. It is probably not exact to say that it will not work. A better phrasing would be that It won't always work correctly. Or if you want, that correct behavior is not always guaranteed.

If you remember my very first description of GLUE-MMU wakeup modes, I called one mode “cold”, and another “warm” (this was when by mistake, I though they were 2 wakeup states instead of 4). That was because that's how most computers usually behave. They tend to wakeup in one mode when they are cold after being powered down for some time, and they tend to wakeup in a different mode when they are warmer.

I didn't explore this as much with the Shifter wakeups, and it is a bit of a PITA to analyze Shifter wakeups, but it's very possible that something similar happens. After all the voltage and the temperature are surely two key factors for establishing the actual wakeup. Then, it is possible that two identical Shifter chips in the same computer TEND to wakeup in the same mode. That would mean that this might work correctly most of the time. And in the worst case, if you get video distortion, you just might need to power cycle the computer. And as long as this is fine for you, then that might be ok.

Now, if you want something that is always guaranteed to work, you need some logic to force the same wakeup mode in both Shifter chips. This is possible, at least in some Shifter revisions, but it's not as simple as with GLUE. It might require a small CPLD.

I was only worried about being able to write into the second shifter in time and the ability of the 32MHz oscillator to drive 2 shifters instead of one (because I recall that @exxos telling that it is quite weak),

You could always buffer the 32 MHz clock in the worst case, I guess?

ijor wrote: 24 Feb 2022 14:34

sporniket wrote: 24 Feb 2022 13:44 On another hand I saw people asking about this mod, so nobody online nowadays seems to have tried to do it. So may be it's a scam, maybe not.

I think that scam might be an overstatement.

Yes I was a bit hasty in writing my answer.

ijor wrote: 24 Feb 2022 14:34 And I might have expressed myself imprecisely. It is probably not exact to say that it will not work. A better phrasing would be that It won't always work correctly. Or if you want, that correct behavior is not always guaranteed.

If you remember my very first description of GLUE-MMU wakeup modes, I called one mode “cold”, and another “warm” (this was when by mistake, I though they were 2 wakeup states instead of 4). That was because that's how most computers usually behave. They tend to wakeup in one mode when they are cold after being powered down for some time, and they tend to wakeup in a different mode when they are warmer.

I didn't explore this as much with the Shifter wakeups, and it is a bit of a PITA to analyze Shifter wakeups, but it's very possible that something similar happens. After all the voltage and the temperature are surely two key factors for establishing the actual wakeup. Then, it is possible that two identical Shifter chips in the same computer TEND to wakeup in the same mode. That would mean that this might work correctly most of the time. And in the worst case, if you get video distortion, you just might need to power cycle the computer. And as long as this is fine for you, then that might be ok.

Now, if you want something that is always guaranteed to work, you need some logic to force the same wakeup mode in both Shifter chips. This is possible, at least in some Shifter revisions, but it's not as simple as with GLUE. It might require a small CPLD.

Thanks for the precisions.

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.

Well, if it work "often enough", for me it's fine, the "mystery" of the original text is solved. Personnally, I am waiting for the new fpga shifter by @Icky and @Smonson.

And I am under-equiped for doing cpld stuff.

ijor wrote: 24 Feb 2022 14:34

I was only worried about being able to write into the second shifter in time and the ability of the 32MHz oscillator to drive 2 shifters instead of one (because I recall that @exxos telling that it is quite weak),

You could always buffer the 32 MHz clock in the worst case, I guess?

yes, if it is really needed

Forgive me if I'm wrong, as I'm just a coder, but IIRC the waitstates are caused by the Shifter<>Glue timings being in sync but (possibly) out of phase with each other. Is this assumption correct?

If so, and there's no system on the board to synchronise the 2 shifters accordingly (as Ijor mentions above), then there is the possibility of having an extra 'out of phase' variance, which may require extra power cycles to correctly phase all three. (Does the STFM have an equivalent of the MCU RESET? Would that work?)

Moving on with the above assumptions, I guess trying to ascertain whether the 2 shifters suffer from phase variance when powered up and if so creating some sort of forced phase match HW logic (as again mentioned by Ijor), if they do, is the next step here, or if that's not possible, a bit of test code to see if they're all in sync.

EDIT: As for the Barry Orlando mod, I did ask earlier if anyone had actually seen or know of a working version. However, the JRI4096 board DID exist, so in theory, there is a way to do all this. I'm not sure if anyone was actually aware of wakestates at that time, so I have some confidence of a good outcome, as it must have worked without dealing with them.

mrbombermillzy wrote: 24 Feb 2022 15:37 Forgive me if I'm wrong, as I'm just a coder, but IIRC the waitstates are caused by the Shifter<>Glue timings being in sync but (possibly) out of phase with each other. Is this assumption correct?

You might be confusing Shifter wakeups with GLUE-MMU wakeups. Shifter wakeups have no relation with GLUE. Also, when you add another chip as here, you might be introducing new wakeups that didn't exist on a stock machine.

(Does the STFM have an equivalent of the MCU RESET? Would that work?)

I'm not sure what you mean by "MCU RESET"? But note that reset doesn't affect the wakeup. That's the whole point.

Moving on with the above assumptions, I guess trying to ascertain whether the 2 shifters suffer from phase variance when powered up and if so creating some sort of forced phase match HW logic (as again mentioned by Ijor), if they do, is the next step here, or if that's not possible, a bit of test code to see if they're all in sync.

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

EDIT: As for the Barry Orlando mod, I did ask earlier if anyone had actually seen or know of a working version. However, the JRI4096 board DID exist, so in theory, there is a way to do all this. I'm not sure if anyone was actually aware of wakestates at that time, so I have some confidence of a good outcome, as it must have worked without dealing with them.

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.

No JRI4096 board survived?