I discovered that somehow I had wired the reset line of the mulitplexor chip to 0 rather than 1, but it is an inverted pin thus this is keeping the chip in reset mode. I had to do a slight rework on the board, cutting the trace connecting this pin to ground and then bridging it to +3.3V to make it sense logical 1. This is an eye-hand coordination test, since the trace in question is only 15 thousandths of an inch wide and within 1/100" of an inch of the adjacent traces on the board, plus it is covered by a tough layer of solder mask. My ohmmeter confirmed success in severing the trace.
To connect this pin to logic level 1 is best done by connecting the reset pin to the adjacent pin which is an address pin wired to +3.3V. One might imagine this would take a wire soldered to each pin in turn, but we are on a different scale with surface mount. The MCP23017 chip is an SSOP sized IC - not the smallest pin spacing but still pretty close together. To bridge the two, I used a bridge of solder across the two pins, something that is way too easy to accomplish accidentally with this pin spacing. Some flux paste to remove oxidants on the pins, some solder put on the end of the soldering iron tip, and it was done. In fact, it created a bridge to the pin on the other side of reset too, but that is not desireable. A bit of solder wick applied judiciously and I was left with was the intended bridging.
The link was still not carrying the data across, thus my attention returned to the logic I used in the temporary kb testing code in the fpga. Found I had missed a bit of code, plus I had left pullup resistors set on in the fpga definition in spite of the fact that my new PCB contains the pullup resistors for the circuit now.
In the rush to move on to yet another test, I swapped the connection of two cables to the board, unfortunately exceeding voltage limits and damaging the two integrated circuit chips and the relay. Out came my hot air rework station, I pulled off the bad chips and replaced them.
Turns out I had swapped the assignment of the clock and data lines from the fpga - embarrassed it took so long to notice. Right now it is working well, with only one channel not working properly, channel 10 which uses one of the two photocells that I replaced. It may require a slightly different resistor value to bring the voltage swing into the right range for the schmitt trigger inputs to the multiplexor chip.
After some time dealing with variations in the light level in the different channels and looking at the overly complex adjustment mechanism on the keyboard intended to allow service people to constantly compensate for lamps aging and dimming, I decided to swap in a full set of LEDs to provide a much more uniform light level with a much longer working life than incandescents. Of course, now I need to redo all the resistance bridges to work with the new light field intensity.
A fellow lover of retro computing hardware contacted me and is offering to share a keypunch keyboard. If this is the IBM 029, then if this goes through I will definitely take advantage of it, regardless of the existing interface and keyboard work, because the keycap colors and titles will be that much more accurate, requiring only a few caps to be altered.
LINE PRINTER PICKUP AND FIRST CHECKOUT
I scheduled pickup of my line printer for this evening and got it here successfully. I had to make room in my garage, which is getting crowded with '1130' peripherals, having a card reader, card punch, paper tape reader, paper tape punch, small and large plotter and now the disk drive and printer. The printer looks good, has a nice stand that elevates it to reasonable height, and passes its self-test handily. The printer has an RS232 interface and the manuals I will need were all easily located on the web at a site run by fans of old HP technology.
 |
| HP line printer and stand |
 |
| Self test printed output |
The printer had power applied and was online for 1,684 hours but printing time itself was just 7 hours. That is very very light usage. The online time itself is pretty low, corresponding to just a couple of months if powered around the clock, about a half a year from being put into service even if you assume it is online only one shift a day. I ended up with a almost new 600 line per minute printer for $100 plus gas and driving time.
The printer is driven by HP PCL, which includes a virtual carriage control tape capability that will allow me to exactly mimic the tapes used on 1403 and 1132 printers, where my code can detect and/or skip to one of the 12 channels on the carriage tape.
I have already built my cable for the interface, still deciding how to link it into the fpga although probably through the RS232 port on the Nexys2 board as those IO pins are already committed and don't subtract from my available pool to use for other purposes. I might put a Raspberry Pi in the chain to the printer, to handle the virtual carriage control tape and the character set translation duties, allowing a quick easy interface for those operator tasks. It would drive RS232 to the printer and a second link back to the Nexys2.
CARD PUNCH PICTURES
 |
| Card punch transport mechanism |
 |
| More of the transport |
 |
| And another view of the complex dual card path transport mechanism |
 |
| Massive transformer inside the punch |
 |
