Debugging the double increment of addresses during a write by the Virtual 2315 Cartridge Facility

MISSING DATA DURING A WRITE APPEARS TO BE A MEMORY ADDRESSING ISSUE

When writing a sector of 321 words to the Virtual 2315 Cartridge Facility (V2315CF), the first portion of the sector is captured correctly but by the middle of the sector, I see the data values being captured are every other word from the 1130 memory buffer. This means we are fetching every other word from memory using the File Address Register (FAR) of the disk controller logic in the 1130. 

The FAR should step by 1 after each memory fetch. The logic requests a cycle steal, a fetch from 1130 memory, with the address set in the FAR. The request signal -CS Req 0 drops low to request the fetch and once it is underway during a 3.6 microsecond 1130 memory cycle, we see +CS Level 0 go high for the duration of the fetch. The data is grabbed during the cycle steal and then when +CS Level 0 drops back to low, the falling edge should cause the FAR to increase by 1. 

Instead, the data returned from the cycle steal is two words past the last one. This suggests that the FAR is double stepping. However, it doesn't do the double stepping until well into the sector. I recorded signals with the logic analyzer to determine if this is what is happening and give clues as to what circuits might be causing the error. 

• -Write Gate
• -Req CS 0
• +CS Level 0
• +FAR 15
• +FAR 14
• -Load File Address
• -Reset File Address
• -B Bit 15
• -Write Clock Phase B
• -Write Clock and Data
• -File Load Gate
• -T6

DEEP DIVE INTO PREVIOUSLY RECORDED LOGIC ANALYZER CAPTURES

I slogged through all the detail of the trace that the logic analyzer captured, recreating the data being written to RAM by my logic and the correspondence with what I was intending to write. I spotted the point where the 1130 went off track. It occured during the 112th word, which should have been 0xC070 but was instead captured as 0x8070. 

The next word, which should have been 0x0071, was instead 0x00E2 and the machine began to step by two addresses at a time from this point until it exhausted the buffer I set up.  The word with 0x00E2 was the 226th word. The address register value while we were processing the 112th word was b0001001101111 (in hex, x26F) and the next word came from address b0001011100010 (in hex, x2E2) which is a huge jump. Further, from that point onward the memory addresses jumped up by two each time instead of one, meaning the data being shifted out by the 1130 to write on the disk was every other word in the buffer from that point. 

The signal that toggles the FAR to add 1 is the falling edge of the +CS Level 0 indicating the end of the fetch and I do NOT see double memory fetch requests on the line -CS Req 0 in the logic analyzer data I have. My next logic analyzer run will capture that signal, thus I can see if we are somehow fetching twice and bumping the FAR twice as a result. Once again, nothing seems to match the pattern and explain why we would work find for 111 words, then have a huge jump and start double fetching or at least double incrementing the FAR.