cbmlink with 3032/3040 pair

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

cbmlink with 3032/3040 pair

Francesco Messineo
Hi all,
I don't know how large is the cbmlink userbase. It's my preferred mode
for CBM<->restoftheworld file transfers, since I still resist in using
SD-based disk emulators.
I use a parallel port "PC64" interface (painfully slow, but I can do
other things while I wait). Now, this setup works well with C64/1541
pair, in the sense that when I transfer a .d64 image to a real floppy,
it's written completely, including disk name, disk-id and BAM (all of
them live in 18,0).
The same setup on a 3032/3040 pair has one slight issue: original disk
name, disk id and BAM remain untouched when I transfer a .d64 image to
real floppy disk.
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?
Frank IZ8DWF

       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|

Re: cbmlink with 3032/3040 pair

silverdr@wfmh.org.pl

> On 2018-03-05, at 14:14, Francesco Messineo <[hidden email]> 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.

--
SD! - http://e4aws.silverdr.com/


       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|

Re: cbmlink with 3032/3040 pair

Francesco Messineo
On Mon, Mar 5, 2018 at 8:56 PM,  <[hidden email]> wrote:
>
>> On 2018-03-05, at 14:14, Francesco Messineo <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: cbmlink with 3032/3040 pair

silverdr@wfmh.org.pl

> On 2018-03-05, at 21:32, Francesco Messineo <[hidden email]> wrote:
>
> On Mon, Mar 5, 2018 at 8:56 PM,  <[hidden email]> wrote:
>>
>>> On 2018-03-05, at 14:14, Francesco Messineo <[hidden email]> 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.

--
SD! - http://e4aws.silverdr.com/


       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|

Re: cbmlink with 3032/3040 pair

Francesco Messineo
On Mon, Mar 5, 2018 at 9:47 PM,  <[hidden email]> wrote:

>
>> On 2018-03-05, at 21:32, Francesco Messineo <[hidden email]> wrote:
>>
>> On Mon, Mar 5, 2018 at 8:56 PM,  <[hidden email]> wrote:
>>>
>>>> On 2018-03-05, at 14:14, Francesco Messineo <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: cbmlink with 3032/3040 pair

silverdr@wfmh.org.pl

> On 2018-03-05, at 22:07, Francesco Messineo <[hidden email]> 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:

http://e4aws.silverdr.com/project64/incdos/

Section 3.3

--
SD! - http://e4aws.silverdr.com/


       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|

Re: cbmlink with 3032/3040 pair

Spiro Trikaliotis
In reply to this post by Francesco Messineo
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.

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. ;)


> 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.

Regards,
Spiro.

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

       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|

Re: cbmlink with 3032/3040 pair

Francesco Messineo
In reply to this post by silverdr@wfmh.org.pl
On Mon, Mar 5, 2018 at 10:14 PM,  <[hidden email]> wrote:

>
>> On 2018-03-05, at 22:07, Francesco Messineo <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: cbmlink with 3032/3040 pair

Steve Gray
In reply to this post by Francesco Messineo
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 <[hidden email]>
To: [hidden email]
Sent: Monday, March 5, 2018 3:33 PM
Subject: Re: cbmlink with 3032/3040 pair

On Mon, Mar 5, 2018 at 8:56 PM,  <[hidden email]> wrote:
>
>> On 2018-03-05, at 14:14, Francesco Messineo <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|

Re: cbmlink with 3032/3040 pair

silverdr@wfmh.org.pl
In reply to this post by Francesco Messineo

> On 2018-03-05, at 22:21, Francesco Messineo <[hidden email]> wrote:
>
>>> 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.

I am still unconvinced/unsure whether it "doesn't write anything" or writes only the high-level data in a 1541 style, which is kind-of-fine[*] for 1541 but not enough for 4040.

>> http://e4aws.silverdr.com/project64/incdos/
>>
>> Section 3.3

* - it actually may cause unnoticed discrepancies for example between the visible and the actual ID.

--
SD! - http://e4aws.silverdr.com/


       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|

Re: cbmlink with 3032/3040 pair