| Card punch side view, showing relative size of transformer |
 |
| Top side of dual card paths, read station on right with bright lamp, punch on left |
Looking for a good ebay unit at a reasonable price now, one seems possible but the seller is holding a hard line on the price, only willing to reduce the Buy It Now price by $5, which I found odd given that it was listed with a Make Offer button. I did notice that there had been three other offers submitted by others; not sure why the seller paid for a Make Offer button if they are not interested in accepting offers below their list price, especially with a 'as is', 'don't know if this works' item.
Before I pull the trigger and buy a chiller, I should work on the punch enough to validate that the basics are operational - motors work, power okay, mechanical systems and transport paths work, etc. That way the additional money, particularly if there is a risk because the unit is of unknown status, isn't risked on top of major risk that the punch machine itself is unrestorable.
DISK DRIVE ARRIVAL AND FIRST CHECKOUT
The drive was delivered early today and I had a chance to unpack and place it up on a work surface in the garage. I opened up the covers and was overjoyed to find that it was complete - all parts in place and seemingly undamaged. Heads looked clean, no gouges or signs of a crash. It was shipped without shipping straps, something I was pretty sure would be the case, so that the arm assembly was subject to movements and may have been moved quite a bit during transport. Again, no obvious signs of damage but I will have to move carefully to restore this to operation.
 |
| RK05 drive front panel |
 |
| Mechanism looks excellent, only one relay fell out of position during shipment |
 |
| More of the mechanism, exposing the logic board cage, blower and spindle motors |
 |
