Designed replacement 5806223 card - device controller logic for the 1627 plotter attached to an IBM 1130

BASED ON BREADBOARDING TESTS, I DEVELOPED A COMPLETE SCHEMATIC

I tested my plan to use monostable oscillator chips to get the same behavior as IBM's AC triggered gates. IBM uses these, which emit a short pulse at the falling edge of one signal as long as the enabling signal is also on. This allows IBM to interface to external devices without the challenges of metastable behavior that can occur with clocked digital electronics.'

The IBM gate emits the pulse and it turns a flipflop on or off, with no clock on the flipflop and no relationship to the 1130 system clock. In addition to its use with signals outside the 'clock domain', it is also widely used to activate flipflops in many situation inside the CPU logic. 

Its primary use on this card is to set flipflops for particular bits that were set by the user as part of their XIO Write instruction. The gate uses the bits as the enabling input, and the falling edge that activates it is from a NAND gate that turns on (goes low) when we have an XIO Write to Area 5 (the plotter) at clock step T6. 

The controller logic uses pairs of single shots in series, which emit a low signal for a fixed duration. For movement of the pen on the paper, the first SS fires for 2.5 ms when its input goes low. As its output goes low for that first SS, it sets the busy condition. The inverted (high) output of the first SS is hooked to the second SS, so that when the first SS time period expires, the output goes low and triggers the second SS for another 2.5 ms. 

As the second SS goes low, it triggers an AC gate to reset the that held the pen motion bits. The low state of the second SS also drives the busy status of the plotter. When the second SS interval expires, the busy condition goes off; the falling edge triggers another AC gate to turn on a flipflop called Response. When Response is on, it drives a request for an interrupt on level 3. 

As you can see, the design depends very heavily on these falling edge detecting gates. I know that the monostable oscillator (single shot) chips have multiple control inputs one of which can act as an enable. Thus, using the 74LS122 with the B bit as the enable and the NAND gate for the XIO write as the trigger will produce a pulse in the range of 30-35ns if enable is high when the trigger edge drops. 

I also made use of 74LS74 flipflops but not in the clocked style they are normally used. I used the asynchronous set input to turn them on when my 74LS122 produces its pulse, and use the async clear input to turn them off when the second SS expires. This takes up more real estate than modern combinatorial gates and flipflops, but it behaves as the IBM circuit does. There is a NAND gate for the XIO Write, a 74LS122 to act as the AC trigger gate, and a 74LS74 flipflop that is set by the pulse from the trigger. 

FAIRLY DENSE BOARD - 22 INTEGRATE CIRCUITS PLUS PASSIVE COMPONENTS

Surface mount chips give me two flipflops per package and four NAND gates per component, but 74LS122 is its own chip. Overall I need ten chips for the single shots, plus four chips for the flipflops. The remainder are the gates that detect when an XIO Sense DSW is issued to feed the appropriate status bits, to detect the XIO Write when we are commanded to move the plotter, and all the other functions. 

The movement commands set for flipflops for up, down, left and right. These use the pair of SS with 2.5ms timing. In addition, the programmer can raise the pen off the paper or lower it down. Those operations take two more flipflops and their own pair of SS since they require 50ms per SS due to the slower mechanical motion. The four SS with fixed times (2.5 or 50ms) require an external resistor and capacitor for each to determine the timing. The SS acting as AC gates operate without external components. 

The 1627 is driven by a 12V signal that is normally high, but pulled to ground for the 2.5 or 50ms of the first SS in a pair. This trips circuitry inside the 1627 to advance the stepper motors one position. This board has open collector gates to drive those signals, with pullup resistors hooked to the 12V power rail. The outputs to the IBM 1130 are inverted logic signals -Req IL3, -DSW Bit 0, -DSW Bit 14 and -DSW Bit 15. These are pulled low by open collector gates on this board. The pullup is done in the 1130 not on this card so no resistors are needed for those outputs.

The design checks for a powered up plotter by sensing the -24V supply from the device. This is hooked to a resistor voltage divider with the upper end hooked to +12V. Thus, the condition being sensed is either 12V if the plotter is turned off or a negative voltage if it is turned on. Modern gates don't like such voltages, so I whipped up a circuit that produces either 5V or barely negative. Using a diode and current limiting resistance ensure that the gate sensing this won't be damaged by the presented voltages on its input. 

Finally, the 5V logic chips on the board are powered by a LVDO voltage regulator that drops the 12V input on the card down to the 5V we require. 

MECHANICAL CONNECTION - SACRIFICIAL DOUBLE WIDE SLT CARD

The double wide SLT card is 3" high and 3.25" wide, with its twin 2x12 sockets that plug into the backplane. My PCB is a bit smaller and will mount atop a card that has been cleared of components and readied for attachment. Small jumpers are soldered to the PCB and the connectors of the board. 

FINALIZING THE PCB LAYOUT WHILE I BREADBOARD AND TEST THE DESIGN

I am mostly done laying out the PCB with the circuitry. When I am comfortable that it will work properly I will send it out to the fab to make five boards. During the wait I will buy all the SOIC-14 sized ICs and other components to solder on the board. 

I will continue to put together DIP sized chips to verify each part of the design before committing to build the cards, using my breadboard testing gear and monitoring timing on the scope. 

Fixed pins on backplane allowing card insertion; working with another museum on a replacement card for 1627 plotters

BENT PINS STRAIGHTENED ENOUGH TO LET THE SLT CARD SNAP INTO THE SOCKET

I worked on the pins slightly and was able to insert the card properly into the slot that had the damage. I was worried that the pins might have broken off but I did manipulate them as gently as I could, as few times, which ultimately succeeded. This resolves one of the mechanical issues that was outstanding for the restoration. 

1627 PEN PLOTTER CONTROLLER LOGIC IS ONE SLT CARD - 5806223 - THAT NOBODY HAS

