STFM to DVI/HDMI project

Troubles with your machine? Just want to speak about the latest improvements? This is the place!

Moderators: Mug UK, Zorro 2, spiny, Greenious, Moderator Team

User avatar
Smonson
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 120
Joined: Sat Feb 20, 2016 9:45 am
Location: Canberra
Contact:

Re: STFM to DVI/HDMI project

Postby Smonson » Thu Dec 28, 2017 8:22 am

ijor wrote:Forget about the original clock mux implementation. Forget about the complicated logic of the pixel counter. Your old, simple, shifter model that you said you implemented before, should work. There is nothing special at all about (classic) overscan or sync scroll regarding Shifter. The only thing is that you need to be ready to accept more loads per line and more active scan lines, that's all. You can also ignore changes to the resolution register outside the active area.

In theory, yeah. But it doesn't work, so obviously there is still some critical difference. There are assumptions that I have yet to confirm, such as the distance between VSYNC and scanline clock cycle 0, which could be the problem. Easy enough - if I had time to work on it.

The problem seems to be that you started testing overscan with the Closure demo. As we are saying, that is a very special and unique case. Try other demos with your old, simple model.

I didn't start with Closure, but it seemed like a good test since it exercises the shifter. Before I ran out of time, I was focusing just on fixing a palette issue with Spectrum 512 actually.

The original simple model is fundamentally incompatible with any software that interferes with DE, which is why a new approach (with frames synchronised to VSYNC in this case) is needed.

User avatar
Smonson
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 120
Joined: Sat Feb 20, 2016 9:45 am
Location: Canberra
Contact:

Re: STFM to DVI/HDMI project

Postby Smonson » Thu Dec 28, 2017 8:29 am

Thanks for the summary Troed - you are spot on.

Eventually this stuff will be all be worked out. If someone is impatient and just wants to run standard ST modes, I can sell you a board that can do that right now.

ijor
Hardware Guru
Hardware Guru
Posts: 3459
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: STFM to DVI/HDMI project

Postby ijor » Thu Dec 28, 2017 1:52 pm

troed wrote:I propose picking up HSYNC and VSYNC from GLUE and synchronizing the scanline and frame signalling to those. The new Shifter implementation then becomes really simple, it's just a question of detecting when DE goes high and react to each LOAD when it arrives. This will solve regular line, regular fullscreens _and_ sync scrolls and non-standard lines that many demos manage to do by accident. The reason for proposing this is that one of the 12 possible lines that a sync scroll can create is a 0-byte line where DE never goes high at all.


It doesn't matter if you don't have HSYNC information for one scan line. You can use the previous one. Sync shouldn't change every scan line, and if it does, you don't care for displaying purposes. You actually don't even need HSYNC at all. You can infer it from VSYNC, because the relation between both sync signals is fixed for a given display frequency.

Probably you don't even need VSYNC, you can also infer it. It might be a bit complicated for full screen, but sounds feasible. And again, you don't need to detect VSYNC on every single frame.

ijor
Hardware Guru
Hardware Guru
Posts: 3459
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: STFM to DVI/HDMI project

Postby ijor » Thu Dec 28, 2017 1:56 pm

Smonson wrote:The problem is these modes and techniques depend on completely internal implementation details of the shifter at a fine level of detail, which are unknown to me and virtually impossible to work out by observation of the shifter in situ.


Smonson wrote:In theory, yeah. But it doesn't work, so obviously there is still some critical difference. There are assumptions that I have yet to confirm, such as the distance between VSYNC and scanline clock cycle 0, which could be the problem.


If it doesn't work, it is not because there are "internal details of the shifter that are unknown to you".

Syncing the output (and even inferring sync if you don't connect VSYNC) is a completely different issue. That is not something you are going to solve even if you would implement a perfect shifter reproduction. Shifter doesn't know and doesn't care about sync.

The original simple model is fundamentally incompatible with any software that interferes with DE, which is why a new approach (with frames synchronised to VSYNC in this case) is needed.


Again, one thing is synchronizing to VSYNC, another is the internal details of shifter. Your original simple model, at the extent of the strict Shifter functionality should be enough. You need to sync the Shifter logic output with the display. But you don't need a more accurate shifter model for that purpose.

User avatar
Smonson
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 120
Joined: Sat Feb 20, 2016 9:45 am
Location: Canberra
Contact:

Re: STFM to DVI/HDMI project

Postby Smonson » Thu Dec 28, 2017 2:04 pm

Yeah, I can sychronise the line timing to either a long gap between DEs (only for standard modes) or VSYNC. Right now I haven't connected HSYNC.

I don't know what you want me to do, things that should be working aren't working, more study is needed, and will be resumed when I have time.

User avatar
troed
Atari God
Atari God
Posts: 1424
Joined: Mon Apr 30, 2012 6:20 pm
Location: Sweden

Re: STFM to DVI/HDMI project

Postby troed » Thu Dec 28, 2017 2:15 pm

ijor wrote:It doesn't matter if you don't have HSYNC information for one scan line. You can use the previous one. Sync shouldn't change every scan line, and if it does, you don't care for displaying purposes. You actually don't even need HSYNC at all. You can infer it from VSYNC, because the relation between both sync signals is fixed for a given display frequency.


Well, you would think :) Unfortunately there are demos (even games I think*) that manage to do some lines in "60Hz" 508 cycles and the rest in 512. Some even do it on purpose (four lines of 508 cycles makes the E-clock jitter disappear between VBLs) and most by mistake.

