Varied tasks at shop while waiting for scale and drive belt

 WAITING ON TOOL TO FINISH M1000 CARD READER REPAIR

In order to set up the card reader after I swapped in a drive belt from the M600, I will need to set two adjustments, using a feeler gauge and a spring scale. Until the tool arrives tonight, I can't get any more done on the reader. In the interim I accomplished a few minor tasks in the workshop.

TESTING MY MODIFIED CARDREAD.EXE APPLICATION WITH NON-WORKING READER

I hooked up the laptop to my external interface box for the M600 card reader. Although both readers are currently not operational, I could at least verify that the modified application communicates with the interface and picks up status correctly.

I was able to connect, see the hopper and error status that occurs when the reader is not powered on, and watch the EOF status reflect the pushbutton and LED on the interface. I also checked that the new "Trunc" button is disabled when it is not appropriate to use it. 

It should only enable when we are verifying a binary mode deck and have at least one card that matched, after which a miscompare occurs between the originally read file and the one being passed through the reader for verification. It will be reset by use of the button or if either the Start read or the Verify buttons are activated. I need an operational reader to test out that functionality and the proper truncation of the original file to the end of the last correctly verified card. 

DISASSEMBLING M600 PICKER MECHANISM TO DEAL WITH ITS ISSUES

When I attempted to set up the M600 reader, the step that sets the picker foot .002" above the vacuum input plate caused it to lock up and not feed. I had to open the gap quite far before it no longer got stuck. The surface between the vacuum plate and picker foot is roughed up, causing the binding. Without a good tight seal the reader doesn't have enough vacuum to guarantee good picking, which is an issue resulting in not only pick checks but errors reading or verifying.

Opening the picker mechanism to restore it

I wanted to disassemble the entire mechanism, smooth the roughed up surface, correct any other issues and get this back into spec. After disassembling things I noticed some magic marker with .010" written near the foot - clearly the setting that let tried to balance low vacuum with the binding of the rough surface. I also see that the shaft on which the picker foot is hooked is chewed up a bit by poorly positioned and tightened set screws. 

Signs that this reader had problems

PUTTING THE IBM 1130 CONSOLE BACK TOGETHER

I had developed a single large PCB with mounted incandescent lamps as a replacement for the poorly designed original boards with SCRs and lamp holders that are a nightmare when a bulb needs replacing. Now that my board is working properly and fits well into the honeycomb, I had to reassemble the console pedestal where these lights will reside.

The plastic honeycombs have the faceplate attached with the legends and openings for the roughly 160 lights. They screw into metal brackets on the sides which themselves are bolted to the insides of the enclosure. On either side of the faceplate there are white metal rectangles that hold the Emergency Stop and Run Mode Switch. These are bolted down to the front of the enclosure and adjusted to fit with uniform gaps to the faceplate. Finally there is a terminal strip that brings the AC power, lamp test and ground lines to the enclosure. 

Run Mode switch from the back

Emergency Stop pull switch from the rear

In addition to the strip, there are about 160 individual wires with clips that push onto pins for each of the lights to be controlled. My PCB has pins in the same relative positions as the multiple small PCBs IBM used. It will be easy to plug them in once the light PCB is placed onto the rear of the honeycomb.

I need to make up some soft wedges to hold my PCB against the rear of the honeycomb, otherwise we are ready to install it and wire it up for testing. There is one other contingency before I can test - I need to get a 240V outlet installed in the workshop. 

FURTHER TESTING OF THE P390 SYSTEM 

I brought up the P390 system, having corrected the seating of the Intel Ethernet card in slot 2. That was giving errors when OS/2 booted up, but now everything comes up cleanly.

I had been worried about the CMOS battery status but with a proper battery installed it has been holding its settings for weeks of downtime. I feel good about the state of this system. Ahead are efforts to connect the 3174 terminal controller to the P390 via WAN cables and to install and configure my 370 parallel channel card for bus and tag peripheral access.

Cardread.exe successfully recompiled, now introducing my modifications

 RESOLVING THE STRCMPI AND STRNICMP USES TO MAKE THIS COMPILE

I wrote my own version of the case insensitive functions strcmpi and strnicmp, inserting them in the code, which made the Pelles C compiler happy. I built the executable and it executes fine as far as tell without connecting it to a working card reader. 

