Project: HDMI/DVI out for STFM

Progress on our FPGA cores.
Post Reply
troed
Moderator
Moderator
Posts: 905
Joined: Mon Aug 21, 2017 10:27 pm

Project: HDMI/DVI out for STFM

Post by troed »

Smonson wrote: Fri Nov 24, 2017 1:22 pm Because the shifter doesn't see vsync and hsync, I don't use them at all. But so far it hasn't been necessary because the leading edge of DE is all you need in order to know when a scanline has begun, and therefore if you know how long each line is, you can add hsync near the end. Same principle for vsync: I detect the first scanline in the frame by a DE-to-DE delay of longer than 2048 32MHz clock cycles.
Alright, then yes, to make this overscan compatible some additional work is needed. The description below will be valid for "sync clean" demos/games - not all are and it's very difficult to generalize them. Specific testing and analysis might be needed for those.

The description below is the "state machine" I researched (building upon the shoulders of giants) and published on the defunct atari-forum wiki. I've since for my internal use started to write it as pseudo code following Ijor's description of how the GLUE actually works, but haven't published it anywhere yet. The state machine description will be good enough for this description.

Code: Select all

4    IF(71) H = TRUE
24    IF(60) BLANK = FALSE
28    IF(50) BLANK = FALSE
52    IF(60) H = TRUE
54    IF(60) LINE = 508 ELSEIF(50) LINE = 512
56    IF(50) H = TRUE
164    IF(71) H = FALSE
184    IF(71) BLANK = TRUE
372    IF(60) H = FALSE
376    IF(50) H = FALSE
450    IF(!71) BLANK = TRUE
LINE-50    IF(!71) HSYNC = TRUE && H = FALSE
LINE-10    IF(!71) HSYNC = FALSE
The cycles above are as seen by the CPU, in low/medium res. Additionally, the ST has four wakestates where changes to the RES and FREQ registers are delayed due to offsets between CPU and GLUE clocks. Example from cycle 56 in the above table for the four wakestates:

Code: Select all

WS1 (DL6): screen DE is FREQ 56, RES 57
WS3 (DL5): screen DE is FREQ 57, RES 58
WS4 (DL4): screen DE is FREQ 58, RES 59
WS2 (DL3): screen DE is FREQ 59, RES 60
DE takes immediate effect in the Shifter, but is picked up later by the MMU which then starts LOADing (DCYC) the Shifter after yet another slight delay. I think for your purposes you might be able to skip all the wakestate and delays stuff though.

There are thus (resulting from the table above) 12 different possible scanline lengths in the ST, resulting from DE being raised/lowered at different "locations" - or not at all (!): 0, 54, 56, 80, 158, 160, 162, 184, 186, 204, 206, 230 (in bytes).

(again, low/medium res, and there are some variants depending on 50/60Hz starting positions which is visibly offset on screen)

I'll think a bit on what might be possible to do here.
troed wrote: Fri Nov 24, 2017 10:36 am I'm very interested myself in getting HDMI out on my main STE so I'll be happy to lend any aid I can.
I don't have an STE, but it looks like the shifter is inside a much bigger 84-pin ASIC. Fortunately there's tons of room in the Cyclone-II so reimplementing the whole thing should be possible, so it could become a similar project. I've only used about 1,500 LEs out of 4,600 available, to get this far. And since this is literally the first time I've ever used an FPGA, I assume my verilog code is very inefficiently using the LEs.
Well, the quick solution might be to make a passthrough board to the original STE Shifter, and only route the "ST Shifter" signals to the HDMI-Shifter instead of the original? I haven't looked at possible overlap though, but the STE Shifter does a lot more other things not of interest for this mod.

/Troed
User avatar
Smonson
Posts: 708
Joined: Sat Oct 28, 2017 10:21 am
Location: Canberra, Australia
Contact:

Project: HDMI/DVI out for STFM

Post by Smonson »

troed wrote: Sat Nov 25, 2017 9:09 am ...The cycles above are as seen by the CPU, in low/medium res. Additionally, the ST has four wakestates where changes to the RES and FREQ registers are delayed due to offsets between CPU and GLUE clocks. Example from cycle 56 in the above table for the four wakestates:

Code: Select all

