Re: cbmlink with 3032/3040 pair

From: Steve Gray <sjgray_at_rogers.com>
Date: Mon, 5 Mar 2018 21:28:30 +0000 (UTC)
Message-ID: <1356646168.8623369.1520285310493@mail.yahoo.com>
Does the directory change when you validate the disk? If so it could just mean that the disk contents are still in the buffer. If you initialize rather than validate what does it do?
Just a comment: I think this is the first time I've seen talk of cbmlink. I didn't think anyone actually used it. I used it in 2006/7-ish when I first got back into cbm equipment, but zoomfloppy came out shortly after with IEEE support and I kinda forgot about it. Actually I had added cbmlink support into my CBMxfer (CBM-Transfer) but no one ever emailed me that they actually used it.... oh well.
Steve

      From: Francesco Messineo <francesco.messineo@gmail.com>
 To: cbm-hackers@musoftware.de 
 Sent: Monday, March 5, 2018 3:33 PM
 Subject: Re: cbmlink with 3032/3040 pair
   
On Mon, Mar 5, 2018 at 8:56 PM,  <silverdr@wfmh.org.pl> wrote:
>
>> On 2018-03-05, at 14:14, Francesco Messineo <francesco.messineo@gmail.com> wrote:
>>
>> This is usually not a big problem, but the disk needs a VALIDATE
>> command after it has been transferred.
>> Does anyone understand why it happens?
>
> DOS differences? DOS differs between the two. My guess is that 1541 shows static data stored in the directory sector, while the other one uses actual sector's metadata.

I don't get what you mean. A disk transferred to a 1541 ends up with
18,0 "overwritten" by the .d64 18,0 sector, while when transferring to
a 3040 (DOS 2, so actually 4040) the 18,0 sector on disk remains the
same as it was originally formatted, so it shows always 664 blocks
free until I issue a VALIDATE to that disk. It looks like the 3040
doesn't actually overwrite the 18,0 sector, which seems odd to me. I
tend to think there's a difference in the PET 3000 cbmlink "server"
code maybe.

Frank

      Message was sent through the cbm-hackers mailing list


   

       Message was sent through the cbm-hackers mailing list
Received on 2018-03-05 23:06:14

Archive generated by hypermail 2.2.0.