Another write test of Virtual 2315 Cartridge Facility after correcting FPGA logic

BASED ON DISCOVERY OF THE ROOT CAUSE, I CORRECTED THE DESIGN

The state machine I developed to capture the data from a write command issued by the IBM 1130 to the disk drive started out of the idle condition based on a couple of conditions. One of them was unnecessary since the other condition already encompassed that event. Much earlier, testing had not failed, only due to good luck, but a small change I made a while back to debounce the incoming signal added a few cycles delay which was enough to cause the failure.

The Virtual 2315 Cartridge Facility (V2315CF) sits in between the IBM 1130 computer and the internal 2310 disk drive, substituting data held in RAM in the V2315CF for what would have been read or written by the disk heads. The 2310 disk drive uses interchangeable 2315 disk cartridges, hosting a 14" diameter magnetic platter, to store 512K words of data. 

A rotation of the platter is divided into four equal sized segments, called sectors. A pulse, called a sector mark, is generated by the disk drive although physically the 2315 cartridge has eight slots around its ring thus produces eight sector markers per rotation. The IBM 1130 disk controller logic blocks every other sector marker pulse so that it indicates the start of each of the four logical sectors. The disk arm can move in and out between 203 cylindrical tracks that the head traces as the platter rotates. 

When the IBM 1130 executes an instruction to write to a sector, the programmer specifies which of the four sectors will be replaced. The 1130 is keeping track of which sector is currently passing under the disk head and when the sector mark arrives for the sector being requested, the 1130 asserts the -Write Gate signal to begin the writing. 

My state machine looked for the -Write Gate signal to go low but also waited for the falling edge of the -Sector Mark signal. If the sector mark pulse occurred coincidentally or after the falling edge of -Write Gate, my state machine would begin the write process. I did this based on some timing diagrams from IBM maintenance documentation, however the diagram implied that -Write Gate changed prior to the sector mark pulse. This was incorrect but the assumption drove my logic design. 

The V2315CF generates a clock signal, -Write Clock Phase B, which it sends to the 1130. The 1130 uses a 1.44MHz oscillator in the disk drive to read and write data. Each 'bit cell' is divided into two halves, each 720 ns long. Because the FPGA clock is 25 nanoseconds, I am actually generating 725 ns intervals rather than 720. In the first half we are transmitting a clock bit of 1 and in the second half we send the data bit value, either 0 or 1. 

The 1130 outputs a combined signal -Write Clock and Data which always goes low for one half of the clock signal, but is either low or high depending in the other half based on whether the data bit value is a 1 or 0 respectively. The logic is inverted: a low level is a value of 1. Thus, -Write Clock and Data alternates a constant 1 bit with a data bit that is either 1 or 0. My logic extracts the data bits from that stream and writes them into RAM in the location assigned to the sector.

The state machine watches the data bits being extracted, waiting during an initial long stream of 0 data bits for a specific sync word pattern 1 1 1 1 0 that tells us the very next data bit will be the low order bit of a 16 bit 1130 data word that has a four bit error correcting code appended (thus 20 data bits per 1130 word). We grab the 16 bits of data, validate that the error checking code is correct, then store the word and evaluate the next sequential data bit as the beginning of word 2 of the sector. This continues for up to 321 words, the max capacity of a sector on the 2315. 

When I added a debouncer to the -Write Gate signal in order to ensure that a glitch wouldn't spuriously trigger the state machine, it added a bit of delay to that signal. The undelayed -Sector Mark signal therefore had its falling edge before my state machine saw -Write Gate and that meant the state machine did not receive the conditions needed to begin. 

Since the 2315 cartridge actually generates 8 sector pulses per rotation - the 1130 ignores every other pulse so that it can create four larger sectors instead of 8 small ones. However, the -Sector Mark pulse I see with the V2315CF is the undivided signal with 8 pulses per rotation. Thus, the second sector mark pulse does arrive in the middle of a sector during the write - it is normallyignored . My state machine, having failed to leave the idle state when -Write Gate first was asserted, started at the midway point of the sector. 

It is too late at that point to see the sync word - that comes about 10% of the way into the first half of the sector. My logic does come across a data bit sequence that is 1 1 1 1 0 at some point and begins interpreting what follows as the low order bit of word 1 of the sector. This produces gibberish, which is what I saw stored in RAM after a write was issued by the 1130. 

Examining the logic diagrams for the 1130, I can see that the -Write Gate signal is generated from the issued request for a write when the correct sector number is arriving but also when the falling edge of -Sector Mark takes place. Thus, that condition is already implicit in -Write Gate going low. I erroneously enforced it in my state machine but the relative timing of the two signals were unfavorable for correct operation.

