Dram Controller module verified by simulation. Memory controller not working on real hardware

MANY ASPECTS HAD TO BE REVIEWED IN SIMULATION

The user interface of the DDR3 memory controller can be busy with activities such as refreshing memory locations, thus it has some ready signals that the caller must obey. I had to validate the correct behavior of my logic with varying lengths of delay as well as no delay in the ready signals. 

Writing to RAM involves two separate actions - loading the data word and address is one, requesting the actual write is another. Each of those actions has its own ready signal - app_wdf_rdy and app_rdy - with the need to build in permutations of the two having delays or not. 

Even the address used for the RAM write has a complication. It is built from the current cylinder address, current head, current sector address and current word address within the sector. However, the sector address as used by the IBM 1130 disk controller and as modeled in my design shows the address of the sector coming up. Thus, once a sector begins (due to a Sector pulse), the sector address will advance to indicate the upcoming next sector. 

While we are reading the sectors into RAM, we have to use the sector appropriate to the data words, not the next sector to arrive. Thus, when the design sees a read request, it latches in the sector address as the Sector pulse arrives and maintains that regardless of the changing sector address afterwards. This saved sector address is what is used to write the data into RAM.

The uploader module that reads the RAM back and writes it out the serial port generates its own sector address, but this is the true one for the sector we want to read and upload. Thus, the dram controller module selects whether to use the saved or generated sector address based on write versus read activity. 

I was able to watch every signal flowing to the two FIFOs, to and from the user interface of the memory generator, and the behavior of the dram controller as I set up various cylinder/head/sector/word addresses and requested writes or reads. Once everything worked as it should, I concluded that this module is finished, subject only to actual hardware level debugging when we are connected to the Diablo disk drive. 

POSSIBLE ALL UP SIMULATION BUT SHOWSTOPPERS OF MEMORY AND CLOCK IP 

I could build a testbench to simulate the Diablo drive and respond appropriately. It would take a good deal of work to produce decent output, using external text files for the data words needed to simulate the bit stream coming from the disk head. If the memory controller and clock modules would simulate correctly, I would have attempted this. However, in their current nonworking state my design couldn't even start working as it will be waiting forever for the initial calibration of memory to complete. 

SIMPLE HARDWARE FIRST LEVEL TEST

I will instead build a version of this with one LED indicating successful initial calibration. It should at least come up with those two lit, on real hardware, before waiting for me to push a button to start the archiving. Once the button is pushed the design will stall as it is waiting for the Diablo drive to respond. 

HARDWARE STARTS BUT MEMORY DOES NOT COMPLETE INITIAL CALIBRATION

My design comes up on the board, as I can see from a signal that reflects the state of a slide switch on led2. However, led1 with the state of the calibration remains dark, just as it does in simulation. The overall reset signal for the design is released once calibration completes, so we have a mostly inert board. 

I began routing different signals to the leds in the hope that I could at least narrow down where things are going wrong, although the memory controller is a prime suspect. In addition it was time to pour over the detailed messages from Vivado to see if I could spot any issue. 

Simulating my dram controller logic but not using Xilinx memory controller nor clock wizard

CLOCK WIZARD SIMULATION USING MY OWN CODE IS WORKING WELL

My own logic temporarily replaces the Clock Wizard IP that will run on real hardware, since the Vivado tool won't properly simulate the clocks. My code is emitting the 200, 167 and 100 MHz clocks properly.

MEMORY INTERFACE IP ALSO NOT SIMULATING PROPERLY, REPLACED

I wrote my own replacement for the memory interface to simulate the results my logic will be seeing when using the real IP on hardware. This is a very complex function but I can collapse the requirements down to the types of uses my logic makes, thus eliminating all the simulation of behaviors like calibration and periodic refresh cycles. 

This was still a bit of work to get the code to match the Memory Interface Generator IP documentation and to accept the way my design requests writes and reads. The MIG supports multiple ways to write data, for example - you can push the data before you request the write, simultaneous with the write request signals, or up to two clock cycles later than the write request signals. Fortunately, my design has picked just one of them so I only had to model that particular pattern.

VERY HAPPY THAT THE FIFO IP IS SIMULATING CORRECTLY

There are two First In, First Out (FIFO) queues I use to move data between the 100MHz clock domain of my general logic and the 83 MHz clock domain of the memory interface. The IP from Xilinx is simulated well enough that I do not have to replace that in the same way I had to replace the Memory Interface and Clock Wizard functions. 

WORKING THROUGH THE DRAM CONTROLLER MODULE SIMULATION NOW

My simulation test bench is driving various write and read requests, just as the archiver will request writes and the uploader will request reads. I am carefully inspecting all the signals and results to satisfy myself that this appears to work as intended. 

Once that is done, I will attempt a grand simulation of everything as it would be wired to the Diablo disk drive, merging the test bench code used in all my module by module simulations and producing a realistic set of driving signals and responses that should let me prove out my design as well as I can before hooking it up to the real disk drive. 

Oscilloscope test of clock wizard inconclusive, but new test proves the IP works on actual hardware

MY PLAN TO VERIFY THE CLOCKING WIZARD WAS NOT WELL RESEARCHED

I simply connected the three clock outputs as well as the clock on the FPGA board to an external connector on the board, to which I hooked my oscilloscope. The results appeared to match the simulation output - at least for some of them - with the clocks half the speed I expected and the 200MHz clock the worst of all. 

The flaw here was that I was trying to observe relatively high speed signals on an output connector (the Digilent PMOD) that is not well suited for this. Further, I didn't instantiate any clock buffers to keep the signal quality high. 

PLAN B QUICKLY IMPLEMENTED AND THE RESULTS ARE POSITIVE

