Rumor has it that Jules Richardson may have mentioned these words:
>I'm not quite sure what having binary data represented as hex for the
>original disk data gives you over having the raw binary data itself -
>all it seems to do is make the resultant file bigger and add an extra
>conversion step into the decode process.
Different systems interpret binary data differently, especially if there is
human-readable code within the file. MS-DOS very likely could think the
file is binary, and the first hex 0x06 would terminate the file. However,
if it is considered binary many viewers wouldn't open it if it's got
non-printable ASCII characters within.
Or -- how about transferring this file from MS-DOS <=> Linux <=> MacOS <=>
BeOS ... will it (and if so, how will it) convert line ending chars, tabs &
other binary chars? A hex representation will reduce conversion problems
measurably - remember, this is supposed to be an "ultra-portable" format.
>As for file size, if encoding as hex that at least doubles the size of
>your archive file compared to the original media (whatever it may be).
>That's assuming no padding between hex characters. Seems like a big
>waste to me :-(
Not necessarily - IIRC, Moto S-records only have records for where there's
actually data, right? So if the disk is only 1/2 full of data, the S-record
would reflect that, right?
If we're already going to take this "beyond" the spec, couldn't we
institute some RLE encoding as well?
Just thoughts,
Roger "Merch" Merchberger
--
Roger "Merch" Merchberger --- sysadmin, Iceberg Computers
Recycling is good, right??? Randomization is better!!!
If at first you don't succeed, nuclear warhead
disarmament should *not* be your first career choice.
Received on Wed Aug 11 2004 - 11:03:32 BST