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. 

M1000 reader magnetic pickup fails again, verifying more of my chips, continuing archiving of decks

 TESTING OF INTERNAL CONTROLLER REVEALS MAG PICKUP FAILS AGAIN

I hooked the scope up to the Index Marker (IM) signal line and saw zip. I then noticed that the behavior of the reader indicates that the original problem I had with the magnetic pickup is back. That is, the pickup is not delivering pulses at all. Those are important in order for the reader logic to recognize that a card is feeding through the photocells and to time the points to read the eighty columns.

I was working on finding the open circuit in the pickup when I found it working again, so I simply installed a new cable and put it back into the reader. It seemed to work properly for a while but just as randomly the connection has failed again.

I am going to attempt more significant surgery on the pickup - cutting into the sealed block and inspecting until I can clearly spot the broken wire. I am assuming that it is broken from where it exits the wound coil up to the point where the external cable is attached; in that case, if I can see the break I can repair it. If it has failed deep in the windings, I am out of luck.

The alternative is to get another pickup that can detect the teeth of the wheel and generate pulses to feed into the logic circuitry. That may involve machining a different holder since I would have to be extraordinarily lucky to find a substitute with an identical size and shape. 

WORKING THROUGH MY MANY BAGS OF IC CHIPS TO DISCARD FAILED ONES

Over the years I have acquired plenty of integrated circuits, with some of them coming from auctions, surplus shops or other sources where I can't be certain that the chips are new and working well. The range of chip types is very wide, including many rare or obsolete versions that are not supported by most chip testers. 

The 8bit-museum.de Retro Chip Tester Pro that I built covers a more comprehensive set of devices - far more than the other testers I have used. As a result, it has tests built in for the majority of the devices I attempt to test. 

I spend time on every visit dumping out bags of chips, sorting them into lots of the same part number and then testing them. I have found a few bad chips. Just as importantly, I have satisfied myself that the bulk of these devices work correctly and can be used in future projects. 

ARCHIVING MORE BOXES OF PUNCHED CARDS

I used the 600cpm reader to archive another one and a half boxes of COMMON programs. These have read fairly reliably, although the heavier work is studying, testing and documenting them afterwards. I also tried to read more of the DMS R2 M12 deck but these cards are very touchy to scan. The rate of misreads, either on the first pass or on the verification run, forces me to take them 20-30 at a time and feed them perhaps five or ten times before I get a good captured file. 

Spent hours organizing DMS files and testing all the COMMON programs I have archived

 DMS FILE ORGANIZATION

I took the batches of cards that I had read, clumped them into larger groups and then split them into the individual phases that are loaded during and initial or reload of DMS onto a disk cartridge. You end up with many, many dozens of phase files plus other files that are assembled into a huge virtual card deck. On the real machine, that deck is loaded in the card reader, a blank disk cartridge is inserted in a drive, and then the deck is loaded by pushing the boot button (Program Load) on the 1130.

A deck consists of the following:

Three loader files in sequence. First, a single 1130 loader card that is the subject of the boot operation. That card's program then reads in a single card that is the 1800 loader; the 1800 is the big brother of the 1130 which was used for real time process control tasks. Finally, the 1800 loader program reads in a multi card deck which is responsible for reading in the system loader. 

The system loader is split into two phases. The first begins to format the disk cartridge and reads the next set of cards which are the data and permanently resident system code areas that are put in the special boot areas of the disk cartridge. After this 'EMN' permanent code and data file comes the system loader phase 2, which is the logic that reads most of the deck of cards and stores each phase on the disk.

A few control cards are inserted by the user that define the peripheral configuration, storage size and defines the ranges of phase numbers for each of the major sections of the monitor system. These are functional areas such as the job control, disk update program, fortran compiler, assembler and core image loader. 

The last phase of the monitor is followed by a 'type 81' card which tells the loader that it through with loading phases onto the disk libraries. The machine then fires up the monitor and runs the DUP program to start loading the system library components such as functions and subroutines. These are small object decks with a *STORE directive in front of each one. After the long string of library components is loaded, the process ends and the disk is now ready to be cold started by hitting Program Load with a cold start card in the reader. 

