On Dec 23, 2025, at 10:34 PM, Mike Begley <spam%hell.org@localhost> wrote: I have an AUI port on my machine (in an expansion card), and when I use that rather than the I am able to successfully get to the point where it keeps asking over and over for the different netbsd kernels, over & over (as opposed to using thinnet, where it just hangs on the le0a carrier lost errors). Can I use the AUI port to deliver the kernel (and the rest of the filesystem) via nfs? ChatGPT claimed that the SYS_UBOOT bootstrap loader would only work on the thinnet network connection...but was it hallucinating on this? As an aside, ChatGPT suggested that Version D ROMs would allow the bootloader to select other LAN interfaces. Also, totally a hallucination? I believe I have Version C ROMs, by the way. The thing about LLMs is that *all they do is hallucinate*. Sometimes what they hallucinate happens to correspond somewhat to reality, in quite a few cases it doesn’t. I don’t use them out of principle and this should help inform your future decisions as to whether to have anything to do with them. I don’t know specifically about whether only the 10Base-2 interface would work with SYS_UBOOT though I strongly suspect that’s not the case. (It’s also almost certainly possible to strap your 360 to ignore built-in LAN.) Similarly, the 9000/300-series version C boot ROMs should be fine, I’ve netbooted many HP-9000/300 systems with version C ROMs. In my experience, for booting NetBSD on HP 9000-300 series, all you need is the remote management protocol server to serve SYS_UBOOT to the HP firmware, a static DHCP server entry to give SYS_UBOOT an IP address and tell it what NFS server, kernel path, and root filesystem to use, and an NFS share that can serve both the kernel and the root filesystem to SYS_UBOOT on your HP. One thing you might also wind up needing to do is modifying the /etc/rc you use on your HP to attach swap first thing, if you have under (say) 16MB of RAM. The last time I tried an 8MB system (a 9000/332) I got a panic partway through /etc/rc due to running out of RAM. Personally, I think we should put back the mounting of NFS swap (as specified by DHCP/bootparams) immediately after the root filesystem to handle cases like this, so /etc/rc doesn’t need to be modified. Totally unrelated: I found in my stash a video board for which I have no idea what monitors it drives. It's not a bunch of BNC connectors, but a 9-pin connector. I don't have the model number on me right now, but when I looked for it on the intertubes I the only reference I could find referred to it as a monochrome graphics framebuffer. Does this right a bell for anyone? I wonder if this is used to drive an early PC MGA or CGA monitor, or one of the touchscreen monitors that HP was selling. I can get the model number later this evening. It’s absolutely not going to be any of the archaic PC equivalent display; in those days, HP was using an RCA jack for mono video at 1024×400 (text, 512×400 graphics). If it’s a larger DIO-II board, it’s almost certainly mono (or grayscale) 1280×1024 at close to VESA refresh rates. I’m not sure offhand whether it’d use RS-170, TTL, or ECL logic levels for the video; I expect the card manual will have a pinout and signal level details, check the HP Museum and Bitsavers. If it is RS-170, it’d be trivial to make yourself a DE-9 to DE-15 VGA adapter, just put the mono signal on green and you’ll get a lovely mono green display on your LCD of choice. (Or if it’s a fancy one, like the NEC LC1990SX that I love, you can use the secret advanced config menu to specify you’re using mono on green and have it render that as white.) — Chris |