Validated and corrected interface polarities,

 RESULT OF VALIDATION OF INTERFACE POLARITIES

After I powered up and checked all the polarities, it was clear that all the status signals including Index Marker were inverted polarity. I updated my code to run an interrupt routine on the falling edge of IM and to treat the status bits as inverted. At this point I am ready to begin testing the code. 

WIRING AND CONSTRUCTION OF EXTERNAL INTERFACE BOX PROGRESS

I wired up the external interface to the shield, inserted it on the Arduino and started work on the final mounting and some outside connections/components. Specifically, I need the USB cable to exit the box, two connectors to provide 5VDC, a pushbutton to toggle the End of File (EOF) status, and an LED to display when EOF is active. 

I made use of my nibblers, hole punch and drills to add the components on the top plate, after which I can close up the box and test. Once again, I had to leave the shop early to perform tasks related to my move-in tomorrow. 

Rearranged shop, building new card reader interface

 REARRANGING WORKSHOP

I bought additional folding tables in order to lay out and organize items in my shop - three 6 foot and two 5 foot tables. Once I had them in place I unpacked all my tools and began to arrange them on a couple of the tables. 

ASSEMBLING SHIELDS FOR NEW INTERNAL AND EXTERNAL INTERFACE

I bought two shields to use with the Arduino Mega 2560 controllers for my new design of an interface for the Documation readers. One will fit inside the card cage of my M1000 reader, thus has to minimize height. The other will attach to an existing cable that plugs into the rear of the M600 reader.

I chose a shield that can have the wires soldered on from underneath, between the shield and the Arduino, to allow the stack to slide into the card cage between the existing PCBs in slots 3 and 6. I assembled the headers and pins onto this shield and set it aside to begin wiring once I prove out the interface using the other machine.

I picked up a shield that has screw down wire terminals for all the pins on the Arduino Mega 2560, giving me ultimate convenience in attaching this and modifying it as I test things out. Too, I can reuse this shield in future projects if I wish. I spent a bit of time soldering on the screw terminals and the headers.

DOUBLE CHECKING POLARITY OF KEY SIGNALS

Looking at schematics and other documentation suggests that I have a mix of normal and inverted logic signals on the interface between the reader and my board. Specifically, it appears that only the 12 row data signals, the Index Marker, and the Pick Request signals are positive. The inverted ones include Ready, Busy, Error, Hopper Check, and Motion Check. 

Obviously my code for the controller has to handle these appropriately. In order to verify what is presented, I hooked up the external cable to the M600, set up a VOM, and was ready to begin probing the logic levels with the reader in various states to validate the polarity of each logic signal.

RUSHING AWAY TO DEAL WITH MINOR SNAG IN THE PLANNING FOR MY NEW HOME

I am closing the purchase of a condominium as my permanent home on this Wednesday. I had plans set up for delivery of various items of furniture, televisions, and possessions from both the rented home I am in now and the storage facility that has the remainder of my possessions I brought from California. 

As we talked with the homeowners association, we discovered that they have a quite reasonable requirement that movers provide a certificate of insurance that covers the common parts of the building from any damage that the movers might cause. This includes coverage for workmens compensation in case one of the works is injured during the move, as well as liability for damage to the property. 

My main move of possessions from the U-Haul storage facility into my condo involved using a small business that brought my gear to my workshop successfully. They would haul the four U-Box containers on special trailers to my condo, unpack outside and carry everything up using the building elevator. Unfortunately, this small operation does not have the level of insurance necessary to provide a $1M certificate of insurance. 

I had to arrange for a large scale moving company to unpack the U-Boxes at the U-Haul location, load their truck, make the short drive to my condo, then unpack their truck and bring everything up into my new home. I dashed home to make this happen today. Fortunately I could arrange this on short notice; I chose the company whose vans were outside my building all week removing the seller's possessions, since they clearly had the insurance necessary to satisfy the obligation. While it will cost me a few hundred dollars more, I still move in on the originally planned date and everyone is satisfied. 

Hunting the elusive motherboard for x235 server

 MOTHERBOARD PART NUMBER FOR MY VERSION IS 23K4588

I see other part numbers on eBay but the two that are the same are both in Europe, come with a high shipping cost and too boot are very steeply priced. I turned my hunt elsewhere.

FIRST TRY TO BUY ONE

I found an outfit, Memory4Less.com, that listed one board at a reasonable price. After buying it with Paypal, dealing with them cancelling the first payment over a supposed mismatch of shipping address with the Paypal address, then accepting the identical payment the second time. Sadly, a day later they cancelled due to 'out of stock and no ETA from their distributor'. In other words, selling what they didn't have.

SECOND TIME IS THE CHARM (I HOPE)

I then found a board that showed up on ebay with a local US address, bought it, and hopefully will have an intact planar in just a few days. Meanwhile, I am waiting for parts for my new Documation card reader interface so I am on pause at the workshop. I will go to Disneyworld tomorrow instead. 

Some disquieting signs with the x235 server

 RAN DIAGNOSTICS AND EXAMINED HARDWARE LOGS

First thing I noticed when I powered up was a 'Bad CMOS Battery' error, but I had just replaced the battery with a new one. That may hint at motherboard damage from the fall that is manifesting in failure to deliver the backup battery power to the CMOS memory holding configuration parameters. 

I then accessed the hardware based log that holds messages issued during POST by the BIOS. Most of them are driven by the failed CMOS battery backup problem, but I also have a message 110 listed that is not in any of the IBM manuals I can access. That may be further problems based on the battery issue or may be an important sign of a different issue.

