Probing further into the OneDark signal mystery

WORKING ON ONEDARK UNTIL IT BEHAVED

I removed the ceramic disk capacitor and replace it with a new one, just in case that was causing the voltage divider behavior. I also saw that OneDark is connected to other cards via the backplane and the issue could have stemmed from a bad chip elsewhere.

I did some substitution of cards from my working M600 reader, as well as pulling various combinations out to see when the spurious voltage level arose. At some point during all this moving and checking, the voltage went solidly near 5V. From that point forward, the OneDark signal was behaving correctly.

I am unhappy that I don't have a clean culprit as the problem can come back, but for now I have to move on to debug what I can see is defective. Looking at the trace of a card going through the reader, I can see the OneDark popping on which immediately triggers the next couple of steps. 

The Good Pick Reset signal goes high for four clock phases, which begins the operation of the PRCLK which counts the time from when the leading edge is detected by OneDark until the point where the column 0 exists. PRCLK is decrementing a counter with a preset amount based on the known card speed of the particular model. 

Meanwhile, a rotating wheel with teeth is triggering pulses from a magnetic sensor. As soon as a pulse arrives, the OSCLK should be cycling causing the offset counter to count up until the PRCLK decremented counter goes to zero. That time is when the card column center is under the photocells, thus that offset count will be remembered. Later, when each new column arrives, a third counter begins incrementing by signal OSUCLK until it matches the value in the offset counter. The match triggers the CSDS signal that we are at a column.

Alas, I don't see OSCLK nor OSUCLK operating. I do see that the sync logic controlling those counters is reset by the ST0B signal. The signal is inverted, meaning it should be high most of the time and them blip low when gated to pass a phase B cycle. When I check the level, however, it is low all the time. This is wrong.

ONE ISSUE AT A TIME - STOB SIGNAL NOT APPEARING

The ST0B signal is emitted by a NAND gate which has phase B clocks going high on one input and a signal from the sync logic when the saved offset counter matches the counted offset for this column. Only when both are high should the gate emit a low output. One input is cycling with phase B, the other is always low when not reading cards, yet the output of the gate is low. I will replace this chip and see where we get to next.

EXTENDER CARD IS NEARING THE WORKSHOP

I received notification that the Extender Card that was donated to me by a fellow restorer working at the Datamuseum in Denmark has reached the US Postal Service in Chicago which means it won't be too much longer before it is delivered to me, connectors installed, and put into good use debugging the card reader.

Restored power to M1000 Documation reader, working on the OneDark signal flakiness

 DOWN TWO WRONG ROADS WORKING ON THE MISSING POWER

Because the power disappeared abruptly right after I inserted a card with tacked on signal wires, I assumed that I had somehow shorted the 5V rail and blown the fuse that is inside the reader. My voltmeter confirmed the absence of 5V on the motherboard, which was consistent with this hypothesis.

I opened up the front and back covers of the reader to get access to the power supplies below. First up was a test of the Slo-Blo fuse. It was good! I then jumped to the second wrong road, assuming this meant that the power supply itself had failed. A filter capacitor sits right after the bridge rectifier, feeding DC to the voltage regulator that would produce the 5V used by the logic. A quick check showed 16V and very little ripple; that too was consistent with the guess that the voltage regulator had failed.

Bridge rectifier and filter capacitor input to 5V regulator

I disconnected the resistor board that feeds the LEDs for the photocells, disconnected the regulator from the filter capacitor, and removed the allen screws holding it to the chassis. It was my intention to feed it 16VDC with bench supply while I did troubleshooting to find the failed component. 

5V regulator unit

Because I had access to the main wire that deliver the 5V up to the card cage above, I moved them around to allow me to to move the card cage further out for access to signals. It was then that my eyes spotted the loose wire where it should be attached to the motherboard.

White positive lead is disconnected!

The stranded wire had flexed enough to have snapped all the strands, one by one, until it cleanly detached. After I removed the remnants and resoldered the wire, I believed that 5V would be back and the reader was operational. I reattached the regulator board and wired it in, then confirmed that my power problem was corrected.

ONEDARK SIGNAL CONTINUES TO BE FLAKY

When I had power back, I could see that OneDark was off, as it should be initially. I moved a strip of cardboard in the photocell slot to toggle the signal on and off. However, it behaved very strangely - flipping on then decaying back to off even though the cardboard remained. Looking at the schematic, I do see a 0.01uf capacitor to ground in the OneDark circuit, as well as in the OneLight circuit which toggles accurately matching the holes and empty columns as a card moves through.

Later, it stopped giving me any OneDark at all. The signal is produced by twelve open collector inverters tied together, so that if any photocell is blocked its inverter pulls the shared line to ground. That shared line is passed through a normal inverter to create the OneDark logic signal.

I put the voltmeter on the input to the final inverter and see that the shared line was sitting at 1.65V. This is an invalid logic level and very suspicious. It is hard to see if one of the twelve open collector gates is partially conducting since they are shorted together as a wired-OR gate. I decided to start with the 7404 inverter chip which delivers the final One dark signal, as it was relatively easier to change that multiple 7405 open collector chips 

Alas, no change with a brand new 7404 in place. At this point, I see three possible failed components. Either of the two 7405 hex inverter chips could be bad, or the ceramic disc 0.01uf capacitor could have turned into a resistor. The last failure would explain the voltage level if the capacitor is so leaky that it has a resistance under 250 ohms. Thats a fairly extreme failure for a ceramic disc but worth checking. In fact, it is easier to yank the capacitor, check its resistance and replace it with a known good part than it will be to pull the two inverter chips so I will do that first when I return to the shop.

