Continued checkout of the keyboard device controller logic - issues and progress

EXHAUSTIVE TEST OF EVERY KEY VALUE

I had a short program entered that issued an XIO Control to select the keyboard, along with an interrupt routine that read the keypress value and loaded it into the ACC register before returning to the XIO Control instruction to reissue it. 

Each time I press a key, it locks down, triggers an interrupt on level 4 and waits. The interrupt routine reads the bit value into a memory location, loads that into the accumulator to make it easily visible to me at the console, then branches out of the interrupt routine to do reenable the keyboard. The XIO Control causes the reset solenoids to unlock the keyboard and turns on the Select lamp on the console. 

In addition to the keys that produce hollerith values, there are three field oriented keys - backspace, erase field and end field. Since a punched card is twelve rows, the hollerith is returned in the leftmost 12 bits while bits 12, 13 and 14 represent these special field keys. 

A Numeric shift key alters the hollerith returned when a particular keystem is pressed - changing it from the alpha (lower) symbol to the upper symbol. The Keyboard Restore key just unlocks the keyboard and removes the hollerith encoding of whatever key had previously been depressed. The Interrupt Request key triggers an interrupt on level 4 and the Device Status Word tells us that key was pressed rather than any other key. 

RESULTS OF THE TESTING

I checked all the alpha position codes (bottom character on each keycap, emitted when the Numeric key is NOT depressed). However, Numeric did nothing, the character was always the alpha version. 

REPAIR OF NUMERIC KEY FUNCTION

I disassembled everything and found that the Numeric key is a spring loaded plunger that pushes a leaf spring microswitch, but the plunger was missing the leaf entirely. I loosened and moved the mount so that this is now working properly. My VOM verified that the microswitch itself works properly. 

I didn't have time to run through all the numeric (upper character) codes of the keycaps as there was an angry lightning storm hitting the area. I though it wise to keep the machine and my sensitive test gear disconnected from the power lines until the strikes were over. 

HEAD START ON ADDITIONAL PERIPHERAL TESTING

I had previously verified that the Console Entry Switches, 16 toggle switches across the front of the console printer, are correctly read into memory with the XIO Read instruction.

The console printer and the disk drive are not yet working, but I could check for the appropriate bits that say so in the Device Status Words for those devices. I see that bit 5 is on for the keyboard/printer device controller when I read the DSW, which is due to the Forms Out condition (no paper in typewriter) also visible as a console lamp. 

To round out the other testing that is possible at this point for I/O devices, I issued sense device XIOs to the internal disk drive and to the 1231 Optical Mark Reader, as both of these device controllers are configured into this system. I did see the Disk Not Ready bit (3) for the disk drive along with Carriage Home and the sector number value was its default of b'11 so that was a good omen. The 1231 DSW was completely zeroes, while I had expected to see bit 15 for the optical mark device indicating that it is not ready.  

It is possible that the Not Ready condition has to be generated by the 1231 itself and with nothing attached to the connector, the lack of a bit is appropriate. If I had the ALDs for the 1231 controller I could check on this possibility, but for now I won't worry about this. 

There are no device controllers configured for the 1442, 1132, 1134, 1055 or 1627, thus an XIO to them will result in a completely empty DSW every time. I verified this result. 

TESTING THE ABILITY TO RESET INTERRUPT LEVELS WITH A BOSC INSTRUCTION

The Branch or Skip on Condition (BSC) instruction has a special function overlaid on it, active when bit 9 of the instruction is set to 1. This makes it a Branch Out (BOSC) that would end an interrupt handler and turn off the level. 

I tested this independent of the keyboard by using the Prog Stop button on the console. This button generates an interrupt on Level 5 and sets a bit in the Interrupt Level Status Word (ILSW) to indicate the button was the source of the interrupt. The button acts as a single shot to trigger the request, thus the level will turn off if you issue a BOSC while the level is active.

I tried to reset it with a short format (single word) BOSC instruction, but it didn't shut off. I hauled out the scope probes and monitored the gate that sets the -Branch Out signal which flips off the interrupt level at every T6 clock state if the signal is active. 

I wasn't seeing it trigger although most of the input conditions were met. It was a BSC instruction, it was short format, and Bit 9 of the instruction had been set. The logic to set this signal has two AND gates, one for the short format and one for the long format BOSC. 

Looking closer at the AND gate, I identified a fourth input condition, +Skip Condition, which means that the BSC would have skipped the next sequential instruction. The behavior of 1130 instructions is somewhat convoluted, in that behaviors switch based on factors such as short versus long format, use of index registers, etc. I hadn't remembered this particular subtlety, but once I changed the BOSC instruction to give it all possible conditions, at least one of them was satisfied, the BOSC skipped, the signal was set and indeed my -Branch Out was active, resetting the interrupt level as desired!

I therefore know there is a defect in the keyboard device controller logic that causes it to stay in level 4 perpetually. The trigger is turned off by the XIO Sense Device when bit 15 is on (called an XIO Sense Device with Reset). Thus when the interrupt handler is exited by a BOSC the interrupt level goes off. Not so with the current machine - once a key press has triggered a request for level 4 interrupt, it cannot be turned off with reset to the entire machine. 

