DEC archives

[Mark Kahrs via cctalk]

In case you hadn't heard, the DEC archives at CHM are available and here's
the PDF:

http://archive.computerhistory.org/resources/access/text/finding-aids/102733963-DEC/102733963-DEC.pdf

Now, I wonder if it has Firefly docs...

Re: Old IBM Ref Manuals / Old Parts HP9000 boards

[Keven Miller(rtt) via cctalk]

All have been claimed.
Keven Miller

Re: Electronic Systems TRS-80 Serial I/O Board?

[Jon Elson via cctalk]

On 06/13/2017 07:59 PM, Chuck Guzis via cctalk wrote:
Well, I didn't say "timing error", I did say "timing 
distortion", which is not quite the same thing. My 
reference was the "TR1602/TR1863/TR1865 MOS/LSI 
Application Notes Asynchronous Receiver Transmitter", 
which can be found in the WD 1984 Data Communications 
Handbook (I think there's a copy online). Page 126-127. 
"Thus, signals with up to 46.875% distortion could be 
received."
Well, I think it is wild market-speak inflation.  Yes, if 
everything else was perfect, then as long as the serial data 
was at the correct level while the UART sampled the signal, 
the rest could be garbage. But, how will a seriously 
degraded channel ALWAYS pass the signal correctly just when 
the UART samples it?  NOT very likely.


Jon

Re: Electronic Systems TRS-80 Serial I/O Board?

[Chuck Guzis via cctalk]

On 06/13/2017 06:27 PM, Eric Smith wrote:

> They sold it, then spent a bunch of money on Field Service trips to make
> it work for customers. It cost them enough to justify multiple
> redesigns, including (finally) switching to a crystal.

The TRS-80 board?   Do you have any documentation on Field Service
Trips?  That'd be amazing.

I'll add that a lot of low-end MCUs make use of internal RC oscillators
for their BRG--and they do just fine, right up to 115Kbit.

--Chuck

Re: Electronic Systems TRS-80 Serial I/O Board?

[Eric Smith via cctalk]

On Tue, Jun 13, 2017 at 6:59 PM, Chuck Guzis via cctalk <
cctalk@classiccmp.org> wrote:

> Well, I didn't say "timing error", I did say "timing distortion", which
> is not quite the same thing. My reference was the "TR1602/TR1863/TR1865
> MOS/LSI Application Notes Asynchronous Receiver Transmitter", which can
> be found in the WD 1984 Data Communications Handbook (I think there's a
> copy online). Page 126-127.  "Thus, signals with up to 46.875%
> distortion could be received."


They're referring to 46.875% of a bit time as the maximum error in the
sampling time of a single bit. That still corresponds to no more than 5%
error of the overall bit rate, which is where use of an RC oscillator runs
into trouble.


> Obviously, the developer of the subject board didn't have
> much of a problem either; or else he wouldn't be able to sell the thing.
>

They sold it, then spent a bunch of money on Field Service trips to make it
work for customers. It cost them enough to justify multiple redesigns,
including (finally) switching to a crystal.

I'd think that if an RC oscillator could have been (inexpensively) made to
work well enough at that time, DEC would have done it. Their hardware
people weren't complete idiots. (Usually.)

Eric

Re: Electronic Systems TRS-80 Serial I/O Board?

[Chuck Guzis via cctalk]

On 06/13/2017 05:29 PM, Eric Smith wrote:

> It's mathematically impossible for a normal UART [*] to handle 49% 
> timing error. The cumulative timebase error by the end of a
> character can't be more than one bit time, or the wrong bit will get
> sampled, resulting in incorrect data, or, (if that happens on the
> stop bit) a possible framing error. For 8N1 [**], there are 10 bits
> in total (including start and stop), so that's an absolute maximum
> timing error of 10%, but for various reasons even 10% speed variation
> won't actually work in practice. If they meant 4.9%, that is
> believable, but even that won't work if the other side is more than
> slightly off-speed in the other direction. Normal spec is a maximum
> timing variation of within +/-2% at each end [***], so that things
> still work properly if one side is at +2% and the other is at -2%,

Well, I didn't say "timing error", I did say "timing distortion", which
is not quite the same thing.  My reference was the "TR1602/TR1863/TR1865
MOS/LSI Application Notes Asynchronous Receiver Transmitter", which can
be found in the WD 1984 Data Communications Handbook (I think there's a
copy online). Page 126-127.  "Thus, signals with up to 46.875%
distortion could be received."  Perhaps this is in error; I'll let you
decide.

I can say, however, that once I set the trimmer on the 555, I didn't
touch it for a couple of years (eventually replacing the TVT with a real
terminal).  Obviously, the developer of the subject board didn't have
much of a problem either; or else he wouldn't be able to sell the thing.

--Chuck

Re: Electronic Systems TRS-80 Serial I/O Board?

[Paul Koning via cctalk]

> On Jun 13, 2017, at 8:29 PM, Eric Smith via cctalk  
> wrote:
> 
> ...
> * I refer to a "normal UART" as one that oversamples the receive data
> signal (typically at 16x the bit rate) to find the leading edge of the
> start bit, delays 1/2 bit time, then samples the start bit and subsequent
> data bits at one bit time intervals.  That is how nearly all UART chips
> work, since the very first ones.

From what I remember from the DEC documentation, the PDP-11 era UARTs took 7 
samples, which may mean they were 8x oversampled.

>  This analysis is disregarding various
> "auto-baud" techniques, which are not performed by normal UARTs, and
> certainly not by the TR1602 or AY-3-1013.

The auto-baud I know was done in software: set the UART to some convenient 
speed, expect the user to enter a particular character (carriage return was 
typical) and look for whatever a carriage return sent at speed x would produce 
as received data in a UART set to speed y.  In RSTS, we lifted an algorithm 
from some other OS (forgot which), which would work from 300 to 9600 baud 
(maybe even 110, I forgot), in two ranges.  So the UART would be set to the 
right test rate for range 1, check the received input, if it says "wrong 
range", switch to the rate for range 2 and await that character.

paul

Re: Electronic Systems TRS-80 Serial I/O Board?

[Eric Smith via cctalk]

On Tue, Jun 13, 2017 at 5:53 PM, Chuck Guzis via cctalk <
cctalk@classiccmp.org> wrote:

> The TR1602 UART, like its cousin, the AY-3-1013 used in the TVT,
> tolerates a pretty wide range of bit rate distortion.  The app note
> gives a figure of something like 49%.  And, since it's async, the game
> starts all over at the next character.
>

It's mathematically impossible for a normal UART [*] to handle 49% timing
error.  The cumulative timebase error by the end of a character can't be
more than one bit time, or the wrong bit will get sampled, resulting in
incorrect data, or, (if that happens on the stop bit) a possible framing
error.  For 8N1 [**], there are 10 bits in total (including start and
stop), so that's an absolute maximum timing error of 10%, but for various
reasons even 10% speed variation won't actually work in practice.  If they
meant 4.9%, that is believable, but even that won't work if the other side
is more than slightly off-speed in the other direction.  Normal spec is a
maximum timing variation of within +/-2% at each end [***], so that things
still work properly if one side is at +2% and the other is at -2%,


> Maybe DEC wasn't using the same sort of UART; I don't know.
>

I'm pretty sure it was a common UART.  DEC invented the electronic UART,
though it was originally two DEC System Modules, effectively a UAR and a
UAT.  They worked with Western Digital to have the first single-chip UART
developed, resulting in the TR1402A. Almost all other UARTs were designed
to be compatible with the TR1402A.

Eric


* I refer to a "normal UART" as one that oversamples the receive data
signal (typically at 16x the bit rate) to find the leading edge of the
start bit, delays 1/2 bit time, then samples the start bit and subsequent
data bits at one bit time intervals.  That is how nearly all UART chips
work, since the very first ones.  This analysis is disregarding various
"auto-baud" techniques, which are not performed by normal UARTs, and
certainly not by the TR1602 or AY-3-1013.

** Seven-level mechanical teleprinters, such as the Teletype Model 33, use
two stop bits, and may substitute parity for the 8th data bit, so they have
a total of 11 bits per character, and thus can actually tolerate slightly
less timing error than a UART configured for 8N1.

*** Various sources make different claims regarding allowable variation;
some claim only 1%, but in general 2% is workable. The ITU-T V.14 standard
for transmitting async data over synchronous modem modulation, as used in
all standard full-duplex modem protocols for 1200bps and over, specifies a
basic range of +1% to -2.5%, and an extended range of +2.3% to -2.5%.  They
specify the two ranges because the methods necessary to deal with the
extended range introduce issues that can negatively affect the operation of
some equipment. For instance, the NEC uPD7210, used in among other things
the AT 7300 & 3B1 "Unix PC", is unable to handle V.14 stop bit shaving.

Re: Electronic Systems TRS-80 Serial I/O Board?

[Chuck Guzis via cctalk]

On 06/13/2017 02:26 PM, Eric Smith wrote:
> On Tue, Jun 13, 2017 at 12:39 AM, Chuck Guzis via cctalk

> A person might think so, but as DEC found out with the PDP-11/05
> console serial port, it's really not. The percentage tolerance of
> async serial is not any higher at low bit rates than at higher bit
> rates, and the percentage tolerance of RC oscillators isn't any
> better at low frequencies than at higher frequencies.  Being off by
> only a few percent is enough to be a problem, because the other end
> might be off by a few percent also. 1% resistors are dirt cheap now,
> but they weren't in the 1970s.  It's become only slightly easier
> since then to get capacitors with 1% tolerance and low tempco.

That doesn't jibe with my own experience.   When I got my TV Typewriter
going, I was too cheap to buy the extra components for the serial board
to enable multiple bitrates.   Instead, I cobbled up a 555 operating in
astable mode with a simple trimmer pot for adjustment (not even the
10-turn units used in the example).  It was plenty stable.

The TR1602 UART, like its cousin, the AY-3-1013 used in the TVT,
tolerates a pretty wide range of bit rate distortion.  The app note
gives a figure of something like 49%.  And, since it's async, the game
starts all over at the next character.

Maybe DEC wasn't using the same sort of UART; I don't know.

--Chuck

Re: Electronic Systems TRS-80 Serial I/O Board?

[Brent Hilpert via cctalk]

On 2017-Jun-13, at 2:26 PM, Eric Smith via cctalk wrote:
> On Tue, Jun 13, 2017 at 12:39 AM, Chuck Guzis via cctalk <
> cctalk@classiccmp.org> wrote:
> 
>> The trimpot on the board says to me that the clock is most likely a
>> simple RC affair.
> 
> That does seem likely.

There's a 7493 (4-bit counter) on the board as well, which looks to have 
connections to the dip switches beside it,
in all likelihood the baud rate divider and rate selection, and so the clock 
would be running at higher frequency.

Simple board to RE if one had a need for it.



>>   For low bitrates, that's perfectly adequate.
> 
> A person might think so, but as DEC found out with the PDP-11/05 console
> serial port, it's really not. The percentage tolerance of async serial is
> not any higher at low bit rates than at higher bit rates, and the
> percentage tolerance of RC oscillators isn't any better at low frequencies
> than at higher frequencies.  Being off by only a few percent is enough to
> be a problem, because the other end might be off by a few percent also. 1%
> resistors are dirt cheap now, but they weren't in the 1970s.  It's become
> only slightly easier since then to get capacitors with 1% tolerance and low
> tempco.
> 
> DEC went through multiple board revisions with changes to the RC oscillator
> in attempt to make it sufficiently reliable. I've heard that they finally
> up and putting a crystal oscillator on the board, but all of mine have the
> RC, and they've given me some grief over the years. I replaced one with a
> crystal oscillator.



HP also used RC timing for serial on early versions of the HP2116 serial 
interfaces, and later went to crystal as the speeds went higher,
but then HP also had a habit of using high-quality componentry (e.g. 1% 
resistors when one could wonder why).
I expect the RC stuff was largely done in expectation of use with teletypes/33s.
Better was known obviously (crystals) but RC was not uncommon in the era.

Re: PDP-11/05 console clock (was Re: Electronic Systems TRS-80 Serial I/O Board?)

[william degnan via cctalk]

On Tue, Jun 13, 2017 at 5:45 PM, Ethan Dicks via cctalk <
cctalk@classiccmp.org> wrote:

> On Tue, Jun 13, 2017 at 5:26 PM, Eric Smith via cctalk
>  wrote:
> > DEC went through multiple board revisions with changes to the RC
> oscillator
> > in attempt to make it sufficiently reliable. I've heard that they finally
> > up and putting a crystal oscillator on the board, but all of mine have
> the
> > RC, and they've given me some grief over the years. I replaced one with a
> > crystal oscillator.
>
> I may be looking into that myself by this time next week.  There's a
> good chance there might be an 11/05 coming my way.
>
> -ethan
>

The console is great for teletype, but otherwise use a M7800 or equiv.
b

PDP-11/05 console clock (was Re: Electronic Systems TRS-80 Serial I/O Board?)

[Ethan Dicks via cctalk]

On Tue, Jun 13, 2017 at 5:26 PM, Eric Smith via cctalk
 wrote:
> DEC went through multiple board revisions with changes to the RC oscillator
> in attempt to make it sufficiently reliable. I've heard that they finally
> up and putting a crystal oscillator on the board, but all of mine have the
> RC, and they've given me some grief over the years. I replaced one with a
> crystal oscillator.

I may be looking into that myself by this time next week.  There's a
good chance there might be an 11/05 coming my way.

-ethan

Re: Electronic Systems TRS-80 Serial I/O Board?

[Eric Smith via cctalk]

On Tue, Jun 13, 2017 at 12:39 AM, Chuck Guzis via cctalk <
cctalk@classiccmp.org> wrote:

> The trimpot on the board says to me that the clock is most likely a
> simple RC affair.


That does seem likely.


>For low bitrates, that's perfectly adequate.
>

A person might think so, but as DEC found out with the PDP-11/05 console
serial port, it's really not. The percentage tolerance of async serial is
not any higher at low bit rates than at higher bit rates, and the
percentage tolerance of RC oscillators isn't any better at low frequencies
than at higher frequencies.  Being off by only a few percent is enough to
be a problem, because the other end might be off by a few percent also. 1%
resistors are dirt cheap now, but they weren't in the 1970s.  It's become
only slightly easier since then to get capacitors with 1% tolerance and low
tempco.

DEC went through multiple board revisions with changes to the RC oscillator
in attempt to make it sufficiently reliable. I've heard that they finally
up and putting a crystal oscillator on the board, but all of mine have the
RC, and they've given me some grief over the years. I replaced one with a
crystal oscillator.

Re: Old IBM Ref Manuals give away

[ben via cctalk]

On 6/13/2017 11:28 AM, Ethan Dicks via cctalk wrote:

On Mon, Jun 12, 2017 at 3:13 PM, Keven Miller(rtt) via cctalk
 wrote:

1.  IBM 2.10 DOS Technical Reference, Sep 1983
2.  IBM Hardware Technical Reference, Jan 1983

Hopefully the picture comes through.


No.  It did not.   Attachments are stripped on this list.  No pictures
come through.


if you want show how your naked mini , go else where I guess. :)