ADDING IN MY MODIFICATION TO TRUNCATE A FILE UP TO THE POINT IT VERIFIED

This enhancement was inspired by the high frequency of verification failures as I read decks with the M600 card reader. I realized that I was often reading 100 cards, verifying to a point through most of the cards and failing on a verification error. I may have to verify again a few times, or re-read and then verify but the process required me to pass the entire 100 card deck multiple times. 

If I could tell the program to just trim the file I had read to the last successfully verified card, I could put those away and resume with only the remaining cards to be re-read and verified. For example, if the bad card was number 76 then I only had to read and test 25 cards as the first 75 are known to be good. 

To achieve this, I add a "Truncate" button on the GUI which is active only when we are in verify mode, reading cards in binary format, and have just encountered a miscompare on some card. The button will cause the file I had been reading for the comparison to be opened in output mode and truncated to the point of the last good card. 

The M1000 reader was reading much more reliably, thus this enhancement is less necessary than with the troublesome M600. Still, I did the design work and have invested time thus I will complete this project and make use of the button for the infrequent cases where I get a verify error going forward. 

Threw away MS Visual Studio as it seems broken, installed Pelles C, working to compile cardread.exe

 Pelles C looks like a great alternative that supports the resource files, is Windows 10 compatible and is free. I installed it and began to build the program but now I have some code to clean up in order to get this to compile at all.

First, some functions were defined with void as a parameter then implemented with an empty parameter list. This compiler throws an error, so I added in the void to get past this point.

More troublesome is the lack of strcmpi the case insensitive string compare function. There does not appear to be an available standard function that does the same, e.g. will return equal when comparing 'Carl' and 'carl'. Assuming I can resolve this neatly I should be read to build and test the program as it was distributed by Brian Knittel. 

Unsuccessfully trying to wrestle MS VS into submission, just to make the unmodified version of Cardread.exe

 MAYBE AN AHA MOMENT AND ROOT CAUSE OF PRIOR FAILURES

I realized that the program was attempting to load the resource for the dialog box but not finding it. I see the RC file, it says it compiled, but it doesn't find it at all or it fails to create the window. All I know is that it silently returns from the call to DialogBox. 

APPLICATION SHOULD WORK PROPERLY PRIOR TO MY FIXES

If I hack up the source code first, I would be debugging not only my code but other issues, such as this one that arose simply trying to build the existing code. 

Had to whip up a card reversing program for decks read prior to my right hand notch modification

 HOW I READ SOME DECKS WITH RIGHT HAND NOTCHES BEFORE MAKING THE MOD

I took the deck and flipped it so that the last card entered the reader first. That also reversed the columns so that column 80 seems to be 1, 79 is in the place of 2, etc. I read the two decks but soon thereafter the jam and belt failure took place. 

I won't need to do this any more, since I have made the modification that protects the reader from false Read Checks caused by light passing around the diagonal notch on the right side and reaching the 12 zone photocell when the card is at the equivalent of column 81. This mod just forces row 12 to be dark at the column 81 time so the error check passes, but if any other row is illuminated then it is a legitimate error that should be flagged. 

QUICK PYTHON PROGRAM TO REVERSE EVERYTHING

I wrote a Python program that seeks to the last card of an input file, reads a card image, then backs up to the prior card position repetitively. I take the 160 bytes of binary data representing the 80 columns and access them in reverse, writing to an output file in the corrected order. The output file will thus have the cards in the proper order, first to last, and have the columns in the correct order, 1 to 80 from left to right. 

The two decks were processed. I did save the program just in case I ever need it or something similar in the future, but that should be the last time I need to process cards this way. 

Documation belt replacement done, adjustments must await arrival of a spring scale

 MADE USE OF THE BELT FROM MY M600 READER

The other reader, my model 600, has some picking challenges that will require quite a bit of downtime rebuilding the mechanism. However, it has the same belt that broke in the M1000. I removed it from that unit so that I could get back to reading before my stock of new belts arrives in the mail. 

BELT INSTALLED BUT TWO SETS OF ADJUSTMENTS ARE NEEDED

