Addressing the frequency challenges in level shifting the disk head signals, building out disk driver logic

XEROX ALTO - DIABLO DISK TOOL CREATION

To deal with the high frequency level shifting demands I have for the datastreams to and from the disk heads, I chose and ordered some different components. The two incoming lines, Read Clock and Read Data, will be handled by a 3.3V zener diode to clamp the high level to 3.3V. The combined outbound Write Data and Clock signal will be driven by a 74HCT125 chip.

These solutions are much faster than the chips I originally used. I have to do some rework on my driver role extension board, but have plenty of room to add the new chip and the two zener diodes. Then there is a small amount of rewiring for the three signal's input and output wires.

I also discovered that I could rewire on power line and swap out the CD4504b chips for CD4050b, giving me the same level shifting on input lines but with much less delay. I will pick up the chips and improve the board by this substitution.

I also dug around to figure out why the register and file IO over USB was not working. The documentation from Digilent on this is abysmal, specifically they have no example UCF files to identify what pin they mean when they use various names in their reference code. None line up, they don't match the names on the Nexys2 board documentation, and it is extremely frustrating.

I went through this the last time I used their reference code and the functions they built into the Cypress USB chip on the board (but don't document worth a shit). I think I figured out that the Write flag used in the code belongs with the FLAGC signal and not the UsbWR signal, or one of a dozen aliases they use for each of these.

This worked great for register read/write, I can now update my registers and see the changed value from the PC side. I am still having trouble getting the File IO function to read and write the RAM properly. Investigating took a while. I couldn't see what was wrong - it was partially working at least but I seemed to always get zeroes back. I decided to hook the LEDs to the RAM output register which will let me see any non-zero bits immediately.

Turns out, no non-zero values at all. Something is not working properly which will take more detailed debugging into the function of the core memory access function and the DRAM itself. I will plan out a sequence of tests that will zoom in on whatever is wrong.

I spent the day dividing up the work involved in reading and writing a sector into modular blocks which I can implement once and use in multiple places. For example, the deserializer module which will return a word once every 16 bits but only while the logic is in the 'synced' state.

This requires some interesting timing oriented code - we are receiving pulses from the Read Clock and the Read Data lines asynchronously to our logic, and the way you detect that a 0 bit is sent is by the absence of a Read Data pulse during the period between two Read Clock signals.

I originally set up some timing to wait for this, but think I can use a more simple state machine so I will recode it. Essentially, the any time we get a '1' on Read Clock, we emit the state of a flip flop and then reset the flip flop. Beginning when the Read Clock goes back to '0', we watch and if Read Data is '1' in any tick, we set the flip flop on. Thus, every time there is a Read Clock rising edge, we emit the 0 or one from the prior interval.

This takes a bit of careful design to avoid emitting a spurious bit when we first are synced up, since the first clock pulse we see after we found the '1' of the sync word should be ignored. The design of the FSM should be able to accommodate this. In fact I tore up several designs and kept refactoring the logic.

At last, by eight PM, I had an elegant state machine that worked for delivering serial bits to the deserializer, waited through a preamble to find the sync ('1') bit, and would shut off on command at the end of a field.

Driver board tested okay, building driver logic now

XEROX ALTO - DIABLO DISK TOOL CREATION

I wired up the driver role extension board, powered it all up and began testing to see that my outputs would swing between 0 and +5 as I switched on each signal. I discovered that the signals for Cylinder Address 64 and Cylinder Address 128 were swapped,. I also discovered that my Index Marker, Read Clock and Read Data input signals were swapped around.

My solution to these was to adjust the documentation. I will then route them appropriately inside the FPGA and all will be well. It was time to add the layers of insulation and copper grounding plates to both sides and finalize this board for use.

I built up the logic to keep track of the current disk sector, watching the Index Marker and Sector Marker lines for pulses. Next, I built up the state machines to trigger a seek to a cylinder and a restore to home cylinder.

One design choice I made might get confusing as I work on my logic. The Diablo interface uses inverted logic, meaning that to activate a signal such as Restore, you set it to 0 while the inactive state is 1. Inputs are the same, with a Sector Marker signal staying at 1 except for a 5 microsecond period where it drops to 0 (active).

I invert all those signals at the entry/exit to my fpga, so that inside my logic, an active signal is 1. Thus, Sector Marker goes to 1 for a few microseconds. Restore is at 0 unless I want to request a restore, where I set the signal to 1 for a few microseconds.

This evening I added logic to match a specific sector target against the sector counter that is continuously running as the disk rotates. I finished with only a partial design for the main sector read FSM, which I have to break apart more modularly to leverage it better for the complex structure of a sector.

I am somewhat concerned that my level shifters are not fast enough for the Read Clock, Read Data and Write Data and Clock signals. I need to generate pulses with a rise time of <50ns and a duration of just 100ns, For the combined data and clock signal for writing, these occur every 320ns. The level shifters could be slower than 50ns for the pulse edges and will just barely fit two in the 320ns window.

I think I may need to come up with a manual circuit having a much faster transition time and frequency response. The FPGA itself produces great crisp signals, but at 3.3V not the 5V swing used for the Diablo drive. I think I have a fix for the outbound signal and can handle the inbound two signals with a voltage divider or zener diode.

At this point, I must get the register read/write and RAM read/write to work over USB, as that will be the key to the rest of the development.

Steady work on building up board

XEROX ALTO - DIABLO DISK TOOL CREATION

I set up logic to display various bits of information on the four 7-segment displays on the fpga board. It will be in hexadecimal. Each byte I select will be displayed on the two rightmost positions, which leaves me with two open displays. I will put the head number on display 1 and the actual sector number as it is detected by the drive on the second display.

When I ran a check to test out my code, the Adept utility thought it had written and read the data from the RAM, but it always came back all zeroes. Lastly, regardless of what I tried to write to any register, I always got zero back.

I checked for shorts before powering up my level shifting driver role extension board, connected to the FPGA board. I have everything laid out but want to work while I am fresh tomorrow morning, as there is potential to blow chips or even the fpga board if I make mistakes here.

While I worked on those problems, I also collected VHDL code to build a VGA display, ascii text only, which I would use to display the results of the latest sector read or written by the tool. I will be integrating this into the module slowly over the coming days, with the goal of having a quick display of the current sector and key other information that can be read off a monitor.

Building up disk tool foundational logic

The Digital Game Museum has a policy that a board member must be in attendance on each Saturday, when we are open to the public. It was my turn to be there today. It was very quiet.

XEROX ALTO - DIABLO DISK TOOL CREATION

I rolled in the code from the Digilent reference implementations to allow PC users to read or load the DRAM on the fpga board, as well as writing or reading from eight registers I defined in the FPGA. These will be used to request transactions such as 'read a sector into the DRAM'.

That is all cleanly synthesizing, It does need to be tested just to verify that the PC can talk to the fpga board, and that stored information comes back as written.

It is my intent to test the extension board with the current hookup of the switches, buttons and LEDs then when I am sure that all the connectivity is correct, I can reassign these to display the registers and other system state of the tool.

I put in logic to drive the four digits of seven-segment displays, which will show selected information while the board is in operation. For example, it can display the current cylinder number, the current head and sector number, the current command, the response and the status of the last operation.

Setting up to test the disk driver role board and starting on the fpga implementation

XEROX ALTO - DIABLO DISK TOOL CREATION

Today my copper plates arrived and I could finish up the construction of the driver role board. First up, however, was to test that the board I wired works properly. I whipped up some fpga code that would light the LEDs when various signals were high or low on input and that would emit a high output on a selected line.

Since I had 9 inputs but only 8 LEDs, I needed to use one of the pushbuttons to switch to the ninth input line. I need to generate outputs on 13 lines but only have eight slide switches on the board, so I used a second pushbutton to swap between the first 8 and the last five signals.

First up, I had to make sure my temporary fpga code was working correctly, before inserting the driver role board and testing it. That took a while to get all the signals for every device on the board working - DRAM, flash, VGA, PS/2, serial port, 7 Segment Displays, switches, LEDs, buttons, peripheral adapter signals, and the USB signals.

Now that it is working fine with the small extension board which allowed me to check the output pins and route an output to all the input ports, I am ready to wire up the extension board to power and do some testing at the end of the cable. I should see +5V on the output pins when I turn on each signal, and I should be able to detect ground and +5V as a 0 and 1 when I hook them onto the input pins.

It is late, so I will work on this over the weekend. I have an obligation on Saturday to be at the game museum, as we want a board member there every saturday but all my peers are on business trips or otherwise unavailable.

I will bring my computers and documents in order to integrate in the code that reads and writes to the onboard DRAM and implements my transactional control registers. These won't impact the testing of the cable at all, but will let me move ahead.

Done wiring the driver role extension board, digging into the design of the logic

XEROX ALTO - DIABLO DISK TOOL CREATION

I received my chip sockets today and finalized the wiring of the driver role extension board. By lunchtime I was just completing a thorough connectivity and short test of everything before installing chips and wiring in the disk cable.

Soldering the 9 input and 13 output lines onto the board was tedious, but eventually I got the wires all inserted. For some reason, one of the input lines is missing, but I had verified it was wired on the cable a few days ago, so I probably taped it into the unused bunch. That adds yet another time-sucking activity, probing all the pairs to find the one that is connected to pin A.

With pin A's wire discovered and soldered down, it was time to bond all the grounds together and tie them to the board. A final test to ensure that no adjacent signal lines are shorting where I soldered the cable on, then it was time to figure out how to anchor the disk cable to the board.

I inserted all the chip, triple checked the pin assignments, polarities and voltage levels of all the level shifting circuits. Everything looks good, This needs +5V, +3.3V and ground power lines attached. I plan to put my copper ground planes on the bottom and top of the assembly and secure everything to finalize this, as soon as the plates arrive.

Board almost complete, waiting for power wires and ground planes

Cable to hook to Diablo disk drive and board to attach to FPGA

I had to begin the VHDL coding,with the sector and cylinder buffer transactions and basic transactions the first steps. This is because I can fully test these with the Adept utility before I add in any Diablo oriented logic or even hook up the extension board to the fpga.

I am still staring at the code, functionality and limitations of the various USB communications methods - essentially a remote block ram access, a remote DRAM access and some 'register' access to figure out the best way to build the system to handle both emulation and driver roles.

I am currently leaning to using just the 16MB of DRAM because it allows me to hold an entire disk cartridge in a easy to address format. Each sector, 532 bytes of data, will sit in 1024 bytes on the DRAM, an even power of two address. I will use five bits to select the 12 sectors (ignoring the wasted 4 sectors that this addressing selects. One bit for head, which has zero waste, and then 8 bits to specify cylinders 0 to 203, so again some waste.

It lets me cleanly control the top 8 address lines for cylinder number, the next line for head number, the following five lines for sector number, and then the bottom 10 bits are the byte number in the sector. No address multiplication, so a straightforward implementation, even if it is wasteful.

The 2,604,672 actual bytes of the virtual disk cartridge are sparsely stored in the 16,777,216 bytes of RAM. More than 84% empty but I have no use for the wasted RAM and this way it is easy to implement.

I will set up a special flag for each sector to show if the contents are invalid. That is, when I first start up in disk driver mode, until I read a particular sector, I have no idea what the contents of the sector will be. This flag will let me distinguish between an all zero sector and an 'undefined content' sector. It will only take up 4, 896 bits of distributed RAM, a teeny sliver of the available capacity on the FPGA chip.

Work on Diablo disk driver/emulator tool

Today is the day I spend with the 1401 restoration team at CHM, thus limited time for my own projects but I did move ahead a bit. At CHM, I replaced a set of brushes in a 729 tape drive, helped diagnose and fix a problem in the 1402 card reader,

XEROX ALTO - DIABLO DISK TOOL CREATION

I hooked up all the remaining wires on the board, lacking only the connections to the last, missing chip socket for it to be ready to have the disk cable soldered on. The sockets will be arriving tomorrow, so we will have a working extension board by end of week for certain.

The chips and my board for the emulator role have come in, but until I get the plug and shield I can't complete wiring up that side of the project.

I plan to add two sheets of insulation and then an upper and lower copper plate to help with signal integrity, given the discrete wire runs on the board. The copper sheets should arrive by Friday.

For simplicity, I will leverage the USB communications example projects provided by Digilent, which will allow me to easily load and fetch the contents of a RAM buffer on the fpga. The Xilinx Spartan 3E chip XC3S1200E on the Nexys2 board features 516,096 bits of block RAM.

The Block RAM on the fpga chip is enough to hold 32.256 words of Alto Diablo data, just over 121 sectors or about 5 cylinders. That is 2.5% of a disk cartridge.

The SDRAM on the Nexys2 board will hold more than seven full virtual disk cartridges, while we only need a cylinder buffer of 24 sectors and a single disk cartridge in RAM. I will leverage the Digilent Block RAM code to fetch and load the cylinder buffer.  Then, I will leverage the Digilent Memory code to fetch and load the virtual cartridge SDRAM.

Essentially I have to piece together a couple of reference project modules and some glue code to implement the transaction types I want for the tool. This allows me to use the Digilent supplied Adept utility right away, not having to complete any PC side code until it is convenient.

Substantial progress wiring up board for Diablo driver role, plus some Calcomp investigation

XEROX ALTO - DIABLO DISK TOOL CREATION

I took another look at the Diablo drive that this cable originally came with, since it would have had to compensate for the lack of a Select Unit line otherwise needed to activate the drive. Nothing was changed in the drive, but I happened to notice a couple of wires on the terminator that was attached to the drive.

The Select Unit 1 line was pulled to ground by a wire on the terminator itself, which is a great idea because it is easily accessible when attaching my tool. The user hooking my driver to a Diablo drive would just jumper across the resistor for pin L (Select Unit 1) that runs to ground, thus pulling the signal permanently on.

In addition to the Select Unit, my terminator also pulled Read Gate to ground, permanently streaming bits from the heads. With no wire in the cable, I will have to logically block this with a virtual read gate inside the fpga.

With this solved, I don't need to hunt for, wait to receive and install extra pins in my cable. I can move right into wiring this up as it sits. My level shifter chips won't arrive until Friday thus I can't have the entire extension board complete today.

I grabbed socket diagrams and IC sockets to begin wiring up the extension board. In addition, I carefully identified each signal wire and labeled it, to make it easy to wire them on when it is time.

By lunchtime I had a bit less than half of the input section wired and am one 16 pin socket short of what I need for the complete board. I hoped to scrounge through my side shed to see if I had even one more socket on hand, but I have to buy more. I can't install the chips.

By dinnertime I had completely wired the input section, other than attaching the actual disk cable, had wired all the power for three of the four chips in the output section (since I don't have the fourth chip socket yet), and have most of the select and enable lines hooked up.

I did buy a plug for use in the emulator role, which should arrive in about a week. It has solder-on terminals and a full set of pins allowing me to implement all the signals I need or want. I went looking for a protective housing which I found on eBay. It has to travel here from Israel, so could be 3-4 weeks until I can properly build the emulator role cable.

After dinner, I went back to my wiring and now have all the lines that will go to the cable hooked to all chips but one, and I am almost done connecting the other sides of those chips to the FPGA connector. When I have a chip socket to put in place and a few more hours, this will be almost complete. The chips themselves go into the socket and a few tantalum power filtering capacitors get added to wrap it up.

I began writing out the various finite state machines (FSMs) in pseudocode to work out the overall flow and process for the driver functionality. Once I have a reasonable idea at this level, I can convert them to FSM diagrams which ensures I think through all the transitions correctly.

I also began plotting out the pseudocode level for FSMs to handle the emulator role, since I may identify sharing opportunities or need to modify a driver role FSM slightly to fit the emulator needs. I have just the grossest levels worked out, but will iterate down through the details in the coming days.

RESTORATION OF CALCOMP 565 AS IBM 1627 PLOTTER

I did some research and satisfied myself that I should be able to shrink the aluminum on the plotter drum in the few places where it is stretched, thus with enough patience and time this drum can be trued up and flat again. The solution is to use a friction wheel, called a shrinking disc, to heat the stretched sections then cool with a spray of water.

If I can make a cylinder the correct size for the inside of the drum and push it inside the aluminum cylinder, it will act as a base to shrink against or stretch any small remaining dents. I need someone with a wood lathe to turn a piece to the size I need.

Blocked on a couple of fronts with Diablo tool wiring and 3178 monitor repair

XEROX ALTO - DIABLO DISK TOOL CREATION

I have worked out all the wiring assignments and FPGA signals involved and was ready to begin soldering the cable to one extension board to implement the disk driver role - able to run a real Diablo 31 disk drive. To do so, I had to unambiguously identify all the wires from the plug and put them at the correct location.

I quickly discovered that my cable is missing the signals for sector count that the drive would report back, nor the unit select line, but it does have index marker and write check llines which I didn't need. I have found a site that claims to offer the pins which would let me add the missing lines. I hope they will respond and allow me to buy a small quantity.

I can use the Index Marker and Sector Marker pulses to manage my own Sector Counter in the FPGA, but without a way of selecting the drive it would stay inert. Not as simple as I had hoped to leverage my existing cable exactly as the Alto is wired to the drive.

I need at least one more socket pin, or have to remove and transfer the pin that currently delivers the Write Check status since the Alto ignores that signal. Another option might be to find a way to bypass the select line and 'hot wire' the drive to be selected at all times, but this requires me to do something inside the Diablo drive which is suboptimal.

IBM 3178 MONITOR REPAIR

I opened the third monitor I received, the one with a broken plastic top cover, which was suspected to not work properly. Indeed, when I had tested it, there was no vertical deflection but I could see that a whole screen of content was making the one horizontal line very bright.

I could see a burned spot on the PCB in the section marked Vertical, where an electrolytic capacitor was connected. I will remove the part and check to see if it had shorted, causing the trace to heat and melt around it. There may be collateral damage, such as driver transistors, but first step is to remove and test the capacitor.

Unfortunately, the capacitor is just fine. I am guessing this was a bad solder joint which led to overheating and failure. The problem is to figure out where the pad is supposed to be connected, then ensure good traces exist. The surface is pretty damaged looking and I may have a trace failure.

Burnt land and traces(?) on 3178 circuit board

I think I will have to open a working monitor and photograph the same area to learn what the undamaged traces look like, then go back and repair my errant board.

RESTORATION OF CALCOMP 565 AS IBM 1627 PLOTTER

I had some discussions with others who might want a replica solenoid and pen for their plotters, because it may make sense to build a small batch at one time given how many people have 'penless' plotters out there.

There are a few levels of fidelity I could seek, which have increasing difficulty and cost but also increasing value to others. I am going to sketch out some ideas over the coming weeks and see what makes sense.

Finishing design work and starting construction of Xerox Alto - Diablo disk tool

CREATING ALTO RESTORATION DISK TOOL

I began the design work for the tool we will use to test out and drive Diablo disk drives, which also will act as a physical drive to emulate and replace a disk cartridge with a PC based file. I am leveraging my Digilent Nexys2 fpga board as the foundation of the tool.

I had to very carefully spec out what behavior the emulator has to present to look like a real disk as well as what it has to deal with to drive, read and write on the real drives. This involved reading documentation, schematics, Alto microcode and looking at investigations done by Ken Shirriff into the same source materials.

I should be able to start building up VHDL code this week and to solder up the cables and related interface hardware that will be needed. Careful advance planning will save a lot of wasted time later, which is why I am doing all the up front work.  The parts for the level shifting boards are on order.

The extension board for the Nexys2 FPGA board that will make wiring easy

Got some 3178 terminals, also parts for SCR module replacements

RESTORATION OF LIGHT DISPLAY ON 1131

My SCRs and resistors arrived from Digikey today, but I haven't built a circuit yet to test it out, mainly because I spent my day as a volunteer examiner for ham radio license tests today.

PICKUP OF 3178 TERMINALS

I spent the day yesterday on a road trip with a friend who had acquired an IBM 2540 Card Reader/Punch, hauling it back to the bay area from Sacramento. While picking up the unit, we both looked around the seller's facility where he had several 4361 and 4331 systems, keypunches, tape drives, terminals and more modems and routers than I though existed on the planet.

I picked up two complete 3178 (green screen) terminals (part of the IBM 3270 family) plus a spare keyboard and spare monitor. Now I have to pick up a controller such as the 3174 to make it usable with my P390 system. Testing (without a controller so very very limited) seemed to show everything working well.

Light display pedestal FINALLY completed and closed up.

RESTORATION OF LIGHT DISPLAY ON 1131

While I wait for my replacement bulbs to be delivered, I can get row L5 properly inserted in the honeycomb and then deal with the intermittent bulb contact in row L4. The lights, when on hand, will allow me to finish up row L6.

I did manage, after quite a bit of tweaking, to wedge L5 in adequately and all the bulbs lighting properly. Still having problems dealing with the erratic bulb on L4 - I am trying to manipulate the bulb hoping that I can get it to light reliably without having to pull row L4 out and start over. It will all come down, as it always does with the light panel, with trying to get the last couple of lights working and the last board inserted properly.

I received my bulbs and proceeded to build 16 lamp holders with these 715 mini bulbs. They are electrically identical to the full sized bulbs and produce the same light output, so my only issue is fitting them to the much larger lamp holder.

I use shrink wrap tubing on the wire leads of the bulb, from the glass down to the point where the wire lead will disappear into the pinhole of the lamp holder. This protects against the leads touching in a short circuit and also stands the bulb up further out of the holder to better match the filament locations of the original equipment bulbs.

I did a test on bit position 2, the one that I had found to be defective yesterday morning but that appeared okay when retested later in the day. I decided to hook up one bulb I have that works okay and give a test - it didn't light.

I then put on my new bulbs on row L6 - the last row to be inserted and therefore the one with the worst minimal access and maneuverability. Bit 2 is working, so I am not sure why I keep getting conflicting tests, but I tried to insert the board as it was.

 My mini lights stick out and are easily bent up or down so they won't fit in the honeycomb cells. Very tedious. All insertions begin with wrestling the board to the right as far as possible, since the power and lamp test wires are connected at that end and tend to spring out, pushing the board too far left.

It requires pushing rightward while pivoting the board around and getting sixteen lamp holders to enter their intended positions. Unfortunately, while pivoting the board, the gate lead snapped off the bit 0 SCR module. Now, I have to remove and replace that SCR before I can continue. Arrrgh.

I hoped I could dig out some of the encapsulation and save this SCR by soldering a new pin to the stub. Unfortunately, the bakelite covering crumbles easily and does not bend at all like plastic (or is a plastic whose plasticizer has departed this mortal veil many years ago). I managed to break off a lead inside while trying to clear space around the pin.

I put one of my donor SCR modules in the bit 0 location, and managed to get the board inserted almost firmly. It is wedged with very slight friction, mostly from one side, but I can't seem to wrestle it to a firmer fit. Still, it is in place and all the lights on row L6 light.

The final problem is the errant light on row L4, bit position 8 which I have to finesse until it works again, or pull the row and deal with the light issue more directly. I noticed that bit 9 is 'hot', always on and when I swap the signal connectors the flaw stays with lamp 9. Time to pull the board out and work on it.

Using my analyzer, I see that both the bit 8 and bit 9 SCRs are bad - 9 is always on and 8 is inoperative. I had only removed a total of 5 donor SCRs and have already used 4, so I ALSO have to remove row R5 and take off more SCRs from the CE light positions.

Two SCRs replaced, all bulbs lighting properly, so I insert L4 into the honeycomb. A light on position 10 is dark now. Remove board, find that the brittle leads at the glass envelope broke on the lamp. I tore it out and put in one of my mini bulbs, tested that all 16 lit, then reinserted. The bulb at position 8 is dark now. Removed board, tested lamp, which had gone open circuit.

New mini bulb in position 8 lamp holder, testing that all 16 lights illuminate during lamp test. Bend and pivot the holder into place, but before wedging it tightly, test again. Now bulb for position 5 is dark. Aaaaaaaaarrrrrrrrrrrrrrrrrrrrgggggggggggggggghhhhhhhhhhh. I hate this panel.

I may have to replace every one of the hundred or so original bulbs if they keep snapping during insertion into the honeycomb. At a minimum, if I don't disturb any other board, I might face more lamp failures on board L4.

I have 14 remaining original style lamps on board L4, one of which is bad and needs replacing. The question is whether I tear out all the other bulbs and go totally with mini lamps, or hope that the string of bulb failures will stop.

When I swung the board out yet again, it was clear that the bulb for bit 5 had self destructed. The bulb was sitting in the honeycomb while the lamp holder was still attached to the board. I replaced this with another mini bulb, tested all were lit, and managed to insert it with all still working properly

I also see that the sheet metal of the rear door comes perilously close to the signal pins on the back of the boards, something I don't like. I put an insulating layer on the offending area before I closed things up.

With the rear of the panel gently closed, I went around front and did another lamp test. Damn!! One bulb on L5 (Accumulator) and two on L6 (Extension) are off - tapping the panel slightly made a couple flicker on, but basically I would have to open the panel up and iterate endlessly with bad bulbs and contacts for L5 and L6. Meanwhile, every time I touch one thing, there is a risk another bulb will stop working.

I decided I can live with the dark positions, because I have already put in almost forty hours of frustrating work and still can't get all 156 bulbs working at the same time. The next time I touch this, I think it will be to strip out the current boards and SCRs to replace it all with some alternate system I build. This makes the machine impossibly fragile and undependable, as it sits.

I truly hate working on the light display and hope that I won't have to do anything to it for a very long time. The way the panel is built in my system is described in the ALDs and other docs as "early 1130s" style.  It has the SCR modules on the circuit boards attached to the rear of the lamp holders.

After those early machines, IBM changed to put 9 boards on the rear cover, each handing up to 20 lamps, with an unknown method of cabling to the lamp holders and for holding them in the honeycomb. I imagine it to be much easier to change bulbs and nearly impossible to blow SCRs with the new method.

To make a mid stream change of this scope to the machine probably meant there had been a flood of complaints from the CE organization about how difficult and time consuming it was to fix machines with the prior design. May also have been a very high rate of parts usage from blown SCRs on these boards.

I can probably build new SCR circuits so that I can either restore the full 8 CE light positions or replace others if more fail over time. I just need an SCR that can comfortably handle the .114A 5V load of the lamp, take the 7.5VAC input power and doesn't need any heat sink. I can wire that, plus a 6.8K resistor, onto the board in place of the encapsulated module used by IBM.

The order from Digikey is on its way - 10 sets of SCR and resistor - which I can test out on a CE light position first and then use to backfill all the modules I previously removed. It will mean opening up this bedeviled panel again, but only to touch row R5 which is relatively easy to manipulate. I won't touch any other rows for the near term.

SCRs replaced on light panel, nearing end of bulb insertion; checking out repaired drum for plotter

My day to meet the rest of the 1401 restoration team at CHM, but can get some work done before and afterwards.

RESTORATION OF LIGHT DISPLAY ON 1131

Well, the replacement bulbs I ordered are not going to arrive today as promised on the selling website. They are coming via USPS and should be delivered by the end of tomorrow. I can't close up and finish this until I have the lights in place.

This morning, it was time to verify the bad SCRs and carefully desolder them from the PCB boards. Four of the left rows have a bad SCR - one apiece - which need to be replaced. Using my semiconductor analyzer device, I can check each suspect SCR (actually an SCR plus a resistor in a molded case). This allowed me to validate the SCRs being removed.

I had removed five SCRs from the "CE Signal" section of row 5 right, in order to repair bad SCRs on the lamps for signals that are normally used. The CE lights are ad-hoc displays that a CE will jumper to some condition to help in debugging a problem. I can use my oscilloscope and other tools instead of such lights.

With the donor SCRs removed, I populated the remaining lamps on row 5 right and inserted it into the machine; now the right side is complete. It is a pleasure to see 2/3 of the boards in place and every light in those rows lit during a lamp test.

I made use of three of my new mini lamps and indeed they look exactly like all the other incandescent lamps when viewed through the panel. I decided I will use shrink wrap as an insulator around one of the two legs of each mini bulb I make up, as there is a risk that if the bulb gets rotated it will bring the two leads into contact with each other and short out another SCR.

The failed SCRs were validated using my analyzer and are bit 10 on left row 2 (SAR), bit 5 on left row 3 (SBR), bit 5 on left row 5 (Accumulator) and bit 2 on left row 6 (Extension). I began my morning by working on L2. Somehow by the afternoon, bit 2 of row 6 was working fine, no issue with the SCR.

The SCR for bit 10 is in the most accessible position of the three failure points (10, 5 and 2) on these boards. Using solder wick and careful work, I released the failed SCR and cleaned up the board. I then took my salvaged SCR that I took out of the CE light positions, dressed its leads and inserted it in the board. Once soldered up, I could put on the bulbs, verify that all lamps lit under test and then put that of lights into place in the honeycomb assembly.

Board with defective SCR module removed

Underside of board with bad SCR module removed

Three more to do - L3 (SBR), L5 (Acc) and L6 (Ext) - with work resuming after a break on board left 3 to replace the SCR in bit position 5. These boards are wired in place and require quite a bit of torque to twist them enough to put the solder face of the board somewhat upward where I can reach it.

I need to hold the board twisted, apply the soldering iron tip, hold the wick in place, and manipulate the SCR to get it out, which takes four of the two hands I own. Persistence, creativity and luck combine to overcome this hand shortage and I completed L3 and inserted it with all bulbs working.

As so often happens with this poorly designed hot mess of a light panel, a bulb stopped working on a previously inserted board, L4. I have to investigate it, correct the problem and then get back to work on completing L5 and L6. I ran out of morning work time at this point and had to head over to CHM.

While I was out on the way to CHM, I stopped and bought some heat shrink tubing, which I will use with the mini (715) bulbs to ensure that the two legs can't twist into contact with each other. I made up one lamp using this method, which also allows me to stand the bulb higher off the socket and closer to where the filament sits in the original equipment bulbs.

I came back in late afternoon and commenced work, at least as far as I could get with the bulbs on hand. I replaced the bad SCR on board L5 at bit position 5, inserted my remaining bulbs and found that 4 and 14 were dark under lamp test. I also pushed the ground pin into the unlit bulb on L4, restoring it to proper operation.

I checked the bulbs in those positions and found them unusable. To be sure that everything else was good, I moved bulbs from 6 and 15 over to 4 and 14, ensuring that every bulb glowed. I can't insert row L5 into the honeycomb until I get my new replacement bulbs and place them on the two open spots, but otherwise it is ready to insert.

Row L6 tests fine for all 16 SCR positions, the problem I thought I had spotted on bit 2 is either cleared up on its own or was a measurement error. Therefore, it is my expectation that once I have the replacement bulbs tomorrow, I can put together than 16 lamps I need for this row and the 2 needed to wrap up row L5.

In early evening, I decided to make two more working lamps from the stock I had. There were a few bulbs which worked but whose wire leads were too short to reliably hook over the ends of the lamp holders. Other bulbs were dead inside but had good long leads.

The solution was to cut off the long leads from bad bulbs and solder them to the too-short leads on good bulbs, allowing me to mount the bulbs in holders successfully. I added them to the L5 board and have a full set of 16 working lamps for this row (Accumulator). I am still finessing the insertion of the board into the honeycomb, not yet done with L5.

The darned row L4 bulbs are flickering off again - the original unlit bulb came back along with a nearby mate. The least amount of flexing of the board and connectivity to the bulb is lost or regained. I will have to pull L4 out and reseat the bulbs more carefully, since this is unacceptable.

Now just in wait mode until I have 16 bulbs to put in holders and insert into the final L6 board. USPS, please be unusually timely and dependable. Just a few more tedious hours and frustrating setbacks until the entire light display is together and all lamps light up.

Only lower two boards on right of picture left to do, light panel coming together

RESTORATION OF CALCOMP 565 AS IBM 1627 PLOTTER

I reassembled the drum with its internal braces, side mounts and brackets. It is still a bit too much out of true in a couple of spots, but those should be recoverable. The remaining issue will be a few rough spots on the drum surface which might be able to be sanded out (thinning the metal in that spot).

Drum reassembled, first view

Second view, drum rotated about 90 degrees

Third view, rotated another 90 degrees

Final view, about 270 degrees from initial view

The risk of sanding it down is a punch thru. At worst, however, it would have to be bridged with automobile dent repair materials. I am feeling cautiously optimistic about the potential to restore this to operation.

Finished cleaning and testing lamp assemblies, began reassembly of light panel; plotter drum much improved

RESTORATION OF LIGHT DISPLAY ON 1131

I will have to wipe the SCR PCB pins with vinegar/salt and then again with sodium bicarb, since there is so much corrosion on those pins too. Some of the lamp holders were extremely difficult to break free, because the pin and lamp holder pinhole had almost welded together with oxides.

I ended up with 18 broken, dead or questionable lamps out of the 156 in the pedestal. A bit over a 10% failure rate, although it is hard to know what part was already dark and what broke during the handling. With 80 replacement bulbs (the mini kind) on order, I should be able to close up the light panel with fully working bulbs, with plenty of spare bulbs for future bulb failures. Thirty of the bulbs are fast-tracked to arrive Wednesday, because I don't want to wait too long before firing up the system again.

I rehabilitated four of the bad lamps, leaving me 14 that need replacements. I had four of the mini 715 bulbs on hand, which I installed in holders - now just ten lamps that need the new bulbs coming on Wednesday. Eight lamps are CE indicators, meaning they are only used if I hook them to some signal I am monitoring, otherwise they remain dark, but that still leaves two of the system states I wouldn't see unless the lamps are fixed.

The honeycomb sections are very firmly in place and there is a slight amount of friction on the sides as it slides into the metal enclosure, rubbing along the vertical plastic bars that should hold everything in place. I suspected that the friction would grow too much when I had the plastic glue on the side plates, so I did some sanding down of the side surfaces of the vertical plastic bars. That should make the fit easier but also improve contact area for gluing.

Not sure how I will get some side pressure introduced to firm up the plastic bonding, but the alternative of removing the vertical plastic bars seems too prone to problems. Maybe I will loosen one side so that it can slide left-right, use it to get sufficient bonding pressure on the panel and tighten it up after everything is set tomorrow.

I ended up getting a good left and right side adhesion holding the light panel in place without having to loosen either of the vertical. Now I can carefully insert lamps into the honeycomb.

I didn't want to power up until I have all the bulbs inserted firmly on the SCR PCBs and all PCBs insulated from each other and the metal enclosure. Sheets of paper insulate the PCBs that are not yet installed. I do a lamp test to verify that all 156 bulbs are working properly before I begin seating each PCB painstakingly into the honeycomb. After insertion, I check to find if any no longer light.

I am very very slowly inserting PCBs and their lamps into the honeycomb. This is extremely tough - there are up to 16 lamps in a row, where all 16 must fit through the small bulb diameter hole and all 16 holders must be aligned close enough to push into the honeycomb.

Partway through the hours of work replacing lights in pedestal

It was easy with the bottom right row that has only two bulbs, but the expected horrific task for the upper left (IAR) row. When I got the sockets wedged into place, the bulb for bit 1 had packed it in (or won't light, anyway). Have to pull the darned PCB out and start over. It will just be that much harder once I am down to the last row on each side, when all my maneuvering room will be gone.

By lunchtime, I had the top right and top left rows, the bottom right row and had inserted the right row just below the top but one of the lamps is not lighting. Have to pull it out and work on that lamp (the E2 lamp). For convenience, I am going to label the rows 1 to 6, with 1 on the top and 6 on the bottom, then refer to right or left as seen from the front of the machine.

After lunch, I fixed the E2 light in row R2 and moved on to populating the 16 lamps in row L2 (SAR). I discovered that the SCR for bit 10 is not working - even if I swap the signal lines between it and an adjacent SCR, the lamp doesn't light. I will need to replace it.

I have eight lamps on the panel that are intended for CE diagnostic displays - if wired up by the CE, they will light when the connected signal is '1'. They have no 'normal' use and therefore are the best place to borrow working SCRs.

SCRs on the narrow PCB, pins at top go into lamp holders

Bottom of SCR PCBs

I populated and inserted rows R3 and R4, which work perfectly. R6 is already in place and I won't try to install R5 since it is the donor board with SCRs that can be relocated to more important positions such as L2 bit 10.

Right side, all rows but 5 in place

I placed lamps in L3 (SBR) and tested them to be sure that the lamps and SCRs are all functional. On L3, bit 5 SCR is dead. Time to move on to L4, L5 and L6 to round up all the bad SCR positions before I begin repairs.


L4 (AFR) worked great and is inserted into the honeycomb cells. L3 is malfunctioning for bit 5.  L5 has bad SCR for bit 5.   L6 has bit 2 SCR bad.

You might wonder why all these SCRs have failed. The answer is a design that has zero tolerance for error. This is compounded by a total lack of warnings in maintenance manuals, schematics or other documentation for the 1130.

The bulbs used in the light display have bare wire leads. These are threaded through the pinholes in the bulb holder and wedged into a narrow slit on the outside edges of the bulb holder. If the remnant of the bulb wire is more than a few millimeters long, it can project sideways towards the adjacent bulbs. If two such wisps meet, it shorts the SCR directly to ground.

Undoubtedly, in my earlier attempts to replace bulbs, particularly when I hadn't gotten the row wedged back into the honeycomb cells, I had such wisp to wisp contacts. If one existed at the time that a signal tried to light the lamp, the SCR would be driving into a dead short. Very hard to trim short to the degree needed to avoid this risk.

I have a total of 4 SCRs which are defective on several left side PCB positions, removed them, and unhooked donor SCRs from the CE lamp positions 8 thru 3 (to have one extra on hand). At this point I ran out of energy - while it was only the early evening the lingering effects of my cold stopped me for the night.

RESTORATION OF CALCOMP 565 - BECOMING IBM 1627

Stan Paddock, a fellow member of the CHM's 1401 restoration team, found a way to undent the drum for the plotter, sufficiently to let me reassemble  it and return it to service. It is still not perfect, but much more usable and close. I will reassemble the drum on its axle and then work on evening out the surface.

I anticipate that I can sand down high spots, fill with paint and repeat until it is smooth and even enough for use as a plotter. Not sure how long it is going to take.

Restoring light display panel, gluing and oxidation removal

RESTORATION OF LIGHT DISPLAY ON 1131

I picked up the vinegar, sodium bicarbonate and salt to proceed on my deoxidation treatment of the light panel parts. In the afternoon I made a batch of each solution - vinegar/salt and bicarb - then tested on a few lights and holders.

lamps and holders soaking in salt and vinegar solution to remove corrosion

The first batch of eleven lamps worked great after the chemical dip - all of them had reliable low resistance. I put a next group of 16 lamps through the wash and discovered two of them with unacceptable high resistance after treatment.

Sodium Bicarbonate solution to neutralize acid from first dip

They were not open, but measured in the multi-kilohm range instead of the near zero resistance that a good bulb should display. Since one had the brown residue inside that is typical of a blown lamp, I took this as an indicator I should swap out the bulbs.

I have more than 100 bulbs still to pass through the baths. Removing them from the SCR board pins is a time consuming and careful process, which means I will likely spend much of today working through all the light holders, deoxidizing them and readying them for reinsertion.

Once they are all clean and any failed bulbs replaced, I have to carefully insert them on the SCR board pins. The assembly sequence for the light pedestal requires all bulb holders attached to the boards, before I swing each board into place and carefully work every lamp holder into the honeycomb cell where it belongs. Reinserting lamps will be a task for tomorrow, while the front panel is glued and sets in place on the front of the display.

Quite a few bulb holders are wedged onto the SCR board pins by the corrosion affecting both. It takes some serious work to get each such bulb loose. I lost a few bulbs which broke off at the glass envelope, but most are working out okay. Just to be safe, I ordered 48 bulbs which are electrically identical but physically smaller, which will serve in a pinch as a substitute in the bulb holder.

Replacement mini bulb at top, same light emission and electrical characteristics as bottom bulb

Surface of honeycomb that bonds with horizontal plastic bar

Side of honeycomb which bonds with vertical plastic bars inside metal case

Side of honeycomb which bonds with adjacent honeycomb segment

After visiting Tap Plastics for advice, I bought some PS 6 fast set acrylic glue to rebond the plastic honeycomb. I wasn't sure whether I needed to sand off the old adhesive first, but decided I would do that to give a flatter surface and better opportunity for bonding.

Fast set acrylic glue to repair front light panel

After sanding, I tried a dab on each of the two plastic types to see how it worked, before trying to glue the honeycomb back in place. Everything looked good, so I glued up the loose honeycomb to the front panel assembly.

Repaired front panel with honeycomb segment glued back into place

The glue specifies a wait of 24 hours to reach maximum strength, so I will wait until tomorrow to glue the entire panel back in place against the two vertical plastic bars that should hold it firm in the metal box.

I am also thinking of aids I can use to make the final assembly job easier. One of the problems is having six layers of PCBs on each side which need to be swung out of the way, so that only one at a time is being manipulated into position. I think I can make use of rubber bands to hold all the others out of play until needed. I have to find a good set of anchor points for the far end of each rubber band.

Beginning restoration of light panel on 1131

RESTORATION OF LIGHT DISPLAY ON 1131

I inspected the front panel and the loose honeycomb to decide how critical is the spacing for gluing it back into place. I also wanted a clue to the adhesive which is now failing in my machine (and that of a friend whose panel has every honeycomb loose. The solution I develop will work for both machines.

I didn't have an adhesive at hand that seemed ideal, so I decided to take the honeycomb over to Tap Plastic tomorrow to find something useful. Once I have the glue, it will be short work to add the loose honeycomb to the others.

I will still have the gap between the honeycomb vertical sides and the vertical plastic holders which keep the panel in place. I am not sure if I will glue that or not, it will depend on how quickly the glue sets, how much contact pressure it needs and whether I can position it accurately once glue is applied.

The next problem I faced was the lamp contacts themselves, or more directly the corrosion on lamp leads, lamp sockets and circuit card pins. I have some lamps which registered as open circuits when measured at the pin holes on the socket but if I make contact with the lamp wires themselves, the bulb is fine. It is corrosion on pin hole and wire that blocks a good contact.

lamp wires in pin holes, oxide on both inhibiting connections

I need some solution to remove the decades of oxide without harming any of the parts. The approach I have heard of that has promise is to use two baths in a row for each part. The first bath is a salt and vinegar solution, which will dissolve the oxide layer. The second bath is a sodium bicarbonate and water solution, which neutralizes the acid when it has done its work.

Finally, I need a way to repair and replace the bulbs in the pedestal. The bulb fits in the socket with friction holding the lead in contact with the pin hole and the pin from the PCB. The pins on the PCB, one fixed on the SCR and the other more flexible, are pushed into the pin holds of the lamp socket to make contact.

PCB with SCR and flexible pins that fit into lamp sockets

Unfortunately, there is another mating operation. The lamp sockets are pushed into the honeycomb to form a friction fit. The challenge in repairing the light pedestal is to pick the right order for the matings and figure out the mechanics of getting each PCB worth of lamps installed; the sequence of PCBs installed is a third variable in this process.

Lamp sockets press-fit into honeycomb

I did determine that the various PCBs (rows of lamps) will pivot out of the way, thus potentially I could install each row in sequence, perhaps from lowest to highest, having improved access for all but the top row.

I believe I will have the lamp sockets pressed onto the PCB pins, swing the PCB into position and use small tools to help guide and push each lamp socket into the honeycomb. This presumes I have no more brittle wires between lamp and socket, as these were breaking off whenever I disturbed them before.

The light panel must be repaired or at least set up to avoid shorts before I can safely apply power to the 1130 system and do any other work with it. My preference is a permanent fix for the panel, so that will be plan A for the next few days.

Memory jumper reconnected and system buttoned up

Not feeling like doing much at all yet.

REPAIR OF JUMPER ON MEMORY BACKPLANE

I found the location where the loose end of the jumper belongs - B4 card pin D07 - and put it back on. Fortunately, the connection was visible in past pictures which made it easy to reconnect. I then closed up the memory and put the covers back in place.

Under the weather, resting up

When I awoke Monday morning I was already feeling the cold that has bloomed to a fully annoying condition through today. I have not been out to work on the 1130, but hope to do so by the weekend at the latest.

Cleanup after VCF West, fixing system and restoring to operation at home

1053 CONSOLE PRINTER RESTORATION

A spring was lost on the left margin mechanism inside the console printer, causing the margin to shift all the way to the left when hit by the carrier during a return. I have to find a suitable spring and install it, hopefully without having to remove the cover on the printer again.

REPAIRING DISPLAY PEDESTAL

During the move back out of the Computer History Museum, while the 1131 bumped over the front door sill on its way to the truck, the light panel on the pedestal fell completely off. Now I have to confront this festering problem of the poor design and extreme difficulty replacing light bulbs.

Display pedestal after the panel had fallen off

There is one plastic honeycomb still attached, on the lower right, the rest are attached to the rear of the panel as you can see below. These honeycomb rectangles are glued to the horizontal opaque plastic bar that runs across the middle of the panel below, and the end honeycombs are glued to two vertical opaque plastic bars you can just see at the left and right side of the opening in the picture above.

The glue that holds them has failed at the two sides and for the one honeycomb. A friend's 1130 has had all the honeycombs separate. I will attempt reglue these more effectively and then share the method with my friend to allow him to rebuild his system.

Rear view of the panel

The design of the light pedestal has wide circuit boards for each row of 8 or 16 lamps. The boards have a Silicon Controlled Rectifier (SCR) for each lamp, delivering the 7.5V AC lighting power to the 3V incandescent bulbs whenever the logic signal applied to the SCR gate is a 1 (+3V) instead of 0V. Thus only half cycles of the AC power are delivered to the lamp, giving it roughly the right average power as hooking 3V DC to the lamp.

SCR boards from read side

The bulbs themselves have wire leads coming directly out of the glass envelopes, inserted in a nylon holder which is pushed over two round pins on the SCR board. The wires to the round pins can shift a bit to either side.

Bulb in its nylon holder

Inserting 16 lamps into the honeycomb requires pushing 16 of those holders while the board is in the way. Further, the board has wiring from the rest of the machine to deliver 16 logic signals, 7.5V AC and ground. It would be annoying, tedious work to insert just one, as each bulb as to be shifted and pushed into the honeycomb.

There are six rows of boards vertically stacked, thus there is almost no room in between them to touch any lamp. The task is to push 12 of these circuit boards with all their lamps so that every lamp fits in its honeycomb cell, without breaking the fragile leads on the lamps. Yes, the old lamps have leads which readily snap off right at the glass envelope with very little provocation.

This has meant that if I pull out one circuit board to replace a burned out lamp, I am very likely to break at least one other lamps leads (silently and invisibly due to the way it all fits together), so that I am no better off than before I attempted the replacement.

This design is hard to work on. The proof of that is that sometime in mid life of the 1130, the design changed. An alternate design had SLT circuit boards screwed onto the back cover of the pedestal, each board handling multiple lamps by having mulitple SCRs installed. Then, the bulb itself had wires running back to the board. This gave the customer engineer access to replace bulbs without disturbing 16 or more associated bulbs.

I am going to study this setup to figure out the best way to deal with my lamps going forward. I might implement the multi-lamp boards for the back cover, or some other approach, with the goal of maintaining a full set of working bulbs on the 1130 at all times. More later when I decide on an approach and implement it.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

Improving seek time modeling of the virtual 2310 disk drive

I noticed two defects in my virtual 2310 disk drive while doing demonstrations at VCF West over the weekend. The first will be extremely quick to fix, the second will take a bit more restructuring of the logic.

When a new disk cartridge is inserted in the drive, the drive logic has retained the last cylinder number that it had reached by seek on the previous cartridge, instead of beginning at the home cylinder.

During the boot card process, if the disk is not already at home cylinder (0), the code loops doing a seek of -1 cylinders until home is reached. I could see it counting down from the prior cylinder. The fix will reset the drive to the home cylinder when it is unloaded or loaded.

The second problem is related to the first. As the boot card looped doing the seek backwards, I could see that each seek took a couple of seconds to complete. It should be much faster. As I investigated I realized that I was modeling the disk arm 'settle' time improperly.

At the end of any arm movement (seek), the drive waits 22.5ms for the heads and arm to dampen any movement related oscillations and be stable enough to sit accurately over the intended track. I therefore waited 22.5ms before issuing the operation complete interrupt on a seek.

However, on the real drive, it works differently. As soon as the arm reaches its target cylinder, the operation complete interrupt is issued. Simultaneously, a 22.5ms settle timer is begun. If a read or write request is issued via XIO during that 22.5ms, the request is queued and does not begin until the time expires. If the timer is already at zero, the read or write begins immediately.

Thus, a program like the boot code which seeks one cylinder then waits for the op complete interrupt to sense if it is at home would have a 15ms wait before each interrupt, but I made it 37.5ms. Then, something else is wrong given the very long time.

My correction is to move the settle timer to an independent process which is fired off at the end of a seek, and to which the logic for read or write will look before beginning its operation. This will be a bit more tricky because I need to hold off storing the XIO function for polling by the GUI until the timer has elapsed.

Finally, I have to look into whatever is causing the overly slow seek delay on the backwards seek. My guess is that I am somehow rolling to a large negative number in the fpga timer for how many tracks to move, which introduces the long delay.

Possible timing error in virtual 1403 function

I believe I have a timing error in how I model the 1403, because on certain lines of a job I will see spurious characters printing, while most lines are presented correctly. The place where garbling occurs is completely repeatable - the same job gives the same bad characters in the same places every time it runs.

This is likely a case where I am giving an interrupt too early, not yet having fetched the print line, yet the software will go ahead and reuse the print buffer in core since it thinks that is now safe. The 1403 has a discrete interrupt cause triggered by having completed the fetch of a print line - I should examine this section of my logic in the fpga.

SETTING UP 1130 SYSTEM IN ITS OLD HOME

The various boxes of the 1130 are rolled into place in the workshop but not yet wired and bolted together, IO units are not cabled and the power connector has not been swapped back to the L6-20 to match my outlets. I can't power up until I complete my repairs of the light panel on the display pedestal, thus have not been in a big hurry to cable, wire and bolt.

The memory blister had to be detached for transportation, separating the core memory from the rest of the system. I have to bolt the two frames together than do some wiring. Two power wiring harnesses are connected to terminal blocks, and three flat ribbon cables are routed to the C gate and plugged into the top row of the memory compartments.

By late afternoon, the frames were bolted together and I had routed the cables to the memory blister, but not yet attached them. I also inspected the disk heads. I can see wisps of ferric oxide on the heads, which is normal wear as these are used. I will clean these with 99% isopropyl alcohol and kimwipes before I put the drive back into service.

Disk head with a bit of oxide to clean off

After dinner, I went out to the workshop and reconnected the power and signal cables to the memory.  On top of that, I removed the L6-30 plug and put back the L6-20 that fits to my house power. Those done, I noticed that one of my two jumpers I recently added to the memory backplane had come loose. I will research this before restoring it and closing up the machine.

Tomorrow gets the jumper fixed, doors all back in place and the disk heads cleaned, leaving only the light panel on the pedestal to restore.

Exhibited 1130 systems at VCF West, back home and recovering

VCF WEST EXHIBITION

I picked up a lift gate truck from Hengehold in Los Altos, drove it home and met some people who volunteered to help me move it all. We loaded up everything, strapped it down, and drove very slowly and carefully to CHM where we could unload and set it all up.

The bumping of the wheels rolling into the freight elevator caused the front panel display lights to slide outward at the front, dislodging the lights. I was able to show the machine for the weekend by using blank punched cards as insulators to keep the loose circuit boards and lights from shorting each other out.

It was a long two days of running various Fortran compile and execution jobs, Assembly jobs, disk directory listings, the Lunar Lander game and other examples. I used the virtual 1442 card reader but most times ran with both the inboard real disk and the virtual 2310 disk. About half the time I had booted from the internal cartridge, the rest using virtual cartridge images.

I met many people I knew from the past, either from various 1130 and classic computing related internet groups or in person. Brian Knittel, who built the 1130 simulator and owns another running 1130 system, visited on Sunday and ran some software on the 1130.

I was able to speak to many visitors, ranging from people who worked with the 1130 years ago to tech enthusiasts who were seeing one for the first time. Met some former IBMers who either used the system or in some cases designed or coded parts of the system.

The show had many other outstanding exhibits, both creative replicas and lovingly restored vintage machines. I knew the VCF judges were going to award ribbons to some exhibits but had little expectation of winning one myself. To my surprise, however, my 1130 received a first place award for the minicomputer/mainframe category and I was given a second place award in the replica category.

Friends including Brian helped break down the system, pack it up and get it on the truck. The trip back down the freight elevator finished the job that the first trip had started on the light panel. The front panel and its honeycomb plastic assembly is entirely separated, with the circuit cards and lights of the display pedestal hanging loose.

It is all repairable, just a bit of a pain. It always has been, a design flaw that makes replacement of bulbs a very tedious and nearly impossible task, so my repair will address this problem once and for all.

By 7PM, the machine was back in the workshop, not yet reassembled but safe and sound. The replica was in the back yard, heading to its temporary home in the shed. We were all a bit exhausted and will need Monday as well to fully recover.

SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130

Issues noted to be addressed after the VCF

When I switch disk cartridges in the virtual 2310 disk drive and boot, the FPGA and GUI think the disk is still on its last cylinder position, thus the boot program has to step backwards one cylinder at a time until it gets to the home cylinder (0). I can change the logic so that unmounting a cartridge restores the arm to cylinder zero.

Also, the speed of the seek is distressingly slow. I think I have a problem with my timing logic to model seeks, in particular the 'settle' time that is applied after a movement. I am withholding the op complete interrupt until the settle time has passed, but I think that a real drive will interrupt as soon as movement stops.

Therefore, the settle time is only applied to block read or write operations subsequent to a seek. I have to restructure the logic to make the settle counter independent, kicked off by the end of a seek and then have the read/write logic wait if the counter hasn't reached zero.

In practice, the disk performed indistinguishably from the real one when running real 1130 job streams. It didn't affect the exhibition at all.

My virtual 1403 will get strange bursts of garbage in certain lines - but totally repeatable on the same jobs. For example, the header of each page with a //JOB has some random 3 characters printing. The header line of a dump slet program has some random 3 characters, but the data lines are perfect.

This tells me I have a timing problem with my modeling - some code is reusing the print buffer before it should, because of something I am doing wrong. With adjustments, this will work fine as well.

Replica completed, prepared to move to CHM tomorrow for VCF West

1442 CARD READER/PUNCH RESTORATION

I tried to boot from the 1442 but the machine is acting cranky, giving read checks on the boot card. I might be able to loosen it up by doing this many many times if I have the patience tomorrow morning, otherwise I might not be able to use it during the exhibition.

PREPARATION FOR VCF WEST EXHIBITION

I developed a couple of hand loop programs to use with the replica and the real 1130, to illustrate how the machine works. I also ran Mike Albaugh's art printing program which seemed to run fine - he may use my system and his program during the show this weekend.

This afternoon, I inventoried everything I will be bringing to VCF-W which I will turn into checklists for packing, setup, and removal time. I decided not to bring oscilloscopes, meters or other tools, because there will be surfeit of them at the show.

COMPLETING REPLICA COSMETICS

Once the electronics were ready to install, I had to mount the display pedestal on the base. This was a challenging task. I had to cut tails off the pedestal base in order to slide the pedestal into place. I also had to cut the wood stands inside the pedestal posts so exactly 1 5/8" stuck out beyond the metal post.

With the pedestal in place, I put a selectric mechanism on the base, laid the console entry switches in their place, and began to connect things up underneath. I had to suspect the fpga and its extension board on the back of the gray cover just below the pedestal base, then lay the keyboard assembly onto the frame.

Wires were routed and then I did the ticklish assembly of the gray metal cover over the keyboard, avoiding damaging or shorting my circuit boards hanging off the rear of the keyboard assembly.
Next was the placement of the power supplies, which need to be up high near the board or I would need to lengthen the wiring to the connectors to allow the power supplies to sit at the bottom of the frame.

Replica before power-on test

Finally, everything was in place and hooked up - time to do a power on test and validate the connections are all correct. Unfortunately, I had swapped the +12 and the +20 connectors to the keyboard aux board - the power supply couldn't come on at all because of a short circuit, but I think it damaged something before I realized what happened.

The processor works but I don't have any lights - pretty crucial to the replica exhibition. There are two cases here - 1) I blew something on the aux board or on the fpga itself, but the light display circuits in the pedestal are still okay. or 2) the pedestal circuits got fried. If the latter, it is game over, can't be fixed in time and the replica stays here.

I do have a second fpga board and can reroute the lights to avoid using the aux board at all. If we are dealing with case 1, then I will have lights and a replica at the show. Time to reroute the LED signals to one of the connectors on the fpga board itself. I moved them, generated a new bitstream, and loaded that in my backup Nexys2 board.

I carefully hooked the new board up to the console entry switches, pushbuttons, display pedestal and rotary mode switch, then fired up the system. I was ecstatic to discover that I have lights, buttons and a good replica.

We will need to be very careful in moving the replica to avoid damaging or undoing connections. Just as with the real 1130, kid gloves are needed.

CONNECTING UP AND TESTING REPLICA

I got the rotary switch working, but haven't got the display lights running yet. After they work, the remaining challenge is the input board and keyboard I2C link. If that all works, I can button up the unit into the frame and be ready to roll.

The display lights are now running nicely and I moved on to testing the console entry switches. Each test requires a run through the Xilinx ISE tool chain, which takes more than 30 minutes to complete. Cobwebs are growing on me as I wait around for each little test.

Good console entry switches, leaving only the testing of the input board. This will be a bit funky because the board I am using has only one of the two multiplexor chips installed, which might require me to change the logic in the fpga that cycles through the various chips.

I decided to extend the cabling from the keyboard aux board, for two reasons. First, the existing solid wires snap off the connectors too easily, but more importantly the length must be increased so that I can locate the FPGA back under the pedestal base. Quite a bit of cutting, soldering, connector preparation and insulating, but it was eventually done.

Now it is time to wire in the input board to the fpga extension card and to power. If I can get these to work right, I will have everything I need for the replica to work as it used to. I intend to wire up the power switch to the power supply, replacing the temporary switch I was using.

The first shot at running everything did not pick up the buttons - probably because my logic for reading the multiplexors was written for four chips - two on the original input board, one on the keyboard board, and one for the console entry switches. With two missing, my state machines are probably stalling because of the lack of response.

I hope that the board I used was wired for the chip address I expect - if so, then my modification to the logic to jump only between chips 1 and 3 should work. If the address is not what I expect, I may have to test the board to verify the actual address in use and modify the logic accordingly. Thirty minute wait until the test could be run.

I am still getting nothing on the link from the input board and keyboard aux board multiplexors. I could wire the six switches to open inputs on the fpga itself, bypassing the need to get the input board working. Since I don't have a debounce anyway, it made sense to just go with the direct wiring method for now.

Once this tested out good, my replica pedestal was ready to mount on the base and to put it all together. This is ready for transport to the festival.