Monday, September 29, 2014

Repaired the delay board and prepared to use it to replace the original time delay relay in the disk drive


I ran out to a local supply shop to pick up the surface mount timer chip then installed it into the delayed on relay board that was broken when I received it. The bad behavior continued. I then traced the circuit to figure out what they were attempting and from that to determine what was wrong.

It appears that the through holes near the potentiometer don't have enough clearance around the internal ground plane, so that some boards are shorting one of those pins, causing the circuit to be reconfigured into the astable (cycling) mode.

I planned a way to wire around it - removing some components and connecting them differently to set up the right circuit wiring. When I wired in the planned component values - 1000uf capacitor and 100K resistor - the timing came in close enough to target that I don't need to tweak the part selection.

Resistor and capacitor wired around the flawed circuit board traces
The target is 90 seconds before the relay turns on, and the board as it sits activates after 100 seconds. That is close and on the safe side (longer means more time for disk platter to adjust to the air temperature inside the drive).

This replaces the original, malfunctioning relay in tight quarters in the AC power box of the disk drive. I attached the relay board to the mounting bracket removed from the relay. It fits in the intended space.

Relay mounting bracket used to hold delay board in place
Before I install this, I need to put together a resistor voltage divider to drop the 48VDC input down to the 12V that the relay board uses, cut the spade lugs off the existing wires and attach them to the terminal blocks on the board. Once that is done, it can be put into place and the drive closed up.

I had to spend most of today preparing for my business trip tomorrow morning, but am pleased that I was able to revive the delay board and establish the behavior required to support the disk drive disk loading sequence. When a cartridge is in place and the switch thrown, the motor begins spinning the cartridge  and energizes our delay circuit. We hold a signal line low until the 100 seconds has expired, then disconnect the line from ground. That signal is normally grounded through the relay and only allowed to pull up high after the delay.

The disk drive electronics won't pick the disk head loading solenoid until this signal goes high, along with other required conditions such as adequate rotational speed. Now that I have a good time delay to raise that signal, it will be fully operable. More importantly, the covers can be put in place and the annoying door closed up.


I spent a good hour with the FE maintenance and theory of operations manuals, plus the illustrated parts catalog, to discover the mechanisms I need to lubricate and check in order to get the print wheels striking the paper with enough force to leave a clean character image. No time to begin the cleaning, but that will be first up when I return from my trip.

Sunday, September 28, 2014

Finishing new keypunch interface unit, progress testing the 1132 and a bit of work on card reader and disk drive


I spent many hours carefully wiring together the interface, using the connectors, checking wiring and soldering, double checking which wire I was holding before putting it on a connector. At this point, the unit is closed up but one task remains before I begin code development and testing. I have to install a power brick inside and a suitable molex power connector, then wire up the corresponding connection inside the keypunch to bring power to everything.

Wiring complete other than power brick
A lot of connections, finally complete
Wires soldered to header pins, inserted in the Arduino
Molex connectors hooked to relay board, barely visible mid-upper right

Unit closed up until I add the power brick and start testing.
I am will be unable to work on the machine from Tuesday through the following Friday due to intensive business commitments, thus will wait to do the exploratory testing and hardware checkout until I am back in the workshop.


My next step to get the cards moving from the cornering station to the stackers is to increase the pressure on the rollers pulling the card into the stacker area. I began to adjust the indicated screws but I need to spend more time to be sure I get this pulling more firmly. I don't want to introduce skew into the card movement, which is possible if the pressure on the two rollers is not the same.


I put in some fresh paper and reloaded the test program. I have an instruction which is supposed to decrement a counter each time I find and print one of my target letters, but the value in that counter, index register two, is not going down. After a look at the program, I realized I was using hollerith code (card reader and keyboard), not 1132 printer codes.

Instead of stopping when I get four matches, I am going to take 48 read emitter interrupts, which is one complete cycle of the print wheels. That should ensure I issue the scan codes to print in all eight of the last columns.

Running with the full 48 character interrupts gave me a satisfying sound of printing, but the page was blank. I probably have a ribbon that is so dried out there is essentially no ink to transfer. I pulled out a spare ribbon, which is about 25 years past its 'use by' date but might just have a bit of ink left. I had to read the manuals to learn how to change the ribbon, but I did get it changed.

It was definitely full of ink - got on the printer cover where I rested the ribbon spool as well as on my fingers! Running the print program again produced very slightly darker letters but only in a few spots. It appears the print hammers are likely partly glued with old lubricants and can't snap crisply into the print wheel.

