11 Aug
2004
11 Aug
'04
4:03 a.m.
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.