Francesco Messineo
In reply to this post by Spiro Trikaliotis
On Mon, Mar 5, 2018 at 10:19 PM, Spiro Trikaliotis
<[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: cbmlink with 3032/3040 pair

silverdr@wfmh.org.pl
In reply to this post by silverdr@wfmh.org.pl

> On 2018-03-05, at 22:28, [hidden email] wrote:
>
> I am still unconvinced/unsure whether it "doesn't write anything" or writes only the high-level data in a 1541 style, which is kind-of-fine[*] for 1541 but not enough for 4040.

Or - as Spiro suggested - it doesn't write due to DOS mark mismatch.

>
>>> http://e4aws.silverdr.com/project64/incdos/
>>>
>>> Section 3.3
>
> * - it actually may cause unnoticed discrepancies for example between the visible and the actual ID.
>
> --
> SD! - http://e4aws.silverdr.com/
>

--
SD! - http://e4aws.silverdr.com/


       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|

Re: cbmlink with 3032/3040 pair

Francesco Messineo
In reply to this post by Steve Gray
On Mon, Mar 5, 2018 at 10:28 PM, Steve Gray <[hidden email]> wrote:
> 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?

No directory doesn't change, it looks right from the start after the
image is completed.
I can also remove the disk and validate it the next day, then it shows
the correct free blocks.
As I said, it seems the sector 18,0 is never written to the disk.

>
> 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.

a PC64 cable is far too simple than any other method. It's just slow...

> Steve
>
>
> ________________________________
> From: Francesco Messineo <[hidden email]>
> To: [hidden email]
> Sent: Monday, March 5, 2018 3:33 PM
> Subject: Re: cbmlink with 3032/3040 pair
>
> On Mon, Mar 5, 2018 at 8:56 PM,  <[hidden email]> wrote:
>>
>>> On 2018-03-05, at 14:14, Francesco Messineo
>>> <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: cbmlink with 3032/3040 pair

André Fachat
In reply to this post by Francesco Messineo
I "invented" the the d67 format in Vice to store DOS 1 images with 670
blocks free analogous   to th d64 image if that is the change you refer to.
The d67 disks have one more sector per track in one of the speed zones.

André


Am 5. März 2018 22:07:14 schrieb Francesco Messineo
<[hidden email]>:

> On Mon, Mar 5, 2018 at 9:47 PM,  <[hidden email]> wrote:
>>
>>> On 2018-03-05, at 21:32, Francesco Messineo <[hidden email]>
>>> wrote:
>>>
>>> On Mon, Mar 5, 2018 at 8:56 PM,  <[hidden email]> wrote:
>>>>
>>>>> On 2018-03-05, at 14:14, Francesco Messineo <[hidden email]>
>>>>> 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



       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|

Re: cbmlink with 3032/3040 pair

Francesco Messineo
On Mon, Mar 5, 2018 at 11:01 PM, And Fachat <[hidden email]> wrote:
> I "invented" the the d67 format in Vice to store DOS 1 images with 670
> blocks free analogous   to th d64 image if that is the change you refer to.

> Regards,

>        Message was sent through the cbm-hackers mailing list
> The d67 disks have one more sector per track in one of the speed zones.

nope, I'm writing .d64 images to a DOS-2 3040 (effectively a 4040), so
the image is correct for the DOS version I have on my drive.

>
> André
>
>
> Am 5. März 2018 22:07:14 schrieb Francesco Messineo
> <[hidden email]>:
>
>> On Mon, Mar 5, 2018 at 9:47 PM,  <[hidden email]> wrote:
>>>
>>>
>>>> On 2018-03-05, at 21:32, Francesco Messineo
>>>> <[hidden email]> wrote:
>>>>
>>>> On Mon, Mar 5, 2018 at 8:56 PM,  <[hidden email]> wrote:
>>>>>
>>>>>
>>>>>> On 2018-03-05, at 14:14, Francesco Messineo
>>>>>> <[hidden email]> 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
>
>
>
>
>       Message was sent through the cbm-hackers mailing list

       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|

Re: cbmlink with 3032/3040 pair

MiaM
In reply to this post by Francesco Messineo
Den Mon, 5 Mar 2018 22:33:27 +0100 skrev Francesco Messineo
<[hidden email]>:

> On Mon, Mar 5, 2018 at 10:28 PM, Steve Gray <[hidden email]> wrote:
> > 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?
>
> No directory doesn't change, it looks right from the start after the
> image is completed.
> I can also remove the disk and validate it the next day, then it shows
> the correct free blocks.
> As I said, it seems the sector 18,0 is never written to the disk.

Are there any good disk editors available for PET? I know that there
were some available even back in mid 80's for C64+1541, but don't know
about the PET.

> > 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.

I googled a bit and this file seems to have some character encoding
problem. I'm sure Marko doesn't spell his name with some strange
non-letter characters :)