I then set up counters that would increment at the rate of the three generated clocks. These were all released as soon as the clock module reported a lock on the PLL that produces the frequencies. A fourth counter incremented using the FPGA boards internal clock, also released when the clock module achieved lock. 

Since we are dealing with multiple clock domains, I implemented a chain of four stages to pass through the counters from the generated clocks so that I had a high quality counter value in the test logic. The test logic would count up to 100 to trigger the test. At 100, I checked that the three counters had reasonable values consistent with the target frequencies. The 200 MHz counter should be approaching 200, the 167 MHz counter nearing 167 and the final counter heading towards 100. 

There are a few cycles lost due to the chain of flipflops that achieve the clock domain crossing for the counters, which is why the results that lit up the LEDs were a few counts less than the target number. For example, the 200 MHz counter would probably hit 198 or 200 at the same time as my test, but the chain of four stages in the domain crossing meant that the value I would test would be about 192 to 194 most likely. My test was tightened to look for > 192 and < 195 with consistent success. 

Simulation challenges since Vivado not correctly simulating its IP components

NEXT UP WAS THE DRAM CONTROLLER LOGIC FOR SIMULATION AND VERIFICATION

This module will drive the memory interface IP (intellectual property) that Xilinx provides for their FPGA devices. It uses the cylinder, head, sector and word number data to generate a RAM address and is triggered by a signal to write a given word to RAM, or later on by a signal to read back a given word.

CLOCK WIZARD FOULED UP IN SIMULATION

The first surprise was finding that the Clocking Wizard was not simulating correctly. The FPGA board operates with a 100MHz clock but the memory interface needs a 200 MHz and a 167MHz clock to function properly. The IP will take the board's oscillator and use it to generate 200, 167 and 100 MHz clocks for use throughout my design. 

Under simulation, the outputs were 100, 83.4 and 50 MHz while the input I produced in the testbench was correct at 100MHz. Regardless of what rate I produced for the input signal - 50, 100, 200 or anything else - the outputs were always 100, 83.4 and 50. Lots of experimentation but I never did get the proper clocks while simulating. I did build a simple design using the same clock wizard that I loaded into the board so that I could use my oscilloscope to observe the frequencies produced in real operation.

MEMORY INTERFACE ALSO MISBEHAVES IN SIMULATION 

The second IP to be seen working improperly was the generated memory interface for the DDR3 RAM chip on the board. It never generated the chip reset signal to the physical RAM chip, nor did it properly reset or come out of reset based on the actual reset signal I generated in the test bench. At first I ascribed this to the incorrect clock speeds, but a special version of the clock IP set to 400, 334 and 200 gave the the designed 200, 167 and 100 yet did nothing to alter the behavior of the memory IP. 

NOT YET ABLE TO CHECK BUT SUSPECT THE FIFO IP WILL ALSO FAIL TO WORK

Until the memory interface completes calibration and comes ready, my design isn't ready to push words into the FIFO for writing nor to trigger reads and push results into the read FIFO. These are necessary because the memory interface IP produces a user interface clock at 83.4 MHz that must be used to interact with the IP, while my user logic runs at 100MHz. The FIFOs deal with crossing the clock domains. 

Finished simulation of the uploader function of Diablo 2315 archiver; building up DDR RAM controller

SUCCESSFUL SIMULATION OF THE UPLOADER

This function walks through the 2315 cartridge, reading each sector in order and writing the values out over the USB serial port. The data is transmitted in ASCII as ordinary text at 921600 baud. Each sector begins with a text line giving the cylinder, head and sector number, then 321 lines with the data values and a trailer line of text showing whether there were errors detected reading the sync or data words in the sector. 

The major pacing issue is the serial link. A complete 2315 cartridge will be transmitted in just under two minutes. I plan to capture the text that is transmitted and use it to convert the data into files in both IBM 1130 Simulator format and Virtual 2315 Cartridge Facility format. 

BUILDING THE DRAM CONTROLLER FUNCTION

The intellectual property provided by Xilinx includes a DDR3 controller which controls the 128MB physical DDR3 RAM chip on the Arty A7 board. It offers an interface called User Interface (UI) to drive read and write activity from my design.

The controller requires two input clocks at 100 MHz and 200 MHz, then generates a UI clock at 66.6667 MHz which must be used to interact with the UI. My general logic uses the 100MHz clock of the Arty board for most of its functionality.

This means that I have to accommodate different clock domains. These introduce metastability risks as well as timing risks. Flipflops whose inputs change too close to their clock edge can enter an intermediate state, neither 1 nor 0, which can persist. Logic has requirements for minimum setup and hold time for inputs to ensure correct outputs. 

Metastability is addressed by placing a chain of D flipflops such that even if the first one or two flipflops enter a weird state, the signal is cleanly 1 or 0 by the end of the chain. Some IP that deals with multiple clock domains will also include metastability FF chains inside. 

In Verilog, this is accomplished by code like this:

  always @ (posedge clock)

  begin : LOGIC // block name

    metadata[3:0] <= {metadata[2:0], OUTSIDE_INPUT};

    signal <= metadata[3] == 1'b1 ? choice1 : choice2;

I instantiated FIFO (first in-first out) IP that was designed to move data across clock domains. Although I don't use them to drive more than a single request for read or write at any time, they solve my timing and metastability risks. 

My logic will push a new data word into a FF at 100 MHz, my general clock, and other logic operating under the UI clock will pull that word out of the FF at 66.6667MHz and write it to the DDR3 controller. When reading back for the upload, the logic running under the UI clock will push the data read from the DDR3 controller into another FF where my logic running at 100 MHz will pull it out. 

To make life simple, whenever data appears at the UI clock end of the first FF, I know it is a write request. Requesting a read requires a signal to go into the UI clock domain from my 100 MHz domain. In addition, the address for the RAM read or write is generated in my 100 MHz domain so it too must get over to the UI clock domain. I handle the metastability of these signals with Verilog code much like that shown in the example a few paragraphs above. 