I have archived one complete deck to load the older V2 M11 version of DMS, a second complete deck to load the newest V2 M12 version, and have started on a third deck which is also a DMS V2 M12 load. Since I have multiples of the deck and have versions of the card decks from other sources, I can do a compare to make sure that I didn't garble any code during the archiving. 

I ran a few comparisons already with no differences detected. As a test I compared the System Loader Phase 1 decks between the two version, M11 and M12, which did flag a reasonable number of differences. I will continue to work with the files until I have compared and verified everything. Preservation of the 1130 system files is the most important aspect of this archiving for me.

TESTING THE PROGRAMS FROM COMMON AND IBM PROGRAM DISTRIBUTION

I have reviewed all the files I have archived, written a short description of what they accomplish, and tested them on the IBM 1130 Simulator as much as feasible. In many cases I include part of the virtual listing from the line printer, particularly for printer art. 

Read almost four boxes more, plus started testing of the internal controller on the M1000 reader

 FINISHED DMS V2 M12 SYSTEM LOAD DECK INCLUDING MANGLED EDGE CARDS

Two of the boxes were the system load plus sample programs in Fortran, RPG, Cobol Assembler plus a few utilities. The sections where the edges near column 1 were torn up gave me the most difficulty, but I was finally able to coax them through and verify the results. 

When a box is particularly troublesome I have to move to small batches, 20 to 35 cards apiece, which means I end up with very many of these small deck files to consolidate. I whipped up a python script to pull them together on my PC.

A box of programs from the COMMON user group was also among the work I accomplished today. The work is just begun when I finish reading, as I have to figure out what each deck accomplishes, document it and test it as much as possible. With as many boxes as I read today, I wasn't able to finish all that back end work by the end of the evening. 

I did find the program that produces music on a nearby radio held near the processor, the complement to the decks of music data I had previously archived. Similarly, I had found a nude woman on stool printer art program which called a mystery program wxyz to print the stool itself. Today I found and archived that program, which completes the printer art work. 

I then began on another reload deck for DMS V2 M12, archiving about 1/3 of a box before I left the workshop. These have intact edges but don't slide smoothly apart so that I have a medium rate of misreads and verification errors. 

TESTING OF THE INTERNAL CONTROLLER ON THE M1000 DOCUMATION READER

I powered up and connected to the controller from my laptop. The connection was successful and it appears to reflect the machine status accurately, although I didn't force very combination of states. The pushbutton toggles the EOF lamp on. Finally, the controller code issues a pick command and drives the reader to move cards through the machine. 

However, no data is transmitted to the PC. Tomorrow I need to monitor the IM line to see if the index marker pulses are arriving which is what triggers the Arduino to capture the hole patterns for each column. This could be wiring, bent pins on the shield, or another defect in the card reader electronics, to be resolved as I test the IM line. 

Fixed retro chip tester and archived more card decks

 RETRO CHIP TESTER DEBUGGING AND RESOLUTION

I flashed the test firmware that would allow me to cycle the voltage rails to the pin.s on the testing socket where they could be routed, as well as cycling signals to all the pins. I quickly discovered that pin 1 of the tester had a constant application of -5V applied to it. 

Tracing the pin back I found the circuitry that could deliver voltages to it - one was a transistor routing +5V but the other was a relay that switches in the -5. That in turn was ARbeing activated improperly because, shame on me, I had inserted the UL2003 backwards! The UL2003 is seven darlington transistor pairs but with pin 8 installed where pin 1 belongs, it fed power to the relay.

Putting the chip into the socket in the proper orientation resolved everything. Fortunately the mistake didn't damage any other components. After I flashed the production firmware I used the tester to validate chips like 7423 that weren't covered by my other chip testers. I validated several dozen ICs, fulfilling my hopes when I took on this project build.

ARCHIVING CARDS CONTINUES

