Cascade Complete Gel may not be good enough

Recently the dishwasher started washing later than it should. Instead of spraying sounds starting early while it was filling, the sounds often started when filling was almost completed, and about a third of the time a few tens of seconds after filling was complete. It never failed to start, but still, this wasn't totally okay. I was wondering if the repair I made over a year ago somehow failed, though the symptoms weren't identical.

I had been using Cascade gel detergent. First it was in a bright green bottle, though over the last few years it was replaced in stores by Cascade Complete Gel. Though I had some Cascade Platinum for use if the gel ran out. Recently I was buying the gel ahead of time, and I hadn't used Platinum in almost a year. I ran out of gel and used Platinum once, and since then, the dishwasher always starts spraying early on while filling. This makes me think that some greasy residue had been making something sticky, and Platinum cleared it out. I don't think it was hard residue, because I don't think that would have been cleared out so quickly.

Since I didn't disassemble the dishwasher and actually see the residue, I can't be certain. This could be a random coincidence. But I am changing detergents.I also didn't like Cascade Complete Gel because it left hard residue below the detergent dispenser. That was not simply hard water residue, because so much of it was collecting below the detergent dispenser. Reading about dishwasher detergents, it also seems that since the reformulation to remove phosphates, gel detergents are the worst because they're not able to use enzymes.

I give up on running recent NetBSD on old hardware

NetBSD is an amazingly cross platform operating system. It also supports some very old hardware, such as most of the first small VAX systems. However, software in general gets bigger and slower over time. I recently tried to run NetBSD 9.1 on my KA650 based MicroVAX with 16 MB of RAM. It takes about 12 minutes to boot to a login prompt in multi-user mode with a stripped down configuration. It doesn't seem like there's any single reason why things are so slow, and comparing various NetBSD releases, I see things slowed down gradually. So I don't see hope for reasonable performance, and I give up on running NetBSD there.

I also couldn't run NetBSD 9.1 on my SPARCstation ELC. It has 16 MB RAM, but the real problem is that each of the 4 MB memory modules are isolated in the address space, and the kernel needs to fit in one of the modules. Probably I could run NetBSD 9.1 if I had bigger memory modules, but I expect the experience would be disappointing.

This isn't meant to be a complaint about NetBSD. The same trend has been followed by other operating systems, and software in general. I still feel it's a bit sad. I'm not sure that the bloat offers a proportional improvement in functionality. But computers have gotten so much faster, storage has gotten so much bigger, and it has all gotten cheaper, so it's not really a problem in practice.

