Falcon SCSI write issues

[exxos]

But isn't it the very opposite? The limit is specifically the sector counter implemented as 14 bits in hardware according to Atari sources - not the byte count resulting from that and the sector size. So the limit is fixed at 16383 sectors, not 8mb.

Uwe said :

This is not correct. How would the DMA chip know the physical sector size? It would have to send a SCSI command to the drive to learn that. The DMA chip counters of ST and Falcon assume 512 bytes per sector. If a sector is bigger, the driver has to take this into account. When Atari talk about sectors and AHDI, it is always sectors of 512 bytes, because AHDI does not support anything else. HDDRIVER supports physical sector sizes of up to 4096 bytes, because these sizes are used by hard drives. 4096 only by SATA 4kn drives, as far as I can tell. I have such a drive, it works fine with the Atari.

I should add that you can transfer not just multiples of 512, but any byte count. Most SCSI commands do not deal with sectors, but only with byte sequences, e.g. the commands that get the drive name, the capacity or the block size. The computer tells the device how many bytes to transfer.

[dml]

Ok so the truth is really somewhere in between - the limit is indeed caused by a 14 bit counter but the hardware-side sector counting is in 512byte sector blocks, so insensitive to the actual sector size in use. An important distinction there but at least it seems to be clear now.

[czietz]

Fwiw, this restriction is also mentioned in the "Sparrow DMA ASIC" documentation by Atari. (Sparrow being the codename for what would become the Falcon.)

write only sector counter (14 bits)

This kind of documentation must always be read with a bit of caution, since these are clearly draft documents. But here the documentation matches the actual implementation.

[Cyprian]

Fwiw, this restriction is also mentioned in the "Sparrow DMA ASIC" documentation by Atari. (Sparrow being the codename for what would become the Falcon.)

write only sector counter (14 bits)

This kind of documentation must always be read with a bit of caution, since these are clearly draft documents. But here the documentation matches the actual implementation.

is it also valid for the ST/TT ACSI?

[czietz]

is it also valid for the ST/TT ACSI?

No. Atari's ACSI/DMA Integration Guide:

The Atari ST can DMA up to 127.5K bytes (i.e.255*512 byte blocks) in a single operation.

Off the top of my head, I don't know about the TT; but it's probably prudent to assume that the DMA chip limit is the same. (With the TT - or an ST with Alt-RAM - there is another restriction. Transfers with a final destination that is not ST-RAM have to go through the FRB, which is only 64 KiB.)

[Badwolf]

If you have a reproducible test case that shows that something still is wrong with EmuTOS's implementation, please share it on emutos-devel and Roger or I will have a look when time permits. However, I can confirm that the limit of 16383 for the Falcon SCSI DMA is known to EmuTOS and being enforced by its disk driver.

I suspect it may have merely been a coincidental error and then a misreading of the code on my part.

Sorry, @czietz, I forgot to mention this: I obtained the latest ET 1.4 512 PRG and booted into it from floppy from a completely clean boot and replicated my megabyte-by-megabyte increasing block size Fwrite() test: I did not see a failure under these conditions.

So my previous lock up was unlikely EmuTOS related and the max block transfer size limiting code appears to be working well.

Thanks,

David.

[czietz]

Thank you for retesting and reporting back. :)

[Dlfrsilver]

I remember last year i had a chat with a Falcon user doing cubase and also transfering big files in SCSI.

He found the solution, it's a bug in the TOS v4.04 : You need in HDdriver to lower the buffers from 300 to 100 only (otherwise a patch in TOS v4.04 would be needed).

Note that i have met the same corruption problem with IDE (i use an 8gb compact flash in mine). Anything above 20mb got silently corrupted (even with clockpatch installed). I applied the same fix he did for SCSI, and it solved the problem also with IDE hard drive/CF file transfer.

[exxos]

@Dlfrsilver I think it was a limitation in the hardware which basically no one knew about.. There's fixes in the latest HDdriver for it.

[mikro]

He found the solution, it's a bug in the TOS v4.04 : You need in HDdriver to lower the buffers from 300 to 100 only (otherwise a patch in TOS v4.04 would be needed).

I somehow doubt that HD Driver's *internal* cache manager has anything to do with TOS. Either it was / is a bug in HD Driver and you should report it or this is just pure speculation.

Note that i have met the same corruption problem with IDE (i use an 8gb compact flash in mine). Anything above 20mb got silently corrupted (even with clockpatch installed).

Again, either a bug in HD Driver (I wonder what exactly the "300" means, IIRC there's 2/2/10 default setting in the three text fields?) or completely unrelated (like bad memory -- that would actually explain a lot in your case: less memory used, less likely to touch the wrong memory module).