Re: Suggested DSK mod

Andy McFadden writes ...

Rubywand <rubywand@xxxxxxxxxx> wrote:
Something like 2MG would have been very nice had it become the
standard 15 years ago. But, instead, the standard is DSK.

The standard is DSK without a volume number in the filename. It may
not seem like it, but you are seeking to change the standard.


A bit, yes. But only in the sense that emus may or may not choose to use
the information. The .dsk file itself is unchanged. Whether or not any emu uses
the VN info, those transferring a .dsk file to diskette on an Apple II
certainly can.


2MG seems to have other problems. According to the specs (unless there
has been a change), the format ties VN to disk order. That is a classic
error.

I don't think your understanding of the specification is correct.
The specification only says it is intended for DOS 3.3 disks. It says
nothing about tying the volume number to the disk ordering.

http://www.a2central.com/programming/filetypes/ftne00130.html


Yes, it does. The determining factor in the Flags field is referenced to
"image format" and image format as defined in the specs is clearly a matter of
sector ordering. Here are quotes from the current description from the above
source:


The Flags field

The flags field contains bit flags that specify details about
the disk image. Bits not
defined here must be zero.

Bit
Description
31
If this bit is set, the disk image is locked and
no changes should be permitted to the disk
data it contains. This is used by emulators to
provide support for write-protecting disk
images.
8
If this bit is set, the low byte of the flags field
contains the DOS 3.3 volume number of the
disk image. This bit should only be set for
DOS 3.3 disk images. If the disk is DOS 3.3
format (the image format is 0), and this bit is 0,
volume number 254 is assumed.
7-0
The DOS 3.3 volume number, from 0-254, if
bit 8 is set. Otherwise these bits should be 0.
<<


and



The image format is indicated as one of the following values:

DOS 3.3 Order
0
ProDOS Order
1
Nibblized data
2
<<

So, we are talking about sector ordering. Making VN dependent upon sector
ordering is an error.


In the cases where VN is specified in the name of a DSK file-- e.g.
GameSaveVN019.dsk-- the user can INIT the target diskette for the correct
VN and, then do the transfer. Or, note the correct VN on the target
diskette and change it after the session; one way is copying to a
correctly INITed diskette using COPYA w/o format.

The system should be automatic. If we're going to change the way things
work, we should change it so things work *better*. Otherwise, people
who are just getting back into the Apple II world will be very confused.
If we had no ability to update the tools, then I think your approach
would make sense; but we can update them, and in fact people have been
updating them quite recently (note the new ".d13" format).

Right now, there is nothing to prevent persons who upload .dsk disk images
from specifying a non-default VN in the file name-- much easier than
creating a NIB image. The image would be perfectly useful to real Apple II
users who transfer it to a diskette with the correct VN. It would be nice
if the image could work on AppleWin, too.

There is nothing stopping them from uploading images in 2MG format.
If the PC side of the ADT transfer created and handled 2MG images, you
could transfer to and from the Apple II without ever having to worry
about the volume number.

The difference for an emulator is that, instead of doing this:

open image file
read and write from offset 0

For 2MG they have to do:

open image file
read header
read and write from offset N

Maybe we should consider that many of our real Apple II users are on
machines that have only 5.25" drives and 64K of RAM. ADT is important.

One of the significant features of ADT is that it is a small program which
transfers pretty easily. If we start adding features like file name parsing and
formatting, ADT will be a lot larger and more likely to get messed up during
transfer. All for a relatively small number of .dsk files where VN matters.
Still, if someone feels like developing an enhanced ADT, fine.

I suggest we avoid complexity. Just tell users that "VN019" near the end
of a filename means the transferred image needs to, eventually, go to a
diskette INITed for VN=19.

Placing Volume Number info in the file name allows a few hundred programs
to be available in .dsk . If it is not a horrendously difficult change for emu
designers to make, I think it would benefit Apple II and emu users.


Suppose, though, that we are Really Serious about making a significant
improvement in emu capabilities. In that case, the obvious upgrade is to accept
ShrinkIt whole-disk archive files.


Rubywand
.

Relevant Pages

  • Re: Whats mean by PAL release?
    ... Europe, several South American countries, some Middle East and Asian ... So if your TV doesn't support this standard, ... So when I buy the CD, how may I determine what format the CD is? ... >> read a UDF format disk. ...
    (microsoft.public.games)
  • Re: Virtual PC 5.0 and mac os 9.2
    ... Format: MacOS standard ... Is the format the one you are talking about, ... > The volume you have your dynamic disk on is probably on an HFS standard ...
    (microsoft.public.mac.virtualpc)
  • RE: Simple but effective Disk Wipe Software
    ... Simple but effective Disk Wipe Software ... returning a Hard Disk to Dell. ... My Director does not want to spend any money as he feel's a standard ... "format" will suffice; therefore I guess a Linux solution is the best. ...
    (Security-Basics)
  • A DRIVE PROBABLEMS
    ... I have a floppy a drive and am running XP yet every time ... I get the message to format the disk, ... standard 1.44 floppy ...
    (microsoft.public.windowsxp.hardware)
  • Re: conflict of software Nero Recordnow Drivers - or ??
    ... disk package anywhere. ... If Not when Would I format a disk? ... For most normal disc burning projects, music CDs, playable DVDs, Photo CDs, ... I know I did have DLA, On both drives and I was using when asked if I ...
    (microsoft.public.windowsxp.hardware)