The RAM size is so large compared to my needs that I can be lazy and wasteful with the benefit that this allows simple straightforward designs. The address ranges for cylinders and for words inside a sector are not even powers of two. I form an address using the eight bits of cylinder, but the value only ranges from 0 to 202 leaving part of the address space wasted. Similarly, the nine bits of word number range from 0 to 321 (322 including the error status I record) which also leaves locations 323 to 511 unused in each sector. 

Also, the DDR3 interface inherently provides bursts of eight blocks of 16 bits for a total width of 128 bits for every read or write. I am only using the first block out of the eight. This means that I will issue eight writes for sequential words in a sector when I could have just loaded the eight blocks then issued a single write. Again, I have the room thus I am skipping the logic to properly use the eight blocks in a single access operation. 

Finalizing and simulating the Diablo disk archiver tool design

DIABLO DRIVE TO BE USED TO READ AND ARCHIVE MY 2315 CARTRIDGES

I have a substantial library of 2315 disk cartridges that I acquired, mostly as part of the purchase of my own 1130 system. I also have a Diablo Model 31 disk drive with the rare standard density heads that match the bit rate of the internal (13SD) IBM disk drive in the 1130 system. I intend to use the Diablo to read and upload all the disk images, avoiding risk to my own internal disk drive if any of the cartridges have a flaw I don't detect that causes a crash. 

ARCHIVER BEING WHIPPED TOGETHER WITH ARTY A7 FPGA BOARD

I had a Digilent Arty A7 FPGA board on hand and chose it to support this role. It has enough onboard DDR3 RAM to read in and hold an entire 2315 cartridge, 1,013,376 bytes and enough logic blocks to implement the fairly simple logic needed to sequentially read all 1,624 sectors of 321 16-bit words, beginning at the home track and stepping forward one track at a time to the last of the 203 cylinders. 

It will then upload the image over a USB serial link where I can post-process the contents into an IBM 1130 simulator format file and then into a Virtual 2315 Cartridge Facility file that can be accessed on a physical 1130. I am leveraging code to format the data into ASCII and send it out over serial that was developed by William Carter at Eclektek LLC.

GOOD SIMULATION VERY IMPORTANT FOR DEBUGGING FPGA DESIGNS

It is important to carefully model the signals, especially their relative timings, to see that the state machines and other logic performs as intended. I work to introduce timing variations, worst case situations and anything else I can think of that could reasonably happen to the FPGA when actually driving the Diablo. 

SIMULATION VERIFICATION PROGRESS

The Diablo Archiver consists of a number of modules that perform various functions. As of now, these are:

• clock_and_reset which generates the asynchronous reset to initialize state machines
• seek_to_cylinder which performs a one track move inward
• sector_and_index which tracks the upcoming sector and indicates arrival
• bus_disk_read which reads the sector, checks for errors and pushes data to RAM
• archiver which steps through all sectors and asks for them to be read
• uploader which sequentially fetches the sectors from RAM, formats and sends them over serial
• dram_controller which takes the requests from above and controls the DDR3 RAM
• YASUTX and UART_DEBUGGER2 for the serial output

I have finished fully testing the bus_disk_read, seek_to_cylinder, sector_and_index, clock_and_reset and archiver modules. Next up I will simulate the dram_controller and its RAM functioning, then the uploader module with its serial stream output. The final simulation will pull the entire FPGA design together. 

EXAMPLE OF SIMULATION OUTPUT

Here is a simplified excerpt of the simulation of the archiver module to show the successful behavior of the machine as it reads the last sector of the cartridge - cylinder 202, head 1, sector 3.

Disk drive and Virtual 2315 Cartridge Facility accomplishments

NEW 48V BULB IN THE UNLOCK LIGHT WORKS PROPERLY

My bulbs came in and I inserted one in the IBM 1130. When powered up, the Unlock light will be lit indicating that the receiver can be opened to slide cartridges in and out of the drive. As soon as the Run switch is activated and the drive begins spinning, the Unlock light will extinguish and stay off until after the drive comes to a halt. 

VOLTAGE CHECKS BEFORE CONNECTING THE RK-05 EMULATOR TO 1130/2310 SIGNALS

I put a meter on all the signal lines that will be connected to the RK-05 emulator circuits to verify that they don't produce voltages that will cause problems for the interface circuitry in the emulator. I found three pins that recorded voltages around 6V, the rest are all 3V or less. 

Pin B13 from the disk drive is the Write Data and Clock signal, an input to the drive which is output by the emulator. The emulator uses an open collector driver gate which is insensitive to the fact that the pin has a pullup to 6V. 

Pin B03 from the 1130 controller logic is the Read Data input to the 1130, which is output by the emulator using a open collector driver gate. Again, it is a pullup voltage that won't affect the RK-05 circuits. 

Pin D10 from the 1130 controller logic is Write Gate output from the 1130, which is an input to the RK-05. I observed a voltage of just over 6V on the pin, which worries me because the SN74LVC244A chip has a specified range of 0 to 5.5V for its inputs and an absolute max, must avoid voltage of 6.5V. 

I am going to mull over whether I need to do anything for this signal or just hope that it doesn't overstress the level converter chip in the emulator. 

REPAIRED B12 PIN IN CONNECTOR TO 2310 DRIVE

After close examination with a microscope I could see the cause of the poor connectivity for the opening for B12. The connector uses individual sockets that have tabs which are bent inward to press against the pin when the connector is pushed onto the backplane. I can see this in all the other sockets but the one for B12 has its tabs pushed outward so that they don't contact the pin. 

Its hard to see to the sockets marked 2, 6 and 8 have tabs bent inward in the rectangular opening but socket 4 has flat sides. B12 is connected to socket 4.