I worked my way through a box (2000 cards) of programs contributed by members of COMMON. These read pretty well - some of them flew through with almost zero errors, other sections were a bit funkier, but I was pleased with the progress. I then turned to a reload deck for DMS V2 M11 which had been in a card tray in a cabinet back in Kansas, where the humidity the basement caused the cards to swell so much they were locked in place. 

The team helping me extract the 1130 could not release the latch to remove the cards in those trays; they were forced to pry sections out to relieve enough pressure to remove the rest. Sadly, this DMS deck had considerable damage on the two sides of the cards, near columns 1 and 80. 

Leading edge of card deck quite damaged

Amazingly the Documation could still get the cards through, albeit with time sucking manipulation that sometimes meant fighting individual cards to read. This will take many many hours to finish reading. 

Continuing the card archiving, finished retro chip tester pro, wiring internal Documation controller

 THREE MORE BOXES OF CARDS READ AND ARCHIVED

The number of reading errors varies dramatically from box to box of card and I don't yet see a pattern to warn me of troublesome decks. A two box set of cards that load DMS V2 M11 (the disk monitor system, compilers and utilities that are the equivalent of the operating system for the IBM 1130) read so smoothly that I only had three cards fail to verify, two of them were errors in the verify pass and one was an error when reading a card on the first pass. A box of contributed programs from COMMON, the IBM users group, on the other hand, was a nightmare where a hundred card deck might require ten or twenty passes to get the data read and verified. 

With the card contents captured, I could move on to phase 2 of the archiving. That is an examination of the decks to understand what they are, which guides me to further work. Sometimes I realize I have two more more logical items in one marked deck and split them up.

I want to end up with a folder for each deck with a descriptive name. In it there will be a text file where I describe what this deck represents and highlights any errors or missing elements. In many cases I run the code on the IBM 1130 simulator to make sure I understand it properly. Where it makes particular sense, I include a text file that is the printer listing output. 

The files I captured include printer art, games, utility programs and the disk monitor. As an example of a very useful utility, I came across programs that write various pause and error conditions to the console printer. In normal practice, a program issuing a PAUSE command will display four hexadecimal digits in the accumulator, visible only on the lights. There is no hard copy evidence of this, so that once you push Start and move past the pause, all record is gone. 

Other conditions produce monitor errors as four hex digits in the accumulator. This utility will type ERROR xxxx on the console, drawing more attention to the issue and making a hard copy. This was handy when I was trying to run a printer art program, because it had a defect that lead to the monitor detecting error F001 and pausing execution. It was helpful to see ERROR F001 printed because you might miss the error otherwise. 

When the card reader runs out of cards, the system waits with a particular address displayed in the console lights - one is accustomed to the monitor waiting and may not carefully examine the lights to distinguish an error from a normal end of job stop. 

I wrote up the order of the decks for someone who wanted to run a fresh install of DMS V2 M11 on a blank disk cartridge - along with the decks themselves. This makes the archived decks more useful than an assemblage of randomly named deck images. 

FLASHED FIRMWARE FOR RETRO CHIP TESTER PRO, FINISHING ASSEMBLY

The last step in building the chip tester designed by Stephan at 8bit-museum.de is to load the code onto the Atmel 2560 chip. The PCB he provides comes with the Atmel soldered on, but not programmed. I picked up a suitable programmer, hooked up and flashed the chip.

I brought it up. All lights were good and the menu system works on the LCD display. I started in testing some chips that weren't covered by the other testers I own, such as the 7475 and CD4050. However, some other chips that are supported came up with errors upon test. More worrisome, either the 12V or the -5V power supply LEDs blinked off during these failed tests. 

I suspect that something is not working properly, applying the wrong rail voltages or hooking more than one supply voltage to the same pin. A construction error undoubtedly. There is a diagnostic firmware load that will selectively apply the rails and signals to each pin, letting me track down the issue.

INTERNAL CONTROLLER FOR M1000 READER GETTING WIRED UP