The change was very simple. I didn't monitor the falling edge of -Sector Mark as a start condition, only -Write Gate, which fixed the problem. I generated a new bitstream to load into the FPGA chip in the V2315CF.

RESULTS OF TESTING WITH THE CHANGED LOGIC

The test I use is to first read in a sector into a buffer in 1130 memory, then manually change a few words before issuing a write of the same sector. This should replace the contents of the sector with the changed data. I can validate that by reading it back with another read command, but also examined the mini 2315 cartridge that was loaded into the V2315CF during the testing. 

When I unload the cartridge at the end of the test, the V2315CF writes back RAM to the microSD card inside the mini cartridge. This can be examined on my PC using a utility reader and a program to display the contents of any sector. It proved that the modified data was what was placed on the cartridge. 

I also will see the bit pattern extracted by my state machine using a logic analyzer to capture the -Write Gate, -Write Clock Phase B, -Write Clock and Data, and a diagnostic output signal that showed whether each data bit was captured as a 1 or a 0. The results were much better, with the write occuring immediately as the -Write Gate signal was asserted low. It did detect the sync word and begin collecting data. 

However, I wasn't happy with the quality of its operation. I noticed a few places where it skipped over a data bit value of 1. These seemed to take place soon after a glitch on the -Write Gate signal. I had debounced that signal, thus a glitch would need to stay on for 400 nanoseconds or longer in order for my state machine to see the signal as reset. The glitches were all 10 to 20 nanoseconds long, much too short to pass through my debouncer. 

Instead, it appears that another logical condition that I combined with the -Write Gate, indicating that a cartridge is ready for use, may have glitched. This condition is detected by the Raspberry Pi PICO processor based on having loaded a virtual 2315 cartridge and the drive becoming ready to access. It should not be reset unless we turn off the drive or it becomes not ready due to a fault. 

However, this is just a bit sent over the SPI (serial peripheral interface) link between the PICO and the FPGA logic. A message type of x00 will set the cartridge status based on bit 4 of the data byte in that message. If the SPI link is spuriously processing a message of that type it might be resetting the bit temporarily, however whatever condition is causing my state machine to believe that the write should end is quickly restored. Thus, I have my suspicions that the SPI link is not at fault in this error. 

However, since it is the only condition besides -Write Gate that is used to abort the state machine, I don't see an alternative explanation at this time. What does appear to be happening is that my write state machine is aborting back to idle soon after a glitch on -Write Gate that shouldn't pass through the debouncer. 

If the signal is seen as deasserted or the cartridge ready condition is withdrawn, the state machine goes back to idle. Because -Write Gate is intentionally asserted, once the glitch conditions expire the state machine will start over, scanning for another sync word. If it sees a 1 bit it will treat that like a sync and begin extracting data again. From the time when it went to idle until the time it sees the first data bit of 1, it is skipping over data. 

I removed the cartridge ready condition from all the aborts. It is now only required to start the write state machine out of idle, otherwise we will only abort on deassertion of -Write Gate through the debouncer logic. 

I suppose another possibility to consider is if the power to the V2315CF unit is drooping or noisy, it might be both the reason I see the glitch on the -Write Gate signal and the cause for the state machine to abort back to idle. I will put an oscilloscope on the 5V power rail going into the V2315CF main unit and set it to trigger if the voltage dips below about 4.8V. I can add some smoothing with a big filter capacitor if this is the cause. 

DEVELOPED TOOLS TO HELP ME BETTER WATCH THE WRITE PROCESS

My main data capture is a logic analyzer that is monitoring four signals, triggered when -Write Gate has a falling edge and recording for long enough to cover multiple sectors. I use the program DSView that comes with the analyzer to look at the signals and evaluate my FPGA logic strategy based on the actual signals being used. 

The program has an option to produce a CSV (comma separated values - file format used with Excel spreadsheets) of the data during the period when the signals are actively changing. The logic analyzer takes a sample of the signals every 10 nanoseconds and records the time when at least one of those signals changes along with the four signal states. 

A write to a sector is transferring 321 words of data from the 1130 to the disk. It begins with a preamble of about 250 microseconds where the data bit value is always 0. This helps the disk drive determine which pulse on the disk was recorded as a clock bit (always 1 so always a pulse) so that it can know where the first half of the bit cell begins. It then watches the secodn half of the bit cell, the second 725ns of the bit cell, for a pulse to indicate a bit value of 1 otherwise the absence of a pulse during this half is taken as a zero. 