I desoldered and carefully removed the socket from the connector shell, where I was able to gently reform the tabs on the socket to provide a reliable firm connection. 

Socket shell partly removed for B12

Socket shell with tabs not yet reformed inward

I then reinstalled the socket and soldered it up. Testing with the connector provided that the connection for B12 is now working properly. 

LOCATION BEING CONSIDERED TO MOUNT RK-05 EMULATOR BOX AND POWER SUPPLY

I will create a mounting so that this is accessible when the right side door of the 1130 is swung open. The interface card will sit behind it and a bit above. The power supply will be behind it against the housing for the peripheral cable connectors. 

During illness recovery time, building archiver logic to read 2315 cartridges on a Diablo drive and upload

DIABLO 33 DRIVE WITH STANDARD DENSITY HEAD ON HAND

The Diablo 33 drives were widely used for minicomputers and other systems, derived from the IBM 13SD (2310) disk drive developed for the IBM 1130 system. However, quite a few enhancements were included in these drives (and similar derivatives like DEC RK-05), including direct seek to a target cylinder and single command restore to home position.

The most important change that most implemented as to double the recording frequency, thus doubling bit density and cartridge capacity. On the IBM 1130 (13SD drive) the bit cell frequency is 720KHz, while the RK-05 and others use 1.44MHz. Thus a 2315 cartridge holds just 1MB at 720KHz but 2MB on the RK-05 (and others). 

The higher frequency uses a different recording/playback head, ceramic surface, while the IBM heads are chromed metal surfaces. The ceramic heads are more resistant to scratching from transient head/disk interference (such as a tiny dust particle slamming between head and disk), these can generally be cleaned well and put back into surface, whereas the metal surface slowly accumulates scratch lines until its aerodynamics are too spoiled for safe use. 

Diablo offered the model 33 in both standard and high density flavors, which are 720KHz and 1.44MHz bit cell rates. For the standard density they use chromed metal heads just like the IBM drive. I am fortunate enough to own a standard density model 33, although its heads had been badly scratched due to a crash before I acquired it.

I am now able to replace the heads with standard density heads in good enough condition to fly. Thus, I plan to use this drive as a means of reading and writing 2315 cartridges containing IBM 1130 software. 

ARCHIVER DESIGN BEING BUILT BASED ON DIGILENT ARTY A7 BOARD

I had a spare Arty A7 board, based on a Xilinx Artix 7 chip (xc7a35ticsg324-1L) and a 128MB DRAM. It has enough general IO connections to drive the Diablo for an archiving session, enough RAM to grab an entire 2315 cartridge in one pass, and a serial link over USB where I can send out the data once the archiving has completed. 

I am finalizing my testing of the DDR interface, ensuring I can reliably write and read to the RAM, before I move on to testing the rest of the design. The IP generation in Vivado provides an example program that does this satisfactorily, so I just loaded that into the board and watched the LEDs to see it perform. 

OVERALL LOGIC OF THE ARCHIVER

The archiver opens a serial port link to a remote host and waits for a simple command to start archiving. The drive comes ready with the arm at home (track 0) position. The logic will step through the 203 cylinders one by one, performing a one track seek between each. For each cylinder, it will step through both the top and bottom heads (two disk surfaces). For each head, it sequentially reads and saves sectors 0, 1, 2 and 3. 

The read logic will be set up when the target sector is approaching the read heads and given a read request. When the sector pulse from the drive arrives, the read gate is turned on and we begin to receive streamed bits on both read_data and read_clock lines. 

Every sector begins with a bit less than 200 bits of zero, which ensures the drive can correctly separate the clock and data pulses coming from the head and route them out on read_clock and read_data lines. The first nonzero bit is the sync word, a special value of 0x8000 that is used to identify where each 16 bit word begins. The 1130 stores words with the high order value labeled as b0 and the lowest order value at b15, thus the one bit coming in on read_data is for b0 of the sync word.

The actual data recorded on the cartridge is 20 bits long for each 16 bit 1130 data word, tacking on four error detection bits after b0 is read in. The stream of 20 bits is b15, b14, b13 . . . b0, e0, e1, e2 and e3. The error detection scheme is simple, based on counting how many one bits were received in each word. As long as the count of one bits received, after we accept all 20 bits from the disk head, is an even multiple of four, then we have a good word. Formally this is 0 modulo 4, implemented by the counter built from two bits so it is always modulo 4. 

The sync word has only a single one bit thus it needs to send three more to get our counter to 0b00 for a good status. Bits e0, e1 and e2 should be a value of 1 each, with the final e4 bit always a zero. We validate the sync word was properly formatted otherwise anything we try to extract in the sector will not be correct. The syncerror flag is raised if the error detection fails on the sync word. 

After each read_clock bit of 1, we see if a 1 bit comes in on read_data in the interval before the next read_clock bit. If it does, we saw a one value, otherwise the data value for this bit cell (combination of a clock pulse and either a data pulse for 1 or absence of a data pulse for 0) is a value of zero. In any case, after each read_clock pulse (1 bit arriving) we push the captured value into a shift register. 

Physically on the disk the low order data value arrives first, with b0 at the end, so we push into the shift register to produce an 1130 format value b0 to b15 once all 16 bit cells have arrived. Any time a one value was pushed into the shift register, we increment the error detection counter. This continues for the last four values, e0 to e3. After the 20th bit value was received, if the counter is not 0x00 (or rolled around to 0b00) we raise the ECCerror flag. 

The 16 bit value from the shift register is written to the ram and our word address bumps up by 1 (having started at 0). When we have read all 321 words - a full sector - we raise a done flag so that the archiver can advance to the next sector. 

Once all 203 cylinders are read and in RAM, we write the data values over USB serial link to a remote system where the data can be captured and postprocessed to build a virtual 2315 cartridge file. 