VARIOUS SLOWDOWNS IN MY WORKSHOP ACTIVITIES

I am forcing myself to spend an hour each time I visit the shop doing sorting and organizing tasks. That way it will slowly but inexorably get more organized and productive over the course of a year. 

Second, the rented house we have for another two months is more than 30 minutes drive each way from the shop. The condo we are buying will be five minutes away but I have a month at least until I can benefit from that.

Third, we have logistics to deal with related to the sale of our California house, the purchase of the beach home, and buying all the furniture we will need while the Labor Day sales are on. 

Detailed study of logic analyzer trace, one signal issue spotted, then OneDark failure returns

 REVIEWING EVERYTHING IN THE LOGIC ANALYZER TRACE

I returned to the shop this morning and opened the trace I had captured previously. This time I looked through it in complete detail, assuring myself that every signal operated at the proper time and with the correct values. Some important information wasn't captured - signals such as IM that go out on the interface are not carried on the motherboard, and the depth of the logic analyzer memory wasn't sufficient to record all 80 data columns plus the leading and trailing portions of the card. 

ONE SIGNAL DID NOT SHOW UP AS IT SHOULD HAVE

Everything that was captured looked great with one exception. Three of the four clock phases are gated at specific times as ST0B, ST0C and ST0D to control the latching of the value of each column. I see ST0C and ST0D occuring at the right time, but ST0B should have been active in the immediately preceding clock interval but was missing. 

The schematics show that there are only two gates involved in converting the phaseB clock signal to ST0B - an inverter and a NAND gate. I did tack a wire to the two pins of the inverter gate and verify that the phaseB signal is passing along nicely.

Here is where it gets interesting. ST0B and ST0C are produced by two NAND gates in the same chip, driven by a common signal from a comparator. When the offset count from a wheel tooth matches the calculated offset value, the three signals ST0B, ST0C and ST0D are passed along. Since ST0C is showing up, the common signal from the comparator is working correctly.

The obvious conclusion is that the NAND gate is defective that generates ST0B. I tacked on wires to confirm however the old OneDark error came back, which blocks the receiver from processing cards, calculating offsets or generating the signals. I have to go back and get that solidly repaired before I can continue.

ONEDARK PROBLEM INVESTIGATION

If you remember from an earlier post, the machine had OneDark active even though there was no card in the path and all twelve photocells should be registering light. When I isolated the photocell components and checked them, I had found that rows 8 and 9 were not switching fully on with light. Its voltage was in the forbidden zone that caused the logic gates to misread the state. 

I tweaked the current to the LEDs until the phototransistors developed good voltages. This allowed me to capture the logic analyzer trace that I did. Now the issue seems to be back. I decided to tack on wires for several rows of the phototransistor emitter lines and verify the voltages. 

OOPS

Somehow in the process of inserting the Control PCB with the tacked wires, I think I shorted the 5V power lines because the logic power is gone. At this point I left for the day before I made any more mistakes. It was a long night and I had a hangover today. 

Extender card coming to me thanks to a gift from the Datamuseum of Denmark

 EXTENDER CARD VALUE

The Documation readers house their logic in a metal card cage that has slots to hold up to six PCBs, although most machines are shipped with just four used. Each PCB has two sets of contacts. Each set is double sided, with 18 across the top and 18 just below them on the bottom side. 

The set of contacts on the right, when looking from the rear of the reader, share common signals that are routed up and down to all six card positions. The connectors are soldered onto a vertical PCB called a motherboard in the documentation. The left set of contacts have discrete wires that are specific to the function of each PCB. 

For example, the Control card has the twelve phototransistor signals wired to its left side connector, provides the latched card data to the external connection from that left side connector, and generates the OneDark and OneLight signals on the right (motherboard) connector. 

Each PCB has 36 chip positions although most boards have a few open positions. An average chip is 14 pins each of which may be of interest when troubleshooting the PCB. Because the four PCBs are close together in the card cage, it is very difficult to get a clip to stay on a pin and nearly impossible to reach in with problems while the boards are mounted and working.

An extender card has the two sets of 36 contacts on one and two 36 contact connectors on the other end. It plugs into the card cage and the PCB in turn plugs into the extender. Because of the length of the extender card, the entire PCB is sitting outside the card cage and can easily be probed or connected to. 

OFFER AND SHIPMENT FROM A FELLOW TECHNOLOGIST

I was contacted by a fellow vintage technologist who built extender cards while working on a Model 200 reader in the collection of the Datamuseum in Denmark. Because PCB fabs require a minimum order, they had extra boards, without components installed. They kindly offered to ship one to me, which I gratefully accepted. 

Because the cost was the same, my benefactor put two in an envelope and has mailed them to me. I look forward to receiving these boards, soldering on my spare connectors, then make use of my extender for any diagnostic work on the card readers.

Deep dive into phototransistor/LED and related circuitry in M1000

ISOLATING PHOTOCELLS AND CHECKING THEM OUT

Because the flawed behavior was the same when I swapped the board from my M600 reader, I suspected the problem was between the connector and the photocells, not on the PCB. In order to test it, I wanted to isolate it from the rest of the machine and verify that each of the twelve channels are working properly.

