Okay all I appreciate the suggestions, but im going to have to say its 
not the disks! ive disconnected them, they are internal, and the same 
results, can someone running netbsd on a sun tell me whats probed right 
after the frame buffer ?? because i suspect thats whats causing the 
problem. Either that or its the frame buffer itself, Ive tried also 
OpenBSD on this thing also and it crashes at the same point, right after 
the frame buffer. Yet linux, and solaris run happily on this unit. yet i 
want a BSD, call me die hard, but BSD rocks, though apparently not in 
this case. its funny to see it ( BSD) capable of running on an amiga and 
odd things alike, but cant get it to boot here. By the way, this thing 
has onboard isdn, not that it matters but.

>>>|> bwtwo at sbus0 slot2 offset 0x0 level 9:sunw,501-1561, 1152x900 console
>>>|>
>>>|> it goes baserk!
>>>
>>>I had a Sparc-10 panic at that point when I tried to use a Quantum
>>>Fireball TM hard drive. The 10's Fast SCSI controller, NetBSD's
>>>driver, and the notoriously bad SCSI implementation of that disk
>>>just didn't go together. That same disk works fine in a Sparc-2.
>>>
>>Looks like the 10 is special in that respect...
>>
>>About the same story here with two 4G Quantum Atlas III disks that ran
>>happily in a SS2 with NetBSD, run happily in the SS10 with Solaris 7&8 but
>>swamped a NetBSD 1.5 kernel with "bad parity" messages so that it barely
>>made it to multi-user.
>>
>
>
>Hmmm... just out of curiosity, I assume these drives are *internal*?
>If external, they really **should** be terminated.  And, running
>Fast SCSI might even need to be terminated if they are *internal*
>(assuming you don't have something else external that terminates).
>
>It could be that NBSD hammers on the SCSI bus a bit more and, at
>the higher data rate, might lead to some ringing in a poorly
>terminated cable... (?)
>
><shrug>  It's an easy "fix" to try...
>
>--don
>