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

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

doc/todo.txt lists two other Falcon palette issues
with Hatari. Maybe those could be looked at the same
time? :-)


	- Eero

On keskiviikko 26 maaliskuu 2014, Laurent Sallafranque wrote:
> 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 */
> 
> 
> 
> And in video.c, I can read :
> 
> 
> /*
>   * [NP] TODO : due to how .L accesses are handled in ioMem.c, we can't
> call directly
>   * Video_ColorReg_WriteWord from ioMemTabST.c / ioMemTabSTE.c, we must
> use an intermediate
>   * function, else .L accesses will not change 2 .W color regs, but only
> one.
>   * This should be changed in ioMem.c to do 2 separate .W accesses, as
> would do a real 68000
>   */
> 
> void Video_Color0_WriteWord(void)
> {
>      Video_ColorReg_WriteWord();
> }
> 
> void Video_Color1_WriteWord(void)
> {
>      Video_ColorReg_WriteWord();
> }
> 
> ...
> 
> 
> Can this difference in code explain my problem ?
> 
> Regards
> 
> Laurent
> 
> Le 26/03/2014 20:15, Laurent Sallafranque a écrit :
> > No problem here.
> > I use this in many parts of my code.
> > 
> > I'm running in true color, so these registers are not used at all.
> > 
> > The rest of the game works well and the sprites display use this
> > technic.
> > 
> > From me, the problem seems to be in
> > 
> >            lea.l        sky_palette_end-8(pc),a0
> > 
> > or
> > 
> >             move.l        a0,$ffff8248.w
> > 
> > or
> > 
> > .do_display_sky:    addq.l        #4,$ffff8248.w
> > 
> > or
> > 
> >             move.l        $ffff8248.w,a0
> > 
> > Only the pointer to the palette is wrong, the movem display on the
> > screen but not the expected palette.
> > Just under this code, there's the background picture display and it
> > displays correctly (at the correct screen address and with the correct
> > colors)
> > 
> > Again, it's just the address pointed by A0 that seems wrong under
> > hatari (or maybe the real falcon is wrong here ;)  lol
> > 
> > Laurent
> > 
> > Le 26/03/2014 19:37, Miro Kropác(ek a écrit :
> >> On Wed, Mar 26, 2014 at 7:34 PM, Laurent Sallafranque
> >> <laurent.sallafranque@xxxxxxx <mailto:laurent.sallafranque@xxxxxxx>>
> >> 
> >> wrote:
> >>     I use these "unused" registers to save some values.
> >> 
> >> Interesting approach ;-) However, since you are referring to bad
> >> colours, can't exactly this be the culprit? What makes you think they
> >> are unused?