Installing the belt requires me to remove the timing wheel for the magnetic pickup, remove three pulleys, loosen and partially unmount the main drive motor, then maneuver the belt. Reverse the process and everything is together, but two key adjustments must be performed before powering on the reader.

First, the main drive belt must be set up at a proper belt tension. That is performed with a spring scale pulling back on the motor assembly until it registers 24 ounces of force, after which I tighten the motor mount screws to lock it in. If it is too low a tension the belt can skip over teeth on the pulleys which will cause misreads. If it is too high, it can wear the belt prematurely or even damage some bearings. 

Second, the timing mechanism requires that the timing wheel be rotating so its teeth are passing right past the center of the sensor pole, and the gap between the pole and wheel is set with a feeler gauge. I have done this previously and have everything on site for that operation. 

SPRING SCALE ON ITS WAY FROM AMAZON

I will need to wait a few days for the spring scale I bought to arrive, before I can complete the two adjustments and put the reader back in operation. 

Built open collector inverter to modify Documation M1000 to read cards with right side notches

 CHOSE SIMPLE BUT EFFECTIVE CIRCUIT

I needed an open collector inverter to tie to the OC inverter that drives the signal path for the row 12 data. No spare gates existed on the board and I wanted to avoid offboard implementations. Since the node where I will implement the modification is an OC inverter with a pull up resistor, all I need is a circuit that can sink enough current to pull the line down to logic LOW when the inverter is activated. 

Pulled up by a 1K resistor to VCC, the node would sink just under 5ma when either of the OC inverters is at low LOW output. Further, I don't want to load the CR81 signal with too much current draw to activate the inverter. I chose an N-channel MOSFET as the only component needed, as it will form a channel to ground for the node when the input to the MOSFET is high. Further, a FET has negligible impact on the input. 

It is important to ensure that the MOSFET doesn't conduct when the CR81 signal is at logic LOW, which can be a voltage above zero defined by the driving chip spec. I did some testing with a breadboard and assured myself that even with a logic low input of almost 0.7 volts, the inverter output stayed high, but any legit high input voltage the FET will pull the output down to almost zero. 

LOCATING THE COMPONENTS FOR INSTALLATION

The MOSFET can be mounted on the PCB near the 13 finger to the backplane which is the source of CR81.  That area has free space with no traces on either side, sufficient to drill two small holes to secure my one component in place. While I won't have copper traces on the board, I can use small jumpers over to ground, directly solder the gate to the 13 inger then run a jumper to the node where I am implementing the wired-OR. 

MOSFET IN PLACE

DRILLED AND MOUNTED IN PLACE, JUMPERS INSTALLED

As you can see, I drilled holes and put the transistor in place on the board. I soldered one jumper between the MOSFET source and ground. Another longer wire had to be run from the drain of the MOSFET over to the 7405N open collector inverter in position 8D on the PCB, to pin 2 which is the output where I am adding this circuit in a wired-OR.

Jumpers to ground and to the new wire-OR node

Archived a few boxes of cards as the M1000 reader gets closer to full working status

 NARROWING IN ON THE FLAKY SECTION OF THE CARD READER

It was my great luck that for a while the flaky behavior turned solid - the reader wouldn't successfully pick at all. The logic analyzer quickly pointed at the issue. The 1Dark signal was permanently on, but should not be until some portion of the card first passes in front of the photocells to block light. 

That transition from logic low to high for 1Dark is what resets the pick cycle and starts the reading of a card, so this blocked the reader pretty solidly. Each pick of a card appears to the circuitry as if the card was NOT picked up, even though it flew through the machine, so the reader tries again for a total of three pick attempts before stopping with a Pick Check.

I grabbed the VOM and tested each of the 12 rows, showing me that it was the 9 position row that was misreading as dark. As I probed around on the card, the issue went away but I do know it is one of the components or connections for row 9 that is producing the intermittent errors.

As an intermittent error, it will manifest by tricking the logic into thinking the card edge has arrived before it really does, thus it reads with a laced hole pattern at the beginning and the data offset a number of columns. In some cases we get an entire card of 80 laced columns, in other cases it triggers a Read Check. Since it is intermittent I can just re-read or re-verify to get around the issue (for now). 

Offset card due to erratic row 9 signal