Ink stains on printer top from the replacement ribbon resting there temporarily
Only some of the hammers can leave an impression, others don't strike with enough force. I also see one case where the letter D printed in the column where I was requesting to print a C. Since that is the next sequential character after the one I requested, it is consistent with a gummed up mechanism latching up too late to match the C.

The next step for this unit is to clean the old lubrication from the hammer and print related moving parts, putting on new oil and making sure it is all moving freely. Once that is done, I can try the print test again and see where I am in the restoration of this device.


I toyed around with the broken delay board from yesterday, finding a way to get it triggering but not correctly. With the original capacitor, it worked on a 10 second delay which is too short for my purposes, thus my second set of tests were with a much larger capacitor to produce a longer time interval.

The first tests, with the 10 second time interval, were supposed to show a turn on delay, meaning the circuit should start with the relay off, wait ten seconds, flip the relay on, and stay in that monostable state while power remains on. Instead, it began latched, then each ten seconds it turned the relay off or on, alternating forever in a bistable mode. It should not be oscillating.

The second tests, with the longer interval, showed even stranger behavior. It would start out active, blip the relay off and on for less than a second, wait the long interval, then repeat the blip. Each interval had a momentary blip and a long wait. Again, not useful for my purposes.

My working assumption is that the LM555 chip (timer) that is the heart of the circuit is malfunctioning, since all the components seem to have proper values and be wired correctly. I desoldered the chip from the board, using my hot air rework gun, and will pick up a surface mount 555 chip to replace it. I am feeling hopeful that with a bit of work I can get this board doing what I want, replacing the original time delay relay in the disk drive startup circuitry.

Saturday, September 27, 2014

Activity, progress, minor complications but nothing completed today


Although I hadn't achieved the printed output I wanted in the first test this morning, I was able to verify that the printer interface works well. I can start and stop print operations, get the interrupts, see correct/rational sense bits, read emitter returns valid characters, and I know it is reading the scan field because of print scan checks if the last bit of the last word is not set.

However, the tests I performed this afternoon didn't come out right either. The scan field is being fetched and there is a definite difference when bits are on - I can hear hammers firing - but I am not seeing all the columns I should and sometimes the characters are not the same. Since I am setting a nonzero pattern into the scan field for just the first read emitter interrupt and then using zeros for the rest, I should have some random character repeated in the pattern I chose.

I used a pattern of AAAA first, in the first 48 columns of the printer, but saw only five or six columns of text printed and these were not all the same character. Another test with a pattern of 5555 to exercise the alternate hammers of the first 48 positions gave similarly incorrect results.

More testing will be required to figure out what is going awry before I can resolve it. Another issue is that I have been reusing the same few pages of paper for multiple tests and see that I do have a line with most of the first sixteen columns displaying the same character ($). Therefore, I might not have the problem I thought, but it will be better if I put fresh paper into the printer and annotate each test to ensure I am not chasing phantom problems. Out of test time for today due to other obligations.


I spent many hours today wiring up the relay boards, read cable connections, building the screw terminal boards to connect to the Arduino and to the relay boards, and ultimately was not happy with the add-on boards that provide screw terminal connections.

Add on boards for Arduino for screw terminal wiring - too cumbersome when installed
I yanked them off and began wiring Molex connectors to hook to the relay boards. I don't yet have a good choice for the wiring on the Arduino, but will be making that decision soon.
Molex connector being created to hook to relay boards
I did most of the mounting work for the Arduino and the DB9 serial input connector, leaving only the 'power brick' to insert and fix down inside the enclosure. Wiring of the connectors to the relay boards for the punch cable is done, but the control signals from the relay board to Arduino are dependent on that connector decision I must make.

Relay boards and connectors installed

Arduino sitting in approximate mounting location

Punch cable connector from keypunch

Reader cable connector from keypunch

Serial link connector to link to PC or other system using the interface
The common power for the punches and space mechanism are partly wired - I have a few more relay poles to add to the chain, but all the activation wiring is just about ready.


The part I ordered to restore the disk drive 90 second timer, which is used to delay loading the heads while the drive stabilizes, arrived but was nonfunctional. About a third of the reviews on mention DOA units, so not a huge surprise I guess. The first problem is an open potentiometer. I scrounged up a pot from my supplies and a larger capacitor, but still get the instant firing. Likely either the NE555 IC is bad or the transistor that drives the relay based on the chip output, but this thing is useless as it sits.

