I selected the locations to glue in rods perpendicular to the rear face of the plexiglass panel, which will be used to mount the panel onto the front of the pedestal enclosure. Using a drill bit designed for acrylic and the slowest speed on my drill press, I was able to make the openings successfully. I bought some nylon nuts with the hope that I could put threads on the 1/8" acrylic rods and fasten the rods inside the enclosure this way. If that doesn't work, some form of shaft collar with adjustable setscrew will do the job.
I marked holes on the flanges of the enclosure where the rods will pass through. Once the rods are affixed to the plexiglass panel, I will use them to fine tune the location of the holes to be drilled in the flange. However, I am not happy with the use of clear acrylic rod as it leaves a 'white dot' on the panel face, so I will buy black acrylic rod , drill the holes through and flush mount the rod to the panel face.
Unfortunately, Tap Plastics does not carry 1/8" diameter black acrylic. I will have to look to alternate suppliers or move on to a plan B to deal with this. I ran out of time on Saturday night, having spent my final hour relocating the Documation reader, attaching the interface and preparing to monitor in the signal status in my adapter logic.
DOCUMATION READER MODIFICATIONS
I was able to find and buy the open collector NOR gate in TTL (7433) that will allow me to block off row 12 signals from the column 81 'all dark' check, so that reading a card with a diagonal cut on the right side instead of the more usual left edge will not induce a false error as the Documation famously asserts for those punched cards. Once it arrives, I will make all three modifications to the reader at the same time (remote stop, remote reset, and right-side-notched card support).
In advance of the chips arriving, I did a layout for a small board that will hold the added chip to be wired in place of the not gate for row 12 whose output trace we will cut. I will have to solder on leads to the inputs and to the wired or that sit on th control board, running to the pins on the new board I designed. In addition I need to find a good place to pick up the 81CR signal, +5V and a good ground. There is plenty of room in the card cage to mount this small board, once I sort out the mechanical attachment I prefer. It would be best if I can mount it above the chips on the control card, as a kind of daughtercard, since it will then slide in and out of the cage along with the parent.
I did open the reader and gain access to the two switches, stop and reset, to begin wiring my leads for the modifications. The remote activation of stop does not prevent the reader from operating standalone, but the way I am attacking the remote control of reset means that I have to build a 'dummy plug' to install on the DB9 connector to allow the machine to operate on its own, replacing that with the cable from my adapter logic when this reader is hooked to the 1130 system.
 |
| DB9 connector installed on reader for remote switch activation |
 |
