Re: [hatari-devel] Problem with SCSI initiator command register

[ Thread Index | Date Index | More Archives ]


> Well, what did you expect? One loop iteration will take approximately 5
> milliseconds (since you're basically waiting for the 200 Hz counter to
> toggle its sign), and you're looping with d1 = 12000 times ...
> that makes 12000 * 0.005 s = 60 s = 1 minute.
> So unless you really expect something different here, I'd say Hatari
> works here as designed ;-)

This is getting more and more interesting ;-).I have not checked how
long this loop might take for several years, probably because with a
real Atari it will always terminate early. (I will have to re-check the
arbitration timeout value again in any case, but I guess it is OK.)

So the fact that with a real Atari the loop terminates early even when
no devices are connected means that the other (non-timer) register
values differ between Hatari and the TT/Falcon. They are checked in
order to quit the loop early, depending on the SCSI bus signals.

As a work-around this might work: Bit 6 of the SCSI initiator command
register ($ffff8783 with the TT) should always be 1 on a read, signaling
that the arbitration is in process. The SCSI data register ($ffff8781 with
the TT) should always be 0 if arbitration is in progress, signaling that
there is no higher ID requesting the bus. With the Falcon it's the same,
but on a Falcon the SCSI register is selected via the DMA modus register.
In case you can or want to emulate this I can test it.

The correct behavior is probably difficult to implement. Didn't somebody in
this mailing list mention some time ago that he was interested in emulating
the SCSI chip? It's a bit tricky, in particular if you want to get
HDDRIVER or CBHD working with SCSI, but the more demanding a task is the
more interesting it is, isn't it? ;-)



Mail converted by MHonArc 2.6.19+