Fighting to get time in the shop; replacement light bulb arrived for Unlock lamp on 1130 console

ONE THING AFTER ANOTHER THIS SEASON

I had several visitors including my daughter and her fiancé, as well as other family. In between, there are all the seasonal obligations to deal with. Nancy and I both caught upper respiratory infections while enjoying Disney's EPCOT with our daughter. Still mostly recovering but looking forward to a more normal schedule playing with old computers. 

RECEIVED REPLACEMENT INCANDESCENT BULB FOR UNLOCK LAMP

The colorful lamps on the 1130's console use incandescent bulbs behind frosted colored plastic rectangles. I have quite a few bulbs available for 12V and lower voltages, but a few of the lamps on the console are wired to 48V circuits such as the disk drive. Thus, they need a 48V bulb which I didn't have on hand.

The new 48V bayonet bulbs arrived today and I will replace the burned out bulb for the Unlock light. This illuminates when the drive is at rest, showing that the handle is unlocked. The operator can slide a disk cartridge into or out of the drive while this is lit. Once the Run switch is activated to turn on the drive, the handle locks and our bulb goes out. 

CONTENDING WITH ODIOUS BEHAVIOR OF A NORTON 360 UPGRADE

The new version that updated itself is much more active in its attempt to protect me. Overly so. When I run the Vivado toolchain to work on FPGA logic, it attempts to block several programs and hangs the start of simulation - claiming it is sending it for real time analysis in their labs. They way they do this leaves Vivado dead in the water, requiring me to kill a background task and restart. 

There is no straightforward way to tell the obnoxious software to not block the software, unlike the ability in the past to ask for a given program to be put on an exclusion list. The only way I could work with Vivado was to disable multiple of the Norton 'protection' services - three of them were involved in ruining the Vivado experience. 

The software now stomps through my system like hateful stormtroopers, interfering with many innocuous acts of trusted software. The change in aggressiveness is dramatic and I don't like it at all. 

Found narrower contacts for producing SLT cards, updated design and ordered new PCBs

ISSUES WITH THE CONTACT PARTS I ORIGINALLY SELECTED

The gold plated contacts I used for my double wide SLT card (a controller card for the 1627 Plotter) are wider than the IBM original parts. They make it hard to install them without shorting and there is some mechanical interference with the nylon covers unless they are just perfect.

I ordered a number of narrower contacts in order to satisfy myself that they will still provide good connectivity when the card is plugged into an SLT board slot, and that they accept the covers easily. I found one I really liked and conducted tests to ensure a good connection when plugged into a card slot.

NEW REVISION OF PCB TO ALIGN THESE CONTACTS IDEALLY

Using the mechanical drawings of the contacts, the 3D design of the nylon covers and the dimensions of original IBM boards, I came up with a pad design and placement that should allow for an easier construction without the risk of skewing that occurred with the prior contacts. 

The boards are being produced and a batch of fifty contacts are on their way as well. I hope to have the card connectors dialed in to my satisfaction once they arrive and are put together. When that is ready, I can mount all the parts for the 5806223 replacement card I am building to attach a plotter to my 1130. 

Virtual 2315 Cartridge Facility interface board connected and a number of tests performed

OVERVIEW OF THE FACILITY

The Virtual 2315 Cartridge Facility implements a virtual version of the 2315 disk cartridge that would be inserted into the disk drive in the IBM 1130. It works in hybrid mode with the disk drive, thus a physical 2315 is placed in the drive and spun while the data is provided by the facility. 

The drive spins the cartridge, the arms seek in and out as programs access the virtual cartridge - essentially everything the same except the heads don't fly down on the cartridge and the data is from the emulator. The timing as well as the physical sensations are just the same as if the heads were actually involved. 

This leverages the RK-05 Emulator designed by George Wiley, but with substantially rewritten logic to emulate a 2310 disk drive and to work in the hybrid mode which is unique to the Virtual 2315 Cartridge Facility. A micro SD card is inserted in the emulator box, containing the virtual 2315 disk cartridge contents. It is loaded into the facility and then waits for the physical disk drive to spin up.

An interface board intercepts the signals between disk drive and the IBM 1130 controller logic. The cable which is normally plugged into the disk drive instead plugs into the interface board. A cable wired to the interface board is plugged into the disk drive instead. The board also accepts two ribbon cables from the RK-05 Emulator box. Finally, it is powered from the 1130's 12V DC supply. 

In addition to the signals for the disk drive, we intercept two other switches on the disk drive. One of them indicates that the drive is unlocked to permit the introduction or removal of a 2315 cartridge. The other is the Run switch which is turned on to spin up the drive. 

The operation of the facility is straightforward. A micro SD card sits in the emulator box. When the emulator box has its switch toggled to activate the image, the cartridge image is read in to the emulator. With a real 2315 cartridge inserted in the drive, the Run switch is turned on. The motor starts spinning the cartridge. After 90 seconds, as long as the emulator had a virtual cartridge loaded, the drive believes it has loaded the heads onto the disk and it turns on the File Ready lamp.

The user operates the 1130 and runs software exactly as they would if the facility was not installed. When the user turns off the Run switch on the disk drive, the emulator will write back any changes to the virtual cartridge image on the mico-SD card at the same time that the real cartridge is slowing to a halt. Finally, the Unlock lamp comes on the 1130 console. 

INTERFACE BOARD INSTALLED INSIDE 1130 AND WIRED TO POWER AND SWITCHES

I tapped some holes in a support frame inside the 1130 and screwed the interface board into place. It also has wires from the DC 12V and ground, plus one wire each to the Disk Unlock switch on the drive and Unlock lamp on the machine console. 

