test-drb

test-drb@ccmp.vtda.org

101090 discussions

by dastar＠wco.com

Check out Tandy's version of history from their web page: "1977 TRS-80 Model I Personal Computer introduced. (First mass-marketed personal computer. In contrast to build-it-yourself computers available at the time, the TRS-80 was fully-wired and tested. Sold at a breakthrough price of $599. More than 200,000 TRS-80 computers were sold from 1977 to 1981.)" Ok, let's conveniently forget about the Apple ][. This is the most blatant denial of reality and outright lie I've ever seen a company publicly endorse. "1980 TRS-80 Model 100 Portable Computer introduced. (First computer ever to feature five programs and a telephone modem built-in. Used by journalists throughout the world.)" First I question the year (I know it was later than 1980). This claim is dubious at best. Mostly its broad and irrelevant. It seems they're trying so hard to make this seem like a breakthrough (it was) that they forgot to mention the real reasons why. "1984 Tandy 1000 Personal Computer introduced. (First PC-compatible personal computer. Within one year, the Tandy 1000 became the best-selling PC-compatible computer.)" God, what a load of chicken turds. I think they missed this distinction by 3 years and umpteen other companies. I'd like to kick the guy who wrote all this crap in the nuts. Sam Alternate e-mail: dastar(a)siconic.com ------------------------------------------------------------------------------- Ever onward. September 26 & 27...Vintage Computer Festival 2 See http://www.siconic.com/vcf for details! [Last web page update: 05/11/98]

28 years, 2 months

Steve Wozniak home page

by stephen.j.gabaly＠lmco.com

For anyone that's interested Steve Wozniak has a home page at www.woz.org <http://www.woz.org> . He has a digital camera in his office which you can point and zoom to see what he is up too, just click on the wozcam button. His email address is also there, I have emailed him several times about questions I had on the early days of Apple, he responded quickly (few minutes). Generally if he can answer the question off the top of his head, he will, otherwise he will politely tell you he is too busy. I think I have used up my quota of questions for the year so perhaps someone on this discussion group can organized a question of the month so he won't get bombarded with a hundred questions and change his email address. Just a thought. steve

28 years, 2 months

Processing data in blocks

by allisonp＠world.std.com

<At 10:42 5/28/98 -0700, Roger wrote: <>Wordstar on the Otrona Attache was also very WYSIWYG because the Otrona <>could do any video attribute Wordstar ever dreamed of.... < <Nice keyboard, too. Visual 1050 had all the char modes and graphics as well. The keyboard is better than many. Allison

28 years, 2 months

Processing data in blocks

by fmc＠reanimators.org

"Max Eskin" <maxeskin(a)hotmail.com> wrote: > Back when I asked about the HP 3000, someone mentioned that it > processed data in blocks. What exactly does that mean? How does it > work? Tim's answer got part of it. Here's some more of the picture, maybe in gorier detail than you wanted to know. Many HP terminals are somewhat intelligent and can be told (via escape sequence or strap setting) to operate in "block mode", where the terminal buffers data in its local display memory and lets the user do local editing of it there. There can also be protected and unprotected fields, which basically turn the display into a fill-in form where the user can type in the unprotected fields and not in the protected fields. Some keys (ENTER (not RETURN) and the function keys) will still initiate a transfer to the host computer. How that works is a collection of fiddly little details but I'm going to try to describe it in terms of the DC1/DC2/DC1 block-mode handshake. Once the form has been sent to the terminal by the application (which basically sends escape sequences and text to set up the block mode, the form, and the unprotected fields), the application starts a read. The terminal I/O system then sends a DC1 (control-Q) to the terminal so the terminal knows there's a read pending. When the user presses ENTER or a function key to tell the terminal to send the form, the terminal sends a DC2 (control-R) to the host as an indication that there's a block of data ready for transmission. The host does whatever it needs to do to get ready for the block (this was important in the days of the Series II/III which used a terminal controller that couldn't handle all 16 ports sending 2400 bps data at the same time) and then sends another DC1 as a go-ahead, and the terminal sends an escape sequence for the pressed key followed by the block of data (usually the data from the unprotected fields on the form, separated by field-separator (FS) characters, and finishing up with a record-separator (RS) character). The terminal won't send anything more 'til it sees another DC1 from the host. OK, well, that's about what you see on the wire if you stick a serial line analyzer in between the 3000 and a terminal, and watch as an application written using one of the more popular block-mode application subroutine libraries (VIEW aka V/3000 aka VPLUS/3000) is in use. Later 3000s have terminal controllers that can handle full speed on all ports, and they can use a simplified block-mode handshake (i.e. the 3000 sends the initial DC1, and the terminal just sends the block when the user presses ENTER or a function key). The goal of all this was, as Tim said, getting a rather slow HP3000 to run a surprisingly big bunch of terminals doing transactions against data on the 3000. The 3000 didn't have to do any work for the user until the user had the transaction edited on the screen, in particular it didn't have to respond to every user keystroke, and as the terminal didn't have anything better to do it could respond to the user's keystrokes right away. There were also some full-screen editors that relied on the terminal to buffer lines of text and let you do your editing in the terminal. Those I used tended to run in line block mode (vs. VIEW which I think used page block mode) where once the user pressed ENTER the host would home the cursor and start sending escape sequences ("<ESC>d" I think, followed by a DC1 once the read was pending) to get the terminal to send the current line 'til it got to the bottom. Feel free to ask questions about this if you want to know more. -Frank McConnell