-ethan

Re: McLeyvier music synthesizer

[Al Kossow via cctalk]

On 6/13/17 11:22 AM, Alan Frisbie via cctalk wrote:

> 2. DTC 520-1 disk controller and its DTC-11 Q-Bus host adapter.

> 
> Our current project is to replace the ST-506 disks with
> the David Gesswein MFM disk emulators.   To do this, we
> need to determine the CRC algorithm used by DTC, which we
> cannot find any documentation for.


did you ask david to try decoding the data for you? he's been
very good at doing so.

DTC documentation should be on bitsavers

"What the DEC?!? Records of Minicomputer Giant Digital Equipment Corporation Open for Research at CHM"

[Lyle Bickley via cctalk]

The CHM has posted this on their blog:
I thought you all (especially DEC buffs) would appreciate this:

https://goo.gl/BV6MXH

I have personally reviewed several boxes of the DEC archives - and they
are a terrific asset in understanding both DEC's business successes
and failures, engineering prowess and bad decisions, etc.

"The Digital Equipment Corporation records are 1,239 linear feet of
material in 1,343 boxes. The records represent the largest and most
complete set of DEC records in existence, dating from 1947 through
2002, with the bulk from the company’s years of operation from 1957
through 1998, when they were bought by Compaq Computer. The collection
is a comprehensive technical history of every major computing
innovation at DEC, as well as its nontraditional business culture,
which still serves as an industry model — nearly every contemporary
company strives for a “culture of innovation.”