The cable from the 1130 controller logic is plugged into the back of the interface board. A cable from the board is plugged into the card cage on the disk drive. Two ribbon cables are plugged into the board to connect it to the RK-05 Emulator box which is mounted on top of the disk drive, accessible by lifting the top cover of the 1130. The emulator box is also wired to the +12V power of the 1130, so that it only comes on when the 1130 is powered up. 

NEW VERSION OF PCB BEING FABRICATED

I improved the design in several ways. A mode switch was added, I did away with the sensing of the Run switch on the disk drive, and I added a circuit to light the Unlock lamp on the 1130 console when running in virtual mode. 

The PCB will have a tiny slide switch which sets the Virtual 2315 Cartridge Facility to either virtual or real mode. In real mode, the disk drive inside the IBM 1130 is active, producing the sector and index pulses as well as physically seeking the arm in and out. In virtual mode, the disk drive is purely emulated and the physical disk drive is not used at all. 

The Unlock lamp is a 48V bulb that is grounded by a microswitch in the disk drive whenever the solenoid is activated that allows the drive to be opened and a cartridge inserted. For the virtual mode, we will pull the line down to ground to cause it to light when the emulator box is ready to have a virtual 2315 image 'loaded' into the disk drive. 

TESTED END TO END CONNECTION TO THE RK-05 EMULATOR BOX

I probed the connections in the RK-05 emulator card and the other end of the signal at either the disk drive backplane pins or the 1130 controller logic backplane pins, depending on the signal. This ensured that the cabling and the interface board design was correct. 

I used the old PCB to verify the connectivity and will continue with it while waiting on the new board to be delivered - it has some bodge wiring and other changes to make it electrically identical to the new design. 

ONE ISSUE WITH A CONNECTOR TO BE RESOLVED

I have an intermittent contact on pin B12 of the connector that plugs into the 2310 (internal disk) drive. It appears that the connector's opening is a bit wide and the pin on the disk drive's SLT board is perhaps a bit narrow. Wiggling the connector causes the connection to drop in and out. I will work on this before I move on to actual testing of my logic and code for the RK-05 Emulator box, now the Virtual 2315 Cartridge Facility box. 

I circled the connector hole for B12. Visually it doesn't look any different but there is an issue with the connection for that pin to the hole. 

2310 Disk power SMS card inserted into 1130; FPGA bitstream Virtual 2315 Cartridge Facility ready for testing

SMS POWER CARDS REQUIRE CHAMFERING OF LEADING EDGE TO INSERT PROPERLY

My design for SMS power cards to route the AC and certain other voltages to certain IBM 1130 system peripherals is in place and the drive blower motor is spinning up when system power is applied. The devices that use these cards are the internal 2310 disk drive, the 1053 console printer (typewriter), the 1627 plotter, the 1134 paper tape reader and the 1055 paper tape punch. All other peripherals receive power through the large IO cables that link them to the 1130. 

The card is .004" thicker than the IBM cards, which is just enough to make insertion of the card almost impossible. It is the cumulative friction pressure of the contacts across the 16 possible contact positions of an SMS card that lead to the difficulties. Because the contacts are spring loaded they would allow the card to fit were it not for the pressure required to get it started moving into the slot.

I used a rasp to chamfer the backside of the card at the edges that enter the card slots. It didn't take much material removal before I could press the card into the slot successfully. I will release the design of the cards on github allowing others to build them for various devices connecting into the 1130 system. The material of the IBM cards is fragile enough that these are often snapped off. 

FINALIZED GENERATION OF FPGA BITSTREAM FOR MODIFIED RK-05 EMULATOR BOX

I carefully updated the constraints file to ensure that all the signals were linked to the proper FPGA input/output pins. The original RK-05 Emulator developed by George Wiley uses signal names appropriate to the DEC RK-05 drives but I needed a different set of signals for my plans to support the IBM 2310 disk drive. 

I have a clean synthesis, placement, routing and bitstream generation of my design. This file can be downloaded into the RK-05 Emulator box, into the Lattice ICE40 FPGA contained in the box. 

WORKING ON COMPILATION OF THE C CODE FOR RASPBERRY PI PICO

The other active element in the RK-05 Emulator is a RPi Pico processor that runs code to interface with a microSD card, an LCD display and various lights and switches. It also links to the FPGA using an SPI link. The virtual 2315 disk cartridge is a roughly 1MB file on the microSD card inserted into the emulator box. When the Load/Unload switch is turned to Load, the Pico code reads in the file and writes its contents over SPI to the DRAM used by the FPGA for disk emulation. That switch, on the original RK-05 Emulator, is labeled Run/Unload but the function is modified in my design. 

Once the image is downloaded into the DRAM, the FPGA is informed that it has a valid image and can now act as a 2310 disk drive. The normal mode for my facility is to insert a dummy 2315 cartridge (an actual cartridge but the disk heads will not be loaded thus its real contents are ignored). When the Run switch on the IBM 1130 is activated, the 2310 drive spins up and eventually believes it has loaded the heads on the drive. This causes the File Ready lamp on the 1130 to illuminate and input-output can commence. 

When the Run switch on the 1130 is turned off, the real cartridge slows down and stops, meanwhile the Virtual 2315 Cartridge Facility code in the Pico will pull the image from the DRAM over the SPI link. This is written back to the file image on the microSD card, thus preserving all the changes written to the virtual disk cartridge while the 1130 system was accessing it. 

I have to put the C files onto a Pico system, compile the code, then perform testing to be comfortable that it will work properly with the FPGA. When that is complete, the code is loaded onto the Pico and the Virtual 2315 Cartridge Facility will be ready to test with the IBM 1130. 

Synthesized FPGA logic after cutting back on usage to fit within the device for the Virtual 2315 Cartridge Facility

FIRST TRIES AT GENERATING IMAGE FAILED DUE TO SIZE CONSTRAINTS

