Re: [hatari-devel] ACSI: READ/WRITE (10) incorrectly evaluate block number

[Thomas Huth <th.huth@xxxxxx>]

Am Sun, 27 Oct 2013 11:00:32 +0100
schrieb Uwe Seimet <Uwe.Seimet@xxxxxxxxx>:

> Hi Thomas,
> 
> > > This might work, I have also already been thinking about this.
> > > This is a general problem where not only Hatari is affected, but
> > > also real hardware that supports the ICD mechanism for using all
> > > SCSI command classes (GigaFile, UltraSatan, ...) connected to the
> > > ACSI bus. But would this also work if there is no DMA transfer at
> > > all, but only PIO? What happens if I read (or send) data not by
> > > DMA but by PIO exclusively? In this case we could not draw any
> > > conclusions from the state of these pins, could we?
> > 
> > As far as I understood, the A1 pin has always be set to zero when
> > starting a new command, no matter whether there is a DMA transfer
> > involved or not. Or did I miss something here?
> 
> You may be right, I have not yet had a very close look at this.
> Haven't looked at the low level ACSI stuff for quite a long time ;-).
> 
> Do you think you can implement it this way?

Yes, I just pushed a little patch that resets the counters back to zero
when A1 is low. Please test whether this cures your problem.

> By the way, the byte counters (bytecount/byteread) are probably not
> reset to 0 when resetting Hatari. Whenever the ACSI emulation was
> out-of-sync I had to restart Hatari in order to get things right
> again. Just resetting the emulation did not help.

You're right, the counters were not resetted here, too. However, this
problem should also be fixed by the A1-patch, so I did not add an
additional reset handler here.

 Thomas