I know of two museums that have plotters but lack the card that interfaces it to the 1130. I too have a 1627 (needing restoration) but lack the card. This was the subject of recent conversations with peers restoring systems in Europe.

The 6223 card is a double card, taking two slots vertically on the backplane. The ALD pages identify the functionality of the card, which should be relatively easy to replace. Ideally the solution will plug into the same backplane slots as the IBM card, with bonus points if it has a compatible appearance. 

This logic makes use of the IBM edge triggered (what they call AC trigger) gates and flipflops, which don't have any modern equivalent gate. I am exploring various circuits using (relatively) modern TTL gates that might fit in the footprint of the 6223 card. Another option is to use a mini FPGA board, several of which will fit with room to spare. This allows room for some interface circuits to deal with the 12V, -3V, -24V and other funky signal voltages present when working with the 1130 and 1627. 

I began breadboarding and testing circuits using 74LS121 monostable oscillators (one shots) to act as the IBM edge triggered gates, turning 74LS74 flipflops on and off. I will continue to build out the circuit using these SSI and MSI TTL devices, then try to fit them all within the area of the 6223 card surface using surface mount chips. If that works I can whip up a PCB design and order the parts. 

The FPGA version is much easier, the only challenge is keeping the height of the FPGA board small enough so that the card can fit side by side with ordinary SLT cards in the gate. 

Mechanical work on VCF 1130 today

TESTING DEVICE CONTROLLER LOGIC WHEN I FOUND DAMAGE TO THE BACKPLANE

I pulled a card and couldn't insert it into the backplane reliably, so when I inspected I found that two pins were bent. The plastic cover over the card end had cracked and had other damage that led to this. While I bent them back correctly to the eye, cards still won't snap in. This will be fun, I can see. 

I will continue to adjust the pins and work on getting the card to seat properly. I replaced the plastic cover from a spare SLT card, manually marking the card number. Hopefully I will get everything repaired. 

FINALLY REMOVED BLOWER CAGE FROM MOTOR SHAFT

The blower motor which produces the high volume of air through a HEPA level filter to float the recording heads over the disk platter was not working. I identified that one of the wires to the motor was an open circuit. Dismounting the motor from the drive was easy, but the blower cage and rotor was almost welded to the motor shaft. 

The removal of the setscrew should have allowed the rotor to slide off, but it was almost beyond my ability to get it off.  Since the hub was inside the rotor cage, a traditional pulley would not fit inside. I had to partially disassemble the motor to be able to put enough torque on the shaft to help dislodge it.

I had to scrape some corrosion off the end of the shaft and use clock oil in order to get it to move better. Finally with some vice grips on the hub and lots of effort, I got the shaft to come out. Now the motor needs to be repaired or replaced. 

LOOKING FOR EASY FIX FIRST

I was hoping that I had a break in the wires, as they were shielded inside woven metal and an outer plastic cover. Alas, I confirmed that the break is inside the motor. All my inspections failed to uncover an obvious point of the failure, thus there is no hope of a surgical fix. 

THINK I FOUND A CLOSE MATCH ON EBAY TO REPLACE THE DEAD MOTOR

The motor was built by Robbins & Myer. The data plate show that it is a single phase motor, 1/30 horsepower, turning at 3450 RPM. The frame type is F26 which indicates the physical dimensions of the motor and shaft. 

I looked on eBay and found a very similar motor advertised. It is the same frame type F26, spins at 3350 RPM which is close enough as this only moves air. The other difference I see is the type is KP whereas the disk drive motor is KS. I suspect the difference in speed is the reason the type varies.

 

According to the listing, this was pulled from a Bell & Howell 16mm projector, but is working. It appears to be a nice drop in replacement and I should receive it within the week. 

2310 emulation write module rewritten and successfully simulated

BUS WRITE STEPS THROUGH A FEW STATES WHEN THE WRITE GATE IS ACTIVATED

Write gate signal starts a write. The erase and write heads are turned on and the drive begins sending out the 720 KHz  clock as it is writing each bit cell. This should continue for the remainder of the sector. The state machine stages are idle, preamble, sync word, data write, and postamble. 

The preamble is 250 microseconds of zero bit values written to the drive. Each bit value is recorded with one clock bit and one data bit each in a 720 nanosecond interval. Recording a bit is accomplished by reversing the flux of the write head. Thus in each clock bit interval the flux is reversed, but in the data interval it only reverses if the bit value is 1, otherwise the flux remains unaltered. 

The preamble is thus 250 us of alternating flux reversal and no flux reversal (writing zero bits). The drive synchronizes a kind of phase locked loop to the clock bits during the preamble thus it can know which pulse is a clock bit and which pulse is a data bit value of 1. The drive and the controller logic now sees clearly delineated clock and data bits, but the controller must also know which bit cell is the start of each word on the disk. 

The sync word serves this purpose. A flux reversal during the data interval signals a 1 bit and the end of the preamble. The 1130 architecture is 16 bit words, but the 2310 writes these on disk as 20 bits, the first 16 are the data and the next four are a check pattern to detect errors reading the disk. Every time a 1 data value is written in the word, a two bit counter is stepped. 

The goal is that the counter will be at zero at the end of a valid word. Thus if a word already has four, eight, twelve or sixteen bits that are 1, the four check bits are written as 0000. However, if the two bit counter is not yet zero, the drive will write a 1 bit and bump the counter until it reaches zero. Thus with three bits that are 1, the check bits are 1000. With two bits in the word that are 1, the check bits are 1100. With one bit that is 1, the check bits are 1110. 

The sync stage will write 11110 which is for a word of 0000000000000001 with the check pattern 1110 appended. Following this the controller is synchronized on the start of each word - the next bit cell is the first bit of data word 1 of the sector and the state machine moves to the data stage.

