[hatari-devel] Monochrome Monitor in Falcon mode

[Laurent Sallafranque]

Hi Eero,

This patch is OK for me. I've uploaded it.

Regards

Laurent


Le 21/02/2011 21:50, Eero Tamminen a écrit :
> Hi,
>
> On sunnuntai 20 helmikuu 2011, Laurent Sallafranque wrote:
>> I've thrown a quick eye into this.
>> This is the original videl code I'll rewrite soon.
> Btw. I tried what the TOS4 desktop video mode settings set as ST shifter
> mode.  Everything else used 0x1 except for the compatibility modes for
> ST low and ST high which both used 0x0.  Both old and current Hatari
> videl code handled all of those fine, for RGB&  VGA&  TV monitor types.
>
> Only thing that bugs is use of mono monitor, which apparently uses mode 2.
> Attached patch would fix that case, but I'm not sure is that enough/right.
>
>
> 	- Eero
>
>> As it'll take some time to write the full videl emulation, I've differed
>> a little the coding of it to when I have more time.
>>
>> for info, in videl.c, I've just added some traces and prepared the code
>> (memorySnapshot, structure, comments, ...)
>> I haven't changed anything from the original videl code until now.
>>
>> Laurent
>>
>> Le 19/02/2011 18:10, Eero Tamminen a écrit :
>>> On lauantai 19 helmikuu 2011, Thomas Huth wrote:
>>>> I just tried to start Hatari in Falcon mode, with monochrome
>>>> monitor, ... but the screen does not come up right anymore. The screen
>>>> looks like 1280x400 instead of 640x400, and there is only graphics in
>>>> the upper part of the window...
>>> I could reproduce it.
>>>
>>>> I think there have been some changes to Videl code recently, maybe
>>>> something broke during these changes?
>>> ST, STE&   TT monochrome look fine, including the 640x400 TT monochrome,
>>> so it was Videl specific.
>>>
>>>> Could somebody please have a look?
>>> The problem is the new code in videl.c::VIDEL_ST_ShiftModeWriteByte().
>>>
>>> I commited one fix to that function, it was reading byte register as
>>> word and as result selecting wrong branch in switch, but that's not
>>> enough to fix the whole issue.
>>>
>>> Now the right switch case is selected, but code there isn't correct:
>>> -------------
>>>
>>>                   case 2: /* 1BP/640 Pixels */
>>>
>>>                           line_width = 0x28;
>>>                           video_mode = videl.monitor_type ==
>>>
>>> FALCON_MONITOR_VGA ? 0x8 : 0x6;
>>> ...
>>>
>>>           /* Set line width ($FFFF8210) */
>>>           IoMem_WriteWord(0xff8210, line_width);
>>>
>>>           /* Set video mode ($FFFF82C2) */
>>>           IoMem_WriteWord(0xff82c2, video_mode);
>>>
>>> -------------
>>>
>>> This code (like all other cases in this switch) checks only for VGA and
>>> seems to be expecting everything else to be RGB and for non-VGA
>>> monitors it sets the video mode "half pixel"&   "interlace" bits.
>>>
>>> "half pixel" bit (0x4) doesn't seem to have any effect on monochrome
>>> monitor, but interlace bit (0x2) makes the screen 640x800 instead
>>> of the correct 640x400.
>>>
>>> Laurent, could you fix the remaining part?
>>>
>>> 	- Eero
>>>
>>> PS. I don't understand why the code in this function is needed, things
>>> seem to be working fine without it...?
>>> _______________________________________________
>>> hatari-devel mailing list
>>> hatari-devel at lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/hatari-devel
>> _______________________________________________
>> hatari-devel mailing list
>> hatari-devel at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/hatari-devel
>
>
> _______________________________________________
> hatari-devel mailing list
> hatari-devel at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/hatari-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.berlios.de/pipermail/hatari-devel/attachments/20110223/dc9eb250/attachment.html>