Built RF amplifier to interface digital VFO to Heathkit HW-100 transceiver

ALTO DISK TOOL

I tweaked what signals are displayed on the LEDs and that show on the seven segment display, otherwise no change to the disk tool as it is simply waiting for the chance to test with real drives, disk cartridges and Altos.

RF AMPLIFIER TO MATE DIGITAL VFO TO HEATHKIT HW-100 TRANSCEIVER

The digital variable frequency oscillator I built to improve the HW-100 tube transceiver produces a low voltage output with 50 ohm impedance. I had tried to leverage the existing tube amplifier in the analog VFO to try to boost the signal before it is mixed with the local oscillator in another tube.

The impedance match is wrong and the tube really needs a larger voltage swing, leading to poor results as it sat. I found a kit by W1AFFL that will boost and match impedance to the tube in the HW-100 from the 50 ohm low voltage swing produced by my digital VFO.

I completed the kit in my spare time today and will put it with the rest of the HW-100 project to resume work in the near future. I have to concentrate on the relay tester, 1130 light panel and Alto efforts first.

1402 Permissive Relay Tester construction nearly completed

RELAY TEST TOOL CONSTRUCTION

I bored out the hole for the power cords, inserted the grommets and then tied the cord strain relief inside. Began soldering grounds together, the +20V to the two relay module contacts and the +5V to the 0.1 ohm resistor leading to the bank of resistors hooked to the individual contacts.

Beginning to wire up the insides of the tester

I had some wiring to accomplish between the relay module and Arduino, set up all the grounds from power supplies to Arduino and the two relay test sockets, solder up headers for all the contact wires from the relay test sockets, and finally hook up my four LED units.

The pick and hold coils circuits were wired to the relays, including the snubber diodes that will short the back EMF as the coils are released. I partially wired the two LEDs that illuminate that will show when the pick and hold circuits are energized. The ground connection to the Arduino was installed, but there was still quite a bit more to do by midafternoon, mostly involving wiring stiff wires to small header pin ends.

When dinnertime arrived, I had all four LEDs wired in, the relay module connected to the Arduino, and the only wiring left to do was to hook the twelve contact leads (6 each for normally open and normally closed sides) to the header that connects to the analog input pins on the Arduino.

Early evening brought completion of all the wiring. Two of the header strips were left detached, giving me more working room to install the LEDs, but they only need to be plugged into the Arduino to complete all circuits. I carefully tested everything for shorts while I was wrapping up, so that as it is ready to have power applied.

Final tasks that will wait until Sunday include

• insulating all the bare metal soldered junctions, 
• inserting the proper grommets into the cover, 
• mounting the LEDs into the grommets,
• install the headers onto the Arduino and
• close up everything after testing

Too, I have to visit CHM over the weekend to pick up the current code (Arduino sketch) that matches the circuit. The major change is the addition of a 0.1 ohm resistor between +5V and the individual 33 ohm resistors feeding each contact.

The code adjusts the voltage measured on each contact (powered through its 33 ohm resistor) against the voltage at the junction with the 0.1 resistor. The contacts are connected to ground by the relay and any voltage above 0 at the contact is due to resistance in the contacts.

Disk tool now working for both read and write; continued building the relay tester

ALTO DISK TOOL

Problem spotted and corrected. The deserializer emits a signal called gotword for the duration of the bitcell, 600 ns or 30 fpga cycles. In that time, my ReadField logic will take the extracted word, store it in RAM, adjust the address of the next word to be stored and loop back.

This takes less than 30 cycles therefore I was trying to put the same word away a second time, instead of waiting for our next incoming word. It was solved with a simple interlock keeping the state machine in the address manipulation state until gotword goes inactive before going back to look for the next word.

I now read the sector but get a checksum error on the first record (header). The data appeared to be shifted in correctly and at the correct time, but the error comes when the comparison between the incoming word and the computed checksum fails. I therefore altered the testbed to emit the running checksum value and watched that for signs of problems.

The checksum matches what was extracted from the bitstream, so the flaw is more subtle. I again changed the emitted signals to allow me to watch the state of the error flag during the test - another 30 minute pass through the toolchain - and observed the results.

What I saw at the time of the test and immediately afterwards was a good status for the checksum, yet the result when the ReadSector transaction completed was an error marked for the header record. I took another half hour, passed out the point in time when the error is recorded as a signal, and examined what was occurring around then.

The ReadField transaction is run three times per sector, at the request of the higher level ReadSector transaction. Each time, the parameters such as preamble size and word count are set up while triggering the inner transaction to run.

