unsynchronous fullscreen-routine

All 680x0 related coding posts in this section please.

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

BTK
Atarian
Atarian
Posts: 2
Joined: Tue Nov 30, 2004 10:04 am

unsynchronous fullscreen-routine

Postby BTK » Mon Jan 10, 2005 2:59 pm

Hello,

With the tutorials available, I learned how to do a synchronous fullscreen (the one with lots of nops that can be filled with more useful code).

In http://codercorner.com/fullscrn.txt however, Flix mentions a new, unsynchronous method (look in the last two or three paragraphs). Does anybody know, how it works? (or isn't it possible at all and that part of the text is a hoax?)

Thanks in advance,
BTK

Here is, what Flix wrote in http://codercorner.com/fullscrn.txt :

A few days after the ICC #2 I developed a new fullscreen-
routine. With this routine the main program does not have to be
synchronous with the electron-ray. The disadvantage of this
method is that the border annihilation takes up to 50 per cent
of the processor time. Therefore you can use keyboard-requests,
multiplications, divisions and interrupts. The routine is,
allthough it's awfully old, top secret and cannot be published
in Maggie (yet).

User avatar
ggn
Atari God
Atari God
Posts: 1258
Joined: Sat Dec 28, 2002 4:49 pm

Postby ggn » Mon Jan 10, 2005 3:35 pm

