Re: Need someone to do a little cracking

["Charlie" <charlieDOTd@verEYEzon.net>]

"Michael J. Mahon" <mjmahon@aol.com> wrote in message 
j5idnV_WFZDwabvXnZ2dnUVZ_o6dnZ2d@giganews.com">news:j5idnV_WFZDwabvXnZ2dnUVZ_o6dnZ2d@giganews.com...
> Nick Westgate wrote:
>> On Jun 3, 2:34 pm, "Michael J. Mahon" <mjma...@aol.com> wrote:
>>> The machine will "break" almost immediately, then you can examine 
>>> the
>>> code (and data) in the region $8AFA..$8BFB and I can guarantee that 
>>> you
>>> will see what it does to signature check the disk.  (Of course, that
>>> means accessing the disk, so there things may get more technical.)
>>
>> Yes, this (!) signature check is easily circumvented.
>>
>> The next problem is that the disk assumes volume 255.
>> Either that needs to be worked around, or a NIB is preferable.
>
> Hopefully, it's not too hard to patch it to accept the default
> volume number...(though it's also annoying that the .dsk/.do
> format doesn't include a volume number or means for conveying it).
>
> I wish that emulators would scan .dsk/.do filenames for the
> presence of, say, ".v" followed by a volume number, followed by ".",
> if such a substring is in the name.  This would be a simple way
> to provide the volume number associated with an image through
> "out of band" signalling.
>
> Unmodified emulators would, of course, pay no attention.
>
> Requiring use of the much less appealing .nib format to convey a
> single byte of information is a problem that should be addressed.
>

Why not have the emulator read the volume number from the VTOC, Track 
$11, Sector $00, byte $06 on any normal .dsk/.do image? If emulators 
already do that (and the original had a different volume number in the 
track/sector address headers) then in this case all that should be done 
is that one byte should be edited to 255.

Of course there were (I believe) disks that used different volume 
numbers in the headers of different tracks/sectors but that could cause 
problems with an image filename scheme as well.

Charlie