Falcon SCSI write issues

[exxos]

I have been talking to @jookie and he's going to write a custom sector test program so we can work out what the actual failure point is more accurately..

Currently there is a bit of a contradiction, because I can seemingly copy a 6.7MB file fine(*), but 8MB+ fails. But @jookie program fails at 4MB.. So we really need to figure out what the actual failure point is and then have other people confirm...

(*) While the file copy did complete, the data was not verified so I don't really know if it trashed anything or not doing that file size..


EDIT:

Uwe says the limit in HD12.72 will be 8MB.. So people can try with that soon as well..

[Badwolf]

I have been talking to @jookie and he's going to write a custom sector test program so we can work out what the actual failure point is more accurately..

Currently there is a bit of a contradiction, because I can seemingly copy a 6.7MB file fine(*), but 8MB+ fails. But @jookie program fails at 4MB.. So we really need to figure out what the actual failure point is and then have other people confirm...

(*) While the file copy did complete, the data was not verified so I don't really know if it trashed anything or not doing that file size..

Bear in mind (as per my earlier digging through the source) you'll be subject to the filesystem's contiguous free clusters too. Best tested with an empty partition else you might find a larger file is split into smaller blocks to fit in around occupied clusters and the problem doesn't manifest.

BW

[exxos]

Bear in mind (as per my earlier digging through the source) you'll be subject to the filesystem's contiguous free clusters too. Best tested with an empty partition else you might find a larger file is split into smaller blocks to fit in around occupied clusters and the problem doesn't manifest.

Yes it will be blank disk.. Fragmentation etc was already talked about.

[mikro]

Great work @Badwolf and @exxos. So 16383 sectors, hmm. We have seen that number in the AHDI source code, too, right? So that could be a sort of official confirmation by Atari.

[stephen_usher]

I know that this is not relevant to Jookie’s test but it should be made clear that:

Size of file != Size of transfer.

I’m very surprised that Atari drivers are trying to send such large chunks all in the one transfer. It’s very unusual.

Here's how EmuTOS does it:

The sector count, calculated from file size and contiguous available clusters (1), is passed directly to the hardware and it's set off (2).

1. https://github.com/emutos/emutos/blob/m ... fsio.c#L84
2. https://github.com/emutos/emutos/blob/m ... csi.c#L167

So on a nice clean drive, a large file will be perhaps only three transfers depending on cluster boundaries (head, middle [the big bit], tail).

BW

This only works because it’s a single tasking OS due to the fact that the machine is effectively just waiting for the I/O to complete.


I’m guessing that MiNT performance would be awful if it used the underlying driver. Any large disk access would halt it.

[exxos]

Great work @Badwolf and @exxos. So 16383 sectors, hmm. We have seen that number in the AHDI source code, too, right? So that could be a sort of official confirmation by Atari.

Uwe is adament that its going to be 8MB limit as thats what's in AHDI. I don't know if it's different in other versions, or even if they updated it in falcon years..

More testing needs to be done when Uwe and Jookie finish updates.

[mikro]

Let me contribute with my experience.

First, that "Fast SCSI" option is close to being useless:

HD Driver 12.71, slow scsi: 1790 kb/s, st high
HD Driver 12.71, fast scsi: 1850 kb/s, st high

Which is kind of expected, 64 KB blocks are more than enough for any serious copy operation.

Second, I have created a set of files to test the transfer (IDE -> BlueSCSI):

3M - ok
4M - ok
5M - ok
6M - ok
7M - ok
8M - nok
16M - nok

So I'd say that the AHDI's statement holds here.

My SCSI controller is marked as LOGIC (triangle)SA8C
L53C80JC 2
5638 9250 A

I'll try to conduct the same test on my other Falcons.

[Badwolf]

Second, I have created a set of files to test the transfer (IDE -> BlueSCSI):

Similarly, I've done an experiment writing increasingly large sizes of a big old buffer to disc under HDDriver 11.14.

Almost same result as @mikro, basically (my 8MB purports to complete -- haven't checked the contents):

IMG_9313.jpeg (175.46 KiB) Viewed 108 times

SCSI hangs at this point. Interestingly the cursor continues to flash. I presume we simply never get the transfer completed interrupt.

Upon reboot, SCSI remains crashed:

IMG_9314.jpeg (140.57 KiB) Viewed 108 times

I think @SteveBagley's code archeology was spot on.

Amazing. I guess any long term Falcon SCSI users settled on AHDI by experimentation, with its secret DMA size limits, or were not getting very much done productively? 8MB+ files weren't exactly rare even when this would have been a typical setup.

There was some muttering earlier in the thread about seasoned Cubase users' rule of thumb was that HDDriver 8 was the best. Perhaps that and versions prior didn't do the same 'all the ST-RAM' trick so the problem was less of an issue back in the day?</speculation>

BW

[SteveBagley]

Found another interesting comment in the various bits of AHDI source about

;+
; Dec-10-1991 ml. Don't need to have extra long timeout because
; extended read and write are not supported due
; to the 8 bit counter in the DMAC.
;
; Feb-13-1992 ml. Put code back in because DMAC has been modified
; to have a 14-bit counter.

Steve

[exxos]

Found another interesting comment in the various bits of AHDI source about

;+
; Dec-10-1991 ml. Don't need to have extra long timeout because
; extended read and write are not supported due
; to the 8 bit counter in the DMAC.
;
; Feb-13-1992 ml. Put code back in because DMAC has been modified
; to have a 14-bit counter.

Steve

Interesting.. Wonder what DMA chips they was actually referring to though.. Assume falcon going by the dates..

The Linux guys must have known about all this as well then... But how.. Unless just experimenting..