Data is serial on the disk surface - a stream of over 6,420 bit cells. to record 321 words of data. Each word on an 1130 is 16 bits long, but when written on disk, an additional four bits is appended to each word that forms an error checking code (ECC). Thus a word requires 20 bit cells in total. The value of the ECC bits are checked against the 16 bit data word such that the sum of all data bits in the word plus the ECC must add up to a number which is an even multiple of four. 

A data word of x1000 for example has only one data bit set to 1 so it needs the ECC bits to contain three 1 bits in order to arrive at an even multiple of four at the end of the word. A word of xFFFF already has 16 bits set to 1, thus already an even multiple of four so the ECC bits must all be 0. 

Because this is a serial stream, the disk drive has to determine which bit cell is the start of a new word. This is assisted by a sync word beiing written. The sector begins with that preamble of all zero bit values, followed by the sync word. The pattern of the sync word is 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 and ECC bits of 1 1 1 0. The preamble is a long string of zero bits, so the first data bit of 1 is considered the end of the sync word (plus its four ECC bits of 1 1 1 0). This defines the very next data cell after the last ECC bit as the first bit of the first word of the sector. 

Words are streamed out twenty bit cells at a time until the count of words to be written is completed. Normally, the 1130 uses 321 words for a sector so that is the reason we will see 6,420 bit cells from this point to near the end of the sector. Recording the state of those signals from the time that -Write Gate is first asserted until it is turned off produces 28,900 rows of spreadsheet data. I save this as an Excel spreadsheet file. 

I wrote a Python program that reads in the spreadsheet file, locates all the points where the -Write Clock Phase B signal has a falling edge and captures the value of the -Write Clock and Data aignal at that time. Because the signals are inverted, I flip it so that a -Write Clock and Data value of 0 is recorded as  a bit value of 1 and vice versa. 

The program watches for the first data bit that is a 1 (the sync word) and begins interpreting bit cells after the ECC bits of the sync word are processed. I collect the 16 data bits, which are recorded in reverse order to how they are stored in IBM 1130 memory, convert them to the correct hexadecimal value in the order they exist in memory and print them. I print the word number and the timestamp of the start of the word. 

I then collect the ECC bits and perform the validation, printing an error flag and the ECC bits if they word is not valid. This should match the data I wrote from the 1130 that the FPGA is capturing from the data stream. It should also match the data that is recorded on the virtual 2315 cartridge by the V2315CF when I display the sector after the testing. I can use the timestamp from the Python program to find the spot in the logic analyzer trace where the word starts, if anything is wrong with how it is captured. 

The trace is about 7,130 bit cells long, which is why I needed to pointer into the timestamp to help me look closer at any point where I don't like the results. 

I took the existing data at the first sector of the virtual 2315 cartridge, overwrote the first few words with x6969, x0000, x0F00, x0000 and x0000 leaving the remainder as it was. Word 9 of the existing sector had a value of x0002 and then the next non-zero word was numbrer 32 which should have been x00EF but is incorrect in the output above. The bit pattern on the disk should have been 1 1 1 1  0 1 1 1  0 0 0 0  0 0 0 0 with ECC bits 1 0 0 0 yet the data captured had shifted by one bit cell. x00EF became x01DE because of this shift. 

The machine was capturing successfully when it saw the word 9 (x0002) but got out of sync somewhere between there and where word 32 began. Each bit cell is 29 microseconds long, and the times seem to line up consistent with that for the start of each of the 32 words shown above, but somehow the -Write Clock and Data value slipped. 

Looking at the trace at the start of word 32, we can see that the 1130 did indeed send us the first three bits as 0 1 1 instead of 1 1 1. The top trace is -Write Gate, the bottom trace is -Write Clock Phase B and the middle trace is -Write Clock and Data, all of them inverted logic. 

When the -Write Clock Phase B is high, this is the second half of a bit cell where the data bit value is transmitted. The first bit has -Write Clock and Data high, e.g a data bit value of 0. The next two bit cells have data bit values in -Write Clock and Datathat are mostly low, thus denoting a bit value of 1. This is what my FPGA logic captured, what the logic analyzer and Python program captured, but not what I wrote. 

This suggests to me that the 1130 is seeing glitches on the -Write Clock Phase B signal causing it to think it missed a bit cell somewhere between words 9 and 32. The logic analyzer is capturing the source of the signal -Write Clock Phase B which is the V2315CF unit, coming out of my FPGA logic. On the logic analyzer the signal looks completely clean with no glitches that might suggest a reason the 1130 got out of sync.

I will need to observe the other end, where the signal arrives into the IBM 1130, to see if glitching is occurring over the signal path. I will capture another trace with the logic analyzer, hooked to pin B03 of slot K6 of compartment C1 of logic gate A in the 1130. It is also tied to pin D12 of slot L7 in the same gate and compartment. The first pin is used to cause the 1130 to shift bits out one by one, serializing each word, while the second pin is used to switch -Write Clock and Data between a constant 1 value for the clock half and the data bit value for the data half of the bit cell. 

