Re: DEC bus transceivers

[Don North]

On 10/24/2016 1: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.


FYI here is an I/O plot I did of the bus input receiver of an 8641 device (the 
blue line). A threshold of about 1.5V.
Also included is a plot of a 26S10 transceiver (which has a higher input voltage 
threshold) which I think is used

in later designs (SBI? IIRC).

http://www.ak6dn.com/stuff/26S10vs8641.jpg

Re: PDP-11 RL02 disk emulation

[Doug Jackson]

My 11/34 and 11/10 would be very happy to have one of these each .

Doug Jackson 

On 25 October 2016 5:28:05 am AEDT, Scott Baker  wrote:
>Hi Noel,
>
>>> Any chance it could be put into 'production'?
>Sure, if there is interest, I could make a run of boards.
>
>>> Also, what FPGA board are you using? I assume it's one that has an
>SD
>>> card socket or something, for actually storing the bits on?
>
>My project is just an interface board for an existing RL02 emulator
>project: www.pdp11gy.com  There are a multiple project revisions listed
>on
>the pdp11gy.com site that use different Altera FPGA dev boards: DE0
>Nano,
>DE0 Nano SOC, and BeMicro CV.
>
>I was planning to use a Terasic DE0 Nano dev board since these boards
>can
>be found on eBay from $50 to $100. The DE0 nano does not have an
>micro-SD
>card socket which is why there is a socket on my interface board.
>http://sierracircuitdesign.ddns.net/temp/RL02
>
>The DE0 Nano SOC, and BeMicro CV dev boards have micro-SD card sockets,
>so
>if you used one of those, then you would not need to populate the
>micro-SD
>socket on the interface board. According to the author of the
>www.pdp11gy.com RL02 project, the 40-pin headers on DE0 Nano, DE0 Nano
>SOC,
>and BeMicro CV are compatible, so you could use my interface board with
>any
>of these boards.
>
>Regards,
>Scott

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

Re: DEC bus transceivers

[allison]

On 10/24/2016 03:55 PM, David Bridgham wrote:
> On 10/24/2016 12:01 PM, Paul Koning wrote:
>
>> I don't know about the receiver part, but I'd expect that the drivers could 
>> very easily be done with a simple transistor circuit.
> Agreed.  However ...
>
>> As for slew rates, unless you have antique transistors, that's not going to 
>> be an issue given that you meet the current sink spec; the slew rate of an 
>> OC circuit is determined by the system capacitance and the sink current of 
>> the driver.
> I think you read this part backwards.  The slew rate requirement is not
> a minimum slew rate but a maximum one.  
It is set by bus loading card and input to devices contribute
capacitance and
pull-up current.   The rule is what you do does not break the system not
individual boards those they must be compliant.
> That is, any modern transistor
> (probably ancient ones too) will be way too fast.  You have to do
> something to slow it down.  
NO no no!  The old 2n706 and 2n3638 (mid 60s silicon parts) are ancient
and still too fast if that were the case.  Its the product of the bus
loading
the saturation characteristics of the device.  In all cases the active low
impedance is less than 20 ohms (much less). 

> Still, I think this one is easily met as
> it's just a series resistor on the gate of the driver MOSFET working
> against the gate capacitance.  Some FPGAs have current limiting on their
> output which may obviate the need for the resistor even.
Actually the Drain of a fet is already loaded with capcitance, look at
their spec's.
Also MOSFETs (trench, hex, or lateral) also have a diode present as well
as a
finite drain resistance.   A series resistor on the gate would seriously
impact
switching time and propagation delay due to Miller capcitance.

The best device is a venerable 2n3904 plus maybe 10 ohms on the collector.
That will easily sink the max 20 loads of the spec with room to spare.

the Qbus is actually harder than Unibus as it can and is extended plus data
and address are multiplex on the same lines which are 120 ohm transmission
lines for speed where the Unibus is 240ohms.  The higher the impedance the
grated the sensitivity to capacitive loading.  Omnibus is a special case
as some
devices can Wire-OR data onto the bus and an active pull-up device would be
unhappy with that.

> The receiver though, that one takes a little more thought.
>
>
Now the input is a device with hysteresis and there are plenty of TTL
devices
that fit in that space and would do well. MOS/CMOS is not god as it high
input
Capacitance and a sensitive to latchup (negative spike from the lines
ringing).

The DEC 8xxx part is like a 7438 for outgoing and 7414 for incoming is the
inversion is wrong there are compliments.   That would be one transceiver
in the package.

My sources include the DEC semiconductor data manual and the Omni/Uni/Q/bus
interfacing manuals.  Most in several editions over time.  That and
prints for
everything I own thanks to Mill Repro.  This information is part of the
design
toolkit.


Allison

Re: DEC bus transceivers

[David Bridgham]

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.

Re: DEC bus transceivers

[Guy Sotomayor Jr]

> On Oct 24, 2016, at 10:37 AM, allison  wrote:
> 
> On 10/23/16 2:59 PM, Al Kossow wrote:
>> 
>> On 10/23/16 11:50 AM, shad wrote:
>> 
>>> The problem is that there aren't open drain bus transceivers, but the
>>> problem could be solved simply using input-only and output-only components,
>>> connecting two in parallel but opposite direction on bidirectional pins.
>>> 
>> The reason for using the old parts is the logic thresholds are unique to
>> the Unibus to handle worst-case bus loading and the termination voltage they
>> used.
>> 
>> 
> The voltages are based on TTL levels.  What are the unique voltages?
> 
> The key was limited leakage current and input current to not load the bus by 
> inserting or removing
> current from a node (there is a specified maximum in per node and total 
> nodes).  That cover input
> to card devices and bus driver leakage.
> 
> Logic low voltage is typical of TTL and the driver device has to sink that 
> current and meet that value.
> Logic High was set by the terminator devices at 3.36V but the threshold is 
> lower based on the bus
> receivers.
> 
> By late 1970 it was an easy spec to meet,  When first used (pdp8e) it was new 
> and the ICs
> were not so great with leakage current and output device saturation current.
> 
> Every time this comes up the world is supposed to stop if not met. The LSI-11 
> bus (qbus)
> was actually harder as it was 120 ohm terminated and HeathKit did it with 
> common TTL
> and the CPU was DEC standard LSI-11 and it worked out to 18 slot backplanes.
> 
> 

The biggest concern is when interfacing to UNIBUS.  In the PDP-11 UNIBUS Design 
Description
document on Bitsavers, page 4-1 indicates what the Unibus interface chips are 
and what are *not*
recommended (8640, 8641 and 8881 are the only ones recommended).

There are a number of rules that must be adhered to when building out a Unibus 
system.  These
include:
Maximum cable length must be < 50’
Maximum DC loading < 20
Maximum lumped loading < 20
There are rules where cable lengths must be *increased* to avoid reflections.

A single Unibus can be divided into multiple segments.  Each segment must 
adhere to the above
rules, so you can see that a Unibus can be quite large.

For example, my PDP-11/40 resides in 2 BA11-F boxes (23” tall) and are fully 
populated with
Unibus backplanes (5 9 slot backplanes each) with a BA11-15 (15’ cable) 
connecting the two.

My point here is that the Unibus has a very different electrical environment 
than Q-bus or Omnibus
and what may work for them will probably have troubles on a Unibus.

TTFN - Guy

Re: turbochannel available

[Gordon Zaft]

Aaron!  I'm interested.

164 S. Aspen Dr.
Chandler, AZ 85226


G

On Sat, Oct 22, 2016 at 12:59 PM, Aaron J. Grier 
wrote:

> I have pmaz SCSI controller, a couple lofis, and a bunch of 8MB pmax+
> modules that are being threatened with the local electronics recycler.
>
> send me the address of your good home or place of business in the
> continental US states, and I'll spare them that fate.
>
> --
>   Aaron J. Grier | "Not your ordinary poofy goof." | agr...@poofygoof.com
>



-- 
Gordon Zaft
Province 35 Governor
Phi Mu Alpha Sinfonia Fraternity
gordonz...@gmail.com

Re: Tek 40xx computer users

[Pete Lancashire]

Start with this

http://www.vcfed.org/forum/showthread.php?33684-Tek-4051-BASIC-Simulator

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
>>
>>
>>
>>
>>
>>
>

PDP-11 RL02 disk emulation

[Scott Baker]

Hi Noel,

>> Any chance it could be put into 'production'?
Sure, if there is interest, I could make a run of boards.

>> Also, what FPGA board are you using? I assume it's one that has an SD
>> card socket or something, for actually storing the bits on?

My project is just an interface board for an existing RL02 emulator
project: www.pdp11gy.com  There are a multiple project revisions listed on
the pdp11gy.com site that use different Altera FPGA dev boards: DE0 Nano,
DE0 Nano SOC, and BeMicro CV.

I was planning to use a Terasic DE0 Nano dev board since these boards can
be found on eBay from $50 to $100. The DE0 nano does not have an micro-SD
card socket which is why there is a socket on my interface board.
http://sierracircuitdesign.ddns.net/temp/RL02

The DE0 Nano SOC, and BeMicro CV dev boards have micro-SD card sockets, so
if you used one of those, then you would not need to populate the micro-SD
socket on the interface board. According to the author of the
www.pdp11gy.com RL02 project, the 40-pin headers on DE0 Nano, DE0 Nano SOC,
and BeMicro CV are compatible, so you could use my interface board with any
of these boards.

Regards,
Scott

Re: Tek 40xx computer users

[Pete Lancashire]

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
>
>
>
>
>
>

Re: DEC bus transceivers

[allison]