Finally, here's a boot log of that KA650 based MicroVAX. The first number is the number of seconds from the start, and the second number is time since the previous line.

  0.00   0.00  >> NetBSD/vax boot [1.12 (Sun Oct 18 19:24:30 UTC 2020)] <<

  4.91   4.91  >> Press any key to abort autoboot 0

  4.93   0.02  Trying BOOTP

  4.97   0.05  Using IP address: 192.168.1.4

  5.00   0.03  myip:  (192.168.1.4)

  5.06   0.06  root addr=192.168.1.42 path=/srv/nfs/vax/netbsd/anoat

  5.56   0.50  open netbsd.vax: No such file or directory

  5.58   0.02  > boot netbsd

 36.93  31.34  2043220+79088 [169744+162143]=0x25768c

 57.60  20.67  [   1.0000000] Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005,

 57.70   0.10  [   1.0000000]     2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015, 2016, 2017,

 57.80   0.10  [   1.0000000]     2018, 2019, 2020 The NetBSD Foundation, Inc.  All rights reserved.

 57.87   0.07  [   1.0000000] Copyright (c) 1982, 1986, 1989, 1991, 1993

 57.97   0.10  [   1.0000000]     The Regents of the University of California.  All rights reserved.

 57.97   0.00  

 58.05   0.08  [   1.0000000] NetBSD 9.1 (ANOAT) #1: Thu Nov 19 22:04:31 EST 2020

 58.11   0.06  [   1.0000000] root@:/usr/src/sys/arch/vax/compile/ANOAT

 58.16   0.04  [   1.0000000] MicroVAX 3500/3600

 58.22   0.06  [   1.0000000] total memory = 16328 KB

 58.27   0.05  [   1.0000000] avail memory = 13032 KB

 60.40   2.13  [   1.0000000] mainbus0 (root)

 60.49   0.09  [   1.0000000] cpu0 at mainbus0: KA650, CVAX microcode rev 4 Firmware rev 83

 60.55   0.06  [   1.0000000] lance at mainbus0 not configured

 60.61   0.05  [   1.0000000] uba0 at mainbus0: Q22

 64.54   3.94  [   1.0000000] sgmap exclusion at 0x3f0000 - 0x3fdfff

 64.96   0.42  [   1.0000000] uda0 at uba0 csr 172150 vec 774 ipl 17

 65.43   0.47  [   1.0000000] mscpbus0 at uda0: version 4 model 3

 65.48   0.05  [   1.0000000] mscpbus0: DMA burst size set to 4

 72.80   7.32  [   1.0000000] uda1 at uba0 csr 160334 vec 770 ipl 17

 79.99   7.19  [   1.0000000] mscpbus1 at uda1: version 6 model 13

 80.05   0.06  [   1.0000000] mscpbus1: DMA burst size set to 4

 82.49   2.44  [   1.0000000] qe0 at uba0 csr 174440 vec 764 ipl 17: deqna, hardware address 08:00:2b:XX:XX:XX

 82.69   0.20  [   1.0300080] ra0 at mscpbus0 drive 0: RD53

 82.74   0.06  [   1.0600080] ra1 at mscpbus0 drive 1: RD32

 82.80   0.06  [   1.0900080] rx0 at mscpbus0 drive 2: RX50

 82.86   0.06  [   1.1200080] rx1 at mscpbus0 drive 3: RX50

 88.46   5.60  [   1.1900080] boot device: qe0

 88.50   0.04  [   1.1900080] root on qe0

 88.55   0.05  [   1.1900080] nfs_boot: trying DHCP/BOOTP

 91.68   3.13  [   4.2200080] nfs_boot: DHCP next-server: 192.168.1.42

 91.73   0.05  [   4.2200080] nfs_boot: my_addr=192.168.1.4

 91.79   0.06  [   4.2200080] nfs_boot: my_mask=255.255.255.0

 91.84   0.05  [   4.2200080] nfs_boot: gateway=0.0.0.0

 98.20   6.36  [  10.3300080] root on synthesis:/srv/nfs/vax/netbsd/anoat

 98.24   0.05  [  10.3300080] root file system type: nfs

 98.31   0.07  [  10.3300080] kern.module.path=/stand/vax/9.1/modules

 98.39   0.08  [  10.3400080] TODR too smallWARNING: preposterous TOD clock time

 98.45   0.05  [  10.3400080] WARNING: using filesystem time

 98.50   0.05  [  10.3400080] WARNING: CHECK AND RESET THE DATE!

122.88  24.38  Fri Nov 20 04:01:44 UTC 2020

155.75  32.87  Not checking /: not listed in /etc/fstab