I removed the old socket from my previous controller and moved the wires over one by one to the Arduino shield that will connect a Mega2560 with my controller sketch. I finished all the signals that were used by Brian Knittel's controller but two additional lines from the reader are used by my controller - Motion Check (MOCK) and Busy. I have to identify the wires for these two and hook them up, along with the LED and pushbutton. 

Card reader interface fully working, beginning the archiving of all my decks

 FINAL FIX MADE TO BYTE ORDER OF WORDS, FLASHED ARDUINO WITH THE CODE

After I adjusted the code to send the two bytes for each column in the order expected by the CARDREAD.EXE application, I flashed that sketch, without a bootloader, to the Arduino Mega2560 inside the external interface box. It was ready to test. That was the last fix, as the unit now reliably read the card images into the file as displayed by the companion DECKVIEW.EXE application.

Cards faithfully captured

STARTED WORKING ON THE ARCHIVING OF WELL OVER 100,000 CARDS 

I can now begin the highest priority task I have, the reading and archiving of all the boxes of punched card programs and data that I hauled with me from California. I begin with around two full boxes worth of cards, consisting of various programs and test data. 

It takes a while for a deck of cards to read correctly - they are a bit sticky from the years of storage, thus from time to time there is a bit of drag as one card slides off the deck. This can cause the data in certain columns to be read as the adjacent column. 

To catch these issues, I read the file and then pass the deck through again in verify mode, where it reads them and compares the data to the stored file. When I get a verify error, it can be an error made during the second pass or it can be an error in the pass that was captured to the file. It takes several tries to figure out which is correct and to get a stored file which verifies properly. Different decks, varying in condition, read with more or less issues and take different numbers of passes to complete. 

The time it takes to make all these passes and yield a verified fail slows down the rate of reading dramatically from the nominal rate of the hardware. The Documation model 600 can read 600 cards per minute at full speed but my net rate of finished reading is only 1200 cards per hour. That is about 30 times slower than the theoretical. This means that it will take about 100 minutes, one and two-thirds hour, per box to archive.

BUILDING INTERNAL INTERFACE FOR DOCUMATION 1000 READER

I now have a reliable Arduino based controller for the reader which I will install inside the other card reader I own, removing the need for an external box and cabling to drive the machine. A USB port on the rear of the reader will let me link it to the card reading application on a PC. 

I have a shield that consists of a set of holes I can attach to wires, linked to each of the Arduino pins. It forms a compact sandwich with the Arduino that will easily fit in the gap inside the Documation card cage between PCBs 3 and 6. The two unimplemented card positions 4 and 5 are a comfortable space. 

I began soldering the wires from the Documation cards that had run down to the external cable connector, but are now available to hook to my shield. When these are done, the only remaining task will be to build a card sized base that slides into slot 5 and supports the Arduino/shield sandwich. 

I had previously installed a pushbutton and LED for the End of File function that is part of the card reading application process. These hook to assigned pins on the shield just as they do in the external box  I finished debugging this morning.

Existing CARDREAD.EXE drives Documation reader properly, formatting mistake in returned data; P390 minor issues

 FLASHED INTERFACE BOX WITH SKETCH SANS BOOTLOADER

I brought my Arduino loader over to the external interface box I made, wired the two Arduinos together and downloaded the sketch without bootloader. As expected, the original CARDREAD.EXE program, written by Brian Knittel, could now faithfully communicate with and control the card reader.

Interface reading cards controlled by this application

I had it read a couple of cards into a file in binary mode, but the resulting file was garbled. After examining it for a bit, I realized that it was my error in how I returned the data from my interface controller up to the PC.  The fix is easy, just a tweak to the sketch and reload it without a bootloader.

Data as passed to the application

Actual cards being read

Brian had his controller return the lower four rows of the card in the first word, padded at the end with four zero bits, then followed it with the word reflecting card rows 12, 11, 0 down to 5. I unfortunately reversed the order of the two words. It was easy to spot when reviewing the pattern of the data in the file. 

Brian's protocol document excerpt

P390 SMALL ISSUES TO WORK ON LATER