Defective delay timer after replacement of first few bad components
This is strike two on what should be a simple component purchase to replace the time delay relay. The first was a unit that provides a 90 second delay for air condition and other units, but while the promotional material and store entry implied it worked for both DC and AC sources, this thing needs AC to work. It has to go into a 48V DC environment, so scratch solution 1. The broken part I received today is solution 2.

This is annoying to stretch out because I have the door hanging open in front of the disk drive, two switches dangling, and would really like this closed up and completed so I don't keep walking around or bumping into the door whenever I move around the system.

Door I can't close, waiting for time delay relay replacement, always in the way

Friday, September 26, 2014

New keypunch interface construction work and 1132 printer testing


I picked up the enclosure and connectors then launched into soldering up the wiring inside the box, from the DB-25 connectors to the two banks of relays. The punch cable is done - 23 wires involved. I mounted one of the relay modules in preparation for hooking it up.

Punch cable connector wired up and one relay module installed
Tomorrow I will wire the connector for the read cable, mount the second relay bank and then wire all the relays to their appropriate connector pins. The remaining steps of wiring the read wires and a few sensing wires from the other cable to the Arduino will have it prepared for initial testing.


I placed the long program in memory and cabled up the printer to do some quick testing. My first run had some flaw - I could see the printer sending the emitter interrupts telling us a new character was rotating into position on the print wheels, but I wasn't properly checking the value or setting the print scan buffer at x0020-x0027 with the proper end bit.

Printing involves the following. An XIO to the printer starts it printing. In that mode, as the print wheels are spinning, each character that comes in position to print causes an interrupt. My interrupt handler has to sense the device status, verify that it is a emitter interrupt, meaning a new character is ready to print, then set up bits for each column where that particular character should be printed. These bits are set in a fixed area of memory, locations x0020 to x0027, called the scan area. Along with the string of bits matching the 120 columns of the printer, the last bit of the scan area (word x0027) has to be set on.

The printer begins fetching the scan area words and firing print hammers in any column where a 1 bit is found. It checks the last bit of the scan area since that is proof that the software has set up the proper columns. If the bit is off, meaning a new character interrupt came to us but we didn't respond fast enough to set up the scan area, then the printer recognizes a print scan check error.

When our program is sure that there are no more unprinted characters, having already received an emitter interrupt for each character that exists in the print line, then we command the printer to stop print. That simply means it should no longer send emitter interrupts or fetch scan words. At this point we can ask it to space down one line or skip to a channel with a new command for that purpose.

My code verifies it has an emitter interrupt, then checks the character against the specific set we plan to print. If no match, we set the scan area to all zeroes except for the last bit. This says that the character doesn't exist in our print line so don't fire any hammers. If we match, it sets the scan area to a specific pattern for which column will have that character printed, plus the final 1 bit. As well, with a match we decrement the count of characters to print. Once the count goes to zero, we command the printer to stop print.

I looked over my code and found a few mistakes - hand assembling code, keeping track of addresses, calculating relative addresses and watching for proper alignment of long format instructions is a lot of work using paper and pen, thus easy to slip up in longish sequences that must be entered in with the console data switches one word at a time.

It is late and it will take a while to toggle in the code again, since enough of it has shifted or changed to warrant a reload. This will be done tomorrow.


Fortunately, this entry has nothing to do with the 1130 restoration. Yesterday, my wife and I visited the pharmacy to get flu vaccinations. While there, the pharmacist talked us into adding the pneumonia vaccine, getting both injections in the same arm.

By late evening yesterday, my arm was extremely sore, very painful to move or touch. It is common to have some soreness, particularly if the muscle is abused with two separate injections on the same day. In this case, the arm was essentially unusable until the evening today and the pain was enough to keep me from getting any sleep until it began to abate around 6AM, but with work commitments I snatched only a couple of hours sleep.

The amount of work I did on the 1130 before 4PM was zero, but once the arm began to be usable without much pain, I did accomplish a few things as you read above. Moral of the story is that, where feasible, injections should be separated by a week.

Thursday, September 25, 2014

Finished keyboard, wired interface cables to keypunch, and prepared software for 1132 printer restoration work


I had to partially disassemble the bail contacts to rebend the bail and contacts, but eventually I had it working properly. I took the time to burnish the oxide from the 40+ latch contacts on the bottom of the keyboard, to ensure that all contacts will be made properly for any keypress.
Removing black plate to get to keyboard underneath