I remember reading somewhere that the trick is done like this: first you bust the left border using normal synchro code, and then you set a timer a (or b?) interrupt to bust the right border. That gives you freedom to use non-synchro code in the time left. Or something like that (it's all from memory here).

Of course, I also read that setting timers each scanile costs a lot of cpu, so you're left with something like 50% left (which of course is gigantic compared with a normal fullscreen)

Just my 2 cents,

George
is 73 Falcon patched atari games enough ? ^^

User avatar
ggn
Atari God
Atari God
Posts: 1258
Joined: Sat Dec 28, 2002 4:49 pm

Postby ggn » Mon Jan 10, 2005 3:37 pm

I remember reading somewhere that the trick is done like this: first you bust the left border using normal synchro code, and then you set a timer a (or b?) interrupt to bust the right border. That gives you freedom to use non-synchro code in the time left. Or something like that (it's all from memory here).

Of course, I also read that setting timers each scanile costs a lot of cpu, so you're left with something like 50% left (which of course is gigantic compared with a normal fullscreen)

Just my 2 cents,

George
is 73 Falcon patched atari games enough ? ^^

User avatar
Nyh
Atari God
Atari God
Posts: 1496
Joined: Tue Oct 12, 2004 2:25 pm
Location: Netherlands

Postby Nyh » Mon Jan 10, 2005 11:25 pm

ggn wrote:Of course, I also read that setting timers each scanile costs a lot of cpu, so you're left with something like 50% left (which of course is gigantic compared with a normal fullscreen)


The timers don't eat the CPU. The problem is at each interrupt you have to re-sync with the screen to open the right border. Because interrupts can't interrupt a running instruction the interrupt has to wait for an instruction to finish up to 158 cycles for a DIVS or a nice 148 cycles for a nice and big MOVEM.L.

But let us suppose you will write code that is nice for your border routines, using only instructions with less as 36 cycles (MOVE.L src,dst), so no MUL's end DIV's, and only friendly shifts and MOVEM.L's. then:
36: instruction to finish
44: interrupt
32: sync
152: border magic (and reset timers)
20: RTE
___+
284 cycles every scnaline to open borders by interrupts. As you know a scnline is 512 cycles long so les than 50% during scanlines (during VBL you got almost all processortime). Maybe add some extra cycles to save and restore registers... But I would do code not touching the important registers.

If you want to accomodate for all code you will have about 40 cycles free every scanline...

Nyh

RA_pdx
Captain Atari
Captain Atari
Posts: 215
Joined: Sun Feb 02, 2003 12:01 pm
Location: Nuernberg/GERMANY

Postby RA_pdx » Tue Jan 11, 2005 10:32 pm

@Nyh: Do you know how it´s possible to sync in every line?

I know only the following sync routine:

Code: Select all

.sync      move.b   $ffff8209.w,d0
      beq.s   .sync
      not.b   d0
      lsl.b   d0,d0


... and of course this doesn´t work in every line.

User avatar
Nyh
Atari God
Atari God
Posts: 1496
Joined: Tue Oct 12, 2004 2:25 pm
Location: Netherlands

Postby Nyh » Wed Jan 12, 2005 10:15 am

RalfZenker wrote:@Nyh: Do you know how it´s possible to sync in every line?

I know only the following sync routine:
<SNIP>
... and of course this doesn´t work in every line.


Why would it not?
There is no need to check the zero on $ffff8209.w because you know you are in the middle of a line so $ffff8209.w is counting for sure.
The value of $ffff8209.w at the end of the line will vary but as long as you interrupt latency is less as 64 clockcycles you are only interested in the 5 lsb of $ffff8209.w.
So:

Code: Select all

move.b  $ffff8209.w,d0
not.b  d0
and.b $1f,d0
lsr.w d0,d0

will sync you.

Nyh

User avatar
leonard
Moderator
Moderator
Posts: 658
Joined: Thu May 23, 2002 10:48 pm
Contact:

Postby leonard » Wed Feb 09, 2005 12:04 am

That technic was invented and implemented by Ziggy Stardust / OVR. You can see its routine in its brainblasting filled vector fullscreen in the OVR screen of the Froggie's demo. Since a very little time, you can see Froggie's demo on your PC using SainT 1.99b.

The time consumed is very high, so there is a very few CPU cycle left. A classic fullscreen line has 3 hardware flip/flip change. Between these changes , you have 89, 13 and 12 free nops. Of course the 13 and 12 nops can't be used by timer (too short). so timer is run one time per line, during the 89nops sequence. but you have to stop at the middle of the line, to sync again.

Ziggy's rout is really well written, and he finds a great tricks to do MULS instructions. Before each MUL, he does a "STOP3 instruction, wich wait automatically the timer. Of course it slow down a bit the whole routine, but he's sure that the MUL never interleave with timer ! Very good trick !
Leonard/OXYGENE.

Gunstick
Captain Atari
Captain Atari
Posts: 263
Joined: Thu Jun 20, 2002 6:49 pm
Location: Luxembourg
Contact:

Postby Gunstick » Wed Feb 09, 2005 8:53 am

I wrote an async routine which does not use the timer :-)

It's a subroutine you have to call regularly in your code. So write your normal code, then spread throughout the code a lot of "bsr overscan" and you have a fullscreen. Put that in front of MULS and DIVS.
That way you gain the interrupt handling time.

That way I get about 64 NOPs free per scanline.
I never used that code in a demo...

andi.w #$ff,d1
sub.b $ffff8209.w,d1 ; sync
neg.b d1
jmp 0(pc,d1.w)
ds.w 93,$4e71

Georges

User avatar
unseenmenace
Atari God
Atari God
Posts: 1961
Joined: Tue Sep 21, 2004 9:33 pm
Location: Margate, Kent, UK
Contact:

Postby unseenmenace » Wed Feb 09, 2005 8:57 am

I've never thought of using the STOP instruction that way. That might be a better way of synching my top border interrupt. At the moment I just have a huge bunch of NOP's in my VBL routine so that when the timer kicks in it will be accurate to within 4 cycles. Will execution continue as soon as an interrupt triggers in the MFP even if it is masked by the MFP or (as I would assume) only if the interrupt would actually happen? I ask this because MFP interrupts are allowed by the SR but I temporarily mask Timers A, C & D to prevent digidrum or SIDvoice interrupts delaying my top border interrupt which uses Timer B.
UNSEEN MENACE
Several STFM's, 4MB STE, 2MB TT with 1.2GB Hard Drive and 14MB Falcon with 540MB Hard Drive,
Lynx 2 and Jaguar with JagCD
Member of GamebaseST and AtariLegend team
Check out my website at http://unseenmenace.110mb.com

User avatar
leonard
Moderator
Moderator
Posts: 658
Joined: Thu May 23, 2002 10:48 pm
Contact:

Postby leonard » Wed Feb 09, 2005 1:19 pm

It's a subroutine you have to call regularly in your code


I see the idea. But, what are xactly the contrainst ( I mean, is there a minimal number of nop between two calls ?
And last but not least, your technic is of course faster (no interrupt), but is it compatible with a filled vector 3d routine ?

Will execution continue as soon as an interrupt triggers in the MFP even if it is masked by the MFP or (as I would assume) only if the interrupt would actually happen?


Only when the interrupt will actually happen.
Leonard/OXYGENE.

Gunstick
Captain Atari
Captain Atari
Posts: 263
Joined: Thu Jun 20, 2002 6:49 pm
Location: Luxembourg
Contact:

Postby Gunstick » Wed Feb 09, 2005 6:42 pm

leonard wrote:
It's a subroutine you have to call regularly in your code


I see the idea. But, what are xactly the contrainst ( I mean, is there a minimal number of nop between two calls ?
And last but not least, your technic is of course faster (no interrupt), but is it compatible with a filled vector 3d routine ?


I have 2 routines, one is a bit faster (67 instead of 64 nops free) but the faster one only allows for a variance of 24 nops, the slower routine can be called anytime.
So for a 3d routine, it's just a matter of calling it often enough. And that's a bit difficult if you have loops which are sometimes shorter or longer.
Using code stacks for those will simplify, as then you can make an overscan call every 2 or 3 loops.

Send me a filled poligon routine and I'll put it into overscan :-)

George

User avatar
tobe
Atari God
Atari God
Posts: 1459
Joined: Sat Jan 24, 2004 10:06 am
Location: Lyon, France
Contact:

Postby tobe » Thu Feb 10, 2005 12:35 pm

Yes, yes, yes, please, do this 8O !
step 1: introduce bug, step 2: fix bug, step 3: goto step 1.

User avatar
leonard
Moderator
Moderator
Posts: 658
Joined: Thu May 23, 2002 10:48 pm
Contact:

Postby leonard » Thu Feb 10, 2005 2:23 pm

Send me a filled poligon routine and I'll put it into overscan


:-)

You can try with your wireframe routine from DSOTS. Wireframe is already hard to put in fullscreen ( complete fullscreen). Should be amazing.

BTW I though about your technic, and I'm not 100% sure this is faster than interrupt method. Of course this is faster "theorically", but in practice you have:

a) it's hard to call your routine in a efficient way. I mean, in practice you will call it 2 times much than needed if you want to be sure. ( esp for a filled vector routine)
b) the call/return time

