STE - shifted bitplanes - urgent

All 680x0 related coding posts in this section please.

Moderators: exxos, simonsunnyboy, Mug UK, Zorro 2, Moderator Team

User avatar
Cyprian
Atari God
Atari God
Posts: 1398
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

STE - shifted bitplanes - urgent

Postby Cyprian » Tue Nov 08, 2016 11:14 pm

its urgent due to upcoming event in Poland

There is a screen with opened bottom border on Timer B. Occasionally the Shifter shows shifted bitplanes. I guess it's caused by delayed Timer B by other MFP Timer and BLiTTER activity. We have no time to track it before an event and we're looking for temporary workaround, something like the Shifter reset or stabilizer on every VBL.
Do you have any ideas?

Thanks!
Jaugar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
SDrive / PAK68/3 / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Aranym / Steem / Saint
http://260ste.appspot.com/

wietze
Captain Atari
Captain Atari
Posts: 185
Joined: Fri Mar 01, 2013 10:52 pm

Re: STE - shifted bitplanes - urgent

Postby wietze » Wed Nov 09, 2016 6:56 am

Is it ocxaisionally during the same run. Or occaisionally over different executions?

If over different executions, doing an additional 50/60 switch at demo init time may fix it.

User avatar
chlu600
Retro freak
Retro freak
Posts: 11
Joined: Wed Mar 04, 2015 8:32 am

Re: STE - shifted bitplanes - urgent

Postby chlu600 » Wed Nov 09, 2016 7:13 am

Is it possible to move the blitter parts earlier in the vbl? Try that.
Even if you have a additional stabilizer on every vbl you will drop the border that particular frame. But it's better than constantly shifted bitplanes.

BlankVector
Captain Atari
Captain Atari
Posts: 394
Joined: Wed Oct 24, 2007 7:52 pm
Location: France
Contact:

Re: STE - shifted bitplanes - urgent

Postby BlankVector » Wed Nov 09, 2016 1:01 pm

While working on EmuTOS resolution change routines, I noticed that the plane shift bug occurred sometimes. I inserted a Vsync() before changing the resolution, and it definitely fixed the problem. My conclusion was that, for reliability, the resolution must not be changed when the beam is drawing something.

However, I don't know how this applies when the lower border is opened.
I would suggest to try the following as workaround:
- wait for the VBL
- switch to medium resolution
- switch to low resolution

User avatar
dml
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 3468
Joined: Sat Jun 30, 2012 9:33 am

Re: STE - shifted bitplanes - urgent

Postby dml » Wed Nov 09, 2016 1:12 pm

