RE: Need to archive: GRiD Compass Computer Operating System Software

[Steve Hatle]

 Original Message 
Subject: Need to archive: GRiD Compass Computer Operating System
Software
From: Ian Finder 
Date: Tue, October 25, 2016 7:08 pm
To: "cctalk@classiccmp.org" 

Folks, there appears to be a large GRiD-sized hole where archived copies
of
the Compass Computer Operating System software should be.

...
-- 
 Ian Finder
 (206) 395-MIPS
 ian.fin...@gmail.com

>>

There's a fairly active GRiD list at

http://groups.yahoo.com/group/rugrid-laptop/

You may wish to cross-post there, or I can if you don't wish to join up.

Steve

Re: Reasonable price for a complete SOL-20 system?

[Terry Stewart]

>I bought the lovely SOL-20 system yesterday. Picture:

>https://twitter.com/nf6x/status/790631315695513600

Lovely.  I'm sure the sloping wood-(veener) sided case design of the Dick
Smith System 80 was inspired by the SOL.

http://www.classic-computers.org.nz/system-80/hardware_s80-mk1-front-800.jpg

Terry (Tez)

Re: DEC bus transceivers

[Guy Sotomayor Jr]

> On Oct 25, 2016, at 12:40 PM, allison  wrote:
> 
>> 
>> Also, I think in a previous email you mentioned that the UNIBUS is 240ohm.  
>> It’s not.
>> It’s 120ohm.
> My book says no. Qbus is for sure 120.
> 
OK, re-reading the first part of section 5.2.5, it’s pretty clear that the 
Unibus is 120-ohm:
A bus terminator is defined as a Unibus element or part of an element containing
a resistive network which connects to the end of a Unibus segment and matches
the 120-ohm characteristic impedance of the Unibus transmission path.

Given that it’s hard to see that the impedance of the Unibus is anything but 
120-ohms.

TTFN - Guy

Re: DEC bus transceivers

[Guy Sotomayor Jr]

> On Oct 25, 2016, at 12:40 PM, allison  wrote:
>> 
>> Also, I think in a previous email you mentioned that the UNIBUS is 240ohm.  
>> It’s not.
>> It’s 120ohm.
> My book says no. Qbus is for sure 120.
> 

Section 5.2.5 of the PDP-11 UNIBUS spec:
A Unibus segment must always have a Unibus terminator at each end of its
120-ohm transmission path.

So, I don’t know how you get a value of anything other than 120-ohms given that
statement.

TTFN - Guy

Re: PDP15 panel

[Pete Lancashire]

A litte Ebay shortcut

http://www.ebay.co.uk/itm/*itemnumber*  so for this guy ...

http://www.ebay.co.uk/itm/112179257620

On Tue, Oct 25, 2016 at 2:48 PM, Graham Toal  wrote:

> Friend of mine pointed this out to me, but I'm a software guy, don't have
> any use for hardware.  Maybe you guys would be interested.
>
> http://www.ebay.co.uk/itm/DEC-PDP-15-console-panel-von-1970-
> /112179257620?hash=item1a1e67a114:g:kDwAAOSwB09YDf2Q
>
> 8 days left.  I think he failed to sell it previously at 130 Euros so that
> probably sets an upper limit on the auction price.
>
> Graham
>
>

Re: DEC bus transceivers

[allison]

On 10/25/16 12:10 PM, Guy Sotomayor Jr wrote:

On Oct 25, 2016, at 8:38 AM, allison  wrote:

On 10/25/16 10:02 AM, Guy Sotomayor Jr wrote:

On Oct 24, 2016, at 11:35 PM, ben  wrote:

On 10/24/2016 2:18 PM, David Bridgham wrote:

On 10/24/2016 01:37 PM, allison wrote:


The voltages are based on TTL levels.  What are the unique voltages?

The QBUS spec from the 1979 Bus Handbook (the Unibus levels are the same):

Input low voltage (maximum): 1.3 V
Input high voltage (minimum): 1.7 V

And from the TI datasheet for the 74LS74:

Vil - low-level input voltage 0.8 V (maximum)
Vih - high-level input voltage 2 V (minimum)

So no, the DEC bus voltage levels are not TTL levels.  Yeah, TTL might
work on a smaller system but you can see that if you push it out to its
limits, TTL could start getting flaky.  That's the kind of bug I'm happy
to have DEC's engineers figure out and not have to track down myself.


But who has the big systems now days? The days of 4K core is long gone.
Use TTL and try to keep the systems small.

I just posted what one of my systems is (11/40).  It has 128KW of core which
takes 4 9-slot backplanes.  I have a fair amount of I/O on that system so I
have 2 BA11F chassis *full* of backplanes (each BA11F holds 5 9 slot 
backplanes).

My other large system is an 11/70 with a BA11K as an expansion box. The whole
point of Unibus was to allow for large configurations.

And I can guarantee you that TTL will *not* work in those systems.

Maybe if care is not taken.   Again there are TTL part and those designed for 
bus use.
Bad choice, bad results.   I've seen a few like that that broke even with DEC 
parts.

That’s why there’s the UNIBUS spec that DEC published.  In big systems, you must
follow the guidelines even with the proper transceivers.  Sometimes it requires 
that
things be split up and cable length added.

Also, I think in a previous email you mentioned that the UNIBUS is 240ohm.  
It’s not.
It’s 120ohm.

My book says no. Qbus is for sure 120.


Then again My 11/73 is BA11S and Ba11N both with 18 slot 4mb ram (two cards), 
DELQA,
two RQDX3 (one for RX floppies, second for RD disks), RLV21 (in box2), CMS scsi,
RXV21V-RX02, DZH11V and Parallel IO (ttl) in box 2 and Gigilo card (DEC sound
card for Qbus) in Box 1.   Likely a few IO I forgot.

OK, it’s still a small system by UNIBUS standards.  ;-)  I can’t check either 
my 11/40
or 11/70 but (from memory) the configs are:
11/40:
BA11F(1): CPU with all options (including FIS), 2 32KW core memory, additional 
backplanes to fill it up
BA11F(2): 2 32KW core memory, 1 RK11D (4 slot backplane), additional backplanes 
to fill it up
The “standard” Unibus devices as I recall are (there are more as most of the 
backplanes are full):
4 DL11s
DZ11
RL11
At least one tape drive interface of some sort
bootstrap/terminator
BC11A-15 to connect the two BA11Fs together.
11/70:
BA11F(1): CPU with all options, Hypercache (4MW option that looks like a 4MW 
cache to the CPU), 2 SMD controllers that plug into the slots for the massbus 
controllers (4 slots each).  2 Massbus controllers (4 slots each), 1 DL11
BA11K: RK11D 4 slot backplane, 2 RL11 controllers, TS11 controller, TU81 
controller, 2 DZ11s, 3 DL11s, 1 ethernet controller
There’s more on this system, I just don’t recall it all at the moment.  Again, 
this system is *full*.  I’m at the point where if I want to add more stuff I 
need to add another BA11K.
bootstrap/terminator
BC11A-15 to connect the BA11F to the BA11K