*) At least Enchanted Land does two lines without HSYNC in between by mistake

ijor
Hardware Guru
Hardware Guru
Posts: 3459
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: STFM to DVI/HDMI project

Postby ijor » Thu Dec 28, 2017 2:19 pm

Smonson wrote:I don't know what you want me to do, things that should be working aren't working, more study is needed, and will be resumed when I have time.


I don't want you to do anything :) I just wanted to make clear that the problem is not what you were thinking (the finer details of Shifter's internals).

Sorry if I sounded too harsh. Rereading my own post I see I might have been. We are all actually very excited about your project :cheers:

ijor
Hardware Guru
Hardware Guru
Posts: 3459
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: STFM to DVI/HDMI project

Postby ijor » Thu Dec 28, 2017 2:25 pm

troed wrote:Well, you would think :) Unfortunately there are demos (even games I think*) that manage to do some lines in "60Hz" 508 cycles and the rest in 512. Some even do it on purpose (four lines of 508 cycles makes the E-clock jitter disappear between VBLs) and most by mistake.


As I said, it doesn't matter for display purposes. A modern monitor can't even accept such a mixed sync. And the display might jump or bent on CRT ones. In the worst cases, we are only talking about a couple of cases. One demo and one game that I know. May be one or two more.

At least Enchanted Land does two lines without HSYNC in between by mistake


Again, it doesn't matter for displaying purposes. IIRC that is part of the (wrong) GLUE calibration with no active display.

ijor
Hardware Guru
Hardware Guru
Posts: 3459
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: STFM to DVI/HDMI project

Postby ijor » Thu Dec 28, 2017 5:06 pm

troed wrote:Well, you would think :) Unfortunately there are demos (even games I think*) that manage to do some lines in "60Hz" 508 cycles and the rest in 512. Some even do it on purpose (four lines of 508 cycles makes the E-clock jitter disappear between VBLs) and most by mistake.


Btw, out of curiosity. Do you remember which demos do that?

User avatar
troed
Atari God
Atari God
Posts: 1424
Joined: Mon Apr 30, 2012 6:20 pm
Location: Sweden

Re: STFM to DVI/HDMI project

Postby troed » Thu Dec 28, 2017 5:35 pm

ijor wrote:
troed wrote:Well, you would think :) Unfortunately there are demos (even games I think*) that manage to do some lines in "60Hz" 508 cycles and the rest in 512. Some even do it on purpose (four lines of 508 cycles makes the E-clock jitter disappear between VBLs) and most by mistake.


Btw, out of curiosity. Do you remember which demos do that?


The famous "tv-snow" screen by The Carebears in SNYD1 does that on the first line after the top border (due to a slight mistake in the coding). I've seen more but I don't think I've kept a list :/

http://www.atari-forum.com/viewtopic.ph ... 25#p237808

(My Dell 2001FP LCD has no issues with some lines being in 508 cycles btw)

ijor
Hardware Guru
Hardware Guru
Posts: 3459
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: STFM to DVI/HDMI project

Postby ijor » Thu Dec 28, 2017 6:59 pm

troed wrote:The famous "tv-snow" screen by The Carebears in SNYD1 does that on the first line after the top border (due to a slight mistake in the coding).


Thanks. But I meant those that you say they do that intentionally.

(My Dell 2001FP LCD has no issues with some lines being in 508 cycles btw)


Yeah. You always mention the wonders of that monitor :) But it is probably an exception. And I guess you use an analog connection (VGA). It is usually very different through a digital port, specially over HDMI.

User avatar
Steven Seagal
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2018
Joined: Sun Dec 04, 2005 9:12 am
Location: Undisclosed
Contact:

Re: STFM to DVI/HDMI project

Postby Steven Seagal » Thu Dec 28, 2017 9:29 pm