The P390 booted up with a post-BIOS error 184, which states that the startup password was corrupted. Since I have not set a password, this suggests I still have some issue with the CMOS battery and storage for configurations. Perhaps it is caused by damage from the twisting that the motherboard sustained. 

OS/2 reports that the gigabit ethernet NIC card is not found, although it is sitting in slot 3. This could be caused by many things. The planar could be damaged causing that slot to not work. The card itself might have been damaged in the twisting. Just as likely, the IRQs and other configuration details were lost when the CMOS lost its data and the default way it was configured is blocking access to the card.

Existing CARDREAD.EXE can communicate to Arduino interface with bootloader removed

 LOADING SKETCH WITHOUT THE BOOTLOADER

The Arduino IDE includes a sketch that will turn an Arduino into a programmer that can load the flash memory of another (target) Arduino with a sketch. The two are wired up with their SPI interfaces connected, such that the 'programming' Arduino will reset the 'target' and transfer an incoming sketch into its flash. It is possible to load the sketch without any bootloader on the 'target' system. In that way, the sketch begins execution almost instantly.

RESULTS AT HOME WITH THE ARDUINO INTERFACE

I loaded my interface controller sketch into my Arduino using the method above, then started up the CARDREAD.EXE application pointing at the COM port to my Arduino. The app connected and was happily exchanging status requests with my controller. 

I used various jumpers on the Arduino to alter various status signals, which were then correctly represented on the GUI of the application. I feel that this will permit me to connect the Documation reader to my controller using this method of installing a sketch without a bootloader. I intend to test the reader tomorrow using the existing Windows application. 

Visitors gone - back in the workshop

 DEVELOPMENT OF ALTERNATIVE CARDREAD APPLICATION IN PYTHON

I am writing an application to drive the Documation card reader and store the data in files using the 'binary' file mode of Brian Knittel's card reader interface programs. I adopted the same protocol that he uses with the Arduino based interface hardware I engineered, thus potentially allowing his program to drive my interface.

However, while I work on resolving the issues running his program on my Windows 10 based laptop, I have been working on my own program to replace CARDREAD.EXE just in case I can't resolve the problems using his code.

I started out with a command line program but have been switching it to a quick and dirty GUI making use of the tkinter library that comes with Python. Eventually, if I have to continue using the program, I will pretty it up including displaying a card with the holes displayed for the card that was just read. 

TESTING WITH DOCUMATION READER

I did some testing with the command line version of my program and worked out some issues. It does report status of the reader hardware properly and will make the reader pick cards. However, I don't yet have it capturing the incoming data words from the cards as they are read. 

BUILDING RETRO CHIP TESTER PRO (DESIGN OF 8-BIT MUSEUM)

I have a huge collection of chips of all types, most of which I couldn't test with the existing chip tester systems I own. I was impressed by the range of devices that are supported by the Retro Chip Pro tester developed by Stephan Slabihoud at his 8-bit computer museum ( http://8bit-museum.de ) and purchased the PCB and related documentation from him. 

I ordered all the myriad parts required to populate the board, so that when the board arrived a couple of days ago, I would be ready to begin assembly when I returned to the shop. That moment was today. I carefully mounted and soldered all the parts to the main PCB, the daughter-card power supply board and set it up for multiple powering options. 

Up next will be careful examination of all the solder joints with my stereo microscope, prior to doing a first power-up and test of the completed project. When this is working, I can revisit the large pile of untested chips I own and validate the condition of many more of them. 

More wrinkles with Arduino and windows serial over USB; making CARDREAD.EXE connect to Arduino

 NEW DISCOVERY ABOUT THE SPURIOUS CHARACTER ISSUE

I was foolishly satisfied that the one millisecond delay I added to my code was going to be a long term workaround for the spurious characters that arrived at startup of the Arduino sketch, in spite of doing this blindly. I had no clear understanding of the cause of the issue and nothing that suggested that a delay was related to the problem. 