By all DEC standards its unsupported config.  Bus signals still look good.
Mine has many LS24x part and 7438s as there are more than a few IO cards 
that are non DEC (mine).
Example IO a PIO IDE interface test dog wire wrapped (usually the worst) 
alone with A/D and D/A.


By Qbus standards its a monster and it was rare to see more than two 
boxes and usually the cages were
not the 18 AB slot but the 9 slot ABCD configuration.  Runs unix well 
and usually that breaks machines
that are flakey.  Also Qbus uses 120 ohm termination so the drivers have 
to sink more current.


Never could fake the DEC interbox cables, those are well done to work right.

The BA123 uVax also has a few odd cards, doesn't seem to care. THose 
however were not fast

on the bus as they used PMI for Memory.

Another example is the 11/23 with all heathkit cards for memory, IO and 
a few unique homebrews.

I've never seen a bus level issue die to devices used.


I've seen my share of BIG VAXen with many unibus crates too.

Yes, and they all used the proper UNIBUS transceivers and not TTL parts.
mostly  A few of the systems were not production and engineering did 
play.


Bottom line is someday there will be no DEC parts and what then?  I 
reserve DEC parts
for repairing defunct boards for new and unique build it would be a 
waste of scarce
material.   The vector interrupt chip DC-series is one that is hard to 
fake without a

larger number of chips.

For preservation reasons its 

Re: Tek 40xx computer users

[Randy Dawson]

I sent Brad Srebink a email on this, lets see if I can get the simulator and 
his Tek Logo examples.



From: cctalk  on behalf of Pete Lancashire 

Sent: Monday, October 24, 2016 10:58 AM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: Tek 40xx computer users

Start with this

http://www.vcfed.org/forum/showthread.php?33684-Tek-4051-BASIC-Simulator
Tek 4051 BASIC Simulator - Vintage Computer 
Forum
www.vcfed.org
I'm working on a Tektronix 4051 BASIC and screen simulator that runs on 
Windows. It's not complete yet, but I can run some of the statements and 
perform some simple ...



Read the thread carefully, forget about the threads title/subject and you
will get close to all the information you need



On Mon, Oct 24, 2016 at 10:42 AM, Pete Lancashire 
wrote:

> The ROM cart your going to want to get never left Tek, it had the capacity
> to hold all the packs, another one is very high (for a 6800) performance
> graphics.
>
> To use multiple ROMs you will need a 4051 Toaster. That's what we called
> it. Can't remember if it was a product or not.
>
> I may have a couple original packs if I find them I'll extract the
> contents and put them on bitsavers
>
>
>
> On Mon, Oct 24, 2016 at 10:28 AM, Brad H  bettercomputing.net> wrote:
>
>> Can't see the video (access denied).. but that looked like an
>> exceptionally
>> nice unit, with the stand to boot!  Some day I'd like to have one of those
>> to go with my Tektronix 6800 board bucket.. but shipping will always be an
>> issue.
>>
>> If you decide to put a video up somewhere public please let me know.. love
>> watching vids of these ones in action.
>>
>> -Original Message-
>> From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Randy
>> Dawson
>> Sent: Sunday, October 23, 2016 7:15 PM
>> To: General Discussion: On-Topic and Off-Topic Posts <
>> cctalk@classiccmp.org>
>> Subject: Tek 40xx computer users
>>
>> I bought the Tek 4051 on ebay today; Jason brought it to my house and it
>> works perfectly, with about a half hour of programming instruction my 12
>> old
>> daughter was plotting a cat face.
>>
>>
>> https://www.facebook.com/Thelma.Franco/videos/10154277153852670/
>>
>>
>> I would like to get in touch with other users of this first personal
>> computer, and find additional resources.
>>
>>
>> Do you know where I can find an archive of BASIC programs for this?
>>
>>
>> Has anybody built plug in cards in the back, mine came with a realtime
>> clock
>> and a "file manager", I do not know what that one does.
>>
>>
>> I have some Tek scopes with IEE-488, and I will see if I can get the IEEE
>> interface working.
>>
>>
>> There was a DC300 tape in the machine:
>>
>>
>> biorithm
>>
>> craps
>>
>> blackjack
>>
>> artillery
>>
>> tanks
>>
>> weatherwar
>>
>>
>> The belt is broken in the tape, I have ordered some new DC300's and will
>> transplant the tape.
>>
>>
>> Any resources will be welcome!
>>
>>
>> Randy
>>
>>
>>
>>
>>
>>
>

Re: Tek 40xx computer users

[Randy Dawson]

Thanks Pete.


The 4051 is working perfectly so far, with a few examples I have typed in.


I started a conversation with VintageTek (Dave Brown and Ed Sinclair) to see 
what they have.


I looked at the 'Toaster' schematics here, it should be fairly easy for me to 
build this one up:


http://bitsavers.trailing-edge.com/pdf/tektronix/405x/


Interesting, the source firmware is in the fiche directory, I have had some fun 
reading it, the comments are a hoot.


Next on the list, I will get a Kraft joystick and build that up, its a simple 
op amp integrator circuit (the more you move the stick, the faster the voltages 
ramp to the 4051)


thanks for anything you have, its a fun machine.


Randy



From: cctalk  on behalf of Pete Lancashire 

Sent: Monday, October 24, 2016 10:42 AM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: Tek 40xx computer users

The ROM cart your going to want to get never left Tek, it had the capacity
to hold all the packs, another one is very high (for a 6800) performance
graphics.

To use multiple ROMs you will need a 4051 Toaster. That's what we called
it. Can't remember if it was a product or not.

I may have a couple original packs if I find them I'll extract the contents
and put them on bitsavers



On Mon, Oct 24, 2016 at 10:28 AM, Brad H <
vintagecompu...@bettercomputing.net> wrote:

> Can't see the video (access denied).. but that looked like an exceptionally
> nice unit, with the stand to boot!  Some day I'd like to have one of those
> to go with my Tektronix 6800 board bucket.. but shipping will always be an
> issue.
>
> If you decide to put a video up somewhere public please let me know.. love
> watching vids of these ones in action.
>
> -Original Message-
> From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of Randy
> Dawson
> Sent: Sunday, October 23, 2016 7:15 PM
> To: General Discussion: On-Topic and Off-Topic Posts <
> cctalk@classiccmp.org>
> Subject: Tek 40xx computer users
>
> I bought the Tek 4051 on ebay today; Jason brought it to my house and it
> works perfectly, with about a half hour of programming instruction my 12
> old
> daughter was plotting a cat face.
>
>
> https://www.facebook.com/Thelma.Franco/videos/10154277153852670/
>
>
> I would like to get in touch with other users of this first personal
> computer, and find additional resources.
>
>
> Do you know where I can find an archive of BASIC programs for this?
>
>
> Has anybody built plug in cards in the back, mine came with a realtime
> clock
> and a "file manager", I do not know what that one does.
>
>
> I have some Tek scopes with IEE-488, and I will see if I can get the IEEE
> interface working.
>
>
> There was a DC300 tape in the machine:
>
>
> biorithm
>
> craps
>
> blackjack
>
> artillery
>
> tanks
>
> weatherwar
>
>
> The belt is broken in the tape, I have ordered some new DC300's and will
> transplant the tape.
>
>
> Any resources will be welcome!
>
>
> Randy
>
>
>
>
>
>

Game master?

[Comcast]

Does anyone remember a subscription time sharing  system called, I think, "game 
master".

It was at least available and marketed in the chicago area...  possibly 
nationwide.

I just wonder if there is any info on what kind of system it ran on and any 
preserved info etc.

Thanks.
-Bob

Re: DEC bus transceivers

[Jon Elson]

On 10/25/2016 03:36 PM, Eric Smith wrote:

On Tue, Oct 25, 2016 at 2:09 PM, Paul Koning  wrote:


As for the receiver, it seems that a TI 75140 (adjustable threshold line
receiver) might do the job.


The high-level input current spec on that is max 100uA, which exceeds the
DEC specification.

One thing everyone seems to be ignoring is that the DEC leakage current
specifications are for Vcc from 0V to 5.25V. In other words, Unibus devices
can't load the bus more when they're not powered.  Almost all proposed
alternatives to the DEC-recommended chips do not meet that requirement.

I believe this is a holdover from the PDP-8 days.  I do not 
know of any PDP-11 system that would actually tolerate a 
Unibus peripheral being powered down in the middle of the 
bus.  I am pretty sure that due to the bus grant logic 
present on nearly every peripheral controller, that powering 
it down would jam the bus.
So, I suspect that for a PDP-11 or VAX Unibus system, this 
requirement does not really make much sense.


Jon

Electroluminescent Display aging - Was : Re: Flat panel display rot - "tunnel vision" in electroluminescent and other displays- bad seals.

[Ian Finder]

Update: I've swapped the displays and drivers around, and the "tunnel"
effect seems to be a property of the panel and not drive electronics.
Perhaps they are all high-hour examples?

Anyone here an electroluminescent display expert?