I will hang a scope probe on one of the two pins above and the logic analyzer on the other, since they are both connected to the same signal coming from the V2315CF. 

There are several theories to be tested, if you have made it down to here in this blog post. First, I will be validating that the power is not dipping on the V2315CF causing glitching. Second, I will have bypassed the role of the SPI link so that it can't cause the resetting of the write state machine that I observed. Third, I will look at the -Write Clock Phase B signal as it is connected into the IBM 1130 disk controller logic circuitry. 

Installed prototype enclosure and attempted testing of Virtual 2315 Cartridge Facility

INSTALLED THE POWER COMPONENTS IN THE PROTOTYPE ENCLOSURE

The enclosure has an incorrect opening size for the Virtual 2315 Cartridge Facility (V2315CF) main unit, but I used it to work out the mounting locations for the various power components that fit inside. These are the power distribution pcb, the power supply, and the timer. I routed all the wiring through the side holes and the two ribbon cables through the rear hole of the enclosure.

This is the view that the operator sees when they tilt the top right cover of the IBM 1130 up (you can just see the hinge on the right of the picture), with the tabletop in front and the enclosure sitting atop the internal disk drive of the IBM 1130. The 3 3/4" diameter mini versions of the 2315 disk cartridge that are used with the 1130's internal disk drive (2310) are inserted into the opening on the right, which is a scaled down model of what the opening of the 2310 looks like. 

ATTEMPTED TO COLLECT DATA FOR THE WRITE ISSUE

I had brought out a signal on one of the unused output lines of the main unit of the V2315CF so that I could capture it along with the -Write Gate,  -Write Clock Phase B and -Write Clock and Data signals that the 1130 sends to the 2310 disk when it is writing a sector of data onto the 2315 disk cartridge. The V2315CF intercepts this data and stores it in RAM so that it can be written out to the mini 2315 cartridge which serves as the disk cartridge for our system with the V2315CF installed. 

The testing is simple. I first issue a read command from the 1130 that requests the data from cylinder 0, head 0, sector 0 be brought into memory at the location specified in the I/O instruction. The data on the mini cartridge should appear there - it has been reading correctly up until today - but instead of the valid data I found the filled with random garbage, mostly 16 bit words of 0xAAAA. 

If it had read correctly, I would then modify a few words in the memory buffer and issue a write command to store the buffer back in cylinder 0, head 0, sector 0. When I unloaded the cartridge at the end of the session, what had been written back to the mini cartridge was just the random junk, not the changes I made. Further, I found random junk written through many other sectors on other cylinders. 

It is acting as if the RAM is not working properly now. When I load a mini cartridge, the V2315CF reads the contents from the mini cartridge and stores it in RAM, then turns on the File Ready status allowing the 1130 to issue I/O instructions to the disk. However, the data is either not loaded properly into RAM or corrupted somehow while the testing is underway. Another possibility would have been that the rewrite to the mini cartridge when we turn off the disk drive is what is failing, except that the read command is finding the garbage so it is definitely in RAM. 

I may have introduced this error during the recent code changes I made for the diagnostic output needed to conduct this test. I will go home and use simulation to examine the behavior of my logic to discover what is going wrong. 

Test build of Virtual 2315 Cartridge Facility enclosure and mini disk drive

ENCLOSURE TO MOUNT VIRTUAL 2315 CARTRIDGE FACILITY IN IBM 1130

The Virtual 2315 Cartridge Facility (V2315CF) is installed inside an IBM 1130 computer with the main enclosure, constructed of acrylic, bolted to the top of the internal 2310 disk drive of the computing system. Cables from that enclosure connect to other elements of the V2315CF, as well as to the 2310 disk drive and the 1130 system itself. The 2310 disk drive accepts 2315 disk cartridges, which enclose a 14" disk platter that holds 512K 16-bit words of 1130 data. 

The enclosure front plate houses the main electronics of the V2315CF on the left and a miniature version of the front of the 2310 disk drive on the right. Mini 2315 cartridges are inserted into the mini disk drive, in the same way the real 2315 is inserted into the 2310 drive from the front of the IBM 1130. A switch on the miniature disk drive is an analog of the motor on/off switch of the real 2310. 

The mini 2315 cartridges hold a microSD card inside them that stores the 512K words of data that would reside on a real 2315. When the mini cartridge is inserted into the mini drive of the V2315CF, the motor switch on the mini drive turned on and the switch on the main electronics panel is flipped to Load, the contents of the mini cartridge are read and copied into RAM inside the main electronics. The File Ready lamp on the IBM 1130 console turns on when the V2315CF is ready to let software read, write and seek between cylinders of the virtual disk drive. 

