exxos's Atari, Amiga & retro forum

This arrived in the post today from Uwe:
So I'll be taking it away with me when I go away for the next few days, and fingers crossed I will return knowledgeable :)

rubber_jonnie wrote: 04 May 2019 00:05 This arrived in the post today from Uwe:

So I'll be taking it away with me when I go away for the next few days, and fingers crossed I will return knowledgeable :)

So after your trip you will be known as the exxos forum HDDriver expert. :)

rubber_jonnie wrote: 04 May 2019 00:05 So I'll be taking it away with me when I go away for the next few days, and fingers crossed I will return knowledgeable :)

:cheer: :bravo:

Icky wrote: 04 May 2019 00:07

rubber_jonnie wrote: 04 May 2019 00:05 This arrived in the post today from Uwe:

So I'll be taking it away with me when I go away for the next few days, and fingers crossed I will return knowledgeable :)

So after your trip you will be known as the exxos forum HDDriver expert. :)

Yeah, probably, that kind of thing happens to me a lot. I did a bit of stuff on Docker at work, now I'm the expert. Who knew?

Sounds familiar..... I'm the expert in many things at work due to being the only one who dare look at it.

Well, I just won the IDE ZIP drive I was bidding on, so more experimentation to come. Need to try a CDROM drive too, see what pops up 😁

Ok, my patience has been tested by IDE2.PRG beyond its breaking point. So I've been wanting to give Lattice C a test run so I have generated another Mass Storage Punisher. I have been running it on Hatari and it is significantly faster than IDE2. It also writes out a 50 mb file, reads it back and checks it. You can also instruct it to run multiple iterations by using -r<number of runs>. Also by default it removes the created test file but if you enter -k it will retain the last file created. So if you command it to run 10 times it will keep the 50 mb data file keep on the 10th or last pass. Also it quits looking for errors after 512 have been found in an iteration. This number cane changed via -e<max # errors per iteration>. There is a -b option that doesn't do anything yet. It will control the number of 4096 byte blocks that constitute a test. It is currently set to 12287 which gives you a test file of 12287 x 4096 or ~50mb. Anyway Phil its another tool you can use to break something quicker. :) :) :)

Ok, to slow to figure out how to attach a TTP file. How does one attach an executable?

You have to zip it to upload files..

BTW, there already is a faster ide test program somewhere which Samson did.. But it didn't detect the errors as good as mine, even though its the same test, just faster., i think it took like 10mins to run instead of 2 hours..

So in using other testing tools, your not actually doing tests which have been proven to work...its not just about how fast the drive can be tested, its about bus stability over the hours its running.. So in speeding up the drive testing, your actually skipping half the test.

There are no shortcuts for this, if there was, we be doing them already ;)

Not sure about all of that, its been my experience that a lot of things work flawlessly when running slowly but tend to show errors when pushed a little harder. Since I have this patience thing I'll use mine and you can use yours and we will all be happy. :) :) :) I did get to check out lattice C which appears to pretty good for its age. Its noticeably faster than MWC which did surprise me.. :o :o :o