The device used in George Wiley's RK-05 Emulator, which is the base of my Virtual 2315 Cartridge Facility after substantial modifications, only had room for a bit more than 1000 LUTs (Look Up Tables, a fundamental unit in FPGAs) but my first attempt came in requiring over 1400.

TRIMMING SUCCESSFULLY WITHOUT COMPROMISING FUNCTIONALITY

George's emulator is quite flexible, supporting a range of DEC CPUs and controller cards that connect to an RK-05 disk drive. As such, it stores many key values in the header of the disk file, such as the length of the preamble of zero bits before the sync word. These are read from the microSD card by the Raspberry Pi Pico and sent over SPI link to the FPGA logic to customize its behavior.

The IBM 2310 disk drive has only one set of values for things such as the bitrate, preamble length, number of sectors, sector duration etc. I hard coded them into the FPGA which allowed me to strip out all the code that read them from SPI and passed them between functional parts of the FPGA design. This pulled the required LUT count below the maximum so that I could use the IceCube2 tool to place and route the design onto the FPGA chip being used. 

Soldered components on the new version of the 2315 interface board

BUILDING THE BOARD 

This board has five connectors and a few other components on it. This sits in between the IBM 1130 and the disk drive, routing signals through the emulator box. 

A set of SLT backplane pins are the connector for the cable from the IBM 1130's disk controller logic; normally that cable inserts into the backplane of the disk drive. A cable coming from the board has a SLT card connector end that will plug into the disk drive. Two ribbon cables run to the emulator, a modified version of the RK-05 Emulator. Some wires connect to the 1130 main power and to the Run and Unlocked switches in the disk drive. 

A power supply regulator and two transistor interface circuits convert the 48V levels of the two disk drive switches to appropriate TTL logic levels before sending them to the emulator box. 

Replaced power paddle card for disk drive in IBM 1130

 NEW PCBS ARRIVED FOR IBM 1130 POWER CONNECTORS

The IBM 1130 uses a block of SMS card sockets, with a metal bar at the position of pin H to ensure that ordinary SMS paddle cards are blocked from insertion. The other positions of the socket are used for various power connections - 115VAC, 230 VAC, 12VDC, 48VDC,  and frame ground. These are used with the 1053, disk drive, 1134, 1055 and 1627 devices only.

This requires a special version of an SMS paddle card with a notch cut at position H. I designed the card and had it fabricated at JLCPCB.com, receiving it today. 

WIRED UP ONE PCB TO CONNECT THE DISK DRIVE INTO VCF IBM 1130

This card has the motor power lines connected 115 AC hot to CD, AC neutral to FG, and frame ground to KL. No other pins are used for the disk drive as it gets its signal ground and +48VDC through a different set of connections; this is strictly for the AC connections to the disk drive.

DIFFICULT TO FIT INTO THE SOCKET - INVESTIGATING THE CAUSE

I wasn't able to insert this into the socket. When I hold it up against the IBM paddle cards, for example the one for the 1053 Console Printer, I don't see any noticeable difference. I measured the thickness of the IBM card and then my card; mine is a bit thicker.

However, the difference is just .004" as the IBM card is .058" thick and my card is .062" by comparison. Holding the card diagonally so that only a small wedge enters, I was able to get it to slide in a bit. That implies that it should be possible to go in. The issue is the amount of force needed to spread the socket contacts and overcome the friction with my the pads. 

I will work with another of my PCBs, not the one with the wiring already attached, to determine how (or if) I can make the card slide in. At worst case I can try to sand or shave down the end that slides into the socket a bit. 

All simulations completed satisfactorily for the Virtual 2315 Cartridge Facility

VERY LIMITED TIME DUE TO FAMILY VISITS AND HOLIDAYS

However, I did grab time to work on the simulations of the FPGA logic for the emulator that will sit between the IBM 1130 disk controller logic and the internal disk drive, allowing it to operate in hybrid mode. I built more sophisticated testbenches and used them to scrutinize the operation and timing of everything in the design.

SIMULATIONS WORK EXACTLY AS EXPECTED NOW

The logic should give me exactly the behavior I want. When any 2315 cartridge is inserted into the internal disk drive (13SD) and a valid disk image on a micro SD card is inserted into the emulator box, the disk image will be read and written to by the IBM 1130 as the 13SD drive spins and moves the disk arm in and out. It will also work properly if the 13SD drive is not working, providing a fully virtual disk drive emulation. 

NEXT UP - CLEAN UP AND TEST THE C CODE FOR THE RASPBERRY PI PICO

I want the code to make use of the file format for disk files of the IBM 1130 Simulators so that disks can be moved between the virtual (simulator) and real 1130 system environments. The RK-05 Emulator upon which my facility is based has its own format for disk files, developed to support various DEC computer disk drives. These were derived from the IBM 13SD but have significant differences. 

Rotation, sector and index pulse timings good, as is reading a sector; working on capturing a write to a sector now

COMPLICATIONS THAT HAD TO BE VERIFIED

The design can operate in one of two modes - virtual only or hybrid where it operates in conjunction with a spinning, operating disk drive. The logic varies in quite a few places depending on whether we are completely driven by incoming sector and index pulses from the disk drive or whether we are generating them. 

I wanted to check that even with jitter and speed variations, the hybrid mode would correctly produce the pulses and more importantly be in complete sync with the sector that is under the read/write heads. We have to pick up the proper sector's content to feed it to the 1130 during a read; for a write, we must be updating the proper sector's image in DRAM. 

The pulses could arrive in any relationship to the logic in the FPGA, which I tested by shifting the pulses generated in my test bench. It is easier for virtual mode, since the FPGA is producing the sector and index pulses itself. 

I very carefully checked all the emitted signals from the modules producing sector and index information. When this was as tested as I could achieve without real hardware, I moved on to test the process of reading a sector on disk. For this, the 1130 controller logic looks at the sector address, then raises the read gate signal when the appropriate sector pulse finishes in the targeted sector number. 