I made some unrelated modifications to the sketch in an entirely different area further along in the code, after which the flaw came back. At this point I wanted to know exactly what was being received as that might give me a clue as to the agent which was sending them. 

I set up the sketch to blink out the eight bit character being received, with one clock blink followed by a second blink only when the bit was one, separating the clock-data pair by a longer interval to permit me to see the data unambiguously. 

What I found was two xF0 characters. This reminded me that I was seeing them earlier with the Arduino based 3174 controller board I was experimenting with. Those spurious characters arrived at various times during a sketch, along with an xF8, not just at startup. My workaround at that time was to 'eat' those characters. Only possible if xF0 and xF8 are not valid incoming characters to the Arduino.

NEW WORKAROUND

The protocol between the application and the card reader interface sketch sends only ASCII characters, a small set - C, P, R, S, and X - which means I can safely eat the bad characters even though I still don't know why they arrive on my laptop USB link. With that added, the sketch seems to be solid again.

QUICK RECAP ON ISSUE WITH CARDREAD.EXE

An Arduino puts a bootloader in upper memory along with the compiled user sketch. When the Arduino is reset, it runs the bootloader which listens on the port to see if the IDE is downloading a new sketch. This introduces a delay of almost 2 seconds on startup of the code. 

The reset is triggered by the DTR control line going low, which occurs every time that Windows opens a COM port. This was introduced into the Arduino system to allow sketches to be loaded without the requirement that the user push the reset button on the controller. 

The CARDREAD.EXE program opens the COM port, sends the character R to reset the controller and reads the incoming serial line for a response character. It does this send and receive ten times in quick succession, looking for a valid status character - ASCII between x40 (@) and x7F which includes the capital letters A to Z. 

The problem is that this rapid fire transmission occurs faster than the bootloader will stop, so that the program nevers sees a valid response character and the Arduino never gets through bootloader to run my actual sketch code. 

I don't know why the program doesn't block waiting for the response character. Instead, it seems to look at the incoming port even if there is no data there yet. This is a second sign that the Windows virtual COM port functionality is broken on my laptop. It is also broken on the Windows Surface Pro tablet so it is not just a Windows 10 problem. My guess is this is a compatibility issue mixed with a defect in Windows.

SOLUTION IS TO REMOVE BOOTLOADER FROM ARDUINO

If I load the sketch to the Arduino without the bootloader, it will start up immediately and look at the incoming characters. That should give us the R command and send back the response character @ fast enough so that CARDREAD.EXE is satisfied. At least, that is the plan.

Discovered why CARDREAD.EXE is not communicating with Arduino

 LED ON PIN 13 FLASHES BUT I DON'T USE THAT PORT

I noticed that when I fire up the CARDREAD.EXE program which is unable to communicate, I see the LED light on the Arduino, the one that is controlled by pin 13. I am not making use of that pin and thus nothing should cause it to light, go off, and then flash periodically, but that is what happens.

Using a terminal emulator or the serial monitor does not trigger this behavior, it is unique to the failing connection from the older Windows based application. 

IT APPEARS THAT BOOTLOADER INTERACTION IS BEING TRIGGERED

I did some quick searching online and found that the bootloader on the Arduino manipulates pin 13 in this pattern. On a first connection to upload code, the loader waits for a second (the long LED interval I see), then subsequent fast resets (triggered by DTR sent over the link) are much faster before they decide that code is NOT being uploaded.

This implies that something in the older program and Windows is causing DTR to pulse downward on each open of the port, then the code sends the 10 tries of the R character and gives up apparently before the boot loader has abandoned its control of the link. 

POTENTIAL FIXES

The bootloaders required the reset button to be pressed on an Arduino in the earlier days, but this was 'enhanced' to use DTR as a reset such that the button did not need to be touched anymore. There are ways I can modify or block the bootloader so that the Arduino does not do its reset, allowing me to test this theory. 