The V2315CF supports two modes - real and virtual. In real mode, the physical 2310 drive in the IBM 1130 is switched on with a dummy 2315 inserted. It spins and the disk arm moves around as commanded by software in the 1130, while the V2315CF transfers data from the mini cartridge instead of the disk heads of the real 2310. In virtual mode, the physical 2310 drive is not turned on, but the V2315CF instead simulates its behavior so that the 1130 software can access the mini cartridge. 

When the motor is turned off and the main electronics switch flipped to Unload, the contents of RAM, which may have been updated as the 1130 software wrote new data to sectors of the 2315, will be transferred back to the microSD card inside the mini cartridge. Thus, the data is permanently saved on the mini 2315 just as it would be on a physical 2315 cartridge used with an unaltered 1130 and its 2310 disk drive. 

PROTOTYPE ENCLOSURE LASER CUT AND GLUED TOGETHER

My friend Barry Ward cut the design on some smoked black colored acrylic and glued it together. I added the support brackets and tested the mounting of all the components. Here I am looking to discover all the interference issues or other changes that will make the production version easier to build and service. 

TESTING PROTOTYPE OF MINI DISK DRIVE DESIGNED BY BARRY WARD

Barry Ward measured the front entrance of the 2310 disk drive from the IBM 1130 system at my workshop, along with a 2315 disk cartridge, and modeled miniature versions that will be used with the V2315CF. 

The mini 2315 cartridge is 3 3/4" in diameter and proportional to an IBM built 2315 cartridge. It mounts a PCB underneath with a microSD socket, a few components and a male 2x4 header that is in the rear. That header plugs into a female socket inside the disk drive when the mini cartridge is slid into the mini drive.

The front of the disk drive in the IBM 1130 is accessed by swinging the right front door open on the 1130 system, where you see the opening of the disk drive, with a blue handle used to open and close the drive, plus a motor switch. 

The drive handle is opened in the real 2310 drive, allowing a 2315 disk cartridge to be slid into the drive or pulled out. When the handle is returned to the vertical position, the cartridge is ready to be used. 

Prototype without motor switch mounted

The motor switch can be recreated with a very small toggle switch that is only a bit out of proportion (bigger than the real drive scaled down). Barry and I did some careful modeling in CAD and he is test fitting the modified front bezel right now. 

What a real 1130 internal drive front looks like

Barry has laser cutters and 3D printers in his home (and heavier duty machinery in his workshop). He is making the next revision of the prototype while I finish the work on the enclosure and other parts of the V2315CF. 

Debugging write of Virtual 2315 Cartridge Facility - ensuring data is captured correctly

WRITING DATA EARLIER IN THE CAPTURE OF EACH WORD

My logic had been waiting until the last of the twenty bits had been captured - the 16 bits of the data word and then the four error checking code bits that validate the integrity of the data. That was unnecessary and put the request too close to the point where we reset to begin accumulating the next word. I now lock in the data value while we are starting on the first ECC bit and request the write while we are starting on the second ECC bit. The RAM controller will put the word away in RAM while we are finishing up on the ECC bits.

Since it was possible that my garbled data was a consequence of address and data bits changing too close to the time when the RAM controller is driving the write, starting earlier should eliminate this risk. I updated the FPGA logic and loaded it into the Virtual 2315 Cartridge Facility (V2315CF) main unit. I again repeated my test where I read in a sector, changed a few words and then did a write to replace the sector. 

RESULTS OF TESTING WITH THE CHANGED LOGIC

The data was still wrong, but when comparing the data on the mini cartridge after the write with the original contents, I noticed that the sector was only changed up until the halfway point. That was a major clue. I went through the entire logic for writing to a sector, including the process of storing it in RAM. I expanded my simulation testbench to track all the aspects of reading and writing to RAM as well as the SPI link data that flows between the PICO and the FPGA.

I identified two issues that have to be resolved. First, the data is not being stored in RAM correctly. Second,  if I restore the logic that locks up the disk drive and puts it off line when an ECC error is detected during a write from the 1130 to the V2315CF, the fault light goes on during the write. That means I am detecting an ECC error during the write logic somehow, although the logic analyzer trace I collected makes it appear that I should be grabbing it correctly. 

The ECC error signal is routed on the V2315CF bus connector B pin U2 which I should be able to detect with the logic analyzer. This will tell me where in the sector write the error is first detected and that may serve as a clue. 

