STE specific fullscreen issue

[leonard]

Hi all,

I discovered at STNICCC that my mega-distorter screen in the "We Were @" does not open the left border on the compo machine. It works on many STE but that one. Another people reported me the same trouble. As I know there is many fullscreen or ST hardware gurus here, I open the subject to try to enderstand that. Here is the details:

In the We Were I use the now famous STE 224 bytes line in all fullscreen code. It's slighty different from the DHS one, here is my version:

Code: Select all

; "We Were @" STE 224 bytes fullscreen line

;a6=$8260
;a5=$820a
;d6=$0
move.w   a6,(a6)   ; open left border
nop
move.b   d6,(a6)
91 NOPs
move.b   d6,(a5)   ; open right border
move.w   a6,(a5)
28 NOPS


the line seems to work pretty well on all STE (even on the strange compo machine ).

Now in the MegaDistorter I'm using the pixel horizontal scroll register ( $8265 ) every line. Please not that I never use the offset "0" ( only 1 to 15 ). My line becomes:

Code: Select all

move.w   a6,(a6)   ; open left border
nop
move.b   d6,(a6)
move.b     d7,5(a6)    ; write to $8265 (horiz pixel scroll)
88 NOPs
move.b   d6,(a5)   ; open right border
move.w   a6,(a5)
28 NOPS


( d7 is updated each line, but never contains "0", only 1 to 15 )


In that case, on some STE, everything appairs like the left border was not open. Fortunatly on the compo machine, the picture was still nice because I setup the video register each line too!

Reading the Troed presentation about shifter finite state machine, I guess there is something related to the new "preload" STE stuff. But the move.b d7,5(a6), running AFTER the left border removal code, seems to cancel it.

Anyone have a guess?

[npomarede]