NEED TO IMPLEMENT MY MODIFICATION TO SUPPORT CARDS WITH RIGHT SIDE CUTS

I attempted to archive the next batch of cards from tray 10 but received immediate Read Check errors, even on the blank first card. Since I had the logic analyzer wired up, I set it to record and trigger to stop when the reader goes into Stop state, a consequence of receiving a Read Check error. 

I could see that the 1Light signal was active at card column 81 time, which triggers the error condition. That occurs when the punched cards have the diagonal cut on the right side rather than the more usual left side. This configuration of card is perfectly legitimate and causes no issues on IBM mainframe card readers. Not so with the Documation. 

I had developed a fix for my M600, essentially it blocks the output of the photocell for the top row (12 zone) when the reader is at card column 81. It required a small daughter board to be added and some rework on the circuit board, not the most elegant solution. I want to make a corresponding modification for the M1000 but hope to avoid add-on boards since I already took up space by moving the Arduino based controller into the card cage leaving little extra room. 

We need one or two additional gates, unfortunately, on a board that does not have any unused gates in any of the installed chips. The board doesn't even have access to the CR81 signal that indicates we are testing for errors at that column position. Fortunately the CR81 signal is carried on the common backplane connector on pin 13, so that we can tack a wire to the finger for pin 13 and receive the signal. 

Several places use open collector gates, so that they can use wire-OR logic to combine tests on all 12 rows. For instance, to generate the 1Light signal, OC inverters for the rows have their outputs tied together and pulled up to VCC with a resistor. If any of the inverters goes low it pulls the entire line down, thus any combination of rows seeing light through a hole (or past the edge of a card) from 1 to all 12 rows will make the line low. 

There is a key point where an inverter for the row 12 signal path is open collector with a pullup resistor even though it only feeds one gate with its output. If I added an open collector inverter and tied the two outputs together, either could force the combined output low. This particular point considers a low to be the absence of light, exactly what we want. Thus, if we feed CR81 to the new inverter, then it will force row 12 to be dark at column 81 time regardless of whether light is leaking past the diagonal cut. 

We still have the issue of where to put the open collector inverter. Possibilities include implementing it on another PCB entirely and bringing the signals up through the card cage, wedging a small daughter card next to the PCB, or building a transistor circuit that is effectively an OC inverter. 

I believe that I could fit the transistor circuit onto the PCB, avoiding the need for daughtercards or use of gates on other PCBs. I will sort out the best place to install it on this board and then implement the modification. 

MUFFIN FAN GOES INOPERATIVE, SWAPPED IN THE FAN FROM M600 READER

The rear cover of the card reader has a large muffin fan to cool the motor and power supplies inside the base. It began to buzz while not rotating at all. Since I have another reader, the M600, I simply swapped the rear covers and continued working with the M1000. At some point I will look into the fan and buy a replacement. 

ARCHIVED A COUPLE OF BOXES OF SOFTWARE WITH THE READER

Once I had the reader working, with only sporadic induced errors with the row 9 signal, I could archive cards. This reader picked much more reliably than the M600 and makes almost no reading errors. I worked through a couple of boxes of software, reading 100-200 cards at a time but probably could have read much larger decks given the excellent reading when row 9 isn't misbehaving. 

TRAGEDY STRUCK DUE TO A HIDDEN INDEX CARD IN A DECK I WAS READING

Alas, I heard a loud thunk and saw a pick check near the end of a deck I was reading. When I looked closely, I saw that an index card had been inserted between cards with handwritten instructions for how to operate the particular utility program. It is thicker than a punched card so it jammed solidly in the entry throat. The sudden deceleration due to the wedge caused the main timing belt to snap!

Snapped belt

The broken belt

SOURCING A REPLACEMENT BELT

The machine had a Pirelli Isoran 160XL 025 belt that connected the motor, roller pulleys and timing wheel. It does appear that I can readily find a suitable replacement then will have to install it and set the adjustments of all the pulleys to each other. It will be a week before the new belt arrives. 

Enhancing Brian Knittel's Cardread.exe to improve productivity archiving old decks of cards

 MAIN CONCEPT OF THE MODIFICATION