When the inner transaction returns to its idle state, the outer transaction should advance to set up the parameters for the next record and trigger the inner transaction to handle it. What I am seeing is that the inner ReadField transaction returns to its rfidle state as it should, sits there for only three cycles and then appears to kick off in another transaction.

This should involve the outer ReadSector transaction stepping from its rsread1 state to the rsset2 setup stage to trigger the inner machine to handle the second (label) record. The outer machine does NOT advance to rsset2; that only occurs at the next rfidle stage of the inner machine.

This means that the inner transaction tries to read the label record but with the long preamble and short word count that pertains to the header record. It fails to produce a good checksum and that is how I get the error status recorded.

I will confirm this with a change in instrumentation, twiddle my thumbs until the testbed is ready and see what is actually taking place. If this is the case, I have a problem with my ReadSector transaction not stepping properly to its rsset2 stage, even with three cycles of the triggering rfidle state from the inner transaction.

Since I did have the problem - the step rsread1 took just a single cycle thus really didn't read the header record - I modified the outer transaction to interlock better with the inner one. That is, kicking off each read step involves a wait step that insists that the ReadField transaction left its rfidle state before it starts looking for the inner to end with rfidle later.

I need to see that the ReadField transaction runs properly three times at the correct time in relation to the outer ReadSector steps, Once that works, I can check to see if the checksum verifies good reading and then verify the contents of RAM to match what my dummy data driver is emitting.

Both tests worked well. I even performed the upper level ReadEntireCartridge transaction which bumps through all the sectors, issuing ReadSector for each in order. The file produced looked good, but since I used contents of all zeroes in my dummy data, it doesn't absolutely prove out the logic.

Therefore, I planned to write some unique data values in each record, first with invalid checksums. I should see all my data captured in the file properly when I 'read' the cartridge, but each sector should reflect the checksum errors. After that works, I can add in the appropriate checksum values and test to see if my logic is now reading 'without errors'.

I had previously built a spreadsheet that is designed around the three record format of an Alto sector. I enter the data words I want and the spreadsheet displays the appropriate checksum. Since it gave me the correct values, I first verified the checksum failure for the two records where I deliberately stored a bad checksum.

I then corrected the data stream, waited a half hour for the toolchain to complete and verified that all worked properly. I found the data properly stored in RAM, matching the values I used, meaning I can consider the logic to read cartridges to be working.

I took a look at the WriteSector state machine to see if it could benefit from the improved interlocking I used on the ReadSector peer machine.  Indeed, it is amenable to the same improvement, which I introduced. Once I wrap up the reading tests, I can quickly do a WriteEntireCartridge to validate that the logic still works.

As of dinner time, both ReadEntireCartridge and WriteEntireCartridge transactions are working properly to the extent I can test them without a live Diablo drive or a real Alto. However, I am reasonably confident and look forward to the testing.

PERMISSIVE MAKE RELAY TESTER CONSTRUCTION

I found a good way to anchor the Arduino and relay modules down inside the box. I had to make some holes for power and USB cables to attach, stick in a barrier strip and add the four LEDs to the cover. Once done, I could wire up the tester and be ready to go.

I tried some acrylic glue to anchor the relay module inside the box, further fixing it firmly. With that done and proven out, I did the same treatment for the Arduino itself. A hole was drilled and covered with a rubber grommet for the USB cable that connects to and powers the Arduino.

I need to decide how to route in the power from the two power bricks - one at 20V and the other at 5V - which drive the relay coils and contacts respectively. I could just drill holes and knot the wire inside and out to anchor it in place, or I could attempt to install sockets on the side and matching plugs to the power cables.

Four LEDs have to be installed in the cover. There is one under each of the two relay sockets, to indicate which is active for testing. The other two are in the center of the cover and light to show when the pick and the hold coils are active. I have a grommet assortment coming which will allow me to mount the LEDs cleanly in the box. The grommets will also help with the holes for power cables or sockets.

I did find a reasonable grommet for the power cables to enter - sans sockets - and drilled a first hole. It is a bit too small in diameter, so it needs to be drilled out with a slightly larger bit. I will take this on tomorrow, then install the power lines and knot them inside for strain protection. I still need the mini grommets to mount the LEDs.

Tomorrow, I will grab four LEDs and wire them up, before beginning the final wiring of the unit. I decided against the use of a barrier strip, instead using point to point wiring. All these soldered junctions need insulation, which I will apply with my 'rubber in a bottle' paint on insulation.