In the data stage, we collect the bit values coming from the controller into groups of 16, then absorb and validate the four check bits. This 16 bit value is written to the DRAM of the emulator and we start with the next word. A sector on the 2310 is up to 321 words long, so we loop while counting words. If the write gate is dropped by the controller (writing a short sector) then we move immediately to the final postamble stage, otherwise we move there are the count of 321 is completed.

The postamble writes more words of zero until we reach the end of the sector. Once the new sector arrives the state machine goes back to idle and waits for a new write gate signal. 

TRICKY PART IS DEALING WITH THE CHECK BITS WHICH ARE NOT STORED ON DRAM

The configuration values for the emulator are set for 16 bit words, which ignores the 4 check bits that occur after each word. In the RK-05, there are no check bits after each word so the logic of the emulator is directly based on bit and word counts for a sector. A checksum word follows all the data words on the RK-05, a different and improved error detection scheme from that of the 2310. 

I have to introduce separate action that does not step certain counters during the final four bit cells, while ensuring that the emulator doesn't stop the read or write prematurely because it thinks all the bits have arrived correctly. For example, the emulator calculates a sector as 5, 136 bit cells long, not counting preamble, sync or postamble. 

If you use the bit cell duration of 1.4 microseconds with that value, you would consider a sector complete at 7.19 milliseconds. However, we really need 8.99 milliseconds because of all the check bits. Adding in the duration of the sector pulse before the read/write begins, the time for the sync word and the 250 us of preamble, you are up almost 9.4 ms out of the nominal 10 ms duration of a sector. The postamble at the nominal rotation speed would consist of almost 460 zeroes - around 638 milliseconds. 

SIMULATION RUN AND ALL TIMINGS AND BEHAVIORS VERIFIED

l completed a version that ignores the check bits written by the disk controller logic in the 1130 system. That seemed to grab the data properly. I then added an ECC testing circuit that would turn on a ECC_error latch during the write and leave it on until the next write begins. It will be routed out to the Fault indicator on the front panel. 

no hurricane damage at workshop and home

HURRICANE MILTON PASSED OVER US, THE CENTER ABOUT TEN MILES NORTH

My home had no water entering or other damage. The condo buildings had one palm tree knocked down, falling into an empty visitor's parking spot. Electricity and water remained on throughout the storm. It was less noisy inside than the hurricanes of two years ago. When the eye was overhead and everything got quiet, I was able to walk the dog. 

I drove to my workshop where I verified that not one drop of water entered under the regular or rolling door, the building was undamaged and the air conditioning remained on. This is good news, even if I did spend an hour lifting boxes of paper and other items from the floor to protect them from possible water damage, plus spreading covers over machinery and special documentation. 

Redesigned the sector and index pulse generator module - either uses real drive pulses or generates emulated pulses

GOAL OF MODIFICATION

I want a setting for the emulator where it can pass along the pulses from the physical 2310 drive in the IBM 1130, as well as operating without a drive by producing its own pulses. With a physical drive switched on, the disk arm will seek at the same time that the emulator virtually seeks. 

The disk controller logic in the IBM 1130 is wired to the physical 2310 drive, but the emulator is also tapped into the signals. Thus, when the controller tells the real disk arm to move forward one track, the emulator will see that and also advance the virtual track number itself. 

The disk controller sees the sector and index pulses, which it uses to determine when to turn on the read or write electronics of the physical drive. The emulator is passing along the physical drive's pulses so that both are in lock step. Thus when the controller sees it has entered the desired disk sector, it begins to read the clock and data lines from the physical drive (for a read) or controls the write data line when writing to the physical drive.

The heads are mechanically blocked from lowering onto the spinning disk surface of the physical drive. However, the controller is sent a signal that the heads have loaded and the drive becomes ready for access. 

As the write data line is modulated, the head is trying to record on the disk but it is very far above the platter and has no effect. The emulator is tapping this signal, however, capturing the bit pattern to write onto our virtual disk cartridge in the DRAM of the FPGA. 

As the drive enables the heads to sense the clock and data pulses from the spinning platter, no signal is detected since the head is too far above the surface. The emulator injects the signals into the line as if the disk head amplifier had read them, thus giving the 1130 and its disk controller the stream of bits it would have seen if using the physical disk in its traditional way. 

I set up a control signal, real_sectors, that tells this module whether to shadow the physical drive or to produce its own pulses. I might connect this to a switch on the RK-05 emulator or make it a configuration parameter. 

MADE CHANGES AND SIMULATED TO VERIFY OPERATION

The simulation shows perfectly shaped and timed pulses generated in both cases - real drive or emulated. My last remaining design task is to finish the sector write logic, where we capture the data being written from the 1130 to the drive. The emulator logic appears to correctly model the disk drive in all aspects. 

The top level module that ties together all the functional modules must be changed since we have different signals connected to a 2310 than to an RK-05. The various functional modules have changes in their input-output which have to be reflected and meshed together. 

The software in the Raspberry Pi needs updating to reflect our 2310 specific functionality. Too, I want to make use of the disk format files from simH versions of the IBM 1130, which likely differ from the RK-05 format files used by George Wiley's emulator. 

Seek logic simulated for 2310 emulation, modified version of George Wiley's RK-05 emulator

SEEK DIFFERENCES BETWEEN 2310 AND RK-05

The RK-05 seek interface sends a cylinder number and pulses a strobe signal, after which the drive either responds with an address accepted or an invalid address response signal. The timing for when the seek ends varies and another can be accepted is different from the 2310 as well. 

The 2310 seek interface sends a direction, a step size and pulses a go signal. The step is one or two tracks and direction is forward or reverse. The drive reports an access-ready signal and a home signal. Home informs the controller that the arm is at track 0, the outer edge of the disk platter. Access ready goes off 5 ms after the access go pulse is sent and turns back on 10 ms after that, to reflect the 14.6 ms max time for arm movement. 

