Re: [hatari-devel] Cycle exact setting affects nf_scsidrv

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On 10/11/18 11:52 PM, Uwe Seimet wrote:
> Thank you. Attached there is a patch for nf_scsidrv.c.

Is st_buffer data something that could be program code read from
the SCSI disk?  If yes, all caches would need to be flushed for that.


> > Le 11/10/2018 à 22:11, Uwe Seimet a écrit :
> > > > I don't see these flushes in your nf_scsidrv.c Hatari code.
> > > >
> > > > Tested patches welcome! :-)
> > >
> > > Since I cannot reproduce the original issue anymore, which is not that
> > > surprising if it's about caches, I will only be able to test that currently
> > > with this patch on my machine it works as expected.

I had been hoping that your issues were reproducible, so that
you could verify that the changes indeed fix things.  :-/


	- Eero

> > > But first I need a hint how to correctly convert "unsigned char *" to
> > > uaecptr. Of course, I could just pass 0, becausing flushing ignores
> > > the address and size anyway :-).
> >
> > uaecptr is just a 32 bit pointer to somewhere in the emulated machine
> > memory, so it's just an unsigned int
> >
> > src/cpu/sysdeps.h:typedef uae_u32 uaecptr;
> >
> > for example, look at GemDOS_SNext() in gemdos.c