When a verify error occurs, a new pushbutton on the screen will offer the ability to accept all the cards that in the stacker except the last card which is the one that caused a verify mismatch error. Those accepted cards can be removed, leaving a hopefully much smaller deck.

That permits me to only deal with the card causing the error and all subsequent cards. These can be read and verified in their own two passes. Since I can accept as much as has been properly verified, I am able to make faster progress through the pile of cards to be archived. 

I read cards in the binary mode, the only lossless way to capture the data. As such, I only implemented this improvement to work with binary mode capture.

HOW IT WORKS

When a verify error occurs, the card reader has been reading each card of the deck as a second pass. The first time the deck was read it was placed into a file on the PC. If there is a mismatch between the hole patterns of the first and second pass, the verify process ends with a failure message. 

At this point, the program has closed the disk file that contains the first pass of the deck, but the full file path is still available in a global variable. If we open the file, determine its end position, drop back one card and truncate the file, we can accept the saved file up to the point of the last successfully read and verified card. An alternative to opening the file 'rb', doing an ftell on the end and subtracting 80 words is to keep a count of words or cards as we are doing the verify so that we can subtract from that to generate the new end of the file. In either case, we open the file 'ab' and do an ftrunc to shorten the file to out desired length. 

IMPLEMENTATION CHALLENGES

The biggest challenge was fighting with Visual Studio  to generate an executable. I can't get the initial window (a DialogBox) to open, the program falls right through that call and exits. I am not and never have been a windows programmer. This may be something simple but until I have the first clue about why it seems to fall through (debug Step Into function of Visual Studio just drops through) I can't research for a solution. 

Will keep you posted. No sense writing code until the baseline app can run. 

Completed testing 74182N chips, diagnosing the M1000 card reader moves forward

 BUILDING BUFFERS ON A BREADBOARD TO COMPLETE CHIP TESTING

Since the chips in question draw well in excess of the 8ma max that the Retro Chip Tester Pro will sink from the input when they are set to logic low state, I made use of two very high capacity buffer chips from my inventory. They were wired up on a breadboard and hooked to the chip under test making use of the Breakout Adapter from the chip tester design files. 

Failure due to inadequate sink current capability

The 7407 chip is a TTL hex buffer, open collector, that can sink up to 40ma per pin and tolerates up to 30V logic high levels, definitely in excess of the needs for this test but they were handy. I put two on a breadboard since I have a total of eight input pins to drive, four propagate carry and four generate carry signals. 

I wired the chip to +5V, tied the ground together to the tester pin that fed pin 7 of the 74181N. Pulling the jumpers from the eight input pins disconnected the chip under test pins from the tester pins allowing me to wire the chip under test to eight of the buffer outputs and the tester pins to the corresponding inputs of the buffers. The outputs were pulled to +5V by 4.7K resistors since this was an open collector chip. 

The tests ran to successful completion for all of my 74182N chips on hand, now that the test can drive the chip adequately. 

Buffer chips in circuit to the eight inputs being tested

DIAGNOSING THE M1000 CARD READER

Once the logic analyzer was fully connected and the signals all verified, it was time to run tests again. Previously the reader was balking at reading, immediately throwing a Read Check and Stacker Check when I attempted a pick. That was not present today - but I worry about erratic behavior. 

I saw the signals registering properly on some runs with the analyzer capturing data, so I hooked up to the laptop and read a small sample deck, flawlessly. I was very pleased and moved over to my COBOL compiler deck to begin archiving that. 

Alas, the gremlins came back. Every card read properly according to the eighty columns of data I captured, but the reader threw up a Read Check error at the end. This comes from the reader checking at the time for column 81 to verify that no lights are present, and again at the time for column 84 to verify that no lights are blocked. This tests that the right edge of the card is in the correct position at the end of a read. 

This flaky behavior is going to be a challenge to troubleshoot. I need to swap the card extender from the Clock card position where it was to the Control Card position which is where the Read Check is generated, so that I have ready access to the pins on the card as well as the backplane signals that are wired to the logic analyzer. 

I can already see that the magnetic pickup is working properly and registering the card column counts properly, based on the data I was capturing, so the error must occur past column 80. I will be prepared to detect that, assuming the reader has not moved on to some other behavior when I next power it up. 