| Standalone operation of the reader supported with the jumper plug installed |
I had some time to continuity check the wires, only to discover there was an internal break in the multiconductor cable I strung inside the reader, which left on signal to the reader logic boards unattached. A quick run of an additional cable to carry the missing signal, some continuity testing, then on to a power-on test. Eureka - the machine works perfectly with the standalone plug in place, just as designed.
I was contemplating the attachment of the adapter logic to the reader mechanism, in order to validate the various signals that should be produced during reading. The machine allows for 'local mode' reading, which is when it automatically picks and reads as long as there is no error condition (such as hopper empty). Probably can't get to this today and I leave on my last business trip early tomorrow morning, but it will be the next reader debugging activity when I return. I won't get a lot done next week, because of the trip, but should get back to a more normal schedule of work on the 1130 after that.
DOCUMATION ADAPTER LOGIC
In the process of debugging the link to the adapter, I discovered a short in my wiring of the card reader adapter, dragging the i2c data line to ground. Once fixed, I put my storage oscilloscope on the line to verify the analog aspects of the link.
I was not satisfied with the quality of the I2C serial links going to the card reader adapter and spent a bit of time ensuring I had perfect looking signals on the line. I switched the method of driving the tristate pins for this serial link, fine tuned the pullup resistor, all with a fairly long cable which will run to the external card reader frame from the 1130 frame.
I have two different I2C master implementations in my design, one provided by Digikey and one provided by the OpenCores org, although I have been working with the Digikey version to date and have not had any reason to switch over to the presumably more rigorously tested Open Core version. I discovered a minor naming issue with one signal for the I2C link to the card reader adapter, which resulted in delivering the wrong status bit to the adapter logic. Once I corrected that, we were working with good signals.
I was not happy with the security of the cable connections for the serial links, as they were too easily twisted, pulled off or shorted due to the heavy springlike behavior of the token ring cable. Now I have secured and repaired the links.
I found a copper trace broken and lifted off the bottom of the outputs board, which I attempted to repair with a short section of bare wire. Because my board has a copper ground plane with very narrow insulating channels around active lines, this shorted the line to ground. I took off that repair attempt and will do a more permanent fix to the board tomorrow.
I am still tweaking the logic that talks to the MCP23017 multiplexer chips, which will be changes I want to carry over to the keyboard and general input button/switch links. I have the input chips working but the output signals are still frustrating me.
My STOP button on the 2501 panel wasn't registering, but I could confirm full signal integrity from the switch to the multiplexor chip pins. After some work with live operation, I discovered that the debouncer is not passing the switch activation through to the input board, staying high at all times. The chip I am using has three spare circuits, so the solution is easy. It now works exactly as intended. Odd that I would have two defective components, the cable with the broken lead used inside the reader and one of the six debouncing circuits in the MC14490 chip, but this is behind me now.
I added some logic to validate the sanity of the incoming stream, so that if the link gets out of sync I can force it to reinitialize. There are ten signals out of the 32 coming from the input board which are not used, thus they should all be zero. I am doing an OR of those lines and validating the result is 0 during normal operation of the adapter. If I see a 1 at the end of an input polling loop, the state machine goes to initialize again. I will wire the open input pins on the input board to ensure these always send the desired '0' state.
ADAPTER FOR PERIPHERALS USING SAC AND 1133
The adapter offers a simple set of protocols for calling devices when XIO commands are issued and for the devices to request service when they wish to perform cycle steal data transfers, initiate interrupts or report status. It can have peripheral adapters that connect directly, such as my 1403 adapter, or it may have a 360 channel emulator adapter that in turn has logic attached for peripherals which expect to communicate by 360 channel protocols.
The complications for this adapter come from the asynchronous requests of peripherals for interrupts and cycle steal transfers, which may come when the adapter is busy servicing another device or when the processor has asserted a block for CS or due to other peripherals using the interrupts. I need to maintain a control word for each attached device, registering any requests, then scan those words when idle to pick up the next cycle steal and interrupt actions to take.
I designed this to be configurable for the number of devices attached, each of which is polled in priority order to pick up requests and place them in the control words. The processor is asynchronously calling this module for XIO commands, and the devices are asynchronously calling for service requests. What we mean by asynchronous is that we may have XIOs arriving while devices are making requests, we may have devices making requests while we or the processor or both are busy, but all of this is clock synchronous to the fpga clock.
This module runs three loops when not busy. One loop polls devices to trigger their requests, simply as a means of bus arbitration so their requests don't step on each other. The second loop looks in priority order at the control words to activate cycle stealing on behalf of devices. The third loop runs when the adapter is not busy and has finished its look for CS requests, this time the adapter scans the control words to trigger interrupt requests if none are active for each of the four levels (2-5) we handle. The index of the device requesting the interrupt on each level is stored in the active interrupt word. The loops are abandoned if XIO or CS requests are received from the processor or devices respectively.
1403 PRINTER ADAPTER
This is a very simple adapter which accepts control, write and initiate write commands from my SAC peripheral adapter, uses cycle stealing to fetch the print line, and sends commands over a 3.3V "TTL" serial port to the Arduino that will act as the operator interface to the HP line printer. It also provides status of the printer, requests interrupts and takes virtual carriage control events from the Arduino.
The fpga board has a serial port onboard that will communicate with the Arduino. The Arduino operates two serial ports, one to speak with the fpga and the other to drive the printer. It has an LCD panel and buttons which the operator will use to manage the printer. We will also pass the print characters in their original 1130 encoding, doing the translation to ASCII in the arduino.
The HP printer has a software function similar to a carriage tape, but we must shadow this in the Arduino to allow us to recognize when we need to request interrupts or change status. The arduino issues the commands to the printer that skip to various channels, go to the head of form (channel 1) and configure it to be as similar as feasible to the 1403 printer it is emulating.
No comments:
Post a Comment