Falcon SCSI write issues

[exxos]

I scoped all the SCSI pins to see if anything looks on.. Basically no. There was a couple pins which seem to randomly struggle a bit to go high but could have been a non driven state as drive access gave nice square waves.

My only other thought currently is maybe modern SCSI emulators may take the data faster and not cause the error. But I guess some benchmarks would have to be done by a few people to see if there is any huge speed differences. But it's probably not that either.

[Badwolf]

My main Falcon with DFB1 disabled. 14MB ST-RAM.

My normal IDE drive attached and a dedicated 128MB SCSI partition attached via BlueSCSI.

Booting with HDDriver 11.14, holding down CTRL.

Copying IDE to SCSI throughout.

Half megabyte TENTACLE.PRG copies quickly and fine (tested with diff).

2.5MB FUSE.TTP copies quickly and fine.

12MB TENTACLE.ST1 times out with 'Your output device is not receiving data'.

Try again copying from EMUCON2.TOS (run from TOS4.04) -- works and is fine.

Run EMUTOS.PRG (1.3) and try copying TENTACLE.ST1 again: system hangs!

Very interesting!

I wonder if I can replicate this in Hatari and with the latest EmuTOS. Since we can establish how that works, we may get a hint of what's occurring.

BW

[exxos]

@Badwolf Jookie has been doing his tests in Hatari and no problems..
He was saying this bug should be included in Hatari... But we don't know what the bug is..

So EMUCON2.TOS works?? I've never used it. Maybe it's running less than full blown TOS? no idea.. Smaller scsi block sizes?

I ran the latest EMUTOS. PRG already a couple days ago.. It trashed the partiton but file copies completed. TOS just hangs on copying.

I have noticed my ezdrive LED flashes write then stays on solid write... Assume that's when it hangs.

Also I'm glad someone else has this problem not just me!

[Badwolf]

So EMUCON2.TOS works?? I've never used it. Maybe it's running less than full blown TOS? no idea.. Smaller scsi block sizes?

With EMUCON I see lots of short flashes on both drives as the copy completes. Suggesting it's got its own copy routine that's using small chunks.

Under TOS the IDE (source) activity light comes on solidly and stays on until timeout.

BW

[exxos]

Under TOS the IDE (source) activity light comes on solidly and stays on until timeout.

I don't see that. My IDE light says on for a couple seconds then goes off and then the SCSI write starts..

I assume the read from IDE to ram works fine.

[stephen_usher]

So, that suggests that it's an issue with the size of the DMA transfer rather than location.

I must admit that doing such large transfers is unusual for most systems which use SCSI. Usually it's based upon the block size (usually 512 bytes) and many UNIX systems use 4K or 8K transfers.

Of course, the NCR5380, being a SCSI1 controller, doesn't have the ability to do command queuing, so that's a performance hit. Maybe that's why Atari drivers push the envelope with such large transfers.

[exxos]

I wonder what Atari did in AHDI in terms of chuck sizes..

Did see this...

. There seems to be a nasty bug in some SCSI-DMA/NCR
* combinations: If a target disconnects while a write
* operation is going on, the address register of the
* DMA may be a few bytes farer than it actually read.
* This is probably due to DMA prefetching and a delay
* between DMA and NCR. Experiments showed that the
* dma_addr is 9 bytes to high, but this could vary.
* The problem is, that the residual is thus calculated
* wrong and the next transfer will start behind where
* it should. So we round up the residual to the next
* multiple of a sector size, if it isn't already a
* multiple and the originally expected transfer size
* was. The latter condition is there to ensure that
* the correction is taken only for "real" data
* transfers and not for, e.g., the parameters of some
* other command. These shouldn't disconnect anyway.

https://codebrowser.dev/linux/linux/dri ... hatgpt.com

[SteveBagley]

I wonder what Atari did in AHDI in terms of chuck sizes..

There's a hard limit in the code (DRIVER.S) of 16383 sectors (so just under 8MB)

Code: Select all

        tst.b   _spscsixst              ; if so, talking Sparrow SCSI?
        beq     scrw0                   ; if not, it's regular SCSI
                                        ; else, it's Sparrow SCSI
        cmp.l   #MAXSPSECTS,d2          ; more than one DMAful?
        bls.s   acrw1                   ; if not, go check boundary
        move.l  #MAXSPSECTS,d2          ; else set count to r/w only 1 DMAful
        bra.s   acrw1

More interestingly, is this comment:

Code: Select all

; 12-Feb-1992   ml 5.0c Modified _do_rw() to use the 14-bit counter on the
;                       ACSI DMA chip of the Sparrow.

which more or less confirms there's an 8MB DMA limit. Interestingly, the ST is limited to 128KB transfers according to the same source. If more than 8MB (128KB on the ST) is requested for transfer then the transfer is split into multiple DMA requests.

Steve

[kohli79]

I did a little testing.

Standard Falcon with 14MB + driver 12.71.
Everything copied with Kobold 3.5.
‘Fast-SCSI’ enabled in HDDRUTIL.APP.

Can you install 12.53 just to make sure something else isn't in the mix..

Note it needs to be installed as dont think just running driver works..

Clean boot... Use TOS copying..

Copying with TOS was only possible with driver 12.71 and "Fast SCSI" disabled. Otherwise, only the window is visible and nothing else happens. However, the mouse can still be moved.
The HDD LED may light up for about 5 seconds at the beginning and then remain off permanently.

[dml]

I just came here for my DMAful.

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.

Aside from AHDI, is it only HDDriver & EmuTOS affected, or not known yet?