Not to beat a dead horse, but a Commodore disk is a header, a BAM, a directory, a pile of data sectors, and perhaps some error data... but each of those vary by location by disk format. There are only a few ways to represent this data, and by default our images are byte-for-byte copies. On Tue, Jan 28, 2014 at 7:51 AM, Rob Eaglestone <robert.eaglestone@gmail.com > wrote: > In other words, the metadata is optional, and useful when present. This > is not an unusual solution. > > If I recall Peter Schepers' useful informational webpages, X64 isn't used > much exactly because it's a container format, and basically has to be > interpreted twice -- once to figure out what the format is, and then once > again to actually get at the image data. > > http://ist.uwaterloo.ca/~schepers/formats/X64.TXT > > There is no advantage for PC users to use this format since virtually no >> PC emulator that I know of uses them, and for the most part, it provides >> the same functionality as a D64 file. > > > >> In order to read a generic X64 file, first you must determine that it is >> an X64, and then determine the type of file it contains. In effect, you >> have to double-decode the file, which makes support a little more >> difficult. Also, you would have to be able to work with *all* of the types >> of drives that X64 supports, a daunting task. > > > >> Its only advantage is that is encompasses all of the standard disk >> formats on the C64. If other disk types were common (like 1581 or CMD >> disks), then this format might be more popular. >> > > > > On Tue, Jan 28, 2014 at 1:13 AM, Jim Brain <brain@jbrain.com> wrote: > >> On 1/28/2014 12:59 AM, Groepaz wrote: >> >>> On Tuesday 28 January 2014, you wrote: >>> >>>> I agree it's a more complete format, but it's not used as much. My idea >>>> of putting this same information on track 18 would add this information >>>> to the image, and has the benefit that folks could "see" if the disk >>>> came from an image when they use a real disk. >>>> >>>> Yeah, I know it "corrupts" the image. complaints to /dev/null >>>> >>> the major problem with that approach is that it doesnt work on disks >>> that are >>> completely filled with data (which isnt really unlikely, lots of cracks >>> and >>> demos use the dirtrack for files, for example) - which rules it out as a >>> generic solution. >>> >>> Well, since the block has a magic sequence, any block will work. Yes, >> though, on a completely filled disk, it's not workable. >> >> Still, for the millions of D64s that are not full, it's fine. And, if >> the D64 does not have the block, it's not like it fails to work. >> >> It's like an MP3 in that way. >> >> Jim >> >> >> -- >> Jim Brain >> brain@jbrain.com >> www.jbrain.com >> >> >> >> Message was sent through the cbm-hackers mailing list >> > > Message was sent through the cbm-hackers mailing listReceived on 2014-01-28 16:01:13
Archive generated by hypermail 2.2.0.