For a Guide to the DEC records (pdf) click the link below:

https://goo.gl/cWMK6F

Regards,
Lyle
-- 
73  AF6WS
Bickley Consulting West Inc.
http://bickleywest.com

"Black holes are where God is dividing by zero"

McLeyvier music synthesizer

[Alan Frisbie via cctalk]

In the early 1980's, a company in Toronto, Hazelcom Industries,
produced a music synthesizer based on an LSI-11/23 running
RSX-11M v3.2.   The music part of it was written by David McLey,
so the product was called the McLeyvier (pun intended).

Several people in the industry have told me that this was the
best analog music synthesizer ever made.   Sadly, it was
introduced just as digital synthesizers were hitting their stride.

Now, a small group of enthusiasts have banded together to restore
the few remaining McLeyviers (only about eight were sold) to
operating condition.

If you have any knowledge about the McLeyvier, and are not
already on our mailing list, PLEASE contact me.   We are
particularly interested in the following subjects:

1. McLeyvier hardware or software documentation.
2. DTC 520-1 disk controller and its DTC-11 Q-Bus host adapter.
3. Peritek VRG-Q Q-Bus graphics controller.  Especially the
   RSX or RT-11 device drivers, or other software.
4. The location or owners of McLeyviers.

Our current project is to replace the ST-506 disks with
the David Gesswein MFM disk emulators.   To do this, we
need to determine the CRC algorithm used by DTC, which we
cannot find any documentation for.