Thus, the controller logic in the IBM 1130 will take a request for a relative movement of some number of tracks and convert it into multiple commands to the disk, using 1 and 2 track movements, until it is complete. If the arm reaches 0 and the command attempts to move in reverse, the arm remains at 0. Similarly, if the request for movement attempts to move the arm past 202, the last track, the arm remains at 202. 

The RK-05 emulator turns on an LED indicator called 'on cylinder' as part of its seek emulation. I decided to use that inversely, as a seek in process indicator. To convert the action to human timescale, my logic turns on the indicator for a quarter second after each seek action. Since the 2310 moves in bursts of 1 or 2 tracks, it will go on steady on longer movements. A full seek across the cartridge can be 1.5 seconds long, but a one to two track movement is 15ms and the LED will be on for 250ms. 

MODIFIED LOGIC AND SIMULATED SUCCESSFULLY

The logic is substantially different than for the RK-05. I simulated it with various conditions to verify both the behavior and the timing of every action. I was very pleased with the results and consider this part complete. 

Design decisions for 2310 disk emulator concerning sector and index pulses

MODIFYING GEORGE WILEY'S RK-05 EMULATOR FOR 2310 EMULATION

The RK-05 disk is derived from the IBM 2310, but with quite a few changes and improvements, such as ability to issue a seek in one command to any cylinder, double capacity, and use of sector checksum instead of word by word check bits. 

I have been simulating my changes and making good progress on the changes. Read emulation is complete and I am working on the write emulation. I had modified the sector and index generation module, successfully simulating it, but now I am considering changes to the module. 

ORIGINAL DISK EMULATOR OBJECTIVE CONCERNING SECTOR/INDEX AND SEEKS

My approach for the disk emulator I designed from scratch used the physical disk drive as the source of the sector and index pulses. It blocked the disk heads from loading down on the disk surface but otherwise let the drive accept and execute every command. Thus the user would hear the whirl of the disk plus the grunting of the disk arm as it seeks in and out. 

The RK-05 emulator is a complete substitute for a drive - it is attached to the controller without any physical disk present. That has big advantages except that it doesn't give the sounds and senses of my original design. 

ALTERNATIVES I AM CONSIDERING

I am therefore considering a rewrite of the sector and index generation module. I see three alternatives:

1. Go back to my original approach and rely on the physical drive for the pulses
2. Use the current generation module, which means the physical drive stays turned off
3. Create a hybrid that uses the physical drive but has an option for pure simulation

HURRICANE HEADING TOWARDS ME WHICH IS LIMITING MY SHOP TIME

Hurricane Milton will pass by me later this week, which means that I have had lots of preparation to do. I moved all the outdoor furniture from my balcony and am securing the common areas of the condo since, I am a COA board member. We are stocking on some food that doesn't require refrigeration or power. In the worst of the past hurricanes we only had a six hour power outage one time, but I have to prepare just in case. 

Finally, I went through the workshop and moved up off the ground all items that might be damaged by water. There is no record of flooding in the building that houses my workshop, but even water blown in under the doors by hurricane force winds would be an issue. 

My shop has several dozen six foot tables where most supplies, equipment and tools are located, but there are a few things I stored under tables. Most at risk are the boxes of printer and typewriter paper, blank cards and paper tape rolls. I also have many padded blankets from the move out here that I use when I am kneeling or lying on the ground working inside machinery - these must be moved up. 

Capturing disk writes with emulator easier than expected

RK-05 DISKS WRITE STREAMS MUST BE TREATED LIKE INCOMING SERIAL STREAMS

Incoming streams clocked by some remote hardware, asynchronously to the receiving system, are typically detected by sampling through a window of multiple time periods looking for the point when the one bit will be present. Since a zero bit is the absence of a pulse, one has to wait to be certain that we are not just dealing with a bit of jitter delaying a one bit.

Serial receivers watch the start bits to select the best sampling point, midway inside the one that arrives as the start bit. It then uses its oscillator, set to the expected (baud) rate, to sample for subsequent (data) bits. At the end of the character, everything is reset and we wait again for the start bit. 

The disk stream from the RK-05 disk controllers is clocked in the controller, not the RK-05 disk drive. The data bit pulse if one, or absence of a data bit for zero, has to be detected based on the expectation for when it will arrive. The RK-05 emulator checks across 27 clock intervals looking for a pulse. It is designed to expect jitter from the controller and wants to see the pulse in the range of 200ns to 500ns with the double data rate 2.88MHz clock of the RK-05. Our 2310 equivalent would be 400 to 1000 ns. 

IBM 2310 DISK DRIVE CLOCKS ITSELF AND EMITS KEY SIGNAL TO THE CPU

The design of the 2310 disk drive is different enough that this is no longer needed. An oscillator onboard the disk drive provides the 1.44 MHz rate at which flux reversals are recorded to produce the clock and data pulses. Further, the drive will divide this in half and therefore indicate which half of the bit cell it is dealing with - the clock or the data bit. 

WRITE DATA LINE TO DRIVE IS NOT SENDING PULSES, JUST LEVELS

The way the drive writes is to toggle the current flipflop for the heads at the rising edge of the 1.44 MHz clock when the -Write Data line is low. It is also producing -Write Clock Phase B which identifies the half of the bit cell being processed. The actual creation of a pulse is done in the drive, so the controller just sets a steady level for the data bit value. 

The controller logic in the CPU uses this circuit below to output the value of -Write Data which then flips the head magnetic flux at the 1.44MHz clock edge. The circuit will always cause a flip during the clock portion of the bit cell, but the remaining gates determine when a flip (signifying a one bit) should occur during the data portion of the cell. 