>
>
> On Wednesday, July 20, 2016, Ian Finder  wrote:
>
>> No, I'm not convinced the EL repro isn't a driver electronics issue.
>>
>> I'm just a little confused about why the issue congregates at the edges
>> of the displays. Any ideas why that might be?
>>
>> I may try swapping the panels around this evening if I am feeling brave.
>>
>> On Wednesday, July 20, 2016, Brent Hilpert  wrote:
>>
>>> On 2016-Jul-20, at 12:52 PM, Ian Finder wrote:
>>>
>>> > I have a few GRiD compass systems and some are suffering from massively
>>> > decreased contrast on the edges of the displays:
>>> >
>>> > [See the system on the left]
>>> > https://www.instagram.com/p/BIGGzUzgat-/?taken-by=tr1nitr0n
>>> >
>>> > [Or this one:]
>>> > http://www.ripstick.com/USCM/images/Grid_Compass_1101_
>>> Laptop_in_Box_002.jpg
>>> >
>>> > Meanwhile, other EL systems I have- like my HP integral PC- haven't
>>> > succumbed to this.
>>> >
>>> > I have seen similar issues on amLCD displays in my Tadpole, Toshiba and
>>> > other machines, so this is something we all may have to confront.
>>> >
>>> > ---
>>> >
>>> > I was wondering if the folks here had theories?
>>> >
>>> > I'm thinking moisture (or air) might be leaking in from the edges of
>>> the
>>> > glass panes, perhaps from a compromised seal- sorry for the silly
>>> picture
>>> > but you can see the composition of the display here:
>>> >
>>> > https://www.instagram.com/p/6BXaLBtSzd/?taken-by=tr1nitr0n
>>> >
>>> > Does anyone know how one might prevent this from progressing- storage
>>> tips?
>>> >
>>> > Could it be reversed?
>>> >
>>> > Better yet, does anyone have ideas on how to rapidly dehydrate the
>>> display?
>>> > Perhaps there is even a way to re-seal them.
>>> >
>>> > I think all two-glass-pane displays that don't have a vacuum may
>>> eventually
>>> > succumb to this.
>>> >
>>> > Perhaps it is just oxidation and not moisture, but I'd love to hear any
>>> > theories.
>>>
>>>
>>> Are you convinced this is a panel problem rather than a driver
>>> electronics problem?
>>>
>>> In one picture it looks like the sort of thing that happens when you
>>> have to turn up the brightness (for some types of display), resulting in
>>> partial illumination in other areas of the screen.
>>>
>>> I've never had opportunity to repair or work on EL flat-panel displays,
>>> I'm not familiar with the driving techniques and requirements, so this is
>>> just a query/guess. (I see it's an X/Y matrix drive scheme, but the
>>> voltages & timing & phasing I don't know about.)
>>>
>>>
>>
>> --
>>Ian Finder
>>(206) 395-MIPS
>>ian.fin...@gmail.com
>>
>>
>
> --
>Ian Finder
>(206) 395-MIPS
>ian.fin...@gmail.com
>
>


-- 
   Ian Finder
   (206) 395-MIPS
   ian.fin...@gmail.com

Re: PDP15 panel

[COURYHOUSE]

even  with shipping across the pond  a great  deal if   your system is 
missing one!
 
 
Ed#
 
 
In a message dated 10/25/2016 3:15:40 P.M. US Mountain Standard Time,  
lini...@lonesome.com writes:

If it  were on this side of the pond I'll be all over  that.

mcl

Need to archive: GRiD Compass Computer Operating System Software

[Ian Finder]

Folks, there appears to be a large GRiD-sized hole where archived copies of
the Compass Computer Operating System software should be.

For those not aware, GRiD had an OS product that was quite advanced for the
time- with bitmapped graphics, multitasking, a beautiful forms-driven, UI,
etc.

Unfortunately, nothing but the basic OS seems to be preserved anywhere- no
add-on software, not even the utilities needed to format the hard drive.

This is a travesty- GRiD made something far more important than PC clone
machines, at one time.

*** I'm looking for leads on any software products mentioned below, or at
this URL:
http://www.1000bit.it/ad/bro/grid/GRID-1984-PriceList.pdf ***

I have been buying manuals for the express purpose of scanning, and have a
great deal of coverage, but am short on software.

I am not opposed to paying for any of this, nor shipping and returning the
original copies to the provider at my own expense.

I will certainly put all the images in Bitsavers, if Al is okay with that-
otherwise they will be made available through some other means.

Any leads on GRiD media is appreciated.

Thanks,

- Ian

GRiDWrite, Management Tools, GRiDVT100, and GRiDbasic have already been
preserved.

[35], [36] and [37-47] would be incredible to find.

REF PRODUCT   MODEL VERSION  NOTES
--- - - ---  -
 18 GRiD-OS 110X/112X 29200 3.1.0.A   [6]
 19 GRiD-OS 113X  29210 3.1.5.D
 20 GRiD-OS 110X/112X 29200 3.1.0.A

 21 Management Tools  21100 3.1.0
 22 GRiDMaster21231 3.1.7
 23 GRiDPaint 21214 3.1.5
 24 GRiDWrite 21132 3.1.7
 25 GRiDAccess21212 3.1.7
 26 GRiDPlan3.1.5
 27 GRiDPlan II 3.2.1
 28 GRiDWrite 21132 3.1.7

 29 GRiDVT100/Reformat21191 3.2
 30 GRiDVT100/Reformat21191 3.1.5
 31 GRiD3101/Reformat 21151   [7]
 32 GRiD3101/Reformat 21151 3.1.5 [7]
 33 GRiDTek4016   21228 36.9.4[7]
 34 GRiDTerm/Reformat 21141 3.1.5

 35 GRiDTransfer/Partition21210
 36 GRiDRecord/Playback 3.1.5

 37 C-86  23032 3.2.0
 38 Pascal-86 23025 0.3.1 [1 COPY SOLD]
 39 FORTRAN-8623015 0.3.0
 40 PL/M-86   23030 0.2.7
 41 BASIC   3.1.0 [7], [1 COPY SOLD]
 42 ASM-8623031
 43 GRiDDebug/Devel. Tools29300 3.1.7
 44 GRiDDebug/Devel. Tools29300 3.0.0
 45 GRiDTask II / Windows 21230 3.2
 46 GRiDTask II   21230 3.1.7
 47 GRiDTask  21230 3.1.7
 48 ROM Builder 2.1.0 [7]

 49 ROM: GRiD-OS System 112X  24100 3.1.0 [8]
 50 ROM: GRiD-OS System 113X  24180 3.1.5 [8]
 51 ROM: GRiD-OS Utilities21400 3.1.0 [8]
 52 ROM: GRiDMaster 3.1.7 [8]
 53 ROM: GRiDVT100/Reformat   24150 3.2   [8]
 54 ROM: GRiDWrite/Term/Refmt 24140 3.1.5 [8]

-- 
   Ian Finder
   (206) 395-MIPS
   ian.fin...@gmail.com

Re: DEC bus transceivers

[Paul Koning]

> On Oct 25, 2016, at 4:36 PM, Eric Smith  wrote:
> 
> On Tue, Oct 25, 2016 at 2:09 PM, Paul Koning  wrote:
> 
>> As for the receiver, it seems that a TI 75140 (adjustable threshold line
>> receiver) might do the job.
>> 
> 
> The high-level input current spec on that is max 100uA, which exceeds the
> DEC specification.

True.

I guess a better option might be a voltage comparitor with FET input.  The 
LT1011 would be an example except that it isn't quite fast enough.  Or a 
voltage follower before the 75140, at the expense of higher part count.

> One thing everyone seems to be ignoring is that the DEC leakage current
> specifications are for Vcc from 0V to 5.25V. In other words, Unibus devices
> can't load the bus more when they're not powered.  Almost all proposed
> alternatives to the DEC-recommended chips do not meet that requirement.

I don't see any such requirement in the spec.  And it would be odd to have one; 
I can't think of anyone who would expect a PDP11 to work with part of its 
devices powered down.  For one thing, if the box with the terminator loses 
power, you don't just have unpowered I/O cards, you have  no power on the 
terminator.

paul

Re: PDP15 panel

[Al Kossow]

apparently because no one knew about it

On 10/25/16 2:48 PM, Graham Toal wrote:
> I think he failed to sell it previously at 130 Euros

Re: PDP15 panel

[Mark Linimon]

If it were on this side of the pond I'll be all over that.

mcl

PDP15 panel

[Graham Toal]

Friend of mine pointed this out to me, but I'm a software guy, don't have
any use for hardware.  Maybe you guys would be interested.

http://www.ebay.co.uk/itm/DEC-PDP-15-console-panel-von-1970-/112179257620?hash=item1a1e67a114:g:kDwAAOSwB09YDf2Q

8 days left.  I think he failed to sell it previously at 130 Euros so that
probably sets an upper limit on the auction price.

Graham

Re: Blue top DEC cabinet -- cheap

[Jason Howe]

This item has been claimed.

--Jason

On October 25, 2016 2:04:49 PM PDT, Jason Howe  wrote:
>Sorry, This is in Seattle, WA.
>
>--Jason
>
>On Tue, 25 Oct 2016, Jason Howe wrote:
>
>> Hey All,
>>
>> Surplus at work has this right now:
>>
>> http://archives.smbfc.net/uploads/retrocomputing/deccab/
>>
>> I'm happy to go pay for it and hold it if someone is interested and
>able to 
>> pick it up quickly.
>>
>> --Jason
>>

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Re: assembler, disassembler for Intel 8089?

[Eric Smith]

I wrote:

> Wrote my own disassembler in Python. No assembler yet.
>

Now there's an assembler as well.

> https://github.com/brouhaha/i89
>

Re: Gould 32/77 (was: NWA auctions)

[Al Kossow]

There are some new scans up now for 32/75 on bitsavers.org/pdf/sel and some 
software
under bits/SEL

I'll be working on MPX documentation next


On 10/14/16 7:29 PM, Tony Aiuto wrote:

> Bob: I may have a lot of software for it, if I can find the tapes and they
> are still readable. I even got hold of their secret C compiler port.
> 

Re: Blue top DEC cabinet -- cheap

[Jason Howe]

Sorry, This is in Seattle, WA.

--Jason

On Tue, 25 Oct 2016, Jason Howe wrote:


Hey All,

Surplus at work has this right now:

http://archives.smbfc.net/uploads/retrocomputing/deccab/

I'm happy to go pay for it and hold it if someone is interested and able to 
pick it up quickly.


--Jason

Blue top DEC cabinet -- cheap

[Jason Howe]

Hey All,

Surplus at work has this right now:

http://archives.smbfc.net/uploads/retrocomputing/deccab/

I'm happy to go pay for it and hold it if someone is interested and able 
to pick it up quickly.


--Jason

Re: DEC bus transceivers

[Guy Sotomayor Jr]

> On Oct 25, 2016, at 1:35 PM, ben  wrote:
> 
>> 
>> If you want to build boards that will work in a small subset of systems 
>> that’s
>> find…but don’t advertise it as Unibus compatible.  I test the boards I 
>> produce
>> in all of my systems (11/20, 11/34, 11/40 and 11/70) and they all use DEC bus
>> interface chips.
> 
> Where do you get your stock?
> 
Secondary chip marked (only reputable vendors).  I currently have ~2500 8641
and several 100’s of the other variants.  Assuming 100% good parts, I have
enough stock to build at least 100 unibus boards (total) of various types that I
have planned.

And to forestall any questions on the topic, no I will not be selling any of the
chips individually.  They are there to allow me to build/sell the various Unibus
boards.

TTFN - Guy

Re: DEC bus transceivers

[Paul Koning]

> On Oct 25, 2016, at 4:31 PM, Guy Sotomayor Jr  wrote:
> 
> 
>> On Oct 25, 2016, at 1:09 PM, Paul Koning  wrote:
>> 
>> 
>>> On Oct 24, 2016, at 4:48 PM, Guy Sotomayor Jr  wrote:
>>> 
>>> 
 ...
 Where do you see the 25 ns spec?  I didn't see it (admittedly in a quick 
 scan).