On 10/23/16 2:59 PM, Al Kossow wrote:


On 10/23/16 11:50 AM, shad wrote:


The problem is that there aren't open drain bus transceivers, but the
problem could be solved simply using input-only and output-only components,
connecting two in parallel but opposite direction on bidirectional pins.


The reason for using the old parts is the logic thresholds are unique to
the Unibus to handle worst-case bus loading and the termination voltage they
used.



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

The key was limited leakage current and input current to not load the 
bus by inserting or removing
current from a node (there is a specified maximum in per node and total 
nodes).  That cover input

to card devices and bus driver leakage.

Logic low voltage is typical of TTL and the driver device has to sink 
that current and meet that value.
Logic High was set by the terminator devices at 3.36V but the threshold 
is lower based on the bus

receivers.

By late 1970 it was an easy spec to meet,  When first used (pdp8e) it 
was new and the ICs

were not so great with leakage current and output device saturation current.

Every time this comes up the world is supposed to stop if not met. The 
LSI-11 bus (qbus)
was actually harder as it was 120 ohm terminated and HeathKit did it 
with common TTL

and the CPU was DEC standard LSI-11 and it worked out to 18 slot backplanes.


Allison

Re: MSCP - was Re: Unibus / Qbus

[Paul Koning]

> On Oct 24, 2016, at 12:34 PM, allison  wrote:
> 
>> ...
> And the RQDX1/2/3 used T11 for the job so its not that intense save for speed.
> The other part of it is much of the code is likely the interface to the MFM 
> disk and thats
> speed intensive and likely more hardware than software.

FWIW, microcontroller based disk controllers existed well before MSCP.  For 
example, the CDC 7054 disk controller (for 844 disks, which are basically 
RP04s, among other things) uses a small 16 bit computer for the top level 
control, with a magic data mover engine to construct the detailed bit-level 
track / sector layout.  If you needed a better disk controller, you could 
modify the firmware (it was downloaded to the disk controller at system boot), 
though not many people were skilled enough to do so.  But I worked with one, 
the famous Don Lee at CERL (PLATO development) at the University of Illinois.

paul

Re: DEC bus transceivers

[allison]

On 10/23/16 2:50 PM, shad wrote:

Hello,
surely the old transceivers are the most compatible solution, however you
still need to convert the voltages back and forth...
Plus the solution is not the cheaper, and a little uncomfortable too, as
you need to find these old chips, hoping not to buy fake chinese duplicates
(it happened to me more time unfortunately).

So I was searching a solution with modern components, but not using
components too much specific and difficult to be found.

As we need 3.3v logic, but able to work in 5v bus, I'm thinking about 5v
tolerant standard logic as TI LVC or LVT.
The problem is that there aren't open drain bus transceivers, but the
problem could be solved simply using input-only and output-only components,
connecting two in parallel but opposite direction on bidirectional pins.
So identifying one or maybe two codes would be enough for all the
components needed for the board.

The idea of using bare transistors seems to me too much simple.
Not that it couldn't work, but it would be almost impossible to satisfy all
the specifications of the bus in this way... unless you use a more complex
circuit with precise current sources and resistors to grant correct voltage
biases, impedances and slew rates, which in the end is a logic integrated
circuit.
To the last point  The output of the DEC drivers are simply bare 
transistors that

had to meet a minimum spec for saturation current/voltage and minimum speed
for the votlage and power of the device.   Modern transistor arrays 
would be the
first choice for that.To make it more complex than that is 
unrealistic and

misses what those old devices were (hint: dirt simple, and somewhat slow,
best of the norm for the day).  Just look at the internal circuits for 
the devices

They are not complex and look much like open collector TTL on the bus side.
They did not include current sources, and bias systems.  They are not 
impedence
controlled nor slew rate controlled save for they were fast for the day 
and there

were slower!

Line receivers any of the devices like LS241 or LS241 have hysteris on 
the inputs and are
a good match to acceptable bus voltages.  I believe there are CMOS 
equivilents for that
as well.  I've used the bipolar LS TTL parts rather than CMOS as they 
have immunity to

latchup and are somewhat more resistant to ESD.


Allison



Andrea

Re: MSCP - was Re: Unibus / Qbus

[allison]

On 10/24/16 8:51 AM, Paul Koning wrote:

On Oct 24, 2016, at 7:39 AM, allison  wrote:

On 10/22/16 6:05 PM, Toby Thain wrote:

On 2016-10-22 4:08 PM, allison wrote:

...
FYI I have never heard of any one recreating the RQDX1/2/3 software
protocol MSCP
as it was nontrivial, proprietary, and copyrighted.

It's been implemented in simh, afaik. Its reputation is a little more imposing 
than the reality.
...

That may be so but putting it on a board to accept a IDE drive is far more 
useful to us that run hardware.
Why IDE, It can use CF and I also have a large supply of drives from 20-512mb.  
 Fortunately I have a
large supply of MFM drives and two SCSI controllers for the larger supply of 
SCSI drives.  However, I
feel I'm the exception and many Qbus users are not so fortunate.

Where is the source code to for that? That is the drive side of that.

There's pdp11_rq.c.  If you were to do a bus interface with microprocessor 
behind it for the protocol work, that code could be adapted for the job.  And 
that would be the obvious way to build an MSCP controller -- that's how MSCP 
was designed to be implemented and how it was done in DEC's controllers.  A 
BeagleBone Black or the like would be more than ample for the job, given that 
early implementations such as the UDA50 were done with 2901 bitslice engines 
(and very odd looking microcode).

paul
And the RQDX1/2/3 used T11 for the job so its not that intense save for 
speed.
The other part of it is much of the code is likely the interface to the 
MFM disk and thats

speed intensive and likely more hardware than software.

I'll have to scratch at the code and see.

Allison

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

[Mouse]

>>> What is the plural of a computer virus?).
>> Viruses.
>> The Latin word _virus_ [...]
>> More than you ever wanted to know, I'm sure.
> Actually, NO.

What Fred said.  Across the board.

Thank you.  That was informative, authoritative, and - impressive,
managing to combine this with the other two - interesting.

/~\ The ASCII Mouse
\ / Ribbon Campaign
 X  Against HTMLmo...@rodents-montreal.org
/ \ Email!   7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

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

[Fred Cisin]

 What is the plural of a computer virus?).

On Mon, 24 Oct 2016, Rich Alderson wrote:

Viruses.
The Latin word _virus_ means "slime, poison", and is a collective noun
. . . 
Furthermore, it is a neuter (neither masculine nor feminine) o-stem noun,

. . .
The -i marker of nominative plurals is restricted to those masculine and
. . . 
Neuters in all ancient Indo-European languages, such as Sanskrit, Greek, and

Latin, end in -a (or a regular development from *-a).
. . . 
The word _virus_ was used as a synonym for _venom_ as late as the early 20th
. . . 
modern usage derives from the medical term _filterable virus_, referring to a

More than you ever wanted to know, I'm sure.


Actually, NO.
You answered a long unresolved question.
Authoritatively, and with sufficient detail to facilitate further 
research, or even to seek collaboration if there were doubts.


Thank you.

--
Grumpy Ol' Fred ci...@xenosoft.com

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

[Rich Alderson]

From: Sean Conner
Sent: Monday, October 24, 2016 2:00 PM

>  MS-DOS had CP/M at its heart, and it had its fair share of virii (viruses? 
>  What is the plural of a computer virus?).

Viruses.

The Latin word _virus_ means "slime, poison", and is a collective noun, like
English _milk_ or _flour_ or _sugar_.  It did not form a plural at all.

Furthermore, it is a neuter (neither masculine nor feminine) o-stem noun, very
very odd because it ends in -us rather than -um in the nominative.  -us is
overwhelming the marker of a masculine o-stem, or occasionally of a masculine
or feminine u-stem (whose plural would be in -us), and very rarely of a
feminine o-stem, or often of a neuter s-stem (like _genus_ "kind", whose plural
is _genera_ "kinds").

The -i marker of nominative plurals is restricted to those masculine and
feminine o-stems; -ii is restricted further, to o-stems in which the stem vowel
is preceded by -i-, so _domus, domi_ "house, houses" vs. _genius, genii_
"tutelary spirit(s) attendant on a person from birth", _Julius, Julii_ "a
_gens_ (clan) name, members of the Julian _gens_", _Cornelius, Cornelii_, etc.

Neuters in all ancient Indo-European languages, such as Sanskrit, Greek, and
Latin, end in -a (or a regular development from *-a).  Presumably, if one were
able to specify a plural in Latin of the word _virus_, it would by rule have to
end in -a.  But the speakers of Latin did not speak of discrete slimes, it all
being one to them, so we will never know.

The word _virus_ was used as a synonym for _venom_ as late as the early 20th
Century in English, as in Burroughs's description of the deadliness of the
_virus_ of Martian serpents (in _The Gods of Mars_), which confused me no end
when I was reading the Martian novels for the first time at the age of 14.  The
modern usage derives from the medical term _filterable virus_, referring to a
disease-causing agent which was unresolvable under a microscope but which could
be mechanically filtered out of water, unlike a poisonous chemical dissolved in
water.  The word _filterable_ was dropped at some point in the literature, then
electron microscopes came along which *could* resolve viruses, and we come into
the modern world.

More than you ever wanted to know, I'm sure.

Rich


Rich Alderson
Vintage Computing Sr. Systems Engineer
Living Computers: Museum + Labs
2245 1st Avenue S
Seattle, WA 98134

mailto:ri...@livingcomputers.org

http://www.LivingComputers.org/

Re: Unibus / Qbus