Cause discovered for failure to test 74182 with chip tester

 INTERACTING WITH THE DESIGNER OF THE RETRO CHIP TESTER PRO

Stephan Slabihoud, the maker of the tester, was kind enough to exchange some emails and lead me to the root cause of the issue, which is the inability of the ATMEL 2560 based I/O pins to sink enough current to pull the inputs of the tested chip properly low. 

His document for the tester mentions excessive sink currents with some TTL logic chips but it also mentioned that he had modified the tester design with smaller protective series resistors to increase the drive current as a solution. I should have taken the hint and examined the data sheet for the chip I was testing, but I rashly assumed 'problem solved' by the modification he introduced into his design.

THE REQUIREMENTS OF THE SN74182N CHIP ARE HIGH

The inputs, four each P for propagate carry and G for generate carry, require from 8ma to almost 15ma of sink current with the design recommendation in the data sheet suggesting that they be driven by a source that could sink up to 20ma. Whoops! Far from the 8ma max available on the tester. 

My failure occurred when the tester was setting the four P inputs low. These require only 8ma max (typically per the datasheet) per pin, so they were easier to drive than the G pins that were currently high for this test but would be blipped low as the testing continued. 

SOLUTIONS TO TEST AS THIS EXCEEDS THE CAPABILITY

In spite of the impressive capabilities of this tester, easily able to test hundreds of logic chip types, a very few older chips are beyond even its capability. In fact, if I were to bridge all the protective resistors of the chip tester I would be putting the sink current dangerously near the maximum of the ATMEL processor chip, possibly damaging it. 

Of course, testing offline using a breadboard is a possibility. I have about a dozen of these lookahead carry chips to test which will be a slow and tedious effort. 

I could skip testing these as the chance I will need to use one is pretty slim. I could postpone the testing until the time when I would actually use one. 

Finally, I can build a small breadboard device with buffers that would drive the chip under test based on the signal injected by the Retro Chip Tester Pro. That is, I would use my adapter that allows me to remove a jumper that bridges any pin between chip-under-test and tester. I could take the pins from the test socket out to my buffer board, with the redriven high current output routed back to the pins applied to inserted chip under test. 

If I do this, I will be able to run through all the tests on the chip in question. Further, if I come across any other TTL chips with excessive drive current requirements I can use the same buffer structure to test them. 

Narrowed list of causes for chip tester failure, instrumented M1000 card reader and looking at problems

 CHIP TESTER ISSUES WITH SN74182N CHIPS

As I outlined in the previous post, I first checked the chip on a breadboard to assure myself that the entire group of chips weren't bad with the same fault. As I expected, when all four P (propagate) inputs were low, the P output was indeed low even though the tester reports it as high. 

Further the voltage was low enough that I discounted any issue with invalid levels causing the tester to see the result as high. I hooked up the scope and watched the tester first set the P inputs high with the P output validly high, then drop the P inputs which forced the P output low. The tester, however, claimed it was high and flagged it as an error. 

I have contacted the designer as he may not have tested this particular chip type and there may be a defect in the test itself. I may put the logic analyzer on the signals to see whether this is a race condition in the test or a real issue.

INSTRUMENTED CARD READER FOR INTENSIVE DEBUGGING

I wired up 32 of the 34 signals from the backplane to the logic analyzer where I can record their state as it operates. The two I didn't record are Power-On-Reset and Reset, neither of which are germane to debugging the operation of the reader. 

FRUSTRATING STATE OF CARD READER

With the logic analyzer hooked up, I can see odd status of some of the signals. I put the reader into its manual trigger mode so it will read cards as fast as it can, while watching the logic analyzer to see the outcome. However, the reader read the batch once and began acting up. It now indicates both Stacker Error and Read Check immediately upon the attempt to pick, before the card actually begins moving at all. 

I did check the power supply as flaky or substandard voltage levels could induce strange errors. It appears to be solid with almost no ripple. I am back looking for bad chips or other explanations for the misbehavior. 

Investigating anomaly testing SN74182N chips with Retro Chip Pro tester

 ALL MY 74182N CHIPS HAVE SAME FAILURE ACCORDING TO THE TESTER

