| Re: [hatari-devel] Small bug in Hatari Falcon emulation |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
On 23 Nov 2020 at 12:16, Eero Tamminen wrote:
>
> On 11/23/20 2:46 AM, Roger Burrows wrote:
> > On 23 Nov 2020 at 1:08, Eero Tamminen wrote:
> >> On 11/23/20 12:47 AM, Roger Burrows wrote:
> >>> When the "STe Bus Emulation" bit (0x20) in the Falcon Bus Control
> Register
> >> at
> >>> $ff8007 is zero, "STe Bus Emulation" mode is set. This affects bus
> error
> >>> handling. Hatari already models this as far as the I/O memory area is
> >>> concerned (I haven't attempted to check how accurately yet). But it
> also
> >>> affects bus errors when accessing RAM, which Hatari does NOT model.
> >> Basically,
> >>> on a real Falcon with "STe Bus Emulation" enabled, there are NO bus
> errors
> >>> generated for the whole $0 to $dfffff region, even in user state. Even
> if
> >> RAM
> >>> isn't present at an address, no bus error occurs.
> >>
> >> Do reads to non-existing RAM areas produce some specific value like
> >> zero, or random values, or
> >
> > A quasi-random sampling of values shows 0xff is returned. That looks like
> a
> > floating bus (but what would I know, I'm a software guy).
> >
> >> is the target location value just unmodified?
> >>
> > I'm just doing reads, so I'm not sure what you mean.
>
> I meant the read result (e.g. register where you
> read it).
>
I still don't know what you mean. I'm doing a read from a non-existent RAM
address. I did write a separate program to do:
read
write new/read
write old/read
and the value returned isn't always $ff (and rewriting the original value
doesn't restore it, unsurprising considering there's no RAM there). I think
it's just floating bus values, but I'm not a hardware guy.
> You seemed to be doing byte reads. For IO HW
> regs, it matters whether read is byte or word
> sized. Did you try word access?
>
1. As I said in my original post, the report is NOT about accessing the I/O
memory area. Hatari already has some code to handle that & I haven't
investigated whether that code is correct or not. The report is strictly about
accessing the RAM area, both existing & non-existing memory.
2. I spent some more of my time and added support for different widths of
memory access. Unsurprisingly (to me) the same issue happens with
byte/word/long widths.
If you want any more answers, I'll send you the code & you can investigate
further.
Roger