Author Topic: Fast Frame flyback Routine  (Read 1783 times)

0 Members and 1 Guest are viewing this topic.

Offline AMSDOS

  • Supporter
  • 6128 Plus
  • *
  • Posts: 3.893
  • Country: au
    • index.php?action=treasury
    • Programs for Turbo Pascal 3
  • Liked: 1104
  • Likes Given: 1871
Fast Frame flyback Routine
« on: 10:08, 07 May 11 »
I just came across this Fast Frame Flyback Routine from AA93 Technical Forum, it looks familiar and might have seen it in another routine which was used to split the Border Colours into 2.
 
Code: [Select]
.ff
ld b,&f5
 
.ffl
in a,(c)
rra
jr nc,ffl

Personally I'm happy with MC WAIT FLYBACK (&BD19), though AA were confident that the routine above is faster, I guess it is since the "in" instruction is kind of like "out"!  :-[  I just wondered if there maybe any disadvantages compared to "MC WAIT FLYBACK"?  :-\
* Using the old Amstrad Languages :D   * with the Firmware :P
* I also like to problem solve code in BASIC :)   * And type-in Type-Ins! :D

Home Computing Weekly Programs
Popular Computing Weekly Programs
Your Computer Programs
Updated Other Program Links on Profile Page (Update April 16/15 phew!)
Programs for Turbo Pascal 3

Offline redbox

  • Supporter
  • 6128 Plus
  • *
  • Posts: 1.751
  • Country: gb
    • redbox
  • Liked: 326
  • Likes Given: 267
Re: Fast Frame flyback Routine
« Reply #1 on: 11:09, 07 May 11 »
Yes, this is the fastest routine.

Only disadvantage I can think of is that it's larger than using the firmware - CALLing &BD19 only takes 3 bytes  :)

Offline fano

  • Supporter
  • 6128 Plus
  • *
  • Posts: 835
  • Country: fr
  • Easter Egg Programmer
    • Easter Egg
  • Liked: 278
  • Likes Given: 612
Re: Fast Frame flyback Routine
« Reply #2 on: 11:18, 07 May 11 »
Another one is you need the firmware to use #BD19  :P
Just a little trick about sprite rendering , instead of waiting frame flyback , you can wait the 6th interrupt before start drawing because the electron beam will be in the border so you'll have no risk of flickering during the border.You'll start to draw earlier so you will reduce the flickering.
« Last Edit: 11:23, 07 May 11 by fano »
"NOP" is the perfect program : short , fast and (known) bug free

Follow Easter Egg products on Facebook !

Offline redbox

  • Supporter
  • 6128 Plus
  • *
  • Posts: 1.751
  • Country: gb
    • redbox
  • Liked: 326
  • Likes Given: 267
Re: Fast Frame flyback Routine
« Reply #3 on: 11:24, 07 May 11 »
Another one is you need the firmware to use it  :P

Yes, but CP/M user asked for "disadvantages compared to MC WAIT FLYBACK" - size was the only possible one I could think of.  ;)

Just a little trick about sprite rendering , instead of waiting frame flyback , you can wait the 6th interrupt instead before start drawing because the electron beam will be in the border so you'll have no risk of flickering during the border.You'll start to draw earlier so you will reduce the flickering.

Is the 6th interrupt at the bottom of the screen draw?  If so, you need some fast sprite routines...

Offline fano

  • Supporter
  • 6128 Plus
  • *
  • Posts: 835
  • Country: fr
  • Easter Egg Programmer
    • Easter Egg
  • Liked: 278
  • Likes Given: 612
Re: Fast Frame flyback Routine
« Reply #4 on: 11:41, 07 May 11 »
Sorry , i'm always in the same no system point of view  ;)
I'll add if you app is time critical , #BD19 jumps into ROM via RST#8 so it is slow.