>>> 
>>> 5.2.7.  It’s discussing the AC loading as a percentage of the risetime 
>>> (25ns) to allow for the
>>> reflections.
>> 
>> That seems more like a "for illustration" than an actual specification. 
> 
> Maybe, but when you read section 5.2.7 of the PDP-11 Unibus specification:
> Nine lumped ac loads reflect 20 precent, and 20 lumped ac loads reflect 40 
> percent of
> a 25 ns risetime step.

That's my point.  It says "a 25 ns risetime step".  Not "THE 25 ns risetime 
step".  Nor "at the minimum 25 ns risetime step".  So it seems to be 
illustrative: if in your particular config the risetime happens to be that, the 
example holds.

The obvious question to ask is what the bus capacitance is, between the module 
contributions, and the distributed capacitance of the cable.  That  would 
explain (in part) the risetime.  The other part would be the inherent risetime 
of the TTL components of the era, which are somewhere in that range judging by 
some of the old datasheets I've just been looking at.

paul

Re: DEC bus transceivers

[Eric Smith]

On Tue, Oct 25, 2016 at 2:09 PM, Paul Koning  wrote:

> As for the receiver, it seems that a TI 75140 (adjustable threshold line
> receiver) might do the job.
>

The high-level input current spec on that is max 100uA, which exceeds the
DEC specification.

One thing everyone seems to be ignoring is that the DEC leakage current
specifications are for Vcc from 0V to 5.25V. In other words, Unibus devices
can't load the bus more when they're not powered.  Almost all proposed
alternatives to the DEC-recommended chips do not meet that requirement.

Re: DEC bus transceivers

[ben]

On 10/25/2016 8:02 AM, Guy Sotomayor Jr wrote:



On Oct 24, 2016, at 11:35 PM, ben  wrote:

On 10/24/2016 2:18 PM, David Bridgham wrote:

On 10/24/2016 01:37 PM, allison wrote:


The voltages are based on TTL levels.  What are the unique voltages?


The QBUS spec from the 1979 Bus Handbook (the Unibus levels are the same):

Input low voltage (maximum): 1.3 V
Input high voltage (minimum): 1.7 V

And from the TI datasheet for the 74LS74:

Vil - low-level input voltage 0.8 V (maximum)
Vih - high-level input voltage 2 V (minimum)

So no, the DEC bus voltage levels are not TTL levels.  Yeah, TTL might
work on a smaller system but you can see that if you push it out to its
limits, TTL could start getting flaky.  That's the kind of bug I'm happy
to have DEC's engineers figure out and not have to track down myself.


But who has the big systems now days? The days of 4K core is long gone.
Use TTL and try to keep the systems small.


I just posted what one of my systems is (11/40).  It has 128KW of core which
takes 4 9-slot backplanes.  I have a fair amount of I/O on that system so I
have 2 BA11F chassis *full* of backplanes (each BA11F holds 5 9 slot 
backplanes).

My other large system is an 11/70 with a BA11K as an expansion box. The whole
point of Unibus was to allow for large configurations.

And I can guarantee you that TTL will *not* work in those systems.

If you want to build boards that will work in a small subset of systems that’s
find…but don’t advertise it as Unibus compatible.  I test the boards I produce
in all of my systems (11/20, 11/34, 11/40 and 11/70) and they all use DEC bus
interface chips.


Where do you get your stock?


TTFN - Guy


Ben.

Re: DEC bus transceivers

[Guy Sotomayor Jr]

> On Oct 25, 2016, at 1:09 PM, Paul Koning  wrote:
> 
> 
>> On Oct 24, 2016, at 4:48 PM, Guy Sotomayor Jr  wrote:
>> 
>> 
>>> ...
>>> Where do you see the 25 ns spec?  I didn't see it (admittedly in a quick 
>>> scan).
>> 
>> 5.2.7.  It’s discussing the AC loading as a percentage of the risetime 
>> (25ns) to allow for the
>> reflections.
> 
> That seems more like a "for illustration" than an actual specification. 

Maybe, but when you read section 5.2.7 of the PDP-11 Unibus specification:
Nine lumped ac loads reflect 20 precent, and 20 lumped ac loads reflect 40 
percent of
a 25 ns risetime step.
> 
>> Yes, all I’m saying is that folks have been looking at OMNIBUS and QBUS and 
>> those are
>> much simpler electrical environments than UNIBUS.  You really need to pay 
>> attention to
>> the fact that UNIBUS is really a set of transmission lines so in addition to 
>> critical levels
>> and currents you need to worry about the transmission line effects (ie the 
>> AC components).
> 
> Sure.  But whether you look at it as a transmission line or not, in the final 
> analysis there should be a small set of receiver and driver specs that 
> matter.  In theory, they should be the ones listed in the DEC documents, 
> neither more nor less.  In practice, there might be unspecified ones, such as 
> max slew rate.  If so, that's easy enough to handle by introducing a suitable 
> RC at the driver base (or gate).
> 
> As for the receiver, it seems that a TI 75140 (adjustable threshold line 
> receiver) might do the job.

My concern (and I get that the supply of DEC transceivers is limited) is that 
someone will build some thing and says it works in Unibus machines and they’ve 
only tested it in a relatively small system (one BA11K box for example) and it 
will fail miserably (or worse only fail intermittently) in larger systems.

TTFN - Guy

Re: DEC bus transceivers

[Paul Koning]