Thank you,
Alan Frisbie

Re: Old IBM Ref Manuals give away

[Ethan Dicks via cctalk]

On Mon, Jun 12, 2017 at 3:13 PM, Keven Miller(rtt) via cctalk
 wrote:
> 1.  IBM 2.10 DOS Technical Reference, Sep 1983
> 2.  IBM Hardware Technical Reference, Jan 1983
>
> Hopefully the picture comes through.

No.  It did not.   Attachments are stripped on this list.  No pictures
come through.

-ethan

Chuck Thacker

[Al Kossow via cctalk]

I had the privilege of doing Chuck's oral history for CHM a few years ago.


From: Christine Thacker [mailto:thac...@nhm.org]
Sent: Monday, June 12, 2017 6:58 PM

Subject: Chuck Thacker


Roy, Alan, Butler & Kurt,

   I'm sorry to tell you that my father Chuck Thacker passed away in the
early hours of this morning, after a short battle with cancer.  He died
peacefully and without pain at home with his wife of 52 years, Karen, and
daughters Kathy and myself all with him.  He was incredibly brave and stoic,
as I'm sure you can imagine, and refused all invasive medical treatment
following his diagnosis in March.  As per his wishes, there will be no
memorial or service.  Kurt, when we heard that Bob was gone my father was so
sad, and I was also so sorry to hear the news.  Working with Bob and all of
you was a source of incredible joy, excitement, and fulfillment for him -
the great animating thread that wound through his life.  We are sad he is
gone, but his life was such an epic adventure that mainly we're all just
glad we got to be a part of it.

  Please feel free to distribute this news widely.