There are two separate but related actions taking place, one is desirable but the other causes my problems. The practice of Windows in dropping DTR during the opening of a COM port triggers the auto reset of the Arduino; this is useful and I want to preserve it. When the Arduino resets, the boot loader takes control of the serial link to look for code being uploaded from the IDE, taking a second to wait for code to arrive; this is the behavior that causes me problems.

The Windows code sends a control sequence to the port to set special characters, but they are all zero valued instead of the proper codes for things like XON and end of transmission. It think this is the root cause of my problem, because that sequence seems to cause the Arduino bootloader to wait for code to begin streaming. That wait is long enough that the CARDREAD.EXE program drops the port and starts over.

If I can block the bootloader from taking control, it should all work well. I would still get the reset when the COM port is opened. The only function I would lose is that the normal way of uploaded code to the Arduino would not work. If I have a tenable workaround to upload sketches and a way to block the bootloader otherwise, I can overcome this problem. 

It seems the best method is to upload my sketch without any bootloader. This will cause it to run immediately after it resets and ignore any sequences that would trigger the loader wait. To this end, the IDE allows you to save the compiled sketch, which is stored both with and without the bootloader. 

I then will have to upload it via a programmer. I decided to use another Arduino as the programmer for now, but might look into my programmer devices at the shop and switch over. These all access the ICSP header on the board to update the flash memory with my sketch. 

Dealing with spurious input with first read on Arduino

 RESOLUTION DISCOVERED BY TRIAL AND ERROR

I determined that as short as a one millisecond delay via the delay(1) command will cure the issue I see, where the Serial.available() reports data in the buffer and immediately after the Serial.readBytes pulls spurious content. Not sure if it is just the time spent or it depends on the delay implementation allowing interrupts to occur but this reliably solves the problem. 

Digging into the serial link challenges with my Documation card reader interface

 DEVICE MONITORING STUDIO USED ON WINDOWS TO WATCH THE COM PORT

The Free Device Monitoring Studio installed filters (shims) on the virtual COM ports on my Windows 10 laptop. It can intercept and record all the data and control commands issued to them even when other programs are in control of the port. I made good use of it to watch what was happening on the link.

CARDREAD PROGRAM SENDS BUT DOES NOT RECEIVE DATA

When I fire up Brian Knittel's CARDREAD.EXE program I see it sending the character 'R' repeatedly and I can see the Arduino receive it based on the blinking LED, but I never see any return traffic which means the program never gets its expected response.

I do see his program request both DTR and RTS handshaking, but whether I set up Windows for hardware handshaking or not, the result is the same. No return data. I don't know why yet.

ARDUINO USE OF DTR SIGNAL ADDS TO THE MESS

The Arduino system has overloaded the meaning of DTR, so that when it drops to logical false, the Arduino does a reset. This is useful both for uploading code and to ensure that the code starts fresh when a link is established. Unfortunately, that interacts with the Windows com driver practice of dropping DTR during the open of a COM port, which is how the reset is triggered.

RANDOM DATA SEEMS TO ARRIVE AT ARDUINO RESET

Regardless of the program I use to connect to the Arduino, when it restarts and opens the serial connection, something happens to the input buffer logic. The Serial.available() function sees waiting data, that triggers my code to read a byte and parse it as a command. It is not a valid command thus the code returns the character '?' without the calling computer or application having sent any command characters. 

If the CARDREAD.EXE program was actually receiving the output of my Arduino code, it would have iterated sending the 'R' until it got a good response, overcoming the one time garbled transmission. That is what happens when I use terminal emulation programs such as PUTTY or the Arduino IDE serial monitor. 

TWO PROBLEMS TO OVERCOME

First, I need to get to the bottom of the issue blocking the CARDREAD program from receiving serial traffic. If I get that working properly I can live with the second problem.

Second, I have to figure out why I am getting the garbage results on opening a serial link over USB. This is a problem that has plagued me in prior projects (on this Windows system) so its resolution will have wider benefits that simply cleaning up this reader interface behavior. 

Setting up to investigate the failure to communicate by cardread.exe to interfaces

 SERIAL PROTOCOLS AND CONTROL LINES

