Monday, October 05, 2020

Telequipment D54 oscilloscope bad MPS6518 transistor in sweep-gating bistable

My Telequipment D54 oscilloscope didn't show a trace. Instead, if I turned up brightness all the way there were some very faint blobs which changed a bit with the horizontal position adjustment. If I pulled the plug, the spot appeared coming from the left of the screen. This is similar to when trigger stability has been turned up and it is not being triggered, but stability couldn't make it work and even external X input mode did not work.

The service manual (available at radiomuseum.org) contains schematics and a detailed circuit description.

Clearly the horizontal deflection circuit was pushing the beam all the way to the left. I first removed JFET TR107 and connected a resistor to ground from the sawtooth output. This affected the voltage at the collector of TR108, and the horizontal deflection amplifier worked as expected. But there was still no spot on the screen. I assumed that was due to blanking.

The fact the CRT was blanked and even external X input didn't work made me focus on the sweep-gating bistable built around TR105 and TR106 transistors. After probing it a bit I unplugged TR105, an MPS6518 transistor, and to my surprise the base seemed open circuit. I don't know what made it fail there. Putting in a 2N2907A made it work. This replacement was very easy thanks to the fact all the transistors are socketed. Here's the right side board with the timebase circuitry, a closeup on TR105, and the bad MPS6518 transistor:




For completeness, here's the left side board, with the two channel inputs, vertical amplifiers, and trigger circuitry which provides an input to that sweep-gating bistable:



Friday, October 02, 2020

DEC KA650 (MicroVAX III / 3500 / 3600) error 62 can mean a bad keyboard connected to QDSS

My MicroVAX produced no output via the QDSS. I saw the monitor flash as if the QDSS was initialized, but video output appeared. Instead text went to the serial console of the KA650 CPU board. There, at the start of self test, I saw an error:

?62 2 08 FF 00 0000


According to the KA650 CPU Module Technical Manual, this is:

62 2004 E254 console QDSS mark_notpresent self test r0 self test r1 ****

It appeared at the same time as a keyboard beep. At the end of self tests there was the ominous "Normal operation not possible" warning. Swapping the LK201 keyboard fixed the problem. The keyboard causing the problem had all 4 LEDs lit, while the working keyboard had them all unlit except for a flash during initialization. There is no more error, and QDSS console works fine.

The MicroVAX can still boot NetBSD/VAX 1.3_BETA from the RA90 drive. Digital sure built this stuff to last!

The known failing parts are the RD53 drives. They can spin up with the trick of disconnecting the head actuator coil at startup, but have many read errors. I'll try reformatting them.

Thursday, September 24, 2020

Netbooting SunOS on a SPARC workstation from Ubuntu 20.04

The general procedure for booting a Sun SPARC workstation over the network is well documented. I liked this guide.The post here exists to document ways in which things break in modern Ubuntu and changes which need to be made. I was booting a SPARCstation ELC.

First you need an IP address. It is best to choose a name, add that line to /etc/hosts, and use the name whenever possible.

The boot process starts with the workstation requesting its IP address via Reverse Address Resolution Protocol (RARP). This simply works. Install the rarpd package and put the address in /etc/ethers.

You can now load boot (like kvm/stand/boot.sun4c) or the kernel (kvm/stand/vmunix) via TFTP. Note that the file name is the IP address followed by period and the architecture, capitalized, like C0A8017B.SUN4C for a SPARCstation ELC at 192.168.1.123.

In either case the next step is an answer from bootparamd. Install the bootparamd package, but it won't see the requests, because they're broadcasts and not sent to the server's IP address. You need to add -r to OPTIONS in /etc/default/rpcbind for bootparamd to see the requests. For some reason the lines adding to options weren't expanding ${OPTIONS}, so I had to set them all at once. It will then answer. You must supply both root and swap values in /etc/bootparams.

After that the final step is NFS. Install nfs-kernel-server. SunOS will want NFS and rpc.mountd version 2 protocols, which are disabled. 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. Note that /etc/exports requires directories, so to share a swap file you need to share a directory containing it.

If you sent boot via TFTP, it will make a bootparamd request and then load the kernel via NFS. That might be faster than loading the kernel via TFTP, because TFTP is simple and inefficient. The kernel makes another bootparamd request, and then mounts root and swap. What happens afterwards is up to what's in the root file system.

Don't forget to restart daemons after changing configuration files.