WS1 (DL6): screen DE is FREQ 56, RES 57
WS3 (DL5): screen DE is FREQ 57, RES 58
WS4 (DL4): screen DE is FREQ 58, RES 59
WS2 (DL3): screen DE is FREQ 59, RES 60
Thanks for all this info. I'm not sure how DE fits into it. Could you explain more about what that happens at that cycle number? Is that the position where the internal register takes effect?
troed wrote: Sat Nov 25, 2017 9:09 am DE takes immediate effect in the Shifter, but is picked up later by the MMU which then starts LOADing (DCYC) the Shifter after yet another slight delay. I think for your purposes you might be able to skip all the wakestate and delays stuff though.
I'll keep my fingers crossed :)
troed wrote: Sat Nov 25, 2017 9:09 am There are thus (resulting from the table above) 12 different possible scanline lengths in the ST, resulting from DE being raised/lowered at different "locations" - or not at all (!): 0, 54, 56, 80, 158, 160, 162, 184, 186, 204, 206, 230 (in bytes).
Obviously if the scanline extends past 1024 clocks or 128 bytes, it's going to cause a problem for interpreting the data via the shifter. We are talking about lines that must pass through the position where HSYNC should be...
troed wrote: Sat Nov 25, 2017 9:09 am Well, the quick solution might be to make a passthrough board to the original STE Shifter, and only route the "ST Shifter" signals to the HDMI-Shifter instead of the original? I haven't looked at possible overlap though, but the STE Shifter does a lot more other things not of interest for this mod.
It seems possible, I had a look at the pinout for that chip and it seems to have all the interesting signals.

Here's what I've got tonight:

After increasing the DE-to-DE minimum gap for a new video frame, I was able to synchronise the screen for this demo that uses overscan:
overscan1.jpg
overscan1.jpg (451.81 KiB) Viewed 3803 times
Not sure yet what causes the gap on the left, but getting in sync is a good start.

I was also able to also stay in sync for the first part of Closure where the word SYNC is bouncing around the screen (at small size). It looked the same as Steem renders it, I haven't seen it run on a real Atari to know if it's meant to look like that (like bitplanes are out of order).

Under the scope I can see that there are scanlines with odd lengths, which confuse the system into thinking a new frame is starting. So it loses sync at that point.
DS0001.png
DS0001.png (9.26 KiB) Viewed 3803 times
This is DE on the bottom trace during Closure (the top is just a debug signal for start-of-frame). I think that's the real start of the frame on the left pulse, then another false start after a couple of real scanlines and a long gap. That's definitely the reason why it's getting out of sync. The distance represented by the cursors is exactly 4 physical scanlines. So there are two DEs completely left out.
troed
Moderator
Moderator
Posts: 905
Joined: Mon Aug 21, 2017 10:27 pm

Project: HDMI/DVI out for STFM

Post by troed »

Smonson wrote: Sat Nov 25, 2017 1:46 pm Thanks for all this info. I'm not sure how DE fits into it. Could you explain more about what that happens at that cycle number? Is that the position where the internal register takes effect?
The other table is the one of interest, I do not believe wakestates are important ;) "H=TRUE" can be read as DE going high (in reality H is ANDed with V to form DE but I didn't post the table for vertical checks).

This is how the 12 different possible line lengths on the ST (in 50Hz) are generated. As you can see, for one of them DE never goes high, and for the other it will go hi and low at different positions during the scanline:

Code: Select all

0: DE never activated
54: DE activated at 60, deactivated at 168. (168-60)/2 = 54
56: DE activated at 56, deactivated at 168. (168-56)/2 = 56
80: DE activated at 8, deactivated at 168. (168-8)/2 = 80
158: DE activated at 60, deactivated at 376. (376-60)/2 = 158
160: DE activated at 56, deactivated at 376. (376-56)/2 = 160
160: DE activated at 60, deactivated at 380. (380-60)/2 = 160
162: DE activated at 56, deactivated at 380. (380-56)/2 = 162
184: DE activated at 8, deactivated at 376. (376-8)/2 = 184
186: DE activated at 8, deactivated at 380. (380-8)/2 = 186
204: DE activated at 60, deactivated at 468. (468-60)/2 = 204
206: DE activated at 56, deactivated at 468. (468-56)/2 = 206
230: DE activated at 8, deactivated at 468. (468-8)/2 = 230
(as a bonus, I include the case of a regular length 160 byte scanline but one that starts four cycles early and ends four cycles early at the 60Hz positions instead of 50. it would show as 4 pixels to the left of a normal one when displayed on screen)

In this table the first and last values are the number of bytes the scanline will consume (LOAD from MMU) and the other values are cycles DE goes high and low during the 512 cycle scanline. I guess it would be possible to hard code these into your code, but I don't currently know how to solve the case of DE never going high.

{Closure} is a tricky demo to emulate and Hatari does a better job at it compared to STeem. There should be some setting in STeem that will show the demo without shifted bitplanes though. That's the next problem to tackle, how to accurately emulate the Shifters IR/RR register behaviour, with your mod.

Regarding the start of {Closure}, even the small dist logo is indeed run in fullscreen. However, I don't think I'm sync scrolling (using the 12 different line lengths at the top of the screen) until the big logo appears. If this doesn't seem correct then I'll have to dive into the source, but I think it is. And yes, considering how you detect lines I'm sure that sync scrolls mess up badly since DE signal positions shift constantly.

Come to think of it, I've assumed the workings of sync scrolling to be obvious. Sorry if you know already but I'm writing a quick explanation anyway :) Sync scrolling is the use of a combination of scanlines at different length causing the MMU to LOAD ("eat") a varying amount of video memory. This of course causes the subsequent graphics to be "shifted" the same amount of memory - in effect scrolling the graphics left/right. A sync scroll table is thus one where lines of different lengths are combined to reach the offsets 0,2,4,6,8 ... 254. Shifts of 256 bytes can be made by poking the middle video base address, so what sync scrolling does in effect is simulating being able to also set the low byte.