> On Oct 24, 2016, at 4:48 PM, Guy Sotomayor Jr  wrote:
> 
> 
>> ...
>> Where do you see the 25 ns spec?  I didn't see it (admittedly in a quick 
>> scan).
> 
> 5.2.7.  It’s discussing the AC loading as a percentage of the risetime (25ns) 
> to allow for the
> reflections.

That seems more like a "for illustration" than an actual specification. 

> Yes, all I’m saying is that folks have been looking at OMNIBUS and QBUS and 
> those are
> much simpler electrical environments than UNIBUS.  You really need to pay 
> attention to
> the fact that UNIBUS is really a set of transmission lines so in addition to 
> critical levels
> and currents you need to worry about the transmission line effects (ie the AC 
> components).

Sure.  But whether you look at it as a transmission line or not, in the final 
analysis there should be a small set of receiver and driver specs that matter.  
In theory, they should be the ones listed in the DEC documents, neither more 
nor less.  In practice, there might be unspecified ones, such as max slew rate. 
 If so, that's easy enough to handle by introducing a suitable RC at the driver 
base (or gate).

As for the receiver, it seems that a TI 75140 (adjustable threshold line 
receiver) might do the job.

paul

Re: DEC bus transceivers

[allison]

On 10/25/16 10:02 AM, Guy Sotomayor Jr wrote:

On Oct 24, 2016, at 11:35 PM, ben  wrote:

On 10/24/2016 2:18 PM, David Bridgham wrote:

On 10/24/2016 01:37 PM, allison wrote:


The voltages are based on TTL levels.  What are the unique voltages?

The QBUS spec from the 1979 Bus Handbook (the Unibus levels are the same):

Input low voltage (maximum): 1.3 V
Input high voltage (minimum): 1.7 V

And from the TI datasheet for the 74LS74:

Vil - low-level input voltage 0.8 V (maximum)
Vih - high-level input voltage 2 V (minimum)

So no, the DEC bus voltage levels are not TTL levels.  Yeah, TTL might
work on a smaller system but you can see that if you push it out to its
limits, TTL could start getting flaky.  That's the kind of bug I'm happy
to have DEC's engineers figure out and not have to track down myself.


But who has the big systems now days? The days of 4K core is long gone.
Use TTL and try to keep the systems small.

I just posted what one of my systems is (11/40).  It has 128KW of core which
takes 4 9-slot backplanes.  I have a fair amount of I/O on that system so I
have 2 BA11F chassis *full* of backplanes (each BA11F holds 5 9 slot 
backplanes).

My other large system is an 11/70 with a BA11K as an expansion box. The whole
point of Unibus was to allow for large configurations.

And I can guarantee you that TTL will *not* work in those systems.


Maybe if care is not taken.   Again there are TTL part and those 
designed for bus use.
Bad choice, bad results.   I've seen a few like that that broke even 
with DEC parts.


Then again My 11/73 is BA11S and Ba11N both with 18 slot 4mb ram (two 
cards), DELQA,
two RQDX3 (one for RX floppies, second for RD disks), RLV21 (in box2), 
CMS scsi,
 RXV21V-RX02, DZH11V and Parallel IO (ttl) in box 2 and Gigilo card 
(DEC sound

card for Qbus) in Box 1.   Likely a few IO I forgot.

By all DEC standards its unsupported config.  Bus signals still look good.

I've seen my share of BIG VAXen with many unibus crates too.

Allison
old millrat


If you want to build boards that will work in a small subset of systems that’s
find…but don’t advertise it as Unibus compatible.  I test the boards I produce
in all of my systems (11/20, 11/34, 11/40 and 11/70) and they all use DEC bus
interface chips.

TTFN - Guy

Re: [TUHS] VTServer/etc for V6 Unix

[Clem Cole]

On Tue, Oct 25, 2016 at 10:16 AM, Noel Chiappa 
wrote:

> Is there any interest in all this? If so, I can put together a web page
> with
> the V6-verion VTServer source, along with the modified V6 serial line stuff
> (including a short description of the extended stty/gtty interface), etc.
>
​Yes please​




>
> So I guess my next step, if I don't hear shortly from someone who has
> previously used VTServer to install V6, is to start on actually getting
> a V6 file system created.
>
​I think there are rk05 images in bit savers, check out uv6swre​


>
> I'm still vacillating over whether it would be better to go V6-style (and
> just transfer a complete, small existing V6 filesystem),
>
​The issue is even at 9600 baud, you do need to download 2.4Mbytes which
will take​ a few minutes.  So you would need to create a very small root FS
and then you get into how much is enough.




> or V7-style (and
> get stand-alone 'mkfs', etc running with V6-format file systems). Anyone
> have an opinion?
>
​Basically it depends how many commands you need.   Clearly, you need to
V6-afy the V7 standalone system and then for each app you need, you have to
both v6-afy and add the #ifdef STANDALONE hacks.   Clearly you need mkfs,
and probably need a one or more other programs in the key of restor, tar,
tp, dd or the like to copy things.
That's going to be a bit a work - although once you have done it, it will
be handy I suspect.

Clem​

Re: DEC bus transceivers

[Guy Sotomayor Jr]

> On Oct 25, 2016, at 8:38 AM, allison  wrote:
> 
> On 10/25/16 10:02 AM, Guy Sotomayor Jr wrote:
>>> On Oct 24, 2016, at 11:35 PM, ben  wrote:
>>> 
>>> On 10/24/2016 2:18 PM, David Bridgham wrote:
 On 10/24/2016 01:37 PM, allison wrote:
 
> The voltages are based on TTL levels.  What are the unique voltages?
 The QBUS spec from the 1979 Bus Handbook (the Unibus levels are the same):
 
 Input low voltage (maximum): 1.3 V
 Input high voltage (minimum): 1.7 V
 
 And from the TI datasheet for the 74LS74:
 
 Vil - low-level input voltage 0.8 V (maximum)
 Vih - high-level input voltage 2 V (minimum)
 
 So no, the DEC bus voltage levels are not TTL levels.  Yeah, TTL might
 work on a smaller system but you can see that if you push it out to its
 limits, TTL could start getting flaky.  That's the kind of bug I'm happy
 to have DEC's engineers figure out and not have to track down myself.
 
>>> But who has the big systems now days? The days of 4K core is long gone.
>>> Use TTL and try to keep the systems small.
>> I just posted what one of my systems is (11/40).  It has 128KW of core which
>> takes 4 9-slot backplanes.  I have a fair amount of I/O on that system so I
>> have 2 BA11F chassis *full* of backplanes (each BA11F holds 5 9 slot 
>> backplanes).
>> 
>> My other large system is an 11/70 with a BA11K as an expansion box. The whole
>> point of Unibus was to allow for large configurations.
>> 
>> And I can guarantee you that TTL will *not* work in those systems.
> 
> Maybe if care is not taken.   Again there are TTL part and those designed for 
> bus use.
> Bad choice, bad results.   I've seen a few like that that broke even with DEC 
> parts.