[Ethan Dicks]

On Sat, Oct 22, 2016 at 5:39 PM, emanuel stiebler  wrote:
> Every time I thought about it, or even started, I gave up, because there
> aren't simply enough people who would buy such a thing. The prices for an
> old working Qbus SCSI controller are low enough, to just wait until you get
> one on ebay for a decent price.

For Qbus SCSI, that number seems to hover around $250.  I can't build
one for cheaper than that, and I doubt anyone can.

> So all of my machines have SCSI in the meantime, and the headache of making
> my own is gone ;-)

I do have more than one Qbus SCSI card, but far more Qbus CPUs than I
could ever afford to so equip.  Also, I have plenty of Unibus and one
VAXBI for which SCSI is far more expensive, so I keep dreaming of a
way to do that, but I never get as far as implementation.

-ethan

Re: DEC bus transceivers

[Ethan Dicks]

On Mon, Oct 24, 2016 at 4:35 PM, Guy Sotomayor Jr  wrote:
> OK, I guess my last email didn’t make it.  It appears to me that the rise 
> time is set at 25ns.
>
> 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.

We used 8641s on our Unibus COMBOARDs (which weren't built cheaply -
$2500 MSRP in 1984).  We also used a pair of DEC DC013s for "Unibus
Interrupt Logic" (and they were somewhat expensive, IIRC, but we used
them to minimize compatibility problems.  Customer confidence was
worth a couple hundred bucks in parts and engineering overhead).  We
likewise went with DEC chips for our Qbus product - we bought the DEC
Chipkits and used about 75% of them - the DC005s for sure, and I think
the DC010s, but didn't use the DC004s, IIRC.  Either way, everything
touching the bus went through a DEC chip.

> There are a number of rules that must be adhered to when building out a 
> Unibus system.  These
> include:
> Maximum cable length must be < 50’
> Maximum DC loading < 20
> Maximum lumped loading < 20
> There are rules where cable lengths must be *increased* to avoid reflections.
>
> For example, my PDP-11/40 resides in 2 BA11-F boxes (23” tall) and are fully 
> populated with
> Unibus backplanes (5 9 slot backplanes each) with a BA11-15 (15’ cable) 
> connecting the two.

We ran machines in the 80s that were not quite as extensive, but one I
recall well was our primary 11/750 with the internal DD11DK full of
cards (UDA50, and a few other things), then a 25' BC11 cable to a
single BA11-K with 3X DD11DK that were full or nearly full - mostly in
that box were the Emulex CS21F 16-port serial cards (at least 5), any
Unibus tape controllers, up to 6 of our COMBOARDs, at least one DMR11,
and a handful of quad SPCs.  It all seemed to play nicely, but we
weren't running close to maxed out.  Most of our other machines had
1-2 DD11DK outside of the CPU backplane but not nearly as many cards
or bus traffic.  We never had any Ethernet hardware, so all of our
sessions were handled via local serial ports.  Lots of serial ports.

-ethan

Intel 8089A, 8089A-3, 8089-3 datasheet

[Eric Smith]

Does anyone have a datasheet for an Intel 8089A, 8089A-3, or 8089-3?

The only datasheets I've found are for the "plain" 8089 with no "A" or
numeric suffix. The component resellers show better availabiliity for with
the "A" and/or "-3" suffix, though it's possible that those are in error.

The 8089 is an I/O processor. The "-3" suffix is most likely a speed grade.
The standard part without the "-3" is 5 MHz.

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

[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)

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

[ethan]

 Memory protection does not protect you from a virus.  It can protect other
running processes from being modified (if they belong to other users they
can't be infected at all; other processes owned by the user it's possible,
depending upon the system [1]) but that's it.
 -spc


Sorry, I was thinking back to the finger file from the ID software guy 
talking about how horrible MacOS was, not from the perspective of 
preventing viruses.


I suppose Apple was early in the networking game with Appletalk but not 
sure if the viruses ever made use of it.


( I grew up Atari -> PC )


--
Ethan O'Toole

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

[Sean Conner]

It was thus said that the Great et...@757.org once stated:
> 
> Early Macs definitely had viruses, a few that I got from thrift stores
> still have the viruses on them. I don't think there is any memory
> protection at all. Software selection for MacOS was pretty crappy, and it
> was hard to get under the hood. So protecting yourself from them would be
> very difficult on the Mac platform. All the file fork BS, dev tools hard
> to get. Also, just like the iPhone pretty much everything was
> shareware/commercial, less community stuff than the PC. I feel bad for the
> people that grew up on MAcOS versus MS-DOS.

  Memory protection does not protect you from a virus.  It can protect other
running processes from being modified (if they belong to other users they
can't be infected at all; other processes owned by the user it's possible,
depending upon the system [1]) but that's it.

  -spc

[1] I would say "yes" in general---you do have to be able to debug your
own programs and thus, intercept and modify a running process (at
the very least, to set a break point).

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

[Sean Conner]

It was thus said that the Great allison once stated:
> On 10/23/2016 09:15 PM, Mouse wrote:
> >> My favorite formatter was my S100 crate with CP/M, [it's] impossible
> >> to give a single user OS without background processing a virus.
> > I disagree.  I see nothing about "a single-user OS without background
> > processing" that would prevent a virus from infecting other programs,
> > even including the OS, when it's run, and potentially doing something
> > else as well.
> >
> > Perhaps you are using some meaning of "virus" other than "piece of
> > software that infects other software to propagate itself"?  That's the
> > only meaning that makes any sense to me.
> >
> Its highly unlikely as first it would have to install itself and do so
> without corrupting the OS. CP/M-80 is a machine monitor with a file system
> and lacking most of the usual read the disk and "do something" automation. 
> The only automation in CP/M is logging a drive which is reading the
> directory and mapping used blocks. So the initial load would have to be
> performed by the user.  Trogan maybe, social engineered for sure, virus
> no.  The key is you have to actually execute a file for action to happen. 
> In CP/M you can disk dump sectors and never execute them, formatting is
> even more benign, the disk is never read save for a post format verify.

  MS-DOS had CP/M at its heart, and it had its fair share of virii (viruses? 
What is the plural of a computer virus?).  The discussion Liam linked to
(https://groups.google.com/forum/#!topic/comp.os.cpm/V1-zYzA6Uzg) seems to
echo my own thoughts here---technically, it's possible, but not probable due
to the resource constraints (mainly memory) inherent in CP/M.  There is
nothing that also requires a virus to run a background process---it can
certainly modify the existing program to infect other programs, but again,
on CP/M because of the contrained resources (and lack of speed) such actions
might be noticed by the user.

  And in my experience [1] most viruses would infect executable programs and
it wasn't until Windows, when Microsoft went out of its way to find any form
of code in any file type and execute it, did viruses start infecting other
types of files (at first, I didn't believe reports of viruses spreading via
JPEGs, but yup, it was true.  Thanks, Microsoft!).

  -spc 

[1] Never got any in my day-to-day activities, but there was an outbreak
at the university I attended in the late 80s.  I managed to snag an
example and decompile it.  I have no idea what virus it was, but I
think I still have a copy in my floppy archives somewhere.

Re: DEC bus transceivers

[David Bridgham]

On 10/24/2016 04:30 PM, Paul Koning wrote:

> I don't see any max slew rate spec in the driver specs in the peripherals 
> handbook.

For the QBUS from the PDP11 Bus Handbook 1979, page 125:

AC Specifications
Bus driver output pin capacitive load: Not to exceed 10 pF
Propagation delay: Not to exceed 35 ns
Skew (difference in propagation time between slowest and fastest
gate): Not to exceed 25 ns
Rise/Fall Times: Transition time from 10% to 90% for positive
transition, and from 90% to 10% for negative transition, must
be no faster than 10 ns and no slower than 1 us

It's faster than the Unibus (that Guy posted) presumably because QBUS
systems tend to be much smaller but a driver that meets the Unibus spec
is good on the QBUS too.

On the receiver, maybe the way to go would be a linear comparator.  It
would be easy enough to come up with a 1.5V rail (half way between the
1.3V low and 1.7V high levels) running down the length.  And you have to
look but you can find them with a fast enough propagation speed.  The
only thing I'm not seeing is meeting the 10pF capacitive load; the spec
sheets just don't say.

Dave

Re: DEC bus transceivers

[Guy Sotomayor Jr]

> On Oct 24, 2016, at 1:41 PM, Paul Koning  wrote:
> 
> 
>> On Oct 24, 2016, at 4:35 PM, Guy Sotomayor Jr  wrote:
>>> ...
>> 
>> OK, I guess my last email didn’t make it.  It appears to me that the rise 
>> time is set at 25ns.
>> 
>> 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).

5.2.7.  It’s discussing the AC loading as a percentage of the risetime (25ns) 
to allow for the
reflections.

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).

TTFN - Guy

Re: DEC bus transceivers

[Paul Koning]

> On Oct 24, 2016, at 4:35 PM, Guy Sotomayor Jr  wrote:
>> ...
> 
> OK, I guess my last email didn’t make it.  It appears to me that the rise 
> time is set at 25ns.
> 
> 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).

paul

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

[Liam Proven]

On 24 October 2016 at 20:20, Cameron Kaiser  wrote:
> - Yes, classic Macs did get viruses. But as a user of a classic Mac since
>   1987, I think I encountered one exactly once and my experience was not
>   unusual. They just weren't all that common and nearly everyone ran Virex
>   anyway until Mac OS 8 days when the platform had little or no relevance to
>   virus authors.


What, really? Wow. You were lucky!

I never owned a Mac of my own 'til my "Road Apple" Performa 5200...