Running diagnostics on the ServerRaid card in slot 4 gave me several errors and it flagged the board as 'Failed' testing. Not sure what this is about but have to look closer. I did verify that all the sectors of my raid set disk are good, which is a relief in itself.

I may buy a replacement motherboard. I see them on eBay ranging for $23 to $150 which is worth a gamble that it resolves issues. I would have to swap the CPUs and DIMMs over but this might be the fast path to resolution. On the other hand, if any of the software is licensed by some value that is specific to each board, then it might not be worth the risk. 

OS/2 is the eComStation version that is sold and maintained by a third party - that was the splash screen I saw when I tried to boot up. If either eComStation or the P390 code is sensitive to serial numbers such as the onboard ethernet MAC address, I would be at an impasse on the board swap idea. 

Building Arduino code as new controller for Documation card readers

CODING AND DESK CHECKING THE ARDUINO SKETCH

I chose to spend the day writing the code for the new interface controller for the card reader. It is compatible with the protocol developed by Brian Knittel but a totally different implementation. It will allow me to make use of two additional interface signals - Motion Check (MOCK) and BUSY - that weren't connected due to limitations of the IO Interface in his design.

The interface has 18 inputs and one output, plus a button and an LED to select and display the End of File (EOF) status. The Documation uses TTL signal levels and presents a 6 us pulse as an index marker (IM) at each of the eighty card columns, after which the interface will guarantee good data to sample for about 345 us. As long as the interface circuit can retrieve the data in that interval and transmit the twelve row bits once every 450 us, it can keep up with the 1000 card per minute reader. 

Using a serial USB link at 115,200 baud and transmitting two bytes with 8-N-1 serial protocol per column, I should be able to send it in 17.3 us. The ATMEL Mega2560 processor is clocked at 16MHz and can easily handle the instructions required drive the reader.

I chose the Mega2560 because it is TTL level compatible and has more than the 21 digital IO pins I need for this project - 18 inputs, one output, a button and an LED - plus it is easily procured and quite inexpensive. I know some techniques to ensure that it responds adequately to the timing requirements, having used this board for other projects of similar complexity in the past.

The ATMEL chip will watch certain I/O pins and trigger interrupts for events occuring on that line. I can hook the IM signal to one of these pins and have it trigger on the rising edge of the pulse. In the interrupt handler routine, I will directly access the ports of the chip to retrieve eight at a time quite rapidly.

I selected pins on the Arduino that are grouped together on eight bit ports that can all be read simultaneously. Using two such groups, in just a few hardware instructions I can extract all 12 row data values and four reader status signals. The routine then saves these in a variable and returns, setting a flag that it has processed an IM. 

The main loop checks for requests from the serial port after it deals with any IM that was processed. If an IM was handled, the loop will transmit the card data as two binary characters and bump the column counter. When the counter has handled the last data column, it sends one ASCII character which is the status byte defined by Brian's protocol.

If a request comes in, it is only for a very limited number of functions and consists of a single character. S requests the status byte be returned. P requests that the reader pick a card, producing the 80 columns of data triggered by the IM pulses and ends with a status byte. C, E and R are various reset functions to cancel picks, turn off the EOF status or reset the controller. Anything else is invalid and receives a '?' back. 

This code is a bit obscure compared to the usual Arduino sketch that uses digitalRead and similar macro commands to do I/O but is much faster. I can do some limited testing before I wire it up to the reader and give it a try. 

Still working to test the interface to the card reader; P390 server partially boots OS/2 and stalls

 TESTING THE INTERNAL INTERFACE BOARD TO THE DOCUMATION M1000

I reinstalled the board where I built Brian Knittels microcontroller based interface, housed inside the card cage of the card reader. The interface connected well with a terminal program and with the cardread.exe program written by Brian. It appeared to show the status correctly - hopper empty and EOF pressed would show up on the PC application as appropriate.

When I tried to read a card, having pushed the EOF button and seen the status reflected properly in the program, the program ignored EOF and left a pick pending after the card was finished. I put in multiple cards but was unable to get it to stop with an EOF and unable to have it save the card contents in the PC file. There is an option to display the last card read but that remained blank.

NEXT STEPS TO UNDERSTAND WHAT IS HAPPENING

It could be that the interface controller board is not reacting properly to the IM pulses nor saving the data - thinking it has asked to read one card and never getting the data back to the cardread.exe program. I am not sure what is occuring on the link. I can use a terminal program like PUTTY to see the status character but it doesn't work well for the binary format data that is sent back for each card column since it interprets them as ASCII characters. 

I will whip up a Python program to connect to the interface and read a card. The interface uses a very simple protocol, sending one ASCII character as a command and receiving an ASCII character with status. When a card is read (response to a P command) there will be 160 bytes of binary information then on ASCII status character. This should be a breeze to examine with my program to see what is transpiring on the link between PC and interface.

It may be that the program is onboard the interface PCB - I can set up the logic analyzer to verify that the various chips are seeing the signals coming from the card reader and where if anywhere things break down. That is another test I can do.

DESIGNING REPLACEMENT INTERFACE USING ARDUINO MEGA2560

In the meantime, I have sketched out a simple implementation with an Arduino Mega2560 that will replace the interface board but conform to the protocol used by Brian's cardread.exe program. I will bang out the code, wire it up as an alternate connection to the reader and test it out at a later date.