ijor wrote:For "classic" overscan and sync scrolling there is nothing to know. Forget about the original clock mux implementation. Forget about the complicated logic of the pixel counter. Your old, simple, shifter model that you said you implemented before, should work. There is nothing special at all about (classic) overscan or sync scroll regarding Shifter. The only thing is that you need to be ready to accept more loads per line and more active scan lines, that's all. You can also ignore changes to the resolution register outside the active area.


With two caveats but I suppose they're obvious:
If you don't go for 100% emulation, the Shifter registers and the LOAD counter should be cleared at the end of each scanline.
The Shifter must also load and (pretend to) shift words that are not displayed because of BLANK in overscan lines.
In the CIA we learned that ST ruled
Steem SSE: http://sourceforge.net/projects/steemsse

User avatar
npomarede
Atari God
Atari God
Posts: 1244
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: STFM to DVI/HDMI project

Postby npomarede » Thu Dec 28, 2017 10:29 pm

ijor wrote:
troed wrote:The famous "tv-snow" screen by The Carebears in SNYD1 does that on the first line after the top border (due to a slight mistake in the coding).


Thanks. But I meant those that you say they do that intentionally.

It was first discussed here with the shorter VBL by Mr.Nii http://atari-forum.com/viewtopic.php?f=68&t=26501
Then Mr.Nii made a demo for "Tos Crew" using it, combined with it's very good 4 pixel width color change https://www.pouet.net/prod.php?which=29074

ijor
Hardware Guru
Hardware Guru
Posts: 3459
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: STFM to DVI/HDMI project

Postby ijor » Fri Dec 29, 2017 1:40 am

npomarede wrote:It was first discussed here with the shorter VBL by Mr.Nii http://atari-forum.com/viewtopic.php?f=68&t=26501
Then Mr.Nii made a demo for "Tos Crew" using it, combined with it's very good 4 pixel width color change https://www.pouet.net/prod.php?which=29074


Ah, Hans, yes. Thank Nicolas.

Well. If I understand correctly, in all these cases that sync is altered, there is no display on those specific lines. You don't really need the exact HSYNC position in those lines. You need the HSYNC position only on the lines that do have an actual active display.

It might be an interesting exercise, but using VSYNC and DE it should still be possible to infer the correct HSYNC. Note again that it doesn't matter if you can't infer HSYNC for every scan line. The active display should always have the same HSYNC position for the whole frame. And if it doesn't, even a CRT normally bents the display as mentioned in the thread quoted above, so it doesn't matter.

User avatar
olivierg
Atari maniac
Atari maniac
Posts: 95
Joined: Wed Jul 27, 2016 2:10 pm
Location: Belgium
Contact:

Re: STFM to DVI/HDMI project

Postby olivierg » Sat Jan 06, 2018 11:51 am

Hi Smonson,

I follow your project with interest.

Do you think we could do the same thing for the TT especially for high resolution.
I tested various analog solution (EC2 to TTL) and I am not satisfied with the quality, especially on current screens.

Thanks
Olivier
TT030 4/32 TOS 3.06 SCSI2SD 5.x HD, Mega STE 4Mb TOS 2.06 DD, Mega ST4 DD miniCosmosEX, Mega ST2 DD, 1040 STE DD, 2 x 1040STFM DD, 2 x 1040STF, MegaFile 30, Lynx 1

User avatar
Smonson
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 120
Joined: Sat Feb 20, 2016 9:45 am
Location: Canberra
Contact:

Re: STFM to DVI/HDMI project

Postby Smonson » Sat Jan 06, 2018 12:27 pm

Hi Olivier,

It should be possible to perform the same job on the TT, but not with the same hardware. The FPGA board I'm using doesn't have enough IO pins for the 64-bit data bus. But in the future, who knows.

Simon

User avatar
olivierg
Atari maniac
Atari maniac
Posts: 95
Joined: Wed Jul 27, 2016 2:10 pm
Location: Belgium
Contact:

Re: STFM to DVI/HDMI project

Postby olivierg » Thu Jan 11, 2018 8:38 pm

I did not understand that you recreate the video signal from the bus, I thought you just convert the RGB signal output to HDMI.


Thanks
Olivier
TT030 4/32 TOS 3.06 SCSI2SD 5.x HD, Mega STE 4Mb TOS 2.06 DD, Mega ST4 DD miniCosmosEX, Mega ST2 DD, 1040 STE DD, 2 x 1040STFM DD, 2 x 1040STF, MegaFile 30, Lynx 1

User avatar
Smonson
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 120
Joined: Sat Feb 20, 2016 9:45 am
Location: Canberra
Contact:

Re: STFM to DVI/HDMI project

Postby Smonson » Thu Jan 11, 2018 9:55 pm

Regarding that, it's also a possibility to do so, but I initially envisaged this method being simpler. I think that I was wrong about that, and so I might try to make a board that reads the RGB values from the shifter's pins and leaves the shifter in place (this will work better on STE too). But right now, I want to finish this project before moving on to another one. Maybe someone else will do it first :)

