actually when it all shows up as cc talk as the sender it is of value
as we can clear the group of mail faster after I have picked out the
topics relative to what we are working on.
Ed#
In a message dated 3/1/2017 2:47:11 A.M. US Mountain Standard Time,
cctalk at classiccmp.org writes:
On 28 February 2017 at 21:23, Rich Alderson via cctalk <
cctalk at classiccmp.org> wrote:
> OK, it's official. I rarely criticize mail interfaces, because they're
> usually
> mostly innocuous. However, today's change makes life a lot more
difficult.
>
> In the past, it was simple to direct a reply to an individual instead of
> to the
> list because the originator's address was right there in the From:
> header. As
> of today, the list address is substituted for that, so that it is
> impossible to
> respond privately...
Users.
--
Yoyodyne Propulsion Systems: "The Future Begins Tomorrow"
Visit us at: http://www.yoyodyne-propulsion.net
--------
"When a true genius appears in the world, you may know him by this sign,
that the dunces are all in confederacy against him." -- Jonathan Swift
On Wed, 1 Mar 2017 cctalk-request at classiccmp.org wrote:
> Message: 17
> Date: Tue, 28 Feb 2017 20:10:33 +0100
> From: Lars Brinkhoff <lars at nocrew.org>
> To: Mattias Engdeg?rd <mattiase at acm.org>
> Subject: Re: DEC VT100/220 line wrapping semantics sought
> Mattias Engdeg?rd wrote:
> > Data for VT100, VT220 and VT510 have been collected, as well as
> > several emulators
> > (https://github.com/mattiase/wraptest/blob/master/results.txt). If
> > anyone has access to other working terminals, VT3xx/VT4xx in
> > particular, I'd be most grateful if you would take a few minutes to
> > run the test program.
>
> I have a VT420 set up for my kid to play with. I'll borrow it and
> submit a pull request with the results.
>
I have a VT525 in my home office that I use to read the mail (including
this and other mailing lists) when I don't want to fire up a workstation.
(It's quick, simple, and I get check/send a message without much fuss).
Would results from that terminal help?
Fred
Ersatz-11 V7.3 is finished. CDs have been mailed to users with current
update subscriptions, and the free Demo version may be downloaded from
www.dbit.com/demo.html as usual.
E11 V7.3 has the following new features:
- My favorite one: a BREAKPOINT command which accepts arbitrary boolean
test expressions, compiles them into native x86 code (to reduce the speed
penalty), and incorporates them (until disabled with BREAK/CLEAR) into
the main fetch/decode loop). Examples:
break pc >= 2000 and pc < 3000 and @(r4+4) = 42776
(range of code with specified value in block pointed to by R4)
break ci(pc)&177400 = 104000
(about to fetch an EMT instruction)
break phys(14634520) <> 3044
(location at physical address gets changed from expected value)
Errors at run-time are silent. If a specified test causes a bus timeout,
odd address trap, or division by 0, the test fails. Well OK division by
*constant* 0 gives an error but I just mean nothing damaging happens if
the registers aren't pointing where you thought, etc.
- A few rare antique emulated devices: DC11 SLU. Basically similar to
the DL11 (ignoring the extra CSR bits and programming it like a DL11A
works), but it also has a settable baud rate and modem control which
is different from how it was done on DL11s.
- Also the DM11 single-speed serial mux (not that E11 minds running each
line at a different speed, but the original did). It uses DMA for
transmission but also for reception into an in-core FIFO which the
documentation adorably calls the "tumble table". And yes this is the
origin of the DM11BB modem-control option more commonly used on the DH11.
There's a new command to tell DM11BBs which to attach to (the default is
still the DH11 with the same controller letter).
- Finally, the justifiably forgotten TR79F 1600 BPI tape controller for
TR79 drives (really HP7970Es), which includes the parity track in core
with each byte of tape data taking up a word, so it's a pain to program.
But it had 1600 BPI pretty early. The only driver I can find for the
TR79F is in the "TRDP" version of XXDP, which is on Bitsavers as a scan
of a microfiche of the listing. It can be used to load the ZTRAB0
diagnostic (the only other program I know of for the TR79F), but of
course the test immediately trashes your boot tape. I felt dumb.
- Driver for raw ATA/SATA/ATAPI disks (DOS and stand-alone versions).
- Driver for National Instruments PCI-DIO-96 digital I/O card (DOS and
stand-alone versions). It's a bad fit to emulating the DRV11/DR11C
(ASSIGN OA: DIO96: does work but you'd have to wire up an adapter with
buffering since the drivers are rated at only 2.5 mA) but it's probably
the most common digital I/O board around. Even though it's PCI (not PCIe),
it's still made new (at great expense), but cheap used examples are
everywhere.
- Ability to use a digital I/O card to drive real display and switch
registers. Wiring up a blinky-lights board for your $25 eBay PCI-DIO-96
is a lot easier than making one for current PC busses, even if the
100-pin D-shell plug is a pain (but AMP makes an IDC connector that
brings it out to two 50-pin Bergs)..
- SET HISTOGRAM command enables/disables histogram of PDP-11 opcode usage
(which again is temporarily compiled into the main loop when enabled).
HISTOGRAM command displays the results or saves them to a file.
- EXAMINE/DEPOSIT /BYTE /WORD /LONG /QUAD switches support various data
types besides just words. Finally.
- MOUNT <tape> FILE.TAP /LENGTH:n or /SIZELIMIT:nMB enables emulation of
EOT early warning flag (giving the approximate maximum length of the
tape in feet or megabytes). Not generally needed (who minds an unlimited
tape?), but some diags want to fill a tape with test data all the way
to EOT.
- ASSIGN <TTY or digital I/O device> NULL: /LOOPBACK switch. Does what
you think.
- Experimental POWERFAIL command simulates power failures on command,
or SET POWERFAIL command schedules one at shutdown (with a core dump
to a file). Thank you Oleg Safiullin for the idea! Might need some
changes -- I've never dealt with power failures on a real PDP-11.
- Dramatically improved timer precision in DOS and stand-alone versions.
SET THROTTLE in particular is silky smooth, but this improvement affects
many many things.
- All commands that take a time duration as a parameter will now accept a
decimal point and/or unit suffix. The default units are the same as in
previous versions. So instead of SET THROTTLE DELAY=1 (microseconds),
you can use SET THROTTLE DELAY=1.2 or SET THROTTLE DELAY=1200NS (values
will be rounded if needed). I hadn't realized so many places use time
values -- I might have missed something.
There are also many bug fixes and minor changes, but most importantly:
- WMSG.LOG file that grows and grows (in Windows versions). Sorry about
that! That was supposed to be disabled in the released version. Well
it is now.
John Wilson
D Bit
I don't know if anyone here has the interest or capability to do it, but
creating a replica of the blue tape trays with the clear overlay that
one could sell for a few bucks with some random fanfold copies of DEC or
other diagnostics would be nice.
Perhaps if there were a ready source of replicas with a perpetual
listing or 10 to overwhelm the auctions with 100 and 300 dollar auctions
for the genuine originals the originals would be listed and sold for a
reasonable amount.
I'm sure there there are things going to people with no idea what they
have which would have been nice to image and save. I would think
someone with vacuum molding and some skill with plastics could do the
trays. not sure about the source of tapes to sell with them, maybe that
does justify some extra expense.
People with working readers and libraries of tapes might like them as well.
thanks
Jim
Would someone with a real DEC VT terminal be so kind and help settle, once and for all, the question about how they behave with respect to line-wrapping, exactly? It is something that isn't covered by any standard, nor by any of DEC's manuals, and there is a scarcity of information online that is not vague repetition of folklore.
There are emulators, of course, but these do not agree with one another to the point that they can be trusted, and are probably just copying each other in any case. It seems that some ground truth would be welcome, for the benefit of both application and emulator writers.
First, the problem: A VT100, when in "auto-wrap" mode, will wrap text from one line to the next in a peculiar way, sometimes called "soft-wrap" or "the VT100 glitch". When the terminal receives a printable character with the cursor in the last column, the character is put at that location but the cursor remains in place. Instead, the terminal enters a pending wrap state, which causes the cursor to wrap before next printable character is displayed. This behaviour is widely known.
What isn't widely known are the finer points:
* What control codes will cancel the wrap state?
* What cursor position is reported in the wrap state?
* Do any operations behave differently in the wrap state?
* Is the wrap state saved/restored by the save/restore cursor codes?
and so on. Every emulator programmer seems to have a different answer to these questions.
If you have a VT100, VT220 or later model (compatibles like Wyse are also of interest) and have a spare moment, I'd be most grateful if you would download and run
https://raw.githubusercontent.com/mattiase/wraptest/master/wraptest.c
in that terminal, and send me the resulting output. (Redirect stdout to save the report.)
The test program is not comprehensive but would give us a good idea of the rules.
Current results, right now only from various emulators, are found in
https://raw.githubusercontent.com/mattiase/wraptest/master/results.txt
OK, it's official. I rarely criticize mail interfaces, because they're usually
mostly innocuous. However, today's change makes life a lot more difficult.
In the past, it was simple to direct a reply to an individual instead of to the
list because the originator's address was right there in the From: header. As
of today, the list address is substituted for that, so that it is impossible to
respond privately unless you happen to have a bunch of old messages archived and
the person to whom you want to respond is someone who has written previously.
Is this a conscious choice, or a configurable with a different default setting
in a new mail system than was previously in place? However it came to be, it
greatly diminishes communications quality (IMAO).
Rich Alderson
Vintage Computing Sr. Systems Engineer
Living Computers: Museum + Labs
2245 1st Avenue S
Seattle, WA 98134
mailto:RichA at LivingComputers.orghttp://www.LivingComputers.org/
This is probably a long shot, but does anyone have a Sparcbook 3TX hard
drive? I know they're difficult to find.
I have a 3TX in great condition, but no drive.
(hopefully this isn't a repost, I tried this when the list was having
issues and don't think it went through)
--
Ben Sinclair
ben at bensinclair.com
> From: Tony Duell
> I fail to see how anyone can be a good digital designer and not
> understand analogue electronics.
It's easy! As long as your devices are being run in a domain where their
behaviour is purely, well, digital, one can get away with it! :-)
I'm a perfect case in point!
I seem to have some bizarre brain dysfunction where I have a very hard time
understanding even the simplest analog circuits. You, or someone like Brent
Hilpert (whose explanation of core memory drivers I still remember :-) can
explain something with sufficient clarity for me to 'get' it, but I can
almost never work it out on my own.
However, I've designed a number of digital devices, at least one of which
became a product!
Noel
> From: Rich Alderson
> it is impossible to respond privately unless you happen to have a bunch
> of old messages archived and the person to whom you want to respond is
> someone who has written previously.
If you go into the list archive:
http://www.classiccmp.org/pipermail/cctalk/
the email address of the sender, for any given message, is still listed (in
slightly mogrified form).
Noel
So sorry for the temporary email outage on the list. We're moving
datacenters and one of my folks moved several front end mail processors -
not realizing that the classiccmp server which stayed behind was still using
them.
Through the magic of a vpn tunnel between front end mx hosts and the backend
mailstores (classiccmp included), it seems to be back up. I'll talk to the
guy tomorrow to discuss the actual movement of that vm. Yes, IP's will be
changing for the list and all websites hosted therein. But DNS is "a thing",
so should be mostly transparent. Depending on timing, I may go ahead and do
some upgrades and recombine the lists - or may do that after the move.
I'll try to do a better job of coordinating this..
Best,
J