http://lowendmac.com/1995/performa-5200/

... in about '96, thanks to Apple's "Platform Club" for UK journos.

However, in the preceding nearly-a-decade, I supported & maintained
plenty of 'em. Virus infections were plentiful, by a wide variety of
viruses, and there were a wide variety of anti-virus apps in use.
Symantec Antivirus for Macintosh -- SAM -- was the most common
commercial one, but there were others. Virex and Disinfectant were the
most common freebies. There were both disk and file viruses, as well
as Trojans.

And when Mac Office 98 came along, there were macro viruses too.

-- 
Liam Proven • Profile: http://lproven.livejournal.com/profile
Email: lpro...@cix.co.uk • GMail/Twitter/Facebook/Flickr: lproven
Skype/MSN: lpro...@hotmail.com • LinkedIn/AIM/Yahoo: liamproven
Cell/Mobiles: +44 7939-087884 (UK) • +420 702 829 053 (ČR)

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

[Liam Proven]

On 24 October 2016 at 18:58,   wrote:
> Software selection for MacOS was pretty crappy, and it was hard to get under
> the hood.


That's not my experience, TBH. Big, great S/W range, shareware and PD,
hard_er_ but still possible to get under the hood.


-- 
Liam Proven • Profile: http://lproven.livejournal.com/profile
Email: lpro...@cix.co.uk • GMail/Twitter/Facebook/Flickr: lproven
Skype/MSN: lpro...@hotmail.com • LinkedIn/AIM/Yahoo: liamproven
Cell/Mobiles: +44 7939-087884 (UK) • +420 702 829 053 (ČR)

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

[Liam Proven]

On 24 October 2016 at 04:03, allison  wrote:
> Its highly unlikely as first it would have to install itself and do so
> without corrupting the OS.
> CP/M-80 is a machine monitor with a file system and lacking most of the
> usual
> read the disk and "do something" automation.  The only automation in CP/M
> is logging a drive which is reading the directory and mapping used blocks.
> So the initial load would have to be performed by the user.  Trogan maybe,
> social engineered for sure, virus no.


It's been discussed and there are /claims/ they existed...

https://groups.google.com/forum/#!topic/comp.os.cpm/V1-zYzA6Uzg

-- 
Liam Proven • Profile: http://lproven.livejournal.com/profile
Email: lpro...@cix.co.uk • GMail/Twitter/Facebook/Flickr: lproven
Skype/MSN: lpro...@hotmail.com • LinkedIn/AIM/Yahoo: liamproven
Cell/Mobiles: +44 7939-087884 (UK) • +420 702 829 053 (ČR)

Re: DEC bus transceivers

[Guy Sotomayor Jr]

> On Oct 24, 2016, at 1:30 PM, Paul Koning  wrote:
> 
> 
>> On Oct 24, 2016, at 3:55 PM, David Bridgham  wrote:
>> 
>> On 10/24/2016 12:01 PM, Paul Koning wrote:
>> 
>>> I don't know about the receiver part, but I'd expect that the drivers could 
>>> very easily be done with a simple transistor circuit.
>> 
>> Agreed.  However ...
>> 
>>> As for slew rates, unless you have antique transistors, that's not going to 
>>> be an issue given that you meet the current sink spec; the slew rate of an 
>>> OC circuit is determined by the system capacitance and the sink current of 
>>> the driver.
>> 
>> I think you read this part backwards.  The slew rate requirement is not
>> a minimum slew rate but a maximum one.  That is, any modern transistor
>> (probably ancient ones too) will be way too fast.  You have to do
>> something to slow it down.  Still, I think this one is easily met as
>> it's just a series resistor on the gate of the driver MOSFET working
>> against the gate capacitance.  Some FPGAs have current limiting on their
>> output which may obviate the need for the resistor even.
> 
> I don't see any max slew rate spec in the driver specs in the peripherals 
> handbook.
> 

OK, I guess my last email didn’t make it.  It appears to me that the rise time 
is set at 25ns.

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.

There are a number of rules that must be adhered to when building out a Unibus 
system.  These
include:
Maximum cable length must be < 50’
Maximum DC loading < 20
Maximum lumped loading < 20
There are rules where cable lengths must be *increased* to avoid reflections.

A single Unibus can be divided into multiple segments.  Each segment must 
adhere to the above
rules, so you can see that a Unibus can be quite large.

For example, my PDP-11/40 resides in 2 BA11-F boxes (23” tall) and are fully 
populated with
Unibus backplanes (5 9 slot backplanes each) with a BA11-15 (15’ cable) 
connecting the two.

My point here is that the Unibus has a very different electrical environment 
than Q-bus or Omnibus
and what may work for them will probably have troubles on a Unibus.

TTFN - Guy

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

[Liam Proven]

On 24 October 2016 at 03:15, Mouse  wrote:
>
> I disagree.  I see nothing about "a single-user OS without background
> processing" that would prevent a virus from infecting other programs,
> even including the OS, when it's run, and potentially doing something
> else as well.

Exactly. This. I agree. MS-DOS was a single-user OS without background
processing, but it had legions of viruses.

I don't think CP/M had TSRs as such...

https://en.wikipedia.org/wiki/CP/M#TSR_.28Terminate-and-Stay-Resident.29_programs

... but that doesn't mean it was totally impossible to get into RAM
and stay there, does it?

-- 
Liam Proven • Profile: http://lproven.livejournal.com/profile
Email: lpro...@cix.co.uk • GMail/Twitter/Facebook/Flickr: lproven
Skype/MSN: lpro...@hotmail.com • LinkedIn/AIM/Yahoo: liamproven
Cell/Mobiles: +44 7939-087884 (UK) • +420 702 829 053 (ČR)

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

[Liam Proven]

On 23 October 2016 at 19:12, Fred Cisin  wrote:
> But, I was explicitly referring to the time BEFORE OS-X!  (<1999?)

Ahh, well, that's entirely fair then.

> Assholes who proclaimed themselves to be "experts" kept pushing our college
> administration to SWITCH ALL of our our student computer labs from PC to
> Mac, mostly using the LIE that "Macs are immune to viruses".

That's... well, yeah, asshattish. Anyone who knew the Mac knew of
viruses. They were a real problem.

> But, we stuck to 80-90% PCs.
> 1) We had a dozen Macs (mostly SE?) and 5 dozen PCs.  We were getting higher
> incidence of viurses on the Macs than the PCs, due to student disks.

Can easily believe that.

> 2) At the time, certain key pieces of software that we needed (such as COBOL
> and FORTRAN compilers) were not as readily available on Mac.

[Nod] Or they were seriously expensive.

> 3) We had only needed a tiny handful of machines with performance.
> PC-DOS, Win3.1, and Win95 on 386SX were PERFECTLY suited for homework of
> programming classes.  (small homework assignments, NOT all day production!)

Win 3.1 on a 386SX, no problem.

Win 95 on a 386SX: sheesh. You'd need the patience of a saint.

Early in my time at PC Pro magazine, I actually benchmarked 95 versus
Wfwg on a 386 with 4MB. We had to hunt for a PC that old, and borrowed
it from a friend of the editor.

Amazingly, app loading was a hair quicker -- 95 had smarter cache
management. But it wasn't fast.

> Think about anybody who would claim to NEED performance to write "Hello,
> world".  And low performance created BETTER sort programs, by NOT giving the
> opportunity to "throw hardware at it".

True.

> Even the "remedial job training for the digital sweatshop" classes

[Chuckle]

> (WordPervert, Lotus, dBase, Weird, Office)

[Guffaw]

> were well suited for a large
> number of 386SX machines.

Yep, guess so!

> 4) At the time, one dozen Macs cost us as much as five dozen PCs! List
> prices for Macs might have been close to list prices of OEM PCs from IBM,
> but we were willing to run cheap generic clones, and assemble them
> ourselves.  THAT was significant, when you have a lab FULL of students (and
> rarely a waiting queue).

Oh my yes.

And they were, $ for $, significantly more expensive in the UK than Stateside.

> But, by about the time that OS-X came out, enough students had their own
> machines that we no longer needed as many.
> Our administration ceased having the Computer Information Systems department
> run the labs for Business, Math, etc., and hired IT (mostly grossly
> incompetents from "trade schools").  They were no longer "our labs".
> Machines started being down for a week or two for a bad floppy or need for
> Windoze reinstallation, waiting for IT to get around to them.