User avatar
troed
Atari God
Atari God
Posts: 1424
Joined: Mon Apr 30, 2012 6:20 pm
Location: Sweden

Re: STFM to DVI/HDMI project

Postby troed » Thu Jan 11, 2018 10:38 pm

Smonson wrote:Regarding that, it's also a possibility to do so, but I initially envisaged this method being simpler. I think that I was wrong about that, and so I might try to make a board that reads the RGB values from the shifter's pins and leaves the shifter in place (this will work better on STE too). But right now, I want to finish this project before moving on to another one. Maybe someone else will do it first :)


Apparently there are three different Shifters, with slightly different motherboards, looking at the Mega ST schematics at least. One of the Shifter models does not output 3 bits RGB each, but has an internal version of the resistor grid and outputs the analog R,G,B signals directly.

C101608 would be that Shifter model. I have no idea how common it is.

ijor
Hardware Guru
Hardware Guru
Posts: 3459
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: STFM to DVI/HDMI project

Postby ijor » Fri Jan 12, 2018 12:38 am

troed wrote:Apparently there are three different Shifters, with slightly different motherboards, looking at the Mega ST schematics at least. One of the Shifter models does not output 3 bits RGB each, but has an internal version of the resistor grid and outputs the analog R,G,B signals directly. C101608 would be that Shifter model. I have no idea how common it is.


I doubt that version with integrated DAC exists at all. It would also require a special version of the motherboard.

ijor
Hardware Guru
Hardware Guru
Posts: 3459
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: STFM to DVI/HDMI project

Postby ijor » Fri Jan 12, 2018 12:41 am

Smonson wrote:But right now, I want to finish this project before moving on to another one. Maybe someone else will do it first :)


So how is this project going, Smonson? Any news? :)

Did you try what I recommended? Enhancing/fixing the simple model that should work with almost all overscan programs?

User avatar
Smonson
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 120
Joined: Sat Feb 20, 2016 9:45 am
Location: Canberra
Contact:

Re: STFM to DVI/HDMI project

Postby Smonson » Fri Jan 12, 2018 8:25 am

I didn't, because of a lack of free time, but I have fixed a couple of bugs since last progress post. Spectrum 512 works well now and also an overscan test program that Troed sent to me that displays a static image with all borders extended.

Static test programs like that are useful because I use a screen mode that displays the shifter state and sync signals for debugging (pictured) - I haven't got a LA, just a 2-channel 'scope. Moving demos are hard to follow.

Image

ijor
Hardware Guru
Hardware Guru
Posts: 3459
Joined: Sat May 29, 2004 7:52 pm
Contact:

Re: STFM to DVI/HDMI project

Postby ijor » Fri Jan 12, 2018 10:58 am

Smonson wrote:Spectrum 512 works well now and also an overscan test program that Troed sent to me that displays a static image with all borders extended.


Nice :)

I haven't got a LA, just a 2-channel 'scope. Moving demos are hard to follow.


I guess you know that the FPGA has some sort of integrated LA (SignalTap) that is invaluable for debugging.

User avatar
Smonson
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 120
Joined: Sat Feb 20, 2016 9:45 am
Location: Canberra
Contact:

Re: STFM to DVI/HDMI project

Postby Smonson » Fri Jan 12, 2018 11:19 am

ijor wrote:I guess you know that the FPGA has some sort of integrated LA (SignalTap) that is invaluable for debugging.


Haha, Quartus has about three trillion buttons I've never clicked on... :wink:

User avatar
troed
Atari God
Atari God
Posts: 1424
Joined: Mon Apr 30, 2012 6:20 pm
Location: Sweden

Re: STFM to DVI/HDMI project

Postby troed » Fri Jan 12, 2018 12:24 pm

ijor wrote:
troed wrote:Apparently there are three different Shifters, with slightly different motherboards, looking at the Mega ST schematics at least. One of the Shifter models does not output 3 bits RGB each, but has an internal version of the resistor grid and outputs the analog R,G,B signals directly. C101608 would be that Shifter model. I have no idea how common it is.


I doubt that version with integrated DAC exists at all. It would also require a special version of the motherboard.


Yeah it does sound strange. However, while the Mega ST schematics are from 1986, you can find the part number also in the Mega STE service manual from 1991:

U17
C025914
IC CUSTOM SHIFTER
U31 or
C101608
IC CUSTOM FULL SHIFTER (w/D/A)
U31


But I agree it seems completely lacking as a motherboard revision.

/Troed


Social Media

     

Return to “Hardware”

Who is online

Users browsing this forum: No registered users and 10 guests