The logic involved is well localized and should be easy to watch with the scope and debug. I will work on this next time I visit the shop. 

MINOR RANT ABOUT THE CONVOLUTED INSTRUCTION BEHAVIORS

As one example of the modal change in behavior, lets look at the BSC instruction. It either flows to the next sequential instruction or takes a branch, depending on whether some conditions are met. These are defined states such as zero accumulator, carry sign on, and so forth. 

However, the short version of BSC will skip when any of the conditions are satisfied; the long version branches only when NONE of the selected conditions are true. Inverses of each other, dependent on the length of the instruction.

Next, the BSC does different things in short versus long. The short instruction either drops to the next address (N+1) or skips over a word to execute N+2. The long instruction either branches to some absolute address encoded in the second word of the instruction or drops through to N+1. 

Other instructions are similarly modal. The short format Modify Index Register and Skip (MDX) instruction can jump to an address relative to the current position, or jump to the pointer in an Index register with a relative displacement added to it. The relative jumps are -127 to +128 words from the location where the instruction is executing. 

The long format of MDX is quite a bit different. With no index register specified, a long MDX is also called a Modify Memory as it will add the relative displacement (-127 to +128) to the contents of the memory location pointed at by the second word of the instruction. It is often used to bump a counter or lock word in memory.

If the long format MDX has an index register specified, its behavior is to add some value to the index register. If the instruction has the Indirect Address bit on, then the location in the second word of the MDX is read and the contents of that location are added to the register. Without IA, the value of the second word of the MDX is added to the register,  without involving any memory location. 

One has to remember these rules which are hard to codify in a reference card thus easy to forget if you are not regularly coding for the 1130. At least, that is my excuse for why I  was rusty and made a few mistakes. 

Possible defects in the IBM 1130 based on some hand entered code

ENTERED CODE TO TEST OUT THE REMAINING KEYBOARD CONTROLLER FUNCTIONS

There were three steps left in my full test of the keyboard device controller functionality. I wanted to verify that each and every key produces the proper hollerith code, check that an XIO Sense Device with Reset will turn off the interrupt request trigger, and test that a BOSC (Branch Conditional with bit 9 on) will turn off the interrupt level.

I BELIEVE I DISCOVERED SOME ERRONEOUS BEHAVIOR

I could NOT get a BOSC to turn off the interrupt level. Not sure if this is due to repeated triggering from the device controller or a flaw in the execution of BOSC. There were also some oddities with processing of long (doubleword) instructions that I saw.

INVESTIGATION PLAN

I can run the machine with interrupts blocked, thus it won't ever go into the interrupt routine. That will allow me easier coding for a loop to XIO Control (select the keyboard), wait, then XIO Read to view the hollerith code returned.

It will also give me easy visibility to the function of XIO Sense Device with Reset, in that I should see the request for an interrupt go away so that when I flip off the interrupt block switch, it does not jump there. 

I will hand step through some long format instructions to carefully exam their execution. The problems could have been coding errors on my part, but I will look closely to catch any defects that might exist.

Almost finished with successful testing of the 1130 keyboard device controller logic; tested more instructions by hand

TESTING SOLENOID SELECT LOGIC, READ, INTERRUPT, STATUS WORD

I continued testing the keyboard device controller circuits. I had validated that an XIO Control will select the keyboard and light the lamp. The remaining functions of the controller that needed testing:

• Activate the solenoid to reset the keyboard when a Control is received
• Activate the solenoid to reset the keyboard when the Rest KB key is pressed
• Triggering an interrupt when a key is pressed
• Triggering an interrupt with the Int key is pressed
• Setting the proper bits in the Device Status Word for keypresses and Int key
• Responding to a Read command and delivering the proper code
• Responding to a Sense Device command and returning the proper status bits
• Setting the proper bit in the Interrupt Level Status Word when we are interrupting
• Responding to bit 15 in the Sense Device command that causes a reset
• Verifying that the DSW shows the setting of the Keyboard/Console switch

A small portion of the keyboard device controller logic ties in the response signal from the typewriter (console printer) device controller, as both trigger an interrupt on level 4 and are identified by the same bit (bit 1) of the Interrupt Level Status Word. I did not test this yet as I am not ready to debug the typewriter driver at this time. 

The good news is that it all appears sound and results look correct. The few things remaining to test this afternoon are solely to be comprehensive.

1. Store the ILSW for the interrupt and ensure that the TWR/KB bit (bit 1) is the only one on
2. Block interrupts, trigger a response and verify that Sense Device with Reset bit 15 turns it off
3. Press every key combination and verify that the hollerith code returned is correct

HAND TESTED VARIOUS INSTRUCTIONS, ALL WORKED PROPERLY

I entered code to exercise various instructions and watched to see that the results were correct. I didn't try every corner case but everything that I did attempt worked exactly as it should. This is an extremely good omen and an indication that I won't encounter a large number of failures in the detailed checkout.

