DOCUMATION READER INTERFACE AND ADAPTER
The error I encountered at the end of last week, where the Documation reader logic had received 79 columns of data rather than 80, drove me to audit the logic behind my serial link and interface. I wanted to see if there were any circumstances that could cause me to miss the index marker signal.
Based on the signalling rate and number of bits involved in the sequences I use in my main loop polling the interface, the time between polls is normally less than 175 microseconds when I am reading inputs but could extend to just under 250 microseconds if there is an output signal change that must be written in addition.
The Documation reader guarantees that the data values are valid for a minimum of 429 us after the index marker pulse rises then falls. My hardware in the interface generates a signal lasting 280 us at the rising edge of each 6 us index marker pulse.As long as my serial link polls pick up the activated signal during its 280 us life, I can latch in the column's data value successfully.
Even at the longer timing inherent when there is a changed output signal to send, the 250 us poll interval is certain to pick up the extended index marker signal of 280 us. The data is valid long enough to ensure I have the proper data values for the 12 rows of the card column even if I catch the extended index marker at the worst case 250 us after it starts.
I will verify the timings with a scope on the 280 us timer in the interface and a timing signal on the fpga marking each round of the serial link polling that I can capture on the logic analyzer. If the poll cycle time is longer than I think and the extended index marker is shorter, it is conceivable that a small fraction of columns will be missed.
If there is a bit error on the serial link, I can miss a set of signals for one round of the protocol, extending the window where the extended IM could be missed to somewhere between 350 and 500 us, which is not only longer than the extended IM pulse but could also result in invalid card data since it might extend beyond the end of the data validity guarantee time of 429 us.
My logic ignores any input if there is an error detected in that byte of the transfer, which avoids data corruption but could give us the worst case timing that misses the extended IM. I need to terminate the Documation read cycle and generate a feed check for the 2501 when it attempts its next feed cycle. That ensures we know that we don't have guaranteed access to all 80 columns and force a re-read of the card.
I instituted a watcher machine that wakes up only during the period in a Documation card reader cycle when it is looking for the card column data, spots any error on a serial link transaction and triggers the abort. The abort ends the read cycle, marks the FIFO as filled so the virtual 2501 will come out of its freeze, and flags the feed check latch to force a feed check in the 2501 cycle.
I also noticed that the virtual 2501 stops running as soon as the physical Documation reader becomes ready. I spent some time investigating why this might be occurring, as it seemed odd, but it is related to the hopper status becoming full which my adapter only sees when the reader becomes ready. I will experiment with different strategies for marking the hopper empty as this may change the behavior.
Sadly, the way the Documation reports hopper empty status makes this unusable for my purposes. They wait until a specific point during the reading of a card, somewhere between columns 18 and 21, to reflect that the hopper is empty. If the reader is not currently ready, there is no indication that the hopper was emptied. If the reader is ready when the hopper is emptied then the ready condition is immediately dropped.
That means I have to use the ready status, not the hopper empty status, to determine when I think the hopper is empty. It is not ideal, as the user may see a hopper full of cards but the virtual 2501 believes the hopper is empty. Once the user makes the adjustment to think that 2501 hopper empty state only means not ready n the physical reader, it may work out.
I also was able to read a card with the 1130 issuing an XIO Initiate Read instruction, however my timing is off and it detected a Read Check at the first column, aborting the rest of the read. No data was therefore transferred, but I can see the card columns being set up and it superficially appears that the correct data is there. I will adjust the timing and run more tests.
Still read checks, but more troubling is that the bit pattern of the three rows I am monitoring doesn't seem to match the card exactly. I cogitated on that awhile and see that the row data is read from the first input board and then the index marker flag arrives on the second input. Thus it is possible that the data values we are using come from before the index marker was set, perhaps 100 microseconds earlier.
In a traditional interface, this wouldn't be an issue because the Documation flags IM well into the data valid period, but my latching board changes this. I don't unlatch and pass through the live column data to the input board until the IM went high, holding those values latched once IM goes back down.
Further, the values we see could have been sensed back when we read the first board even though the second board tells us data is latched; that sequence can give us data before the latch locked in the values. This might seem like it would be okay, since the data is valid from when IM first goes high, the latch then acting like a pass through giving us the live values during the high point of IM.
However, the card column data can be more than 100 us older than the real IM pulse, which only lasts 6 us. If it hadn't actually opened the latch back then, we have the prior columns data or a mix if the change happens just as we are clocking out the 16 bits of input board 1. This is why I can't trust the data when my IM is high.
My index marker is an extended 280 us version, not the actual short pulse of the machine. I should be able to trust the values when IM goes back to 0, because the card data is within the last 250 us at worst case and all that time it was valid.
The logic by which I push data into the FIFO must use the fall of IM as the trigger. I will check the FSM carefully to be sure that I comply with the constraints. Of course, the flaky data I see is actually during the output of the FIFO contents to the virtual 2501, thus the issue could also be due to issues in the logic on that side.
I resumed testing with the updated logic and chased down a few single shot gates in the IBM designed adapter logic that I had implemented with too long a duration. Nothing is specified about duration for most of the SS and SPD type gates, so I had to guess. Adjusted down, I vanquished the read check failures. Now on to getting the data reliably in from the Documation and out to the virtual 2501, through the 1130 adapter logic and into memory.
I saw them reliably picked up from the interface and presented to the FIFO to clock in, but found that my error recovery logic was flawed and was resetting the FIFO to empty inadvertently. With that blocked off, I moved on to debugging the cycle steal data transfer mechanism that is invoked as each column's data 'arrives'.
I am patiently working my way through the various actions involved in the cycle stealing activities of the IBM adapter. The address of the data field is loaded into an adapter address register, then it requests the first cycle steal to transfer a word from that location. For the 2501 adapter, that first word is the count of columns to transfer into memory. Each time the adapter does a cycle steal, it bumps up the address so it is walking through the data field until the end.
The adapter sits in this prepared state, with the count of columns to read and the location held in adapter registers, until the physical motion of the card moves it to where the first card column is passing the photocells. The emitted pulse tells the adapter to store the values of the 12 photocells, wait until the end of the column interval and check that the values are still the same. Any difference is a read check error.
Assuming there is no error, the adapter then requests a cycle steal to write that data into the processor. When the cycle steal is granted, at the appropriate time, the adapter makes the data value available so the processor writes that into the memory addressed by the adapter. Again, the address in the adapter is bumped on each CS. The adapter decrements the word count it is holding at the end of the column time.
If the word count gets to zero, the adapter stops checking card columns or requesting cycles steals. The word count is actually held in ones-complement form and counts up, with an all-ones valuing equating to a word count of zero, because it makes the circuitry simpler. When the feed cycle ends in the 2501, the adapter requests that an interrupt be taken in the processor.
The program issues the XIO Sense Device command to get back a word with the status of the card reader, various bits having meanings such as 'busy', 'read check' and 'end of file'. As of Wednesday night, the cycle steal circuits seem good, the word counter is correct and the final sense status is appropriate, but I don't see the interrupt taken. I am still receiving read checks too which blocks the delivery of the card data to memory.
I have found some sporadic oddities at startup, e.g. at reset of the fpga, which I decided to work on. Most FSMs I use are initialized by the inverted reset signals of the 1130 processor, which are emitted by those modules once they receive a power on reset signal that reflects seven cycles of stable output from the fpga's hardware clock module.
The FSMs use the fpga clock, ClockMaster, but don't get the initialization pulse (reset) from the 1130 until it starts which is a mininum of seven clock cycles later. During the first seven or so clock cycles, some of the startup signal states of the 1130 won't be right, if they need the reset signal or worse, an 1130 clock pulse at its much slower rate than the fpga clock.
I implemented a new reset signal that is based on the fpga hardware clock and the seven cycle startup - thus all my FSMs outside of the IBM designed logic should be initialized before the 1130 clock begins its ticking and nothing will advance if there is a glitchy early clock pulse from the fpga. I am hoping this will rid the machine of those sporadic odd startup states, otherwise I will need an even more nuanced set of release signals to let various functions start operation.
The machine is more consistent from test to test, in those areas where I saw sporadic problems before. The read operation is still triggering read check errors. I think the best approach is to walk through every detail of the state transitions and signals from the IBM adapter logic, which will flush out errors in my implementation of the IBM logic as well as flaws in the emulation from my logic.
Correctly generates reset of the card reader address and word count registers as the XIO instruction begins. Successfully latches the address of the IO buffer at the end of the XIO Initiate Read command and flags request for first cycle steal, where the word count of columns to be read is fetched from the front of the buffer in 1130 memory.
The fetch of the word count and latching into the card reader count register is the next milestone to check. At that time, it also must bump the address register by one to point at the location for the first card column to be stored. The address increment pulse occurred on time. The count is being picked up properly and the address register for the card reader adapter is incrementing as expected.
At this point, the card is moving in the emulated 2501, the word count and memory address are set up and the adapter waits for the emitter pulse from the reader when the first card column is ready. The emitter pulse causes the photocell data value to be latched into the card data register at the rising edge of the emitter and for a comparison of the photocells and data register at the emitter's falling edge.
If the comparison is equal for all 12 card rows, the adapter will request a cycle steal. In the cycle steal, the adapter writes the card data value to 1130 memory, increments the card memory address register, as long as the word count is not down to zero. When zero, the card transfer is complete and an interrupt is scheduled to present status of the IO operation.
I can't verify the rest until my emulator logic presents the proper card data value as the photocell signals and holds that value until the falling edge of the emitter pulse is over. My next series of tests put the microscope on the signals and timing between my emulator logic and the IBM adapter logic.
The relative timing of the photocell signals I am emitting from the emulator logic and the tests that bits haven't changed during the time of the emitter (when the column is being read) all look correct, yet I also see that the signal that combines the twelve individual row comparison tests isn't updating as it should. I have a few other signals to watch, but I am likely on the trail of the defect that causes my read check errors.
DISPLAY PEDESTAL COMPLETION
Cementing together the acrylic light masks into a block that can be affixed inside the enclosure right behind the plexiglass panel on the front. I am using a medium density acrylic cement, suitable for bridging a slightly imperfect mating surface. I had to pick up some thick acrylic of the appropriate size to glue the parts together properly, which meant a trip to TAP Plastics.
With the new plastic stock in hand, I began gluing up the spacer that holds the last section of lamps, which sits at the right of the plexiglass panel. Once it is ready, I can glue together the two mask sections to make the single long mask that will be installed in the enclosure just behind the plexiglass panel.
I built side assemblies to be glued to the outside edges of the mask, those side assemblies each have a flat plate with a hole in it. That plate rests on the bottom of the enclosure and is used to fasten the mask in place with a nut and bolt. Once the side assemblies are glued to the mask I can mount it and finish up the display pedestal.
Turned out that my left and right side mounts weren't perfect. The right side, when viewed from the front, conflicts with the fastener holding the plexiglass panel to the enclosure. I have to rework that mount. The left side mount barely reaches the screw hole, so that the bolt is in a notch not a hole. The nut and washer will just sit atop the holder at the notch but won't prevent rightward movement of the mask. Fortunately, the other side will have a hole through which it is firmly affixed.
The mask assembly is in place and fastened down, with the LED boards placed into position to test out the operation. The left side board which displays the six major registers, IAR, SAR, SBR, AFR, ACC, and EXT, is working satisfactorily. I have a light metal band formed into an arch to press the left board into place, the two ends of the arch hooked under the top and bottom lip of the back of the enclosure.
The middle boards exhibits some glow through the black portion of the plexiglass surrounding the transparent letter openings on the panel. The plexiglass panel is not thick enough to be opaque in this middle section. I am not certain that I can completely compensate for this and may have to accept some of the shine-through.
The 1130 logo plate is fastened atop the enclosure, now that the left LED circuit board is firmly in place. Once the spacing and fastening is sorted out for the middle and right boards, just a few tasks remain before the enclosure is sealed up. The left and right side plates, containing the emergency pull and mode switches, need their fastening made more solid, then the main LED control circuit board must be secured in the enclosure.
TEKTRONIX TOOLS FIXES
7d01 Logic Analyzer
I bought a submini toggle switch whose handle shape, length and angle match the Tek part quite well. It appeared to have the same barrel diameter and thread type, but I found that the nuts are not interchangeable between the failed switch and this new one. It is also a bit too deep to fit in place, I will need to cut away at the electrodes and find a way to attach it to the PCB. The spacing of the three electrodes is not the same as the TEK PART.
Oddly, the failed switch began to work again after it was removed from the PCB, most likely due to being twisted during the cutting. It was clear that I could reattach the switch, if I could put a bit of copper wire on each of the three stubs on the switch. I solder it into place, verified its correct operation, and began to reassemble the logic analyzer.
No comments:
Post a Comment