Re: 1581 loosing data

From: Spiro Trikaliotis (ml-cbmhackers_at_trikaliotis.net)
Date: 2006-04-05 18:29:02

Hello,

I am answering to all mails in one. First of all, thank you all for your
feedback.

* On Wed, Mar 29, 2006 at 02:54:29PM +0200 Nicolas Welte wrote:
 
> > I know the 1581 is known to loose data in some ROM versions. Anyway, I
> > did not find any details in how this can happen.
> 
> Did you compare the two ROM versions that exist? IIRC, they differ
> only by a single SEI command, that was missing in the original
> version. Plus a few patches to make space for this single missing
> byte.

Yes, you are right:

         318045-1                     318045-2
$AF38:   $3A                          $00
$C160:   $6C $48 $00  JMP ($0048)     $4C $AF $C5  JMP $C5AF
$C5AF:   $FF          - unused -      $78          STI
$C5B0:   $FF $FF $FF  - unused -      $6C $48 $00  JMP ($0048)

The differences to the "BETA ROM" (as it is called on Funet) are
somewhat bigger than this.

And: Yes, the drive has a 318045-1 ROM.

> I doubt you can assign a specific problem like yours to *this* bug.
> I'd rather expect that it makes the drive behave unreliably in some
> (rare?) circumstances only.

Yes, it seems so. Anyway, this tells me that my bug might be related to
this.


* On Wed, Mar 29, 2006 at 03:26:29PM +0200 Joel Ricci wrote:

> Yes, the original 1581 kernel has some serious bugs that can cause
> data loss. I don't remember exactly, but I think it's file
> fragmentation related, so you should Validate the disc OFTEN to avoid
> these problems, especially if you have a lot of (small) files on the
> disc or/and you are writing/rewriting files frequently. Or better up -
> get JiffyDOS for your 1581. It has all the nasty bugs sorted out.

Too bad no-one can contribute more details to this.


* On Wed, Mar 29, 2006 at 08:43:19PM +0200 Ulf Diabelez Harries wrote:

> I just did a quick test, well as quick as the 1581 will allow me
> anyways ;-)

Thank you for your time!

> I created a disk with 52 files of 60 blocks each leaving 40 blocks
> free.  Then I wrote the last 60 block file resulting in the open file
> of 0 blocks.
> After I did the validation, only the last file was removed. So in
> other words, it seems to work as expected for me.

Ok, this is my error. I should have noted that the above behaviour
occured while doing some automated test.

Most of the time, everything worked fine, and I was seeing exactly what
I expected to see. Anyway, after some rounds (> 30), the above
surprising behaviour occurred.

As this automated test just did the same series of commands one after
the other, I was very surprised.

> The details:
[...]
>   30 PRINT #15,"C:FILE"I"=FILE 0 "
> 
> RUN'ing that took about an hour I guess ;-)

Yes, the 1581 is extremely slow with the COPY (C:) command; it seems it
always copies just one block from track to track, resulting in very much
time spent in seeks.

Writing the files "by hand" seems to be faster than using the COPY
command. :(

 
> My personal experience with 1581 is that it quite often screws up the
> directory.

Oh, you're sure it is often the directory? This sounds exactly like what
I am experiencing. :)

 

* On Wed, Mar 29, 2006 at 11:47:47PM -0500 William Levak wrote:
> 
> I have had this problem.  It seems to lose directory sectors.
> 
> The latest revision of ROM, 318045-02, does not have this problem.

Ok. Thus, I will test upgrading my ROMs to -02.


* On Wed, Apr 05, 2006 at 01:57:31AM -0400 Greg King wrote:

> > I have had that problem.  It seems to lose directory sectors.
> >
> > The latest revision of ROM, 318045-02, does not have that problem.
> 
> Maybe, the directory's file-chain was truncated, by mistake.
> 
> Try looking at sector 40,4 ($28,$04) with a disk editor.


Ok, I have done this.

40/0 links to 40/3, whichs links to 40/4. This one contains $00/$FF as
linker, thus, the directory is broken.

I repaired the linker, pointing to 40/5, and the rest is visible again.
After validating the disc, everything is fine again, "only" one
directory block has been lost (8 files).
 
> List the directory; then, try validating again.

Yes, everything is fine again.

This was a test disc, anyway. I wanted to do an automated "stress-test"
for cbmcopy (cbm4win/cbm4linux) when I encountered that problem.

Thank god, I am convinced now that this problem is not related to
cbmcopy, but to the ROM of the 1581.

Thank you all,
   Spiro.

-- 
Spiro R. Trikaliotis
http://www.trikaliotis.net/
http://cbm4win.sf.net/

       Message was sent through the cbm-hackers mailing list

Archive generated by hypermail pre-2.1.8.