Each word on disk is 20 bit cells long, the first 16 of which are the values of the bits from the IBM 1130 and the last four are a check bit method that writes a 1 it until the total count of 1 bits in the 20 bit field is an even multiple of four. Bit Counter E is on when we are processing the four check bits. As long as the total count is not yet zero modulo 4, a one bit is written out. Once the count gets to zero, the remaining bits are zero. 

When we are not in Bit Counter E state, we are shifting the 16 bits from the CPU out of a shift register, the low order one is bit 15, so when +File Bit 15 is on we write a one bit in the data part of the cell, otherwise zero.

The data is shifted in the register when in the clock part of the bit cell, right when the -Write Clock Ph B signal goes high at the start of the data part. This is occurring while the clock pulse is being toggled in the write head, the next rising edge coming almost 700 ns later. This is plenty of time for the data to shift and be steady at +File Bit 15 before the -Write Data is sampled again to flip or not flip the flux. 

I have to capture the state of the -Write Data line after the shift has occurred but before the -Write Clock Ph B goes low again to start the clock part of the bit cell. All I need is to wait for about 400 ns, which is 16 clock cycles of the FPGA. This is much easier than trying to find the pulse amid a window. 

Console printer set in place on the 1130 - found I need to adjust the pushbuttons

COVER AND FACEPLATE INSTALLED ON THE 1053

I scraped away some degraded sound insulation inside the cover before putting it back on. The printer was easy (but cumbersome) to slide onto place atop the 1130. Tilting it up allowed the faceplate to be fastened, then the tab set/clear rod had to be attached to the faceplate lever to wrap things up.

I did some more testing of the typing. I had found something that was contributing to sporadic failure to fully stop at the left margin; it was adjusted and CR seems quite reliable now. I also worked on the index (line feed) operation which had been sporadically doing a double feed or not feeding fully. This seemed to be some residual stale lubricant, so I flushed and reoiled this part of the machine. Behavior much better. 

FRONT PUSHBUTTONS DON'T WORK

However, when I pushed the three plastic buttons on the faceplate - Tab, Space and Return - they did not actuate the button mechanisms on the typewriter. They didn't move those far enough. I can adjust the parts on the typewriter outward to fix this, but I will have to remove the tab set/clear rod and faceplate temporarily.

This exposes a hole in the maintenance documentation. The 1053 maintenance manual covers most adjustments for the various flavors of the I/O Selectric including the printer only models like this, but does not discuss the faceplate which is unique to the 1130. The 1130 maintenance manuals say nothing about the adjustment procedures to make the plastic pushbuttons work properly. 

Modifying George Wiley's RK-05 emulator to emulate IBM 1130's 2310 disk drive and 2315 disk cartridge

GOAL

I want an emulator to install on any IBM 1130 which will emulate the internal disk drive, allowing a file on an SD card to be opened and used as if it were a real 2315 disk cartridge. This should allow the physical internal disk to spin up and move the disk arms, providing realistic sounds, but avoid lowering the nearly irreplaceable disk heads onto the rotating disk surface. 

My emulator will emit the sector pulses every 5 milliseconds to indicate the start of a new sector, although 1130 disk sectors are pairs of physical sectors thus 10 milliseconds long. It will respond appropriately when the controller requests a movement of the arm radially to a new sector. Then it will produce a string of bits that match what the real disk drive would produce if it was reading a sector. When the controller is writing to a sector, it will watch the stream, remove the 0 words and sync pulse, then grab each 16 bit word from the 20 bit stream produced by the controller. 

I store the contents of a disk cartridge in a file, organized in the same format as used by the simh based IBM 1130 simulator, thus virtual cartridges can be interchanged between simulators and real 1130 systems. The cartridge being accessed is stored in RAM on the FPGA on the emulator but transferred to and from an SD card on a processor board linked via a Serial Peripheral Interface (SPI) link to the FPGA. The SD card can hold a library of virtual disk cartridges (IBM named these the 2315 cartridge). 

PAST ISSUES 

I attempted this with development boards centered on single chip solutions (System on a Chip - SoC) which required complex interconnect channels between the ARM processors and the FPGA inside the SoC. The most serious issue is that the on-board DRAM are connected to the ARM side, which requires the FPGA logic to use interconnects to reach memory. I could never get the interconnects all activated by modifying the boot loader, in spite of every published example, YouTube video and published Intel/Altera document. 

APPROACH USED BY GEORGE

George on the other hand installed a discrete FPGA chip and a discrete Raspberry Pi Pico processor on his board. The two communicate using a SPI link. It is slightly different from my approach - I had been using the real Sector and Index pulses from the physical drive inside the IBM 1130, whereas he just generates them virtually. It has the great advantage that it works so any gremlins concerning the interaction of the C code on the Pi and the logic in the FPGA are already worked out.

IMPORTANT DIFFERENCES BETWEEN THE RK-05 AND THE 2310

The recording frequency of the IBM 2310 drive is half of that on the RK-05, 720 KHz versus 1.44 MHz. A 2315 cartridge holds 512 KW of 16 bit data, while the RK-05 cartridges are roughly twice the size. IBM invented the disk drive, evolving it from Ramac through 1300 series to the 23xx series for the early 1960s computers. 

They licensed the technology to many minicomputer and mainframe vendors, who evolved it but retained key aspects such as the 14" disk platter size and 203 physical cylinders. DEC, Diablo and others immediately doubled the bit density by increasing the frequency (with new ceramic heads). 

The RK-05 has eight or twelve sectors, which are all passed along to the DEC computer unaltered. The 2310 has eight physical sector slits but the 1130 controller passes along every other pulse, thus logically dividing the disk into four pie shaped sectors. The controller still needs 8 pulses but the emulator logic to fetch a sector of data from DRAM and feed it to the controller must deal with the 4 larger sectors instead. 

