Re: cbmlink with 3032/3040 pair

On Mon, Mar 5, 2018 at 10:19 PM, Spiro Trikaliotis
<ml-cbmhackers@trikaliotis.net> wrote:
> Hello,
>
> * On Mon, Mar 05, 2018 at 10:07:08PM +0100 Francesco Messineo wrote:
>
>> > 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.
>
> What is the "format byte" of the IEEE drive? The 3rd byte (0x02) of
> sector 18/0 contains it. On a 1541 disk, it is 0x41 ("A").
>
> You can also see it in the directory listing of a disk: If the disk was
> formatted with the ID 98, then you have the ending "98 2A" on the title
> of a 1541 disk.

directory shows 2A on the 3040 too (it's actually upgraded to 4040 firmware).

> Is the format byte identical between the formatted disk and the image?
> IIRC, the 1541 refuses to write on a disk if the byte is not correct,
> but my memory may be wrong. I am not sure if it refuses to write to 18/0
> only, or to any block, though, or if my memory is completely wrong. ;)

there's no 1541 involved here.
I take a .d64 image from the net with PET programs, I write to a 3032
connected to the 4040
and the resulting disk always needs a validate because after the disk
transfer, the blocks free
remains 664 (and disk name isn't changed).

When I write .d64 images (with C64 software) to a C64 connected to a
1541, then the resulting disk
has a new disk name (probably the one stored in the .d64 image) and
correct blocks free count.

I didn't try to write a PET image on a 1541, but I might try too. All
.d64 images I have, are of the same size, regardless of what they
contain.


>
>> 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.
>
> Only the *visible* cosmetical disk ID (that is seen in a dir listing) is
> changed.  The on-disk ID in the header of each sector, that is the
> important one, remains unchanged.

ok, good to know, then somehow, when writing a .d64 image to a PET,
the sector 18,0 is not really written to disk.

Frank

       Message was sent through the cbm-hackers mailing list