That’s why there’s the UNIBUS spec that DEC published.  In big systems, you must
follow the guidelines even with the proper transceivers.  Sometimes it requires 
that
things be split up and cable length added.

Also, I think in a previous email you mentioned that the UNIBUS is 240ohm.  
It’s not.
It’s 120ohm.

> 
> Then again My 11/73 is BA11S and Ba11N both with 18 slot 4mb ram (two cards), 
> DELQA,
> two RQDX3 (one for RX floppies, second for RD disks), RLV21 (in box2), CMS 
> scsi,
> RXV21V-RX02, DZH11V and Parallel IO (ttl) in box 2 and Gigilo card (DEC sound
> card for Qbus) in Box 1.   Likely a few IO I forgot.

OK, it’s still a small system by UNIBUS standards.  ;-)  I can’t check either 
my 11/40
or 11/70 but (from memory) the configs are:
11/40:
BA11F(1): CPU with all options (including FIS), 2 32KW core memory, additional 
backplanes to fill it up
BA11F(2): 2 32KW core memory, 1 RK11D (4 slot backplane), additional backplanes 
to fill it up
The “standard” Unibus devices as I recall are (there are more as most of the 
backplanes are full):
4 DL11s
DZ11
RL11
At least one tape drive interface of some sort
bootstrap/terminator
BC11A-15 to connect the two BA11Fs together.
11/70:
BA11F(1): CPU with all options, Hypercache (4MW option that looks like a 4MW 
cache to the CPU), 2 SMD controllers that plug into the slots for the massbus 
controllers (4 slots each).  2 Massbus controllers (4 slots each), 1 DL11
BA11K: RK11D 4 slot backplane, 2 RL11 controllers, TS11 controller, TU81 
controller, 2 DZ11s, 3 DL11s, 1 ethernet controller
There’s more on this system, I just don’t recall it all at the moment.  Again, 
this system is *full*.  I’m at the point where if I want to add more stuff I 
need to add another BA11K.
bootstrap/terminator
BC11A-15 to connect the BA11F to the BA11K
> 
> By all DEC standards its unsupported config.  Bus signals still look good.
> 
> I've seen my share of BIG VAXen with many unibus crates too.

Yes, and they all used the proper UNIBUS transceivers and not TTL parts.

TTFN - Guy

Re: DEC bus transceivers

[Ethan Dicks]

On Tue, Oct 25, 2016 at 2:35 AM, ben  wrote:
> But who has the big systems now days?

Me.

> The days of 4K core is long gone.

I have Unibus machines that were 8 or more "system units" (DD11CK
equivalents), and a PDP-11/20 that takes up 3 BA-11 boxes.  60% of it
is 4K core stacks, BTW, just like the day it was made in 1972.  It
only has a handful of peripherals (console, RK11, LP11...)

> Use TTL and try to keep the systems small.

That's great if one is cobbling together a new system, but it doesn't
help when one is trying to breathe life into an existing system by
adding a modern peripheral because ancient disks are no longer
reasonably available.

-ethan

Re: VTServer/etc for V6 Unix

[Toby Thain]

On 2016-10-25 10:16 AM, Noel Chiappa wrote:

> I'll start with getting VTServer to run under V6 (my only Unix, don't
> have anything later :-)

So, I just got VTServer runnin under V6: ...
Is there any interest in all this? If so, I can put together a web page with
the V6-verion VTServer source, along with the modified V6 serial line stuff
(including a short description of the extended stty/gtty interface), etc.


IMHO it's worth putting on github with a README, yes.

--Toby


...

Noel

Re: Reasonable price for a complete SOL-20 system?

[Mark J. Blair]

I bought the lovely SOL-20 system yesterday. Picture:

https://twitter.com/nf6x/status/790631315695513600

It will probably be a week or three before I work with it in detail, because 
right now I'm nominally working on my absurd Retrochallenge 2016/10 project of 
making a USB interface for an RL02 drive.

Now I'm on the lookout for a small, monochrome, composite monitor of late 1970s 
vintage to set on top of it. I have other monitors which will be functionally 
just fine, but which won't look Just Right sitting on top of the SOL-20. I'll 
probably do initial work with my little Apple IIc monitor, just because it's 
small and easy to carry.

This system came with an 80x25 video card, but I plan to initially use it in 
its original 64x16 glory. I'll either upgrade to 80x25 later in the natural 
progression of getting to know the new system, or use it in the other S-100 
chassis that I am building up.

I don't know about the system's operational status yet. I'm going in to the 
project assuming that the capacitive keyboard is dead, the electrolytic caps 
are dried up, the drive heads are filthy, and the bearings are gummed up. Maybe 
the condition is a lot better than that, but those seem like reasonable 
assumptions for a computer of its age that hasn't been used recently.


-- 
Mark J. Blair, NF6X 
http://www.nf6x.net/

Re: VTServer/etc for V6 Unix

[Noel Chiappa]

> I'll start with getting VTServer to run under V6 (my only Unix, don't
> have anything later :-)

So, I just got VTServer runnin under V6: it successfully loaded a memory
diagnostic from the 'server', into the 'client', using 'vtboot' on the
latter. (Both running on emulated machines, for the moment - I thought I'd
take all the hardware-related variables out of the equation, until I have the
software all running OK.)

It didn't require as much work on VTServer as I thought it might: I had to
convert the C to the V6 dialect (no '+=', etc), and some other small things
(e.g. convert the TTY setup code), but in general, it was pretty smooth and
painless.


Note that it won't run under vanilla V6, which does not provide 8-bit input
and output on serial lines. I had previously added 'LITIN' and 'LITOUT' modes
(8-bit input and output) to my V6; since the mode word in stty/gtty was
already full, I had to extend the device interface to support them. I didn't
add ioctl() or anything later, I did an upward-compatible extension to
stty/gtty. (I'm a real NIH guy. :-)

My only real problem in getting VTServer running was with LITIN; I did it
some while back, but had never actually tested it (I was only using LITOUT,
for my custom program to talk to PDP-11 consoles, which also did downloads,
so needed 8-bit output). So when I went to use it, it didn't work, and it was
a real stumper! But I did eventually figure out what the problem was (after
writing a custom program to reach into the kernel and dump the entire state
of a serial line), and get it working.

(I had taken the shortcut of not fully understanding how the kernel serial
line code worked, just tried to install point fixes. This turned out not to
work, because of a side-effect elsewhere in the code. Moral of the story: you
can't change the operation of a piece of software without complete
understanding of how it works...)


Is there any interest in all this? If so, I can put together a web page with
the V6-verion VTServer source, along with the modified V6 serial line stuff
(including a short description of the extended stty/gtty interface), etc.


> so if you turn up whatever you used to boot V6, it would probably still
> be useful.

So I guess my next step, if I don't hear shortly from someone who has
previously used VTServer to install V6, is to start on actually getting
a V6 file system created.

I'm still vacillating over whether it would be better to go V6-style (and
just transfer a complete, small existing V6 filesystem), or V7-style (and
get stand-alone 'mkfs', etc running with V6-format file systems). Anyone
have an opinion?

