Project: HDMI/DVI out for STFM

[troed]

Just popping up quickly since I briefly saw my name mentioned. I'm way way way overloaded workwise* and had to cut down on all other activities, like retro. I'll try to get back up to speed and see what software I have to help out with and to test the new, sadly still unpacked, Shifter board on my hardware.

/Troed

*) also, kid #3 arriving in a month

[exxos]

*) also, kid #3 arriving in a month

I've noticed a trend lately, I have put together a formula. more kids = less atari time. Don't work to hard in any case

[troed]

Now read up.

Regarding Closure, the last time I checked my opinion was that it's a _single_ (or close to single) issue. The way I clear the Shifter at the left border is "different" and so the FPGA Shifter is one bitplane "off" when getting data from the MMU.

Otoh, not a priority to fix, since it's kind of the only demo in existence using that method ...

[rubber_jonnie]

FYI I did a test on a different, not blittered machine last night, and all seemed fine at low and med res.

At hi res, I got this:

IMG_20190324_233819.jpg (600.01 KiB) Viewed 4963 times

There is an obvious shift/step on the LH end of the screen

However, it behaved impeccably otherwise, with all resolutions stable and clear, and no blanking.

I'll try to go through my stack of STFMs and work out which have a blitter (They are actually closed up!) as I'll need to know before pulling them apart. I also have no idea which machines have a socketed shifter, so some checking is needed.

[Smonson]

That effect comes from the ST and shifter being out of sync with each other. The shifter only gets reset at boot time, when the internal registers are cleared, and after that if it receives an extra LOAD it gets out of sync like this and stays that way until the next reset when it should go back to normal. I don't know why this happens to the FPGA shifter and apparently not the physical shifter :/

[exxos]

Maybe its just a fluke.. that the actual shifter is to slow or not finished setting up internally to "see" the load pulse ? No idea Could you "skip" the extra load on power up ? Though I imagine as not all machines suffer, that would create more issues ?

BTW - did you ever look at the suska video core, see if any ideas in there ?

[Smonson]

The problem with skipping is knowing which ones to skip. It could also be caused by some other mechanism of course, an unknown unknown.

I've never looked at the suska source actually. Maybe I should learn VHDL.

[rubber_jonnie]

Give me a bit more time to suss out my other blittered non blittered machines and I'll get more testing done.

[exxos]

I think myself and troed saw this issue when we did the 16MHz boost.. Maybe troed remembers more.. but I think it was actually a sync issue between the MMU & GLUE 8MHz clock.. Where some small delay caused random sync issues..

Doesn't look like I documented it, but RJ could possibly try a small pF like 47pF on the 8MHz line on the bottom of the GLUE and see if that helps (or makes it worse even) .. its possible it may need a series resistor... Its also possible it could be a sync issue with DE from GLUE to MMU as well..

So I think this is just another buggy ST fault where the original atari logic is to slow and dumb for the problem to cause issues...

[rubber_jonnie]

Doesn't look like I documented it, but RJ could possibly try a small pF like 47pF on the 8MHz line on the bottom of the GLUE and see if that helps (or makes it worse even) .. its possible it may need a series resistor... Its also possible it could be a sync issue with DE from GLUE to MMU as well..

I'll see what I can do, can you please advise on the pin I need to connect to on the GLUE?