The schematic shows all twelve LEDs with their cathodes tied together and to ground. The LED anodes are wired to a resistor board, with a resistor connected to VCC. The other side of the channel, through which the punched card passes, is a set of twelve phototransistors.

All the collectors of the twelve transistors are tied together and to VCC. The emitters are brought to the connector to the Control PCB. On that board, each signal is connected to the input of an inverter and to a 5.6K ohm resistor to ground. 

Since I have the PCB disconnected, I set up a breadboard with a 5.6K resistor to ground which can be connected to each phototransistor's emitter to test what voltage is developed at the emitter. When the light is blocked by a punched card, the transistor is cut off and the emitter voltage is essentially zero. Without a card in the way, or with a hole in the card, the transistor conducts which pulls the emitter voltage to a positive level. 

All that is needed is to supply 5V to the phototransistor collectors and to the resistor board, which will light the LEDs and let me test the voltage with and without a card between them. I opened the bottom of the card reader to locate the resistor board.

DISCOVERY ABOUT THE RESISTOR BOARD

Unlike the schematic which suggests a single fixed resistor for each channel, the board in the reader has variable resistors to adjust the LED current individually. 

board as depicted on the schematic

actual resistor board

DISCOVERING A PROBLEM AND CORRECTING IT

After having isolated the LEDs and phototransistors, I measured the voltage for each of the 12 channels. Rows 12, 11, 0, 1, 2, 3, 4, 5, 6, and 7 showed just over 3V when no card was present and dropped to almost zero when blocked by a bit of cardboard. 

However, the unblocked levels for rows 8 and 9 were just a tad over 1V. That explains the sporadic pulses of OneDark and erratic behavior. The voltage is not a valid level as an input to an inverter, it is in the forbidden zone. The output of the inverter is undefined and can produce the behavior I saw.

I used a small screwdriver to adjust the levels until rows 8 and 9 were around 3V like the others. They still drop to nearly zero when blocked. 

MUCH IMPROVED RESULTS SO FAR

I now have a very reliable OneDark signal. It is solidly off when no cards are in the reading station. Putting the scope on it, I see that it goes on solidly for the duration of each card passing the station and off again after it passes. If I had a card with all twelve rows punched out in some columns, the OneDark would wiggle, but the actual cards I have only have some holes in each column. 

I did a run on the logic analyzer while running two cards through the machine using the Local mode which automatically picks each card until the hopper is empty. With a limited memory in the analyzer, able to hold just over 2000 clock cycles of data, I couldn't fit an entire card cycle in memory.

I triggered on the start of the PCLK clock that begins with a pick, then with the arrival of a 1 for OneDark. I was leaving for the day so I only did a superficial examination, but all the signals I checked were behaving exactly as they should. 

The reader turned on GPR, good pick reset, stopped the PCLK and began to count with OSCLK to determine the time offset from the edge of the timing tooth to the time when OneDark when on. It then counted with OSUCLK on every other tooth passing, to add in the offset to time the middle of each column. 

I saw the machine raise the 0CR signal when it recognized the start of the card. I saw each column come by, up until the buffer had filled. I didn't verify every individual signal, but will do that when I next get to the workshop.

Closing in on one defect in the M1000 reader

 OUTCOME OF THE FIRST FULL LOGIC ANALYZER SESSION WITH THE READER

I set up the analyzer to trigger on the start of the PCLK clock, which is a 120Hz counting clock that is used by the pick circuit to watch for a failed attempt, where the card does not arrive at the read status within a defined time period. I also observed the reset signal TSTR that zeroes out the offset counters in preparation for the time when the leading edge of the card first passes the photocells.

What I saw at that time was that both OneDark and OneLight were high. Neither changed within the length of the analyzer buffer. Later I determined, using the scope, that they do in fact change as cards move by but it wasn't in the trace I captured. 

Normally I would devise a secondary triggering strategy in order to catch the interesting signals within the buffer, but I can immediately see that something isn't right because OneDark should not be true.

WHAT ARE THE ONELIGHT AND ONEDARK SIGNALS?

There are various times in the movement of a card when the control logic needs to know if the full set of 12 photocells are dark or if the full set are illuminated. What these signals mean is that one OR MORE photocells is seeing light, for OneLight, and that one OR MORE of the photocells is dark in the other case. 

The reader knows that a card has just arrived when OneDark goes on. This is because the leading edge of the card is starting to block the light between the LED and the phototransistor for one or more rows. 

Once the card is in the station fully but prior to it reaching the area where column 1 of the data is punched, the error checking logic tests that OneLight is false. There should be solid card blocking the light at that point. 

After finishing reading the hole patterns for 80 columns of data, the card advances to the space that would be column 81, Once again, error checking circuits ensure that OneLight is off proving that we have the right side of the card blocking the light. By the time equivalent ot column 84, the trailing edge of the card will have passed beyond the photocells and the error logic insists that OneDark is false - that light is reaching all twelve photocells.

WHY THE RESULTS DEMONSTRATE A PROBLEM

At the time that the pick begins, no card is in front of the photocells and we should have all twelve LEDs illuminating all twelve phototransistors. The signal OneDark should be false at this time, and it shouldn't change until the leading edge of the card begins to interpose, blocking light.

However, OneDark is steadily true. This is a problem. 

CHALLENGES GETTING TO THE ROOT CAUSE

The only signals brought out to the backplane are OneDark and OneLight, not the twelve individual row values. While the separate signals exist on the Control PCB, the way that a signal such as OneDark is generated uses a wired OR. That is a technique to avoid the cost of extra logic gates or diodes, by shorting together all twelve open collector inverter outputs, pulling the shorted combined line up with a resistor, and considering the result to be the inverse of the condition. 