Is the 6th interrupt at the bottom of the screen draw?  If so, you need some fast sprite routines...
Yes , but it is a gain of 52 lines at least.Depending sprite amount needed but you can refresh and draw 8 16*16 (mode 1) masked sprites easily (more with further optimisations).If you need more time to display , you can start after the electrom beam instead before but you need to sort sprites on Y.
"NOP" is the perfect program : short , fast and (known) bug free

Follow Easter Egg products on Facebook !

Offline Optimus

  • 464 Plus
  • *****
  • Posts: 352
  • Country: gr
  • Liked: 169
  • Likes Given: 141
Re: Fast Frame flyback Routine
« Reply #5 on: 11:54, 07 May 11 »
Quote
Just a little trick about sprite rendering , instead of waiting frame flyback , you can wait the 6th interrupt instead before start drawing because the electron beam will be in the border so you'll have no risk of flickering during the border.You'll start to draw earlier so you will reduce the flickering.

That's a nice trick I haven't thought before. I am always used double buffering these days so I don't need it. But maybe in an overscan setup where two buffers are too much, it could be a nice alternative, depending on what you want to do.

Offline AMSDOS

  • Supporter
  • 6128 Plus
  • *
  • Posts: 3.893
  • Country: au
    • index.php?action=treasury
    • Programs for Turbo Pascal 3
  • Liked: 1104
  • Likes Given: 1871
Re: Fast Frame flyback Routine
« Reply #6 on: 12:00, 07 May 11 »
Sorry I wasn't clear in my inital post, because I'm working on things for CP/M I wasn't sure if this would work from there or not. For instance should the state of the Upper or Lower ROMs needs to be changed, that will present an issue. AA haven't stated that the State of the ROMs needs to be selected, though cause their working through BASIC/AMSDOS that routine may by default be legitimate. Only way I'll know is to try it out in CP/M perhaps (with something moving along the screen). With MC WAIT FLYBACK I usually find I have to call it more than one (2 or 3 times) to produce a smooth effect, though I've got no problems with it and works just fine for myself!  ;D
* Using the old Amstrad Languages :D   * with the Firmware :P
* I also like to problem solve code in BASIC :)   * And type-in Type-Ins! :D

Home Computing Weekly Programs
Popular Computing Weekly Programs
Your Computer Programs
Updated Other Program Links on Profile Page (Update April 16/15 phew!)
Programs for Turbo Pascal 3

Offline andycadley

  • Supporter
  • 6128 Plus
  • *
  • Posts: 908
  • Liked: 442
  • Likes Given: 73
Re: Fast Frame flyback Routine
« Reply #7 on: 13:01, 07 May 11 »
Sorry I wasn't clear in my inital post, because I'm working on things for CP/M I wasn't sure if this would work from there or not. For instance should the state of the Upper or Lower ROMs needs to be changed, that will present an issue.
The code queries the hardware directly, things like ROM state won't matter at all and it will work just as well in CP/M as it does in AMSDOS (or indeed with no OS at all)

Offline AMSDOS

  • Supporter
  • 6128 Plus
  • *
  • Posts: 3.893
  • Country: au
    • index.php?action=treasury
    • Programs for Turbo Pascal 3
  • Liked: 1104
  • Likes Given: 1871
Re: Fast Frame flyback Routine
« Reply #8 on: 15:18, 07 May 11 »
The code queries the hardware directly, things like ROM state won't matter at all and it will work just as well in CP/M as it does in AMSDOS (or indeed with no OS at all)

Yes unfortunately I seem to forget that doing everything directly to the hardware kind of bypasses whatever state the machine is in!  :o
* Using the old Amstrad Languages :D   * with the Firmware :P
* I also like to problem solve code in BASIC :)   * And type-in Type-Ins! :D

Home Computing Weekly Programs
Popular Computing Weekly Programs
Your Computer Programs
Updated Other Program Links on Profile Page (Update April 16/15 phew!)
Programs for Turbo Pascal 3