Serial communications protocols like RS-232 were developed over time and included a number of signals that are erratically implemented. These include signals with labels such as RTS, DTR, CTS, DSR, RI, RTR and DCD in addition to the TX and RX lines that carry the outbound and inbound data. Even the voltage levels are subject to some variation, with the original standard involving positive and negative voltages of up to 15V but often with computers today TTL levels of 0 and +5V are used. 

The meanings of the signals were originally defined around connections between a modem and a device, the DCE and DTE respectively in the jargon of the standard. Thus, DCD meant that the carrier signal on the phone line was detected and RI meant that a ring was incoming on the line. With fixed wiring between the two sides of a serial link and no modems involved, these have much less meaning.

Flow control can be implemented using the lines, but again the way this occurs varies. One can imagine the use of RTS (Ready to Send) and CTS (Clear to Send) but even that has evolved so that RTS is relabeled RTR (Ready to Receive) and thus each signal indicates that data can be sent on its associated RX or TX line. Other flow control schemes include using characters like XON/XOFF sent inband rather than using the control signals.

Control lines such as DTR and DSR indicate that the two sides of the link are ready. In some implementations, the link won't operate unless it sees these positively asserted. Many other implementations ignore these lines. 

Thus, making a serial link work is more involved than just hooking up TX and RX, then setting the baud rate, bits, parity and stop bit configurations. One has to know whether lines like DTR, DSR, CTS and RTS are required and how they must operate. 

CODE IN THE CARDREAD.EXE APP USES DTR AND RTS

Investigating the source code for the application written by Brian Knittel to control the Documation card reader shows that he opens the serial link at 115200 baud, 8-N-1 settings but also that he is specifying that DTR and RTS are to be used for link enable and flow control. 

The big question to resolve is how this is handled by Windows in its com ports, in the USB driver, and again on the remote end inside the Arduino as it is converted back to RS232 signaling. It is possible that some settings are causing the application to block or to not receive the responses from the interface. 

SERIAL COMMS MONITORING TOOL INSTALLED

In order to see exactly what the application is seeing in its requests to Windows for communication with my interface module, I downloaded a tool that installs a filter in front of each COM port on Windows, allowing it to capture every request and data transfer. 

It will let me see whether the windows to CARDREAD.EXE traffic shows the transmission of the character 'r' to the interface and the receipt of the response '@' which indicates that our interface has successfully reset. That will guide me further in diagnosing the failure to communicate which is blocking my use of the existing application to control my card readers. 

Issue found with my card reader interface; can't get existing program to connect

 CAUSE FOUND FOR LACK OF ERROR STATUS SIGNAL

I used an inspection mirror to look between the shield and the Arduino. Problem found! A pin from the shield was bent out of place and not inserted into the header on the Arduino. It was for pins 35 and 37, which includes the failing ERROR signal. 

A quick bit of bending and the problem was gone. I now get proper status for the machine. 

FAILING TO CONNECT FROM BRIAN KNITTEL'S CARDREAD.EXE

The program shared by Brian Knittel as part of his interface solution to the Documation card readers uses a virtual serial port to speak to the interface. It has been failing to connect to my instances of the board designed by Brian, which was the impetus for me to shift over to the Arduino based design I developed that will provide a more solid base for reading all the punched cards I own.

Sadly, it fails to connect to the Arduino either (or doesn't like something coming back from the Arduino which it interprets as an indication that this is not a valid interface). It fails on my laptop and on my older Surface Pro that I had been using with the readers in past years. 

This could be a problem introduced by Windows maintenance, breaking something for this old code. It could be an issue with my Arduino link also. I chat with my new interface over various terminal programs and everything appears good as far as I can tell.

I will proceed on two fronts simultaneously to overcome this last hurdle. First, I will write a Python program to manage the card reading, bypassing the need for the older program entirely. Second, I will write a program to masquerade as the interface to see what the program attempts, what it sends and how it responds to the intended responses. I will also dig around a bit to see if there are reports of other virtual serial port based programs failing due to windows fixes.