>> [...speculation...questions...] > the SS4 and SS20 both have on-board video, You've got a cg14? Nice! (What does the SS4 have onboard? It's been too long since I worked with one.) > the SS10 has a card in it. All 3 have no video, no keyboard > connected. Shouldn't serial console be fall-back when no keyboard is > detected? Yes, in general the ROMs will fall back to serial console when no keyboard is present. (The kernel uses the ROM's console spec in my experience, but, even if that's changed in the versions you're using, you should get serial console for OBP at least.) > On my SS20 I see: > output-device=screen > input-device=keyboard > I have the same on my SS4. Okay, so that's not it. What do they have diag-switch? set to? I think if diag-switch? is set true then OBP will talk to ttyb regardless of the ordinary console setting, so if you're using the B connector on your Y cable and the '10 and '20 have diag-switch? set true but the '4 doesn't that might have some relevance. Also, what are ttya-mode and ttyb-mode? In general, the wrong baud rate just produces baud barf. But, if the mismatch is extreme enough, you can get nothing but 0x00 or 0xff octets, which might look like no output. Another possibility is that the serial output driver on the '4 is fried. If you boot it and write to the serial ports from NetBSD, do you get any output? > I tried setting input and output device both to ttya, but no avail. > I end up with a black screen if I attach a monitor... so the > parameters do something, but not what I expect.. seems like serial is > somehow dead/different. That sounds like what I'd expect if the output driver is dead: no video init but still no output. Try using ttyb instead (and the other arm of the Y cable), maybe? If the output driver is dead, it's moderately likely the other port is fine. > Luckily I still have the 113W3 cable, even if the LCD Monitor doesn't > properly sync the size like the old CRTs, so the last line is > missing... but enough to test and boot. Yes, that's one of my beefs with flatscreens. In the old days, the computer chose the video output signal parameters and the monitor had to adapt (or, if it couldn't, at least indicate that fact somehow, such as by displaying a synthetic "input out of range" screen). Now, the monitor declares (via EDID, I think the name is) what video signals it can handle, and the computer is expected to generate one of them. This, of course, produces interoperability fails in both directions. (While it is not, strictly, connected to the switch to flatscreens, it happened at about the same time; in my experience, the correlation "CRT can autosync; flatscreen can't" is extremely strong.) Of particular relevance now, old video hardware such as the cg6 and cg14 have a very limited list of video modes they can run in. (The cg14 is capable of more than the ROM-provided modes, but it's still fairly restricted as compared to the peecee video that the modern "monitor dictates the video parameters" model seems to be expecting.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse%rodents-montreal.org@localhost / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B