The displays could do vector-drawn text ("calligraphic") or arbitrary graphics by drawing dots (basically just periods). No line vectors. Plot speed was about 2.5 microseconds per character. The displays did not have any kind of refresh memory -- instead, the controlling software would just redisplay stuff fast enough. This meant that your status display was always up to date, because it was rebuilding the display from the current state each refresh. This is very handy to get a feel for what a system is doing. For example, if something gets stuck, the corresponding display element would freeze. If things were running, that element might flicker or be a blur. You'd get the same intuitive view of stuff as you do with a classic "lights" console (only more so). Text could be displayed in three sizes; the smallest characters were 64 across, 32 lines, per tube. I suspect one reason for two tubes is the same reason that people today put two displays on their desk: more screen real estate to show more stuff. Given the way the circuitry was done, two displays were only slightly more expensive than one. The controller would send the signals to the tube pairs, and a tube select signal would control which tube would light up for that particular signal. So things like the character waveform generator did not have to be duplicated. I've seen some photos but haven't run into videos. There's an emulation that fairly accurately shows what things looked like; one could do screen capture videos from that. But that wouldn't be quite the real thing. They all started out as batch (card deck input), unless you count job entry from the console display which was for operator use. Remote Job Entry showed up in some of them, as did timesharing. The early timesharing stuff was amazingly primitive but it worked. Roughly speaking you'd enter the same commands as might appear in a card deck, but each would be executed when entered. Bytes, in the sense of 8 bit clumps that were addressable, showed up in the IBM 360 series. Before then, and for that matter in many other computers for years after, machines tended to be word addressable, and character sizes might vary. 60 bits with 6 bit characters (usually) is one example. 36 bits with 6 or 7 or 8 bits is another. 48 bits with 8 bit characters... the list goes on. If you think these are odd, consider the Electrologica machines, with 27 bit words and 5, 6, 7, or 9 bit characters. paul

On Wed, 22 Jun 2016, Chuck Guzis wrote: The descriptions are fascinating. I hope I can see one operating some day. Do you know of any still operational ? So far my only comment on the Stretch is "I also hate project managers." I'm always happy to see corporations lose (scads of) money for a good cause. Hmm, now that I think about it, it doesn't even need to be a good cause. :-) 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. Well, it probably didn't need to do much multi-process multi-tasking, so that probably still worked out fine vis-a-vis the competition. Could you roll them back in by just re-populating memory with the dump and hooking back to whatever the equivalent of PC and EIP were on that system and re-launching the job? I'm not fond of them. They waste a ton of money (classified budget!?) on projects that never see the light of day. I contrast their efforts with folks like NASA where a lot of (amazing and super important) tech found it's way to the public domain. I would cheer to see them de-funded, renamed, and irrelevant. Ah, okay, good to know. Awww, darn. I thought that was pretty cool about the 6600, actually. Time marches on, I guess. Thanks for that description, that helps a lot, actually. I'm an "applied" guy and I'm not very imaginative when it comes to theoreticals. So, knowing the nuts and bolts operational stuff helps me to understand how the abstract parts fit together. Hehe, isn't that always the way it goes. Version 2 is always much harder to get right. Interesting! I really like little tidbits like this when I'm piecing together a "system narrative" again, it puts some things in perspective. Sure it can. I've done that on the M68k before, too. It's a mechanism I've used for to create more complex mechanisms. Rotate with carry was something I often found useful, too, since I could use the carry bit for a conditional jump. Hehe, clever. I guess that's working with what you have, though. 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 ? Well, they picked ones that are soothing to mine eyes. That's a pretty micromanaging standard, though (I skimmed it). I can just see some style-nazi jerkhole in the back with the guide nitpicking everyone's comma placement. "How DARE you put a space before the comma on the destination operand!" *apoplectic choke*. Still, I've had gigs where there was no style guide and it can create stress and friction between coders. So, I guess it's better to have one than to just have the wild west. Otherwise, you'll give people a pass who want to show you how clever than can be in various extremely annoying ways. In C, it's usually someone who thinks it's cool to use one-letter variables for everything, and make all his lines 180 columns long. I've never had to peer review someone's ASM. It'd be pretty painful, I think. -Swift

