exxos's Atari, Amiga & retro forum

I've been trying some filecopies. It seems to be linked to multiple file writes causing the problem. For example , I can generally copy several small files about in one go just fine. I can copy larger files like 300k just fine. But if I create several folders on a floppy then copy those the C: I can pretty much guarantee it will fail. Something is happening to fast. Which is agrivated by the booster.

During booster development I had issues with ultrasatan and I slowed down the busgrant stuff to solve it. But I'm now thinking it's the same problem as we are seeing now. I think ultrasatan is borderline with some timing somewhere.

At this point it's only speculation. But obviously something is tripping up somewhere.

It sounds like this has got to the point of really needing dedicated test software.

Write a controlled set of data and read back several times, kind of thing.

Vary what and how things are written.

Once I hear behaviour is different depending on the filesystem structure, I worry there are too many variables in the chain.

BW

@Badwolf we been using jookies DMA test program. It seems to write the first sector fine then dies.

It seems just 2 buffers on the 8mhz clock to the CPU is enough to cause the problem. It's only 6ns. Something is tripping up somewhere.

exxos wrote: 17 May 2023 17:26 It seems just 2 buffers on the 8mhz clock to the CPU is enough to cause the problem. It's only 6ns. Something is tripping up somewhere.

Have I read that correctly?

=> If the CPU runs ~6ns behind the rest of the system (ie, a slight clock skew), you get DMA grief?

BW

Badwolf wrote: 17 May 2023 20:34 => If the CPU runs ~6ns behind the rest of the system (ie, a slight clock skew), you get DMA grief?

So it seems. As impossible as it sounds.

I've been out all day so not done anything on the STE.

For the hell of it I just started doing sector test and it is passing..

So there must be some thermal aspect going on as well somewhere.

EDIT:

Heated up all the main chips and still passing :WTF:

EDIT2:

So started to copy my files to C: from floppy and failed as expected again. Madness.

Some more tests.

Copying several small files around 300bytes each all at once passes.

Copying HDDURIL.APP (about 305KB) copies fine - checked loads and works fine.

Copied a folder with 3 empty folders insdes, copied fine. ( however this test failed yesterday)

Copied FIXES folder and files from HD11 folders.. copied fine.

Copied 24 files with 11 folders.. died after copying HDDUTIL.APP. (GEM says it copied 9 files and 6 folders) doing info on the folder after.

Copying a folder with 12 empty folders - only copied 3 and locked up.

Deleting 19 files 21 folders - died after several deletes.

Its like fast FAT access causes the corruption :shrug:

Problem with seek commands being missed?

exxos wrote: 17 May 2023 21:02 Its like fast FAT access causes the corruption :shrug:

Which sounds logical (software) rather than physical (hardware), as why would the hardware care?

Which is why I was thinking a dedicated (non-driver, non-filesystem, non-vectored) test program that can manifest it is needed.

viewtopic.php?f=25&t=43 <-- this is the one you've been using, correct? Can you reliably get this to fail?

BW

Badwolf wrote: 17 May 2023 21:28 Which sounds logical (software) rather than physical (hardware), as why would the hardware care?

That's the problem as well. Because ultrasatan (two different variants of it) work fine and also they old spinning metal drive works fine. Plug in the Pico drive and it will fail. So you think it is the driver at fault ? but how ?

viewtopic.php?f=25&t=43 <-- this is the one you've been using, correct? Can you reliably get this to fail?

That is the one I have been using. It did reliably fail up until today.

Which is why I was thinking a dedicated (non-driver, non-filesystem, non-vectored) test program that can manifest it is needed.

Yes but other than file copies does not seem to be any programs to specifically test this problem.

Ordinarily this would tally with the whole "Bad DMA" thing. I am using the -38 DMA. But as said previously the allegedly "GOOD DMA" actually makes the problems worse.