Re: cbmlink with 3032/3040 pair

From: Francesco Messineo <francesco.messineo_at_gmail.com>
Date: Mon, 5 Mar 2018 22:21:22 +0100
Message-ID: <CAESs-_x8VNUCajPfyC1r7UJ10ga8-rQR=Z-BbF6HBDUQKgq-OA@mail.gmail.com>
On Mon, Mar 5, 2018 at 10:14 PM,  <silverdr@wfmh.org.pl> wrote:
>
>> On 2018-03-05, at 22:07, 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.
>
> D64 is a high-level image so it doesn't contain low-level metadata. Disk ID for example is stored in sector headers during formatting, not only in directory. Actually that one, visible in the directory listing is less important ;-) To preserve the low-level metadata you'd need to use G64 rather than D64. Also have a look at:

yes, I knew about disk ID being stored in every sector's header. I
thought that the cbmlink server part could overwrite the sector
headers, but maybe it's only changing the ID stored in 18,0.
The fact that the 3040 doesn't write anything in 18,0 when used
through cbmlink is still annoying though.

>
> http://e4aws.silverdr.com/project64/incdos/
>
> Section 3.3
>
> --
> SD! - http://e4aws.silverdr.com/
>
>
>        Message was sent through the cbm-hackers mailing list

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

Archive generated by hypermail 2.2.0.