The copy of the sketch that drives the Arduino is out of date, not including the improvements suggested by Ron Crane that improved the accuracy of the testing by way of a known voltage drop. I will need to find that code on the laptop at CHM where the original tester sits. 

Core problem on 1401, progress on disk tool and in wiring up relay tester

IBM 1401 RESTORATION TEAM

Our Connecticut system has a bad core location up in high memory. Consistent errors at one location thus it is almost certainly a single core issue. It will be fun to fix that one. Otherwise, both systems are working fine.

One of the 729 tape drives has had a problem with a coupler failing that connects the capstan to its drive motor. The rubber disintegrated. A different coupler was installed but it appears that the shafts are misaligned somehow which is putting the stress on the coupler. We will watch to see if this coupler will work long term, otherwise we must either correct the alignment or do some other more serious surgery. 

George was working on his SMS card tester, which has signal issues in the cabling between the digital logic section and the analog card or somewhere on that card. 

While working on that, we discovered that a consequence of using the laptop power bricks to supply the +/- 19V power for the unit is that the ground of the SMS tester is actually set 20V off from ground of the oscilloscope (thus 20V off from the AC nuetral). We will move over to a lab power supply, using it to provide the input voltage without the ground offset, and see where we get to. 

ALTO DISK TOOL

Finally today I beat my dummy data driver logic into shape and have a properly formatted string of data bits going into the disk tool, looped from some temporary output pins, to let the logic attempt to read a sector properly. With this, I can check and debug the ReadSector logic.

   

Now I can use the logic analyzer and track the operation of the ReadSector and ReadField state machines. First step in reading any field is to sync up by finding the first non-zero data bit, from then count off bits in each word as they are deserialized and stored in RAM. Right away I can see that the first non-zero data bit came in but the logic did NOT work properly from that point.

The trace shows the sync state being properly recognized from an initial '1' data bit yet the checksum validation failed. I began reconstructing the signals to watch the extracted words from the deserializer. It should tell me whether I am reading the stream on the right boundaries, when I resume testing tomorrow.

PERMISSIVE RELAY TESTER CONSTRUCTION

Today I found some clamps used with the relay sockets as they are installed on 1950s era IBM equipment. There is a clamp that latches over one end of the socket, providing round holes for screws to mount the socket properly, but the other end of the relay does not fit these. It seems that IBM used long common bars that a group of relays would slip under, anchoring them individually with the small clips I found.

The clips come in two widths, for the red 4-circuit and the green 6-circuit relay types. I altered one of each clip type, cutting off enough so that it could install upside down on the far end of the relay socket, still giving me holes for mounting screws.

I used these to firmly mount the sockets into my box and could do the final wiring of the relay sockets. Next up I have to mount two boards inside the box - the Arduino Mega 2560 and the dual relay module - plus a barrier strip.

Top with relay sockets mounted

Additional steps are routing of two power brick cables into the box to a short barrier strip, cutting an opening to insert the USB cable through the box onto the Arduino and final wiring of the relay socket wires to the components inside the box.

Arduino and relay module to be mounted (also a barrier strip)

Wires and resistors installed on sockets, ready to insulate

Wasted day fighting the disk tool logic to produce dummy disk data bits

ALTO DISK TOOL

I discovered that the toolchain had become confused with a change I made inside the process that spits out the dummy data stream to test reading. I have an array of about 350 words of data that represent the contents of a disk sector, clocking them out one bit at a time until a 16 bit word is exhausted and then advancing to the next word.

It had worked fine, but I wanted to reverse the polarity of the bit being emitted since the disk drive delivers inverted data. I did this with a variable inside the process, which should work fine but the toolchain blithely claimed that my array of data was used but never assigned. It is assigned as an initial value on the signal declaration, however it forgot that and gave it the default value thus always 0.

Took a several hours of fighting with the toolchain before it would do what I asked and deliver the data stream I had initialized into the block ROM. I can't do anything until it begins emitting the pattern I set up. I tried many methods, finally extracting the relevant logic into a separate module that I could easily simulate to discover exactly WTF is going wrong.

The extracted logic simulated fine and is purely combinatorial. I instantiated it into the main logic and synthesized everything to test once again. It again failed to work. I even output the signal on a separate pin just to validate that I didn't have a dead output line, but the results were the same.

Tomorrow is the holiday (July 4), when I will be mostly busy with family, but I will do one last synthesis to output the states of the driver logic that extracts my dummy date. Then when I resume I can get to the bottom of this.

