Hey Michael,

(I post this to the list too, it might be interesting to others)

> So, after reading some code I found that the upper 8 bit of the flags control sync negotiation, one bit for each target, a 1is supposed to disable it. The lower 8 bit are apparently unused. I'll compile a new kernel with a few printf()s added to see which flags end up where ( I'll have to shut down X to test it - well, I guess mesh is more important right now ).
> According to the code mesh should NOT try to negotiate sync - either the flags get distorted for some reason or something is really weird. But something else - are you sure your box is a stock 9500? 
Yes, I know that's an odd question, but there are several odd things
about it:

let's check nothing gets distorted. But it seems it gets so, check the
bottom of the message.

Yes I am sure I have a stock 9500! I bought this 9500 with the box, it
was a bargain, but it was new. Mavbe my only "new" box.
Anyway, AFAIK it could be a 9500, a 9600 or a 9600/3x0. It can only be
one of the former because it has the cache soldered on the motherboad,
so it is a Tsunami and not a Kansas board...

Really, I used the box "stock" for a long time under MacOS/MachTen. Only
lately (1 year ago or more) I put in an MGA I bought used from a friend
and the most recent addition was the digital board to get etherent and
now the processor board. I Still have the original left, but I really
think it shouldn't make the difference. Besides I had SCSI and video
trouble with the old CPU too, that one is a fairly recent addition.

> - the kernel doesn't see the 2nd bandit.
maybe nothing is in there ? I remember quite clearly that when I had to
get the string location of the video board to write in the Nvram I saw
both bandits.

> - the MGA ROM is disabled - OF should enable it to be able to use the card as console. Of course the driver may copy itself into RAM and then unmap the ROM but that would be odd. It looks almost as if your OF supports the MGA directly.
Here really, my knowledge of what should happen is equal to 1/X with
X->inf
 
> The debug kernel should appear at the usual spot in the next hour or so.
 
> have fun
well, lately the "fun" gets headache :)

Ahh, the Kaffe JavaVM seems to work now again on NetBSD/ppc. We might
get some java after all. I think that if someone uses NetBSD more
professionally this could be good news.

Hey, the output is very nice. The kernel seems to IGNORE the flags and
negotiate anyway

wsmouse0 at ams0 mux 0
mesh0 at obio0 offset 0x18000flags: ffff
disabling sync negotiation for target 0
disabling sync negotiation for target 1
disabling sync negotiation for target 2
disabling sync negotiation for target 3
disabling sync negotiation for target 4
disabling sync negotiation for target 5
disabling sync negotiation for target 6
flags: ffff
disabling sync negotiation for target 0
disabling sync negotiation for target 1
disabling sync negotiation for target 2
disabling sync negotiation for target 3
disabling sync negotiation for target 4
disabling sync negotiation for target 5
disabling sync negotiation for target 6
 irq 13: 50MHz, SCSI ID 7
scsibus1 at mesh0: 8 targets, 8 luns per target
nvram0 at obio0 offset 0x1d000
scsibus0: waiting 2 seconds for devices to settle...
scsibus1: waiting 2 seconds for devices to settle...
sd0 at scsibus1 target 0 lun 0: <QUANTUM, FIREBALL SE4.3S, PJ0A> disk
fixed
sd0: 4110 MB, 7637 cyl, 4 head, 275 sec, 512 bytes/sect x 8418816
sectors
probe(mesh0:0:1:0): max sync rate 10.00Mb/s
sd1 at scsibus1 target 1 lun 0: <IBM OEM, DFHSS4F, 4141> disk fixed
sd1: drive offline
cd0 at scsibus1 target 3 lun 0: <MATSHITA, CD-ROM CR-8005A, 4.0i> cdrom
removable
boot device: sd1