Re: Need someone to do a little cracking

[Poake <beheybirder@gmail.com>]

On Jun 3, 7:55 pm, "Charlie" <charlieD...@verEYEzon.net> wrote:
> "Michael J. Mahon" <mjma...@aol.com> wrote in messagej5idnV_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

This is something I've never understood. The volume number is right
there in the VTOC and ignored in the emulator. Having the ability to
inject a volume number via a setting into the emulator is another
option (overriding vtoc values) but it should at least read the .dsk
as it is formatted.