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

[Laurent Sallafranque <laurent.sallafranque@xxxxxxx>]

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áček a écrit :

On Wed, Mar 26, 2014 at 7:34 PM, Laurent Sallafranque <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?

--
MiKRO / Mystic Bytes
http://mikro.atari.org