My testbench produced the stream of clock and data pulses that the 1130 controller logic expects from the disk drive. This is approximately 250 microseconds of alternating pulses, which are a 1 for the clock and an absence of a pulse to represent a bit of 0. The 250 us of zero bits allows the disk drive to sync up and learn  to separate data and clock bits, since they are simply sequential pulses or absence of pulses on the disk surface. 

At the end of the 250 us, a word is written with only the high order bit set - x1000 - which the controller logic uses to know when a new word is starting. This sync word is followed by a stream of pulses which represent up to 321 words of 16 data bits plus 4 check bits, delineated by the controller based on the sync word identifying where a new word begins. 

When the read logic was accurately generating the pulses in the proper timing, I could verify that the pulses delivered on the data and clock lines from the disk drive are correct. One aspect of my read logic is that it has to generate the four check bits for each word. Thus, after sixteen bits of data for a word is emitted, the next four bits are the check pattern that implements IBM's error checking algorithm.

The ECC is pretty simple - during the reading of each word, a two bit counter is advanced for every data bit that is a 1 value. The counter rolls over, so that after it saw three 1 bits, another 1 bit sets it to zero. Thus the counter is operating modulo four. After the sixteenth data bit, check bits are produced to bring the counter to zero. 

This means if we had 1, 5, 9, or 13 bits with a 1 value, the counter is at 1 and we generate a check pattern of 1110 which advances the counter so it reaches 0 at the end of the word. If we had 2, 6, 10 or 14 bits with a 1 value, the counter was at 2 and the check bit pattern of 1100 advances it back to 0. Having 3, 7, 11, or 14 bits with a 1 value gives a counter of 3 and the check bit pattern 1000 gets it back to 0. Words with 0, 4, 8 or 12 bits with a 1 value ends with a counter that is already 0, so the check bit pattern is 0000 since we don't have to advance the counter. 

For every 1130 data word - 16 bits - we write 20 bits onto disk in order to have the four check bits appended. The file containing the disk cartridge contents only saves the 16 bits per word, with our read logic generating check bits on the fly. If the controller logic doesn't end the 20 bit word with a counter value other than 0, it has detected a read error and flags the read as defective. 

I verified that this read logic worked in both hybrid and virtual modes. It appeared very solid, but needs testing on real hardware to be certain I have it correctly generating the bits. 

WRITE LOGIC INVOLVES A MIXED STREAM OF CLOCK AND DATA BITS

When the controller logic is writing to a sector, it is varying a single signal line. Whenever that signal is at logic low, a flux reversal is produced on the disk surface; if the signal is logic high, no flux reversal is produced, thus no pulse is on the disk. Timing is how you differentiate clock and data pulses, since they are a single stream on disk. 

The disk drive produces a 720 KHz oscillator signal that is fed to the disk controller logic in the 1130. When that signal is at logic low, we are writing the clock pulse which is always present. Thus, the combined signal line to the disk drive is low when the oscillator signal is low. When the oscillator signal is high, this is the time where we write a pulse for a data bit value of 1 or we do nothing to signify the data value is 0. 

My testbench had to produce the combined signal line that would come from the 1130 logic. It is fed by an oscillator we are generating in our write module. In hybrid mode, I plan to feed the actual 720KHz signal produced by the disk drive but in virtual mode, we generate the oscillator. 

I know the logic gates involved in toggling the combined signal line so I could reproduce their impact pretty faithfully. Bit counter E is on when we are in the check bits, thus this writes a pulse if check bits haven't set the counter to 0 yet. When bit counter E is off, we are writing the sixteen data bits of the word, emitting a pulse if the current bit value is 1. Finally, if -Write Clock Phase B (our oscillator signal) is low, we always produce a pulse for the clock. 

What happens in the real world is that there are delays in the oscillator signal from the disk to the controller, plus delays going through the logic gates, so the combined signal is not edge coincident with the oscillator coming from the disk or my write logic. This had to be simulated to be certain that my write logic would capture the intended data words coming from the 1130 to write onto the disk sector. 

In write mode, I have to follow the 250 us of zero bit values (clock pulse followed by no pulse), then detect the sync word so I could separate the clock from the data bits on the combined line. As well, I had to know when a new word began, just as the controller logic must determine when it is reading. 

When the oscillator signal is high, I open up a timing window but don't look too close to the signal edges. This protects me from the delays I mentioned two paragraphs above. During the window I open in the middle of the logic high portion of the oscillator, I look for a low value on the combined signal line. If I see one, I have captured a value of 1 for that data bit. 

The one and zero bit values are shifted into a register as they coming in from the 1130 controller logic. I keep the two bit counter based on bits with a value of 1. When the sixteenth bit was received, I capture the next four bits only to advance the two bit counter. At the end of the 20th bit, if the counter is not 0 then I have detected an ECC error. The register only had the first 16 bits shifted in, then it was written to the DRAM and the address advanced to the next word in the sector. 

I continue to grab words and store them sequentially in DRAM as the write from the 1130 continues. If we reach the next sector pulse while trying to write, an error is detected and reflected to the program requesting the disk write. As long as I am accurately producing the sector pulses as I capture bits from a read, my logic will work correctly with the disk controller. 

The test bench code to produce the combined signal line properly based on the oscillator signal value is complicated. Not only emitting the sync word so the controller logic is in sync with us, but skipping the check bits and properly delineating the completion of each 1130 data word. On top of that, I had to introduce some delays just to understand what that does to my write logic. 

I am not done yet with testing of the write logic. The test bench code is almost complete to my satisfaction, and I have adjusted some of the write logic already based on that simulation stream. I am going to take my time with this one as it is likely the most challenging part of the logic to get right.