Christine Thacker

Re: RC11 manuals / schematics online?

[Christian Corti via cctalk]

On Sun, 11 Jun 2017, Jay Jaeger wrote:

Yes, I am doing the drawings at 600DPI, including the drawings that
reside inside a couple of the maintenance manuals (but 400DPI for the
text, etc.)


Please do *everything* at 600dpi, disk space and file sizes for such 
documents don't matter these days, especially as it won't be a big 
difference between 400 and 600 dpi.


Christian

Re: Electronic Systems TRS-80 Serial I/O Board?

[Chuck Guzis via cctalk]

On 06/12/2017 10:23 PM, jim stephens via cctalk wrote:

> Things odd about the board.  No 1488 / 1489 or any other transmit / 
> receiver chips.  No clock circuit.  Was there an appropriate 
> frequency crystal or clock on the interface to divide to something 
> for the 1602 uart clock?
> 
> I see transistors randomly across the bottom and "EIA" in the etch, 
> maybe they got cheap on the RS232 / TTL.  The CD4069 cmos chips are 
> the only things other than the 10 turn pots I see that are other
> than TTL and the UART.
> 

There are a couple of transistors and a diode on the board.   Take a
look at the SIO board for, say, the Altair 8800.  Level translation done
with transistors.

The trimpot on the board says to me that the clock is most likely a
simple RC affair.   For low bitrates, that's perfectly adequate.

--Chuck