When creating devices in the root file system, ./MAKEDEV std is insufficient. You need ./MAKEDEV pty for telnet or xterm, and ./MAKEDEV win for the windowing system. The MAKEDEV script worked fine from Linux. The arch -k error is harmless unless you're using a sun4m system.

SPARCstation ELC repair

The SPARCstation ELC is a SPARC workstation built into a monochrome CRT monitor. It is fanless, and gets quite hot, which is bad for electrolytic capacitors. I suspect that also some particular capacitor models used are bad.

Accessing the computer motherboard (under the cover at the back of the top) is very easy. Unfortunately, disassembling the rest isn't very convenient. Maybe the design tried to make it convenient at first, and then changes defeated that.

Before disassembling further, consider the shock and electrocution hazards. Obviously the line voltage side of the power supply is dangerous. The secondary side is dangerous too, because besides supplying safe voltages to the computer, it also supplies higher voltages to the monitor. The main monitor board uses those to make even higher voltages, and sends some of these to the CRT socket board. Due to capacitors, voltages can persist even when the device is turned off and unplugged.

The first problem was the power supply, the board to the right when viewed from the rear. It seems like it could be possible to lift out, but the speaker bracket screwed into its bottom prevents that. So the whole side needs to be freed and moved outwards.

The power supply was pulsing. This can happen when an SMPS detects a fault, shuts down and restarts, but that's not what was happening here. The -12 V rail had excessive ripple, and I replaced its 100 µF 16 V filter capacitor (the missing C528 in the photo) to fix that, but it wasn't causing the problem either.



Just guessing I saw the 100 µF 35 V capacitor near what seems to be the SMPS controller IC. The board in that area was browned due to heat around various holes, so it makes sense that the capacitor may have been ruined by heat. Also, a failure in power supply to that IC could cause the symptoms. After testing the theory by temporarily placing a capacitor in parallel, I replaced the capacitor and fixed the problem.



Now the picture was barely visible. The firmware screen has black text on a white background, but the text was just a bit darker than the background. Replacing the two visibly leaking pairs of back to back 100 µF 10 V capacitors at the bottom of the CRT socket board took care of that.It turned out those transistors, labelled ITT 895 115C, near the corner of the board were bad as well. According to NTE's cross reference, 2N4401 was a good substitute. I don't know why they failed. I thought maybe I damaged them by accidentally solder bridging surface mount tubular C417S to the neighbouring resistor on the underside while replacing the rightmost capacitor, but that solder bridge apparently needs to be there. I also replaced some other capacitors but am not sure any of that was necessary. This board is probably the worst for capacitors because it is in its own RFI shield box inside the monitor.


Note that the CRT socket board requires the RFI shield to make ground connections. The main ground area visible at the CRT socket and the three tabs to the left of it need to be connected by wires if you remove that shield and want to power on the monitor.

Finally there was some vertical foldover at the top. It was interesting to note that its start stayed in place as vertical size and position was adjusted. Multiple guides about this problem with CRTs in general say that the prime suspect is the pump-up capacitor. The vertical deflection circuit needs a pulse of higher voltage to overcome inductance and quickly move the beam back to the top. This is accomplished via a charge pump, which charges a capacitor in parallel with the supply, and then connects it in series, to provide that higher voltage. That was another one of those 100 µF 35 V light blue capacitors, like in the power supply (the large cap in this photo). Here are the definitely bad components:

If you want to see more photos, take a look at the album.

Friday, September 04, 2020

Fixing Whirlpool part 3378207 to make dishwasher start washing reliably

A dishwasher doesn't simply recirculate water while washing. It tries to separate solids coming off the dishes from the water, and recirculate only the water. Some dishwashers have filters. This dishwasher has a soil separator. First, a chopper breaks up any large particles. Then part of the water being pumped by the wash impeller goes through the plastic doughnut surrounding it, where baffles try to trap particles. Later, when the dishwasher pumps out water, it pumps from the soil separator, sending the particles down the drain.

The outlet of the soil separator connects to the drain pump via the drain pump cover. Also, the outlet of the soil separator has a simple valve operated by water pressure. Under that little cover to the right is a diaphragm which is pushed down by a spring to open the passage. When pressure builds up, it acts against the spring, pushing the diaphragm upwards, and pulling a rubber cone which blocks the passage.

But, how does that pressure build up in the first place, while the passage is open? I'm assuming it builds up due to the drain impeller spinning the wrong way. Both the wash and drain impellers are on the same shaft, and the current function depends on the rotation direction, determined via the motor start winding.

