The tab interposer has its rear spring in place, but there is another spring hanging in the space blocking the movement. I have to pull it out and figure out what is might be. I thought it might be the spring that holds the operational latch forward toward the interposer and out of the way of the bar that activates the machine function. However, I am not sure.
This is the most blocked and inaccessible area in the entire machine. I can only catch glimpses of part of the spring, I can't see the ends where it does or should attach. There are two possibilities - the spring is one that I lost deep in the machinery months ago, and thus superfluous, or it has partially detached and is needed for the tab interposer to work properly.
I put in another 45 minutes trying to sort out the spring issue, to no avail. Perhaps tomorrow.
1442 CARD READER/PUNCH RESTORATION
Worked out the scheme for the virtual 1442 card reader/punch, soon will finalize the fpga logic and start on the Python program for the PC side of the USB link. The PC side was all blocked out in pseudo code by the early evening.
SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130
I have no idea how fast or slow the Python program will deal with multiple peripheral devices simultaneously. There are various ways I can improve the performance, from the interactive workbench which only uses on PC processor through to versions will exploit all cores, then to a rewrite in C if that becomes necessary.
Each virtual or mirror device is a separate Python thread and if allowed to be dispatched across multiple cores on the PC, should handle a lot of the scaling required to support simultaneous peripheral operation. The bottleneck is the single USB link and simple transaction I am using to communicate. If this saturates it could keep the PC side from checking device conditions often enough to see all the activity. This is something to worry about later,not now.
The fpga itself is fully parallel, of course, and can support as devices as I wish without impact on the others. Ultimately, the bottleneck will be the 3.6 microsecond memory cycle of the 1130 and the interrupt intensive nature of some of the IO devices used with the system. If each instruction requires, on average 15 to 20 microseconds, then the code paths through the interrupt routines as well as the XIO instructions themselves will be a major limiter on system bandwidth.
The cycle stealing peak rate might be 277K words per second, but real life activity is going to be down in the thousands to tens of thousands of words per second. If we do an IO every 100 instructions, that is one word per 1.5 to 2 milliseconds, thus less than a thousand words per sec. As long as my PC program and the USB link can do at least 5000 transactions per second, it should be able to keep up with the IO activity.
The fpga itself is fully parallel, of course, and can support as devices as I wish without impact on the others. Ultimately, the bottleneck will be the 3.6 microsecond memory cycle of the 1130 and the interrupt intensive nature of some of the IO devices used with the system. If each instruction requires, on average 15 to 20 microseconds, then the code paths through the interrupt routines as well as the XIO instructions themselves will be a major limiter on system bandwidth.
The cycle stealing peak rate might be 277K words per second, but real life activity is going to be down in the thousands to tens of thousands of words per second. If we do an IO every 100 instructions, that is one word per 1.5 to 2 milliseconds, thus less than a thousand words per sec. As long as my PC program and the USB link can do at least 5000 transactions per second, it should be able to keep up with the IO activity.
Re the hidden springs - back when I was a hardware CE, a standard tool in the CE's bag was a dental mirror: small round mirror on a long handle. Have you tried one of those?
ReplyDeleteI have one but don't have any access where the mirror reveals any more. Exceedingly limited access, because microswitches and solenoid assemblies cover the space that would permit a tad of access on an ordinary selectric. Maybe a fiber optic camera probe is what I need for these cases.
ReplyDelete