In article <[EMAIL PROTECTED]>, Ed Gould <[EMAIL PROTECTED]> wrote:
> IIRC the model 30 & 1419 were exceeding time dependent you had x many > micro seconds to make the decision to tell the 1419 to direct the > document to the correct hopper. IIRC TR was one of the slower > instructions on the mod 30. Its been *YEARS* and I could be wrong but > TR could not be used (if you wanted to get the check into the right > sort bin). The mod 30 used core memory. Because a memory read was destructive, the memory hardware would automatically rewrite data after reading it, raising a "busy" flag for the bank of ferrite cores including that bit until the rewrite was done. Memory was interleaved, so successive reads would come from different banks of core, usually avoiding having to wait on that busy flag. But the TRT instruction read the translate index, used it to fetch the translated value, then rewrote that value into the same byte from which the translate index had just been fetched, and therefore bumped into the busy flag. Of course, that rewrite was unnecessary in the TR case because the TR itself was about to write an updated value, but the memory hardware wasn't designed to accomodate that. > Of course if you used it outside of the "window" you could use it all > you wanted. I wonder if the CCW chain could be processed fast enough that much of the reversing could be done with the Chain Data flag and appropriate destination addresses. In the days when we actually wrote channel programs, we could do a lot with them; for example, a PCI could allow the program to start validating the early data while the check was only partially read, substantially widening the stacker-select window. -- Randy Hudson ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