The RK-05 and every other drive derived from the 2310 will accept an absolute cylinder address and seek in one operation out to the intended location The 2310, on the other hand, will only seek one or two cylinders at a time (relative seek), either towards cylinder 203 or towards cylinder 0 which is called Home. 

My changes have to track where the 2310 arm is sitting now, so that when I get a relative seek from the IBM 1130 I have to convert it to an absolute seek for the emulator logic so it can get to the correct file contents based on the target cylinder. I also have to emit the Home signal when we are at cylinder zero as that is the only way that software on the 1130 can know the current cylinder number when the software starts using the disk. 

The 2310 and its derivatives all use the same MFM-ish recording scheme - emitting a clock pulse in every bit cell but only emitting a data pulse if the bit value is 1. Thus a bit cell is two pulse times, the first always containing a 1 for the clock and the second containing the actual data value. However, the various computer systems using the technology organize bits, words and the rest in very different ways.

The RK-05 writes each word sequentially while accumulating a checksum that it will write as the last word after the data in the sector. The 2310 writes every 16 bit data word followed by four check bits - 20 bits on disk for each 16 bits of data. The check bits emit 1 values until the total of 1 bits in the 20 bit field is an even multiple of four (looks for zero modulo 4). Thus, the final four bits can be 0000, 1000, 1100 or 1110 but always ends with a 0. There is no checksum for the 2310. 

Each 2310 sector begins with  250 microsecond long interval, called a preamble, writing zero bits (clock pulses but no data pulses). It then writes a 1 bit that is the sync word (conceptually b0000000000000001), which ensures that the disk drive knows which pulses are clock and which pulse times are for data. It also knows that where a word boundary starts, since the disk is just an undifferentiated string of bit cells. The data words begin after this. In reality, the 1130 sync word is b00000000000000011110 to complete a 20 bit word with the check bits. Various DEC drives have their own preamble durations. 

George's emulator is more generalized - it supports various DEC formats for sector counts, sector sizes, word sizes and even a format that records a header field then the data field on each sector, thus it will have two preambles and two sync words. I don't need any of these variations so I am hacking away at his logic and code just to support the 2310. 

USING TOOLCHAIN TO SIMULATE MY LOGIC TO VERIFY THE CHANGES

I modified the timing module to implement the lower 720KHz clock rate, then verified its operation by simulation. I changed the sector and index pulse module to produce the eight physical sector pulses but to only trigger the read/write logic with every other pulse, matching how the 1130 combines two physical into one logical sector. This was also simulated successfully. 

I then updated the sector read logic to handle the 20 bit words, format of the sector and timing of the 2310. I worked through this with the simulator until everything worked as I wished. 

Going forward, I will modify the disk write module and the seek module, making them behave as they should for the 2310. Once they work the C code on the Raspberry Pi needs to be updated to be certain it reads the IBM 1130 Simulator (simH based simulators) format disk files rather than the more flexible file format adopted by George. The last steps are electrical - getting the right signals with the right polarities and voltage ranges to interface with the IBM 1130 controller logic. 

VCF 1130 system is missing two SLT cards to support the full complement of configured peripherals

TWO 0000 SLT CARDS ARE MISSING FROM THE MACHINE

These are the most common of SLT cards, providing four double input "AND" gates and two triple input "AND" gates. These are in fact NAND gates, as the output goes low only when all the inputs are high, but IBM either calls them A gates or alternative OR gates (with the output high when any input is low). Exact same truth table, which the rest of the world would call a NAND. 

NOT A PRACTICAL LIMITATION FOR THE VCF MUSEUM

The museum owns an 1132 printer and a 2501 card reader, but not a 1442 reader/punch. Thus, there are spare cards from the 1442 controller logic that will complete the machine for the peripherals it will be attached to during its use at the museum. 

Finding and fixing the space issue with 1052 console printer

RECAP OF FAILURE TO SPACE WITH AN XIO WRITE COMMAND

The typewriter is driven by an XIO Write to the console area code (00001) with the top 8 bits of the word signifying the request to the typewriter, either to type a character on the typeball or to execute a function such as carrier return. The controller logic fires one or more solenoids in the Selectric mechanism, then issues a response interrupt to signal that the operation is complete.

I was able to type all characters on the typeball and control all functions of the typewriter except for one. Requesting a space by XIO Write resulted in no action on the printer but a successful response interrupt from the controller. The physical Space button on the front of the typewriter successfully performs the spacing function, it only fails when XIO Write requests this. 

TOOK MEASUREMENTS TO FIND THE BREAKDOWN POINT

The scope demonstrated that all the circuitry in the 1130 was firing correctly when I sent an XIO Write to command a space. I then checked continuity to the solenoid pin inside the typewriter as well as appropriate resistance of the coil winding. This pointed squarely at mechanical issues inside the Selectric. 

I quickly discovered that the armature of the Space solenoid was gummed in place. It is located in a very difficult spot to reach for lubrication and checking, thus I missed it during the effort to free up every moving part. 

REPAIR AND RETEST

It didn't take much effort to free up the armature and allow the solenoid to trip the Space function on the operational cam assembly. I fired up the machine and indeed now the console printer spaces whenever the software requests it. 

LOADED CONSOLE DIAGNOSTIC INTO MEMORY AND RAN IT

I had captured the console diagnostics on the IBM 1130 simulator and produced a core memory load file so that I could get that code into the real 1130. With it loaded, I began executing the diagnostic. Its behavior depends on the setting of the Console/Keyboard toggle switch as well as the function(s) selected on the diagnostic. 

When I started it with the switches set appropriately, it ran through the series of printer tests. These require that tabs are set at column 20 from the left margin in order to work properly. The tests run include:

• Tab and Carrier Return tested
• Upper case characters
• Lower case characters
• Backspace and line feed
• End of line auto carrier return
• Registration (print, backspace and print)
• Lines are printed in black and red ink
• severe case (rock, roll and twist tests)