On 06/22/2016 01:58 PM, Swift Griggs wrote: You don't seem to realize how expensive these systems were to operate. IIRC, the *internal* COMSOURCE price charged for an hour of block time was about $500 (that's 1970s dollars, thank you--when $3K would buy you a nice imported sports car). There *was* a PP program called o26 (after the keypunch) but used mostly by CEs and systems installation people. Using the console of such an expensive machine by ordinary users would have been viewed as something akin to feeding $20 bills into a regular keypunch. Remember, this was in the era of "glass walled rooms", where only selected people were allowed to touch the machine. I once made the mistake of trying to mount my own tape at a military base. I thought that I was going to be tackled and led away by MPs. They have people stationed by each bank of tape drives who do nothing but that all day. They don't take kindly to someone trying to take their job. You don't understand. Big iron did multitasking and multiprogramming, but the I/O media was cards, tape and printed output. Going "online" was expensive and slow in terms of equipment. The rolled-out job didn't lose its files or place in the running job queue; it just got represented by a placeholder bit of memory (usually the exchange package) and then read back in when its turn came up. Sometimes the non-classified parts were repurposed. For example, TCM/TOOS was used for both USAF Logistics and UBS (Switzerland) projects. Called different things, of course and code shared only up to a point. Remember that SAGE was classified. The military and defense industries were major funders of big iron work. Who do you think Seymour Cray sold to as his initial customers for his boxes? There was a lesson to be learned from it--give the I/O to another, cheaper, machine. You'll see that philosophy in the later Cray machines. The 6000 had no carry bits; for that matter, it had no condition codes at all. If you think about it, that makes instruction scheduling much easier because you don't have to worry about instruction side-effects. On the X (60 bit registers), you can branch on the sign of a register or its zero/nonzero contents. B-registers can be queried by a single compare and branch instruction. It also helps that the 6000 is a three-address architecture, so you needn't clobber a source register when testing contents. And the smallest instruction was only 15 bits wide. To elaborate a bit, you could divide a word into sixths, halves and thirds (6, 18 and 12 bit) parcels and operate on each of them. So not really a "byte". It was a necessary evil with long product lives, many people, etc. "Egoless coding". Try doing something else and you wind up with Linux code eventually. Miles of code without a clear comment on what's happening--or why. Worse, yet, stupid comments. I once knew a young programmer who was quite proud that *every* line of his code had a comment on it--even if he never explained what he was doing. e.g., IX6 X3+X4 ADD X3 AND X4 AND PUT SUM IN X6 He carefully explained what each instruction did but not what he was trying to do. The old rule of writing "Tell people what you're going to say, say it--and then tell them what you've said" also applies to commentary, IMOHO. --Chuck

Slightly different. A rolled out job was a file, containing the whole job state, including stuff like currently attached files, memory content, exchange package (program registers). Like any other "local file" it would show up in memory as an entry in the file table -- just 2 60-bit words if I remember right. When selected by one of the scheduler components to be run again, it would be assigned a control point, memory, rolled back in, and execution resumed. Jobs could also be moved in memory without being rolled out; this could happen if they or some other job changed memory size, forcing something to move to make room. PPU programs would have to watch out for that to happen and "pause for storage relocation". Getting that wrong was a great way to wedge the OS; I've got that t-shirt... paul

