Project: HDMI/DVI out for STFM

Progress on our FPGA cores.
User avatar
Smonson
Posts: 708
Joined: Sat Oct 28, 2017 10:21 am
Location: Canberra, Australia
Contact:

Re: Project: HDMI/DVI out for STFM

Post by Smonson »

troed wrote: Wed Jan 03, 2018 11:26 am I think testing with Hatari instead of STEem might help here. The current wakestate-code in STEem isn't really emulating the hardware but more of an in-between thing that works with the code that has already been published and tested. I'm quite sure Spectrum 512 has a uniform border color.
Cool, thanks. I only have a single ST, and it would be a pain in the butt for me to put it back to 'stock' to test things. I've been relying on Steem to be my ST reference point. There is the "blank" signal from the glue which I haven't looked at; perhaps it's involved.
Can anyone suggest a program that displays a static image that extends into the overscan area? Preferably something that lets you specify which image, a picture viewer for example. With demos, there's usually crap flying everywhere and it's really hard to see what's going on.
I'm guessing left/right is of most interest? I believe I have some code by Evil/DHS that only displays a fullscreen, made for calculating number of visible lines. Both ST (230 byte) and STE-specific (224 byte) line variants.
This is excellent. Exactly what I need - thanks again Troed. Your help is always invaluable :D
User avatar
Smonson
Posts: 708
Joined: Sat Oct 28, 2017 10:21 am
Location: Canberra, Australia
Contact:

Re: Project: HDMI/DVI out for STFM

Post by Smonson »

About that overscan image display program. I see most of the image when it's running - just the right border seems to be wrong. I'm gonna get a bit technical:

Here is the output that is generated from my shifter model. This is a 512-pixel wide view that shows the output from the shifter at each point in time during the scanline (it ends in grey pixels).
overscan-result.png
overscan-result.png (1.22 MiB) Viewed 4007 times
As you can see it breaks down at a point where the ST switches to high-resolution and back to low to avoid the end-of-scanline condition.

Here's the top of the same screen overlaid with shifter signals and state:
overscan-overlaid.png
overscan-overlaid.png (293.43 KiB) Viewed 4007 times
The light blue line is DE. The line below that is the shifter's resolution (white=hi, red=low). The line above the blue line (with the cycling intensity) is the pixel counter. The part where you can see a dark version of the image has red lines superimposed over it, which are LOADs; similar yellow lines that come after every 4th LOAD are the reload signal.

It's obvious what's happening here. While the ST is in monochrome mode for several cycles, the shifter is generating monochrome video for more than 48 mono pixels. Here's a close-up view of this section of the display:
overscan-detail.png
overscan-detail.png (350.11 KiB) Viewed 4007 times
I am expecting that the real shifter has a 2nd copy of the resolution register so that it doesn't take effect immediately.
troed
Moderator
Moderator
Posts: 905
Joined: Mon Aug 21, 2017 10:27 pm

Re: Project: HDMI/DVI out for STFM

Post by troed »

The Shifter switches to the mono output pin and not RGB when in mono mode, effectively displaying black during that time. The Shifter does have it's own copy of RES but it takes effect "immediately" (4 cycle aligned).

You might be interested in some signal captures I'm doing at the moment: http://atari-forum.com/viewtopic.php?f=15&t=32918
Steven Seagal
Posts: 3
Joined: Mon Dec 18, 2017 10:06 pm

Re: Project: HDMI/DVI out for STFM

Post by Steven Seagal »

troed wrote: Sat Nov 25, 2017 2:35 pm{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.
/Troed
What precisely does Hatari emulate better?
AFAIK Closure is supported in recent versions of Steem (since v3.8 according to my "hit list").
I think testing with Hatari instead of STEem might help here. The current wakestate-code in STEem isn't really emulating the hardware but more of an in-between thing that works with the code that has already been published and tested. I'm quite sure Spectrum 512 has a uniform border color.
AFAIK Spectrum 512 works in Steem SSE, I think the rasters in the borders are quite normal.
Of course testing with other emulators is always a good idea.
But I don't agree with your comment, in fact the wakestate code was too generic if anything.
User avatar
Smonson
Posts: 708
Joined: Sat Oct 28, 2017 10:21 am
Location: Canberra, Australia
Contact:

Re: Project: HDMI/DVI out for STFM

Post by Smonson »

troed wrote: Sat Jan 06, 2018 1:26 pm The Shifter switches to the mono output pin and not RGB when in mono mode, effectively displaying black during that time. The Shifter does have it's own copy of RES but it takes effect "immediately" (4 cycle aligned).

You might be interested in some signal captures I'm doing at the moment: http://atari-forum.com/viewtopic.php?f=15&t=32918
I know I say it a lot lately, but... Steem doesn't display a black bar at that point, surely a real Atari displays continuous low-res pixels through the entire scanline without a gap?

A 4-cycle alignment of the update on the resolution register wouldn't be enough to cover the gap in this case, it looks like it's about 12 cycles long.

The LA recordings are fantastic and extremely valuable. Thanks for going to the trouble. I hope we can pull out interesting moments and build up a collection of illustrative cases that document how the video is generated in detail. I haven't played around with the viewer, but I'm looking forward to it.
troed
Moderator
Moderator
Posts: 905
Joined: Mon Aug 21, 2017 10:27 pm

Re: Project: HDMI/DVI out for STFM

Post by troed »

Smonson wrote: Sun Jan 07, 2018 9:59 am I know I say it a lot lately, but... Steem doesn't display a black bar at that point, surely a real Atari displays continuous low-res pixels through the entire scanline without a gap?
Nope :) At cycle 444 when the switch to high resolution happens the real Shifter indeed displays black until the switch back to low happens. This is actually the reason why ULM chose to use medium resolution for their stabilizer instead (from cycle 440) since that doesn't happen.