My next diagnostic change will be to output the data bit value that was captured, using the same connector B pin U2 of the V2315CF. Syncing that with the -Write Clock Phase B and -Write Clock and Data signals being captured on connector A pin T2 and connector A pin F2 respectively, I can see any place where I DON'T correctly capture the data value coming from the 1130. The changes were made ready and the logic will be installed into the V2315CF FPGA for the next testing session. 

EXHAUSTIVE SIMULATION RUNS AND INCREASINGLY SOPHISTICATED TESTBENCH

I have not been able to cause the ECC errors to show up when simulating the logic. I have not thought of a type of glitch or timing issue in the incoming signals that should produce the error, but keep adding details to the simulation allowing me to experiment until I can recreate the failure. Hard to fix it when the nature of the failure is unknown.

I should be able to triangulate in on the cause by alternating simulation sessions with live system data collection. Fixing the issue is easy once I know what is going wrong, but the real work has been in capturing the errors. 

Deglitching the write output of the 1130 for Virtual 2315 Cartridge Facility - part 2

RESULTS OF TESTING A WRITE TO THE V2315CF USING MY NEW DETECTION METHOD

I loaded a test 2315 cartridge into the Virtual 2315 Cartridge Facility (V2315CF) in virtual mode, so that the IBM 1130 saw the disk drive as ready for activity about 90 seconds after loading. I had a few hand inserted instructions in memory to be able to test the disk.

I coded an XIO Start Read command to the disk for a full sector of 321 words, bringing the current data on the mini cartridge into memory. I then modifed a few words of the memory and changed the instruction to an XIO Start Write. This will capture the changed data from memory and replace the contents of that sector inside the V2315CF RAM. 

I can then zero out the memory location before doing another XIO Start Read, ensuring that what comes back from RAM (from the disk) is what I intended to write. If not, I can see how close or far it is from properly capturing the stream of data coming from the IBM 1130. The flag from my logic when it detects an error in the error checking (ECC) bits was routed out to a connector so that I could capture it with the logic analyzer and oscilloscope. That would tell me where in the sector it first detected invalid data. 

RESULT OF FIRST TESTS

My logic analyzer is watching the incoming data from the 1130 on -Write Clock and Data and observing the signal that is raised if the four error checking code bits at the end of each word indicate some error grabbing the word. The error signal was never raised - my logic is grabbing the data properly, I believe, and never sees an ECC error. 

However, when I read back the sector that I wrote, I get random garbage. I used my utility box to open the mini cartridge on my laptop and then examined the sector with the showsector.exe program I developed. The data matches - it is the same garbage that I see when I read the sector. The data that is being carefully assembled and error checked is somehow not getting put into RAM correctly. 

This leads to to suspect the interaction of the logic processing the write from the 1130 and the logic that updates the RAM. I will do some careful examination - the likelihood is that I am not holding the data value steady long enough for my RAM module to lock it in. I will do some simulation aimed at testing this theory and look for ways to trigger the RAM module earlier. 

BUILT ANOTHER COPY OF THE V2315CF FOR THE SYSTEM SOURCE MUSEUM 1130

Since I intend to install another instance of the V2315CF on the 1130 system up in Maryland, I wired together the entire power system, built another 2310 Interface Board and have the second main unit ready to transport once I have all the debugging wrapped up.

Final wiring of Virtual 2315 Cartridge Facility into the VCF - Infoage Museum IBM 1130

POWER FAIL PROTECTION FOR V2315CF INSTALLED

At the heart of the Virtual 2315 Cartridge Facility (V2315CF) is RAM that holds the entire contents of a 2315 disk cartridge. The persistent home for each cartridge image is on a microSD card inside the mini cartridge, but it is read into RAM when loaded so that the contents can be read and updated as IBM 1130 programs issue read, write and seek commands. After powering down the disk drive, the unload switch on the V2315CF triggers it to write the contents back to the mini cartridge thus the changes are persistent.

If system power were to abruptly fail, any changes that were made to the cartridge image in RAM will be lost since the user is unlikely to hit the Unload switch in time to have it fully written. In fact, it could produce a corrupted version, rending the mini cartridge contents lost. To avoid that risk, I designed a way to provide backup power for enough time to write the contents of RAM written back to the microSD card. We can't depend upon the operator to recognize the issue and flip the switch to Unload, so this process is automated.

I have dual power sources attached to the V2315CF main unit, one of which is a 12V motorcycle battery. The connections run through the Power Distribution Unit (PDU) PCB. A timer module is triggered by the falling edge of the 12V system power, which switches  the V231CF main unit to the battery for 45 seconds before shutting off. That is plenty of time to complete an unload of the RAM contents to the microSD card. 

