Testing Virtual 2315 Cartridge Facility capturing data written from the IBM 1130 to the virtual disk

RAN WITH THE NEW LOGIC, TESTING WRITE IN VIRTUAL MODE

Armed with the logic analyzer trace of the exact timing that the Virtual 2315 Cartridge Facility (V2315CF) would see of the two related signals, -Write Clock Phase B and -Write Clock and Data that are used during a write to the disk, I arranged the logic in the FPGA to capture the correct bit values so that they could update the sector data in the RAM, just as the sector would be updated on a 2315 cartridge in the internal disk drive of the IBM 1130 if we had not installed the V2315CF to intercept the signals. 

The method used to store data on the internal disk drive (2310) uses two 690 nanosecond long intervals, back to back, to record each bit. The first of the two intervals always has a pulse, which is a clock. The second of the two intervals only contains a pulse if the bit value is 1, otherwise the interval passes without a pulse. 

A sector begins with a long string of 0 bits, allowing the drive to synchronize in order to assign each pulse it sees to either a clock or a data signal line. The first 1 bit defines the start of an 1130 data word begins as the next pair of intervals. The 1130 has words of 16 bits, but on the disk an additional four bits are recorded for error checking. Thus there are twenty pairs of intervals per word, with up to 321 of these fitting on a sector of the disk. 

When a write begins, triggered by the 1130 activating the signal -Write Gate, the disk drive starts generating a clock signal of 1.44 MHz while which is assigned to be the clock, then on the other half of the cycle it will only emit a pulse if the data bit value is a 1. Both the clock and the data interval are s nt on the same signal line -Write Data and Clock, which the V2315CF has to evaluate to determine which bits are a 1 and which are a 0. 

When the -Write Clock Phase B signal drops from high to low, which marks the data interval, my logic will grab the value of -Write Data and Clock and if it is low, the bit value is a 1 otherwise if high the bit is a 0. It had previously waited through the initial sequence of 0 bit values until the first 1 bit is seen. We then collect the next 20 bits and save the first 16 as the word. 

The last four are a special pattern that matches the number of 1 bits in the first 16. This error checking code allows the disk drive to detect errors when reading back the data later; if the error checking bits aren't write, the 1130 flags the data has invalid. 

RESULTS OF WRITING A SECTOR TO THE V2315CF WITH THE NEW LOGIC

I started up the 1130 with the V2315CF in the virtual mode. A mini 2315 cartridge was inserted into the V2315CF and loaded, so that the File Ready light illuminated on the 1130 console. I executed an XIO Start Read instruction which brought the data from the sector into memory. I altered a couple of words of the data and then issued an XIO Start Write to put back the modified data in the sector. 

I zeroed out the area of memory then repeated an XIO Start Read to bring back the value from the V2315CF into memory. If it matches the modified version and as long as the V2315CF validates that each word had the correct error checking code when it was written, then we know that the write is working properly. 

However, initially I was getting garbage in the buffer and back on the mini cartridge after I unloaded it. I traced it down to an error that regressed into the code as I was adding in some diagnostic output. The memory controller was not properly advancing the address after writing each word to RAM. It took a while to find it, some simulation to prove it however the fix was quick. I just returned the proper logic statement to the code and that issue was gone.

However, I was back to the problem that the logic was not capturing the bit stream coming from the 1130 system. I put the logic analyzer on to the V2315CF and captured four signals: 

• -Write Gate (which turns on a write to a sector)

• -Write Clock Phase B (the clock signal I send to the 1130 to cause it to emit both clock and data bits depending on whether this signal is high or low)

• -Write Clock and Data (a value of 1 that is either a clock bit or a 1 in the data. A 0 data value is sent as a zero during the data portion of the prior signal)

• Bit value (a diagnostic output set to 1 when the data bit value of 1 is detected). 

I saw that the logic did NOT identify the start of the data on the sector, which would be a specific bit pattern that is the sync word. The capture during the time when the 1130 is sending the sync word is below. The four signals above are shown in order as horizontal traces. 

The sector begins with a long string of 0 data bits which is terminated by the bit sequence 1 1 1 1 0 causing the logic to begin sending 1130 data words as streams of 16 data bits plus four error checking code digits. The sync word is a word of value 1000000000000000 plus an ECC sequence of 1110 that validates the word as properly formatted. At the end of the sync word, the next bit is the start of the first data word of the sector. 

The -Write Clock Phase B signal alternates strictly at a 720 KHz rate, with the high level denoting the data portion of a bit cell and the low level of this signal signifying the clock portion. During the clock portion of every bit cell, the value of -Write Clock.  and Data is a logic low which means a 1 bit for the clock. There is always a clock bit in every bit cell but during the data portion of the bit cell we either have a logic low on -Write Clock and Data which means the data bit is 1, or a logic high that means the data bit value is 0. It can be confusing to interpret because of the inverted logic - a logic low means a value of 1.

The failure to detect the sync word is visible because the fourth signal in the trace should emit a 1 for each bit position that is transmitted as a 1, but it is a while later before the logic begins emitting that signal. This means it did NOT detect the sync word properly. 

At least I now have a view of the data coming in from the 1130 which should help me devise a strategy for reliably detecting the bit values. A bit of design work, some extensive simulation and then I resume testing in the workshop. 

Identifying issue capturing data on write to Virtual 2315 Cartridge Facility

THE ISSUE I WAS INVESTIGATING

The Virtual 2315 Cartridge Facility (V2315CF) attaches to an IBM 1130 computer and works in conjunction with the internal 2310 disk drive of that computer. The disk uses swappable 2315 disk cartridges to record 512K words of data stored as 1,600 sectors of 321 words each. A word on the IBM 1130 is 16 bits long. 