Bail contacts detached to get to bails thenselves

Bails with removed contacts at right

Closeup of bails which pivots for certain keystems, touching bail contact plate
Reasembled bail portion of permutation assembly on keyboard
After reassembling the keyboard, I installed it into the 1131 but only hand placed the black plate over it - didn't want to tempt fate if I had to go back in yet another time to tweak the contacts. Turns out that was a good idea. The keyboard is correctly encoding all the characters but also spuriously firing up and entering keystrokes. When it fired, I saw only bit 2 turned on.

A bit of deductive reasoning with the schematic of the permutation unit connections told me that it had to be a specific bail whose gap was too narrow and intermittently made connection. Only a few contact pairs emit bit 2, but only one does so only when the keyboard is in alpha mode but not numeric. That is bail 13, which is right next to the one I was bending in the repair. It makes sense that one might have been disturbed a bit.

I was able to check and adjust the bail contacts without removing the keyboard, since they are on the sides. However, the problems continue. It may be that I adjusted the bails with the keyboard on its side, due to cable length restrictions for the wiring coming out of the 1131, but with the sag of gravity I might need to adjust them better.

I spent some time but it was hard to determine where my extraneous triggering is occurring. It does not seem to be the bails, which makes me suspect I might have a more devious connection through latches that are producing the behavior. To resolve that, I do indeed have to unscrew the keyboard from the 1131 and tilt it up once again.
Latches on bottom of permutation unit, under bails
I cleared up the issues with the latches, put it back onto the 1131 and checked that operation was now normal. No spurious clicks and I walked through every key and character to ensure it was encoding the right characters.
Working keyboard back in 1131, ready to be closed up
With the problems all fixed, I declared the keyboard fully restored and complete. I mounted the black plate and closed up the machine.


I decided to try to adjust the connectors I have in hand, using some wire lead cutters to gently bend them to a slightly tighter fit. I get this mostly right, but some become too tight to slide onto the SMS pins. After a half hour of careful work, I had nine of the twelve punch magnet connections affixed properly. For each problem connector, once I rule out issue on the pin itself, I will cut off the old and install a new connector, gently pinching it, and installing on the pin. This took two hours overall to complete.

Having fixed the connectors, I was able to complete the wiring of the punch cable, joining the read cable I previously wired in. The last step was to install a reed switch on the side of the card lever relay, allowing us to sense when the relay is energized. The wiring was tied down neatly and the keypunch tested to verify that its functionality was not impaired through any wiring foulup or incidental damage.

It is now time to begin wiring the relays and Arduino to the corresponding DB25 connectors. I will put this in a hobby box of some type - time to pick up some connectors and miscellaneous supplies.


I retrieved my hand code to test out the 1132 printer, generalized it a bit, and carefully laid it out so it can be entered into memory. When that is done, I will be able to test the printer.

Wednesday, September 24, 2014

Very little time for 1130 today, but got into the shop for a bit

I had a heavy workload from my day job, plus I spent my lunchtime at the Computer History Museum working with others to get the twin 1401 systems back in operation. My team solved a problem with the power supplies but the impact of that failure may have damaged some other circuits - more work to do next week. The other teams worked on the other machine and some other equipment, but by the afternoon when I left, the score was equipment 3, restorers 0.


My connectors arrived to hook wires to the pins on the back of the SMS socket panel and I started to hook the 22 wires into the keypunch tonight after soldering connectors to the cable half. Some of the connectors don't seat sufficiently firmly, something I will have to correct. First I will try to adjust the connectors I have, otherwise I need new connectors to replace the ones I just soldered onto the cable.


I opened up the keyboard area once again and took some extra time burnishing and sanding contacts until I had very reliable connections for all the bails. Right at the end of this process, on bail 15, the screwdriver holding the point against the contact plate slipped while I was burnishing, bending the contact arm. I spent 15 minutes trying to get it back where it would connect reliably when keys were pressed but not otherwise.

It appears I might have done something to stop the bail itself from rotating, perhaps a tab jumped out of a slot, so this could end up as a much more painful repair than just rebending a contact arm. I will wait until I am rested and have good daylight before I tilt at this windmill again.


Tuesday, September 23, 2014

CE Disk Cartridge inspected: not usable - surfaces too damaged


I realized that with the markings that were visible through the cartridge door, it was essential that I open up the cartridge, inspect it and clean it if it can be used in the drive. I unscrewed the bottom plate and opened up the container. Immediately, I could see scoring, scratches that glinted because they were deep enough to expose the aluminum substrate of the platter. Oh dear.