FINISHED INSTALLING PCI CARDS AND RAID DISK DRIVES INTO x235 SERVER

After I replaced the CMOS battery and verified that the server gets through all its BIOS initialization without errors, I finished up the installation by putting in the P390 card, RAID card, SCSI card and LAN cards to the slots where I found them. I then slid all six disk drives into the front bays.

RUNNING DIAGNOSTICS ON SERVER

I fired up the diagnostics that are built into the server, exercising everything except communications. All looked great. I won't know about the PCI boards until later but the core of the server seems undamaged. I believe there are good diagnostics for the P390 board that I can run from OS/2 once I have the server OS fully operational.

ATTEMPTING TO BOOT OS/2 BUT HANGS PARTWAY

When I let it boot, it found a hidden OS/2 partition for reinstallation, a production OS/2 partition and one called New OS/2. I tried to boot the 'production' one but it stopped on a splash screen for some communications program and never proceeded. 

I tried rebooting and hitting the F2 key to drop OS/2 into command line, but it froze on the same splash screen before I saw a command prompt. 

Some possibilities:

1. The "new OS/2" is the correct partition to boot
2. Some configurations were lost due to the CMOS battery dying and need to be recreated
3. Something is broken in one of the PCI cards being accessed by OS/2 at boot time
4. Some other damage was done not otherwise specified

I am woefully ignorant of OS/2 but I will need to collect some documentation and figure out how to debug the bootup (unless the New OS/2 partition magically works). That will be my homework for now.

M1000 appears to be working correctly now; x235 P390 server assembled and looking good so far

 VERIFIED STOB SIGNAL WORKING

I set up the oscilloscope to capture ST0B, a phase B signal gated by the sync logic that matches the cards movement through the reader. Indeed, as I had listed as one of the reasons it wasn't in the analyzer capture, it occurs once before the card edge reaches the phototransistors to signal OneDark. It was there on the scope!

VERIFIED IM SIGNALS PRESENTED TO EXTERNAL INTERFACE

The scope was hooked to the IM line on the external interface and showed me the clean pulses that signify that data is latched into the 12 row lines and ready to be sampled. Another great sign!

BUSY AND STOP STATUS, COLUMN 81 AND COLUMN 84 VERIFIED

I triggered the logic analyzer on the occurrence of the 81 CR signal that means we have completed reading the 80 columns of the card and have now moved to the next column position where no holes should exist. Later the counter gets to 84, which is the point when the trailing edge of the card should have moved past the LEDs and all 12 rows should be illuminated. Those signals were there and the error checking successfully varified that no light was seen at 81CR and that no dark was present at 84CR time.

The reader then turned off the BUSY signal since the card had finished passing through the system. Error logic then looks at the state of the microswitch on the input hopper to see if there are more cards to read or the hopper is empty. Since I was reading a single card, the hopper was indeed empty and the error logic raised the condition HOCK for hopper empty check. That turned off the blower motor and switched on the STOP status exactly as it should have.

At this point, it appears the M1000 reader is working properly. I have to get my interface hooked and up and see if it extracts the proper data from some cards. I will leave that for another day. What I can do is see if the external interface is properly reporting card column data. I hooked up the logic analyzer to rows 12, 11, 0, 1, 2, 4, 5, 6, 7, 8, and 9, also watching CSDS whose edge clears the register to enable it to latch in the next card column.

The run worked perfectly. I saw exactly the correct contents matching the physical card I had read. Astute readers will notice that I didn't capture row 3 - purely a result of the limited number of grabbers I had on hand, which allowed me to only capture 12 signals and one had to be a trigger such as CSDS to be sure I was starting the analyzer capture at the correct time.

It is my working assumption that the M1000 card reader is working perfectly now. I only need to re-insert my internal interface board inside and test to determine whether the link to the PC works properly and I can now read and archive cards successfully. That will take place on the next session in the workshop.

ASSEMBLY OF x235 SERVER FOR P390 CONTINUES

I put everything together except for most of the PCI cards which I am leaving out since several of them are essentially unobtanium and can't be jeopardized if the server has issues. 

x235 server begins testing

I was able to bring up the server but received two error notifications. First, the CMOS battery is bad, something that is certain to be true given the age of the system. Second, the fan light is lit on an internal error status panel. 

Dead CMOS battery

An issue with one or more fans

I have ordered a replacement CR2032 battery and will have it in time for my next shop session. Tomorrow we are driving over to Orlando to pick up our new Florida Resident Annual Passes to Disneyworld with lunch in EPCOT for a short day before we return home. Saturday we are driving to meet relatives in Mt Dora and Sunday we are visiting my real estate agents since one of them is still recovering from a breakthrough COVID 19 instance of Pneumonia that had him in the hospital for 30 days and still recovering, requiring supplemental oxygen while at home. Monday should be clear for some time.

The FAN LED should be matched to a fan with a glowing LED but none of the six fans are showing a light. It appears that the bottom fan which cools the disk drive cage is not spinning, in spite of the lack of an error light. This can be caused by an incorrectly mated connector behind the fan, or the power cable poorly mated to the planar (motherboard), or some other issue.

I removed the bottom fan and found that the power connector was out of position and not mating with the fan. It took only a moment to insert it properly, after which powering up the server gave no FAN error LED. One problem down and with the CMOS battery replaced in the next session I should be able to slowly add in the PCI cards and eventually try to boot OS/2 and then run the P390 system.

Resumed testing of M1000 card reader, reassembly of P390's x235 server

 QUICK ADJUSTMENT OF MAGNETIC PICKUP POSITION USING CARD