In other words, if we pass the twelve phototransistor signals through the inverter, a dark phototransistor will not cause the output of its inverter to pull low. Thus, when all twelve inverters are high because none of them had a true (light) input, then the resistor keeps the shorted output high meaning that we did NOT see any one or more lighted cells. 

As a quick test, I swapped in the Control PCB from my working M600 but saw exactly the same iniitial state where OneDark is true but shouldn't be. If the problem were logic chip failures or other hardware defects on the Control card, I could tack wires to check each and every photocell line to find the one that appears dark. 

With the problem more likely to be bad phototransistors, LEDs, cabling or connectors, I need to do different testing where the access is even more limited. The phototransistors and LEDs are wedged between two large aluminum structures that also hold all the rotating parts to drive cards forward. Opening it up would be challenging and then everything will need to be aligned again. 

phototransistors and LEDs

PREPARING TO TEST THE PHOTOTRANSISTORS AND LEDS

The wire leads from the transistors are wired directly into the left side connector for the Control PCB, with no exposed conductor I could reach. Until I have an extender that would expose those contacts, there are two ways to debug. First is to tack wires to the PCB and see what the twelve transistors are delivering onto the board. The second is to remove the PCB and directly connect to the 12 contacts on the connector. 

I had to unscrew the connector and bend it around to give me access to the contacts, but that is now complete. I will set up a simple circuit to validate the output of each cell then apply it to each contact. 

Connector twisted out of cage to permit access

ERRATIC ONEDARK OUTPUT LINE

Using the scope and tacked wires I observed the OneDark and One Light signals from the PCB. The OneDark would sporadically pop on even though nothing was happening with the reader. When I tapped on the card cage or reader, it would exhibit a higher rate of random pulsing. 

It is essential that i track down this behavior and correct it before moving on to other testing. 

Digging into why card data isn't being returned

 TACKING WIRES TO USE WITH SCOPE AND LOGIC ANALYZER

I tacked on small wires to the legs of ICs at strategic points in the generation of the impulses that trigger our microcontroller to latch in the contents of each card column. I began with the earliest precursor signals, monitored the control flipflop, then looked at various gates on the way to the external interface wires. This allowed me to put the board into the reader but have access to the various signals.

EVALUATING THE IM GENERATING LOGIC

Once a pick takes place, recognition of the first dark edge means the card has entered the photocell region. This resets the column counter and does some other timing to establish the time when the counter is advanced to represent the arrival of the next column. 

