Project: HDMI/DVI out for STFM

[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?

[exxos]

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

[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.

[czietz]

For the screen border afaik always palette entry 0 is used, so you'll see whatever color is programmed into that entry.

[Smonson]

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.

[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 ?

[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.

[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

[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.

[Smonson]

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