A sensing circuit on the PDU pulls a signal wire down to ground at all times when the system 12V supply is on. When the power drops out, the signal is pulled up by the input pin on the PICO processor thus the code can detect the failure as soon as power drops. This does an emergency unload of the RAM back to the mini cartridge. The front panel of the V2315CF shows the unloading of the cartridge image back onto the mini cartridge. 

The final element of this power protection is a means to keep the motorcycle battery charged so that it is ready to support an emergency unload. A smart charger manages the state of the battery, doing trickle charges to keep it at the proper state of charge. That smart charger is plugged into a utility socket on the side of the 1130, inside the right side cover. This outlet is always powered, even when the 1130 system is turned off, as long as the system main power plug is connected to building power. The trickle charger does not impact the use of the battery during an unplanned power outage. 

The 1130 handling of power failures is quite compatible with this design. If the input power drops or the main power switch is flipped off, the main power rails sag rather rapidly. A sensing ciruit in the system detects this and opens a relay to disconnect the 12V and 48V supplies from the rest of the equipment. All of the bulk capacitors for the system's 12V supply are on the other side of the relay from the loads, so the power disappears quite crisply. 

There is buffering in the power supply module that converts 12V down to 5V for the V2315CF, enough to allow it to continue working while the time delay relay quickly connects the battery to the power supply module. The relay stays energized for about 45 seconds once it trips, then reconnects the V2315CF to the 1130 12V supply which is unenergized. The V2315CF turns off very soon after this. 

PERMANENTLY WIRED ALL THE PARTS OF THE V2315CF INSIDE THE 1130 SYSTEM

I placed the battery inside the 1130 at the base and secured it. I completed wiring the power supply module, timer and trickle charger together along with power down to the 2310 Interface Board. I have tested that this system works as intended thus it is time to make it permanent. I used 18ga stranded wire to make all the connections as neat as possible. 

I had worked out a way to wire everything together that only required two junctions to be made of wires; all the rest were interconnected on the power distribution board. The Power Distribution Board is designed to help with the interconnection of all these elements - 1130, battery, charger, timer, failure detection signal, 2310 Interface Board, and the V2315CF power supply module. I re-used the PCB for the power distribution board from an earlier version, but without the diodes installed. Instead, two wires tied together three holes to make the board fit the current design.

A short extension cord with a flat plug is connected to the IBM 1130 utility outlet and has the trickle charger inserted into its other end. All of the boards and components other than the 2310 Interface Board, battery and extension cord will sit inside the plexiglass enclosure that is mounted on top of the internal 2310 disk drive inside the IBM 1130. At the current time, I have not completed the enclosure so they sit atop the disk drive. 

TIGHT FIT IN FPGA REQUIRES BELT TIGHTENING OF CODE

The Lattice ICE40HX1X FPGA chip in the V2315CF main unit is limited in the capacity it provides for logic elements. Often when I make a seemingly small change in the Verilog code, during the routing and placement phases of the IceCube2 toolchain, I will get a message that the design needs more Programmable Logic Blocks (PLB) - a mix of lookup tables, flipflops and related elements. 

The chip provides 160 PLBs but recently I saw it request 167. If I work to remove some code in the FPGA that isn't strictly necessary, or recode some function in a way that needs fewer flipflops or gates, I can get it to fit. Often, it will initially claim that it needs 163 but is able to cram everything into the 160. It appears 167 is just too far over the limit for the toolchain to find a way to squeeze into 160.

This did slow me down in doing the write functional testing recently. I find that I suddenly blossom the requirements so that I can't generate the bitstream to load into the FPGA, when I whip up what should be a trivial change, such as routing a signal to an external pin or blocking the logic from considering an ECC (Error Checking Code) error to be a fatal disk failure. This just adds time and a touch of frustration to the debugging and resolution activities. 

Deglitching the write output of the 1130 for Virtual 2315 Cartridge Facility - part 1

EVALUATING STRATEGY FOR DETERMINING BIT VALUE

The IBM 1130 writes to disk alternating values on the -Write Clock and Data signal line, with a 0 always written to -Write Clock and Data during the first half which represents a self clocking pulse and then writing the inverse of the bit value during the second half. The two halves are 1.38 microsecond intervals driven by the 720KHz clock produced by the internal disk drive. That self clocking signal, delivered on the -Write Clock Phase B signal line, is 0 during the clock (first) half and then 1 during the second half when the data bit value is written.

The logic in the IBM 1130 that produces the -Write Clock and Data line is combinatorial, driving a 0 value while the -Write Clock Phase B is 0 and then outputing the current bit value, inverted, while the -Write Clock Phase B is 1. However, there are glitches produced because this is not generated by clocked logic, so time delays in signal propagation produce some glitches that are too fast for the internal disk drive circuitry to react to. 