28 years, 2 months

Processing data in blocks

by IVIE＠cc.usu.edu

From: Frank McConnell <fmc(a)reanimators.org> > HPWORD was actually a little more WYSIWYG than, say, Wordstar, because > the terminal actually had bold and italic faces and underlining > features. Wordstar on the Otrona Attache was also very WYSIWYG because the Otrona could do any video attribute Wordstar every dreamed of: italics, underline, strikethrough, bold, etc. Roger Ivie ivie(a)cc.usu.edu

28 years, 2 months

VAX 785 Backplane Schematic

by DSEAGRAV＠toad.xkl.com

Anyone have the printset describing the VAX 785 CPU backpanel? I'd be interested in a scan of it... -------

28 years, 2 months

More stuff acquired

by jon＠techniche.com

Hi, I've not participated much since I joined this mail group a number of weeks back, so I thought I'd make myself heard. A few of you seem to be pretty familiar with HP equipment so maybe you can tell me what I have (or have not) here. I pick up a box of junk at the local recycler several weeks ago. It caught my eye because it has some microprocessor emulator pods. In the box were the following: Z8002 emulation pod, HP part # 64233A (says use with 64271A) Z80 emulation pod, HP part # 64252A (says use with 64251A) 6801/6803 pod, HP part # 64256A (says use with 64255A) also the following boards: 64300/66501 internal analysis bd 64154/66501 Static Ram board (only one of 4 rows has sockets installed) 64152/66501 Static Ram board (All 4 rows socketed and populated) [both of the above have 2147 memory chips] 64211/66501 680x Control board I called HP and asked what the pod normally connect to, just in case it was still down at the surplus store and I had overlooked it. HP says that they would normally be used with a "frame" (?) i.e. some sort of general purpose analyzer having a part number of 29000 or 29120 (these two number are from memory since I can't find my notes at the moment where I wrote down the two numbers. It was either 29000 or 59000 but I'm pretty sure it was 29000). I was attracted to the emualtion pods because they looked like they had never been used. All of the pins appeared to be straight and intact. There was protective foam one each pod. What can you guys tell me about these? I'm thinking that without the frame they are not very useful to me. Perhaps they're worth something in trade? Thanks, Jon

28 years, 2 months

Processing data in blocks

by fmc＠reanimators.org

