exxos blog - random goings on

[exxos]

I did a tree dump on the SD card itself. I don't really see anything odd there even in sector view.

tree.zip

So the problem has to be Atari side :roll:

I did a video of the STE deleting the files which is showing those corrupted folder names.



Considering it seems to be successfully deleting invalid folder names :shrug:

[chronicthehedgehog]

I could only get the ICD drivers to work personally even though I only tried the demo HD and PP drivers. I get similar spurious folder entries when using fat16 partitions with ICD. Kobold ignores them maybe pp does also

[exxos]

I could only get the ICD drivers to work personally even though I only tried the demo HD and PP drivers. I get similar spurious folder entries when using fat16 partitions with ICD. Kobold ignores them maybe pp does also

That is interesting then. Not just me that is having this problem.

What STE do you have exactly ? Do you know the DMA number ? Internal/external blitter ? Early bodge STE board or later one ?

I guess I could start over and try a TOS only partition. Not many options left now :(

[chronicthehedgehog]

On hols at the mo and can't remember the specifics but it has a 001 'good' DMA. Perhaps it's a late revision as it also has an Ajax FDD controller. I honestly can't remember if it's internal or external blitter but my hunch is internal

[stephen_usher]

Those spurious folder names would be corrupted FAT directory entry. This could happen if the seek command is buggy or there's a timing issue when reading the command on the bus so that it's not reading the parameters correctly. The FAT reading takes a lot of seeks to/from the start of the drive. It could be reading too early or too late and the data on the bus is not consistant.

[exxos]

I started again and repartitioned the SD card to TOS only. Copied files from my test floppy to C: then copied all those folders on C: back to C: under new folder names etc. Basically filled up a 220MB partition. Ends up around 7,000 files and 4,000 folders or thereabouts. Long story short it still crashed about halfway with 3,500 files to go. I did these tests with ultrasatan just to rule out again that the Pico drive was not a factor in it all.

While I was copying files to the C: drive etc I did spend a fair bit of time watching the filenames and did not see anything out of the ordinary while copying. so the problem only seems to manifest itself during deleting files.

I guess I could run EMUTOS.PRG and rule out a TOS problem. Though I have a feeling this is just going to end up being another stupid DMA problem :roll: My only other course of action is to remove the "Good DMA" and put a -38 in the STE and see if anything changes.

[exxos]

Grabbed the latest EMUTOS and didn't get very far :( @czietz ?

IMG_0961.JPG

Have half wondered if it was the number of directories problem but I only believed that was in like TOS104 era. I assume with TOS206 all that old chaos was fixed. :shrug: Though I don't exactly have a massive amount of directories within directories anyway. From what I can tell I am going about eight directories deep.

[exxos]

I tried TOS206 again and it crashed a lot quicker this time. Got no where near half way. So I assume this is going to be some hardware problem now :(

IMG_0962.JPG

IMG_0963.JPG

I think the next course of action is to put a socket in the STE and try the -38 DMA and see if anything changes.

[stephen_usher]

Looks like the FAT filesystem is being corrupted which is then causing the system to crash when it reads a nonsensical entry.

This feels like a timing issue in the firmware of the device which is marginal and happens to just work on most machines by accident.

[exxos]

This feels like a timing issue in the firmware of the device which is marginal and happens to just work on most machines by accident.

It's the same with the PICO and Ultrasatan. My only other option is to try a spinning metal drive. Though I am not sure how big those drives are for a fair test. But with those drives being slower, it may not be a fair test anyway.