The SN74182N chip is a Look-ahead Carry Generator for use with full adders to implement wide word adds without the delay of a ripple carry. It is typically used with the full adder chip such as 74181N which takes the inputs produced by this chip and provides the appropriate propagated carries. 

The G (generate) output is on if the adder generated a carry because both A and B inputs were high. The P (propagate) output is high when A and B are opposite logic values, either HL or LH.  If the Generate is true, there is a carry to the next higher bit adder regardless of the value of the carry input to this bit position. If only the Propagate is true, then the carry input of this bit position is passed to the carry input of the next bit position. If neither is high, no carry is passed to the next bit position.

One of the tests per the chip data sheet is verifying that when all four propagate inputs are low, the propagate output should be low.  The concept is used to pass the carry input to our 75182 chip when all four bit positions covered by the look-ahead chip are true. This is slightly muddied because the propagate inputs and outputs are all inverted - a high value means NO propagate. 

The tester flags that the propagate output pin (7 on the DIP) is high but should be low, when it sets all four propagate inputs to low. Any other combination of inputs would produce a high but this set of inputs should have created a low output. 

Since I have every such chip I own showing the same error, and these come from separate batches and sources, something is up. I doubt that all the chips are defective in exactly the same way, although there is an extremely low chance that some manufacturing feature is going to fail years after manufacture on every chip. Extremely low chance.

While it was possible that the test is incorrect, I looked at the datasheet and come to the same conclusion - with all four inverted P inputs low, the inverted P output pin should be low. I will set up a breadboard and test that the chip performs as expected just to put a nail into this unlikely explanation for the failure.

That leaves me with the possibility that some build error in my tester is causing this. One of the four input pins may not have a valid low even though the tester believes it is generating the proper code, or the output pin may be driven high by some erroneous signal. I will check for this using an adapter I built that lets me isolate one or more pins from the tester so that I can see what the chip is producing AND what is on the tester pin side without them interacting. 

Almost every chip I have tested has passed its tests. That should have already exercised the input pins and the output pins which makes me wonder what exactly is going on. I suppose that we could have a programming error where the test for the 74182 chip is not really looking at pin 7 but at some other pin when it senses the high. Finally, I can imagine a case where the output voltage for the low condition on pin 7 is high enough to register as a high on the tester, but I only include this for completeness. 

Stay tuned for the results once I am back at the workshop and can conduct the tests to narrow down the fault and draw conclusions. 

Archiving steadily with pauses to battle Documation card reader isI asues

 PROGRESS ARCHIVING CARD DECKS

I completed reading and organizing tray 9 of the 15 trays of software I own. In addition, am down to 14 card boxes of unread software. Overall I have less than 50,000 cards remaining to process. 

One item I discovered while archiving is a complete distribution deck for the DNA Systems RPG-II compiler, a product they sold to replace the RPG compiler that comes with the 1130 Disk Monitor System. Presumably this is a more complete and modern compiler. 

M600 CARD READER ADJUSTMENT BATTLE AND BALKY PICKING

The M600 reader is the one that I used for all the cards I have read to date. Its picking declined as I described in a prior blog post, due to the picker arm becoming loose on the \solenoid shaft. I started through the 24 steps to adjust the picking mechanism, but discovered some issues I have to resolve before I can successfully set this machine up.

The loose picker arm created scratches where it rotated against the aluminum frame, right where the vacuum supply is delivered to the picker arm. When I used a .002 feeler gage to set the gap, the picker arm would stick and not snap back to the ready position. I had to make the gap much wider which defeats the purpose in order to have the arm operate with almost no binding events. 

I believe I have to disassemble the mechanism and polish the surfaces before I can make the adjustment as required. This will be a multiple hour project which I deferred while the reader was still reading cards adequately. 

Sadly it has degraded again to the point where it isn't good enough to continue reading the decks with that machine. I will try to get the M1000 fully operational since i know that picks superbly, but also have the repairs for the M600 to restore it to a useful state.

M1000 READER FLAKY BEHAVIOR

I modified my card extender for the reader to install pins for all the signal lines. That makes it easy to hook up the logic analyzer and/or the oscilloscope for debugging. It took a couple of hours to finish the card but I put it into use.

Last time I tried the reader, it was sporadically generating garbage input to the controller and generating Read Checks. I set up the extender and some logic analyzer wires to troubleshoot this situation, but the reader was no longer producing Read Checks. 

