SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130
While I was thinking through an implementation of a big buffer to hold data from a mirror device adapter, under the premise that the speed of the data production is fully determined by the real peripheral device and its IBM adapter logic in the 1131, I had a flash of insight.
The bus that devices use to present data and sense status when processing an XIO is constructed as a wired-or bus. That means that all devices have their outputs tied together, but only one will be pulling down the bits that have a '1' value. The others leave their signals high, which is logic level 0.
That means that while I am shadowing the XIO Sense DSW for the device, I have the opportunity to force the 'busy' bit or other sense bits on, but not off. If it makes sense for a particular device and software that the presence of a busy bit will keep the program from issuing additional read/write commands until it goes off, then I could throttle the peripheral by jamming the busy bit into an Sense DSW the program issues, until my PC program has retrieved the currently stored value and free up room for the next.
For the 1053, that will probably suffice on a character by character basis, causing it to slow down the real selectric typewriter but preserving the data. For the mirror 1132 printer, I would have to pretend the carriage is busy after handling each line of print, ceasing my jammed busy bit when the Python program finished retrieving the prior line. For the mirrored Console Entry Switches, I needn't worry because the 'data rate' of flipping switches is low enough that I should never have an overrun on my mirror peripheral.
For this to be feasible, I need a means of switching the pseudo-busy behavior on and off, depending on whether the Python program is mirroring the device or not. I chose to use the transaction Write Special Data with a value of 0 meaning disarm (the default state) and 1 meaning arm this. When armed, this pushes on the busy status of the typewriter as soon as we process an XIO Write command and leaves it merged into the DSW that will be returned to software until the next transaction that fetches the word written by an XIO Write.
My testing uncovered a few minor issues which I fixed up, but it did not appear that the merged DSW was blocking the program from writing additional characters. This could be a flaw in my logic to force in the busy bit, or it could be a miscalculation that assumed any software would look at that bit before issuing a write.
I scrutinized the logic, made some changes and resumed testing. Mirroring is working, sort of, but not sure I am capturing every character. I will put some paper in the typewriter, insert the ribbon, and then compare. The testing will be done tomorrow, it is now after 8PM.
For this to be feasible, I need a means of switching the pseudo-busy behavior on and off, depending on whether the Python program is mirroring the device or not. I chose to use the transaction Write Special Data with a value of 0 meaning disarm (the default state) and 1 meaning arm this. When armed, this pushes on the busy status of the typewriter as soon as we process an XIO Write command and leaves it merged into the DSW that will be returned to software until the next transaction that fetches the word written by an XIO Write.
My testing uncovered a few minor issues which I fixed up, but it did not appear that the merged DSW was blocking the program from writing additional characters. This could be a flaw in my logic to force in the busy bit, or it could be a miscalculation that assumed any software would look at that bit before issuing a write.
I scrutinized the logic, made some changes and resumed testing. Mirroring is working, sort of, but not sure I am capturing every character. I will put some paper in the typewriter, insert the ribbon, and then compare. The testing will be done tomorrow, it is now after 8PM.
No comments:
Post a Comment