What do you think about ?
Leonard/OXYGENE.

uko
Atarian
Atarian
Posts: 6
Joined: Sun Aug 25, 2019 6:45 pm
Location: France

Re: unsynchronous fullscreen-routine

Postby uko » Sun Oct 13, 2019 8:28 pm

Hi !

I'm posting to this very old thread now, because it has been very useful to me during the past weeks, and I wanted to add some performance figures since there are only estimations of remaining CPU time here.

I have just done my first classical fullscreen routine (STE specific) these days (yes, it's never too late ! :cheers: ) and I have continued this hard work by doing a timer A based unsynchronous routine (launched after opening the left border).

It not yet fully optimised (and I am not sure I will continue it ! ;-)), and only tested with Hatari, but I currently have nearly 59000 cycles left (considering VBL and time between left and right border for each scanline).
Not a suprise, it is almost half of what a static fullscreen routine would allow by filling the nops of the middle of the scanline and using VBL.

Uko

Gunstick
Captain Atari
Captain Atari
Posts: 263
Joined: Thu Jun 20, 2002 6:49 pm
Location: Luxembourg
Contact:

Re: unsynchronous fullscreen-routine

Postby Gunstick » Wed Oct 16, 2019 9:43 pm

Programming fullscreens on hatari usually ends with not working on real hardware. You get flicker issues, plane shifting, and if you use keyboard and dma, you get delays. So expect a little fixing-phase on the real hardware.

User avatar
thomas3
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 130
Joined: Tue Apr 11, 2017 8:57 pm
Location: the people's republic of south yorkshire, uk.

Re: unsynchronous fullscreen-routine

Postby thomas3 » Wed Oct 16, 2019 10:48 pm

@uko

Nice. What kind of effect are you planning to use this for?

uko
Atarian
Atarian
Posts: 6
Joined: Sun Aug 25, 2019 6:45 pm
Location: France

Re: unsynchronous fullscreen-routine

Postby uko » Thu Oct 17, 2019 9:38 pm

Gunstick wrote:Programming fullscreens on hatari usually ends with not working on real hardware. You get flicker issues, plane shifting, and if you use keyboard and dma, you get delays. So expect a little fixing-phase on the real hardware.

Thanks for the advice !
Do you know if some emulators are more accurate than others in this way (i.e. the code that works on emulator has more chance to work on real hardware) ?
Anyway if I pursue my developments and code a full demo, I'll need some help from people having an STE ! But it will be with a classical synchronous fullscreen.

uko
Atarian
Atarian
Posts: 6
Joined: Sun Aug 25, 2019 6:45 pm
Location: France

Re: unsynchronous fullscreen-routine

Postby uko » Thu Oct 17, 2019 9:47 pm

thomas3 wrote:@uko

Nice. What kind of effect are you planning to use this for?

