I wanted to suggest using vram as a cache.
A player can have hundreds pics, but only a fraction of that is "recently used", so the reload will not hurt framerate. Benefits of the cache:
All vram space fiddeling headache is gone 
1 page vram cache, means: can have a 3rd background buffer, no more background save blit, BOB drawing speedup
The cache: let's divide a page into 4x4 pics, 16 pics. The cache got 16x this entry:
3 bytes ROM address of the pic (a 24bit mapper address) 2 bytes vram address of the cache position (or maybe 2 bytes x y coordinate for the blitter)
The ROM address is the unique id for the cache.
You could also have some different kind of id, like a 2 byte index to some tables.
Then just search thru all 16 entries. If found, you take the vram address and go.
If not found, then load the desired pic into one of the 16 cache positions. The position to pick is told by a counter that increments on every cache miss, round robin.
Whenever I said "16", this should be loaded from a "cachesize" variable to keep things tunable later. The slicing of the cache is contained in the "vram address" part, can also be changed later.
Limits of this setup: one pic is max 64x64 pixels size.
With more than 16 different pics "permanently in use" the speed may stall (or maybe not, see below).
sketching inner loop of the cache search:
;a contains low byte of id ;b is number of cache entries loop: 8 cp (hl) ;hl->low byte of id 8 jr z,checkhibyte ;rarely called extra stuff 12 add hl,de ;de = 5, skip to next cache entry 14 djnz loop -- 42
42*16 = 3 rasterlines per sprite. And with 10 sprites the penalty is... 3 rasterlines
Because z80 does something instead waiting for blitter painting that previous fat fighter, multiprocessor action
Actually, z80 is faster in copying a BOB from .rom to vram cache than blitter drawing it onscreen (transparent blit, slowest mode). So z80 is doing something while blitter is running. Even permanent cache miss doesn't look like a desaster.
And if the cache turns out to do well, the cache loader could DECOMPRESS images from .rom 
Also kind of "decompress" would be the conversion from screen 5 pics to 16 color sprites format - no more "things stored 2x in the .rom".
ever tought of doing a copy mirrored instead of wasting 2 times as much data??
Good point! The cache loader mirroring the image also kind of is "decompress ROM data".
I feel that your idea just somehow virtualy doubled the .rom size 
In this case, the cache entry needs an update:
3 bytes ROM address 1 byte mirror info (like 0 = unflipped, 1 = flipped horizontal)
The pic comes from the same ROM address, but it is different (flipped).
A different thing needs a different id. So the mirror byte is part of the id.
Update about the vram pointer of the cache entry:
Port 99 setup only covers 16k. Need to set another vdp register to address 16k banks.
For speed, this value is better in a third byte.
Now things are more tidy because now you can allocate a cache tile anywhere in 128k.
Similar, there be 3 bytes to completely describe the same vram address to the blitter: x,y, and page number.
So a cache entry ends up like this:
--- id part 3 bytes ROM address 1 byte mirror info (like 0 = unflipped, 1 = flipped horizontal) --- vram address part 3 bytes to describe it to port 99 gear 3 bytes to describe the same location to blitter gear
The id part in the cache entries change dynamic, the vram addresses are initialized one time at game start.
I'm glad i maybe helped out some one with such simple solution 
@hit9918
don't you think that the gain from having a 3rd screen for restoring background is lost owing to the overhead of the cache management and update?
Consider that a sprite frame (32x64) takes about 256 (shapes)+128(colors) bytes, not a lot in the end.
I think there is a much simpler solution for this game:
Assume that the bitmap details are small and can fit all in one single page (it has to be the case, as sprites are already 32x64), say page 3
Use, as you say, page 2 for storing the background, so there is no need for extra copies for restoring the area where sw sprites appear.
Store data for HW sprites in ROM (as we said 64K give 170 frames, you can live with that 
)
Each frame:
Send vdp commands to restore the background in page 0 and 1 from page 2 and to copy the bitmap details
While the vdp works, use standard rom to vram transfer to update sprite definitions
This implies 2*384 bytes to be transferred by the z80 at each frame (two players) -> it can work even to 60Hz!
In ROM you can store as many sprites you like, in the 4th vram page, you can fit the bitmap details for those frames that do not fit in the 32x64 grid
For this game it can work, it is much simpler and without cache overhead
@ARTRAG
I guess your message was "I want both players with sprites".
I see the whole issue coming down to "30 fps streetfighter versus 60 fps streetfighter with reduced graphics".
A stunt palette was posted and I envision that palette getting damaged by 3color sprites.
Is there a screen 5 to 3color sprite converter? Or someone draw the 300 sprites?
A 32x64 pixel bob: LMMM 0.017s + HMMM 0.006s = 0.023s . The 30fps streetfighter would go with BOBs + a 32 pixel wide 16 color sprite band assisting. 16 color means no repainting of pics and no palette damage.
About the cache,
blitter HMMM copy 167040 byte/s
cpu outi 198333 bytes/s
cpu loads the image from ROM while blitter does the background cleanup copy 
You still could have a cache for flipped images - in RAM
well to be honest...
I dont see a decent sf2 clone working on 60fps
maybe 15 or 20 fps is discussable...
im kinda losing hope of making a decent port........
the sprites are just too big to handle
I have been talking and thinking about it for the last few days,
I just dont see it happening on 30 fps, unless we reduce the spritesize immensely:
But is this really gonna be cool ?
this will look too much the already existing sf2 clone:
