Project: HDMI/DVI out for STFM

[troed]

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

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]

I asked Evil for the programs - here you go

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

/Troed

[Smonson]

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

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



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:



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:



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

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

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

[Smonson]

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]

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

[exxos]

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 ?

[Smonson]

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.



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