What I normally do here is schedule the timer B a couple of lines in advance, pause the blitter (which takes a varying amount of time, but less than the padding time you're providing) and monitor the timerb data until it decays to the correct line. You can then sync properly. Sounds like you're saying there's no time for that padding?

And this still doesn't work with HOG blits - unless they are super short and/or timed. There's no solution to that one except to move the blits away from the timecritical region.

A left/right border style toggle might clean up the mess after the fact but I doubt you can do it with less than 1 dead line. It's already too late. Maybe someone else has tried it.

AtariZoll
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2759
Joined: Mon Feb 20, 2012 4:42 pm
Contact:

Re: STE - shifted bitplanes - urgent

Postby AtariZoll » Wed Nov 09, 2016 2:46 pm

I used practically same what dml suggesting - activating Timer-B 1 line earlier, but it may be more if there is some very long uninterruptable blitter activity. Then perform only NOPs for 1 or more lines, what assures short Timer-B response-at desired line, with always same delay. May need to disable other interrupts during those lines. That will of course insert some inactive CPU time, what is not much, normally under 1% .
Extra accurate synchronization is possible by trick used in hi-color displaying,
English language is like bad boss on workplace: it expecting from you to strictly follow all, numerous rules, but self bending rules as much likes :mrgreen:

User avatar
npomarede
Atari God
Atari God
Posts: 1129
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: STE - shifted bitplanes - urgent

Postby npomarede » Wed Nov 09, 2016 2:51 pm

Cyprian wrote:its urgent due to upcoming event in Poland

There is a screen with opened bottom border on Timer B. Occasionally the Shifter shows shifted bitplanes. I guess it's caused by delayed Timer B by other MFP Timer and BLiTTER activity. We have no time to track it before an event and we're looking for temporary workaround, something like the Shifter reset or stabilizer on every VBL.
Do you have any ideas?

Thanks!

Are you just opening bottom border, or also changing STE video address at the same time in the bottom border ?
If the latter, it's *very* important to change video address while the shifter displays color 0 in the border (ie DE signal is OFF), else changing video address at the same time as shifter is reading data will cause this kind of shifted planes.

Nicolas

User avatar
Zorro 2
Administrator
Administrator
Posts: 2190
Joined: Tue May 21, 2002 12:44 pm
Location: Saint Cloud (France)
Contact:

Re: STE - shifted bitplanes - urgent

Postby Zorro 2 » Wed Nov 09, 2016 6:29 pm

Hi Cyprian,

I can see the Issue tonight if you provide me ASM source code by PM ?

Regards.
Member of NoExtra Team

User avatar
Cyprian
Atari God
Atari God
Posts: 1398
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Re: STE - shifted bitplanes - urgent

Postby Cyprian » Mon Nov 14, 2016 2:09 pm

Hello All,

Many thanks for your suggestions!

Lower border is opened by timer B which is scheduled a couple lines in advance (as DML mentioned) in order to avoid BLiTTER's disturbance.

As Nicolas suggested, it appeared changing STE video address was from time to time a few cycles toolate (it overlapped with the left border edge). The code was moved dozen cycles earlier and voila - no more bitplanes shifts.

There you can check the result: https://demozoo.org/productions/165194/ (another Wachu's demo from 1996 https://demozoo.org/productions/71887/) Most effects are in 1 VBL and contain a tons of small blits.
Jaugar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
SDrive / PAK68/3 / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Aranym / Steem / Saint
http://260ste.appspot.com/

nanard
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 107
Joined: Mon Apr 04, 2016 2:11 pm

Re: STE - shifted bitplanes - urgent

Postby nanard » Wed Dec 21, 2016 2:24 pm

I have the same problem of shifted bitplanes with my slideshow http://www.pouet.net/prod.php?which=68597
Timer B is used to open bottom border
here is the code : https://github.com/miniupnp/AtariST/blo ... 80s.s#L844
If someone can spot the problem...
4MB STE + CosmosEx /|\ MegaST4 + MegaFile 44

User avatar
troed
Atari God
Atari God
Posts: 1181
Joined: Mon Apr 30, 2012 6:20 pm
Location: Sweden

Re: STE - shifted bitplanes - urgent

Postby troed » Wed Dec 21, 2016 3:18 pm

nanard wrote:I have the same problem of shifted bitplanes with my slideshow http://www.pouet.net/prod.php?which=68597
Timer B is used to open bottom border
here is the code : https://github.com/miniupnp/AtariST/blo ... 80s.s#L844
If someone can spot the problem...


IMHO the best solution is to sync lock and make a cycle perfect switch. You'll get shifted bitplanes if you happen to do a 60Hz early line end (60Hz at cycle 372) for example.

User avatar
Zorro 2
Administrator
Administrator
Posts: 2190
Joined: Tue May 21, 2002 12:44 pm
Location: Saint Cloud (France)
Contact:

Re: STE - shifted bitplanes - urgent

Postby Zorro 2 » Thu Dec 22, 2016 1:26 pm

Hi Nanar,

Two Hbl for the bottom border, hum... your assembly source is not compliant with DevPac, I need to translate some directives and locale variable...

I advice you to see this thread http://www.atari-forum.com/viewtopic.php?f=68&t=9511 to understand how to manage different palettes with the Timer B and the bottom border overscan.
Member of NoExtra Team

nanard
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 107
Joined: Mon Apr 04, 2016 2:11 pm

Re: STE - shifted bitplanes - urgent

Postby nanard » Mon Dec 26, 2016 7:45 pm

Zorro 2 wrote:Hi Nanar,

Two Hbl for the bottom border, hum... your assembly source is not compliant with DevPac, I need to translate some directives and locale variable...

Hi,
I can try to make my code DevPac compliant (as long as it still assemble with VASM as well). Please tell we what DevPac doesn't like

here is the code I inspired from at first : http://www.ntrautanen.fi/marko/suomen.atari.org/stklubi/stklubi/91/91_02/pd/assy/border.s

Zorro 2 wrote:I advice you to see this thread http://www.atari-forum.com/viewtopic.php?f=68&t=9511 to understand how to manage different palettes with the Timer B and the bottom border overscan.

I tried to match the code from this topic, but it is not better

Code: Select all

HBL:                     * 200
                           sf   $fffffa21.w   * Stop Timer B
                           sf   $fffffa1b.w
                       
                           REPT   95   * Wait line end
                           nop
                           ENDR   
                           
                           sf   $ffff820a.w   * Modif Frequency 60 Hz !
                       
                           REPT   28   * Wait a little
                           nop
                           ENDR
                       
                           move.b   #$2,$ffff820a.w * 50 Hz !

how to be sure the timing of 95 nop's and 28 nop's are ok ?
4MB STE + CosmosEx /|\ MegaST4 + MegaFile 44

FedePede04
Atari Super Hero
Atari Super Hero
Posts: 935
Joined: Fri Feb 04, 2011 12:14 am
Location: Denmark
Contact:

Re: STE - shifted bitplanes - urgent

Postby FedePede04 » Mon Dec 26, 2016 8:41 pm

That was a great Demo, it had a nice flow.
Thx for sharing :)