I methodically checked all the signals for the backplane to see where the reader might be malfunctioning. Initially I saw some signals that weren't operating properly but after I began documenting the state I found the reader seemingly working properly. That is the logic which controls the card flow and generates the output signals for each column were working fine.

I then hooked up the controller to my laptop and tried to read the card decks. What I saw was the complete absence of any data being returned to the controller. The laptop program knew that it hadn't successfully read any cards. 

Next up, I moved the extender to the clock card so that I could watch the Index Marker pulses being presented to the controller. I discovered that the backplane signals that worked well before and controlled the card column behavior were failing again. 

This is very erratic and quite difficult to debug when problems come and go. I left the shop and will devise some strategy to figure out what is going awry. I might have to set up the logic analyzer and record everything in order to see what drops out when it the flaky behavior arises. 

Partially adjusted M600 card reader and resuming archiving decks

 ADJUSTMENT PROCEDURE FOR THE PICKER MECHANISM

The procedure consists of 24 steps, setting such factors as picker shoe height, throat width, rest position, end position and vacuum clearance. Most are accomplished with allen wrenches and feeler gages. Unfortunately my metal ruler was back at the condo and not in my shop. It is needed for step A of the procedure and they should be accomplished in strict sequence.

Rear adjustments for rubber foot

Picker 'motor' (rotary solenoid)

Rubber foot

EXAMINATION REVEALS CAUSE OF CLANKING AND MISFEEDING

As I examined the machine to locate all the places that I might need to adjust and where I needed to perform measurements, I noticed that the rubber foot was not securely fixed on the shaft of the picker motor. It could slide up and down and the motor might not be able to swing the foot to the intended locations to make a pick work.

By simply moving the foot to a reasonable height on the shaft and tightening it down, the reader began to accurately feed cards without the clank heard previously. Until I have the metal ruler, I can't complete the 24 steps precisely, but it appears suitable to do archiving. 

FINISHED MOST OF TRAY 6 SYSTEM SOFTWARE AND A PRINTER ART DECK

Just to satisfy myself that it is working adequately, in the short time I had available I fed about 2200 cards of DMS system software and a 250 card deck that is some calendar printer art. The rate of errors was negligible for the DMS software but more annoying for the printer art, similar to my experience before the reader had worsened. With a proper adjustment it might work even better, but at this state it is still adequate to complete my archiving work.

Archived cards, M600 reader now out of adjustment and misfeeding, but M1000 reader nearly ready to take over

 OVER 1/3 THROUGH THE ARCHIVING OF 145,000+ CARDS

I have completed five of the 15 trays of system cards and archived about a quarter of tray 6. Further, I continue to read and save the COMMON submitted decks and soon will start on some IBM distribution boxes and programs used by the prior owner to operate his business.

M600 CARD READER BEGINS CLANKING AND MISFEEDING

I will hear some clanks and metallic sounds on certain feed attempts. The reader is also failing to pick cards much more than before. The troubleshooting guide suggests that this sound is either misadjustment or wear in the parts that accomplish the pick/feed. 

There is a series of adjustments that I will have to put the mechanism through in order to have it properly set up. If there is wear, for example in a bearing, I will learn that as well during the process ahead. Until this is done, the main reader I was using and its external interface are unusable.

M1000 CARD READER GETTING CLOSER TO FULL OPERATION

The magnetic pickup is again reading as fully connected and functional. The oscilloscope shows good clean pulses being detected and the reader logic is working properly. I finished installing the internal interface and connected it to my laptop to test reading some cards.

The problem I am encountering now is random Read Check errors. The data that is showing often has dozens of columns apparently laced with holes, although the actual cards are not punched like that. If light is detected and times when the card should not be over one of the 80 columns, or dark is seen when the card should be past the read station, the Read Check error is triggered.

This could be caused by sporadic circuit continuity problems with the magnetic pickup, if that causes the logic to miscount and believe the card is already past column 80 when it is physically still in mid stride. It could also be a different error that I have not yet found and debugged. 

Still, the pick mechanism and feeding seem really healthy. If I can resolve the erroneous read errors and its root cause, I will be ready to archive more cards with the new reader.