Since a punched card is approximately .007", the specified distance from the pole of the magnetic pickup to the highest point of the teeth on the timing wheel, I used a card to set the pickup position. With that done, I powered up the reader and testbed to verify that the pulses are arriving properly. I made use of my card extender to easily get to the comparator output on the clock card that emits the timing pulses.

Pulses produced by magnetic pickup through comparator

The pulses look great. Nice and regular, cleanly shaped, definitely good for driving the card reader sync logic. That shows it is time to fire up the logic analyzer and record a card going through the machine. 

LOGIC ANALYZER TRACE OF THE BACKPLANE SIGNALS DURING A READ

The analyzer was set to trigger on the appearance of OneDark, representing the moment that the card edge first occludes any of the LEDs shining into phototransistors for the 12 card rows. I triggered a card and saw that we had a good capture. Further, the machine went into Stop mode and shut down the vacuum/blower motor, which it should do when an error condition arises. In this case the error condition is Hopper Empty Check, which is in fact the expected result since there was only one card in the hopper. 

I went through the trace and found most signals appearing exactly as I would expect. The only one that wasn't in my trace was STOB, but there could be one of three causes. It may not appear in the interval from OneDark through the end of the analyzer buffer, it might be an actual defect in generation of the signal, or it might be yet another bad wire between the backplane and the analyzer. 

I did see the logic signals that cause IM to be emitted on the external interface, but didn't put a scope on the actual IM wire to verify it is present. The buffer is too shallow to hold the full set of clock cycles from OneDark to the completion of reading a card. The duration of a read at full speed is about 60 milliseconds, so perhaps 45 ms is the required capture. With the clock operating at 480KHz, that would require a buffer depth of more than 20K or almost 8 times the capacity of my analyzer. 

The solution to checking the signals at the 80th column through the end of the pick cycle is to trigger on the signal 80CR, so that doesn't really pose an issue. When I next go to the workshop I will watch IM on the external interface as well as doing a column 80 capture. Another capture I will set up for is watching some of the row data signals on the interface to see that they make sense. 

CONTINUING ASSEMBLY OF THE x235 SERVER FOR THE P390

I was able to force the rod through the blue plastic holders to get the PCI card area in shape. It took quite a bit of persuading but I was triumphant.

Plastic card holders in position and ready to hold cards

I then began reattaching and reinstalling various parts of the machine. I have to be careful to ensure that all the proper cables are in their respective connectors and not misplaced, but the mechanical parts are pretty obvious

Slowly putting the server back together

Magnetic pickup cable repaired and connected, beginning reassembly of x235 server for P390 system

 FINISHED CABLE SWAP FOR MAGNETIC PICKUP USING NEW PIN

The replacement pin for the Amphenol connector arrived yesterday. These cost almost $3 per pin, an indication that they are fairly uncommon now. I prepared the shielding, crimped the pin onto the end and inserted it into the connector.

New cable inserted in connector for Clock card

The connector was then reinstalled in the card cage and aligned for easy insertion of the clock card PCB that fits in slot 1. All that remains is to adjust the magnetic pickup for its target spacing from the teeth on the timing wheel. It needs to be .007" within a tolerance of plus or minus .001 inch. 

I ordered feeler gauges but as I drove home from the workshop I remembered that an IBM punched card is exactly the right thickness - .007" - and therefore I can do an initial setup even before the gauges arrive. 

WRESTLING STRAIGHTENED PCI SLOT METALWORK INTO P390 CHASSIS

I used screws and nuts through some of the rivet holes in order to anchor the rear of the server together now that I had restored it to nearly its original shape. I feel good about the result - it will definitely support the PCI cards properly. 

PCI card holder to fan holder connection

Right side of chassis to PCI card holder

Fan holder to side plate fasteners

BEGAN REASSEMBLY OF THE ESERVER X SERIES 235 OF THE P390

I am working in reverse order from the way I disassembled the server to remove and repair the bent sheet metal. First step was to install the motherboard in place. That fit nicely with all the I/O connectors in the proper position at the rear.

Motherboard (planar) back in the chassis

Next step was to add the conductive metal shield and the card holder plastic pieces. These rotate down and lock over the end of the PCI cards to keep them anchored in place. A long rod is pushed through the four plastic card holders and threaded through holes in the metal section I repaired. 

Here is where I am facing the first consequence of all the bending and distorting that the part went through. Three of the four plastic card holders fit right into place and can be secured by the rod, but the last one, which is the first and most critical, doesn't fit in its area well. It is very difficult to get the rod to pass through the holder and into the hole in the metal plate. I will have to continue to finesse this on the next visit. 

Plastic holder cocked sideways, rod not fitting into metal support

Joined local Makerspace and used it to straighten out the P390 bent sheetmetal

 MELBOURNE MAKERSPACE

A Makerspace is a club whose members have access to a pool of tools that are too expensive or large for most to have personally. It also supports interaction among the members as they work on projects. I had belonged to one in Silicon Valley back when I was building my 1130 replica, thus I was aware of the value of such a resource. 

When I moved here I had sold all my woodworking and larger tools, concentrating on the vintage computer and space restoration type of projects and electronics design/construction. Some tasks that would have been a breeze to handle back in my garage in California are impossible with the tools I brought with me. 

Fortunately, the Makerspace here has a full woodworking shop, metal mills and lathes, laser cutters, kilns and lots of other tools. The membership is small enough relative to the club that there is rarely a delay getting access to a particular tool. 

