Page 23 of 68

Re: Project: HDMI/DVI out for STFM

Posted: 04 Oct 2018 02:26
by Smonson
That's interesting. I'd like to know more about this. I take it this is a program that works with or from a diagnostic cartridge?

Re: Project: HDMI/DVI out for STFM

Posted: 04 Oct 2018 08:44
by exxos
Smonson wrote: 04 Oct 2018 02:26 That's interesting. I'd like to know more about this. I take it this is a program that works with or from a diagnostic cartridge?
https://www.exxosforum.co.uk/forum/viewt ... =50&t=1201

Re: Project: HDMI/DVI out for STFM

Posted: 04 Oct 2018 09:53
by Smonson
I don't have a "default" palette in the FPGA shifter. Maybe there's a default palette in the real shifter, and you're seeing those colours. It's something I can add.

Re: Project: HDMI/DVI out for STFM

Posted: 04 Oct 2018 10:48
by czietz
For the screen border afaik always palette entry 0 is used, so you'll see whatever color is programmed into that entry.

Re: Project: HDMI/DVI out for STFM

Posted: 04 Oct 2018 11:18
by Smonson
czietz wrote: 04 Oct 2018 10:48 For the screen border afaik always palette entry 0 is used, so you'll see whatever color is programmed into that entry.
Yeah, I think you're right. I have no theory to explain that behaviour.

Re: Project: HDMI/DVI out for STFM

Posted: 04 Oct 2018 14:17
by exxos
This is what it does on a real ST...

But on the HDMI board, it just stays white until the menu comes up.

Its not a huge issue.. but maybe someone knows a game menu which flashes background colours while decompressing and see if it has similar issues or not ?



Re: Project: HDMI/DVI out for STFM

Posted: 04 Oct 2018 15:01
by Smonson
I've seen the same effect on pretty much every pirated game, and as far as I know it works fine on HDMI. Spectrum 512 also uses the background colour to show bars, but it's a semi-static effect. I only use HDMI so I have no easy way to compare the two setups.

Re: Project: HDMI/DVI out for STFM

Posted: 25 Oct 2018 12:25
by Smonson
Small update regarding clocks.

I "engineered" in an NB3N551 proper clock buffer in place of the generic logic buffer I had on the adapter board originally. Anyway, it worked fine first go and is rated up to 180MHz, so that should hopefully be totally future-proof. Many thanks to rpineau for suggesting that part.

I've used 100Ω series resistors for both sides of the oscillator for this test, but I don't think it's necessary for the Atari side, just the FPGA side as proposed by Exxos (thanks again!).

:thanksyellow:

I'm getting new boards made within a month or so. The new socket adapter has the IDC connector inside of the 40-pin DIP outline, so it won't tip over when trying to plug in the ribbon cable anymore.
new-clock-buffer.png

Re: Project: HDMI/DVI out for STFM

Posted: 25 Oct 2018 12:47
by exxos
I would suggest putting resistors in there needed or not. can always zero ohm them if don't need them, but better to have that option. I generally add 33R in all clock ins and outs. I also use a schmitt buffer (tiny logic) for the actual buffering IC.

Re: Project: HDMI/DVI out for STFM

Posted: 26 Oct 2018 10:35
by Smonson
exxos wrote: 25 Oct 2018 12:47 I would suggest putting resistors in there needed or not. can always zero ohm them if don't need them, but better to have that option. I generally add 33R in all clock ins and outs. I also use a schmitt buffer (tiny logic) for the actual buffering IC.
About the extra "optional" resistor footprint: agreed. For the same reason, I'm keeping an electrolytic footprint on the socket adapter board just in case it's needed. I have just redrawn that board and the new one will be smaller and denser. The reason the 34-pin header is so far to the right is that I still need it to line up with the header on the other board, which is as far left as it can go. I've added a hole where access to the 16MHz clock can be accessed from a separate driver off the clock buffer (so as not to interfere with the system clock).

Do you know of a schmitt buffer that can also do 3.3 -> 5v level translation though? That's the thing.
socket-adapter-2.png