However, if water leaks out elsewhere, then pressure may not build up enough to push up the diaphragm and seal off the passage. That Whirlpool 3378207 drain pump cover has a rubber gasket on top. It has a thin plastic ridge surrounding that gasket, to keep the gasket in place. That ridge breaks off, and then pressure stretches the gasket, allowing water to leak out. The result was that sometimes the dishwasher would fill with water normally and not start washing, even though the pump was running. It's surprising that enough water can escape that way to cause this, but apparently it can.

If I stopped and restarted it while full of water, it always started properly. I guess the big pulse happening when the pump starts provided enough pressure to move the diaphragm, but the slow pressure increase happening as it was filling didn't.

I cut two thin slices from a copper water line, and soldered them into the appropriate shape for holding the gasket in place. The gasket had been stretched a lot, but I managed to squeeze it into place.


Thursday, May 14, 2020

Using SpeedFan's driver to call Dell BIOS functions for fan control

SpeedFan uses a signed driver to talk to hardware for temperature measurement and fan control. The fact it's signed is important because Windows 10 makes running unsigned drivers difficult. I wasn't satisfied with how SpeedFan fights with Dell Inspiron 6400 laptop's built in Fan control. I8kfanGUI was better, but didn't have a signed driver, so I only used that in Windows 7 and earlier.

I also wasn't satisfied with fan control options in Linux. The Linux kernel provides access to Dell BIOS temperature measurement and fan control functions via the i8k driver, but attempting fan control led to the same issues. So, I first created a small fan control program in C in Linux. Getting it to run in Windows was surprisingly easy, thanks to SpeedFan's driver. First one needs to open the driver:

    sfdrv = CreateFile("\\\\.\\SpeedFan",
                       FILE_ALL_ACCESS, FILE_SHARE_READ, NULL,
                       OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);

Then one can use the IOCTL to call Dell BIOS functions:

#define SFD_CALL_DELL 0x9C402424

int call_dell(uint32_t eax, uint32_t ebx)
{
    uint32_t inbuf[4], outbuf[4];
    DWORD readbytes = 0;

    inbuf[0] = eax;
    inbuf[1] = ebx;
    inbuf[2] = 0;
    inbuf[3] = 0;

    if (DeviceIoControl(sfdrv, SFD_CALL_DELL,
                        &inbuf, sizeof(inbuf),
                        &outbuf, sizeof(outbuf),
                        &readbytes, NULL) == 0 ||
        readbytes < 4) {
        return -1;
    } else {
        return outbuf[0] & 0xFF;
    }
}

I don't know if you need to read and write 16 bytes. SpeedFan always did it this way. I guess they're probably eax, ebx, ecx and edx, in little endian order of course. Certainly the first two seem to be eax and ebx. The i8k Linux driver, now part of dell-smm-hwmon.c, will show you what to do with this.

#define I8K_SMM_SET_FAN     0x01a3
#define I8K_SMM_GET_FAN     0x00a3
#define I8K_SMM_GET_TEMP    0x10a3

int get_temp(unsigned int which)
{
    return call_dell(I8K_SMM_GET_TEMP, which);
}

int get_fan(void)
{
    return call_dell(I8K_SMM_GET_FAN, 0);
}

int set_fan_real(int speed)
{
    if (speed < 0 || speed > 2) return -1;
    return call_dell(I8K_SMM_SET_FAN, (speed << 8) | 0);
}

