Re: [hatari-devel] move.w $ffff8908.w,d0 returns $ff in high byte?

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 30/11/2024 à 16:38, Christian Zietz a écrit :
> Miro Kropáček schrieb:
>
> > first I thought this is a clear bug but then looking into ioMem.c I 
> > see that this is deliberate? Is this how real hardware (STE in this 
> > case) behaves, i.e. that I can't read current DMA counter value as a 
> > word?
> >
> > Just to clarify, I'd expect
> >
> > move.w $ffff8908.w,d0
> >
> > return d0.w = $00HH
>
> See attachment for the result on a real STE. I don't think the data bus 
> is actively driven for the high byte; so it's just "bus noise". Hence, 
> Hatari's choice of 0xFF is as good as every byte.

Hi

thanks for the check on real HW.

Quite a long time ago, I remember I checked this on STF/STE too. 
Sometimes "unused" registers a fixed value like 0, and sometimes it's 
the "bus noise".

for some reason I chose 0xff, because most of the time bits were set to 
1, but in real HW that's of course dependant of the current opcode and 
what was last left on the bus.

Nicolas