Re: cbmlink with 3032/3040 pair

From: Francesco Messineo <francesco.messineo_at_gmail.com>
Date: Mon, 5 Mar 2018 22:07:08 +0100
Message-ID: <CAESs-_yfjr474=-XmBfcwKkXuSk3Q=10-he6vDzqu+AUViaQaA@mail.gmail.com>
On Mon, Mar 5, 2018 at 9:47 PM,  <silverdr@wfmh.org.pl> wrote:
>
>> On 2018-03-05, at 21:32, Francesco Messineo <francesco.messineo@gmail.com> wrote:
>>
>> 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.
>
> I would have to check exactly what the differences are but there are other people who I bet have them in their heads ;-) while I vaguely recall that the DOS 2.6 in 1541 is not the same as DOS 2.x in other drives. This means there may be nuance differences, and if you write a D64 (from a 1541 disk?) to another drive using DOS 2.x things like you describe may show. Once you re-VALIDATE, the drive updates the metadata to what it expects, rather than what 1541 would expect.

I would expect that cbmlink just writes sectors, starting from 1,0 and
ending to 35,16. I don't think it even knows about directory, BAM and
so on. On a 1541, even disk id (the two characters you give at format
time) gets changed from the .d64 image. On a 3040 they don't.
I don't know how much "metadata" is present on a .d64 image though.
F

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

Archive generated by hypermail 2.2.0.