In my program I used the following rules to reduce fighting between my fan control and the built in fan control: Read fan speed setting (not RPM, but off / low / high) before setting it. Only write it to change it (because otherwise it's pointless). It is always okay to raise fan speed. Once the program raises fan speed, it is allowed to lower it. If the program reads a speed that is higher than the last one it set, it is not allowed to lower it anymore until after the next time it raises fan speed.

I used the rohitab.com API Monitor to figure this out by watching the DeviceIoControl calls that SpeedFan was using.

Other people have also used the SpeedFan driver. Although you need to have Administrator rights to talk to the driver, the driver seems to be a bit of a security hole because even Administrator isn't supposed to have such absolute total control in Windows. Here's one example: https://github.com/SamLarenN/SpeedFan-Exploit/

Here's an example of MSR reading to get the temperature from the CPU's internal thermal sensor:

#define SFD_READ_MSR 0x9C402438

int read_msr(uint32_t msr, uint64_t *dest)
{
    DWORD readbytes = 0;
    if (DeviceIoControl(sfdrv, SFD_READ_MSR,
                        &msr, sizeof(msr),
                        dest, sizeof(*dest),
                        &readbytes, NULL) == 0 ||
        readbytes != sizeof(*dest)) {
        return -1;
    } else {
        return 0;
    }
}

int get_coretemp(void)
{
    uint64_t msrdata;
    if (read_msr(0x19C, &msrdata) < 0) return -1;
    if (msrdata & 0x80000000) {
        return 100 - ((msrdata >> 16) & 0x7F);
    } else  {
        /* Reading not vaid */
        return -1;
    }
}

I'm not using that because the CPU sensor reported by the Dell BIOS gives the temperature of the hottest core. It seems if I read the MSR directly I would have to run the code on each core I want to measure. Calling Dell BIOS once is simpler.

I hope the code didn't get mangled by blogger. I haven't written anything here in a long time. Trying to format stuff as code, in a fixed font, made it too wide, so I didn't bother.

Opening a "single use" armband plastic snap together button

As you can see the armband's button was secured by 4 plastic ribs which stick out from the post. The ribs on the post and the profile of the ring act like a wedge, temporarily deforming plastic to allow you to close and latch the button. But, once latched, the slope you would have to work against to unlatch is very steep. So, the button is easy to close but very hard to open via pulling.

In order to open the button less destructively, a pipe is needed, to go in the slot between the post and ring and . Finding a pipe of the right diameter and thickness would be difficult. So, I took a sheet of aluminum, cut a small piece, and shaped it onto a pipe using a suitably sized wire and pliers. Such aluminum can be easily be cut by scissors, though you probably shouldn't use good scissors which you want to keep sharp. Once I made the pipe, I adjusted it, making it a bit smaller by cutting a tiny sliver with scissors to reduce circumference and again shaping with pliers. Then I forced the pipe into the gap between the ring and core.

Saturday, December 30, 2017

Dealing with a partially installed Windows 7 update

On one computer the June 2017 monthly rollup (KB4022719) somehow installed improperly or got corrupted. It couldn't be uninstalled, and future rollups couldn't be installed. Apparently, the process of installing a new rollup first needs to uninstall the previous one.

The Windows Update user interface simply gave the useless 80004005 error, but detailed information about the failure was available in c:\windows\logs\cbs\cbs.log:

2017-12-28 20:54:05, Error                 CBS    Failed. Attempted to uninstall a version of a non-driver component that is not installed, version: 0X700061db15cfe, component: amd64_microsoft-windows-w..lient-aux.resources_31bf3856ad364e35_7.6.7601.23806_en-us_e79af1b12d6db6c9, owner: Package_835_for_KB4022719~31bf3856ad364e35~amd64~~6.1.1.6.4022719-2919_neutral_LDR [HRESULT = 0x80004005 - E_FAIL]

Each update is a package which refers to many other packages, like Package_835_for_KB4022719~31bf3856ad364e35~amd64~~6.1.1.6.4022719, and each of those packages refers to components, like 2919_neutral_LDR. If you're curious, you can unpack an update and look inside it. First unpack the .msu to get the CAB and then unpack the CAB. You probably must use Microsoft's expand.exe to unpack the CAB because it may use intra package delta (IPD) compression which is not supported by 7-Zip.

Inside the CAB you will find various .mum files, which correspond to the main package and those sub-packages. The logical thing to do would be to reinstall these problematic components. However, I don't see a way to install from a .mum file.

So, I ended up uninstalling the messed up update by editing its already installed .mum file, found in c:\windows\servicing\packages, as  package_for_kb4022719_sp1~31bf3856ad364e35~amd64~~6.1.1.6.mum. (Note the absence of a number after "package" in the file name.) That directory is set up by default so only TrustedInstaller can write there. Not even SYSTEM can write there! So, I had to temporarily grant access to Administrators. The sections to remove are like this:

<update name="4022719-4117_neutral_PACKAGE">
<package integrate="hidden">
<assemblyIdentity name="Package_835_for_KB4022719" version="6.1.1.6" language="neutral" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" />
</package>
</update>


After removing the sections referring to messed up sub-packages, it was possible to uninstall the rollup. However, reinstalling it didn't fix the problem. I guess the messed up partly installed sub-packages don't get reinstalled? Fortunately, I was able to install the December roll-up without problems. Hopefully future roll-ups will install, and the only consequences will be a few small unnecessary but harmless files and registry entries.