"D. Peschel" <dpeschel(a)u.washington.edu> writes: > I hope the invitation isn't directed at only one person. :) Nope. > One thing I realized from the exposure (and have since read about) is > that the local editing features are usually horribly limited, _and_ > they're impossible to extend unless you modify the hardware. What > kind of local editing do the HP terminals provide? (Any fancy cursor > movement keys, line editing, cut- and-paste, etc.?) I'm trying to get > a feeling for how well the HP editors stack up against more modern > ones. The line editor sounds pretty nice, actually. (I use vi -- > which is the same kind of full-screen line editor -- a lot. The > navigation commands are nice and quick.) For what passes for full-screen editing, the display is pretty much something you can type on. Cursor movements available are up, down, left, right, page up, page down, home (top-of-buffer), and end-of-buffer. Typing defaults to type-over but there is an insert-char mode that you can turn on and off from the keyboard. If you do this, wrapping is kind of simple (it will open up a new next-line and wrap characters onto that as they go past the right margin). Also you can delete characters from the keyboard (but this does not un-wrap wrapped characters). It's also possible to delete lines and add blank lines, and clear to end-of-display. Not cut-and-paste, though; well, if you can use the memory lock feature of the terminal you might be able to do it but some of the full-screen editors used it in a way such that if you tried to use it you would screw things up and lose work. Things are somewhat different if protected fields are set up; those will limit character insertion and deletion. > I mentioned reading... there are stories about people trying to > combine full-screen interactive editing with local terminal editing, > and finding that the two don't mix. The people usually bit the > bullet, invested in the extra hardware, and gave the workload back to > the CPU. I think there was an enhanced version of TECO at Stanford > that falls into this category. I know that Emacs on MULTICS was > developed like that. Mind pointing me to some of those stories. HP did something odd in the early-mid 1980s: HPWORD. This was a word processing system for the HP3000 that used 2626W (and later, 2628A and HP150) terminals as intelligent front-ends. When you first started HPWORD after turning the terminal on, it would spend about 10 minutes downloading code to the terminal, and then the downloaded code ran the interface and the communications link back to the HPWORD process on the 3000. I was told at the time that the terminal handled processing up to the paragraph level, and got the 3000 to do anything larger. HPWORD was actually a little more WYSIWYG than, say, Wordstar, because the terminal actually had bold and italic faces and underlining features. And it was nifty because you could queue up a print job >from one terminal to a printer connected to another HPWORD terminal; the backing HPWORDs running on the 3000 would talk to each other and get the document printed. Oh, and someone could be typing on the terminal that had the printer connected. All in all, it was a cheaper solution than PCs in the 1983-1984 time frame when we bought into it -- we didn't have to buy a printer for every workstation, and we didn't have to pick a PC LAN with lots of funny cabling. > Personally, I found the local editing completely inadequate for > dealing with the multicolumn file lists and pop-up windows the AS/400 > kept putting onscreen. Using only arrow keys to move the cursor to > precise places all over the screen was a real chore. The designs of > input and display just didn't match ewll. Yeah, and back then I used to switch between editors depending on the job at hand. Some things just work better with good old EDIT/3000, and even for editing code I liked QUAD. Later when I went to work at Wollongong I discovered Voodoo on the 3000 there and got kind of used to it; it tries to be vi-like but the inherent inability of the 3000's terminal I/O to accept characters without a pending read (and to do anything else while there is a pending read) really got in its way sometimes. Now I just use Emacs (though not on the 3000), and quite frankly I do think it works better. -Frank McConnell

28 years, 2 months

IBM SYSTEM 36 IN RICHMOND, VIRGINIA NEEDS LOVING HOME

by Marty＠itgonline.com

An IBM System 36 (Type 5336 or Type 5360 depending on whom you speak to) is available free in Richmond, Virginia at CW Wright Construction Company. Contact Vaughn Atkinson or Bob Jennings @ 804-768-1054 for more details. Marty

28 years, 2 months

DEC Rainbow available in Cambridge UK

by kevan＠heydon.org

Hi, I have a DEC Rainbow that I want to pass onto another collector. I live in Cambridge UK, and while I can deliver for a short distance collection would be the best as there are quite a few manuals that go with it. Drop me an email if you are interested -- Kevan Old Computer Collector: http://www.heydon.org/kevan/collection/

28 years, 2 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

test-drb