The Silicon Valley club required reservations for machines, some of which had long lead times and limited availability. It was also 2.5 times more expensive for membership and required purchase of pricy classes to be authorized to use each major bit of machinery so the costs quickly ratcheted up every month. 

Here in Melbourne I can ask for help or training but it is not required. It is about a 10-15 minute drive from my shop, thus fairly convenient for when I need to do something beyond my own shop's capabilities.

EASY TO STRAIGHTEN THE PC CARD BRACKET

The twisted up bracket that holds the ends of the PCI plug in cards was such a challenge in my shop. I didn't have a heavy duty vise to hold one end while I applied force to bend it back, thus I wasn't making much progress. I began to look for used servers whose chassis I could outfit with the parts from my machine. That would have cost a bit particularly in shipping as the only two I found were in California and Australia. 

I drove over to the Makerspace at midday. I was the only one inside, turned on the lights and went over to the vise and hand tools. It didn't take too long to force the bracket into nearly orthogonal shape, certainly close enough to support the PCI card ends while in the server. 

I then closed up and drove back to my shop to fit it into the server chassis. I have a few tiny tweaks to accomplish but it is almost there already as you can see from the picture in this post. I will use bolt and nuts in place of the pop rivets I removed; I used to have a riveting kit but that went away before the move. 

Loose fit to demonstrate how much it has improved

SHOPPING AND ORGANIZING FOR NEW HOME

My wife and I have been shopping for the remaining pieces of furniture that we know we will need for the new condo as well as decorations and supplies. The living room of the house we are renting has a dresser and two chairs, while one bedroom is filled with carpets, bedding, large screen televisions and other items. 

The organizing surrounds how to get four U-box pods brought from the U-haul storage facility in Melbourne to our condo, unpacked and everything hauled upstairs. Too, we have to organize moving all the gear we are stacking in the rental house and the boxes and suitcases we brought here. Finally, we have a bit piece of furniture that has to be moved from the antiques store in Melbourne to our place.

Then there are the deliveries. Two California King mattress sets, a bed frame, seven tables of various sizes, and a very large TV all will be delivered to our doorway or into the condo. It is keeping me busy, which is a good thing because time seems to have slowed to a crawl as we wait for the closings and access, finally, to our new place. 

Built the extender board, spliced the replacement cable for magnetic pickup

CONSTRUCTED THE EXTENDER BOARD

I dug out some hardware, drilled holes and anchored the wire wrap style connectors onto the end of the extender PCB. The mounting aligned the wirewrap tails of one side up against the PCB traces, so I soldered that side down. The other side needed jumper wires from the tails to the PCB holes further down the board.

Mounting brackets and direct solder of one side to wire wrap tails

The design of the extender PCB didn't directly connect the contacts on the card cage side with the contacts on the new connector that will hold the extended reader PCB. There are pairs of holes for each signal, thus the signal can be passed between the holes, blocked, or a new signal substituted, depending on the debugging requirement at the time. While it is a flexible approach, I didn't need that functionality.

It did leave me with the requirement to bridge the pairs of holes even for the side of the connector that I had soldered right to the PCB traces, because the traces were interrupted at the hole pairs. I put in small yellow jumpers which established an end to end connection for all signals on that side of the extender board.

Yellow jumpers for other side's direct soldered pins

 

The other side needed jumper wires soldered to each of the connector wire wrap tails and the other end soldered into the hole in a pair that was connected to the other side, the card cage end. I used blue wires for this purpose. With those wires all in place, the extender was put into the cage and is ready to accept the Clock card for when I restart my debugging.

Wire wrap tails jumpered to far side holes

SPLICED NEW CABLE ONTO THE MAGNETIC PICKUP

I put the new cable onto the short ends of the existing cable coming out of the magnetic pickup. I wrapped as much shielding around it as I could and then taped it up securely before loosely fitting the pickup into its bracket under the machine near the many-toothed timing wheel. 

Black wrapped replacement cable to pickup

The other end had its two signal leads already soldered to the leaf contacts that fit into the Amphenol connector. The shield should be attached to a third leaf contact but it had broken during the repair operation previously. I put the two signal contacts into the connector but have to wait for a new contact before I can finish the insertion. 

Black and white wire contacts inserted already

I did verify good connectivity of the magnetic pickup and its approximately 630 ohm DC resistance, same as the working pickup on the M600 reader nearby. When the cable shield is soldered to a contact and inserted, the pickup itself must be positioned to .007" distance from the timing wheel teeth before I can turn on the reader. 

ORDERED REPLACEMENT CONTACT FOR PICKUP CABLE

After twenty minutes of internet detective work, I found the proper contact part at Digikey and ordered it. I should have it by midweek and wrap up the pickup repair. 

WORKING OUT WIRING FOR SECOND EXTENDER BOARD AS ANALYZER CONNECTION

I received two boards from Datamuseum, one of which was outfitted with the connectors for use as an extender. The other will serve as an easier method of connecting a logic analyzer to the motherboard (backplane) signals. The card cage has a connector in place at row 4 but no card sits there. I can plug this special extender card into that slot and it can give me access to all the backplane signals. 