The printer passed with flying colors, almost perfect. I see a trace of stickiness when doing line feeds to advance the paper, plus sporadically the carrier return doesn't slam all the way to the left margin. I will attack the machinery with a bit more lubrication and exercise, but this typewriter is ready to have its cover and faceplate attached, resuming its rightful place under the display light panel and it front of the keyboard. 

Working on my 1442 card reader/punch

MY 1442 WAS NOT FULLY FUNCTIONAL

My card reader/punch had a number of issues that were outstanding. Once I implemented my virtual peripheral device using the Storage Access Channel feature on my 1130, I could feed cards from virtual readers based on files on a laptop and left the 1442 for a later repair session. It will be very useful if I can get it working so that I can fully test the logic in the VCF 1130 that controls a 1442. 

The card movement was a bit pokey, due to residual gummed up lubricants in the moving parts of the reader. It would feed and read a card, but either gets a read error or a feed error right away. It also moved the cards so slowly that they failed to 'corner' on the path to the output stackers.

This device has a continually running motor with a feed clutch that is energized to move cards from one station to the next. During a feed cycle, the read clutch is tripped to move a card through the read photocells. If the card has not reached certain points when timing pulses from the motor (feed CBs) arrive, the controller detects the read or feed error. 

Another issue is dealing with the lamps that show the device status. The 1442 reader was first designed as part of the IBM 1440 system, part of the Standard Modular System (SMS) of the 1950s that preceded the Solid Logic Technology (SLT) generation in the 1960s for System 360 and the 1130. I absolutely hate the lighting displays from SMS, which were carried over for the display light panel of the 1130 system and for the console of the 360 model 30. All the others used the SLT version which are much easier to deal with. 

The SMS approach uses wire lead incandescent bulbs fitted into nylon holders. The holders have two brass cylinders on the back, into which pins are pushed. The holders are themselves pushed into a plastic honeycomb. 

An SCR has a pin that is pushed into one hole of a lamp holder, the other hole has a metal pin pushed in to deliver the common side of the connection. These are in fact inherited from the pre-computer punched card machines, miserable pins that don't fit easily into the holes. They either require brute force to push them in, but the least bit of corrosion on a pin or frankly even the phase of the moon can make these barely able to enter the hole. 

Each SCR and common pin is manipulated individually in tight quarters. Push in one pin, the torque on the common wire causes another pin to pop out of its holder. Just like with the 1130 display light panel, this becomes a game of whack-a-mole, producing a ton of frustration. The job of replacing burned out incandescent bulbs takes far longer than necessary because of this poorly designed mechanical system for the lamps. 

Inside the 1442, the indicator lights are a delight

I converted all my lamps over to LEDs, where I solder an LED plus a limiting resistor and fit that inside the nylon lamp holder. I use 26 ga copper wire which is similar to the leads of the original incandescent bulbs. 

The original incandescent bulbs have their wire corrode at the junction with the glass envelope, becoming brittle and then snapping off at the least of provocations. Many more bulbs failed due to broken wires than burned out. In trying to replace the broken bulbs, I wasted a few hours and never got the light panel back together. 

Now I get to finish this task - what a joy. 

The final issue with my 1442 is that the punch unit is broken. It has two wheels with ceramic grit that bit into punched cards to move the precisely one column at a time as the card is being punched. The ceramic broke on the wheels and I was unable to repair them in the past. 

Fortunately, a very kind organization presented me with a replacement punch unit from a 1442. I just have to pull out the old broken one and install the replacement. 

Loaded and ran hand loop to test out the 1052 console printer (typewriter)

THIS TESTS BOTH THE CONTROLLER LOGIC AND THE TYPEWRITER DEVICE

Most of my tests are of controllers that will operate with printers or card readers at the VCF's museum that are yet to be restored. Thus I am taking advantage of my own peripherals, to the extent that they work okay, to verify the controller logic only. 

In contrast, for the console printer and keyboard, the device is part of the 1130 so the test is both of the controller logic and of the proper operation of the device. I have already validated the keyboard device and controller logic; this is the typewriter side of the console. 

HAND LOOP TO PRINT CHARACTERS BASED ON CONSOLE ENTRY SWITCH SETTINGS

The hand loop reads the console entry switches and alternates sending the left eight and right eight bits to the printer. I verified that almost all of the functionality of the printer that way. It shifted between red and black ribbon stripes, it shifted as appropriate between the upper and lower case sides of the typeball, it typed characters properly from all rotate values -5 to +5, it performed tab, backspace, line feed, and carrier returns upon command. It detected the right margin and automatically inserted a carrier return. 

One function failed to operate - space. The space button on the typewriter works properly, but when sending the code x2100 via an XIO command, the typewriter silently ignored the request. Much of the logic involved in commanding a space is shared with logic controlling the R2 selection, yet I printed characters using R2. The unique path is 

• one three input NAND gate
• a driver gate to ground the solenoid (whose other end is at 48V)
• a trace over to the connector for the cabling from the logic gate to the SMS paddle card connector
• a trace on PF2 SMS paddle card
• a wire into the typewriter
• and a solenoid in the typewriter plus a reverse quenching diode. 

When I next get to the shop, I will validate the path continuity, the proper signal when processing a space request, and the energizing of the solenoid. If the issue is electrical, I will find it this way. 

One operational cam serves tab, space and backspace, thus it is working. The same trigger is used for the pushbutton as the solenoid, so that works as well. It may be that the linkage from the solenoid to pull the space trigger is not adjusted correctly or gummed up. 

Repaired typewriter now working; ran 1132 diagnostics to finish off that controller logic testing

CLEANED THE CONTACTS, REASSEMBLED THE SWITCH AND PUT BACK IN TYPEWRITER

