HDTenEightyP/NetNews huggingface dataset:
From: gerard@tscs.com (Stephen M. Gerard)
Subject: MVME167 - '040 Processor Clock Rate?
Organization: Total Support Computer Systems, Tampa, Florida
Date: Thu, 16 Apr 92 07:49:41 GMT

What are the current clock rates available for the Motorola MVME167 board?

I am considering upgrading a 33MHz MVME141 board and would like to get the
fastest processor available.

Thanks in advance.

Steve

-- 
------------------------------------------------------------------------------
Stephen Gerard  -  Total Support Computer Systems  -  Tampa  -  (813) 876-5990
E-Mail: gerard@tscs.tscs.com				   FAX: (813) 871-2783
US-MAIL: Post Office Box 15395 - Tampa, Florida  33684-5395
Organization: Alphabetical
Date: Tuesday, 14 Apr 1992 23:19:47 EDT
From: Jeff Siegel <JXS118@psuvm.psu.edu>
Newsgroups: comp.sys.m68k
Subject: Semi-Useful Phone Numbers for 680x0 designs

I just finished bulding a 68030 system. For what its worth, these
are the phone numbers I collected in the process:

Alpha Wire Co.
800-522-5742
Project wire is type 2842/7 Description: 28 AWG composed of 7 strands
of 36 gauge Teflon coated 0.006" thick insulation. This wire is thin
enough to wire cards with pins spaced 0.1 inches apart. The insulation
will not melt against the soldering iron.

AMP
717-564-0100
717-780-4100 Don Zerphey - University Relations Contact
For prices must go to "Customer Service" with an account number
No account number, have to ask distributor:
Greybar Distributors 412-837-2900


Augat (PC Boards for VME designs)
General 800-336-3526
VME Sales Office 508-699-7646


Data I/O (Eprom and PLD Programmers)
1-800-332-8246
Tech Sales REp for Eprom Programmers Joan Sewell
1-800-247-5700 ext 6943


Dawn VME (PC Boards for VME designs)
800-258-3296
Tech Sales Rep Don Dickerman


Hybricon (Manufactures VME Card racks)
508-772-5422


IBM (Pennsylvania Donations Contact)
814-237-5721
Timothy P Wilkinson
Account Marketing Representative
365 N. Science Park Rd
State College 16803

Jameco
1-800-831-4242


JDR Sales 1-800-538-5000
Tech Support 1-800-538-5002


Lattice (Manufactures GALs)
800-327-8425 Literature
503-681-0118 General


Logical Design Group (Manufactures VME cards.)
919-851-1101
6301 Chapel Hill Rd.
Raleigh, NC. 27607


Logical Devices (Eprom and PLD Programmers)
General 1-800-331-7766
Tech Support 305-974-0967
BBoard 305-974-0612



Motorola
General 512-928-6000
Sales Locator 1-800-521-6274
Penna Dist 215-957-4100
Literature 602-994-6561

Motorola University Contact
602-952-3855
Fax 602-952-3621


Mupac (VME Cards)
800-926-8722


Nec
Marketing Support (Literature)
800-632-3531


Newark Electronics (Sells large number of components from many makers)
412-788-4790


Samsung
800-423-7364 (Computer Voice System)
KS84C31 or KS84C32 DRAM Controller for 680x0 designs
Bill Mikolonis 408-954-7268 (DRAM Sales rep)
408-954-7228 Literature Number (Real humans)
Boston Sales Office 617-273-4888 (Jim Harsted - Field Engineer)

Part Samples for Samsung parts
CMS Sales 215-834-6840 (State of Pa only)
All-American Sales 800-327-6237

Sharp
Regional Sales (Boston for NorthEast)
617-270-7979


TI
General Info
800-232-3200
University Relations
Ansel Goldgar
PO Box 655303
MS 8338
Dallas, Tx 75265
214-997-6267

TI Data Books (for Educational Institutions only)
Dolores Hackney at 214-997-2476
               Fax 214-997-5018


VITA (Provides specifications on the VMEbus standard)
The VMEBus Specification 29.95
Phone 602-951-8866
FAX 602-951-0720


Weller (Soldering Irons)
919-362-7511
Weller Technical Info 800-476-3030
Lamen-Losh 215-467-6200 (Distributor for Pa)
From: gjm@gserv1.dl.ac.uk (g.j.milne)
Newsgroups: comp.sys.m68k
Subject: Re: 680x0 vs 80x86
Date: 13 Apr 92 08:37:44 GMT
Reply-To: gjm@gserv1.dl.ac.uk
Organization: Daresbury Laboratory, UK