Cartridge open, platter visible for inspection and cleaning
Top cover of the cartridge, with platter removed
Circular scratches fill an area somewhere near where the CE information was recorded, rendering it unusable because any heads flying on this pack would be damaged. I took several pictures looking at the scratches, plus the dark circular area on the other surface which may be rubbing wear but does not show the aluminum at the base. 

Scratched through to the aluminum underneath

Another view of the scatches

Evidence of one scratch beginning, where a particle jammed between head and disk temporarily

other surface, dark rub marks
 In addition to the scratches, there are quite a few spots were some contaminant settled on the platter and affected the material. These may be water spots or other materials, but if they altered the surface it might be uneven enough to cause head-disk interference and a crash. One set seemed to have removed quite a bit of the binder, showing some of the bare metal underneath.

Melting away the binder and magnetic material

Contaminant spot

Spray of drops across left to right, affecting surface

More streaks of contaminant across surface, top to bottom

Keyboard almost fully restored and working, progress on 1053 console printer and 360 channel emulator card


Today I picked up a burnishing tool and used that along with an oxidation remover to get those keyboard restore bail contacts working again. After a bit of work, I was able to get the contacts to make a circuit with between 0 and 4.5 ohms resistance, good enough to work with.

Oxide removing spray and burnishing tool at bottom
Contacts after cleaning and burnishing, much better connection
I reassembled the keyboard and console cover, fired up the system, but discovered that the first 8K of core memory is now hosed up - most bits stuck on regardless of the bit pattern being written. It must be something I disturbed while troubleshooting the contact issue on the keyboard, but right now I can't think of what I might have touched since I last turned off power that could cause these symptoms.

If I can't find something that was disturbed recently, I will have to go back to troubleshooting basics to see what is happening. I carefully checked the connections and closed up the gates, then powered up again. Things were working fine now - not sure what happened but it is working properly at this time. If it misbehaves sometime in the future, I will debug it while it is in that state in order to resolve the root cause.

I entered my keyboard testing code and began checking out the various keys and functions. Int Req does fire up interrupt level 4, as does the press of any key while the keyboard is in the selected state. XIO Read correctly stores the Hollerith code associated with a pressed key. I worked my way through the lower case (alpha) keys, with most of them reading correctly.

The keyboard is a transplant from an 029 keypunch, which is why it encodes Hollerith (punched card coding). The keys have a stem underneath, which have a unique pattern of tabs that pull on certain crossbars, called bails. Any bail that is pulled by a tab will activate a switch contact. The end of the stem also pushes its own contact, called a latch.

Wiring of the bails and latches creates what IBM calls a permutation unit, which is an encoder. When the numeric key is held down, it powers certain latches, others are powered when it is in alpha mode, while another group are powered at all times. This is how a key with two characters, lower and upper, encodes the appropriate bit pattern.

The first failure I encountered was incorrect behavior of the numeric key. It should only be switching power from the alpha group of latches to the numeric group, but not triggering any bit unless a bail is also connected. However, when I hold down the numeric key, it is sending in bit 1 and also triggering a keyboard restore operation, in a machine gun speed series of restores.

Restricted to verifying the lower case (alpha) characters, I continued with the testing. Most keys produced the right Hollerith, but the % and the , keys were both incorrect. They were missing bit 6 in both cases. By carefully studying the permutation unit logic and the results, I determined that bail 5 is not making contact.

Other bails might be unable to make a reliable connection, but they are associated with numeric mode (upper) characters which I couldn't test while the numeric key was malfunctioning. Pretty clear that this is another case of oxide on contacts, thus I took the console part and began to test each set of bail contacts.

Finding a few that were erratic, I decided to use a deoxidizer on all of them, along with my contact burnisher, to ensure they would work reliably. Once the bail contacts were working, I moved on and cleaned up the latch contacts.

Powering up, I did some exhaustive testing of the characters again. The numeric key now works correctly, as do most characters. I am still having some problems with a few bails that drive bits 5 and 6 for some alpha characters, but the keyboard is almost good now. I will get some good very fine sandpaper and really scrape the heck out of the oxide on those contacts.