The contact oxide coating was thick but I got it cleared off, allowing a low resistance connection in the normally closed position of the CB5 switch. The CB2 and CB7 switches were already conducting with low resistance, thus the CB Response signal will be properly generated now.

RAN 1132 DIAGNOSTICS, TYPEWRITER WORKED PROPERLY

The console printer is no longer permanently busy, allowing the diagnostic monitor to write the status messages as it ran. With this resolved, I then put the printer through its paces to verify that all parts of the printer controller logic are working in the 1130. 

The diagnostic features a number of tests, among them:

1. Wait through 200 cycles with no printed characters, reading the emitted character as the print wheels turn. This verifies that the 48 character codes are read correctly in the proper sequence that matches the physical print wheels. 
2. Sets bit 15 of the word at x0027 (end of the printer scan buffer in memory) to 0, then verifies that the printer detects a scan error.
3. Issues line space commands both with and without the printer on to verify operation
4. Prints a ripple pattern so that each character moves a column rightward per line
5. Prints all the characters of the print wheel, one character per line
6. Spaces 16 times and records which channels are punched on the carriage control tape at that line. It then does skips to specific channels and verifies that it reached the correct point.

Test 6 could not work properly with no carriage control tape installed, as is currently the case. A tape must be punched with no more than 16 total holes. The absence of a tape appears to have 8 holes punched on every line, so we will violate the test by the third time it spaces. 

If I can find any carriage control tapes, even blanks, I can set up a tape for use with the test. So far I have not located them in my workshop. 

RESULTS OF DIAGNOSTIC TESTING

The 1132 printer passed with flying colors. My ribbon is dry, thus the print is light, but you can see that the diagnostics ran well. I stopped the various tests in order to preserve my stock of printer paper. 

In addition to the ripple print and line per character printing above, it printed comments for the spacing tests, such as space 2 with the next printed line starting two down. It verified the emitters, proper code emissions for the characters on the print wheel, and the ability of the printer to detect a Scan Check. 

Some console printer output during the diagnostic run

Finished up typewriter installation and attempted to run the 1132 printer diagnostics

POWER CONNECTOR INSTALLED AND SEARCH FOR THE MISSING BOLT

I plugged in the SMS paddle card for the power connection to the typewriter. The signal paddle cards are plugged in above the power section, with a long bolt and wing nut holding the connectors in place. I was reinstalling the bolt, which is inserted from the bottom and secured by the wing nut at the top. It dropped out of my hand and disappeared down inside the machine amidst a maze of cables. 

I searched for about an hour, moving cables, shining lights and feeling around. I then began deinstalling items to open up the space. I loosened and moved the connector block that the printer and card reader cables are attached to. I disconnected the raw power supply and slid it partway out of the machine. 

When I finally found the bolt, I installed it from the top, disregarding the IBM method, so that this doesn't happen to me again. The cables were connected and it was time to power up the 1130 and try out the diagnostic using the typewriter.

DIAGNOSTIC REPORTS TYPEWRITER REMAINING BUSY - PLUS MOTOR NOT RUNNING

The diagnostic monitor tests the console printer and loops to try again when the busy bit is on in the device status word. After sixteen attempts without the bit clearing, it waits with 30FA in the System Buffer Register. I pushed the Space button to see how the printer was responding, but nothing happened. That was when I noticed that the motor was NOT running. 

I opened the main fuse section of the 1130 to test the fuse delivering the 115VAC to the peripheral devices. It was then that I noticed that fuse F6 was completely missing, which certainly explained the lack of motor activity. 

FUSE INSERTED, TYPEWRITER COMES TO LIFE FOR BUTTON PRESSES

Once the fuse was back in the machine, the typewriter completed the button press actions I triggered back before I discovered the missing fuse. It responds to those, but the diagnostic still reports it is continually busy. 

SCOPING THE SIGNAL FROM THE TYPEWRITER TO FIND THE FLAW

I put the scope on several signals coming into the 1130 from the console printer. End of Forms indicates when the paper has run out. End of Line should go high as the carrier passes the right margin. The interlock signal will go high during the long operations Tab and Carrier Return. Finally the CB Response should go low during an operation such as space, character print, or other action, returning to high once the mechanism has completed enough of that function that it is safe to trigger a following request. 

Pushing the Tab or Return buttons activated the interlock signal and blipped the end of line signal as the carrier moved through the right margin. The CB Response signal was permanently low, however, which is not correct. This is why the controller logic considered the typewriter to be busy.

CB Response is a series of three microswitches (CB in IBM parlance) that should normally be closed. They are wired in series to pass the +48V supply through to the CB Response line. Thus it should be at 48V when the typewriter is idle, only dropping out during motion of the mechanism. I found this to be an open circuit from the 48V side to the CB Response side.

One of the switches is driven by the print cycle, opening during most of a print operation and closing again after the selection solenoids are free to be selected for a different character. This is called CB2. 

Another switch is driven by the shift mechanism, opened while the type ball is rotating between the upper case hemisphere and the lower case side. It would be closed when the shift mechanism is sitting at either state. This is CB7. 

A third switch, CB5, is opened when the short action operational clutch is activated - for a space operation, as an example. When the operational cam stops, the switch should close again. 

I found that CB2 and CB7 were working properly. CB5, on the other hand, was mechanically opening and closing as it should but no electrical signal was making it through the contacts. I tried some Deoxit but it had no effect. 

SWITCH REMOVED TO CLEAN CONTACTS

I had to remove the switch from the machine to get in and clean the oxidation layer off the contacts. I hunted for ten minutes but couldn't locate my burnishing tool, a piece of metal that looks like a feeler gage with a slightly rough surface that will gently remove high spots of oxidation on contacts. Still, I am comfortable that once I get the switch passing electricity while the contacts are closed, the typewriter will no longer be permanently busy.