1130 light panel upgrade ready to install, 1402 relay tester relay sockets being wired

ALTO DISK TOOL

Two observed problems in the ReadSector function must be investigated and corrected. First, the function starts off as if it saw a 1 bit coming in from the drive, indicating a sync word, but this occurs even if we only inject zeroes. Second, the read functions don't parse the incoming stream properly.

I lack confidence in the logic that detects sync, thus my first pass at the machine will expose signals needed to debug the function of the logic. I generated external signals both for the logic analyzer and on LEDs after dinner but didn't have time to test today.

IBM 1130 LIGHT PANEL UPGRADE

Finished up the last 24 bulb assemblies and installed them on the last PCB. The three cards are now ready to be placed in the 1130 panel and have the power lines wired up. I have to move some items around in the garage to make room to properly deal with the 1130. Too, I have swapped plugs on my extension cord to use with my electric vehicle charger, so I would have to swap back to power up the 1130. Later this week for that work.

1402 RELAY TESTER BUILD

I found that I could solder the resistor leads into the socket, after doubling over the lead, if I dipped it in rosin first and then carefully soldered. I did one row, after which I needed to solder in the common contact wires before I did the other side's resistors. Too, I have to solder in four wires on each side to carry the signal over to the red relay socket.

By late afternoon of day 1 I had the green socket wired with its ground, all resistors, and four wires to run over to the red socket on one side. Four more wires were needed to run to the red socket, plus twelve wires soldered to the far ends of the resistors that will run down to the common 0.1 ohm resistor.

Early evening had the remaining wires on the green socket and all the wiring on the red socket that can be installed now. There are eight wires that span from the green to the red socket which are attached already to the green but must be soldered down in situ to the red socket after they are mounted on the cover.

In the morning of day 2 (Sunday July 2) I had cut the openings and drilled the holes on the project box cover. I began mounting the relays, affixing the green one first so that I could route wires out the hole of the red socket letting me solder them to the red socket while it was loose.

I discovered that mounting the relay socket was trickier than I expected, since the socket only has half-circle holes on its edges. The screw had slips off as the screw tilts away from the socket. Perhaps I need a bent metal cover with holes drilled for the screws and a 90 degree section that will stand as tall as the socket.

Hmmmm. Thinking about alternatives as well. Can't proceed until these are bolted down properly. Will try larger diameter screws as well, but the shortest spacing of the holes is 5/16" on centers which doesn't allow for more much of a nut diameter. 

Almost done building bulb assemblies for 1130 light panel, beginning on 1402 relay tester

IBM 1130 LIGHT PANEL UPGRADE

I continued soldering together lamp assemblies, completing one of the two small PCBs by midday and starting on the final small PCB. I have 24 more lamps to build and I will be done. Completed 132 assemblies of the the 156 used in the light panel.

The supply of incandescent bulbs I bought worked out well. The bags were sold as containing 100 bulbs but there were quite a few more in the first bag I used. The quality control inspection was as casual as the counting.

A couple of bulbs had the two wires exiting the glass envelope too close to each other, making the risk of accidental short circuit too high. One bulb was a different shape and barely glowed. Another bulb did not keep its vacuum seal and smoked inside when illuminated. Two bulbs didn't light at all.

Still, I had more than 100 good usable bulbs in the bag, a great deal for the price. The only downside to the deal was waiting weeks for it to arrive from China. Glad I have a test circuit to check each finished bulb assembly, which is how I found the dead bulbs, although after I had soldered them onto the headers.

1402 RELAY TESTER CONSTRUCTION

I thought I had everything in hand but got a call from Stan. He remembered that after he created the original wiring diagram, Ron Crane had recommended a modification that was not copied to the diagram. It involved another resistor and additional wiring. Stan didn't remember the details.

I went to CHM, opened the working tester, and took detailed photos. I also learned the value of the additional resistor, which is a 0.1 ohm 2W unit. Anchor Electronics was just about to close at 3:56PM when I rushed in and picked up that resistor.

Careful measurement of the case and the relay sockets gave me the information I needed to plan out the exact spot for holes and rectangular slots on the cover. I will be soldering up the wires and resistors to the relay sockets on my workbench, then inserting the wires/parts through the slot when I mount the sockets.

The important question is how I make good contact to the relay socket. Soldering will be hard as the metal fittings are a close fit to the plastic body, which will melt from heat very easily. I could wedge wires into the connectors, although that means some parasitic resistance is introduced. More thought is needed for the build process.