Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!husc6!think!ames!ptsfa!ihnp4!laidbak!mdb
From: mdb@laidbak.UUCP (Mark Brukhartz)
Newsgroups: comp.unix.wizards
Subject: Re: tar
Message-ID: <1069@laidbak.UUCP>
Date: Sun, 24-May-87 10:55:36 EDT
Article-I.D.: laidbak.1069
Posted: Sun May 24 10:55:36 1987
Date-Received: Sun, 24-May-87 21:42:50 EDT
References: <1003@bobkat.UUCP>
Distribution: na
Organization: Lachman Associates, Inc., Naperville, IL
Lines: 34
Summary: Some MC680x0/Multibus systems write byte-swapped tapes.

> From: m5@bobkat.UUCP (Mike McNally )
> ...
> What's the point of the 's' (swap bytes) option to tar?  Are there any
> systems which store characters of a string in byte-swapped order (so
> "TAMALE" looks like "ATAMEL")?  I dig the scene with integers, man, but
> strings?  Far out.  Especially since it swaps bytes in the header
> blocks as well as in the data.
> ...

Several Motorola 680x0 systems with an Intel Multibus actually make tapes
with every byte pair swapped. It seems that Motorola and Intel believe in
different byte orders. The Multibus is word-oriented; hence, byte order is
significant.

This affects the memory-mapped control registers, DMA'ed control structures
("IOPBs"), and, of course, the data. Some Multibus controllers have switches
to reverse their byte order (presumably by inverting the low-order address
bit on the bus). Typically, though, the magtape driver must do this the hard
way.

The usual solution is to byte-swap the data before the DMA and to restore it
afterwards. For odd-boundary transfers, the odd-addressed byte(s) must also
be swapped with their neighbors. These could be at the beginning of the data
(odd address, odd length), at the end (even address, odd length), or at both
ends (odd address, even length). Needless to say, several drivers handle the
general case, but botch odd boundaries.

Of course, a few systems (especially early ones) ignore the problem entirely.
They read and write tapes with reversed byte order. (They also corrupt data
which begins or ends at odd addresses.)

					Mark Brukhartz
					Lachman Associates, Inc.
					..!{ihnp4, sun}!laidbak!mdb