(I think you mean 256 bytes, not 128 bytes btw, for the full line which would cover hsync)

/Troed
User avatar
Smonson
Posts: 708
Joined: Sat Oct 28, 2017 10:21 am
Location: Canberra, Australia
Contact:

Project: HDMI/DVI out for STFM

Post by Smonson »

troed wrote: Sat Nov 25, 2017 2:35 pm Come to think of it, I've assumed the workings of sync scrolling to be obvious. Sorry if you know already but I'm writing a quick explanation anyway :) Sync scrolling is the use of a combination of scanlines at different length causing the MMU to LOAD ("eat") a varying amount of video memory. This of course causes the subsequent graphics to be "shifted" the same amount of memory - in effect scrolling the graphics left/right. A sync scroll table is thus one where lines of different lengths are combined to reach the offsets 0,2,4,6,8 ... 254. Shifts of 256 bytes can be made by poking the middle video base address, so what sync scrolling does in effect is simulating being able to also set the low byte.
You're right, I hadn't the faintest idea how sync scrolling worked until now, thanks for the explanation!
troed wrote: Sat Nov 25, 2017 2:35 pm (I think you mean 256 bytes, not 128 bytes btw, for the full line which would cover hsync)
D'oh, yeah, I was thinking one pixel per bit... my eyes and brain were getting pretty blurry by the time I made that post.

Today I've attached an extra wire down to get vsync off the GLUE, and I've got a working implementation at 60Hz (not overscan, just the desktop) which is synchronising everything to the leading edge of vsync. It seems pretty stable - I think this will solve the problem as long as Closure and other demos don't affect the position of the vsync pulse with respect to the video data.

This could be an optional thing, because it'll make it harder to install the mod.
troed
Moderator
Moderator
Posts: 905
Joined: Mon Aug 21, 2017 10:27 pm

Project: HDMI/DVI out for STFM

Post by troed »

Smonson wrote: Sun Nov 26, 2017 7:19 am Today I've attached an extra wire down to get vsync off the GLUE, and I've got a working implementation at 60Hz (not overscan, just the desktop) which is synchronising everything to the leading edge of vsync. It seems pretty stable - I think this will solve the problem as long as Closure and other demos don't affect the position of the vsync pulse with respect to the video data.

This could be an optional thing, because it'll make it harder to install the mod.
Well, expanding on that then it would be easy to solve sync scrolling as well. Use vsync _and_ hsync, and display as much data (and when, on the line) as LOADed by the MMU.

There could then be two installation methods. One "easy" (desoldering the Shifter is never easy though, not that many are socketed) which will not support sync scrolling and maybe fail at a few fullscreens, and one "difficult" (two additional solder points to the GLUE signals) which would be very compatible.

/Troed
User avatar
Smonson
Posts: 708
Joined: Sat Oct 28, 2017 10:21 am
Location: Canberra, Australia
Contact:

Project: HDMI/DVI out for STFM

Post by Smonson »

troed wrote: Sun Nov 26, 2017 9:35 am Well, expanding on that then it would be easy to solve sync scrolling as well. Use vsync _and_ hsync, and display as much data (and when, on the line) as LOADed by the MMU.
Hmm, I don't know if hsync is really needed. Vsync coincides with the first clock cycle of a scanline, so hsync only provides additional information if the scanline timing is messed up - which will probably screw up the HDMI frame (I haven't tested this but I doubt a digital TV would be happy with non-uniform scanline lengths).
troed wrote: Sun Nov 26, 2017 9:35 am There could then be two installation methods. One "easy" (desoldering the Shifter is never easy though, not that many are socketed) which will not support sync scrolling and maybe fail at a few fullscreens, and one "difficult" (two additional solder points to the GLUE signals) which would be very compatible.
My thoughts as well. I didn't know shifters were normally not socketed, that's a shame since they probably need to be destroyed to remove them. The reason I am removing the shifter in this mod, instead of leaving it in place and passively reading the same signals, is that I need the 32MHz clock. But maybe it would work with just the 16MHz clock pin and the spare PLL.

