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.