Received: (from major@localhost)
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) id LAA15274
	for pups-liszt; Wed, 30 Dec 1998 11:06:51 +1100 (EST)
Received: from moe.2bsd.com (0@MOE.2BSD.COM [206.139.202.200])
	by minnie.cs.adfa.edu.au (8.9.1/8.9.1) with ESMTP id LAA15267
	for <pups@minnie.cs.adfa.oz.au>; Wed, 30 Dec 1998 11:06:42 +1100 (EST)
Received: (from sms@localhost)
	by moe.2bsd.com (8.9.0/8.9.0) id QAA12964
	for pups@minnie.cs.adfa.oz.au; Tue, 29 Dec 1998 16:06:30 -0800 (PST)
Date: Tue, 29 Dec 1998 16:06:30 -0800 (PST)
From: "Steven M. Schultz" <sms@moe.2bsd.com>
Message-Id: <199812300006.QAA12964@moe.2bsd.com>
To: pups@minnie.cs.adfa.oz.au
Subject: Tape endianness in Bob's simulator
Sender: owner-pups@minnie.cs.adfa.edu.au
Precedence: bulk

Hi -

	In glancing thru Bob's simulator I spotted this:


* Endian independent binary I/O package

   For consistency, all binary data read and written by the simulator
   is stored in little endian data order.  That is, in a multi-byte
   data item, the bytes are written out right to left, low order byte
   to high order byte.  On a big endian host, data is read and written
   from high byte to low byte.  Consequently, data written on a little
   endian system must be byte reversed to be usable on a big endian
   system, and vice versa.


	Perhaps this sheds some light on why a Sparc can't read a pdp-11
	generated (via 'makesimtape') tape.

	I know I've read simulated tape files on an Intel system with no
	trouble - so it would appear that the endianness was correct.

	Good Luck Robin! ;)

	Steven