I am starting an oldskool 50Hz demo. I don't think I'll use this unsynchronous routine for my codings. There is not enough CPU time left, and since I won't do some kind of 3D demo with variable frame rate, it might be simpler to "replace" the NOPs of a synchronous routine.
The objective of coding this unsynchronous routine was more to see if I was able to code it than to make a real usage of it. It has been a great exercice ! :D

User avatar
thomas3
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 130
Joined: Tue Apr 11, 2017 8:57 pm
Location: the people's republic of south yorkshire, uk.

Re: unsynchronous fullscreen-routine

Postby thomas3 » Thu Oct 17, 2019 11:02 pm

uko wrote:
Gunstick wrote:Programming fullscreens on hatari usually ends with not working on real hardware. You get flicker issues, plane shifting, and if you use keyboard and dma, you get delays. So expect a little fixing-phase on the real hardware.

Thanks for the advice !
Do you know if some emulators are more accurate than others in this way (i.e. the code that works on emulator has more chance to work on real hardware) ?
Anyway if I pursue my developments and code a full demo, I'll need some help from people having an STE ! But it will be with a classical synchronous fullscreen.


My recommendation, as someone also doing this stuff at the moment, is not to worry so much about the emulator but instead make sure you use a tried and tested shell for your fullscreen code. This might mean you lose some cycles here and there, but better to play it safe in my opinion. (one caveat - I'm developing for stf, not ste).

I use the switches and timer A from evl's DHS demosystem. It's "old fashioned" but rock solid so far on all original hardware it has been tested on. Besides, imo the magic resides in the concepts and illusions you're using, rather than the fullscreen tech ;) - especially if you're leaning more towards old school effects.

User avatar
Cyprian
10 GOTO 10
10 GOTO 10
Posts: 1733
Joined: Fri Oct 04, 2002 11:23 am
Location: Warsaw, Poland

Re: unsynchronous fullscreen-routine

Postby Cyprian » Fri Oct 18, 2019 7:45 am

uko wrote:Do you know if some emulators are more accurate than others in this way (i.e. the code that works on emulator has more chance to work on real hardware) ?


Steem and Hatari are actively developed and have high level of accuracy:
https://sourceforge.net/projects/steemsse/files/
https://hatari.tuxfamily.org/download.html
Lynx II / Jaugar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
Hatari / Steem SSE / Aranym / Saint
http://260ste.appspot.com/

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1984
Joined: Sun Jul 31, 2011 1:11 pm

Re: unsynchronous fullscreen-routine

Postby Eero Tamminen » Fri Oct 18, 2019 11:17 pm

AFAIK main Steem & Hatari differences are:
* Steem is more for Windows, Hatari for Linux
* Steem has GUI debugger, Hatari only CLI one, but it can do profiling with callgraphs: https://hatari.tuxfamily.org/doc/manual.html#Profiling
* Steems is ST/STE only, Hatari emulates also TT & Falcon

uko
Atarian
Atarian
Posts: 6
Joined: Sun Aug 25, 2019 6:45 pm
Location: France

Re: unsynchronous fullscreen-routine

Postby uko » Mon Oct 21, 2019 8:54 pm

thomas3 wrote:My recommendation, as someone also doing this stuff at the moment, is not to worry so much about the emulator but instead make sure you use a tried and tested shell for your fullscreen code. This might mean you lose some cycles here and there, but better to play it safe in my opinion. (one caveat - I'm developing for stf, not ste).

I use the switches and timer A from evl's DHS demosystem. It's "old fashioned" but rock solid so far on all original hardware it has been tested on. Besides, imo the magic resides in the concepts and illusions you're using, rather than the fullscreen tech ;) - especially if you're leaning more towards old school effects.


You're right, moreover I must also keep time for coding the demo itself ;-)

uko
Atarian
Atarian
Posts: 6
Joined: Sun Aug 25, 2019 6:45 pm
Location: France

Re: unsynchronous fullscreen-routine

Postby uko » Mon Oct 21, 2019 8:57 pm

Cyprian wrote:
uko wrote:Do you know if some emulators are more accurate than others in this way (i.e. the code that works on emulator has more chance to work on real hardware) ?


Steem and Hatari are actively developed and have high level of accuracy:
https://sourceforge.net/projects/steemsse/files/
https://hatari.tuxfamily.org/download.html


Thanks, these are the two ones I'm using now to test my codings.


Social Media

     

Return to “680x0”

Who is online

Users browsing this forum: No registered users and 5 guests