Project: HDMI/DVI out for STFM

General discussions or ideas about hardware.
troed
Posts: 237
Joined: Mon Aug 21, 2017 10:27 pm

Re: Project: HDMI/DVI out for STFM

Post by troed » Wed Jan 03, 2018 11:26 am

Smonson wrote:
Wed Jan 03, 2018 8:28 am
[*]On a real ST, does Spectrum 512 show a bunch of colours in the screen border area when it's just displaying the image? In Steem SSE, it does if you enable a wake state, but not if you set it to "ignore". I always see colours in the border with my setup.
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.
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.
Petari wrote:
Wed Jan 03, 2018 8:52 am
I have some overscan displaying code, mostly for STE. Res 416x 240 and similar. It is wakestate sensitive.
I think it's important to separate GLUE-MMU wakestates (WS1-WS4, can be tested in software) and Shifter(-MMU) wakestates (not completely researched, but "Spectrum 512 black pixels" is one. Cannot be detected from software, only visually).

GLUE-MMU wakestates only exist on ST, not STE.
Shifter-MMU wakestates, at least some, exists on both ST and STE.

troed
Posts: 237
Joined: Mon Aug 21, 2017 10:27 pm

Re: Project: HDMI/DVI out for STFM

Post by troed » Wed Jan 03, 2018 11:47 am

I asked Evil for the programs - here you go :)

http://ae.dhs.nu/tmp/oversc.zip

/Troed

User avatar
Smonson
Posts: 97
Joined: Sat Oct 28, 2017 10:21 am

Re: Project: HDMI/DVI out for STFM

Post by Smonson » Wed Jan 03, 2018 1:37 pm

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: 97
Joined: Sat Oct 28, 2017 10:21 am

Re: Project: HDMI/DVI out for STFM

Post by Smonson » Sat Jan 06, 2018 1:11 pm

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

Image

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:

Image

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:

Image

I am expecting that the real shifter has a 2nd copy of the resolution register so that it doesn't take effect immediately.

troed
Posts: 237
Joined: Mon Aug 21, 2017 10:27 pm

Re: Project: HDMI/DVI out for STFM

Post by troed » 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

Steven Seagal
Posts: 3
Joined: Mon Dec 18, 2017 10:06 pm

Re: Project: HDMI/DVI out for STFM

Post by Steven Seagal » Sat Jan 06, 2018 8:35 pm

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: 97
Joined: Sat Oct 28, 2017 10:21 am

Re: Project: HDMI/DVI out for STFM

Post by Smonson » Sun Jan 07, 2018 9:59 am

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
Posts: 237
Joined: Mon Aug 21, 2017 10:27 pm

Re: Project: HDMI/DVI out for STFM

Post by troed » Sun Jan 07, 2018 10:33 am

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
Posts: 2885
Joined: Wed Aug 16, 2017 11:19 pm
Location: UK
Contact:

Re: Project: HDMI/DVI out for STFM

Post by exxos » Sun Jan 07, 2018 11:01 am

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 ?
4MB STFM 1.44 FD- VELOCE+ 020 STE - 4MB STE 32MHz - STFM 16MHz - STM - MEGA ST - Falcon 030 CT60 - Atari 2600 - Atari 7800 - Gigafile - SD Floppy Emulator - PeST - HxC - CosmosEx - Ultrasatan - various clutter

https://www.exxoshost.co.uk/atari/ All my hardware guides - mods - games - STOS
https://www.exxoshost.co.uk/atari/last/storenew/ - All my hardware mods for sale - Please help support by making a purchase.

User avatar
Smonson
Posts: 97
Joined: Sat Oct 28, 2017 10:21 am

Re: Project: HDMI/DVI out for STFM

Post by Smonson » Sun Jan 07, 2018 11:22 am

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.

Image

Unfortunately I've just reached the end of my Christmas holidays :(

Post Reply