I just came across this Fast Frame Flyback Routine from AA93 Technical Forum (http://cpcoxygen.fxwebdevelopment.com/amstrad_action/AA093/jpg/scans/aa93-21.jpg), it looks familiar and might have seen it in another routine which was used to split the Border Colours into 2.
.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"? :-\
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 :)
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.
Quote from: fano on 09:18, 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. ;)
Quote from: fano on 09:18, 07 May 11
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...
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.
Quote from: redbox on 09:24, 07 May 11Is 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.
QuoteJust 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.
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
Quote from: CP/M User on 10: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.
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)
Quote from: andycadley on 11:01, 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