The counter produces signals such as 0CR (left edge), 81CR (arrival at column to the right of the last data containing position on the card), 84CR (when the trailing edge should have passed resulting in light on all photocells, and 84 (a delayed end of card counter used only in certain models of the reader).

At the time of 0CR generation, the Impulse Marker control flipflop is turned on, which generates the timing pulses for each column that will produce the IM on the interface. Our microcontroller sees the IM and latches in the 12 card row values for that column. This occurs 80 times to fill a one card buffer in our controller. 

The signals for columns arriving are tied to a coil reacting to teeth on a spinning wheel in the card feed mechanisms. Those pulses are timed and a precise delay is counted between the last tooth being detected and the exact time that the first photocell goes dark from the leading edge of the card in motion. This delay is applied to each subsequent set of pulses to synchronize timing pulses to the position of the card. That is, we would receive two more pulses, add back in the counted delay, then send out a gated version of the phase C and phase D clocks at that time. These gated clocks, called ST0C and ST0D, are used to latch and clear the photocell contents, to advance the column counter, and to emit the IM pulse.

As you can see from the description above, quite a bit has to happen correctly in order to have our IM pulses produced and the reader be happy with the reading process. At certain column times, e.g. column 81, there must be no light detected on any row. At other times, e.g. before column 0 and at column 84 time, there must be light on all twelve detectors. This is a kind of check that verifies that the card moved at the proper speed through the reading station. We get an error if these checks aren't successful.

RESULTS MONITORING THE LINES I TACKED TO THE BOARD

My wires were tacked on different pins on the PCBs to observe various parts of this process. I had to see the timed pulses going through, the card position signals such as 0CR and 81CR get produced, the IM control flipflop be set, the IM pulses be generated, etc. 

I did catch a single IM but most of the signals never occur. The issues are earlier than where I was looking. It was too tedious and cumbersome to tack on many wires, label them and try to hop between them with a scope. I decided I need to wire the logic analyzer to the backplane, look at all 34 signals that are available there, and draw conclusions from the mass of data before I try to narrow in to individual ICs or small circuits. Each of the four PCBs has over 30 chips mounted, making the scattershot method impractical.

PREPARING BACKPLANE SIGNAL CONNECTIONS

The backplane is a PCB that runs between the six connector positions for the right side of the card cage. The PCBs have a 2x18 connector that fits into the backplane; in addition there is a second 2x18 connector on the left of the card, with discrete signals relevant to the specific PCB rather than signals shared among all. 

There is not enough room between the connector and the backplane PCB to snag signals with any hooks. However, since the machine has six slots but only four cards fitted, there are extra connector positions on the backplane that do NOT have a connector soldered down. This gives me 36 holes that I can attach wires to, bringing the 34 signals, VCC and ground out where I can hook to them.

I carefully soldered on the 34 wires, preparing a means to wire up the logic analyzer and scope more effectively. The logic analyzer needs a good clock to latch in signal values, but the backplane provdies only four 120KHz clock phases (A to D). Those phases are developed out of a 480Hz signal on the Clock card, so I tacked on one wire to bring that master clock out to drive the logic analyzer.

As a quick check, I used the logic analyzer to capture the four clock phases and used the scope to observe all the clock signals. Everything was good, so I am comfortable that after I wired up the other 30 signals I can capture meaningful clues about the machine problems. 

capturing clock phases A thru D

It was then the end of the workday, where I saved the configuration and shut it all down for the evening. Tomorrow I will continue with the wiring and analyzer setup.

Detailed test of the M1000 reader with the internal interface

EOF LED NOT LIGHTING

I had an LED installed in the reader, wired to Brian's interface design, which should be toggled on and off by repeated presses of the pushbutton just below it. Nothing was lighting. I determined that the NAND gate driving the LED had failed, but fortunately there are two unused gates on the same IC.

I cut some traces, rerouted signals with wire jumpers, and soon had the LED working properly again. 

RESEARCH INTO THE Q CHARACTER AND PICK CHECK

When the card reader attempts to pick up a card six times but never sees its edge pass the photocells, it detects a pick error. That Pick Check is indicated by a lamp illuminated on the reader itself but the only way the PC program will know is that the READY status goes off. 

The program should accept the pick command, begin card movement, capture all the eighty columns of data, then stream back 160 bytes preceeded by an '=' character and followed by a status character.

If a pick check occurs, the reader should be sitting with pick active but not respond with anything. Pressing the EOF button returns a '!' character to indicate that the read was terminated. Clicking stop ont he application cancels the pick. Otherwise there shouldn't be a status response to the pick command P but this machine is returning a 'Q' character. 

RUNNING A DECK THROUGH THE READER TO SEE WHAT IS TRANSFERRED

I have a short deck, an RPG program for the IBM 1130, which I am using to test the reading system. I ran it up until the first pick check then closed the program so that I could view the resulting file. The outcome was that the file was not created and the read was cancelled due to pushing the EOF button since no contents had been read.

I switched over from Brian's application to a terminal program where I could issue the commands and see the responses directly. That showed me that no content was being collected or transferred by the microcontroller, although the control logic of the card reader didn't detect any errors. I would type the P command and once we had a pick check, it would return the status character Q (Pick request active and ready status; the ready status is inaccurate in a response to a pick so it can be ignored).

Some scope work attempted to view the IMST signal (the clock phase D is issued on this motherboard line whenever a read is being attempted, but the exact timing of start and end of card columns gates that forward to the IM signal delivered to the interrface. There would be one pulse per column for card columns 1 to 80, telling the microcontroller when it was safe to sample the 12 data lines for the card rows 12, 11, and 0 to 9. It is my suspicion that this pulse is not getting to our interface.

Retrofitting Error board with pullup resistors and investigating additipnal circuits

 TWO OF ADDED SIGNALS ON THE BOARD CONNECTOR ARE NOT WIRED IN READER

I see that pins 9 and 13 of the Error card unique connector are not wired in the card reader, but they have connections on the board to some of the new circuitry and to VCC respectively. It is my opinion just based on this that the card was borrowed from a different model, perhaps with an option I don't have, but it has no effect since the reader isn't wired to those signals. 

ADDED PULLUP RESISTORS, VERIFIED OPERATION

I inserted the four 5.6K pullup resistors onto the board and now see the output signals correctly reflecting the state of the reader. I hooked up the interface and fitted it loosely into its home. The card cage on the Documation reader has six slots, but only cards 1, 2, 3 and 6 are fitted in my two models. The space where 4 and 5 would sit was wide enough to house the interface PCB and the cables and connections for the reader signal lines. 

READER IS AT LEAST PARTIALLY WORKING

The PC connected to the interface and was able to see the status signals such as Hopper Check (no cards in the input hopper). I then triggered the program to read cards and in fact it did go partway through the test deck I had inserted.

There is much that has to work properly for this to occur. The reader has to see the holes, not detect any errors, and it has to send impulses for each card column allowing the microcontroller to collect the entire card image. 

I haven't looked at the file that was produced yet - there may be good capture, nothing or mangled contents - but there is at least one problem occuring that has to be diagnosed and repaired. The interface microcontroller sends the machine status back after every command. This is a single ASCII character whose bits encode the various machine signals being tracked. 

The card reader signalled a pick check. This is a condition where the reader attempts to pick up and move a card sixteen times without success. The PC side program complained that along with the pick check, there is a status character Q. That may be an unexpected or invalid set of conditions - some research is needed.

By this time it was 4PM and I was ready to head back to the rental house for the evening. I didn't investigate the file that was read nor look into the Q status code. That is fodder for tomorrow's time in the shop.

Whole lot of "nope" today

 CARELESS LOW COST MANUFACTURER LABELED USBMOD SIGNAL WRONG

I got the data sheet for the FTDI chip on the module in question, then verified that the WR signal from the chip is directly connected to the module pin that is falsely labeled #WR. It is not inverted. No problem.

COMMUNICATING WITH MY INTERFACE IN THE M1000, READER IS STILL BAD

I was able to connect over serial to my board and see it present status. To do this, I swapped in my good error board from the M600 and then watched as the external signals assumed correct values corresponding to changes in the reader state. 

DEBUGGING THE EXTERNAL INTERFACE SIGNALS

I see oddball and incorrect voltages on the output lines from my newly replaced 7417 chip to the external connector lines. I pulled the board and decided to continuity test all the traces to and from that chip. It was at that point, as I tried to verify the 5.6K pullup resistors on each open collector chip output line, that I found they were missing! No pullups which is a bad thing on an open collector gate unless there is an external pullup. The interface design I am using depends on the reader to do the pullup. 

Known good board has four 5.6K pullup resistors

M1000 error board with no pullup resistors

As I looked closer at that board, I see it is quite a bit different from the board in my working M600 model. For one thing, it has five additional ICs that don't exist on my working board. These are a 555 timer, a 7400 quad NAND, a 7474 dual flipflop and a 7404 hex inverter. 

Only the upper left chip exists on standard board

There are also two jumpers added to the board. One connects marked pads L and N on the board, which don't show up on the schematics I have. It is barely visible as a thin pink wire in the upper left of the picture above. The other jumper is a mod that must be implemented to change the board to work with the very slow models M200, M300 or M500, although it seems to have been uninstalled. In other words, the mod cuts the trace between C and D, then a jumper is put between C and E. This restores connectivity of C and D. 

trace cut C to D but 

Not sure why it had a modification and then was backed off. On the other hand I see jumpers and rework on other boards so it might have had boards converted for the 1000, pulled from other machines, to serve as replacements when prior boards failed. 

Continuing to work on the Documation readers

 ORDERED NEW INTERFACE PCBS THEN FOUND A BOARD ALREADY ASSEMBLED

The original M600 reader used the external connector hooked to a very funky bit of hardware that I cobbled together quickly from a prototype enclosure for an earlier project. I had re-used the wiring of the connector for the Documation reader, but cut away all the connections to the old logic. I then built the Brian Knittel designed interface using phenolic breadboards and discrete wires. 

It was a proof of concept. One that I never replaced with a production quality implementation. After powering it up in my new lab, I found that the link was no longer working properly over the USB line. I suspect that it was an intermittent connection to one of the eight data bit lines from the USB module over to the SX28 microcontroller chip. The symptom was that some valid commands would receive responses indicating that the character was invalid, while others appeared to work. 

Rather than debugging this further, given the fragility nature of this work that had long outlived its useful lifetime, I decided to build a PCB based interface that could be put in a small box hooked to the external connector. It would be the same interface I was building into the M1000 reader, but housed externally for the M600. 

I hunted in vain for any blank PCB blanks, since fab runs produce a minimum of five boards even when you only need one or two to assemble. Having found no blanks, I dusted off the design files from my PC and shipped them to a PCB fab company to make another five. They should arrive next week and were pretty inexpensive, only $2 plus shipping for the entire batch.

Alas, the day after I bought the new run, I looked in a box and found a completed interface board. I decided to tear apart the funky breadboard interface and build a proper one in a plastic enclosure using the existing cabled external connector. I spent about half a day carefully building this, testing the connections and preparing it for use.

NEW PCB INTERFACE FAILS MUCH LIKE THE PCB INTERFACE IN THE M1000

I fired it up and found that it was failing in a similar way to the one I had built into the M1000. That told me something is wrong independent of the readers. One reality of the interface is that the USB to parallel module specified by Brian was long out of production and unavailable, causing me to make use of seemingly compatible alternatives. 

In fact the first module I used, the one that was hooked to the funky breadboard implementation, was truly compatible. It had worked properly for many years. That successful substitute is itself no longer available, so that the PCB based interfaces made use of a third type of USB module. Neither of which seems to be working properly, although the evidence is muddied as I check out the reader with some hardware flaws of its own.

I looked closely at the original and my properly working modules, noticing that the signal to write data out over USB is a normal logic sense, make a high pulse to write and return to low value otherwise. Peering at my new USB modules, I see that they are marked #WR, implying that the write signal is inverted logic. It should normally sit high with a pulse down to low to cause a write. 

If these markings are indeed correct with the two working modules different from the new nonworking modules, then I have found my smoking gun. This  would make the module latch in the data byte at the wrong time, likely before it is even set up by the microcontroller. That matches the all zero status I was seeing from the M1000 and the bits not changing as the reader state changes.

It appears I would need to invert the WR signal, which fortunately I can do with moderate rework since my PCB has a quad NAND (open collector) IC installed with two of the gates unused. I need only scratch off the trace holding one input high, break the trace between SX28 and USB module for the WR line, then tack wires from SX28 WR to the input of the gate and from the output of the gate to the USB module #WR pin. 

I will do this with one of my boards and verify that it works before I convert the other one, but I am hopeful that this will give me good functionality.

BAD IC FOUND IN M1000 AND REPLACED

I found some output signals from the M1000 were not assuming valid voltage levels at the connector. After some debugging, I found that a chip that drives these was malfunctioning. It was a 7417 non inverting open collector buffer in a PDIP package. I didn't have any spares and placed an order from Digikey for a few.

Later that day I did some googling and found a surplus electronics component operation nearby in Palm Bay Florida - MRAM Surplus. It takes a bit of digging to find the part, similar to the old Weird Stuff in Sunnyvale California for those familiar with digging through cardboard bins with poor markings. I did, however, find two 7417 chips which allowed me to replace the IC as soon as I got back to the workshop. 

First faults found on Documation readers

 QUICK RECAP

The two card readers are connected via a microcontroller based external interface over USB to a program on a PC that will drive the reader and capture the card images. The M600 has a large clunky external interface I have successfully used in the past but the PC application complains that it can't communicate with the interface box. The M1000 has a small interface I am building into the machine so that it will offer a USB socket on the rear for connection to a PC. That reader won't pick (read) cards in local mode, nor through my interface. 

DOCUMATION M600 TROUBLESHOOTING

The link over USB uses a simple protocol devised by Brian Knittel, with a single letter transmitted from the PC to request status, pick (read) a card, reset the interface, clear a prior pick request or to clear the End of File status. The interface returns a single ASCII character indicating the status as well as the card image when it is being read.

Using a simple serial terminal program (PUTTY) I issued the S command to request status and see a valid empty status character coming back. Invalid commands get an error character '?' back. However, the status is always off even when there are indicators such as Hopper Empty on the reader. Further, the reset command is sent an error response. 

This tells me that the USB to serial converter board is working and the microcontroller is at least partially working properly, but I suspect that the 82C55A Peripheral Interface Controller chip is not working correctly.  This requires more debugging but since the interface was cobbled together on breadboard with discrete wiring, it is probably more effective to just properly build a new one.  

DOCUMATION M1000 DIAGNOSIS PHASE 1

When I had swapped the PCBs from my M600 into the failing M1000, it did pick a card when switched to local mode. However, with its own card complement, it never attempts a pick. The Reset button lights green which indicates that the reader control logic thinks it is error free and ready to read cards. 

I looked over the logic involved in issuing a pick and began to check the various input signals that control this function. It is awkward to clip leads on IC pin legs and string the wires out of the cage with the cards inserted, but there is a motherboard that routes 34 signals between all the PCBs. These are the major signals and are easily accessible from the back of the card cage while it is powered up. These signals are numbered 1 to 18 across the top and A to V across the bottom of each card connector - some letters like G, I and O are omitted in the sequence. 

Motherboard routing common signals to all six PCB sockets

Each PCB has another 38 position connector that is unique to the function of each board. For example, the Reset pushbutton is routed to one of the boards which handles the reset function, but the outcome of that button, the RESET signal is also propagated on the motherboard

Card specific connections on the other connector set

The pick logic is reset by power on reset, the reset button, and the completion of reading the prior card. With the switch in Local mode, pick should be continuously requested. If the reader is not in READY status, for example because an error condition exists, the pick won't take place.

I examined the signals going into and coming out of the pick logic, testing the state of the various motherboard pins associated with READY, POR, RESET, GPR, etc. I quickly discovered that the RESET signal is asserted.

I swapped in the same board from my M600, verified that RESET should be low, and found that the M1000 would now pick one card when switched into Local mode. The next step is to find the bad component generating the erroneous reset state. 

Snippet of schematic for the Reset signal

The RESET signal that is on the motherboard pin 2 is produced by a fairly simple circuit. One complication is that the Reset button must be blocked while a card is in the midst of being read - that is the purpose of the Reset Inhibit flipflop at bottom middle. If that inhibit state is on, then RESET will not be generated. We have a RESET so the flaw cannot be in that flipflop or its preceeding signals. 

The state of the Reset pushbutton is captured by the other flipflop. This one is forced on using its Preset pin and forced off using its Clear pin, with those pins hooked to the ResetSw and notResetSw wires from the physical button. Ground is connected to one of those at a time, with the wires pulled up to high by a resistor. Thus normally the switch would have the notResetSw line grounded, which activates the Clear pin of the flipflop and forces it off. If pressed, the button grounds the ResetSw line, activating the Preset pin to turn on the flipflop. 

The output of the flipflop is passed through a NAND gate, whose output only goes low if the Reset flipflop is set high and the ResetInhibit flipflop is set low. This low output is then passed through an inverter to produce the RESET signal on the motherboard connector. 

There can only be four components that might be bad. The inverter may be failing. The NAND may be failing. The Reset flipflop may be failing. Finally the pushbutton switch may be failing or miswired. Next time I go to the workshop, I will hook up some leads to the board with the problem and hook them to my logic analyzer. I should quickly identify the bad part which I can then replace from my spare parts inventory. 

PCB generating false RESET signal

Logic analyzer connectors ready to be wired to the PCB

x

First projects in the new workshop

 PRIORITY WORK TO FREE UP SPACE

I have many many boxes of punched cards that I had to bring to Florida until I can read them all and archive the contents. Once the data is preserved, I will sell, give away or throw away almost all of them. Similarly I have many dozens of 14" single platter disk cartridges most of which can be released once I read and archive the contents. Therefore, the archiving efforts are high priority for the coming months.

GET CARD READERS INTO SHAPE FOR ARCHIVING

I own two Documation card readers, one reads at 600 cards per minute and the other reads at 1000 cpm. These can be driven by a USB based interface designed by Brian Knittel which produces PC files that can be shared and archived. He wrote a driver program and related utilities that control the interface over USB. 

The card readers have a 38 pin connector on the back which transports control and data signals. The design by Brian requires the purchase of the male version of the connector and implements the interface as an external box that sits beside the card reader. I built one like this for my first reader, the M600, but I find the need to drag around the external box to be limiting.

I bought a second reader, a faster M1000, and designed a version of Brian's interface that would sit inside the Documation reader and give the reader a USB connector to replace the original bulky 38 pin one. The interface was built and installed but the M1000 wasn't working properly due to some defects in the reader. 

I began to debug the M1000 with the aim of getting it fully operational using the built in USB connection.  I also connected the external box to the M600 as I would like to have that working as a backup or second system. The USB link to the external interface box was failing, thus something is wrong with my interface which also needs to be diagnosed and repaired.

The M1000 won't pick cards at all using its PCBs, but when I swapped in the cards from the working M600 it worked better. This suggests to me that there are defects on the M1000 cards, but that the solenoid and picker circuits themselves work fine. 

CHECK OUT P390 SERVER DAMAGE DURING PACKING

I was attempting to pad the P390 server with inflating foam within a box for the move, which involved triggering the foam packs and nestling the unit, repeated several times to get all the sides protected. After blowing up one pack, I tried to rotate the cardboard box and server inside to place the next foam pack, however the weight of the heavy server overcame my grip. It crashed on its side. 

This bent the sheet metal, twisted the PCI cards at an angle and made me fear that the motherboard, PCI cards and other parts of the server might be ruined. 

Today I stripped out the PCI cards and disk drives, then powered up the server to see whether it would work at all. It did appear to work properly, other than complaining about configuration changes (as the cards were removed). Obviously it didn't find a boot device either. 

None of the PCI cards appear damaged, nor does the motherboard, but I fear there may be microcracks I don't see. Secondarily I have to hope that the RAID drives don't have damage (head-disk interference or crash) from the impact of the fall. 

I will add in the cards and disk drives, then see if it will boot up into OS/2 successfully. The last and most important test is whether the P390E card starts up and the mainframe software boots successfully.

WHIP UP TAUNTEK IC TESTER 

I had purchased the PCB and design for the Tauntek IC Tester, a device that will provide a sophisticated  of tests on various 7400 series (and other SSI/MSI from the same era) chips, looking at leakage, shorts, opens, unusual current or voltage levels all in addition to the obvious logical function verification. I had to order all the components separately and they hadn't arrived before I began the move. This week the last few showed up, so I took a couple of hours to mount and solder the parts on the board to complete this kit. It will be helpful in investigating ICs on systems I am restoring such as the Telex 9 track tape drives. 

Equipment moved into the new workshop

 REMOVE CONTENTS FROM U-BOXES AT U-HAUL AND LOAD TRUCK

After some predictable bobbles at U-Haul we unloaded the four boxes and moved everything into the rented 26' van for the drive over to the workshop. In spite of making a reservation to unload this morning and receiving clarification of that, none of the boxes were ready. They were stacked deep inside a multiple row stack of containers requiring workers to shuttle many boxes around in order to get to them.

The boxes arrived at the outdoor loading pad one by one over the course of 45 minutes. As fate would have it, the box with the aluminium loading ramps to allow my machines to roll out of the boxes was in the last to be delivered. Fortunately for me, the three movers I hired were eager to proceed and lifted the machines out of the boxes without a ramp - with these weighing 500 to 1,050 pounds each. 

Loading up the truck

They were great at respecting the D for delicate I placed on the more fragile boxes, filling the truck and securing the load expertly. Within 45 minutes of the last box delivery, we were ready to go. 

TRUCK TO WORKSHOP IN THREE EASY HOURS

I drove up local roads except for the one causeway that linked the mainland where I started with the barrier island between the Indian River and the Atlantic ocean on which the workshop sits. Smooth and easy, nobody cut me off and no lights switched requiring heavy braking, ensuring that nothing shifted in transit.

Beginning to unload into the workshop

The crew expertly unloaded it all into the workshop. Amazingly, all that gear, some 800 cubic feet, hundreds of boxes, tables and other items, were swallowed up in the 1200 square feet of the shop. 

Almost all boxes unloaded

I will take me about a week to unpack all the boxes and begin organizing items into areas of the shop. At first glance, nothing was damaged in transit, but I have to delve deeper to be certain. 

Gave up on U-Haul, going to plan B with them

Monday I called again just in case the four boxes were actually scheduled for delivery that day, but as you could guess from the past experiences I had, nothing was scheduled or even noted in the records. At this point I decided that I needed to unload the four U-Boxes at the warehouse into a truck, drive them over to the workshop and unload them there.

I first attempted to contact a local moving firm but after they heard more about the move, particularly the 1000 pound weight of the 1130 and the other challenges, they passed on the work. I would need to become the contractor and put together the move myself.

The four pods are scheduled to be available outdoors on Wednesday morning at the warehouse for me to unload them. I have booked a 26' truck from U-Haul and arranged for a group of three movers to do the loading and unloading work. I estimate it will be about six hours all told to pull the equipment out of the four U-boxes, load them into the truck, get the truck driven 12 miles to the workshop, then have the crew unload the truck and place the items in my shop. 

All is looking good. I got an email confirmation from U-Haul about access to my four boxes on Wednesday. I see the rental confirmation for the truck on Wednesday morning. I got a text and call from the moving labor group as well. 

Still waiting on U-haul to schedule drop off of my equipment pods

 I contacted U-Haul on Monday to have them drop off my four U-box pods with the computers, equipment and parts to my storefront workshop. They keep promising to call me to give me the scheduled date, but even with a reminder call to them yesterday, I still have no idea when they will drop them off. The workshop stays empty and I have idle hands. 

The boxes are rented by the month and the new month's rent begins today, so there may be a bit of skullduggery involved in the delay as now I have to pay a few hundred dollars for another 30 days rent of the four boxes. Then again, Occam's Razor tells me that I shouldn't assume conspiracy when simple incompetence will explain the observed facts.