During the low phase of -Write Clock Phase B the output of -Write Clock and Data is low. In the high phase of the clock, we drive -Write Clock and Data low during a write in one of two cases, represented by the two A (and) gates on the left. The bottom one takes the bit being shifted out of the data register during the first 16 clock cycles of a word. 

The top one is used during the last four cycles, those that will produce the error checking code. As long as the total count of 1 data bit values sent is not an even multiple of four, -Zero Check Count is high causing the -Write Clock and Data value to be low producing a 1 bit. As soon as the total count becomes 0 modulo 4, -Zero Check Count is low which blocks the upper gate from emitting any further 1 bits. The remaining ECC bits are therefore seen as 0. 

Other factors contribute to glitches as well during the data (second) half. Any glitch in the -Write Clock Phase B signal as received by the 1130 will falsely flip the gates to pass through a 1 as if it were the clock half instead of part of the data half. A signal flaw in -Write Clock Phase B produces a spurious 1 bit value if it happens when we are evaluating the signal -Write Clock and Data as the data bit value. 

To bolster the reliability even further, I introduced a method that could block the effect of most short term glitches. When the -Write Clock Phase B rising edge occurs, we begin counting all the FPGA clock cycles (one per 25 ns) where -Write Clock and Data is low, that is has a bit value of 1. When we get to the end of the data phase and -Write Clock Phase B has dropped to low, we judge if we saw a 1 by whether the count of cycles with a 1 detected is more than 15 out of the 29 cycles during which the data value is being transmitted. 

I found a theoretical vulnerability in how I implemented the detection algorithm. If we have a glitch in the -Write Clock Phase B such that it drops low for a cycle or two when we should be in the data phase, this can interfere with the counter mechanism I used. I reset the count when I see a rising edge of the clock; if we had a glitch that dropped the clock and then it goes back to its correct high value during the data phase, the counter gets reset to 0. If the glitch happens later in the data phase, even with zero glitches during data we can't count high enough to meet the bar for detecting that the data bit value was 1. 

Late glitch guarantees bit value seen as 0

The graphic above shows the -Write Clock Phase B signal, where the high portions are when we should be looking for a low value on -Write Clock and Data to count it as a possible data bit of 1. When a glitch happens relatively late in the high portion of the clock, the count is reset and cannot count high enough to achieve the minimum of 15 detections even if the data signal -Write Clock and Data is low for the entire time of the clock phase. 

The reality for this project is that I generate the -Write Clock Phase B inside my FPGA, thus I do have a perfect internal clock that I can use to drive the decoding. This reduces the impact of glitches, as they are only seen on the incoming -Write Clock and Data line. These can be induced by glitches in the -Write Clock Phase B as it is used inside the IBM 1130 disk controller circuitry, but that is the purpose of my counter and threshold logic. 

EXAMINING LOGIC ANALYZER OUTPUT TO EVALUATE METHODOLOGY

My current design looks at the value of the -Write Clock and Data signal at the time that the -Write Clock Phase B signal has a falling edge. If -Write Clock and Data is low, I record it as a bit value of 1, inversely a high signal denotes a bit value of 0. 

I converted the logic analyzer data to a spreadsheet,  hiding all captures except when the -Write Clock Phase B signal changed from 1 to 0. I took the inverse of the -Write Clock and Data signal as the bit value. After the correct interval for a string of all zero bits, I saw the proper sync pattern which is a 1 bit followed by the four ECC bits of 1 1 1 0 and thus could interpret all the following data bits as words. 

I recorded the bit values as they would be interpreted by my logic, counted the number of bits in each block of 20 that had a value of 1, and checked that this count was 0 modulo 4 which is the error checking algorithm. I also verified that the data that would be captured was exactly what was in memory when I issued the XIO Start Write command on the IBM 1130 to do the write. 

It all looked as if it would be perfectly recorded using the algorithm, in spite of the fact that the V2315CF was flagging an ECC error on the read. The timing was correct as well - the entire sector of 321 words took 9.311 milliseconds from the beginning of the first word until the end of the final word (321). With 10 ms available for a sector, this was exactly what I would expect. I also checked the time between words.

To help evaluate what is taking place, I temporarily blocked the ECC error flag from triggering a disk fault. That will allow me to read back what we wrote and compare it. If I see any words that don't match what I had in memory for the write, that may suggest where to look further. I also brought the ECC error detection signal out on the main V2315CF box on connector B pin V2 so that I can spot it on the scope and logic analyzer as it is turned on. Next session I will make use of this modified logic to test how well my logic does the job and whether there are any further subtleties I need to address.