Noel

Re: DEC bus transceivers

[Guy Sotomayor Jr]

> On Oct 24, 2016, at 11:35 PM, ben  wrote:
> 
> On 10/24/2016 2:18 PM, David Bridgham wrote:
>> On 10/24/2016 01:37 PM, allison wrote:
>> 
>>> The voltages are based on TTL levels.  What are the unique voltages?
>> 
>> The QBUS spec from the 1979 Bus Handbook (the Unibus levels are the same):
>> 
>> Input low voltage (maximum): 1.3 V
>> Input high voltage (minimum): 1.7 V
>> 
>> And from the TI datasheet for the 74LS74:
>> 
>> Vil - low-level input voltage 0.8 V (maximum)
>> Vih - high-level input voltage 2 V (minimum)
>> 
>> So no, the DEC bus voltage levels are not TTL levels.  Yeah, TTL might
>> work on a smaller system but you can see that if you push it out to its
>> limits, TTL could start getting flaky.  That's the kind of bug I'm happy
>> to have DEC's engineers figure out and not have to track down myself.
>> 
> But who has the big systems now days? The days of 4K core is long gone.
> Use TTL and try to keep the systems small.

I just posted what one of my systems is (11/40).  It has 128KW of core which
takes 4 9-slot backplanes.  I have a fair amount of I/O on that system so I
have 2 BA11F chassis *full* of backplanes (each BA11F holds 5 9 slot 
backplanes).

My other large system is an 11/70 with a BA11K as an expansion box. The whole
point of Unibus was to allow for large configurations.

And I can guarantee you that TTL will *not* work in those systems.

If you want to build boards that will work in a small subset of systems that’s
find…but don’t advertise it as Unibus compatible.  I test the boards I produce
in all of my systems (11/20, 11/34, 11/40 and 11/70) and they all use DEC bus
interface chips.

TTFN - Guy

Re: DEC bus transceivers

[ben]

On 10/24/2016 2:18 PM, David Bridgham wrote:

On 10/24/2016 01:37 PM, allison wrote:


The voltages are based on TTL levels.  What are the unique voltages?


The QBUS spec from the 1979 Bus Handbook (the Unibus levels are the same):

Input low voltage (maximum): 1.3 V
Input high voltage (minimum): 1.7 V

And from the TI datasheet for the 74LS74:

Vil - low-level input voltage 0.8 V (maximum)
Vih - high-level input voltage 2 V (minimum)

So no, the DEC bus voltage levels are not TTL levels.  Yeah, TTL might
work on a smaller system but you can see that if you push it out to its
limits, TTL could start getting flaky.  That's the kind of bug I'm happy
to have DEC's engineers figure out and not have to track down myself.


But who has the big systems now days? The days of 4K core is long gone.
Use TTL and try to keep the systems small.
Ben.

Re: DEC bus transceivers

[allison]

On 10/25/2016 02:35 AM, ben wrote:
> On 10/24/2016 2:18 PM, David Bridgham wrote:
>> On 10/24/2016 01:37 PM, allison wrote:
>>
>>> The voltages are based on TTL levels.  What are the unique voltages?
>>
>> The QBUS spec from the 1979 Bus Handbook (the Unibus levels are the
>> same):
>>
>> Input low voltage (maximum): 1.3 V
>> Input high voltage (minimum): 1.7 V
>>
>> And from the TI datasheet for the 74LS74:
>>
>> Vil - low-level input voltage 0.8 V (maximum)
>> Vih - high-level input voltage 2 V (minimum)
>>

True, you run the bus at 1.3/1.7 and see how far you go without errors.
Those are limits.  Most systems I've played with if you get over 1V/low
and below 2V/high things tend to be a bit flakey.  

Also TTL switches at 1.7ish and anyone using a 74ls74 on the bus should
be shot!
Look at 74LS240 or 241 as a better example for an bus to board receiver.
For driving the bus look at 74ls38 those are more typical.

Look at a machine that's running well and tends to stay that way and
you see more like .6-.8/low and over 2.4 high.

>> So no, the DEC bus voltage levels are not TTL levels.  Yeah, TTL might
>> work on a smaller system but you can see that if you push it out to its
>> limits, TTL could start getting flaky.  That's the kind of bug I'm happy
>> to have DEC's engineers figure out and not have to track down myself.
>>
> But who has the big systems now days? The days of 4K core is long gone.
> Use TTL and try to keep the systems small.
> Ben.
>
Some of the recovered and restored system are big.


Allison


>
>

Re: DEC bus transceivers

[Christian Corti]

On Mon, 24 Oct 2016, Paul Koning wrote:
You need to look at the PDP-11 UNIBUS Design Description document on 
Bitsavers.  Firstly, in section 4-1, it specifies which chips to use 
and recommends not using a whole list of other chips.  The only 
recommended chips are: 8640, 8641 and 8881.


Sure.  But we're trying to understand what is required in order to 
design alternatives. Where do you see the 25 ns spec?  I didn't see it 
(admittedly in a quick scan).


I have the 1979 edition of the PDP11 Bus Handbook in front of me. This 
book is very handy as all information on the Unibus and QBUS can be found 
there. The driver and receiver characteristics are listed in table 1-3 on 
page 60. The only timing parameters for the drivers are the maximum
_propagation_ delays (25ns TPDL and 35ns TPDH), so I interprete this that 
the drivers can be faster than that, and no single word about slew rates.

For the QBUS drivers, page 125 specifies the rise/fall times: 10ns<=t<=1µs
There is no such equivalent for the Unibus.

Christian

Re: Archived viruses, was Re: Reasonable price for a complete SOL-20 system?

[fritz chwolka]

Am 24.10.2016 um 23:28 schrieb Terry Stewart:

Here is some I wrote some time ago on my experiences with vintage viruses.
Bear in mind it's a narrative (and hence somewhat long-winded and rambling)
but anyway..here it is for anyone interested...
http://www.classic-computers.org.nz/blog/2009-08-30-vintage-viruses.htm

Terry (Tez)



I say thanks for your note.  Some years ago got an "wake up" with a 
stone virus. On my dos systems using for disc converting or retro games 
I test now  every disk I insert.


Best Regards

fritz


Mit freundlichen Grüßen

Fritz Chwolka

___