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

[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?

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.

Take care

Uwe