Falcon SCSI write issues

[stephen_usher]

The other issue is that large block reads/writes would cause the system to hang in I/O wait for far too long for an interactive, multi-user, multi-tasking OS. Linux would most likely use the normal UNIX system 4K or, in exceptional cases, 8K chunks.

Interestingly the cursor continued to flash during my tests. Including when it hung, so interrupts must still have been working implying the bus isn’t relinquished for the entire duration of the transfer.

Does it work a bit like blitter nohog mode, I wonder?

Anyway point being I don’t see why multitasking would be unduly affected. Or perhaps I’ve misunderstood your point?

BW

If the DMA is hogging the bus then you’d get the system essentially hanging during the transfer. It could work like the blitter I s’pose.

[don_apple]

We need to know now if cubase has its own SCSI driver.. And if so.. Does it suffer from the same "8MB bug"..

Don't know if Cubase has its own SCSI driver.

But Cubase Audio Falcon seems to be doing its own thing with SCSI, because there are multiple threads over on a-f where it is mentioned that in order to get it work correctly with a BlueSCSI (and other similar hardware) a special setting is needed in the BlueSCSI config file:
https://www.atari-forum.com/viewtopic.p ... 11#p473011
https://www.atari-forum.com/viewtopic.p ... c6#p484256
https://www.atari-forum.com/viewtopic.p ... 75#p485875

[exxos]

New HDdriver 12.72

https://www.hddriver.net/forum/viewtopi ... 1471#p1471

https://www.hddriver.net/en/prices.html

These are the main changes in HDDRIVER 12.72:

- HDDRIVER: On the Falcon, an undocumented behavior of the DMA chip limits the number of bytes that can be transferred via SCSI/DMA in one go to just under 8 MiB. This value is also used by AHDI. The accelerated transfer mode for Ataris without Alternate-RAM has been adjusted accordingly.
- HDDRUTIL: The display of invalid partition data with "Check Boot Sector" has been improved.
- HDDRUTIL: Calling "Locate HDDRIVER" before an update installation could result in a corrupted HDDRIVER.SYS file. "Locate HDDRIVER" before an update is needless, because just like with the initial installation, double-clicking the boot drive is sufficient. The manual explains when to use "Locate HDDRIVER

[kohli79]

Yes, I've already seen that. :)
Copying my test file to SCSI (50MB) under TOS now works without any problems with BluSCSIV2. (Fast-SCSI enabled)
Tested it again shortly before with the old driver and it crashed with 2 bombs.
As I said, all under TOS.

[Badwolf]

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

I note on the emutos-devel list it's reported that the 16k cluster limit is known about and enforced. I must have misinterpreted the trace I did above, in that case. I did however still see a lock up on Emutos PRG (albeit v1.3) so when I have a chance I'll investigate that further in case I was seeing an artefact of a previous (HDDriver-induced) failure.

BW

[czietz]

I note on the emutos-devel list it's reported that the 16k cluster limit is known about and enforced. I must have misinterpreted the trace I did above, in that case. I did however still see a lock up on Emutos PRG (albeit v1.3) so when I have a chance I'll investigate that further in case I was seeing an artefact of a previous (HDDriver-induced) failure.

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.

[dml]

Great work guys not letting go of this until it was figured out. Especially jookie for the sector-level test - final proof.

Seems this is/was known to some developers (certainly Atari!) at some point but not widely known to the rest of us...


In another life I (with 1 other engineer) caused & identified an ALU bug in the microcode of a CPU a bunch of you are probably still using - which prevented some builds of nameless but very well known commercial software from running properly. It eventually got acknowledged and fixed - but ooooh that took a *lot* of convincing to get there :P :P :P

[exxos]

Just got another Email from Uwe...

one more thing I want to mention for the sake of completeness: The precise
limit is 8388096 bytes, not 16383 sectors. This is an important to memorize,
because media with a different physical sector size than 512 bytes also
have to be taken into account, and such media are also used by Ataris.
CDs or DVD-RAMs are a good example. If you are using software like ExtenDOS,
which uses the SCSI Driver, the block limit is 4096 sectors (blocks) for
data CDs and even less for audio CDs.
The same applies if you access a DVD-RAM disc, e.g. with a SATA drive
connected to the Atari. Almost any DVD-RW drive supports DVD-RAM media,
and HDDRIVER can make use of these media as if they were hard drives. You
can format them, partition them, and then use them with TOS.
A bit more exotic, but still in use with some Ataris: MODs. They also often
use physical sector sizes > 512 bytes.

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

Wilco, thanks Christian.

I haven't concentrated on EmuTOS and merely did a quick test in passing. I then tried to follow the evolution of an Fwrite() in the code since I was already examining why EMUCON2 didn't exhibit the problem.

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

BW

[dml]

one more thing I want to mention for the sake of completeness: The precise
limit is 8388096 bytes, not 16383 sectors. This is an important to memorize,
because media with a different physical sector size than 512 bytes also

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.

Although, with 512 bytes being the low end of the sector count, just keeping <8mb shoould be safe. Still technically wrong though :) Unless I'm still missing something here.