On Wed, 22 Jun 2016, Chuck Guzis wrote: I'm sure I don't (but hey! give me credit for trying). I'm betting that even "expensive" systems of today (barring ultra-massive HPC SSI rigs) are cheap by comparison in inflation-adjusted dollars. I'm 41. I was born in the mid-70's and it was awfully time consuming afterwards learning pre-requisites to my computing skills, such as they are. Things like talking, correct potty techniques etc.. :-) Time I could have spent mainframin' if I'd only been taller. :-) Plus, I have all kinds of different experiences "coming up", as it were. Somewhere near my moment of conscious singularity, it was the age of the PC and the micro. Sure, mainframes were (and kinda still are) going strong. Even for guys who lived it in the 1960's, they didn't grow up with computers around the house I'm betting. So, it's a bit of a shift in our thinking. Hmm, and you'd want an imported one if it was the 1970s. Ugh. The drugs might have been good and the women more friendly, but the cars were a drag vis-a-vis the 1960s, OMG... What happened.... The 1980's weren't too much better (but I have soft spot for Fieros at least). Hmm, I totally didn't consider that, but certainly seems like the kind of way people would act around something so valuable and expensive. I guess my "altar of the console" phrase wasn't so bad, then (ie.. half true). Well, I started with computing very early, too. So, nowadays when I see those rooms I'm normally in the priesthood and am _expected_ to go fix some very expensive systems (I've put hands on production Origin 3k's, a couple of UNICOS based Cray systems, lots more). So, I kinda forgot about the outsider perspective, too. With many fewer systems around to work with, I'm sure the glass-walled sort of exclusivity got that much more serious. LOL, there's initiative and there's orders. You had initiative. They had orders. Hmm, but wouldn't being able to multitask and multiprocess lead directly to wanting to have multiple terminals, card readers, tape readers, etc..? Then wouldn't someone be responsible for setting process priorities and managing the process scheduling? I told you I was an igmo on this. All I have to go on are sketchy internet archives that don't give me a sense of the real way these systems were used by real people. The only other source about mainframes I had growing up was my grandmother, whom I worshiped as a child and worked on IBM gear. However, who knows what kind of kid-brained-notions I have grown into some personal fiction since then. Ohhh, okay. That makes sense. Some were, yes, and you cite some great examples. I'm just saying I'm more in favor of dumping bazillions of dollars on projects that more or less default into the public domain rather than default into top secret and someone has to justify having them released or shared. SDI in the 1980s sticks in my craw, I suppose. Unless of course they were secretly very successful and, in that case, I say "awesome"! I am strongly in support of not getting nuked! Fair point. I'm not anti-military, but the NSA I'd like to see behave more responsibly. I've noticed with really large systems they have some very interesting points of cleavage (just like their sales force, hehe). They split things up in ways that micros just aren't scaled for. It's one of the things I find so interesting about them (same goes for the sales force *grin*). Carry bits aren't a hack I'm particularly married to anyway, just something to use when needed, 'cause the hardware wants it that way. That sort of thing can be done in lots of ways, as this CDC box illustrates. That saves some code. I think I've seen other platforms that have similar features, but I'm only a hack at ASM in general. There are so many clever things I've seen people do with 68k ASM (the only one I can really get anywhere with) that sort of blew my mind insomuch that I have no idea how they ever got the idea for some of these algorithms or "tricks" in the first place. Perhaps at the foot of a Zen master somewhere? There was a guy I knew who went by "Sauron" in the 1990s... He was like Master Po. .... and another 2-3 lines saved ! It does add up, though. Ah, okay. They had specific factors, then. Agreed (sadly). No comments doesn't bother me as much as one-letter variables and over-compressing the name of everything to the point I can't figure out what they were even getting at. People often laugh when they see my code because of how long and descriptive the actual code is. Sometimes they complain that it makes it slower to slog through typing everything. I will trade code-clarity for (almost) everything else. That would be entertaining for the first few minutes, though! -Swift

