change Diskname and ID
DerSchatten
1541 Disk Drive?
A User from the OpenCBM mailing Archiv says:
"no, you can't do this with a simple cbmctrl command. You have to
read
track 18, sector 0 which contains (among other things) the name of
the
disk, and write the block back using "B-R"/"B-W" and family, just
like
you would do it on a breadbox.
"
But how exactly?
Steve Gray
Nate Lawson
What I'd do, if it wasn't a protected original, is dump a d64 of track 18 with d64copy or nibread. Then hex-edit the sector and write it back with d64copy or nibwrite. It's so fast and you can just copy a single track with the -S/-E flags.
-Nate
Steve Gray
DerSchatten
is based on it.
On 19 Okt., 20:09, Nate Lawson <n...@root.org> wrote:
> If he's comfortable with a hex editor, he could also use cbmctrl to send the block commands.
>
> What I'd do, if it wasn't a protected original, is dump a d64 of track 18 with d64copy or nibread. Then hex-edit the sector and write it back with d64copy or nibwrite. It's so fast and you can just copy a single track with the -S/-E flags.
>
> -Nate
>
> On Oct 19, 2011, at 11:04 AM, Steve Gray wrote:
>
>
>
> > I'd recommend copying the files off the disk, reformatting with the correct ID and then copying the files back on. Unless the disk is protected.
>
> > Your other option is to run a disk editor like "disk doctor". I've used it on the pet to do exactly what you are looking for. I think there is a C64 version, but not sure. There must be a dedicated tool to rename the disk as well, perhaps on the testdemo disk.
>
> > Steve
>
> > To: ZoomFloppy Users <zoomflop...@googlegroups.com>
> > Sent: Wednesday, October 19, 2011 6:37:44 AM
> > Subject: change Diskname and ID
>
> > Does anyone a Idee to change the Disk-Name and ID via cbmctrl on a
> > 1541 Disk Drive?
> > A User from the OpenCBM mailing Archiv says:
>
> > "no, you can't do this with a simple cbmctrl command. You have to
> > read
> > track 18, sector 0 which contains (among other things) the name of
> > the
> > disk, and write the block back using "B-R"/"B-W" and family, just
> > like
> > you would do it on a breadbox.
> > "
>
>
> - Zitierten Text anzeigen -
Jim Brain
> Is it not possible only from Command Line? I've programmed a GUI there
> is based on it.
PC/Mac/Linux/etc.
OpenCBM is the utilities that use the device driver
Thus, the most appropriate forum for this request (which does not exist
in a simple way in the current opencbm tooling) would be the opencbm
mailing list.
Jim
Spiro Trikaliotis
* On Wed, Oct 19, 2011 at 11:30:37AM -0700 DerSchatten wrote:
> Is it not possible only from Command Line? I've programmed a GUI there
> is based on it.
In principle, this can very easily be added to cbmctrl (or to a
standalone program). With testing, it should not take more than one
hour.
Unfortunately, I do not have any CBM equipment available ATM, so I
cannot do it. If there is interest, I could write the code, but someone
else would have to test it thoroughly!
But, as Jim already pointed out, this belongs to a OpenCBM mailing list
rather than here.
Regards,
Spiro.
--
Spiro R. Trikaliotis http://opencbm.sf.net/
http://www.trikaliotis.net/ http://www.viceteam.org/
DerSchatten
myself. I know that I am probably wrong here but no one from the
OpenCBM Mailing List could help me further.
On 20 Okt., 21:28, Spiro Trikaliotis <an-zoomfloppy-
Spiro Trikaliotis
* On Fri, Oct 21, 2011 at 03:36:32AM -0700 DerSchatten wrote:
> It would be kind if you could do this for me. I could do the tests by
> myself.
Let's try to use the cbmctrl tools in a good way.
Note: Test this on a test floppy. Do not use any floppy disk that you do
not want to be damaged. I cannot guarantee that the commands are right,
but they should be.
Execute the following commands (without the "dash", that is). I assume
you are using drive 8 (otherwise, replace every "8" with the correct
device number). Also note: IT IS IMPORTANT THAT THE DRIVE/DISK IS A
1541, 1551, 1570 or 1571 type! Otherwise, you will damage the data on
the disk!
1. Lock the OpenCBM driver (only necessary for Windows and XA1541/XM1541,
but better safe than sorry):
- cbmctrl lock
2. Initialize the floppy disk, that is, make sure all data is updated:
- cbmctrl --petscii command 8 i0
3. Check the status. It should be "00, ok,00,00":
- cbmctrl status 8
4. Open the access channel for reading/writing data:
- cbmctrl --petscii open 8 2 #
5. Check the status. It should be "00, ok,00,00":
- cbmctrl status 8
6. Read in track 18/0:
- cbmctrl --petscii command 8 "u1: 2 0 18 0"
7. Check the status. It should be "00, ok,00,00":
- cbmctrl status 8
8. Position the read/write pointer ("buffer pointer") on byte 144:
- cbmctrl --petscii command 8 "b-p 2 144"
9. Overwrite the old name with 16 $A0 characters:
- cbmctrl listen 8 2
- cbmctrl --petscii put --extended %a0 %a0 %a0 %a0 %a0 %a0 %a0 %a0 %a0 %a0 %a0 %a0 %a0 %a0 %a0 %a0
- cbmctrl unlisten
10. Position the read/write pointer ("buffer pointer) on byte 144 again:
- cbmctrl --petscii command 8 "b-p 2 144"
11. Write out the new disk name:
- cbmctrl listen 8 2
- cbmctrl --petscii put "DISKNAME"
- cbmctrl unlisten
12. Position the read/write pointer on the ID of the disk:
- cbmctrl --petscii command 8 "b-p 2 162"
13. Write out the new disk ID:
- cbmctrl listen 8 2
- cbmctrl --petscii put "ID"
- cbmctrl unlisten
14. Now, write block 18/0 back to disk:
- cbmctrl --petscii command 8 "u2: 2 0 18 0"
15. Close the data channel:
- cbmctrl close 8 2
16. Unlock the OpenCBM driver:
- cbmctrl unlock
Please execute the commands one after the other for testing. If you see
any error behaviour (blinking LED), stop immediately and execute a
"cbmctrl status 8" then, and tell me what you got.
Make sure the replace "DISKNAME" and "ID" in steps 11 and 13 with the
names you want. DISKNAME is not allowed to exceed 16 chars, ID can be
anything between 2 and 5 characters (with more than 2 characters, it
will replace the " 2A" part of the directory).
> I know that I am probably wrong here but no one from the
> OpenCBM Mailing List could help me further.
Huh? When did you ask? I cannot remember such a question, and I should
know it. It is me who is running the OpenCBM ML.
HTH,
Spiro.
--
DerSchatten
Point 9:
cbmctrl says: invalid byte: %a0
On 23 Okt., 13:42, Spiro Trikaliotis <an-zoomfloppy-
Spiro Trikaliotis
* On Sun, Oct 23, 2011 at 07:29:12AM -0700 DerSchatten wrote:
> Point 9:
> cbmctrl says: invalid byte: %a0
My bad... I forgot the correct syntax.
Remove the spaces between the %a0, that is: Replace the "cbmctrl
--petscii put" with:
�- cbmctrl put --extended %a0%a0%a0%a0%a0%a0%a0%a0%a0%a0%a0%a0%a0%a0%a0%a0
(The --petscii was also superfluous, but it did not do any harm, either)
Is this better now?
Regards,
Spiro.
--
Hoffmann-Vetter, Martin
> 12. Position the read/write pointer on the ID of the disk:
> - cbmctrl --petscii command 8 "b-p 2 162"
>
> 13. Write out the new disk ID:
> - cbmctrl listen 8 2
> - cbmctrl --petscii put "ID"
> - cbmctrl unlisten
If i remember correctly, you can't change the id only on the block of track
18, sector 0 without changing the id in the header of every sectors on the
whole disc.
On each track the sectors are written with a header. The header starts with
a sync mask and some header bytes. These bytes contain the actually track
and sector number, the checksum and the two id characters bytes. When the
disk reads a sector from a track, it compares this header and if the id
bytes unequal to the ids from track 18, it triggers an error. I think this
was a "29, DISK ID MISMATCH".
Greetings
Martin
Thomas Winkler
D64COPY does write a D64 imagefile to a floppy disk without changing evrey sector ID. But directory seems to be ok after writing imagefile.
Of course, a very simple copy protection which reads "real" ID (hard-ID) does find a copy very simple. To avoid this you have to format a disk with correct hard-ID bevore writing with D64COPY.
Error "29, DISK ID MISMATCH" comes if BAM sector has another hard-ID as any other sector. The "I" command does read hard-ID into a RAM cell from DOS. Any "read sector" command compares header with this RAM cell content and produce error 29.
DerSchatten
the Prozedure works fine, without errors on a 1541-II Floppy.
But the Line "cbmctrl put --extended
%a0%a0%a0%a0%a0%a0%a0%a0%a0%a0%a0%a0%a0%a0%a0%a0" writes the Letter
a0a0a0a0a0a0a0... in the Diskname, not SPACES.
On 23 Okt., 20:36, Spiro Trikaliotis <an-zoomfloppy-
Spiro Trikaliotis
* On Mon, Oct 24, 2011 at 05:14:56PM +0200 Hoffmann-Vetter, Martin wrote:
> > 12. Position the read/write pointer on the ID of the disk:
> > - cbmctrl --petscii command 8 "b-p 2 162"
> >
> > 13. Write out the new disk ID:
> > - cbmctrl listen 8 2
> > - cbmctrl --petscii put "ID"
> > - cbmctrl unlisten
>
> If i remember correctly, you can't change the id only on the block of track
> 18, sector 0 without changing the id in the header of every sectors on the
> whole disc.
As Thomas Winkler correctly told, you are only half-right.
The "visible" ID (soft-ID, as Thomas said) is the one in the directory.
This is changed by my procedure. It is not used anywhere else, only for
display in the directory.
For the invisible ID (hard-ID, as Thomas said), you are right. That's
the ID that is written in the header of every block. That one must be
identical for all blocks, at least for a standard format.
Regards,
Greg King
>
> Error "29, DISK ID MISMATCH" comes if BAM sector has another hard-ID
as any
> Any "read sector" command compares header with this RAM cell content
and
I think that the checking is confined to each separate track. That is:
When the DOS moves to a different track, it reads the header of
_whichever_ sector happens to fly, next, under the read/write head.
Then, the DOS looks for the sector that was specified. Each time that
the DOS reads a sector -- on that same track -- it compares the ID from
that specified sector with the ID from the initial random sector. If
they match, then the DOS continues; if they don't, then the DOS
complains.
That scheme allows each track to have an ID that's different from every
other track. I think that there is an early copy-protection method that
put specific IDs on specific tracks. The protected program would peek
at the drive's RAM, to see what ID was on particular tracks. If the
found ID didn't match an internal table, then the program would stop
running.
Hoffmann-Vetter, Martin
> As Thomas Winkler correctly told, you are only half-right.
After i read it, i think that's true.
> The "visible" ID (soft-ID, as Thomas said) is the one in the
> directory. This is changed by my procedure. It is not used anywhere
> else, only for display in the directory.
>
> For the invisible ID (hard-ID, as Thomas said), you are right. That's
> the ID that is written in the header of every block. That one must be
> identical for all blocks, at least for a standard format.
The question is, why changing the "visible" IDs only? The only reason for
changing ids is the unique problem. Some drives detect the disk change after
reading a changed id. So the ids must be unique over all used disk. Or you
must initialize via the command "I", "I0" or "I1" manually.
Thanks you for the clearly explanation above.
Greetings
Martin
Spiro Trikaliotis
* On Mon, Oct 24, 2011 at 09:13:00AM -0700 DerSchatten wrote:
> the Prozedure works fine, without errors on a 1541-II Floppy.
> But the Line "cbmctrl put --extended
> %a0%a0%a0%a0%a0%a0%a0%a0%a0%a0%a0%a0%a0%a0%a0%a0" writes the Letter
> a0a0a0a0a0a0a0... in the Diskname, not SPACES.
Are you really sure you copy-n-pasted this line correctly? I tested it
myself (not using real hardware, but dumping the buffer that would be
output onto the screen): The data is absolutely correct.
Did you accidentially use any other character than "%"?
Regards,
Spiro.
--
Nate Lawson
> * On Mon, Oct 24, 2011 at 09:13:00AM -0700 DerSchatten wrote:
>
>> the Prozedure works fine, without errors on a 1541-II Floppy.
>> But the Line "cbmctrl put --extended
>> %a0%a0%a0%a0%a0%a0%a0%a0%a0%a0%a0%a0%a0%a0%a0%a0" writes the Letter
>> a0a0a0a0a0a0a0... in the Diskname, not SPACES.
>
> Are you really sure you copy-n-pasted this line correctly? I tested it
> myself (not using real hardware, but dumping the buffer that would be
> output onto the screen): The data is absolutely correct.
>
> Did you accidentially use any other character than "%"?
If this is in a cygwin shell, you need to put quotes ("") around the entire %a0 string. More likely, I am guessing the DOS cmd shell is expanding %a0% into a shell var and thus it needs to be quoted.
-Nate
DerSchatten
The CMD-Shell under WindowsXP ignore the %-Character, i think.
What now?
Spiro Trikaliotis
* On Tue, Oct 25, 2011 at 12:44:28PM -0700 Nate Lawson wrote:
> If this is in a cygwin shell, you need to put quotes ("") around the
> entire %a0 string. More likely, I am guessing the DOS cmd shell is
> expanding %a0% into a shell var and thus it needs to be quoted.
I thought so, too. However, before I posted the above mail, I tried it
myself from cmd.exe and from bash.exe (cygwin): In both cases, it worked
as expected.
Spiro Trikaliotis
* On Tue, Oct 25, 2011 at 09:22:32PM +0200 Hoffmann-Vetter, Martin wrote:
> The question is, why changing the "visible" IDs only? The only reason for
> changing ids is the unique problem. Some drives detect the disk change after
> reading a changed id. So the ids must be unique over all used disk.
I have read these back in the days over and over again. However: This
might be true from some drives. But this is surely not true for the
2031LP and the 1540/1541/1551/1570/1571: These one already mark "disk
changed" when the WP LED changes. Thus, there is no need for unique IDs
on these drives.
I do not know about the 4040 (for example), though.
I know that many disks had the disk ID changed for cosmetical reasons.
Often, also the "2A" was changed to something else, to give 5 characters
for an id (2 ID, 1 Shift+SPACE, "2A" in original).
Why anyone would want to do it? I do not know, either.
Spiro Trikaliotis
* On Tue, Oct 25, 2011 at 03:20:27PM -0400 Greg King wrote:
> From: "Thomas Winkler"; on Monday, October 24, 2011; at 11:27 AM -0400
> >
> > Error "29, DISK ID MISMATCH" comes if BAM sector has another hard-ID
> > as any other sector. The "I" command reads hard-ID into a RAM cell
> > from DOS. Any "read sector" command compares header with this RAM
> > cell content and produces error 29.
>
> I think that the checking is confined to each separate track. That is:
> When the DOS moves to a different track, it reads the header of
> _whichever_ sector happens to fly, next, under the read/write head.
> Then, the DOS looks for the sector that was specified. Each time that
> the DOS reads a sector -- on that same track -- it compares the ID from
> that specified sector with the ID from the initial random sector. If
> they match, then the DOS continues; if they don't, then the DOS
> complains.
IIRC, you are wrong. However, I would have to either test it (not
possible ATM), or look at the drive ROMs (no time for this, either).
Can anyone confirm either way?
Regards,
Hoffmann-Vetter, Martin
>> Some drives detect
>> the disk change after reading a changed id. So the ids must be
>> unique over all used disk.
>
> But this is surely not true for the
> 2031LP and the 1540/1541/1551/1570/1571: These one already mark "disk
> changed" when the WP LED changes.
If the drive is badly modified and the disk changes can't detected by the WP
LED, the only way is an unique id!
In all other situation, you're right!
Greetings
Martin
Greg King
> Hello,
>
> * On Tue, Oct 25, 2011 at 09:22:32PM +0200 Hoffmann-Vetter, Martin wrote:
>
> > The question is, why changing the "visible" IDs only? The only reason for
> > reading a changed ID. So, the IDs must be unique over all used disks.
>
> I have read those back in the days, over and over again. However: This
> might be true from some drives. But, this surely is not true for the
> 2031LP and the 1540/1541/1551/1570/1571. Those ones already mark "disk
> I do not know about the 4040 (for example), though.
disk when it sees a different ID.
Therefore, I suspect that Martin described the _original_ IEEE drives;
and, Spiro described the VIC drives (the 2031 sounds as though it is a
VIC that was repackaged as IEEE).
Is the error message "29,DISK ID MISMATCH" listed in any of the
manuals for IEEE drives?
>
> I know that many disks had the disk ID changed for cosmetical reasons.
> Often, also the "2A" was changed to something else, to give 5 characters
> Why anyone would want to do it? I do not know, either.
Greg King
>
> * On Tue, Oct 25, 2011 at 12:44:28PM -0700 Nate Lawson wrote:
>
> > entire %a0 string. More likely, I am guessing the DOS cmd. shell is
> > expanding %a0% into a shell var.; and thus, it needs to be quoted.
> I thought so, too. However, before I posted the above mail, I tried it
> as expected.
I tried it, too -- it didn't work! If a0 is an environment variable,
then its contents are used. But, if it isn't defined in the
environment, then %a0% simply disappears! Therefore, odd-numberred
"a0"s are thrown away; and, even-numberred "a0"s are used, verbatim.
The escape needs to be escaped. That is, use double percent-signs.
%%a0%%a0%%a0%%a0%%a0%%a0%%a0%%a0
Spiro Trikaliotis
* On Thu, Oct 27, 2011 at 09:30:51AM -0700 Greg King wrote:
> I remember reading somewhere that the 4040 automatically initiates a
> disk when it sees a different ID.
This is also done on a 154x/157x. The only interesting thing is that on
a 154x/157x, under normal circumstances, you will not encounter this, as
the drive already reinitializes the disk when it sees the WP LED
changing.
> (the 2031 sounds as though it is a
> VIC that was repackaged as IEEE).
It's the opposite: The 2031LP was the predecessor of the 1540. The 1540
is a 2031 with IEEE removed and IEC instead. The 2031LP predates the
1540 for sure. This can be clearly seen in the ROM.
Spiro Trikaliotis
* On Thu, Oct 27, 2011 at 09:52:27AM -0700 Greg King wrote:
> On Oct 26, 3:00�pm, Spiro Trikaliotis wrote:
> >
> > * On Tue, Oct 25, 2011 at 12:44:28PM -0700 Nate Lawson wrote:
> >
> > > If that is in a Cygwin shell, you need to put quotes ("") around the
> > > entire %a0 string. More likely, I am guessing the DOS cmd. shell is
> > > expanding %a0% into a shell var.; and thus, it needs to be quoted.
> >
> > I thought so, too. However, before I posted the above mail, I tried it
> > myself from cmd.exe and from bash.exe (Cygwin): In both cases, it worked
> > as expected.
>
> I tried it, too -- it didn't work!
I tested it with the attached patch. The patch makes "cbmctrl"
completely disfunctional, it only outputs for "put" what it would have
done. Thus, you can just enter it on the commandline without any other
commands before.
I tested it with a VC6 compiled binary as well as with a WDK compiled
one.
The output is:
(Cygwin):
$ ./cbmctrl.exe put --extended %a0%a0%a0
Command-line args: 4
argv[0] = 'C:\cygwin\home\tri\cbm\opencbm.git\opencbm\Debug\cbmctrl.exe'
argv[1] = 'put'
argv[2] = '--extended'
argv[3] = '%a0%a0%a0'
len = 3
0000: a0 a0 a0
(cmd.exe):
C:\cygwin\Debug>cbmctrl put --extended %a0%a0%a0
Command-line args: 4
argv[0] = 'cbmctrl'
argv[1] = 'put'
argv[2] = '--extended'
argv[3] = '%a0%a0%a0'
len = 3
0000: a0 a0 a0
It does not make a difference if I use uppercase or lowercase "A0" or
"a0", it's always the same.
> If a0 is an environment variable,
> then its contents are used. But, if it isn't defined in the
> environment, then %a0% simply disappears! Therefore, odd-numberred
> "a0"s are thrown away; and, even-numberred "a0"s are used, verbatim.
>
> The escape needs to be escaped. That is, use double percent-signs.
> %%a0%%a0%%a0%%a0%%a0%%a0%%a0%%a0
Well:
$ ./cbmctrl.exe put --extended %%a0%%a0%%a0
Command-line args: 4
argv[0] = 'C:\cygwin\home\tri\cbm\opencbm.git\opencbm\Debug\cbmctrl.exe'
argv[1] = 'put'
argv[2] = '--extended'
argv[3] = '%%a0%%a0%%a0'
len = 9
0000: 25 61 30 25 61 30 25 61 30
This does not look right to me. ;)
BTW: My MS Windows is:
c:\> ver
Microsoft Windows XP [Version 5.1.2600]
This gets mysterious for me. Can anyone else please do some tests and
report the results here?
Thomas Winkler
Diddl
worked fine with my grey 1541. I'm sure it will work with any 1541
including 1541-II and OC-118, cause BAM has same format on all drives.
Also a 4040 or 2030 should work with this.
I'm using latest OpenCBM coming with Zoomfloppy v2 and Windows Vista.
To see new diskname I had to reset the floppy after the sequence.
Thanks Spiro
------------------------------ rename.cmd
cbmctrl lock
cbmctrl put --extended
%a0%a0%a0%a0%a0%a0%a0%a0%a0%a0%a0%a0%a0%a0%a0%a0
cbmctrl unlisten
cbmctrl --petscii put "A++DISKNAME++A"
cbmctrl unlisten
cbmctrl --petscii put "ID"
cbmctrl unlisten
cbmctrl unlock
------------------------------
> 2011/10/30 Spiro Trikaliotis <an-zoomfloppy-us...@spiro.trikaliotis.net>
Diddl
This does work if you enter line by line, I have done this on my first
try.
This does NOT work in a batch file (shell script). As "DerSchatten"
says, it fills diskname with "A0" chars at the end.
The correct syntax in a .cmd scriptfile is:
cbmctrl put --extended %%a0%%a0%%a0%%a0%%a0%%a0%%a0%%a0%%a0%%a0%%a0%
%a0%%a0%%a0%%a0%%a0
--------------------------------------
cbmctrl --petscii command 8 i0
cbmctrl status 8
cbmctrl --petscii open 8 2 #
cbmctrl status 8
cbmctrl --petscii command 8 "u1: 2 0 18 0"
cbmctrl status 8
cbmctrl --petscii command 8 "b-p 2 144"
cbmctrl listen 8 2
%a0%%a0%%a0%%a0%%a0
cbmctrl --petscii command 8 "b-p 2 144"
cbmctrl listen 8 2
cbmctrl --petscii command 8 "b-p 2 162"
cbmctrl listen 8 2
cbmctrl --petscii command 8 "u2: 2 0 18 0"
cbmctrl close 8 2
cbmctrl unlock
pause
cbmctrl dir 8
--------------------------------------
Spiro Trikaliotis
* On Mon, Oct 31, 2011 at 02:43:57PM -0700 Diddl wrote:
> ok, I have it ...
Fine. ;)
> This does work if you enter line by line, I have done this on my first
> try.
>
> This does NOT work in a batch file (shell script). As "DerSchatten"
> says, it fills diskname with "A0" chars at the end.
Oh yeah, this is a .BAT file 101.
Although, honestly, I have to admit that I did not figure out myself
that this might be a problem here.
Thank you for your investigation.
"DerSchatten", does this help you now?