If the holes in the PCB were the right size for standard 2.54mm (.1") header pins, I could have used female-female jumpers to connect those pins to the logic analyzer cables. Instead, the holes are much larger diameter so I have to sort out the easiest way to reliably make connections between my logic analyzer cables and the board. The solution is yet to be determined. 

Miscellaneous work mostly for the Documation card reader tasks

 PREPARING NEW CABLE TO SPLICE ON THE MAGNETIC PICKUP

I chose a microphone cable with XLR connectors as the source for my replacement cable. It has two leads and a ground shield and is a suitable impedance. I began to strip and organize the wires to join together and insulate. One end needs Amphenol connector pins to insert into the female connector in the card cage. 

I removed the three connectors from the old cable and carefully soldered the new cable wires onto the pins. Unfortunately, the pin with the shield attached broke off as I was attempting to insert it into the connector. I will have to find another pin and try again later. 

CONSTRUCTING THE ALUMINUM ENCLOSURE FOR THE EXTERNAL INTERFACE

The project box also arrived and I began moving the external interface for the M600 reader into it. I punched holes to allow the cables to enter from the connector that screws into the back of the card reader. 

Next I have to mount the pushbutton and LED for the End of File state, set up the USB socket and a power connector, then mount the PCB inside securely. 

BUILDING MORE READER INTERFACES SINCE I HAVE PCBS AND COMPONENTS

I began to use the PCB blanks and my stock of the microcontroller, IO interface chip and other components to assemble more interfaces. I don't have a specific need for them right now but they may be useful to someone else with a Documation card reader and it is an easy task to complete. 

SORTING AND ORGANIZING THE WORKSHOP

Every day I try to spend between half an hour and a full hour sorting and organizing the items in the workshop. I began with integrated circuits and then resistors. I have quite a few cabinets with small drawers that already housed quite a few ICs and resistors.

My Tauntek IC Tester is useful to verify the working status of many of the chips. Unfortunately, only a subset of the chips have existing drawers in the cabinets and only a subset are supported by the tester. Worse, the subsets are not identical. Still, I have able to build a pile of tested and working chips that can be put in new storage bins as I build them. The larger pile still exists of chips that are not in the tester nor in my drawers - more modern devices, memory, and so forth - that I will need to organize somehow.

Resistors were more straightforward to handle. Many of the values exist in the cabinet drawers and I could add to them readily. Some odd values are in a miscellaneous resistor case, thus everything is handled. I expect to do similar things with all my capacitors, but I don't have any existing cabinets or storage. Same for diodes, transistors and other component categories. 

BUILDING THE CARD EXTENDER FOR THE DOCUMATION READERS

The two PCBs from Poul-Henning at the Datamuseum arrived yesterday and today I began to prepare them for use. One of them will have female connectors added so that Documation PCBs can be plugged into the extender and the combination plugged into the reader card cage. The other will have pins set up for the logic analyzer so that it can be plugged into card slot 4, unpopulated on my two readers, to give easy access to the motherboard signals. 

My female connectors are designed to install into a chassis and have wirewrap tails for the signals. This does not directly interface with the extender cards, but I can use L brackets to bolt the connectors to the end of the extender and then use wires to connect the signals to the wirewrap tails. I drilled the holes for the L brackets but am waiting for that hardware to continue. 

Working on the chassis of the x235 server that houses the P390, plus extender cards are nearby

 USPS RAISES PERISCOPE, EXITS STEALTH MODE WITH EXTENDER BOARD PACKAGE

Out of the blue, I received an email this morning that the extender boards were out for delivery today. It had been a week since they were briefly spotted in Chicago and then activated the postal cloaking device. I expect to visit the workshop Thursday, as I have an old childhood friend visiting tomorrow, but on that day I can solder on the connector and extend a working board! 

As an update, USPS didn't leave the extender boards because I wasn't home to sign for it. I scheduled it for pickup tomorrow at the local post office. 

ORDERED AN ALUMINUM BOX FOR THE CARD READER INTERFACE EXTERNAL UNIT

In case the board is picking up noise from motors and solenoids of the card reader, I plan to rebuild it inside an aluminum project box that I ordered for delivery tomorrow. That should eliminate this possible cause of the flaky synchronization issues I am having. 

STRAIGHTENING ALUMINUM CHASSIS OF P390 SERVER

I had to disassemble the chassis, removing the back section with the PCI card support slots since it was so twisted up. This allowed me to bend the remainder of the chassis into good shape. I further have to remove the pop rivets to take the card support section off the rail so that I can get to all sides to attempt to bend it into suitable shape. 

Rest of chassis now in decent shape

Problem section on right

Needs major reshaping

XXXXXXXXXXXXXXXXXXXXXXX

xxxx

Began work on bent up P390 server chassis

 CABLE ON ORDER TO REPAIR M1000 CARD READER MAGNETIC PICKUP

I won't have the cable to splice onto the pickup until tomorrow, which blocked me from working on the Model 1000 card reader. Further, I have to noodle a bit about the best way to proceed on the interface issues that appear to be induced noise or other challenges from operating close to the server. 

DISASSEMBLED IBM x235 SERVER FROM MY P390 SYSTEM TO STRAIGHTEN CHASSIS

The chassis of the xServer 235 which is the base for my P390 became seriously twisted after it fell over while fully populated, back in California as I was attempting to securely package it for transit. I did fire up the server itself to confirm that the motherboard (planar in IBM-speak) or other components weren't cracked. 

I didn't have the P390 card or other PCI based cards installed because frankly the chassis is so bent that they sit at an uncomfortable angle away from vertical putting stress on the PCI sockets and motherboard (and the cards themselves). I decided to attempt to straighten the chassis at least well enough that the PCI cards can sit safely upright and be supported. 

I believe the reason that the motherboard survived is IBM's design for the server. They mounted the planar on a metal base which is in turn mounted into the chassis. The metal base is so sturdy that it didn't receive any twisting force while the chassis deformed around it. The remaining area of concern on the planar are the PCI sockets and connectivity to the motherboard, but I do see motherboards available on eBay if this one is damaged. 

I did some initial straightening but still have quite a twist in the PCI card area. I will either need to bend this all better, which is difficult because of its interlocking construction, or find a replacement chassis somewhere. 

Planar on its metal base

Bent chassis at top

Badly deformed area for PCI cards

Wire close to pickup has connectivity, just need to splice new cable I hope; erratic behavior of card reader interface

 ATTEMPTING TO RESCUE THE MAGNETIC PICKUP

I figured out how to release the three pins from the PCB connector, releasing the cable from the magnetic pickup. It has two wires plus an outer shield. As before the ends of the wires measured as an open circuit.

The pickup is mounted in a holder with an allen head setscrew to lock it in position. It has to be adjusted to sit .007" from the ends of the teeth on the timing wheel. I released the setscrew and withdrew the pickup from the holder.

No amount of wiggling of the wires restored connectivity. At this point, I would either have a break somewhere down the several inches of cable or inside the pickup itself. I decided to remove the majority of the cable and get access to the wires just as they left the molded plastic of the pickup.

I was very pleased to find that after stripping insulation off of the 1/4" of wire remaining, there was a resistance of approximately 635 ohms across the two wires and it seemed solid as I moved the wires around. 

I am hopeful that if I splice on some replacement cable, I will have a functional pickup again. Time to look for a cable with suitable impedance characteristics. 

TESTING THE CARD READER INTERFACE WITH THE WORKING M600 READER

Since my Model 600 reader was working perfectly the last time I used it, but the very ad hoc interface was giving me issues, I decided to create a new version of the external box. The board I had soldered up for that was not communicating properly with the laptop, garbling characters. I thought that I had a board that communicated well already inside the M1000. It was simple to unplug that from the new reader and stick it into the external box I had recently built.

Indeed, the board talked well with my laptop, tested first with a terminal emulator program (PUTTY) and then with the cardread.exe program that Brian Knittel wrote. I connected the cable and did some testing with the M600 card reader. Alas, the interface would get hung up after reading a card. In fact, the data it stored had the actual holes on the card but many spurious holes as well. 

It would then hang with what the microcontroller thought was an active pick command but the card reader itself disagreed. If I reset the reader or power cycled it, the microcontroller would report an unexpected pick response. 

I also did a pick using PUTTY, which gave me the 160 bytes of data and a final status character. Something is not right here and I am suspecting, since the pick error character is similar to how the M1000 presented back when I tried to drive it with the controller, that the interface is being corrupted by spikes or induced voltages as the card reader operates. This would explain why it starts out working perfectly with the reader until we fire up the motor and read a card. 

More furniture purchases but did find sources for magnetic pickup if necessary

 DAY SPENT VISITING STORES AND MAKING PURCHASES

Today we took care of the balcony furniture groupings and did some preliminary shopping for the one remaining bedroom dresser we will need. All this after I tested the two large televisions bought for the guest bedrooms since they had a 15 day return policy but our closing is more than three weeks away. In the middle of the day we met friends for a nice lunch.

EXTENDER BOARD REMAINS IN USPS VERSION OF BERMUDA TRIANGLE

My extender boards made it from Denmark to the US but have vanished from existence on August 30th. No idea where they are or when I will receive them.

FOUND SOURCES FOR MAGNETIC PICKUP

With an open circuit across the two wires to my magnetic pickup in the M1000 Card Reader, a solution depends on exactly where the fault is. If the inside of the pickup is broken and not accessible for a repair, I would have to replace it with a compatible part or a reengineered alternative solution. 

I was worried that such a part was specialized to Documation and no longer available. Doing some research, however, I found that companies are building new pickups of very similar design and specs. The prices I found ranged from a low of $50 to hundreds of dollars;  the actual cost would depend on which pickups have a small enough pole piece to reliably detect the fine pitched teeth on the timing wheel. Still, I can take the worst case scenario off the table - I will not have to scrap the machine as unrepairable. 

Tracked down issue with stalled M1000 card reader - no connectivity to magnetic pickup for toothed wheel

 ABNORMAL TRACE RESULTS SUGGESTED ISSUE IN SYNC CONTROL LOGIC

The expected sequence of events is that when the card first moves into the photocell region, triggering OneDark, a set of timing happens to sync the remainder of the card with the positions in the middle of each of the eighty data columns. The pick is declared successful with Good Pick Reset then a counter is loaded with a preset count of the time it should take for the card edge to move past the cells and have them over the middle of column 0. The clock counts down until it reaches zero, turning on signal ZERO.

In the interim from when the OneDark first occurs until ZERO is turned on, the timing wheel will be passing its teeth in front of a magnetic pickup. The first such pulse from a tooth passage will start a counter OSCLK that runs until the ZERO activates. This is a calculated offset from a tooth.

Every other tooth passing afterwards causes OSUCLK to count up until its value matches the offset. This will tell the machine that we are directly over the middle of a column, activating CSDS signal. 

In the machine currently, we see the present counter counting down and reaching zero, but OSCLK never counts nor do we get OSUCLK or any CSDS signals to tell us we are at column middles. Thus, the sync control logic is not working properly.

ITERATING THROUGH THE FLIPFLOPS AND LOGIC GATES

Sync control makes use of twelve flipflops to sequence through the states from the initial OneDark until we generate each CSDS signal for column positions 0 through 84. There are combinatorial gates to control when these flipflops are set, cleared or switched. All of these are sitting on the Clock card, inside the card cage and thus very hard to access.

I tacked wires onto three or four pins at a time, looking to see whether the gates are behaving as expected or not. For example, the gate that emits the OSCLK counting clock has three inputs, one being the 120KHz clock C1 and the other two gating its passage to the output to become OSCLK. One of the other inputs is the same signal that successfully gated the 120KHz clock to count down the preset amount, but was verified. The final input is from the logic that senses occurences of the teeth passing the magnetic pickup. That one was never activated.

I began to back up through the flipflops looking for which was blocking the deliver of the tooth signal (called TST2 at this point). It took some time to sample 3-4 pins and move along the chain. Eventually I decided to check the output of the op amp that produces the pulses from the magnetic pickup connections. 

I didn't see pulses coming from the op amp. I checked the inputs and didn't see any pulses arriving! That would explain the symptoms that have developed in the last couple of days. Prior to that, I was seeing the pulses and the OSCLK and OSUCLK clock signals. 

I pulled the card and measured the resistance of magnetic pickup across the two wires on the connector. Infinite ohms, an open circuit! By comparison, my good M600 reader measures a bit over 100 ohms at the same connector points. 

THREE SCENARIOS TO CONSIDER HERE

The first scenario is that the wire itself has broken inside the cable, much as the 5V power wire to the card cage broken off on its own. This would be resolvable by replacement of the cable with a compatible one. It consists of two conductors with a ground shield around them. 

The second scenario is that the magnetic pickup itself has suffered a broken wire inside the component but it can be accessed and repaired. This would require removal and reinstallation of the pickup, which forces some adjustments and tests before it can be assumed to work properly.

The third scenario is that the pickup is broken inside but can't be repaired. I would need to source a compatible replacement, but with no information about the part, its maker and its specs, that is very unlikely. A possible alternative is to install a new technology alternative to detect the position of the wheel and make that new circuitry produce the pulses in lieu of the old op amp and pickup. 

Day spent buying furnishings and televisions for new home

 Various bits of furniture, a mattress, bedding, televisions for two bedrooms, two area rugs, and other smaller items were on the agenda for the day, which kept me out of the shop entirely. Hoping to have a productive day tomorrow (Friday September 3). 

Resolved OneDark signal issues, moving forward with diagnosis of M1000 card reader

 REPLACED INVERTER CHIP TO RESOLVE THE INVALID VOLTAGE LEVEL

I unsoldered some chips that are tied to the OneDark signal, which had been floating at an invalid 1.65V level erratically. With replacements installed, the signal is now behaving properly. That was a vexing issue as the problem would sometimes disappear only to show up randomly at a later point.

Desoldering chips with the Hakko

I set up two VOMs to monitor the input and output pin of the driving inverter and had really great voltage levels. Using a zip tie to obscure light in the photocell channel made the two signals reverse voltages, exactly as they should.

Left is the wired-OR, right is the OneDark output

Blocking some photocells to trigger OneDark signal

VERIFIED THAT ST0B SIGNAL ISSUE IS FIXED

Having replaced a NAND gate that was driving the wrong output signal based on its input signal values, I suspected that the ST0B signal would now sit properly at logic high when not active and pulse on when gated. I was able to verify this with the scope today.

ST0B signal produced

EXTENDER CARDS DISAPPEARED INTO THE USPS BLACK HOLE

I sure could use the extender cards coming from Datamuseum in Denmark, as there are so many issues that require probing of the components on PCBs while they are stacked in the card cage. I have had to tack on wires, reinsert, test the levels and repeat as I chase down faults. If the card were extended I could just touch probes or attach leads. 

Tacking wires to monitor signals on pins

The boards arrived into the USPS international shipping center in Chicago on the 30th, with no trace of them seen since. It is possible they are moving silently through the system and will show up at my doorstep, but more likely they are heaped in a pile in the center waiting for someone to direct them onward. 

CIRCLING AROUND IN THE SYNC CONTROL LOGIC TO FIND NEXT FAILED PART

Currently when I try to read a card, it reaches the point where it should start processing card column positions. It does this by counting down from a preset value that reflects the time the card will travel from first obscuring the photocells until it is centered in the holes that would be punched if there was a column 0. That is, the position that is one column width to the left of the first data column. This should be recognized by the signal 0CR and a check made that no light is detected on any of the twelve row photocells. 

The preset countdown clock is working well in the logic analyzer trace, the zero detector asserts the logic condition ZERO, and I see the first tooth of the wheel producing a pulse. However, it stalls at this point.

What should occur is that a new clock, OSCLK, should begin counting from the OneDark first turning on up until the ZERO occurs. This sets up the offset count. Then, the next time a tooth is detected a third clock, OSUCLK, will count up with a comparator triggering once the new count matches the saved offset count from OSCLK. None of that is happening.

Without the OSUCLK logic, it will never trigger the signal CSDS that says we are at a sampling point for a card column, thus never latch the photocell data, never emit an Index Marker pulse, and never increment the column count. The entire card cycle ends when the column count reaches 84 (signal 84CR is produced), but that doesn't happen so we are hung. 

Tomorrow I will move around tacking a small number of wires on likely gates until I find the one(s) that are malfunctioning. Could be a tedious time.