I strung the nylon tape that activates the ribbon color shift, placing it onto the machine. It hooks to the activation arm inside the carrier, goes around a pulley on the carrier and then to the left of the frame. There it changes direction around a pulley to downward, loops over a pulley on the solenoid arm at the bottom left and return upward to a second pulley on the top left of the frame. From this pulley, it runs direction across to the right top frame, around a pulley and back to carrier, where it hooks over an anchor bolt.

Tape running left from carrier, down to solenoid, up and then to the far right
Tape runs from left side to right side, around pulley and back leftward to the carrier
Tape exiting carrier left side around pulley, crossing in front and then returning to the right side of carrier
I can tell that this tape is too loose, requiring some sort of tension adjustment, but that can wait until I have the selectric able to space, backspace, return and type. I still have the one spring to connect deep inside the recesses of the machine under the cycle clutch and then forward to the cycle clutch latch arm. After this, it is only the stickiness of the old grease and oil that is keeping me from a restored typewriter console printer.

Of course, there are a few contacts on the typewriter, any of which may suffer from the thick oxidation I am seeing on many other contact pairs. I don't want to deal with this yet, but will check it out before I try to print from the 1131 which depends on those contact signals to ensure safe and correct operation of the printer.


I received my latest eBay purchase of an IBM card that implements a 370 channel in a PC, with a set of bus and tag cables that hook to any IBM mainframe peripheral. I already owned the bus and tag cable set with the special connector plug that fits this card. When this card is installed in a MCA (Microchannel) bus slot in a PC and the driver software is loaded, I can make use of 3420 tape drives, 2501 card readers and other peripherals.

IBM 360 Channel Emulation/A card

Monday, September 22, 2014

Busy day, not too much time with 1130, but some diagnostic progress


It was very clear that the keyboard selects and latched down keys are released when the restore button is pushed, but otherwise it is not functioning. The Int Req button should immediately trigger a level 4 interrupt, but nothing is occurring. As well, when I select the keyboard, the Select lamp lights, then push any key, it should interrupt on level 4 and allow an XIO read to grab the character pushed. That does not happen.

Out came the oscilloscope, allowing me to trace the state of various signals until I can sort out where the problem lies. First up, I watched the two latches - interrupt requested via Int Req key, and keypress occurred - but they never responded in any way. Moving backwards through the logic, I found the signal from the Int Req key as it arrives from the keyboard, but that didn't register either. In fact, it seems to have an unusual voltage on the line.

Continuity from keyboard to gate A - good
I moved to the pin where the cable is plugged into the logic compartment, but that showed no sign of life. It was time to check signal continuity on the cable back to the keyboard assembly and if needed, back into the mechanism itself to the switch. Out came the voltmeter for some power-off testing.

Immediately it was obvious that I had good connectivity through to the keyboard and through the key. The last element to check was the +12V that runs through the keyboard contacts and down to the logic.

Connections for Int Req are in that clump of wires at top
Testing connection to the 12V supply into the Int Req switch
Where is the 12V supply to the keyswitches?
Open up everything, get to the keyboard assembly
It comes in to the keyboard, through a contact what is interrupted as the keyboard restore takes place - the bails are pushed back by a bar energized by a solenoid, with a contact switch on that bar. It is the same kind of contact switch as used on the keypunch - and those were so oxidized they wouldn't conduct a current.

Zooming in on all the contacts (bails, latches and connector boards galore)
Keyboard tipped up on its side to see the underside
The contact switch for the keyboard restore bail - our problem
Same situation here - the keyboard restore bail contact switch was oxidized to the point where even with deoxidizer and rubbing of the contacts, it had a resistance of over 30 million ohms in spite of being closed. This will probably require emery sandpaper to cut the oxide down to the conductive metal. I made no progress by the time I had to close down for the evening.

36,130,000 ohms instead of 0

I wrote a nice routine to read a card, store the characters in a buffer and keep count of columns read, errors encountered and so forth. With it, I found I was receiving error checks right away on the card, probably timing issues where the card is not moving fast enough to satisfy the error checking, due to gummed up clutches and excess friction in the mechanism or drag on the cards themselves.

I am deferring work on this while I get the keyboard working. That should be relatively easy and rapid. It will be reassuring to have a complete XIO and interrupt behavior working perfectly, even for the very simple keyboard device, before I am troubleshooting the reader, printer and disk devices. Otherwise there might be a CPU problem that I would assume is an IO device issue, wasting time.


I received the ribbon color shift tape from Lukas Tschudi today, which I began to install on the typewriter mechanism until I ran out of time. I will work on this along with the keyboard when I get back to the system tomorrow.