On 06/22/2016 04:46 PM, Rich Alderson wrote: Well, if you were a serious programmer, major segments of code came in the drawer of a card filing cabinet (I don't recall exactly, but I believe one held about two boxes.) However, then the idea was to get them onto tape before something dreadful happened, such as being subjected to a jam or being rejected because of a compare error in the reader. I can recall on more than one occasion where an I/O clerk with a cart loaded down with card trays hit a loose trim strip in a raised floor. Mayhem indeed. If you were smart, you drew a long diagonal across the top of the card deck with a felt-tip pen to at least give you some sort of clue about the order. There were SCCS type of systems even back then. SCOPE had UPDATE, which corresponded to KRONOS MODIFY. Each card was assigned a set identifier and sequence number, used as reference when editing. Updates could be YANKed or PURGEd as necessary. --Chuck

I'm not sure why that would make it faster. I've only seen brass roller reading in an IBM card sorter, which ran probably as fast as, if not faster than, than the fastest card reader I've ever seen. paul

From: Chuck Guzis Sent: Wednesday, June 22, 2016 5:13 PM Well, sure, but I was answering Swift's student-sounding question. A card drawer held slightly more than 2.5 boxes' worth of cards, but you wouldn't carry that around, of course. Different colors, different patterns, anything to help. For that matter, cards were manufactured with different colors along the upper edge (where the printing went in a keypunch) to allow for this kind of separation. That predates electronic computers, I would wager. Oh, yes. We had that kind of thing on big IBM gear as well. Rich Rich Alderson Vintage Computing Sr. Systems Engineer Living Computer Museum 2245 1st Avenue S Seattle, WA 98134 mailto:RichA at LivingComputerMuseum.org http://www.LivingComputerMuseum.org/

On 2016-06-22 9:45 PM, Swift Griggs wrote: Do you have a counterproposal? What problem do you think UTF-8 is trying to solve? I haven't heard that particular complaint. Got a cite? --Toby

Nice. I have a copy of 1948 (!) lecture notes on computer design. It discusses one's complement and two's complement. It points out the advantage of two's complement (no two zeroes) but also the disadvantage that negating is harder (requiring two steps). In early computers that was significant, which explains why you see one's complement there. Another consideration which may have played a role is that with one's complement you need fewer instructions: bitwise complement serves both for Boolean logic and for negate, for example. The "two zeroes" problem is handled best by using the CDC 6000 technique: it doesn't use an adder, but rather a subtractor (so adding is done by subtracting the complement). If you do that -- an exercise for the student to demonstrate why -- the result will never be negative zero unless there were negative zeroes in the inputs. In particular, adding x and -x will produce +0 for all x. I just added a few more machines to the table in the Wikipedia article referenced by the comments you mentioned. https://en.wikipedia.org/wiki/Word_(computer_architecture) Another interesting aspect where people may not be aware of how much variety existed is in the encoding of floating point numbers. IEEE is now the standard, but PDP-11 users will remember the DEC format which is a bit different. CDC and IBM were different still. The Dutch machine Electrologica X8 had a particularly interesting approach (parts of which were adopted, many years later, by the IEEE standard). paul

Nice. The CDC 6000 description isn't quite right (or not clear) because a negative float is formed by complementing the entire word, not just the mantissa part. I'll feed the Electrologica details to the author of that page; they are different from everything shown there and have some interesting/useful properties. paul

On 6/23/16 8:17 AM, Chuck Guzis wrote: I have also heard that 2s compliment was popular in shorter word length machines because 1s compliment multiple precision arithmetic is a PITA to implement.

Something to look into.... in the Electrologica machines (Dutch computers from the late 1950s to mid 1960s), double-length values are encoded with the sign bit replicated in each word. I wonder if that makes this problem go away (entirely or mostly). paul

The CDC 6000 did that in part. It has full 60 bit integer add/subtract, but multiply and divide are done using the floating point operations so they work only for numbers up to 47 bits. The Electrologica X8 is yet another take on this. There, the mantissa is viewed as an integer, and the normalization rule is to make the exponent as close to zero as possible without losing bits. The consequence is that all integral values under 2**40 are represented as exponent zero and the mantissa equal to the number, which amounts to simply the integer representation of that number. This makes conversion from float to integer rather easy (and of course, conversion in the other direction takes no code at all). paul

On Wed, Jun 22, 2016 at 7:45 PM, Swift Griggs <swiftgriggs at gmail.com> wrote: Encode negative integers using this one weird trick! By the way, it's two's complement. A twos compliment would be something like, "Hey, nice twos!". #overlypedantic :-) It's just pointer arithmetic to add a signed integer to a character pointer, to move the pointer forward or backward some number of character positions. Of course, it can be used on anything represented in a PDP-10 byte, which can be any number of bits up to 36; it doesn't have to be a character per se, but character handling is possibly the most common use of the PDP-10 byte instructions.

Not quite. KRONOS treated ECS (rather clumsily) as a kind of disk. PLATO just bypassed all that and managed ECS directly, as memory the way it was originally designed to be used. After startup, PLATO would own all the ECS and do transfers directly, without any OS involvement. It would also use ECS for inter-job communication, and for communication with PPU programs. For example, PLATO disk I/O uses both request queues and data buffers in ECS, which the PPU program accesses. Ditto for terminal I/O. This is how PLATO could support 600 logged in highly interactive users on a pair of 6500 (low end 6000 series, single issue) machines. paul

Hey guys, I was looking and found that the Tektronix 4010 is a calligraphic display, for which I found a video! https://www.youtube.com/watch?v=IztxeoHhoyM Let me know if it bares a resemblance to the display on the 6600 On Wed, Jun 22, 2016 at 10:32 AM, Swift Griggs <swiftgriggs at gmail.com> wrote:

On Thu, 23 Jun 2016, James Vess wrote: I was just looking at those things, too! I've always liked Tektronix and these are wonderful. I found some picture of people doing what appeared to be CAD on them. There are descriptions of all kinds of creative things being done with them. About 15 years ago I did some work for a lumberyard company. They had the most consistent IT setup I've ever seen. They had very few actual computers anywhere. 95% of the company used terminals fed off serial MUXes tied over 56k or 128k leased lines back to their corporate headquarters. They used portable battery-powered hand scanners that plugged into the terminals' keyboard interface, IIRC. Those were for scanning their inventory. I noticed: * They had almost no IT staff, yet things ran pretty smooth. * They never had viruses. * Replacing "workstations" (terminals with more access to their business apps) took about 10 minutes. * They had some weird office automation package (word processor, time management, spreadsheet, etc..) I'd never seen before that reminded me a bit of that one office product from DEC for VMS (I can't remember the name, but I think it was written in DCL). I don't know enough about VMS. The bosses and admin assistants ran that and they absolutely loved it. It was very fast and the kind of thing were once you memorized the keystrokes you could just fly through it. * They had a coder who wrote some really cool blackberry-like features for the Palm Pilot. They could sync all kinds of business related stuff from their Unix boxes (mail, order information, inventory, etc). The bosses all had those. It's the only place I ever saw, besides the (extremely well funded and very nice) Don Harrington Library consortium that was able to really get some mileage from a hub-and-spoke, terminal based, WAN distributed, highly integrated, centralized system. From a sysadmin perspective, it seems like it makes a lot of sense. Just cluster a few robust systems and tie everything you can into them once you've got your confidence up! However, I think most folks these days would faint if they were forced to work on a terminal. 1. They couldn't play minesweeper when they got bored. 2. They couldn't refresh Twitter & Facebook every 5 seconds. 3. They couldn't run an IM client. 4. They'd have to actually read the screen. No icons. 5. How would they do their jobs as users and infect the thing with crapware and viruses? I often setup terminals on my desktop as "extra heads" to display logs or monitoring information, or sometimes use them for debug output for coding projects etc... When I'm working at a big corporation it absolutely freaks just about everyone out and their reactions are mostly quite annoying. It pains me to hear people use the words "text" like it's a curseword. Plus, they also just stand there stunned and say "but.... but.... that's OLD!" as if I were violating some local ordnance not to poop on my desk. I smile when I go to the auto parts store and they are still using terminals. Never say die! I think terminals were, and actually still *are* cool. Computers might be cheap now, but that doesn't mean that having centralized control with users on terminals isn't still useful in many instances/situations. -Swift

Not Tek but I've seen directly two instances where simple terminal UI's where very much missed by the end users. The one I remember the most was a nationwide auto parts company who I wont mention who. The stores used 80x25 ASCII terminals with forms and fields and just about every function key did something. Once the UI was learned watching a counter person was quite amazing, someone with an account would walk in ask for a price on something and if say ok you would in less time it would take for one to move a mouse and click a button on a modern UI, a dot matrix printer had printed out the three part NCR paper invoice. Other then going to get the part and rip the 'holes' off the invoice paper the guys hands never left the keyboard. After conversion that simple terminal became a PC with a mouse, a fancy gui front end, blue screens of death, virus scanners, and software contract for the O/S, the fancy gui client, etc. etc. Not to mention pissed off customer because it went from a few seconds hit half a dozen of F keys, hit the tab key a few times to a good dozen mouse moves, clicks, open windows, wait for a megabyte or two of data to go back and forth, reboot the PC in the back room because the Printer Spool crashed, and ...... On Fri, Jun 24, 2016 at 7:50 AM, emanuel stiebler <emu at e-bbes.com> wrote:

On Fri, 24 Jun 2016, Paul Koning wrote: That reminds me vaguely of RIP at the end of the BBS era. It probably could do a partial-refresh/erase, but if you watched it "paint" images, that's how it appeared. I was glad that the Internet-era came along, but it's sad RIP didn't come along earlier. I also remember some kind of BBS terminal emulator that I only saw over someone's shoulder. It was for the Amiga and appeared that it could transmit/receive sprite-based graphics over the modem connection. I just remember watching a friend of a friend connect to a BBS overseas and I they had some kind of welcome screen with a little sprite-based unicorn running across the screen. I dunno, maybe it was a rigged demo, but it showed me that "terminal emulation" could be all kinds of awesome stuff. -Swift

And HTML, which is 3270 updated for the 1990s.