[FFmpeg-devel] a64 encoder 7th round

[Bitbreaker/METALVOTZE]

>>> now a few questions, i hope iam not too annoying
>>> the low nibble is either 15 or 8 if i did RTFS correctly
>>> do you have 64 byte left for a LUT?
>>> if so you can do some code equivalent to
>>>
>>> x= read_net();
>>> dst[0]=lut[x  ];
>>> dst[1]=lut[x+1];
>>> dst[2]=lut[x+2];
>>> dst[3]=lut[x+3];
>>> x= read_net();
>>> dst[4]=lut[x  ];
>>> dst[5]=lut[x+1];
>>> dst[6]=lut[x+2];
>>> dst[7]=lut[x+3];
>>> ...
>>>
>>>   
>>>       
>> Gotta see tomorrow if that works...
>>     
Hmm, i am afraid, a lookup from the table is as expensive as reading a 
byte from the network :-) So over all you end up at the same speed again.

   [setup as always]
   ...
  
   ldx $de00
   lda lut+0,x
   sta dest,y
   iny
   lda lut+0,x
   sta dest,y
   iny
   lda lut+2,x
   sta dest,y
   iny
   lda lut+3,x
   sta dest,y
   iny

that is 12 cycles per reconstructed byte in the inner loop.
263 big LUT is possible in size, but the index will be too small for 
that :-)

As for the memory there is still some space left, the displayer is i 
think ~0x400 bytes big, and there is still ~0x1400 bytes free before the 
first buffer starts at address $2000, at $4000 the second buffer starts 
for the other charset and charmaps. Then there is again some space left, 
but i need a bit of place for the assembler compiler and source. From 
$a000 Basic ROM starts, but that can be swapped out so that RAM appears 
at that address, same goes for $e000-$ffff, where the kernal is located, 
but i need some of the routines of that kernal, so banking in out all 
the time is a bad idea. Same goes for $d000-$e000 were all the memory 
mapped i/o + colorram is located. Colorram is loaded directly when 
needed, so as i am a bit slower than the rasterbeam on the screen while 
loading i just start loading + writing the actual colorram after the 
first line was displayed by the video chip. As the colorram is linear, 
this is no problem.
Else i would need to load the colorram information into a buffer and 
speedcopy in the remaining 112 rasterlines of the overscan. Not a good 
option.


However another idea i got, but have to do tests and code code code for 
that first to see if it is a good idea:
Loading an initial bitmap, and then only transferring the blocks that 
change on the bitmap. If that works with a fixed amount (0x800 bytes 
would be a fourth of the bitmap), we could more or less display in 
bitmap quality. However when we do doublebuffering we would need to 
change bitmaps in each buffer alternatingly, if not doing double 
buffering the changes on the bitmap need to be applied in 112 
rasterlines (else the changes applied so far get visible already), way 
too few for 0x800 bytes. But still, i see how much changes fit into 
0x800 bytes and how quality comes out. If it looks good, i think 
further, if the result sucks, bad luck :-)

Also a good source for furtehr tries:
http://www.devili.iki.fi/Computers/Commodore/C64/Programmers_Reference/front_cover.html
or in textform:
http://www.zimmers.net/cbmpics/cbm/c64/c64prg.txt

Kindest regards,

Toby