On the other hand, the shifter is an IC dedicated to generating video that can't be displayed properly in any country where SCART TVs aren't available. So maybe most people will be OK with removing them. I'm not going to miss mine.

Here's a progress shot for tonight. It should be downhill from here since the rest is just down to various timing counters and logic. Crossed fingers.
closure2.jpg
closure2.jpg (146.37 KiB) Viewed 3803 times
User avatar
exxos
Site Admin
Site Admin
Posts: 23437
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Project: HDMI/DVI out for STFM

Post by exxos »

Looking cool!

If Vsync makes life easier then use it. A lot of shifters are not in sockets as mentioned, and I go with what someone said the other day, that if people want solderless upgrades, then they need a different hobby ;)
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
User avatar
Smonson
Posts: 708
Joined: Sat Oct 28, 2017 10:21 am
Location: Canberra, Australia
Contact:

Project: HDMI/DVI out for STFM

Post by Smonson »

Hi guys, I've hit a gap in my knowledge here...

The shifter keeps its 2-bit register index counter which address the IR regs when LOADing data, and increments by one each time.

In order for sync scrolling to work, I think that index counter is not cleared at the end of a scanline, so it can start shifting out pixels after 1, 2, or 3 loads.

But if that's the case, if you hit reset or some software crashes, the ST might write an odd number of LOADs into the shifter, leaving the screen all messed up as the bitplanes from video memory will never be loaded into the correct location in the shifter from that point on (all scanline data being in multiples of 4 LOADs).

My question is does the shifter ever reset any of its internal registers - if so what triggers it?
User avatar
exxos
Site Admin
Site Admin
Posts: 23437
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Project: HDMI/DVI out for STFM

Post by exxos »

Smonson wrote: Mon Nov 27, 2017 11:52 am Hi guys, I've hit a gap in my knowledge here...

The shifter keeps its 2-bit register index counter which address the IR regs when LOADing data, and increments by one each time.

In order for sync scrolling to work, I think that index counter is not cleared at the end of a scanline, so it can start shifting out pixels after 1, 2, or 3 loads.

But if that's the case, if you hit reset or some software crashes, the ST might write an odd number of LOADs into the shifter, leaving the screen all messed up as the bitplanes from video memory will never be loaded into the correct location in the shifter from that point on (all scanline data being in multiples of 4 LOADs).

My question is does the shifter ever reset any of its internal registers - if so what triggers it?

As far as I know, nothing resets on the shifter. I did wonder about this while I was doing my hardware shifter design. As there is actually nothing to even set what bit plane is output first. As there is for registers, then it would be potluck which one gets the data first. Obviously this does not sound correct as chances are the shifter would output garbage a lot of the time on power up. So I can only assume any reset signals is on power up where everything defaults to 0.

Troed will probably have some input on this.. But I do wonder exactly the same thing..

I can only assume that internal counters are reset on resolution changes..

As a side note, I have actually seen on the STE bit planes out of phase.. This mostly happens on power up and I am not sure exactly why.

Image

Image

Interestingly, the fault seems to pass over to the desktop.. I'm assuming the STE powers up in medium resolution ? But I am not convinced myself that changing the resolution is what resets the counters... Resetting the machine I think does actually reset something in the shifter so the bit planes are properly in phase again... I have never seen this happen on the STFM though, only the STE what I remember. Unfortunately, this problem is very rare so I have never been able to ever look into it :(

It is a really interesting question though...
https://www.exxosforum.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxosforum.co.uk/atari/store2/ - All my hardware mods for sale - Please help support by making a purchase.
viewtopic.php?f=17&t=1585 Have you done the Mandatory Fixes ?
Just because a lot of people agree on something, doesn't make it a fact. ~exxos ~
People should find solutions to problems, not find problems with solutions.
User avatar
Smonson
Posts: 708
Joined: Sat Oct 28, 2017 10:21 am
Location: Canberra, Australia
Contact:

Project: HDMI/DVI out for STFM

Post by Smonson »

OK, it's not just me then :lol:
Post Reply

Return to “FPGA DEVELOPMENT”