[ moved to tech-kern. please don't include surrent-users in replies ]

On Aug 22, Ken Nakata wrote
> Why not?  In host byte order (BE) "NetBSD is cool" becomes in IDE bus
> byte order "eNBtDSi soclo" if the bridge's byte-swapping is cancelled
> out.  This is not cool.

No. Without byte swapping, strings are still the same. You get this with
the byte-swapping. byte-swapping is only needed for integer values.
If you want to read data from the disk, you need to get them in
the order they were stored on the disk. It's up to the filesystem
to do the rigth thing with integers if needed, and nothing is never needed for
strings.

> 
> The "raw" byte-order will not be correct if the bridge's byte-swapping
> is cancelled out!  Am I saysing something strange?

It will be correct ! 'raw' means that you get it in exactly the same
order it is on the device !
That is, if you write "NetBSD" on the 6 first bytes of the first sector
of you hard disk on an i386 (with a stream function, but stream and non-stream
are the same here), you will get NetBSD if you read it with
the stream functions on your mac. You will get "eNBtDS" if you read it with
the non-stream function.

> 
> What bios?  Macs don't have the BIOS in the sense i386 does.

BIOS, firmware, or whatever you call the thing that makes the machine
boot from disk at power on.

> If you
> are talking about i386, thie is all moot since i386's host byte order
> coincides the IDE bus byte order.

Yes, so the stream and non-stream functions do the same thing, i.e nothing.

> 
> How do I get it?

You need to patch -current with the patch from
ftp://ftp.netbsd.org/pub/incoming/bouyer/

> 
> > (the stock -current ATA/ATAPI driver doesn't work properly with the on-board
> > controller on the atari).
> 
> Ah ha!  I was mislead (perhaps by myself) to believe that it does.

ATA works, but not ATAPI (I think no-one tried an ATAPI device on an ATARI
until recently :) .

> It does not.  The wiring I described in my previous post is
> hard-wired.  I have no choice; it's Apple engineer's.

So the stream functions need to byte-swap, as on the ATARI.

> 
> No, it does not (unless bus_space_read_multi_2() does), since ntohs()
> does nothing on m68k.

Sorry, I got my mind fooled:
for WDCC_IDENTIFY or ATAPI_IDENTIFY_DEVICE, the ATA/ATAPI specs require
the strings to be byte swapped (that is, a drive would return
"eNBtDS" for "NetBSD").
On big-endian system you don't need to byte-swap it because
bus_space_read_multi_2() is supposed to do it (so, in your case,
doesn't do it because the bridge does). On i386 the ntohs() is needed for
the strings.

> 
> > In theory, whe should use stream access here, and then byte-swap the
> > numeric fields. But as all the fields in sc_params are 16bit quantities,
> > exept the strings, it's simpler to do 16-bit byte-swapping access and
> > restore byte-order of the strings.

And the stings too, because letter are swapped ! I was wrong here.

> 
> "16-bit byte-swapping access"?  On mac68k and Mac IDE i/f, the bus
> bridge does byte-swapping but not the bus_space_read_multi_2()
> functions.  Does this count as "16-bit byte-swapping access"?

Yes

> If so,
> why does it not work? (I had to add a piece of code that byte-swapps
> every word in the parameter block)

By 'word' I think you mean 16-bit quantities, not "strings".
Would it be possible that the bridge snoops the command register, and
does selective byte-swapping, based on the command you issued ?

> 
> Yes, it is hacky, but I don't think it's the source of my confusion.

It was for me, at one time :)

> Am I misunderstanding the meaning of the term "byte-swapping"?  I
> thought it was said to be byte-swapping when the I/O bus' upper and
> lower bytes were wired to the host bus' lower and upper bytes
> respectively.

It's what I understand too.

> 
> Why do I have such a problem understanding something which other
> people have no to little problem understanding?  I feel like I'm an
> idiot.

If this can help you, I needed a lot of time and aspirine when Leo Weppelman
and I worked on the ATARI problem :)

--
Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer@lip6.fr
--