Let's develop an open-source media archive standard

From: Vintage Computer Festival <vcf_at_siconic.com>
Date: Wed Aug 11 12:45:24 2004

On Wed, 11 Aug 2004, Steve Thatcher wrote:

> I don't quite understand why representing binary as hex would affect the
> ability to have command line utilitities. Certainly more cpu cycles are
> needed for conversion and image file size is larger, but we need a
> readable format and I would think that cpu cycles is not as much of a
> concern or file size. A utility to create a disk would only have to run
> through the conversion once to buffer a representation of the floppy
> disk (unless we are talking about a hard drive image of course). The
> file size to re-create a floppy disk is only going to be 2 to 3meg at
> the most (if thinking about a 1.2meg floppy with fortmatting info).

I'm leaning away from including a raw binary image of the data in the
archive itself. Sure, it would be handy to have a dual use file, that's
both readily human and machine readable. But as has been pointed out,
there's two issues: mixing characters with binary might be messy, and the
archive size then bloats considerably, which might be a problem for
certain platforms.

The image can always be parsed in realtime by the native platform, if it's
fast enough and has enough resources (RAM, HD space, etc.) A driver of
sorts could translate the archive file in realtime to make it appear as a
floppy or tape or whatever. Creative solutions like connecting to a host
processor over a serial port, having the host processor do the
translation, and then making the serial port look like a disk drive or
whatever on the target system is another option. And then of course, the
image can be simply converted back to it's original format and sent to the
target system so that it can be written out back to its native media.

> As for GCR, that would have been covered under etc... I am not familiar
> with GCR, but I would guess that it has to deal at least with physical
> tracks and heads. In this case, a track would consist of whatever the
> format needed plus the data blocks required for the track.

GCR is no different than MFM in terms of data organization. It's just the
way the bits are read/written from/to the media that's different. GCR has
tracks and sectors just like MFM.

I am taking notes on everything being written, BTW. I'm currently
planning a special session at the VCF to officially launch this as an RFC.
If all the big names I plan to invite actually come (and I think they
might be compelled to do so) it will turn into quite a neat session.

Sellam Ismail                                        Vintage Computer Festival
International Man of Intrigue and Danger                http://www.vintage.org
[ Old computing resources for business || Buy/Sell/Trade Vintage Computers   ]
[ and academia at www.VintageTech.com  || at http://marketplace.vintage.org  ]
Received on Wed Aug 11 2004 - 12:45:24 BST

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:36:33 BST