Hi
ff8265 is the prefetch version of the horizontal scroll, but in your case you use it while display is already ON (because left border switch was made), so maybe the prefetching confuses the mmu/shifter. Did you try using ff8264 instead (it doesn't prefetch) ?
Or maybe you could try changing ff8265 before the hi/lo switch ?
Well, I guess it's not easy to test if your own STE doesn't show the problem

Nicolas

[leonard]

yes you get the point! I don't have hardware to test. I even don't know that there was 8264 without prefetch Could you elaborate on this? Is this documented or already used in any practical code?

[leonard]

I have some important new informations: At first I though the left border was not open, but it is! by carefully looking the video of STNICCC demo competition during the megadistorter, I can see the left border is open, BUT there is 16 pixels missing. Exactly as a fullscreen picture was shifted 16 pixels to the right.

I did a try using 8264 on HATARI and it produces exactly the same picture as on the STNICCC compo machine! So on that compo machine, writing to 8265 seems to has the same effec?t as writing to 8264 on a "normal" machine.

I will try to set 8265 before the left border and try it on weird hardware.

[npomarede]

This register is not well documented, original Atari STE doc states ff8264 is a 16 bit register and only lower 4 bits are used (thus in ff8265).
I wrote some test programs some years ago to emulate this better under Hatari, this register is rarely used because the non-prefetch causes a worse looking result.

Regarding STE HW scrolling, we know the screen is shifted to the left when hscroll is increased. This is similar to a 'LSL' in 68000, pixels exit on the left, but you get "0" bits on the right. On STE, in order to get pixels "entering" on the right when the 1st pixels are skipped on the left, you need to have the 4 next-bitplanes registers already loaded (they were called RIx in Alien's doc IIRC). So, if scrolling is done using ff82685 (with a value != 0), the mmu will read 4 words 16 cycles ahead before the usual start of the display, so when display starts you can skip some pixels immediately and have some words already loaded to fill the missing pixels on the right of the shifted words.
If ff8264 is used, then prefetch is not done before display starts, but when display starts. So, during 16 cycles color 0 will be displayed (like the left border) during the time that 4 words are sent by the MMU to the shifter. This is why ff8264 is rarely used, because you will get 16 less usable pixels on each line.
(You can have a look in Hatari video.c source for a more complete description of ff8264/65).

Another effect of using ff8264 combined with ff8265 is to get a 336 pixel wide line, by starting display 16 cycles earlier, thus gaining 16 pixels (DHS used this a lot)

If by using ff8264 in your test you see the same result as reported by some people on their STE with your demo using ff8265, this could mean that some words were not completely prefetched to the shifter. A possible cause could be that you set video counter in ff8205/07/09 on each previous scanline at a point where display is still active ?
Changing video counter at the same time the mmu is reading words could have some unwanted effects (maybe partially cancelling some preloaded words ?). But that's just some guess, unfortunately Troed's presentation at STNICCC didn't mention those STE specific points, and that would be a lot of tests to do (that's sthg I plan do one day, but not at the moment)

Nicolas

[alien]

Interesting, I noticed that weirdness when I played your demo in Hatari. I thought it was an STe thing, not ever having had one.

The prefetch thing is simply that the Shifter needs to have been given 4 words early by the MMU so that should the scroll register be set to a value that results in most of the leftmost pixels being skipped, the shifter has had the time to be given the next 4 words to display. A simple implementation of the Shifter would result in a gap in the line, while it waited for the IR registers to be loaded. Instead, from what I've read, Atari designed the Shifter to require 8 words to be preloaded to the shifter if the scroll register isn't 0, before it starts displaying pixel data.

This does seem related to your issue. If the register causes the internal buffer to be cleared, setting it once per VBL, or at least when no data is being fetched would indeed help. Otherwise, it could be a silicon difference between different STes, as to when they transfer data from the IR to the RR registers.

Oh, it seems Nicolas just also responded.

[leonard]

thanks alien / nicolas for details about 8264, seems really a strange register (the fact that ATARI does not document it officially is really weird)

And yes, I setup the video register each line. To be complete, my line is:

Code: Select all

   
   movep.l   d7,-5(a5)    ; set screen ad in 8205, 8207, 8209 and dummy write in 820b ( D7=screen<<8)
   move.w   a6,(a6)       ; remove left border
   nop
   move.b   d6,(a6)
   move.b   d7,5(a6)    ; write to pixel scroll ( 8265 )


[npomarede]

Interesting, I noticed that weirdness when I played your demo in Hatari. I thought it was an STe thing, not ever having had one.

Side note regarding Hatari and the 224 byte STE overscan : the 8 leftmost pixels are shown as color 0, but on a real STE they would be black (or more exactly the color you get when blank is active during the hi/lo switch), so this is not correctly emulated yet, we should not see the raster color for color 0.
Hatari will display 416 pixels in that case (same as on STE), but I think Saint only shows 400 pixels, so those 8 leftmost pixels are not shown on the video Leonard made with Saint. On a real STE + CRT monitor, they might not be visible too depending on how wide the picture is set on the monitor.

Looking at the video from STNICC, there indeed seems to be 16 pixels with color 0 on the left, but that's not for the same reason as what we see with Hatari, this really look like a delayed start of the display.

EDIT : the 8 leftmost pixels should not be black as I stated above by mistake, they should display the content of color 0, which is already the case in Hatari.

[npomarede]

thanks alien / nicolas for details about 8264, seems really a strange register (the fact that ATARI does not document it officially is really weird)

And yes, I setup the video register each line. To be complete, my line is:

Code: Select all

   
   movep.l   d7,-5(a5)    ; set screen ad in 8205, 8207, 8209 and dummy write in 820b ( D7=screen<<8)
   move.w   a6,(a6)       ; remove left border
   nop
   move.b   d6,(a6)
   move.b   d7,5(a6)    ; write to pixel scroll ( 8265 )


With some traces under Hatari, I see movep is done at cycle 476, so this should be fine, display is already OFF at this point (it stops before cycle 460), so I don't think that's related to changing video counter.
But that could be a test to try on the non working STE : does a small program that removes left/right and just change ff8265 as in your demo still produces the same problem of delaying display ?

[npomarede]

Also, at the end of the dist, some yellow squares are drawn to fill the screen. At this point, do you still set ff8265 to a !=0 value, or is it set to 0 (because on the video we still have the same 16 pixels margin on the left) ?

[leonard]

I'm still using 8265=1 when yellow squares are filling the screen

[npomarede]

I'm still using 8265=1 when yellow squares are filling the screen

OK, so that's normal the margin is still there. I wonder if the margin would go if you set ff8265=0 at this point when you need a constant hscroll value for all the lines.

[leonard]

Ok new informations. Many thanks to Wietze for testing version I sent him on his STE (wich has the same issue as compo machine). I attached two of Wietze's shot, the first one is the We Were original with:

Code: Select all

   movep.l   d7,-5(a5)    ; set screen ad in 8205, 8207, 8209 and dummy write in 820b ( D7=screen<<8)
   move.w   a6,(a6)       ; remove left border
   nop
   move.b   d6,(a6)
   move.b   d7,5(a6)    ; write to pixel scroll ( 8265 )


leo_orig.jpg

and the second picture is with:

Code: Select all

   movep.l   d7,-5(a5)    ; set screen ad in 8205, 8207, 8209 and dummy write in 820b ( D7=screen<<8)
   move.b   d7,5(a6)    ; write to pixel scroll ( 8265 )
   move.w   a6,(a6)       ; remove left border
   nop
   move.b   d6,(a6)


the second show that left border has only 12 or 16 pixels in color 0. ( for scale, a white square is 16 pixels width)

leo.jpg

[alien]

Glad you figured it out!

[npomarede]

OK, so there's a problem on these STE when changing HSCROLL while display is ON. As it seems to be always the case, this might not be a random wakeup state as on STF, but maybe a different HW revision in these STE. Or a hi/lo 60/50 combination earlier that puts the chip in this delayed state.
PS : there was an error in my previous posting, unlike 230 byte overscan line, the 224 byte STE overscan line should display color 0 in the leftmost border, before displaying pixels really start. This is already handled in Hatari and can be seen on the above images too.

Nicolas

[troed]

@alien The STE makes the decision to start a 60Hz or 50Hz screen 16 cycles earlier than on ST - so no time to preload 8 words, but four. (And it preloads 4 cycles earlier in mono)

I don't think there are several revisions of the STE hardware. The compo machine was different from mine and Bluestar's (and Gunstick's, which I later verified on) though in respect to something I believe is a Shifter-MMU offset (one cycle). I do think it's like a wake state so on a different boot the demo could've looked ok. None of our machines had ever gotten into that mode, but the compo machine did easily.

/Troed

[leonard]

Hi Troed

You think the compo machine could work "sometimes" ? Strange thing is that it always fail on Wietze machine

[troed]

Hi Troed

You think the compo machine could work "sometimes" ? Strange thing is that it always fail on Wietze machine

To be fair, I don't know. I fixed one of the issues we found with it in Closure but other things (that I didn't manage to fix in time) could differ between reboots.

It could be interesting to ponder whether the issue affecting your code also could depend on Shfter-MMU timing being off by one cycle

/Troed

[alien]

@Troed: I think we're just not agreeing on the term preload.

16 cycles = 4 words earlier than the ST. But the ST preloads 4 before starting to display. So that makes 8 for the STe, and 4 for the ST.

By preload I just mean: loads the pixel data before starting to display it on the screen. You might mean: does something different from the ST.

[leonard]

new information: my second try (the second image above) keep 12 or 16 pixels margin ( filled with color 0 ) on STNICCC compo or Wietze machine. I asked Wietze to test the SommarHack 2010 invtro by DHS. This intro use pixel scrolling per line + fullscreen. On his machine, the intro has exactly the same trouble: there is 16 pixels (maybe 12) not used. As he does not use color change, we see only black pixels, but it's not in fullscreen.

Seems that nobody find a way to completly open left border with pixel scroll in fullscreen on these strange STE

[troed]

You might mean: does something different from the ST.

Sorry, yes, indeed.

/Troed

[Steven Seagal]

That screen worked fine on my STE.

Another demo that mixes 224 byte lines with HSCROLL is More or less zero/Spiral, could be worth checking out.

By the way, Steem displays some trash on this screen because of a little rendering bug when HSCROLL is set at the start of the line, will be fixed for next version.

[leonard]

Steven: no I mean using HSCROLL with a different value for each scanline. If you use only 8265 one time a frame, everything is working ok, even on compo machine ( We Were use a lot of HSCROLL for complete screen and it works)
8265 has really strange behavior if used several times during the frame (ie one time per line)

still have no solution to perfectly do this with fullscreen on some STE

[Steven Seagal]

There is Delirious 4/Tekila with HSCROLL on each line, but it's 230 byte overscan.
This one also works on my STE.

[Steven Seagal]

we_were_dist_big.png

This is supposed to be correct, so it's normal to have a "margin", it's the normal "colour 0" border seen on all 224 byte overscan screens.
An artefact of this trick. I see the same on my CRT monitor.