Cyprian wrote:Hello All,

Many thanks for your suggestions!

Lower border is opened by timer B which is scheduled a couple lines in advance (as DML mentioned) in order to avoid BLiTTER's disturbance.

As Nicolas suggested, it appeared changing STE video address was from time to time a few cycles toolate (it overlapped with the left border edge). The code was moved dozen cycles earlier and voila - no more bitplanes shifts.

There you can check the result: https://demozoo.org/productions/165194/ (another Wachu's demo from 1996 https://demozoo.org/productions/71887/) Most effects are in 1 VBL and contain a tons of small blits.
Atari will rule the world, long after man has disappeared

sometime my English is a little weird, Google translate is my best friend :)

User avatar
troed
Atari God
Atari God
Posts: 1181
Joined: Mon Apr 30, 2012 6:20 pm
Location: Sweden

Re: STE - shifted bitplanes - urgent

Postby troed » Mon Dec 26, 2016 8:58 pm

nanard wrote:how to be sure the timing of 95 nop's and 28 nop's are ok ?


By sync locking, as I wrote. The jitter from the timer you use can surely cause your code to go to 60Hz at cycle 372 and thus create an early line end (1 word less) which will create shifted bitplanes.

Code: Select all

   moveq #0,d0
.sync   move.b $ffff8209.w,d0
   cmp.b $ffff8209.w,d0
   beq.s .sync
   move.b $ffff8209.w,d0
   not.w d0
   lsr.w d0,d0


The code above will cancel out any jitter and any following background color changes (or frequency register changes) will be pixel perfect.

/Troed

User avatar
Cyprian
Atari God
Atari God
Posts: 1398
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Re: STE - shifted bitplanes - urgent

Postby Cyprian » Mon Dec 26, 2016 10:34 pm

FedePede04 wrote:That was a great Demo, it had a nice flow.
Thx for sharing :)

You're welcome Peter
Jaugar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
SDrive / PAK68/3 / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Aranym / Steem / Saint
http://260ste.appspot.com/


Social Media

     

Return to “680x0”

Who is online

Users browsing this forum: No registered users and 3 guests