http://www.zimmers.net/anonftp/pub/cbm/crossplatform/transfer/C2N232/cbmlink.html

> a PC64 cable is far too simple than any other method. It's just
> slow...

PC64 seems to be a semi usable thing, might make one :)

--
(\_/) Copy the bunny to your mails to help
(O.o) him achieve world domination.
(> <) Come join the dark side.
/_|_\ We have cookies.

       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|

Re: cbmlink with 3032/3040 pair

Francesco Messineo
On Tue, Mar 6, 2018 at 9:13 PM, Mia Magnusson <[hidden email]> wrote:

> Den Mon, 5 Mar 2018 22:33:27 +0100 skrev Francesco Messineo
> <[hidden email]>:
>> On Mon, Mar 5, 2018 at 10:28 PM, Steve Gray <[hidden email]> wrote:
>> > 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?
>>
>> No directory doesn't change, it looks right from the start after the
>> image is completed.
>> I can also remove the disk and validate it the next day, then it shows
>> the correct free blocks.
>> As I said, it seems the sector 18,0 is never written to the disk.
>
> Are there any good disk editors available for PET? I know that there
> were some available even back in mid 80's for C64+1541, but don't know
> about the PET.
>

I don't know, but sometimes in 1986 I wrote my own disk editor for the
C64, so I guess I could do it on a PET too :)


>
>> a PC64 cable is far too simple than any other method. It's just
>> slow...
>
> PC64 seems to be a semi usable thing, might make one :)

I'm very happy with it. I can use the same cable on C64, VIC-20 and the PETs.
Each of them just needs its own version of the "server" program, but
the linux client is always the same.

Frank

       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|

Re: cbmlink with 3032/3040 pair

silverdr@wfmh.org.pl
In reply to this post by MiaM

> On 2018-03-06, at 21:13, Mia Magnusson <[hidden email]> wrote:
>
> I googled a bit and this file seems to have some character encoding
> problem. I'm sure Marko doesn't spell his name with some strange
> non-letter characters :)
>
> http://www.zimmers.net/anonftp/pub/cbm/crossplatform/transfer/C2N232/cbmlink.html

Those FUNET files come from the times before encoding support matured, let alone UTF-8 became standard. Set your browser manually to ISO-8859-1 to see Marko's surname the way it should look ;-)

--
SD! - http://e4aws.silverdr.com/


       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|

Re: cbmlink with 3032/3040 pair

silverdr@wfmh.org.pl

> On 2018-03-07, at 12:29, [hidden email] wrote:
>
>
>> On 2018-03-06, at 21:13, Mia Magnusson <[hidden email]> wrote:
>>
>> I googled a bit and this file seems to have some character encoding
>> problem. I'm sure Marko doesn't spell his name with some strange
>> non-letter characters :)
>>
>> http://www.zimmers.net/anonftp/pub/cbm/crossplatform/transfer/C2N232/cbmlink.html
>
> Those FUNET files come from the times before encoding support matured, let alone UTF-8 became standard. Set your browser manually to ISO-8859-1 to see Marko's surname the way it should look ;-)

OTOH - I just checked the file and it looks all correct to me. It's the server that sends incorrect Content-Type charset. Time to tell Bo, I guess ;-)

--
SD! - http://e4aws.silverdr.com/


       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|

Re: cbmlink with 3032/3040 pair

Spiro Trikaliotis
In reply to this post by silverdr@wfmh.org.pl
Hello,

* On Mon, Mar 05, 2018 at 10:28:41PM +0100 [hidden email] wrote:
 
> I am still unconvinced/unsure whether it "doesn't write anything" or
> writes only the high-level data in a 1541 style, which is
> kind-of-fine[*] for 1541 but not enough for 4040.

A way to check it:

1. Write an image "a.d64" to the disk
2. Read back that image into a file "b.d64"
3. Remove the disk from the drive, switch off the drive, switch it on
   again, insert the disk again into the drive
4. Read back that image into a file "c.d64"
5. Validate the disk
6. Read back that image int a file "d.d64"
7. Compare a.d64, b.d64, c.d64 and d.d64

This might give us a hint what went wrong.

Regards,
Spiro.

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

       Message was sent through the cbm-hackers mailing list
12