:-(

C21 IT. Everyone raves about it. I'm considered a weirdo for saying
some things were better before.

> They hired an extremely expensive outside firm ("because they are experts",
> and because the college "IT" had no idea how to do it!) to run a public
> domain test program for Y2K compatibility, and dumpstered the few machines
> that would have had to have their date manually set [ONCE!] after Y2K.

Well, TBH, I did some of that consultancy myself. I didn't dump any
kit though. Some clients took the chance to refresh their whole
office, and I made sure the old boxes were re-homed or given to
charity.


-- 
Liam Proven • Profile: http://lproven.livejournal.com/profile
Email: lpro...@cix.co.uk • GMail/Twitter/Facebook/Flickr: lproven
Skype/MSN: lpro...@hotmail.com • LinkedIn/AIM/Yahoo: liamproven
Cell/Mobiles: +44 7939-087884 (UK) • +420 702 829 053 (ČR)

Re: DEC bus transceivers

[Paul Koning]

> On Oct 24, 2016, at 3:55 PM, David Bridgham  wrote:
> 
> On 10/24/2016 12:01 PM, Paul Koning wrote:
> 
>> I don't know about the receiver part, but I'd expect that the drivers could 
>> very easily be done with a simple transistor circuit.
> 
> Agreed.  However ...
> 
>> As for slew rates, unless you have antique transistors, that's not going to 
>> be an issue given that you meet the current sink spec; the slew rate of an 
>> OC circuit is determined by the system capacitance and the sink current of 
>> the driver.
> 
> I think you read this part backwards.  The slew rate requirement is not
> a minimum slew rate but a maximum one.  That is, any modern transistor
> (probably ancient ones too) will be way too fast.  You have to do
> something to slow it down.  Still, I think this one is easily met as
> it's just a series resistor on the gate of the driver MOSFET working
> against the gate capacitance.  Some FPGAs have current limiting on their
> output which may obviate the need for the resistor even.

I don't see any max slew rate spec in the driver specs in the peripherals 
handbook.

paul

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

[Liam Proven]

On 23 October 2016 at 18:03, Electronics Plus  wrote:
> I used to have factory original CD install disks from Zip drives, but I threw 
> them all out, because they were all infected with viruses. Iomega was kind 
> enough to send me clean install disks, after I mailed them back one of the 
> infected disks. That prompted a huge recall, back in the 90s.

Wow! I never heard about that one!

I did hear of other such instances, though. And more recently,
at-the-factory-infected USB sticks and digital picture frames.

-- 
Liam Proven • Profile: http://lproven.livejournal.com/profile
Email: lpro...@cix.co.uk • GMail/Twitter/Facebook/Flickr: lproven
Skype/MSN: lpro...@hotmail.com • LinkedIn/AIM/Yahoo: liamproven
Cell/Mobiles: +44 7939-087884 (UK) • +420 702 829 053 (ČR)

Re: RK8E Plessey Clone and Data Break Error

[Al Kossow]

good job!

On 10/24/16 12:48 PM, Marco Rauhut wrote:
> As repl to my own post...
> 
> The problem was the current adress register. One of three 74161 binary 
> counters was bad. After replaceing it, RK8E
> Diskless Controlltest working fine
> 

Re: DEC bus transceivers

[David Bridgham]

On 10/24/2016 12:01 PM, Paul Koning wrote:

> I don't know about the receiver part, but I'd expect that the drivers could 
> very easily be done with a simple transistor circuit.

Agreed.  However ...

> As for slew rates, unless you have antique transistors, that's not going to 
> be an issue given that you meet the current sink spec; the slew rate of an OC 
> circuit is determined by the system capacitance and the sink current of the 
> driver.

I think you read this part backwards.  The slew rate requirement is not
a minimum slew rate but a maximum one.  That is, any modern transistor
(probably ancient ones too) will be way too fast.  You have to do
something to slow it down.  Still, I think this one is easily met as
it's just a series resistor on the gate of the driver MOSFET working
against the gate capacitance.  Some FPGAs have current limiting on their
output which may obviate the need for the resistor even.

The receiver though, that one takes a little more thought.

Re: RK8E Plessey Clone and Data Break Error

[Marco Rauhut]

As repl to my own post...

The problem was the current adress register. One of three 74161 binary 
counters was bad. After replaceing it, RK8E Diskless Controlltest 
working fine


Marco


Am 18.10.2016 um 21:55 schrieb Marco Rauhut:

Hello all together,

i restore a rk05 disk drive in combination with an Plessey RK8E clone 
controller.

Now the drive itself is restored, and the connection cables are built.

My problem is that the rk8e diskless controll test (dhrka) fails with 
an data break error. The diskless controlltest
is running throug all register and also the databuffer test. But in 
the first data break routine it fails.


Then i toggled in the Example program from the maintanence vol.III, 
Single Cycle Data Break Transfers (Write than Read).
With this program the content of the SwitchRegister is written through 
the data buffer registers and read back to the memory.
Afterwards it is compared to the original SR content. I found out that 
the routine is running if SR=. Deeper investigation results that 
the bits 0, 1, 4, 6 and 9 have to be one`s to run the routine. The 
other SR  bits are switchable while running the program.


Next thing i did is trying read data with futil. i could read data 
form the disk. But with many read errors.
Because i do not know anything about the allignment between my 
diskpack and the drive, i formated the pack
with the RK8E Formater (dhrkd). The write part of the format is 
running. In the disk checking part the formater fails.


Anyway. Then i used futil and scanned the whole surface off the 
diskpack. On the whole disk are 5 bad blocks left.


Now i am able to dump blocks from the disk. But it seems that no 
matter witch block i dump out, it is the same block
all over the disk. Afterwards i tried to modifie some words in block 
0. And this is working. When i write the modified block i see the

modification also in every other block of the disk.

Have anyone the lightning idea?

On a Google search i found a post of Rick Bensene from 2014 on this 
list witch described a similiar problem.
In this discussion where talked about an spike in the load signal of 
the current address register.

I checked that and see that this was not my problem.

Thanks in advance

Marco Rauhut

cctech vs cctalk issues / was Re: DEC bus transceivers

[Brent Hilpert]

I'm still getting duplicates from cctech:  I'm registered to cctalk but for 
many messages, a day after it appears via cctalk, the same message shows up 
from cctech - this has been going on since the list crash a year or two ago.
It seems to be the messages that were sent to cctech.
It gets annoying when a block of 20 messages comes in and you have to read 
through them all to realise you've already seen them.

I thought the outcome of conversation of these issues after the list crash was 
cctech was going to be eliminated/amalgamated. Having the two lists may be 
resulting in more detriment than benefit.


On 2016-Oct-24, at 11:08 AM, Al Kossow wrote:

> having half of this conversation not making it from cctech to cctalk is 
> really starting to piss me off

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

[Fred Cisin]

On Mon, 24 Oct 2016, et...@757.org wrote:
I *DO* remember that in the local BBS wars, people who were toying with 
MS-DOS viruses would make them then submit them to the AV companies to get 
them on "the list." The huge list of viruses that the software would defend 
against. But in reality, they were never in the wild.


At the time of the "Michelangelo" panic, it did not appear to be in the 
wild.  (ZERO of the "hundreds" of disks destroyed during scanning at UC 
Berkeley student computer labs were retained for analysis)
The AV companies had copies, and they provided them to each other 
and to the media.  It wasn't until later that copies started to leak out 
into the wild.  In fact, we speculated that what was being found were 
wannabe variants, created from "Stoned", and INSPIRED by and after the 
panic.
The ones that we finally ran into were blatently obviously simply slightly 
modified versions of "Stoned", but THAT aspect was never mentioned by the 
AV companies nor the media during the panic.



Oh and the local guy that was involved at a high level with the DOS Virus 
group, he said at a party that had a bunch of DOS virus authors John 
MacAffee was there partying with them. No proof and he probably wouldn't 
admit saying that today (was told to me in the early 2000s).


Wouldn't be surprising.  I knew one fellow, with journalistic ties, who 
partied with both groups.  He threw a Comdex party at the Landmark Hotel 
with a lot of strange people.


There were rumors at the time, that McAfee was involved in creating 
"Michelangelo" and the panic.  But, until there is some evidence, I would 
give him the benefit of the doubt; and there's no way to ask him now (he's 
currently a murder suspect fugitive).




Creation of the "Michelangelo" variants that we saw did not require any 
expertise, just some disassembly of "Stoned" and some trivial patching.

Creation of the PANIC was an impressive feat of showmanship.

THAT (creation of the "Michelangelo" panic), and Harold Hill of Meredith 
Wilson's "Music Man" ("You've got TROUBLE, right here in River 
City") really helped train a lot of people how to make money off of Y2K.
The college probably spent more than $300 average PER MACHINE testing and 
preparing for Y2K!  (Since there were friends and relatives of upper 
officials working with the contractors, exact amounts spent were not 
clearly revealed)



--
Grumpy Ol' Fred ci...@xenosoft.com

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

[Cameron Kaiser]

> Early Macs definitely had viruses, a few that I got from thrift stores 
> still have the viruses on them. I don't think there is any memory 
> protection at all. Software selection for MacOS was pretty crappy, and it 
> was hard to get under the hood. So protecting yourself from them would be 
> very difficult on the Mac platform. All the file fork BS, dev tools hard 
> to get. Also, just like the iPhone pretty much everything was 
> shareware/commercial, less community stuff than the PC. I feel bad for the 
> people that grew up on MAcOS versus MS-DOS.

Lest this turn into another chapter in Mac vs DOS:

- Yes, classic Macs did get viruses. But as a user of a classic Mac since
  1987, I think I encountered one exactly once and my experience was not
  unusual. They just weren't all that common and nearly everyone ran Virex
  anyway until Mac OS 8 days when the platform had little or no relevance to
  virus authors.

- You may not have had a command line, but it was perfectly possible to get
  under the hood. You could mess with resources in MacsBug or ResEdit, shuffle
  INITs and CDEVs, whatever you like. Such tools were easy to get and freely
  available. Whether you *liked* the resource/data fork split is a matter of
  preference but they certainly didn't prohibit mucking around by the
  knowledgeable and the structured nature of the resource fork in some ways
  makes it easier.

- No, pretty much everything was *not* just shareware/commercial. Look at
  UMich or Info-Mac for a nearly total refutation of your statement. Freeware
  existed in quantity commensurate with the platform's penetration and Apple
  certainly did not discourage it in those days. I have mirrors of them which
  you can check out:

gopher://gopher.floodgap.com/1/archive

-- 
 personal: http://www.cameronkaiser.com/ --
  Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com
-- Art is either plagiarism or revolution. -- Paul Gauguin 

Fwd: Re: DEC bus transceivers

[Al Kossow]

 Forwarded Message 
Subject: Re: DEC bus transceivers
Date: Mon, 24 Oct 2016 13:37:14 -0400
From: allison 
Reply-To: General Discussion: On-Topic Posts 
To: General Discussion: On-Topic Posts 

On 10/23/16 2:59 PM, Al Kossow wrote:
>
> On 10/23/16 11:50 AM, shad wrote:
>
>> The problem is that there aren't open drain bus transceivers, but the
>> problem could be solved simply using input-only and output-only components,
>> connecting two in parallel but opposite direction on bidirectional pins.
>>
> The reason for using the old parts is the logic thresholds are unique to
> the Unibus to handle worst-case bus loading and the termination voltage they
> used.
>
>
The voltages are based on TTL levels.  What are the unique voltages?

The key was limited leakage current and input current to not load the bus by 
inserting or removing
current from a node (there is a specified maximum in per node and total nodes). 
 That cover input
to card devices and bus driver leakage.

Logic low voltage is typical of TTL and the driver device has to sink that 
current and meet that value.
Logic High was set by the terminator devices at 3.36V but the threshold is 
lower based on the bus
receivers.

By late 1970 it was an easy spec to meet,  When first used (pdp8e) it was new 
and the ICs
were not so great with leakage current and output device saturation current.

Every time this comes up the world is supposed to stop if not met. The LSI-11 
bus (qbus)
was actually harder as it was 120 ohm terminated and HeathKit did it with 
common TTL
and the CPU was DEC standard LSI-11 and it worked out to 18 slot backplanes.


Allison

Fwd: Re: DEC bus transceivers

[Al Kossow]

having half of this conversation not making it from cctech to cctalk is really 
starting to piss me off



 Forwarded Message 
Subject: Re: DEC bus transceivers
Date: Mon, 24 Oct 2016 13:10:21 -0400
From: allison 
Reply-To: General Discussion: On-Topic Posts 
To: General Discussion: On-Topic Posts 

On 10/23/16 2:50 PM, shad wrote:
> Hello,
> surely the old transceivers are the most compatible solution, however you
> still need to convert the voltages back and forth...
> Plus the solution is not the cheaper, and a little uncomfortable too, as
> you need to find these old chips, hoping not to buy fake chinese duplicates
> (it happened to me more time unfortunately).
>
> So I was searching a solution with modern components, but not using
> components too much specific and difficult to be found.
>
> As we need 3.3v logic, but able to work in 5v bus, I'm thinking about 5v
> tolerant standard logic as TI LVC or LVT.
> The problem is that there aren't open drain bus transceivers, but the
> problem could be solved simply using input-only and output-only components,
> connecting two in parallel but opposite direction on bidirectional pins.
> So identifying one or maybe two codes would be enough for all the
> components needed for the board.
>
> The idea of using bare transistors seems to me too much simple.
> Not that it couldn't work, but it would be almost impossible to satisfy all
> the specifications of the bus in this way... unless you use a more complex
> circuit with precise current sources and resistors to grant correct voltage
> biases, impedances and slew rates, which in the end is a logic integrated
> circuit.
To the last point  The output of the DEC drivers are simply bare 
transistors that
had to meet a minimum spec for saturation current/voltage and minimum speed
for the votlage and power of the device.   Modern transistor arrays would be the
first choice for that.To make it more complex than that is unrealistic and
misses what those old devices were (hint: dirt simple, and somewhat slow,
best of the norm for the day).  Just look at the internal circuits for the 
devices
They are not complex and look much like open collector TTL on the bus side.
They did not include current sources, and bias systems.  They are not impedence
controlled nor slew rate controlled save for they were fast for the day and 
there
were slower!

Line receivers any of the devices like LS241 or LS241 have hysteris on the 
inputs and are
a good match to acceptable bus voltages.  I believe there are CMOS equivilents 
for that
as well.  I've used the bipolar LS TTL parts rather than CMOS as they have 
immunity to
latchup and are somewhat more resistant to ESD.


Allison

>
> Andrea
>

RE: Tek 40xx computer users

[Brad H]

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 
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: Archived viruses, was Re: Reasonable price for a complete SOL-20 system?

[ethan]

But, I was explicitly referring to the time BEFORE OS-X!  (<1999?)
Assholes who proclaimed themselves to be "experts" kept pushing our college 
administration to SWITCH ALL of our our student computer labs from PC to Mac, 
mostly using the LIE that "Macs are immune to viruses".


Jumping in here late. When I was much younger I remember being on BBSes 
that were H/P/A/V (Hacking, Phreaking, Anarchy and Viruses.) The first 3 
just being old textfiles that are lovingly preserved by people like Jason 
Scott. We had a local guy that shook up the DOS Virus group NuKE. Later he 
became a coworker.


Early Macs definitely had viruses, a few that I got from thrift stores 
still have the viruses on them. I don't think there is any memory 
protection at all. Software selection for MacOS was pretty crappy, and it 
was hard to get under the hood. So protecting yourself from them would be 
very difficult on the Mac platform. All the file fork BS, dev tools hard 
to get. Also, just like the iPhone pretty much everything was 
shareware/commercial, less community stuff than the PC. I feel bad for the 
people that grew up on MAcOS versus MS-DOS.


I *DO* remember that in the local BBS wars, people who were toying with 
MS-DOS viruses would make them then submit them to the AV companies to get 
them on "the list." The huge list of viruses that the software would 
defend against. But in reality, they were never in the wild. I think there 
was at least 8 of these from one author who was just a bored Navy guy. So 
take the # of viruses with a grain of salt. But BBSes did have collections 
of them, and I'm sure you can still find the huge zip files of them 
somewhere.


There were utilities like Virus Creation Lab that had checkboxes and would 
crap out assembly code or something that you would then take the output 
over to MASM or the Borland Assembler and compile. So who knows how many 
of the DOS viruses came from this.


I remember doing a lot of BBSing, and trading stuff with friends and never 
saw a virus. There was a case where the computers at Sears had the stoned 
virus or something and everyone in the area was excited to go over there 
and get a disk infected with it.


Of course BBSes always had the virus scan door. Ahhh fprot. And also the 
zip files that never stop expanding :-)


Oh and the local guy that was involved at a high level with the DOS Virus 
group, he said at a party that had a bunch of DOS virus authors John 
MacAffee was there partying with them. No proof and he probably wouldn't 
admit saying that today (was told to me in the early 2000s).

Re: DEC bus transceivers

[Paul Koning]

> On Oct 23, 2016, at 2:50 PM, shad  wrote:
> 
> ...
> The idea of using bare transistors seems to me too much simple.
> Not that it couldn't work, but it would be almost impossible to satisfy all
> the specifications of the bus in this way... unless you use a more complex
> circuit with precise current sources and resistors to grant correct voltage
> biases, impedances and slew rates, which in the end is a logic integrated
> circuit.

I don't know about the receiver part, but I'd expect that the drivers could 
very easily be done with a simple transistor circuit.  After all, that's what 
an open collector (or open drain) driver is, in essence.  And the spec is quite 
straightforward, it demands an adequate current sinking capacity which is easy 
to meet.  As for slew rates, unless you have antique transistors, that's not 
going to be an issue given that you meet the current sink spec; the slew rate 
of an OC circuit is determined by the system capacitance and the sink current 
of the driver.

Some fiddling with SPICE should yield simple answers here.

paul

Re: DEC bus transceivers (was Re: Unibus disk controller with modern storage)

[Noel Chiappa]

> From: David Bridgham

> Just the bus interface takes over half the area of a dual-height board!

In part because the level converters are SMD, and we had to mount them on
(modified) wide DIP carriers to use them in a wire-wrap board.

> I've played around with laying out what might be the production board
> ... and I've got it down to a row of 8641 bus transceivers and a row or
> two of the level-converter chips.

> http://pdp10.froghouse.org/qsic/proto-pcb.jpg

For those looking at that picture, it's not our current plan for 'producton'
QSIC's; the one in the picture uses a daughter-card with an FPGA on it, but
that makes the card to high to fit into a single slot. So the current plan is
to do a card with an FPGA on it directly.

Noel

turbochannel available

[Aaron J. Grier]

I have pmaz SCSI controller, a couple lofis, and a bunch of 8MB pmax+
modules that are being threatened with the local electronics recycler.

send me the address of your good home or place of business in the
continental US states, and I'll spare them that fate.

-- 
  Aaron J. Grier | "Not your ordinary poofy goof." | agr...@poofygoof.com

Re: 11/35 on eBait

[allison]

On 10/24/16 8:51 AM, Pontus Pihlgren wrote:

On Mon, Oct 24, 2016 at 01:12:50PM +0200, Philipp Hachtmann wrote:


On 10/19/2016 02:42 AM, Noel Chiappa wrote:

> From: Glen Slick

>> Went unsold at $3500. Relisted, this time at $5000.

> there was a taker for that 11/35 at $5000 today

Smack me with a wet halibut. They must not have seen the original listing?

I can't come up with any other explanation why someone would pass up a chance
to buy it for $3.5K, and pay $1.5 more for the priviledge...


Was it really sold? I can't figure that out from here. Only "listing has
ended". And when I try to search for it, the website doesn't show it :-(


Looks like it:

http://www.ebay.com/itm/DEC-PDP-11-35-COMPUTER-/142146207101?

(ebay will usually tell you "the seller has relisted this item" and if
you click it you get the above url)

/P
I peeked at it and who knows on that...  Along with that there was a 
Robin [vt180] so they claim
for 262$ save for its missing the keyboard, disk drives and cables and 
compared to mine it looks
rough.  The funny part is they claim it works without keyboard and disks 
it can't be tested except

for as a vt100 as it will default to that.

The other was a 11/23 or a box marked as such untested and unknown what 
boards if any are in it.

I have two of them sitting... maybe time to sell.

Ebait, still full of hilarity.

Allison

Re: MSCP - was Re: Unibus / Qbus

[Paul Koning]

> On Oct 24, 2016, at 7:39 AM, allison  wrote:
> 
> On 10/22/16 6:05 PM, Toby Thain wrote:
>> On 2016-10-22 4:08 PM, allison wrote:
>>> ...
>>> FYI I have never heard of any one recreating the RQDX1/2/3 software
>>> protocol MSCP
>>> as it was nontrivial, proprietary, and copyrighted.
>> 
>> It's been implemented in simh, afaik. Its reputation is a little more 
>> imposing than the reality.
>> ...
> That may be so but putting it on a board to accept a IDE drive is far more 
> useful to us that run hardware.
> Why IDE, It can use CF and I also have a large supply of drives from 
> 20-512mb.   Fortunately I have a
> large supply of MFM drives and two SCSI controllers for the larger supply of 
> SCSI drives.  However, I
> feel I'm the exception and many Qbus users are not so fortunate.
> 
> Where is the source code to for that? That is the drive side of that.

There's pdp11_rq.c.  If you were to do a bus interface with microprocessor 
behind it for the protocol work, that code could be adapted for the job.  And 
that would be the obvious way to build an MSCP controller -- that's how MSCP 
was designed to be implemented and how it was done in DEC's controllers.  A 
BeagleBone Black or the like would be more than ample for the job, given that 
early implementations such as the UDA50 were done with 2901 bitslice engines 
(and very odd looking microcode).

paul

Re: MSCP - was Re: Unibus / Qbus

[allison]

On 10/22/16 6:05 PM, Toby Thain wrote:

On 2016-10-22 4:08 PM, allison wrote:

...
FYI I have never heard of any one recreating the RQDX1/2/3 software
protocol MSCP
as it was nontrivial, proprietary, and copyrighted.


It's been implemented in simh, afaik. Its reputation is a little more 
imposing than the reality.


--Toby


That may be so but putting it on a board to accept a IDE drive is far 
more useful to us that run hardware.
Why IDE, It can use CF and I also have a large supply of drives from 
20-512mb.   Fortunately I have a
large supply of MFM drives and two SCSI controllers for the larger 
supply of SCSI drives.  However, I

feel I'm the exception and many Qbus users are not so fortunate.

Where is the source code to for that? That is the drive side of that.

Allison

Re: DEC bus transceivers

[allison]

On 10/23/2016 04:57 PM, Toby Thain wrote:
> On 2016-10-23 2:50 PM, shad wrote:
>> Hello,
>> surely the old transceivers are the most compatible solution, however
>> you
>> still need to convert the voltages back and forth...
>> Plus the solution is not the cheaper, and a little uncomfortable too, as
>> you need to find these old chips, hoping not to buy fake chinese
>> duplicates
>> (it happened to me more time unfortunately).
>>
>> So I was searching a solution with modern components, but not using
>> components too much specific and difficult to be found.
>>
>> As we need 3.3v logic, but able to work in 5v bus, I'm thinking about 5v
>> tolerant standard logic as TI LVC or LVT.
>> The problem is that there aren't open drain bus transceivers, but the
>> problem could be solved simply using input-only and output-only
>> components,
>> connecting two in parallel but opposite direction on bidirectional pins.
>> So identifying one or maybe two codes would be enough for all the
>> components needed for the board.
>>
>> The idea of using bare transistors seems to me too much simple.
>> Not that it couldn't work, but it would be almost impossible to
>> satisfy all
>> the specifications of the bus in this way... unless you use a more
>> complex
>> circuit with precise current sources and resistors to grant correct
>> voltage
>> biases, impedances and slew rates, which in the end is a logic
>> integrated
>> circuit.
>>
>> Andrea
>>
>
> As an electronics noob, I'm really waiting for somebody to publish
> their findings on this, comprehensively, so I can steal their labour.
>
> Has anyone done so? Is anyone planning to do so? I know that this
> topic flares up on the list every 6 months ago in a series of
> disjointed posts and observations. The gold is hard to find
> (especially for aforesaid noobs).
>
> --Toby
>
Toby,

I've watched many flail on this when simple solutions work.  They seem
to read into the driver/receiver
specs a lot of imagined should be x when its simple.  The specs are
those of Utilogic and TTL of the day.

DEC buses relied on two things; pull-ups to assert the high voltage
level and a strong pull down to ground
at low cost.  All of this was developed in the late 60s and early 70s. 
To add to that the idea of open
collector was  to prevent damage if two drivers asserted the same
line.Also in some cases to allow
wired OR logic.  We forget that a transceiver in 1970 was the level of
complex logic and the only thing
more complex was a flipflop as around then the tech was not there for
more than a handful of transistors
on the die.  By time the tech could do more the parts were firmly
entrenched and provided the basic
bits often needed.

DEC always suggested their part for the base reason is they work, there
were examples in use to study
and internal engineering was expected to!  That and if a customer needed
DEC support it was easier.

I keep my supply of those for board repair.  For new boards I make for
myself (QBUS or Omnibus)  I use
bog simple 74LS14, 74LS240, 74LS241, 74LS245  and occasionally a open
collector part like 7438.

The 3.3 volt problem is  modern logic and not modern in conflict.   The
trick in engineering around that
is to keep the interfaces limited to reduce the needed transitions back
and forth.

Allison
Former MilRat

MSCP - was Re: Unibus / Qbus

[Toby Thain]

On 2016-10-22 4:08 PM, allison wrote:

...
FYI I have never heard of any one recreating the RQDX1/2/3 software
protocol MSCP
as it was nontrivial, proprietary, and copyrighted.


It's been implemented in simh, afaik. Its reputation is a little more 
imposing than the reality.


--Toby




Allison

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

[allison]

On 10/23/2016 09:15 PM, Mouse wrote:
>> My favorite formatter was my S100 crate with CP/M, [it's] impossible
>> to give a single user OS without background processing a virus.
> I disagree.  I see nothing about "a single-user OS without background
> processing" that would prevent a virus from infecting other programs,
> even including the OS, when it's run, and potentially doing something
> else as well.
>
> Perhaps you are using some meaning of "virus" other than "piece of
> software that infects other software to propagate itself"?  That's the
> only meaning that makes any sense to me.
>
> /~\ The ASCII   Mouse
> \ / Ribbon Campaign
>  X  Against HTML  mo...@rodents-montreal.org
> / \ Email! 7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
>
Its highly unlikely as first it would have to install itself and do so
without corrupting the OS.
CP/M-80 is a machine monitor with a file system and lacking most of the
usual
read the disk and "do something" automation.  The only automation in CP/M
is logging a drive which is reading the directory and mapping used blocks.
So the initial load would have to be performed by the user.  Trogan maybe,
social engineered for sure, virus no.  The key is you have to actually
execute
a file for action to happen.  In CP/M you can disk dump sectors and never
execute them, formatting is even more benign, the disk is never read save
for a post format verify.

There is no boot block save for system tracks and even then the OS is not
wired to write them without a utility so other than boot in rom(usually)
its kinda hard to pollute the disk though powering off with it in the
drive usually
will kill a sector making it unreadable.

There are many other OSs that equally as crude such as Northstar Dos or
for that
fact OS/8.  Old machines do not evaluate like current winders, linux,
OSX in that
perspective.

The extreme opposing end of the spectrum is a VAX running VMS/OVMS the
level of protection is high enough that you would spend much time and
effort to
find the way to get something above the user account level.   In that
case you
can pollute your self maybe share with friends assuming you don't user
crash first.


Allison

Re: MSCP - was Re: Unibus / Qbus

[Paul Koning]

> On Oct 22, 2016, at 6:05 PM, Toby Thain  wrote:
> 
> On 2016-10-22 4:08 PM, allison wrote:
>> ...
>> FYI I have never heard of any one recreating the RQDX1/2/3 software
>> protocol MSCP
>> as it was nontrivial, proprietary, and copyrighted.
> 
> It's been implemented in simh, afaik. Its reputation is a little more 
> imposing than the reality.

Well, it certainly is vastly more complex than the older CSR-based controllers. 
 That's not to say it's undoable; compared to, say, SCSI it's not that painful. 
 (In fact, you might say it's a natural predecessor of SCSI.)  Proprietary, 
yes.  Copyrighted?  perhaps so, but copyright is irrelevant if you want to 
build implementations.  (It only matters if you want to make copies of the 
document.)  I assume MSCP was patented, but any patents have expired long ago 
so those aren't relevant any longer either.  

The main question is whether a sufficiently accurate spec is available.  In the 
case of MSCP (and TMSCP, which is a close relative) the answer is yes (on 
Bitsavers).  And unlike some other standards sources, DEC standards generally 
are written to the level of quality that conformance implies interoperability 
-- in other words, do what the spec says and it will work correctly.

paul

Re: DEC bus transceivers (was Re: Unibus disk controller with modern storage)

[allison]

On 10/22/2016 06:40 PM, David Bridgham wrote:
> On 10/22/2016 12:44 PM, shad wrote:
>
>> What kind of bus transceivers did you used for the QSIC, specially
>> because you have
>> to go from 5V open-drain logic to 3.3V logic?
> To add to Noel's answer, here's a picture of our current prototype board.
>
> http://pdp10.froghouse.org/qsic/qsic-wirewrap.jpg
>
> Coming up from the QBUS, the first two rows of chips are the bus
> transceivers.  The next row and a half are the level-converters.  Then
> the two large ribbon cables run off to the FPGA module we're using for
> development.  The two small ribbon cables go to the indicator panel. 
> Just the bus interface takes over half the area of a dual-height board! 
> I've played around with laying out what might be the production board
> (when I get tired of Verilog and want a mindless break, I doodle with
> kicad) and I've got it down to a row of 8641 bus transceivers and a row
> or two of the level-converter chips.  It's better but still a good
> fraction of the entire board.
>
> http://pdp10.froghouse.org/qsic/proto-pcb.jpg
>
> Now I thought, what if my idea of that two MOSFET bus transceiver would
> work?  What would the board look like then?
>
> http://pdp10.froghouse.org/qsic/qsic-smt.jpg
>
> Obviously that could be squeezed down a lot more.  Even another
> transistor or two per bus line would still be fairly small.  Doing the
> bus transceiver and level-conversion in one step makes a big difference.
>
> For the QSIC, we're going to have sufficient room and we're able to find
> enough old bus transceivers to continue on as we're going.  Still, I'd
> sure love to have an option that used production parts and took up less
> board space.
>
>

For bus to card LS241, LS244 and LS245 were used in the day by heathkit
(H11)
For bus to card with hysteresis LS14 was a common choice along with
LS13 or maybe LS132.  

Other considerations the DEC specs were based on available devices of
the day (late 70s)
and in the last 40 years there are a plethora of better devices that
replace those easily.  
The key being Schmidt input (bus to card level) for noise immunity and
robust drive for the
output devices.  Many of those were also used for S100 (less well
thought out and
often noisier.) with good success.  I've copied and used those for
making boards as
needed for Qbus and Omnibus as those represent the common DEC buses
outside of SCSI
in the hardware I own.

One thing I'm adverse to is bus to CMOS without buffering or the reverse
even if
the CMOS can drive the bus.  Unexpected ringing or spikes on the bus can
play
havoc with those as well as poor ESD practices.

Now the problems of board space and available parts may force SMT and CMOS
for the internal circuits and also power conservation (and thermal
management).


Allison

Re: Unibus / Qbus

[emanuel stiebler]

On 2016-10-22 22:08, allison wrote:


So to do that you have two project the hardware is fairly straight
forward (see the
applicable Bus interfacing books put out by DEC) but the software to use
it is a project.
FYI I have never heard of any one recreating the RQDX1/2/3 software
protocol MSCP
as it was nontrivial, proprietary, and copyrighted.


Every time I thought about it, or even started, I gave up, because there 
aren't simply enough people who would buy such a thing. The prices for 
an old working Qbus SCSI controller are low enough, to just wait until 
you get one on ebay for a decent price.


So all of my machines have SCSI in the meantime, and the headache of 
making my own is gone ;-)

Unibus / Qbus

[shadoooo]

Hello,
we are discussing on separate thread about doing an universal interface for
PDP11.
I'm taking all the relevant documentation about Unibus and Qbus busses,
aiming to check the possibility of doing a board compatible, with some
adjustments, with both worlds.
I started to read the 1979 specifications, however it's not all clear to
me, specially about Unibus.

What I understood:
- Qbus is complete on A and B connectors, so a dual card could be done.
Some backplanes have a true serpentine, while some other has C and D with
other signals, but those are of particular usage with dual-board interfaces.
Basically both dual and quad boards can be done, with the latter using A
and B and simply propagating grant on C and D, supposedly connected in
standard serpentine.

Unibus: the specifications are describing A and B, but backplanes are
complicate than that, and can have Unibus, Modified Unibus, Extended
Unibus, SPC...
What for?
If all the signals are in AB, why they are connected again in CDEF?
There's some complete documentation about the different backplane types,
and the standard approach for an Unibus board?

Thanks
Andrea

Re: Unibus / Qbus

[allison]

On 10/22/2016 03:18 PM, shad wrote:
> Hello,
> we are discussing on separate thread about doing an universal interface for
> PDP11.
> I'm taking all the relevant documentation about Unibus and Qbus busses,
> aiming to check the possibility of doing a board compatible, with some
> adjustments, with both worlds.
> I started to read the 1979 specifications, however it's not all clear to
> me, specially about Unibus.
>
> What I understood:
> - Qbus is complete on A and B connectors, so a dual card could be done.
> Some backplanes have a true serpentine, while some other has C and D with
> other signals, but those are of particular usage with dual-board interfaces.
> Basically both dual and quad boards can be done, with the latter using A
> and B and simply propagating grant on C and D, supposedly connected in
> standard serpentine.
>
> Unibus: the specifications are describing A and B, but backplanes are
> complicate than that, and can have Unibus, Modified Unibus, Extended
> Unibus, SPC...
> What for?
> If all the signals are in AB, why they are connected again in CDEF?
> There's some complete documentation about the different backplane types,
> and the standard approach for an Unibus board?
>
> Thanks
> Andrea
>

There are later DEC databooks on the net that give a more complete picture.

The biggest total difference is the QBUS the address (a0-15) and data
d0-15 are multiplexed.
So separate boards make more sense for the buses when you allow for the
Qbus being AB
and Unibus minimally quad or hex size.  

FYI the CD and some cases EF width for Qbus was to allow for quad wide
and hex wide cards
for large peripherals or memories (PDP-11 Qbus CORE is hex wide) and
many board sets for
Qbus like RLV-11 (two boards) need CD interconnect to ty both together
but not for CPU access
where the single board version RLV21 is only a single quad wide.

So a Qbus mass storage could be a dual width and can be very simple for
IDE/CF or maybe SD.

Often the larger problem is not building hardware (there was an IDE
design out there for
QBUS VAX or PDP11 using PIO transfers) but a driver for VMS, Ultrix,
RT11, RSX11, RSTS
was a totally larger project.

So to do that you have two project the hardware is fairly straight
forward (see the
applicable Bus interfacing books put out by DEC) but the software to use
it is a project.
FYI I have never heard of any one recreating the RQDX1/2/3 software
protocol MSCP
as it was nontrivial, proprietary, and copyrighted.


Allison

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

[allison]

On 10/22/2016 01:36 PM, Ali wrote:
>>> I didn't think modern A/V products included complete historical sets
>>> of signatures. I
>>
>> I would certainly expect them to, yes!
>
> Just wondering are you guys not running AV SW on your old HW? I personally 
> run period specific AV SW on my older machines. Granted I have mostly IBM 
> 51xx series machines and later Macs so AV SW is easier to find. 
>
 If its a PC and running M$ it has it...  I don't collect them but have
a few oldies for the utility they present.
Even the mainstay PCs in use are linux based.  For those times I need
winders VMware/Openbox virtualization
keeps it well contained.

The rest of the hardware is DEC PDP-8f, Qbus PDP11s (11/03 through
11/73) and Qbus VAX plus 3100series.
The S100 gear runs CP/M as do the 8080/8085/z80 SBCs so no risk there
the remainder are odd things like
IMSAI 3035 control computer Ti9900, 6502 and others that virus/trogans
mean nothing.  I can't Imagine
malware for my AmproLB+ or Kaypro4/84  would look like.  In general if
its not internet connected its  very
low risk and if it can't run M$ OS on intel its even less risk.When
I find a bug using the PDP-11 running RT11
or the Vax running VMS makes it really easy to dissect the code without
worry of it escaping.

For those times I wish to visit a site that is flagged as dropping
malware using an expendable virtual machine
(copy of one) has proven both safe and handy. 


Allison

Re: 11/35 on eBait

[Noel Chiappa]

> Philipp Hachtmann wrote:

> Was it really sold? I can't figure that out from here. Only "listing
> has ended". And when I try to search for it, the website doesn't show
> it :-(

??? If you go to the listing:

  http://www.ebay.com/itm/142146207101

the image has 'Sold' emblazoned across it. And if you click on that image, it
takes you to the original listing, which says "Sold for: US$5,000".

Noel

Re: 11/35 on eBait

[Pontus Pihlgren]

On Mon, Oct 24, 2016 at 01:12:50PM +0200, Philipp Hachtmann wrote:
> 
> 
> On 10/19/2016 02:42 AM, Noel Chiappa wrote:
> >> From: Glen Slick
> >
> >>> Went unsold at $3500. Relisted, this time at $5000.
> >
> >> there was a taker for that 11/35 at $5000 today
> >
> >Smack me with a wet halibut. They must not have seen the original listing?
> >
> >I can't come up with any other explanation why someone would pass up a chance
> >to buy it for $3.5K, and pay $1.5 more for the priviledge...
> 
> 
> Was it really sold? I can't figure that out from here. Only "listing has
> ended". And when I try to search for it, the website doesn't show it :-(
> 

Looks like it:

http://www.ebay.com/itm/DEC-PDP-11-35-COMPUTER-/142146207101?

(ebay will usually tell you "the seller has relisted this item" and if 
you click it you get the above url)

/P

Re: 11/35 on eBait

[Philipp Hachtmann]

On 10/19/2016 02:42 AM, Noel Chiappa wrote:

> From: Glen Slick

>> Went unsold at $3500. Relisted, this time at $5000.

> there was a taker for that 11/35 at $5000 today

Smack me with a wet halibut. They must not have seen the original listing?

I can't come up with any other explanation why someone would pass up a chance
to buy it for $3.5K, and pay $1.5 more for the priviledge...



Was it really sold? I can't figure that out from here. Only "listing has 
ended". And when I try to search for it, the website doesn't show it :-(