Re: [hatari-devel] Small bug in Hatari Falcon emulation

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


Le 25/11/2020 à 02:27, Roger Burrows a écrit :
On 25 Nov 2020 at 2:34, Eero Tamminen wrote:

Hopefully this pseudo-code (without bus error
checking) clarifies what I meant:
-------------------------------------
for (addr = start; addr < end; addr++) {
    old = value;
    value = *addr;
    /* this check is what I'm referring to: */
    if (value == old) {
       value = ^value;
       old = value;
       value = *addr;
       if (value == old) {
          printf("0x%06x = <no value>\n", addr);
          continue;
       }
    }
    printf("0x%06x = 0x02x\n", addr, value);
}
-------------------------------------


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.

You said that value is 0xff, which I assume to
be from a byte read.  If you do word reads from
non-existing RAM area, is the value 0xffff (as
expected), or something else?



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.
^^^^^^^^^^^^^^^^^^^^^^^^^^



Did you read my 2nd message (quoted above)?  See the underlined bits.

If you want any more answers, I'll send you the code & you can investigate
further.

Unfortunately I don't have Falcon HW.

If you write a program to get the data you want, I'll run it on my Falcon.

Hi
regarding this memory reads in ste compatible mode, I think Eero is mixing things. From what I understand in Roger test, this means that if we read non existing ram on falcon, there will be no bus error but you will read a kind of random value (whether it's byte/word/long doesn't matter) whose real content is certainly based on the latest data seen on the bus.

this is similar to STF/STE when you try to read ram in the range 512KB-1MB on a machine with only 52 KB : there's no bus error, but you read some "random" values which are related to the bus activity.

Nicolas





Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/