162.67   6.92  mount: Unknown special file or file system `/'

177.78  15.11  Starting file system checks:

204.22  26.44  random_seed: /var/db/entropy-file: Bad file system type nfs

205.15   0.94  /etc/rc.d/random_seed exited with code 1

208.30   3.14  Setting tty flags.

218.78  10.49  Setting sysctl variables:

221.91   3.13  ddb.onpanic: 1 -> 0

226.99   5.08  Starting network.

227.28   0.29  Hostname: anoat.tff.ca

243.03  15.75  Configuring network interfaces:.

243.75   0.72  Adding interface aliases:.

245.54   1.79  Waiting for DAD to complete for statically configured addresses...

347.59 102.05  Building databases: dev, utmp, utmpx.

369.39  21.81  Starting syslogd.

428.49  59.10  Mounting all file systems...

444.08  15.59  Clearing temporary files.

460.34  16.26  Creating a.out runtime link editor directory cache.

546.65  86.31  Setting securelevel: kern.securelevel: 0 -> 1

558.94  12.29  /etc/rc: WARNING: No swap space configured!

559.65   0.71  /etc/rc.d/swap2 exited with code 1

562.11   2.46  Starting virecover.

581.65  19.54  Checking for core dump...

585.27   3.62  savecore: no core dump (no dumpdev)

607.05  21.78  Starting local daemons:.

616.16   9.11  Updating motd.

704.94  88.78  Starting inetd.

719.23  14.28  Starting cron.

735.03  15.80  The following components reported failures:

735.07   0.05      /etc/rc.d/random_seed /etc/rc.d/swap2

735.13   0.05  See /var/run/rc.log for more information.

735.26   0.14  Fri Nov 20 04:11:44 UTC 2020

741.85   6.59  

741.90   0.05  NetBSD/vax (anoat.tff.ca) (constty)

ULTRIX 4.00 problems writing to devices hosted on a Linux NFS server

When the VAX ULTRIX 4.00 Rev. 158 /usr/diskless/genvmunix kernel does a non-appending write to a device, like "echo foo > /dev/console", that fails if the device is located on a x86_64 Ubuntu 20.10 Linux 5.8.0-25-generic NFS server.

ULTRIX seems to be at fault. It sends an NFS V2 SETATTR call setting the length of that device file (eg. /dev/console) to zero, and that fails. This behaviour was observed after netbooting ULTRIX, on the root NFS file system, and is a problem for running netbooted ULTRIX. Even if I mount another NFS file system read-only, ULTRIX still sends the SETATTR there. Surely it shouldn't be trying to change things on a file system that's mounted read-only! 

Use of SETATTR to truncate a file is standard behaviour when overwriting a file, like "echo foo > bar". In that case it works fine on a writable file system. Also, ULTRIX doesn't make attempts to change ordinary files on read-only mounted NFS file systems.

Appending to devices, like "echo foo >> /dev/console" works properly, both on writable and read-only file systems. 

Installing MIT Project Athena 4.3BSD onto a VAX

Athena 4.3BSD is an MIT modification of 4.3BSD for their Project Athena distributed computing environment. Although it is designed to work in such an environment, it can be installed and used on a single machine. A few things do break, but there are ways around that.

First, you need the Athena 4.3BSD srvd tree, and a way to boot the VAX into a minimal environment. Both are available via http at those links, though if you want proper Unix permissions and ownerships, you should download srvd via AFS if possible.

You also may need a VAX. I have successfully installed on a VAXstation 2000, MicroVAX II, and VAXstation 3100 m38, but I have not successfully installed in simh yet. Though the RD53 drive image from the MicroVAX II does work in simh.

Export the srvd tree read-only via NFS, using a server which accepts version 2 NFS and mountd protocols. In Linux you can add --nfs-version 2,3,4 to nfsd and mountd options. In Ubuntu and probably also Debian, in /etc/default/nfs-kernel-server add --nfs-version 2,3,4 to both at the start of RPCNFSDCOUNT (because RPCNFSDARGS won't make any difference) and in RPCMOUNTDOPTS.

I have not mastered netbooting yet. The first stage seems to be etftp loaded via MOP, but then it seems you cannot simply TFTP load the kernel and expect it to run, and I'm not sure the kernel supports root over NFS. If interested take a look at the vax650 folder in bootkit and the LORE file there. In this case, I'm using an RX33 floppy image from bootkit, 61+.floppy, to boot a VAXstation 2000. That's an ordinary 5.25" 1.2 MB floppy image, which can be written on a PC using dd or rawritewin. Maybe you could netboot NetBSD/VAX on the same VAXstation 2000 and write from there, but I don't know which version has working floppy support.

If not using an attached display and keyboard, hook up the serial console. The VAXstation 2000 uses 9600 baud. The initial steps seem to be 8-N-1, but later on the OS switches to 7-E-1, meaning you'll see lots of characters with the high bit set if you don't reconfigure your terminal emulator.

After booting from the floppy, you'll see kernel output, a few lines from the startup script, a big warning that this destroys the contents of the hard disk, and a prompt for the hostname. I don't believe you can get past this prompt, because it relies on Athena infrastructure to query the hostname. So just control-C out of that. Then you get a prompt. It's a very minimal environment, without even ls.

Now you need to configure networking and mount the srvd tree via NFS. You need to use get_pack to mount via NFS, because mount doesn't seem to understand it. Change the network device name and IP addresses as needed. Note that the NFS server address and path are separate arguments, and not connected with a colon like you would use with mount.

# stty erase ^H
# ifconfig se0 192.168.1.5
# get_pack nfs 192.168.1.42 /srv/nfs/vax/athena/srvd /srvd
/srv/nfs/vax/athena/srvd server ok
/srv/nfs/vax/athena/srvd mounted on /srvd

At this point you could run stuff from /srvd if you wanted and explore. Note that the root filesystem is on a floppy and there is little space and few inodes available there. To continue the installation, you need to set some variables and run the phase 2 installer.

# MACH=VS2000
# save_site_flag=false
# . /srvd/install/phase2.sh

Actually, you might want to first look at phase2.sh, because it assumes some things. For me it was a perfect fit because it assumed the disk was an RD32, but you might have a different hard disk. Also, if your VAX has multiple hard disks, and you want to install onto a particular one, be careful. Remember the front panel write protect buttons.

The installer worked fine, except umount didn't work, and at the end I got a "/dev/rrd0a: DIRECTORY /etc/athena: LENGTH 1040 NOT MULTIPLE OF 512 (ADJUSTED)" warning. This should put a bootable system on your hard disk, but some customizations are needed for a successful multi-user boot. If you try to boot you'll get errors which might be mostly unreadable over serial because new console output starts before old output is finished, making network configuration failure look like "Setticannot opeUnablePleaseHaltinsyncing disks... done". If you do end up in that situation, boot with "b/2 dua0" to enter single user mode and fix things from there.

Since /etc/athena/rc.net relies on Athena infrastructure, I replaced that line in /etc/rc with just a simple "/etc/ifconfig se0 192.168.1.5". Also, change the configuration in /etc/athena/rc.conf. You can set everything false except for NFSCLIENT if you need it to mount srvd. In particular AFSADJUST takes a long time or maybe never completes, and needs to be disabled.

The installer only creates the root filesystem and a site filesystem for local storage. Most of the operating system is in the srvd tree, which will need to be read-only mounted at /srvd. If you don't have space to put it somewhere on the VAX, again mount it via NFS. Add the hostname of the server to /etc/hosts, and add the line for mounting it to /etc/fstab. You can't mount via IP address in fstab.

In /etc/ttys, there are lines which either start an X display manager or getty in text mode. Booting the VAXstation 2000 from serial, X fails to start. This means a wait for a timeout before getting a login prompt. Commenting out the /etc/athena/dm line for console and uncommenting the /etc/getty line fixes that.

You can get rid of the root password by removing the 2pEdLRdD8rMnk from /etc/passwd. (Documents about Athena say the root password of workstations is identical and not secret, but I don't know what it is.) Trying to set a new password via passwd doesn't work because it wants to talk to a Kerberos server.

That should be it. You now have a VAX which runs Athena 4.3BSD. You can even run X on a VAXstation or a KA630 MicroVAX with QDSS. (The KA650 kernel doesn't include QDSS support, though the bootkit one seems to have it.) It's leaner than NetBSD, even working fine on a VAXstation 2000 with 4 MB RAM.

AT motherboard serial connector pinouts can differ between motherboards

Older AT format motherboards don't have a back panel with many connectors, like an ATX motherboard. The only direct external connection is for a keyboard. Many motherboards have onboard serial and parallel ports. These connect to the outside via ribbon cables which go to standard connectors. The standard connector is mounted on an expansion slot cover or elsewhere on the case (so slots aren't wasted for this), and the ribbon cable connects to the motherboard.

Different motherboards can have the same ribbon cable connectors for serial and parallel ports. However, the pinout of those connectors differs, and swapping motherboards may require swapping those connectors.

ATI Mach 64 GX character generator failure

This is an PCI video card from ATI, based on the 210888GX00 Mach64 chip. I think it's a Graphics Pro Turbo. It is only designed to accelerate the Windows desktop, and was released well before 3D cards became common. To the right you see a 2 MB VRAM expansion board which plugs into the main board.

Here's the image produced by the card:

Note that this isn't just random garbage. It is a text mode screen. Some characters are blank and the rest are all the same horizontal lines. Colours are still there. This is a BIOS startup screen. At the top right you would see the Energy Star logo in yellow and EPA pollution preventer in green. Those graphics are created in text mode by changing some characters of the font and putting them there. So, both standard and user defined characters are wrong the same way.

It's weird that such a card failed while sitting unused in a PC for a long time. I don't know what's wrong with it. If anyone knows, leave a comment.

An ugly fix for on ODIN OEC12C887A RTC

The Odin OEC12C887A chip contains a battery backed real time clock and a small amount of battery backed RAM. The battery and the crystal needed for this are part of the chip. Many old motherboards use these chips, and have them soldered onto the board. Of course, batteries don't last forever, and when they fail, motherboards lose the time, date and settings. Unfortunately it seems settings cannot be retained even while the PC is on. After applying settings, the BIOS reboots and then reports they're invalid. Some motherboards can function this way, with problems related to few settings, like floppy drive type. Others may not allow you to boot.

Then the proper fix is to unsolder the chip, solder a socket, and put a new chip into the socket. Though it's also possible to drill into the chip and connect a new 3V lithium non-rechargeable battery, such as a CR2302. I don't have a Dremel or equivalent, so I used a soldering iron. The result is ugly but it works. Here is a photo of the chip with exposed connections:

You can see 5 metal pieces among the melted plastic. Going clockwise you see a pin from the chip, a tiny bit of metal which it was pried away from (which connects to the bottom of the battery), the top of the battery, a bit of metal connecting to the top of the battery, and another pin from from the chip which was pried away from that.

To understand this better, imagine a normal dual in-line package (DIP) chip. The pins come out the side and bend downwards, in order to go through holes in the circuit board and connect to the rest of the circuit. In this case, some of the pins instead bend upwards, and connect to the battery and crystal. If you look underneath the board you'll see that some pins are missing, and some or all of those are bent upwards. Probably these devices start off as a typical DIP package, which is then encased in a second layer of plastic after those components are added.

The pinout can be found at https://www.betaarchive.com/forum/viewtopic.php?t=22000, in particular in this image. Pin 16 is negative, and pin 20 is positive. Pin 16 has continuity with motherboard ground. Pin 20 has continuity with the larger surface of the coin cell, which is generally positive. Probably the crystal is connected to pins 2 and 3.

It doesn't smell too bad, and controlling the temperature so it's mostly melting and not burning plastic helps. I'm not going to recommend it because plastic fumes might be unhealthy, and I certainly wouldn't want to do this on a regular basis. But the repair was a success. The PCI slot is fine too, with only very minor cosmetic damage to the outer surface.

Fix for Tseng ET3000AX SVGA card displaying monochrome

This is a Micro-Labs VGA Solution, an ISA super VGA card based on the Tseng Labs ET3000AX. It seems to be a reference design because other brands of cards also exist with the same board layout. It displayed in monochrome on the SVGA monitor.

At first I thought the switches on the back were set incorrectly. They tell the board what kind of monitor is connected and whether it's primary or secondary. They're documented here, but basically they all need to be off. That tells it a that it's the primary card, a "multisync analog monitor" is connected, and a secondary monochrome card may or may not be present. Up, away from the circuit board, is off.

The switches seemed to make no difference. So, I thought the board was broken. But no, the VGA connector standard changed. Those switches only talk about colour and monochrome regarding TTL monitors, using the DB9 connector. The VGA monitor is detected via monitor ID bits according to the old VGA connector standard. The current standard doesn't include those and instead uses an EEPROM providing information about the monitor. It seems that based on what the board detects on those ID bits, it can go into monochrome mode. All the palette entries get transformed via gray-scale summing, making everything black and white. This even happens if you try to set the palette via int 10h.

A software solution is coloron.com, which uses int 10h functions to switch the card to colour mode from DOS. Another solution is to boot with the monitor disconnected. This doesn't only mean power-on, but also if you reboot via the reset button or control-alt-delete. I opted for a hardware solution, cutting the circuit board trace between those connector pins and the rest of the card:

One last thing. The old VGA connector standard has a key at pin 9, meaning no pin there in the male and no hole there in the female. Now that is +5 V DC supplied to the monitor for the identification EEPROM. You might want to drill a hole there in the connector to avoid breaking pins on more modern VGA connectors.