Re: [hatari-devel] It seems I encounter a bug into hatari

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 26/03/2014 20:22, Laurent Sallafranque a écrit :
> Giving a closer look at how hatari manages these registers, I see
> something that may be interresting :
>
> In IOmemtabST :
>
>      { 0xff8240, SIZE_WORD, Video_Color0_ReadWord,
> Video_Color0_WriteWord },            /* COLOR 0 */
>      { 0xff8242, SIZE_WORD, Video_Color1_ReadWord,
> Video_Color1_WriteWord },            /* COLOR 1 */
>      { 0xff8244, SIZE_WORD, Video_Color2_ReadWord,
> Video_Color2_WriteWord },            /* COLOR 2 */
>      { 0xff8246, SIZE_WORD, Video_Color3_ReadWord,
> Video_Color3_WriteWord },            /* COLOR 3 */
>      { 0xff8248, SIZE_WORD, Video_Color4_ReadWord,
> Video_Color4_WriteWord },            /* COLOR 4 */
>      { 0xff824a, SIZE_WORD, Video_Color5_ReadWord,
> Video_Color5_WriteWord },            /* COLOR 5 */
>    ...
>
>
> In IOmemtabFalcon :
>
>      { 0xff8240, 32       , IoMem_ReadWithoutInterception,
> VIDEL_StColorRegsWrite },         /* ST color regs */


Hi

If you're in falcon mode, then a write will call VIDEL_StColorRegsWrite, 
which does nothing in fact when we look in videl.c (except changing 
hostColorSync), so value should be stored.

More tests would be needed. If you have :

	move.l	#$ffeeddcc,d0
	move.l	d0,$ff8240.w
	move.w	$ff8240.w,d1
	move.w	$ff8242.w,d2

What values do you get in d1 and d2 on Falcon and Hatari ?


Nicolas