Pues bien sencillo: no copies directamente a VRAM las posiciones de los sprites, sino simplemente a RAM. Reprocesa en RAM con alguna rutina "inteligente" y copia a VRAM entonces.

Lo mejor es sencillamente "darle la vuelta". Es decir, copiar a VRAM en los frames pares 1-2-3-4-5-... y en los frames impares 32-31-30-29-... Por supuesto esta técnica sólo funciona correctamente en ciertas condiciones. Lo más adecuado es comparar las coordenadas verticales y para los coincidentes, alternar sus posiciones relativas en la tabla de atributos de sprites.

Creo que no me he explicado nada bien 

Thanks for sharing this routine! . Could be very handy to implement working behind a BASIC program (just an idea).

Only a question, the routine seems a bit C oriented (globals, labels and so...). What's the format of the jump labels?, they are neither standard labels nor offsets...

Yep!, that's the info!. Now I see... .
Btw, I'm experimenting a bit with the demo version of Hitech 7.50 for windows and I agree, it's a very nice compiler!

In v7.8 you get all the sources of the libs and of the runtime code...
I have found also a way to get megarom on ascii 8K rom mappers   
The compiler can handle by itself up to 1M Rom of code and data and all you need
is to specify which functions and data should go in the same rom page!!
Actually, the ASCII mapper isn't very far from what the C compiler expected to have
when you compile in large model (all you need is to change a line in the lcall and lret routines).


I think that it is a great compier, even if to use it I have to move the date
of my PC to 2005 

Note that my solution is different from Robsy's one.

In my case you are always sure that the 5th sprite will be displayed (well at least one 5th sprite will be dispayed).
In Robsy's solution, this isn't guaranteed, moreover look at this effect

assume you have sprites on planes

1  2 3 4 5

on the same line: the sprite on plane 5 disappears.

reverse them

5 4 3 2 1

now sprite that was on plane 1 disappears.

Repeat this process at refresh rate:
Result: only sprite 1 & sprite 5 flicker at half of the refresh rate (25Hz if you go @50Hz)
Robsy's solution implies a very noticeable effect.

with my proposal sprites on planes

1 2 3 4 5

disappear in turn, at each frame one different sprite disappear

Result: all sprites flicker but the flickering is at 1/5 of the refresh rate (10 Hz if you go @50Hz)
This implies a much better visual effect as the flickering is at very low frequency

Hi robsy,
I see you point, but I am not sure that the case you posed isn't handled by my approach

let's see
assume 8 sprites on 8 adjacent planes

1 2 3 4 5 6 7 8

sprites 5 6 7 8 disappear, S0 returns plane 5, so next int, my routine reorders
the sprites putting sprite 5 and the following on top

you get :
5 6 7 8 1 2 3 4

now sprites 1 2 3 4 disappears
S0 returns plane 5, i.e. sprite #1, next int my routine reorders the sprites
putting sprite 1 and the following on top

you get
1 2 3 4 5 6 7 8

As you can see my approach can safely handle up to 8 sprites per line.

Actually you're right when you say that solution for all seasons doesn't exist,
Also my approach has problems, they occur when there are two lines with 5 or more sprites

Look at this case, 10 sprites on two lines, 1 2 3 4 5 on the first line
6 7 8 9 10 on the second line
the sprite planes are
1 2 3 4 5 6 7 8 9 10
where on the screen you see
1 2 3 4 5
6 7 8 9 10

Sprite 5 and 10 disappear (5 is covered by 1 2 3 4 and 10 by 6 7 8 9)
S0 points to plane 5 (only the first 5th sprite is revealed, but the problem is similar if S0 reveals the last 5h sprite)

my routine does this reordering
5 6 7 8 9 10 1 2 3 4

on the screen now sprite 4 disappears (covered by 1 2 3 5), sprite 5 appears, and sprite 10 stay hidden !!
S0 points to plane 10 (i.e to sprite 4)

my routine does this reordering
4 5 6 7 8 9 10 1 2 3

on the screen now sprite 3 disappears (covered by 1 2 4 5), sprite 4 appears, but sprite 10 stay hidden
S0 points to plane 10 (i.e. to sprite 3)

my routine does this reordering
3 4 5 6 7 8 9 10 1 2
on the screen now sprite 2 disappears (covered by 1 3 4 5), sprite 3 appears, but sprite 10 stay hidden

actually you can go on and see that sprite 10 stay hidden for a large number of frames
only the first line of sprites flickers correctly, the second line is almost unaffected.

In this case your approach is better as it has the advantage to revert all the planes,
so one frame sprites 5 and 10 disappear, on one frame sprites 1 and 6 disappear.
Your solution goes better, but all depends on the game design and on the prob. of having two
or more lines with 5 sprites or more

if you use as flickering_offset the 5th sprite in S0 you get exactly my strategy,
the difference is that I do not mirror the SAT twice but I send to the VRAM
the SAT in two steps, from flickering_offset to the max used position first,
and, then, the initial part as second.
(I need to handle up to 20-24 sprites on the screen, so copying the SAT can
be CPU expensive)

Using as flickering_offset the 5th sprite in S0 is better when sprites are one line
If sprites are on two or more lines, the second line, in my approach isn't handled correctly
and your "blind" scramble is better