The V2315CF allows mini cartridges to be used instead of actually reading and writing to a physical 2315 cartridge. The IBM 1130 sees the V2315CF system exactly as it sees the real 2310 drive, other than diverting data to stream on and off of the mini 2315 cartridge instead of the disk surface of the 2310 drive. 

When the 1130 writes a sector of data to the disk drive, the V2315CF should capture the stream of data and use it to update the sector in the RAM inside V2315CF, which will be used to update the mini 2315 cartridge (containing a microSD card to hold the data) when the virtual 2315 cartridge is unloaded at the end of a session. 

Currently the data is not recorded correctly in the RAM and thus the mini 2315 cartridge contents are corrupted for any sector where the 1130 wrote. In addition, the V2315CF checks the data that is coming from the 1130 to be written on the sector. At the end of each 16 bit data word, the 1130 sends four additional bits of error checking code that allow the 1130 to detect if a word is corrupted when being read from disk. Any time the 1130 reads a sector from a mini 2315 cartridge, the V2315CF generates valid ECC bits at the end of each word during transfer into the 1130. The 1130 will see the incoming data as valid. 

The V2315CF verifies that the data word and its ECC bits are valid during the write to a sector - data transfer from the 1130. If we see an error, we turn on a disk fault condition, make the disk drive appear to be not ready as far as the 1130 is concerned, and cease operation until the mini cartridge is unloaded. This should not happen. Somehow I am detecting an error, in addition to not producing a sector whose contents matches the data sent from the IBM 1130 during the write operation. 

REDESIGNED BASED ON CAPTURED LOGIC ANALYZER SIGNALS

I had spotted some reasons that my earlier approach wasn't working. Based on that, I redesigned the logic to be more reliable. Simulation suggested it would work, but of course the proof is in the pudding - I have to test with actual hardware to be sure it works as intended. 

At the same time, I implemented the 90 second wait when the disk powers up in the Raspberry Pi Pico code, rather than in the FPGA where it had been previously implemented. Once the mini cartridge image has been read and loaded into RAM, if the drive is in virtual mode, then the system loops for 90 seconds before it continues to consider the cartridge loaded and make the disk drive ready. 

Having this in the FPGA meant that I had to count to 90 seconds, making use of a pulse I emit once each microsecond for timing purposes. That means I had to count to 90 million, requiring 28 D flipflops and an adder with carries wide enough for a 28 bit integer. This is what pushed the count of required logic elements over the capacity of the Lattice FPGA chip I was using. By moving this to the PICO software I freed up those logic elements and had room left for all the functionality I needed in the FPGA. 

OBSERVATIONS WITH THE LOGIC ANALYZER AND OTHER TOOLS

The logic analyzer captured the signals used by the IBM 1130 to write the sector to the disk drive - -Write Clock Phase B and -Write Clock and Data. It also is triggered by the activation signal to the disk drive -Write Gate and records the output of the V2315CF where I emit the bit value detected when I am capturing each bit. Finally I output a diagnostic signal I can use to track how well my logic is accomplishing the goal of grabbing the data sent by the 1130. 

In addition to the logic analyzer, I have other tools. I can read the sector from the mini 2315 cartridge using a utility tool and programs I provide along with V2315CF. When I write from the 1130 to a sector and then unload the mini cartridge, that new data is inside the mini cartridge. Reading it with my utility programs gives some evidence of what was placed into RAM. 

I had read in sector 0 of the mini cartridge then changed the first few words of the sector in 1130 memory before doing a write of the memory back to sector 0. This should cause the mini cartridge, after being unloaded, to have the original data except for the few words I modified which should capture the values I entered.

It is not working correctly. What I see from the logic analyzer trace is that it is not detecting the sync word, so it starts decoding the words much too late. Below is the entire sector, where the last horizontal line is the 1 bit detection output I created for diagnosis purposes. It should start about 435 microseconds into the 10 millisecond sector, but as you can see it waits until almost halfway through the sector before it begins detecting. 

Here is the sync word coming in from the 1130 but not being detected by my logic. With inverted logic, the third signal line has the clock interval when it is low and the data interval when it is high. The second line is the combined clock and data signal from the 1130, where a low means the bit is 1. There is always a 1 bit in the clock interval (the second line is low at that time), but during the data interval we have a 1 bit for data only if the second line is low. 

The circled area is where the sync word is generated by the 1130. The data bit values are listed in yellow below the data intervals. We see data bit values of 1 1 1 1 and 0, which is the pattern that is the sync word. There was no capture of the 1 bit values in the fourth line, but it should be emitting them. 

A CLUE COMES FROM WHEN THE 1 BIT DETECTOR PULSES START

The diagnostic output signal I captured in the fourth row should be produced as soon as the logic considers the sector to have started. It watches the data stream until it sees the sync word pattern, which will show up in the fourth line as well. That triggers the collection of the 321 words of data for the sector. 

I now suspect that the defect is related to the sector marker pulses. The disk drive generates eight such pulses in a rotation of the disk platter, but the disk hardware hides every other pulse so that the 1130 only sees four sector marker pulses, corresponding to four sectors of data held on a rotation of the disk. 

My state machine that handles a disk write waits to see a sector marker pulse to end before it begins the writing logic. The 1130 asserts the -Write Gate signal low, which begins writing the sector. I suspect that when I see that signal asserted, I have missed the edge of the -Sector Mark pulse and therefore my logic waits until the next pulse halfway through the sector before it starts looking for the sync word. 

I will look at this, simulate it and change the logic so that it is not skipping the first half of the sector. I am hopeful that this will resolve the issue, but will have to wait for a couple of days because I am tied up all day tomorrow at Disneyworld and then guiding friends through the Kennedy Space Center Visitor Center on Friday. 

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.