re: Tacking on an end-block. That's an interesting idea. I've always thought front-endian: that a header block needed to come first. But it doesn't, does it? If the final 256 bytes start with the CBM equivalent of "PAY ATTENTION!!" then that really gets you the same thing, without messing up the disk image. And it's not too big of a deal to seek to the end of a file and back up one block... at least not with non-eight-bit machines, which are likely to be the customers here. I've thought it would be nice to have a flexible-sized image. X64 has room for parametric structural data. But adoption would be low (nil, in fact, and that includes after I would submit code for the VICE team to reject), and compression programs really make that sort of thing counter-productive. But I like thinking about those sorts of geekinesses anyway. On Mon, Jan 27, 2014 at 11:05 PM, Rob Eaglestone < robert.eaglestone@gmail.com> wrote: > I won't say the ship has sailed, but it's certainly pulled out of the port. > > I'm all for embedding metadata, if a place can be found. At least, it's a > fun thought experiment. I once thought about putting metadata in Block > Zero, but I suppose that's used more often than Track 18, Sector 18. > > Overwriting the BAM with a Magic Word, for example. (After all, > rebuilding the BAM is just one validate away.) > > And I *do* like the possibilities made by the X64, unlikely tho they are > to be ever exercised. > > > > On Mon, Jan 27, 2014 at 9:29 PM, Jim Brain <brain@jbrain.com> wrote: > >> On 1/27/2014 4:59 PM, Rob Eaglestone wrote: >> >>> re: container format. Hasn't this been done already, i.e. the X64? >>> And, it's rather moribund (although I think there are fun things one can >>> do with a container). But yes, tradition tends to be a handy bond. >>> >>> And, regarding the thought of a five-character extension: sure, but I >>> think that way lies madness; you'll suggest a modest and reasonable but new >>> way, and before you know it I'll have lost my self-restraint and will >>> suggest a real-like 256-byte header appended to those new formats, and then >>> I'll be suggesting a .D1541 image that includes that header, and that the >>> directory should be located at the front of the image, and......well it's >>> just madness, I tell you!! >>> >> >> I agree containers and different extensions are on a ship that has sailed. >> >> However, I am wondering if there is a way to "embed" the metadata into >> the existing format. >> >> Yes, I know there are issues... >> >> Still, giving people the option of using the last sector of track 18, >> for example, which is hardly ever used, or tacking a block onto the end of >> the image and putting data into that block would sure help matters. >> >> Jim >> >> >> >> Message was sent through the cbm-hackers mailing list >> > > Message was sent through the cbm-hackers mailing listReceived on 2014-01-28 06:00:51
Archive generated by hypermail 2.2.0.