[hatari-devel] Mahabharata demo problem ?

[Eero Tamminen]

Hi,

On lauantai 15 tammikuu 2011, Eero Tamminen wrote:
> Not unbounded sizes.  During the demo, 5120x200 and 5120x240
> sized resolutions are requested several times.
> 
> I think there could be some corner-case that Hatari Videl code isn't
> emulating.   Maybe the real HW clips large resolutions and like ST/STE
> does something "unexpected" when being requested funny resolution
> changes.

Videl code does following:

get width (register is scanline size in words):
        (handleReadW(HW + 0x10) & 0x03ff) * 16 / VIDEL_getScreenBpp();  

get bpp:
---------------------
        int f_shift = handleReadW(HW + 0x66);                                   
        int st_shift = handleRead(HW + 0x60);                                   
        /* to get bpp, we must examine f_shift and st_shift.                    
         * f_shift is valid if any of bits no. 10, 8 or 4                       
         * is set. Priority in f_shift is: 10 ">" 8 ">" 4, i.e.                 
         * if bit 10 set then bit 8 and bit 4 don't care...                     
	...
        if (f_shift & 0x400)            /* Falcon: 2 colors */                  
                bits_per_pixel = 1;                                             
        else if (f_shift & 0x100)       /* Falcon: hicolor */                   
                bits_per_pixel = 16;   
---------------------

If scanline register value is 320, and bpp gets set to 1 instead of 16:
-> width = 5120

And indeed when I traced changes in all of these registers:
b (0xff8210).w ! (0xff8210).w :trace
b (0xff8266).w ! (0xff8266).w :trace
b (0xff8260).b ! (0xff8260).b :trace

Whenever the window goes too wide, I see:
  $ff8266 = $400
2. CPU breakpoint condition(s) matched 1 times.
WARNING: too large screen size 5120x240 -> divided by 4x1!
  $ff8266 = $100

I.e. Falcon shifter control register 2-color mode bit is toggled, but
nothing else.


I remember that monochrome toggling on color resolutions did something
special on ST(e), maybe something similar should happen on Falcon's Videl?


There's also this suspicious stuff in VIDEL_renderScreen():
        if (since_last_change > 2) {                                            
                if (vw > 0 && vw != width) {    
                        Dprintf(("CH width %d\n", width));                      
                        width = vw;                                             
                        since_last_change = 0;
...
       if (since_last_change == 3) {                                           
                HostScreen_setWindowSize(width, height, bpp == 16 ? 16 : ...
        }                                                                       
        if (since_last_change < 4) {
                since_last_change++;
                return false;
        }

This function is called from Video_DrawScreen() which is called from
Video_InterruptHandler_VBL() and on fullscreen switches.

-> The resolution is changed 3 VBLs later than it actually happens and
     rendering of Falcon screen content to the Hatari window is skipped
     during this time.

Everything seems to work fine if I remove that (see the attached patch).
 
Thomas?


	- Eero
-------------- next part --------------
A non-text attachment was scrubbed...
Name: videl-change.diff
Type: text/x-patch
Size: 1694 bytes
Desc: not available
URL: <https://lists.berlios.de/pipermail/hatari-devel/attachments/20110115/8de5760f/attachment.bin>