This is so far out into the right border that very few TVs/monitors displayed it. A modern LCD of course does, especially if you can tweak horizontal position.

12 cycles is indeed the normal length of a HI-LO stabilizer.

Just let me know what else I should capture, else I will just continue with what I think is relevant when I find the time :)

/Troed
User avatar
exxos
Site Admin
Site Admin
Posts: 23437
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: Project: HDMI/DVI out for STFM

Post by exxos »

troed wrote: Sun Jan 07, 2018 10:33 am
Just let me know what else I should capture, else I will just continue with what I think is relevant when I find the time :)
Could you please post you scope shots in a thread maybe in member blog section :)

Also, for those who are not keeping up (me mostly) are you saying during a normal video low output the shifter switches into high res.. Or is that just a trick demos do for some reason ?
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:

Re: Project: HDMI/DVI out for STFM

Post by Smonson »

troed wrote: Sun Jan 07, 2018 10:33 am Nope :) At cycle 444 when the switch to high resolution happens the real Shifter indeed displays black until the switch back to low happens. This is actually the reason why ULM chose to use medium resolution for their stabilizer instead (from cycle 440) since that doesn't happen.

This is so far out into the right border that very few TVs/monitors displayed it. A modern LCD of course does, especially if you can tweak horizontal position.

12 cycles is indeed the normal length of a HI-LO stabilizer.

Just let me know what else I should capture, else I will just continue with what I think is relevant when I find the time :)

/Troed
Whoa, so that 1st picture is actually correct? After the switch the mono and back, the output from the shifter is all garbled.

I've just been fooling around with it tonight and if I fix the resolution register at the beginning of the physical frame, it can display the whole image perfectly.

I'll probably make this a permanent change just for the mono-or-not-mono status, because changing to and from mono changes the physical parameters of the screen (because of the scan doubler, which moves everything down one scanline) and it can cause the monitor to lose sync. So you'd be able to change between low and medium during the video frame but not to mono and back.
overscan-full.png
overscan-full.png (845.1 KiB) Viewed 4007 times
Unfortunately I've just reached the end of my Christmas holidays :(
User avatar
Smonson
Posts: 708
Joined: Sat Oct 28, 2017 10:21 am
Location: Canberra, Australia
Contact:

Re: Project: HDMI/DVI out for STFM

Post by Smonson »

exxos wrote: Sun Jan 07, 2018 11:01 am Also, for those who are not keeping up (me mostly) are you saying during a normal video low output the shifter switches into high res.. Or is that just a trick demos do for some reason ?
It's not during a normal screen mode, it's done by this program to avoid the end of the scanline, because the point where the scanline ends is much earlier in mono mode. It (the GLUE I think?) is waiting to hit a specific cycle number to end the line, so by changing that number to one that it already passed, you can skip over that point and make it continue outputting more pixels.
troed
Moderator
Moderator
Posts: 905
Joined: Mon Aug 21, 2017 10:27 pm

Re: Project: HDMI/DVI out for STFM

Post by troed »

exxos wrote: Sun Jan 07, 2018 11:01 am Could you please post you scope shots in a thread maybe in member blog section :)

Also, for those who are not keeping up (me mostly) are you saying during a normal video low output the shifter switches into high res.. Or is that just a trick demos do for some reason ?
Currently I'm dumping traces to the A-F thread simply because I want to get input on what to capture. Once I have good and relevant captures I'll reformat those with analysis and likely post to my own blog - that I can then link here also of course :)

When doing fullscreens there are two tricks used. GLUE checks when to start and stop lines (and screen) depending on the resolution, so by carefully switching frequency or resolution at specific points the GLUE either starts lines or end lines at "wrong" (fullscreen!) positions. Additionally, extra words left behind in the Shifter that can screw up alignment on the next line can be "cleared" by going into high or medium resolution and then back to low at the very end of the line. That "stabilizer" is what Smonson and I discussed now :)
Smonson wrote: Sun Jan 07, 2018 11:22 am Whoa, so that 1st picture is actually correct? After the switch the mono and back, the output from the shifter is all garbled.
Yeah you should display black when mono is set on an otherwise color line, and you can ignore what happens after the stabilizer has run. Actually, in detail, the stabilizer skips BLANK start and the line is then displayed for a few more pixels until HSYNC kicks in which again means nothing should be displayed from there until BLANK is deasserted on the next line ;)

(The stabilizer is not used to "open" the right border - that's done via a 60/50Hz switch at cycle 376 and is not visible to the Shifter at all)
Post Reply

Return to “FPGA DEVELOPMENT”