| Logic cards - all are there, missing only the drive to controller cable and terminator |
First steps in my plan are to reform all the major capacitors, verify the mechanical elements are working okay, then bring this up slowly with my variac and check out the power supply. Once it is good, I will start adjustments and tests using the DEC manuals I retrieved from bitsavers.org. That site also had the self-training course materials that DEC used to train its customer engineers in servicing these - very valuable. I will also inspect my two packs to discover in which format they are - 12 sector PDP/11 or 16 sector PDP/8 - and to very carefully inspect the disk surface for signs of damage or prior head crash.
I have to decide how I am interfacing this - if I will mimic and use the controller logic, then I might need an M930 terminator card and cable, for example. This is the most straightforward approach, but it will require some level shifting and translation since the drive uses inverted logic with (typically) 0.5V for a logical 1 and 3.5V for a logical 0. No available ICs match the specs of Unibus exactly, but everything inboard of the bus interface is pure standard TTL which does suggest that the input might be hacked to deliver TTL signals pretending to come from bus driver/receiver chips. Since I know the exact situation for this link - the loads from the RK05 and the side I design - I can probably use interface chips that, while not fully meeting the Unibus spec, will be well within tolerances for the conditions under which my link will face.
An update today - I was able to locate a NOS (new old stock) supply of one of the interface chips from a Southern California dealer and my preferred supplier (Digikey) had the other type in stock. Each signal line is hung on the node between a pair of resistors, one side connected to +5V and the other side to ground. This controls the line so that it swings between +3.5V and 0.5V as the 75452 chips drive the lines to logical 1 or 0 states and allows those to be detected reliably by the 8640 bus receiver chips.
I bought some space saving resistor networks - a 16 lead component that provides support for eight resistor divider pairs with the 190 ohm and 380 ohm values that are used as in the DEC terminator. Just five of these implement the M390 terminator function and another five on my interface will terminate the other side of the bus.
The DEC boards are quite primitive by today's standards - big wide signal traces, widely separated, through hole components and the contact fingers are quite large. No need for modern capabilities in PCB manufacture, I can build these easily myself and save a bunch of money compared to fab prices. I just picked up the gear to build boards and will start with the terminator boards (M390 equivalent) and interface cable board for my drive. It is possible that I will put some logic on the same board as the cable interface, even perhaps using a more modern protocol and link between the drive and my system. Decision not yet made on the logic side, but I am about halfway done designing the terminator board which is will also be the basis for the cabling/interface card, since both sides of the bus will be terminated.
I checked my two disk cartridges. Both are the less desirable (by the retro computing enthusiasts) 12 sector versions but I have a scheme in mind for the interfacing that will render that moot, in that it would work with either format pack transparently. Basically, the 1130 divides the pack into four sectors rotationally, but physically the 2315 pack is built with 8 sector markers evenly around the hub rim. The 1130 adapter logic toggles a flip flop to skip every other sector pulse, thus 'seeing' only four pulses. The packs I have will deliver 12 or 16 sector pulses per rotation, thus I have a skip pattern I will interpose between the RK05 and the 1130 adapter logic.
If I have a 16 sector DEC pack, I skip every other pulse before delivering it to the 1130 adapter, which itself is skipping every other pulse it sees. That turns 16 hardware pulses into four logical sector pulses, just perfect for the 1130's use. The head is perfectly happy reading and writing across the points demarcated by sector pulses - those are optical pulses from the hub not data recorded on the disk platter surface. The 1130 does this by design, writing its sectors to straddle two of the physical 'sectors' of the 2315. The 1130 is seeing only sector markers 0, 4, 8 and 12 of the physical pack.
For the 12 sector DEC pack, I will skip every third pulse from the drive before handing it to the 1130 adapter. The 1130 skips every other pulse it sees, delivering a total of four pulses for a rotation. These are in correct place, in spite of the asymmetric pulses I deliver to the adapter, because I do my skipping synchronized to the index pulse that begins a rotation. I deliver sector markers 0 and 1, skip 2, deliver 3 and 4, skip 5, etc ending with delivering sector 10 and skipping pulse 11 to end a full rotation. The 1130 adapter throws away every other sector pulse, thus it passes on only sector pulses 0, 3, 6, and 9 from the real disk, which correspond to the four points spaced at 90 degrees of rotation.
The scheme above for the 12 sector packs yields the same spacing as the 16 sector scheme delivers when it passes sector markers 0, 4, 8 and 12 of its disk which are 90 degree points too. All I need to do handle a drive transparently is count sector pulses for one rotation (index pulse to next index pulse). If 12, skip every third pulse, if I counted 16, skip every other pulse. My logic will be activated when the RK05 is telling me it has file ready, but when I have not yet sent the 1130 adapter a file ready. Power down sets my file ready state off, so I just watch for when that state first flips on, do my count, and we will be set to go.
The surface of one of the two packs is clearly good enough to use, but the second may or may not pass muster after I clean off some debris marks from dust dragged by a head in a circular pattern on the top platter. If it cleans well with isopropyl alcohol with no ridge or groove that disturbs the surface flatness, I will consider risking the heads on it. If I don't like it for any reason, then it remains a cosmetic prop and not a functional cartridge.
My Kimwipes and pure Isopropyl Alcohol will arrive this weekend, at which point I can clean heads, platters and the internal surfaces of the disk drive and cartridges, then begin storing the cartridges in plastic 'baggies' to keep out contaminants.
CARD READER MECHANICAL WORK
The documation is slowly working through the solidified grease problem in the pick solenoid - although it is still not returning totally crisply it feeds properly much more often now. The error being reported most frequently is now 'read check', which I suspect is a result of the slow moving transport rollers but could even be a timing wheel that has jumped out of alignment due to the loose belt and dragging transport rollers. More work needed but progress is achieved. I expect a suitable spring scale to arrive this weekend with which I can do the adjustments.
TYPEWRITER INTERFACE LOGIC DEBUGGING SETUP
I set up the logic analyzer to watch the signals from my fpga board to my interface card inside the typewriter, allowing me to test the critical parts of the interface without risking the somewhat fragile selectric mechanism until I feel more confident that it works safely. The biggest trick needed as I move forward is to fake the three response signals that come from the typewriter - the print feedback, emitter and shift status signals.
I am using my Arduino to watch for commands I am issuing to the typewriter and using it to reply with realistically timed pulses and feedback. The logic analyzer will capture the whole sequence for my study. I will disassemble the testing setup that is in place with the ATX PC power supply and laptop brick to deliver the 5, 12 and 20V needed to the keyboard and its interface board. That will give me the space to spread out the analyzer, arduino and 1130 board for my debugging.
Since my Arduino code successfully drove the various operations I need such as spacing, printing, line feed, carriage return and shifting, I know exactly what I need to emit and the timing to work the typewriter. This stage of testing is to ensure that I do the right things, as the 1130 adapter code activates my logic in the fpga based on XIO commands I code to write to the console printer. I can also begin testing more advanced functions like end of line detect, seting, clearing and moving to tab positions, etc.
No comments:
Post a Comment