Falcon SCSI write issues

[stephen_usher]

Or an internal hardware counter goes screwy when the 23rd address line gets used?

Remember that the Falcon was rushed out the door so I imagine that not all the bugs were found or fixed in the silicon.

I wonder if there are any clues in the Linux m68k kernel, 'cos I guess that supports more than 4MB of RAM and SCSI.

[exxos]

Or an internal hardware counter goes screwy when the 23rd address line gets used?

Remember that the Falcon was rushed out the door so I imagine that not all the bugs were found or fixed in the silicon.

I wonder if there are any clues in the Linux m68k kernel, 'cos I guess that supports more than 4MB of RAM and SCSI.

There was some Linux chatter I saw earlier but was a bit hard to follow.. But one site did hint at a driver update because of large file transfer errors.. But I can't conclusively prove that.

If jookies test program stops dead at like a 4mb mark then it's likely a design flaw I mean did Atari copy/paste some stuff from the ST series of logic and forgot to update it for more RAM.. Hope I'm wrong as that wouldn't be fixable..

I wonder. If there's a falcon ram disk I can create a 4mb drive, really just to eat up 4mb of RAM.. then try hd12.71 to see if it still works.. It should prove if there's a hard DMA limit..

[stephen_usher]

Of course the best way would be to write a test program which accessed the hardware directly doing raw writes to the SCSI device and then raw reads. You don't have the OS and driver getting in the way possibly interfering with your experiment and reading and writing from the FAT as you're writing to the file.

[exxos]

Of course the best way would be to write a test program which accessed the hardware directly doing raw writes to the SCSI device and then raw reads. You don't have the OS and driver getting in the way possibly interfering with your experiment and reading and writing from the FAT as you're writing to the file.

That's what jookies program does. He just sent it to me and I quickly tested and sent him the results.. So far 3MB passes and 4mb+ fails.

I have to go out now so can't so anymore tests until I get back home.

[Steve]

Are we saying that in 30 odd years, Uwe Siemet hasn't noticed such a fundamental flaw in the Falcon SCSI system. Also in a similar amount of years, the EmuTOS team also hasn't, and perhaps the Hatari team? I just find it hard to believe. (Don't get me wrong, I'm not saying this problem doesn't exist, the whole situation just beggars belief)

[Badwolf]

I wonder. If there's a falcon ram disk I can create a 4mb drive, really just to eat up 4mb of RAM.. then try hd12.71 to see if it still works.. It should prove if there's a hard DMA limit..

Here's a small program that does nothing but steal ST-RAM from your system starting as low as possible in memory.

By default it'll take the lowest 4MB it can, but you can configure how much to steal by giving it a (decimal) number on the TTP command line.

membgone.zip

(7.96 KiB) Downloaded 7 times

It works by allocating as many blocks of your requested size (eg. 4MB) as possible in the memory available, then freeing all but the lowest one and exiting. It does it like this to avoid any assumptions about the order of allocation by whatever OS's malloc() tool is in use but it has a weakness that if, for some reason, blocks are allocated from the top to the bottom and there's not a nice integer number of blocks that can fit in the memory available, there will be up to one block size of gap at the bottom of available ST-RAM. This is very much a conceptual problem, however as on a clean machine under TOS4, I think it allocates upwards. I spent too much time thinking about this, really...

Anyway, long story short, run it without any parameters and you'll have 4MB less. Almost certainly at the bottom of RAM. Run it again, it's 8MB gone. etc. You can verify this under 'Desktop Configuration'.

BW

[mikro]

Are we saying that in 30 odd years, Uwe Siemet hasn't noticed such a fundamental flaw in the Falcon SCSI system. Also in a similar amount of years, the EmuTOS team also hasn't, and perhaps the Hatari team? I just find it hard to believe.

I'm equally sceptical. This issue needs more testers. @whomper, @kohli79 and @don_apple reported their experience here: viewtopic.php?p=134323#p134323 but it's all bogus because they used HDDriver 12.71 without the "Fast SCSI" option enabled, therefore limiting the transfer buffer to 64 KiB.

[stephen_usher]

The question is, how many Falcon owners have used SCSI for storage other than CDROMs?

Given that the main storage for the Falcon is the IDE drive I somewhat doubt there's a very large number of people trying to use SCSI storage as (a) the number of Falcons is small, (b) most were for music composition where the storage of MIDI data would be easily held on the internal IDE drive. So, probably a vanishingly small number.

[mikro]

The question is, how many Falcon owners have used SCSI for storage other than CDROMs?

Given that the main storage for the Falcon is the IDE drive I somewhat doubt there's a very large number of people trying to use SCSI storage as (a) the number of Falcons is small, (b) most were for music composition where the storage of MIDI data would be easily held on the internal IDE drive. So, probably a vanishingly small number.

I have to disagree. Just recently I have inherited a musician's Falcon and got a heap of SCSI ZIP disk media full of files with tens of MB each.

[exxos]

Here's a small program that does nothing but steal ST-RAM from your system starting as low as possible in memory.

Awesome!
Will test it when I get home later.