In article 6255@public.BTR.COM, thad@public.BTR.COM (Thaddeus P. Floryan) writes:
>Remember that systems based on Intel (and VAX) computers violate even the
>Internet standard Network Byte Order

Come on, since when has the Internet Network Byte Order been THE byte ordering
of preference? Surely, the VAX (or PDP-11) came about before the Internet?

I also prefer Motorola to Intel but this kind of argument is nonsense.
There are far better points on which to score, in particular Intel
don't seem to understand the importance of an orthogonal (or
near-orthogonal) command set. Of course that uses up a bit more silicon
but at least it gives you a few more registers to play with, far better
than using the stack!

What is amazing is that even with the `advantage' of fewer registers
Intel had to go and screw the whole thing up with a weird set of memory
limitations. What a company!

---
S.E.R.C. Daresbury Laboratory, Warrington, WA4 4AD, United Kingdom.
e-mail     : g.j.milne@dl.ac.uk (INTERNET)  g.j.milne@uk.ac.daresbury (JANET)
Disclaimer : Opinions expressed are my own, not those of my employer!
From: wdorsey@lila.Eng.Sun.COM (William Dorsey)
Newsgroups: comp.sys.m68k
Subject: speeding up an '020 system
Date: 8 Apr 92 21:47:44 GMT
Organization: Sun Microsystems Inc., Mountain View, CA
NNTP-Posting-Host: lila

I have a couple of ideas on improving the performance of an old Sun 3/60
system I have at home.  Before I break out the soldering iron and risk
wasting a lot of time, I thought I'd solicit a few opinions regarding
what I'm proposing.

The 3/60 contains an 68020 clocked at 20MHZ.  It works with 100ns simms,
though it presently has 80ns simms installed in it.  If the '020, '881,
and other chips in it could handle a higher CPU clock speed, this would
be one way to speed things up.  I'm thinking of trying a 50MHZ crystal
which would bring the clock rate up to 25MHZ.

Another idea I have is building a daughter board with an '030 on it and
then performing the necessary translation to mimmick an '020.  My own
benchmarks seem to indicate the '030 is roughly 40% faster than that
'020 at a given clock speed.  I could even combine this idea with the
above idea and put in an '030 and run it at 25MHZ.  I know the '030 is
missing a couple of instructions found on the '020, so I may run into
problems with this approach.  However, the Sun 3E systems used '030s in
them and I suspect the OS will still work.  Anyone heard of a company
that sells daughterboards like this for upgrade purposes?

If these approaches turn out to be more trouble than they're worth, I
guess I'll just have to stick to using the profiler and assembler on
slow applications until I can afford something faster...  Thanks in
advance for any information/ideas.

- Bill Dorsey
From: bnell@ferrari.siemens.com (Bill Nell)
Newsgroups: comp.sys.m68k
Subject: fast reversal of a bit field
Date: 7 Apr 92 15:55:14 GMT

Does anyone know a fast way of reversing the bits in a 16 or 32 bit
number?  What I mean is if you start of with 011010 (for example)
to change it to 010110.  Right know I am just doing a simple rol.l
checking the carry flag and setting a bit in a temporary register
with bset if the carry is set.  I'd like to know if anybody knows
a faster way to do this (on a 68000).
					Thanks,
					Bill
From: rh2y+@andrew.cmu.edu (Russell E. Hoffman, II)
Newsgroups: comp.sys.m68k
Subject: TUTORbug question
Date: 6 Apr 92 13:04:23 GMT
Organization: Junior, Electrical and Computer Engineering, Carnegie Mellon, Pittsburgh, PA

Does anyone know if it is possible to disable the register dump after
every trace instruction in TUTORbug? We're working on a rather large
project for a class, and at 4800 baud, it's a real pain to hafta watch
hundreds of register dumps fly by when I'm really only interested in flow
of control. What I'd like to be able to do is type T 24 and get exactly
one screenful of traced instructions, with no register dump after each
instruction. Any ideas? (And no, re-burning the EPROM is not an option..)

Thanks,
Russell Hoffman
rh2y+@andrew.cmu.edu
From: tardif@outaouais.ulaval.ca (Pierre-Martin Tardif)
Newsgroups: comp.sys.m68k
Subject: MC68332
Keywords: MC68332
Date: 10 Apr 92 15:22:56 GMT
Organization: Universite Laval

I'm desperatly seeking for a MC68332 cross-compilator.  Freeware, shareware
or anything else, I DON'T CARE if it's a good one...

Does anybody know about a 68332 user' group ?

Does Introl make anything for this microcontroller ?

Thanks, pleeeeeaaaaase, help meeeeee  :-)


-- 
Pierre-Martin Tardif, etudiant gradue  (email: tardif@gel.ulaval.ca)
Laboratoire de Vision et Systemes Numeriques
Universite Laval, Pavillon Adrien-Pouliot, local 00100-I, Ste-Foy, Quebec,
Canada, G1K 7P4         (418-656-2131, ext 4848)
From: pl@hakki.cs.tut.fi (Lehtinen Pertti)
Newsgroups: comp.sys.m68k
Subject: Re: Pure Segmentation on 68K's
Date: 16 Apr 92 06:42:26 GMT
Organization: Finnish University and Research Network FUNET

From article <11461@ksr.com>, by jfw@ksr.com (John F. Woods):
> dnichols@ceilidh.beartrack.com (Don Nichols (DoN.)) writes:
>>In article <11399@ksr.com> jfw@ksr.com (John F. Woods) writes:
>>>icsu8209@cs.montana.edu (Glassy) writes:
>>>>A beginner question on the 680[234]0 architecture:
>>>>Does Motorolla make any MMU chips that do or can use pure segmentation
>>>>for managing memory?
>>	[ ... ]
>>>>I've heard of the 68451 (is that the #?) MMU, but thought it was a
>>>>paging-oriented unit.
>>>I'm pretty sure '451 is the number of the segmented MMU ('851 is the PMMU).
>>>It was never too popular, and I wouldn't be surprised if Moto wasn't making
>>>it any more (in fact, I wouldn't be too surprised if the architect hadn't been
>>>taken out into the parking lot and machine-gunned... :-).
>>	[ ... ]
>>>The '451 required segments to be a power-of-two length, and you got a fairly
>>>small number of them.
>>>[My apologies to the architect of the '451, who almost certainly wasn't
>>>machine-gunned and no doubt had very good reasons for why it came out the
>>>way it did.]
>>	Well, before he was "fired" :-), the 68451 found its way into the
>>COSMOS CMS16/UNX (a 68000-vanilla computer in Intel multibus).  It ran a
>>UniSoft port of v7 unix, and the cpu couldn't handle page faults (that
>>didn't come till the 68010), so a paging MMU wouldn't be of any use.
> 
> I've had one complaint that I may be mistaken on the capabilities of the
> '451, and I can't find a handy data book with that part in it (it has been
> a long time since I participated in the decision not to use whatever 68000
> MMU it was that we rejected).  Could someone with the data sheet post a
> genuine description of the part so I know whether or not to buy some machine
> gun bullets :-) ?

	Well, some info is here:

	MC68451 is used on MVME121 board from Motorola (VME CPU)

	It has some features:

	- segment sizes vary from 2k to 16M on powers of two.
	- segment can start from any address divisible by segment size.
	- MMU contains 32 descriptors for segments ( MAX 32 loaded segs at time)

	- Descriptor has

		Physical address	- where segment really is
		Logical address		- at what address it is visible
		Address mask		- which part of logical is replaced by physical
		Address space number	- On which address space this segment belongs
		Address space mask	- Which bits of asn are valid
		Protect bits		- writeprotect, modofied, interrupt, etc...

	- Address space table maps function codes from CPU to address space number
	- AST has 16 entries.

	Can be easily used as TLB for page tables in memory (if you need vm).
	Then you have variable size pages.

	Or as simple memory protector (ala old PDP-11 mechanism, which is
	propably emulated on Unix V7 ports).

---




	
pl@cs.tut.fi				! All opinions expressed above are
Pertti Lehtinen				! purely offending and in subject
Tampere University of Technology	! to change without any further
Software Systems Laboratory		! notice
From: green@eniac.seas.upenn.edu (Bradley Green )
Newsgroups: comp.sys.m68k
Subject: RS-422 in 68000 system
Date: 7 Apr 92 23:54:39 GMT
Article-I.D.: netnews.73157
Organization: University of Pennsylvania

Newsgroups: comp.sys.68K
Subject: RS-422 on 68000
Followup-To: 
Distribution: world
Organization: University of Pennsylvania
Keywords: 

I'm trying to build an extremely inexpensive (to produce) single-board
computer based on an 8 mHz 68000.  I need to get an RS-422 serial interface
into this system, running at ~232Kbaud (AppleTalk speed, for interfacing with
Mac's).  My question is this: What hardware (UART chip) will most easily
work in this system, with the least amount of 'glue' chips?  Also, if
anyone knows of a site where I could get a pre-rolled interrupt-service
routine for this interface, it would be very helpful.

Thank all you you very much.

BTW - all of you at Motorola, when are some new 680x0 chips coming out?
      I don't want to see Intel (yech!) get ahead of you.

Brad

Newsgroups: compcomp.sys.m68k
Subject: RS-422 in 68000 system
Followup-To: 
Distribution: 
Organization: University of Pennsylvania
Keywords: 

Newsgroups: comp.sys.68K
Subject: RS-422 on 68000
Followup-To: 
Distribution: world
Organization: University of Pennsylvania
Keywords: 

I'm trying to build an extremely inexpensive (to produce) single-board
computer based on an 8 mHz 68000.  I need to get an RS-422 serial interface
into this system, running at ~232Kbaud (AppleTalk speed, for interfacing with
Mac's).  My question is this: What hardware (UART chip) will most easily
work in this system, with the least amount of 'glue' chips?  Also, if
anyone knows of a site where I could get a pre-rolled interrupt-service
routine for this interface, it would be very helpful.

Thank all you you very much.

BTW - all of you at Motorola, when are some new 680x0 chips coming out?
      I don't want to see Intel (yech!) get ahead of you.

Brad
From: bruce@heather.pooh.com (Bruce Robertson)
Newsgroups: comp.sys.m68k
Subject: Re: MC68681 DUART help
Date: 8 Apr 92 05:56:38 GMT
Organization: Hundred Acre Consulting, Reno, NV
In-reply-to: byron@cc.gatech.edu's message of 6 Apr 92 13:26:22 GMT

In article <1992Apr6.132622.10098@cc.gatech.edu> byron@cc.gatech.edu (Byron A Jeff) writes:

>   In article <1992Apr6.074628.25008@cs.ubc.ca> sritchie@cs.ubc.ca (Stuart Ritchie) writes:
>
>   But that's not what is needed. Until another character is transmitted the
>   interrupt (not the transmitter) needs to be disabled.

Disabling the interrupt works okay, but I prefer to disable the
transmitter itself.  This is faster than disabling the interrupt,
because you have to maintain a shadow of the IMR register since it's
write-only.  Another reason to avoid it is the IMR is shared between
both DUARTs, so you have to find its offset, and figure out which bits
you're going to mess with.  All of this adds cycles in something you
probably want to be pretty fast.  On the other hand, each DUART has
its own command register, and disabling the transmitter is done by
writing a single byte to it.

Also, I've used a hardware implementation that configured the output
port bits as the interrupt lines, and didn't use the IMR at all.  Just
disabling the transmitter works with both implementations, and you
don't have to have #ifdefed code in the driver to handle both.

Note that disabling the transmitter while it's still transmitting the
last character works properly.

--
Bruce Robertson			bruce@pooh.com		Phone: +1-702-329-9333
Hundred Acre Consulting		1280 Terminal Way #26	Reno, NV 89502-3243
Newsgroups: comp.sys.m68k
Subject: Re: 680x0 vs 80x86
From: gcall@phx.mcd.mot.com (Glen Call)
Date: 13 Apr 92 20:16:30 GMT
Organization: Motorola Computer Group, Tempe, Az.

In article <6255@public.BTR.COM> thad@public.BTR.COM (Thaddeus P. Floryan) writes:
>In article <73288@netnews.upenn.edu> green@eniac.seas.upenn.edu (Bradley Green ) writes:
>[much mention of Motorola and that other company deleted]
>Be smart, use a Motorola chip; so what if it's not (ugh) "politically correct."
>

Not politically correct?  That's the nicest compliment we've been paid in
a long time :-) :-) :-) !

>Thad Floryan [ thad@btr.com (OR) {decwrl, mips, fernwood}!btr!thad ]

------------------------------------------------------------------------------
Glen Call, Firmware Development engineer
Motorola Technical Systems Division,  2900 S Diablo Wy, Tempe, AZ   85282
Voice:  602-438-3438                      UUCP: ...!{asuvax,uunet}!mcdphx!gcall
Domain: gcall@phx.mcd.mot.com             CAUSE: Preserve the 2nd amendment
DISCLAIMER: I don't speak for Motorola.  Everything herein, heretofore, and
hereafter is purely my opinion.
Newsgroups: comp.sys.m68k
From: misch@rbhp90.rbg.informatik.th-darmstadt.de (Clemens Misch)
Subject: Re: MIPS/MFLOPS ratings
Originator: misch@rbhp90.rbg.informatik.th-darmstadt.de
Date: Mon, 06 Apr 1992 08:25:07 GMT
Reply-To: misch@rbhp90.rbg.informatik.th-darmstadt.de
Organization: Rechnerbetriebsgruppe FB20; TH Darmstadt (Germany)


In article <Adr7iji00WB8Mn3Whx@andrew.cmu.edu>, rh2y+@andrew.cmu.edu (Russell E. Hoffman, II) writes:
> From several people:
> 
> Oh, and for any interested parties, I have heard tell of a 68040 OS9/68000
> box doing just over 26,000 dhrystones/sec.
> 
FYI, here are the ratings for a HP 9000/400t, 68040 25Mhz:
Dhrystone 2.1 (C-Language)

	cc -O -DREG=register:    ~30000	(HP's C_MIN compiler)
	gcc -O -DREG=register:   ~28800	(gcc 2.1)

The difference is due to superior loop-unrolling in the native cc. If
you leave out -O then the ratings drop to about 17000 dhrystones/sec.

I do not know how many waitstates the RAM needs, but guess it is near zero.
===============================================================================
Clemens Misch                                        Rechnerbetriebsgruppe FB20
                                                     Merckstrasse 25 
EMail: misch@rbhp90.rbg.informatik.th-darmstadt.de   W6100 Darmstadt (Germany)
Tel.: +49 6151 163514
===============================================================================
-- 
===============================================================================
Clemens Misch                                        Rechnerbetriebsgruppe FB20
                                                     Merckstrasse 25 
EMail: misch@rbhp90.rbg.informatik.th-darmstadt.de   W6100 Darmstadt (Germany)
Newsgroups: comp.sys.m68k
From: gudjm@uniwa.uwa.edu.au (D John McKenna)
Subject: Re: fast reversal of a bit field
Organization: University of Western Australia
Date: Thu, 9 Apr 1992 08:00:04 GMT

joberreu@sumax.seattleu.edu (Jesse Oberreuter) writes:

>ROL a bit out of one number and ROR it into another, or ROR , ROL.

I won't flame you for this, since you didn't have the manual with you...
but to shift the bit into the destination register, you use ROXL/R - the
X means extend, and shifts a 33 bit register made of the register and
the carry flag.

>     The carry holds the bit being shifted between rotates.  Instead of
>sending the bit into the next var the opposite way it came out, send it
>in from the same direction, reversing the bit order.  Be sure to shift all
>8/16/32 bits (size of vars)!

A neat way of doing the count - 
     
     moveq #1,d1
     (you may need to clear carry here. not entirely sure)
loop roxr.l #1,d1
     roxl.l #1,d0
     bne loop
exit ...

The first time through the loop sets the high bit of the source. Since
the destination now contains all 0 bits, each time through the loop will
cause another bit of the source to become 0 - on the last time through,
and only then, the source will become 0, and the loop will end. There
may be an obi-wan error in that code, but I don't think so. Check it
first - any corrections it needs will be fairly simple.
But yes - the best way to do this type of thing is lookup tables. Only
way to fly:
  for i:=0 to num_bytes-1 do
    dest[num_bytes-1-i]:=table[source[i]]
if you've got lots of memory to spare, you can even go word-by-word.
If the field-width is not a multiple of 8 or something nice like that,
then you've got problems, and would probably be better off with a loop -
a proper counting loop.

John West
-- 
gudjm@uniwa.uwa.edu.au  For the humour impaired: insert a :-) every 3 words
Newsgroups: comp.sys.m68k
From: skipper@motaus.sps.mot.com (Skipper Smith)
Subject: Re: MVME167 - '040 Processor Clock Rate?
Organization: Motorola Semiconductor, Austin, Texas
Date: Thu, 16 Apr 1992 16:07:02 GMT

In article <1992Apr16.074941.8434@tscs.com> gerard@tscs.com (Stephen M. Gerard) writes:
>What are the current clock rates available for the Motorola MVME167 board?
>
>I am considering upgrading a 33MHz MVME141 board and would like to get the
>fastest processor available.
>
>Thanks in advance.
>
>Stephen Gerard  -  Total Support Computer Systems  -  Tampa  -  (813) 876-5990
>E-Mail: gerard@tscs.tscs.com				   FAX: (813) 871-2783
>US-MAIL: Post Office Box 15395 - Tampa, Florida  33684-5395

Motorola MicroComputer Group will be shipping production quality MVME 167 
boards at 33 MHz in August.  If you are willing to work with beta, you can 
get them now (assuming you meet their requirements to receive beta boards).


-- 
Skipper Smith                             | skipper@wmtowdc.sps.mot.com
Motorola Technical Training               | 8945 Guilford Rd  Ste 145  
All opinions are my own, not my employers | Columbia, MD 21046
From: joberreu@sumax.seattleu.edu (Jesse Oberreuter)
Newsgroups: comp.sys.m68k
Subject: Re: fast reversal of a bit field
Date: 9 Apr 92 03:21:08 GMT
Organization: Seattle University, Seattle WA

In article <1992Apr8.124215.19063@icf.hrb.com> els@icf.hrb.com (Eric L. Schott) writes:
>In article <4084@sumax.seattleu.edu>, joberreu@sumax.seattleu.edu (Jesse Oberreuter) writes:
>> In article <bnell.702662114@ferrari> bnell@ferrari.siemens.com (Bill Nell) writes: 

>>
>> ROL a bit out of one number and ROR it into another, or ROR , ROL.
>> 

>Use a 256 byte lookup table, with each byte you want to reverse as
>an index into the table.  This is significantly faster than the above
>16 rotates for each byte (eight out and eight in).
>Eric L. Schott, HRB Systems, Inc.   814/238-4311
>  Internet: ELS@ICF.HRB.COM

     I considered this, but I thought the solution too obvious...  If 
you can spare 512 bytes or so (not often a problem :), this does work 
VERY effectively!

                                    Jesse Oberreuter
                                    joberreu@seattleu.edu



-- 
A signature file is not a complicated thing!  Why won't mine work?
From: green@eniac.seas.upenn.edu (Bradley Green )
Newsgroups: comp.sys.m68k
Subject: Sorry about last
Date: 7 Apr 92 23:57:47 GMT
Article-I.D.: netnews.73158
Organization: University of Pennsylvania

Sorry about that last posting.  I'm still getting used to this network stuff.

Brad
From: els@icf.hrb.com (Eric L. Schott)
Newsgroups: comp.sys.m68k
Subject: Re: fast reversal of a bit field
Date: 8 Apr 92 17:42:15 GMT
Article-I.D.: icf.1992Apr8.124215.19063
Organization: HRB Systems, Inc.

In article <4084@sumax.seattleu.edu>, joberreu@sumax.seattleu.edu (Jesse Oberreuter) writes:
> In article <bnell.702662114@ferrari> bnell@ferrari.siemens.com (Bill Nell) writes:
>>Does anyone know a fast way of reversing the bits in a 16 or 32 bit
>>number?  What I mean is if you start of with 011010 (for example)
>>to change it to 010110.  Right know I am just doing a simple rol.l
>>checking the carry flag and setting a bit in a temporary register
>>					Thanks,
>>					Bill
> 
>      I haven't done any 68000 yet (waiting for the rest of my MM/1), but
> (pulling out my 68000 Moto manuals), why not do it the 6809 way:
> 
> ROL a bit out of one number and ROR it into another, or ROR , ROL.
> 
>      The carry holds the bit being shifted between rotates.  Instead of
> sending the bit into the next var the opposite way it came out, send it
> in from the same direction, reversing the bit order.  Be sure to shift all
> 8/16/32 bits (size of vars)!
> 
>                                           Jesse Oberreuter
>                                           joberreu@seattleu.edu

Use a 256 byte lookup table, with each byte you want to reverse as
an index into the table.  This is significantly faster than the above
16 rotates for each byte (eight out and eight in).  For 16/32 bytes,
just switch bytes while doing the lookup.  (I.e., for D16:
    dest[even] = lookup[source[odd]]
    dest[odd]  = lookup[source[even]]

-- 

Eric L. Schott, HRB Systems, Inc.   814/238-4311
  Internet: ELS@ICF.HRB.COM