From: Swift Griggs Sent: Wednesday, June 22, 2016 1:58 PM On Wed, 22 Jun 2016, Chuck Guzis wrote:
>> I think Paul's covered that pretty well. I'll add that the more complex >> the display, the more flicker was present. > The descriptions are fascinating. I hope I can see one operating some day. > Do you know of any still operational ? We have one running at LCM, attached to an instance of dtCyber, the 6000/Cyber simulator, via John Zabolitzky's Xilinx-based display adapter. We're in the process of refurbing the one that came with the 6500, which we may attach to the system at some point. >> Well, SCOPE had INTERCOM, an interactive facility, as well as >> EXPORT/IMPORT which was an RJE facility. But the system was targeted >> primarily at batch jobs. > Hmm, after reading the responses, I'm guessing most folks just showed up > with an armload of punch cards and didn't bother with keying things on the > console at the altar of the system. Not a matter of "didn't bother with", but rather "were never allowed to". You don't get to fuck with the console of a multimillion dollar machine if you're not part of the operations or systems programming staff. And it's rarely an armload. Most programs fit into a deck of a few dozen cards or so. If you can't wrap a rubber band around the deck, you kept it in the box. (Oh, yeah, you bought cards in boxes of 2000. About 16" long, IIRC.) >> As an aside, take a look at the UNIVAC 1107/1108 instruction set from >> roughly the same period. It has an instruction to define the byte size >> (36 bit words). > Hmm, interesting. I can't really even wrap my head around the implications. > If you can't change the register sizes, why would you want to do that? Was > it just to shorten certain operations by increasing or decreasing their width? For the same reason you do it in the PDP-6/PDP-10: Data often comes in the form of text characters, which are much smaller than the word size, so it makes sense to pack them in. On the 6/10, the common method was 7-bit ASCII packed 5 per word. With instructions for operating on byte pointers available, you set your initial pointer up such that an increment will end up pointing at the first byte in a word; Macro-10 had a pseudo-op for doing that (or pointing at any other byte in the word, depending on what you needed to do). In addition to the byte size and location within the word, the indexed and/or indirected address of the word is in the one-word byte pointer. The most commonly used instructions are ILDB (Increment pointer and LoaD Byte into AC) and IDPB (Increment pointer and DePosit Byte); there are also LDB and DPB (good for status-checking operations, for example), IBP (Increment Byte Pointer), and on the KL-10 and later processors, ADJBP (ADJust Byte Pointer, which can back up as well as move forward). If the byte size is such that no room is left in the current word, the first byte in the next word in memory is addressed. The networking code uses a lot of 8- and 16-bit byte pointers, to handle the fields in IP datagrams. Other I/O code uses other byte sizes, to pull out or set the relevant parts of device register values. A quick example, which substitutes a space for a rubout in a text string without having to copy it into a second: txtptr: point 7,string ; sets up to point to the non-existent byte ; before string move 10,txtptr ; initialize pointer in loop top: ildb 11,10 ; increments pointer, copies byte into AC 11 skipn 11 ; non-null value? jrst bottom ; no, end of string, exit loop caie 11,177 ; is it a rubout character jrst top ; no, get next character in string movei 11,40 ; change a rubout to a space dpb 11,10 ; deposit byte into same location it came from jrst top ; and continue bottom: <whatever> PDP-10 operating systems in general use null-terminated strings. Hope that helps you with capital wrapping. Rich Rich Alderson Vintage Computing Sr. Systems Engineer Living Computer Museum 2245 1st Avenue S Seattle, WA 98134 mailto:ri...@livingcomputermuseum.org http://www.LivingComputerMuseum.org/