The instructions I tested:

• Load instruction, both short and long format
• Add instruction, both short and long format
• Subtract long format
• Multiple long format
• Divide long format
• AND long format
• OR long format
• EOR long format (XOR)
• Load Index short format
• Store Index short, IAR and IX 1
• Set Status to verify Carry and Overflow are set, reset
• Branch long
• Branch indirect
• Branch and turn off interrupt level (BOSC)

Bit 0 flip with parity stop has gone away

MY ANALYSIS OF THE BIT FLIP ISSUE

Since I had used the Storage Load and Storage Display CE functions, which loop continually through memory either storing a pattern on the console entry switches or reading out storage, I was pretty certain that the sporadic flip of a bit from 0 to 1 was NOT occurring in the memory unit itself. If it had, the Storage Display would have stopped on a parity error. 

It was occurring during program execution, specifically with a tight loop of an Add instruction and a branch back (MDX -1). My working assumption is that some other part of the machine which writes to memory is flipping bit 0 improperly. 

The inputs to the storage buffer register (B Reg or SBR) are all tied together in a large wired-OR with every contributor able to assert a 1 bit by pulling the shared line down. They should all be properly gated so that they do NOT pull to 0 unless they are supposed to be controlling memory.

It was my working hypothesis that one of those sources was not gated properly and sometimes emitted a 1 into the SBR at bit 0. I was seeing my loop programs trip an error within a second or two of starting to execute, which is frequent enough to trap with a scope or logic analyzer but not fixed enough to find statically. 

THE ISSUE IS NO LONGER OCCURRING

However, when I ran the loop this time, it ran continually without any injection of a 1 and therefore without the parity stop. There may be other conditions necessary to trigger the problem but as of right now it seems solid enough that I can proceed with debugging by running code. 

More cleanup of the database, I deem it ready for use

MOST OF THE 80 DUPLICATES WERE NOT, BUT FOUND A FEW TYPOS

Where I had duplicates, i.e. the same pin assigned to two Netnames, in most cases these were the signal entry pages of the ALD, which just list the connector pin for the I/O cable and where the signal first goes inside the 1130. These are legitimate and I left them.

I did find a couple of typos. For example, there are two associated nets, +Bit Counter E and -Bit Counter E. In a couple of entries, I typed the wrong sign for the entry. After verifying with the real ALD pages what was the correct value, I adjusted things. 

We are still at a count of 6,900 pin entries since those were all false duplicates.

RESOLVED AMBIGUITIES AND FIXED TYPOS

A sort just by netname let me perform an eyeball scan for places where I entered netnames differently but these might be the same net. I again had to refer to the ALD images to make the decisions, but that did let me improve the quality of the data. 

As an example of the ambiguities I cleaned up, sometimes I referred to a clock state as +T 2 and other times as '+T2 but these were clearly the same net and should be electrically connected. In these cases I referred to the ALDs and made a choice for the form I believed would be canonical, then repaired the spreadsheet entries that differed.

Removed direct duplicates in the spreadsheet of IBM 1130 signal pins

REMOVED DUPLICATES

I saved the spreadsheet in CSV format, sorted by netname, slot, pin, and compartment. I then whipped up a Python program to look for successive entries that were duplicates in those fields. This gave me a hit list to use to strip the excess entries from the database. At the end of that process I was down to 6,900 entries.

I then ran a different sort, using only slot, pin and compartment, to look for duplicates that might have different netnames. This would flag any entries where the netnames differed or entries that might erroneously assigned. I discovered 80 duplicates by this method but resolution will be slow. 

I will need to look directly into the relevant ALD pages to find what the correct values should be. This will occur over the next day. 

Completed second pass entering signals to 1130 database

COMPLETED ENTERING SIGNALS TO THE SPREADSHEET

The final stretch, covering the inputs to the 2501 Card Reader pages FRxxx, was particularly tedious. Blurry images and complex interconnections meant that each ALD page took quite a while to enter. Many times a signal would not show up, for example SQ and SG might be confused as they looked identical on a blurry image of a page printed with a 1403 printer chain. Finally, however, I was done.

The result was 7,43 9raw pin entries. There are some additional ALD pages that, if I can get access to them, will let me complete the database for all standard 1130 systems. First, I am missing one page of the 2501 device controller section (FR341). I am missing the entire ALD sections for the Synchronous Communications Adapter (SCA), which are FC pages, and the 1231 Optical Mark Reader, whose ALD page names begin with FD. 

I have asked owners of another 1130 who had those pages in their ALDs; at least at one time they owned ALDs with those sections included. They are searching for them now and hopefully I will have more work to do, adding the 1231 and SCA to the database. 

CLEANUP AHEAD

I will sort the database to get all the netname entries together to look for:

• Duplicate entries
• Variations in signal names
• Variations in net names
• Signals entered under two similar netnames that should be the same

The result will be the final version of the spreadsheet that I can put to use in verifying connectivity particularly between backplanes (compartments) but a reasonable fraction of all signal paths are included.