14 Oct
2012
14 Oct
'12
10:42 a.m.
> [...non-ancient disk on Unibus machines...]
I'm surely not the only collector who would be willing to pony up
some $$$ for such a project.... 
14 Oct
14 Oct
10:58 a.m.
On Sun, Oct 14, 2012 at 1:42 PM, js at cimmeri.com <js at cimmeri.com> wrote:
What makes IDE to Qbus or Unibus interfacing so
difficult? There must be
reasons, otherwise it would have been done by now.
Oddball bus interface chips on the hardware side, and either
completely emulating an existing DEC (or 3rd party) controller's
registers and functionality or creating a new controller and being
prepared to write drivers for every DEC OS known to man.
-ethan
12:37 p.m.
On 10/14/2012 01:58 PM, Ethan Dicks wrote:
On Sun, Oct 14, 2012 at 1:42 PM, js at cimmeri.com
<js at cimmeri.com> wrote:
The bus interface side is not that hard for non-dma (slower PIO)
and hust a bit more for DMA. However Ethan hit the nail on the head
with driers for whatever is done.
The best known is a Q-bus IDE (could also use CF) interface that
likely worked fine but the list of Qbus OSs that would need
support was huge. The hardware was by Qbus standards trivial.
PDP-11/Qbus includes RT11, RSTS, RSX-11, Unix(many)
Then we have MicroVAX, VMS, Ultrix, Netbsd.. Others?
The hardware was never the show stopper it was software to use it.
There are a few that are easy to simulate one being the TU58 tape.
That interfaced via serial port. Its been done in the past. The serial
interface limits speed but it beat the real tape by a mile.
Another might the RL, RS, or RM disks, simulated the interface and
registers and use a MPU to do the heavy lifting to a 64 or 256b
Solid state simulation of a disk using flash or other technology.
In the end it would be to identify the disks common to all those OSs
(other MSPC)
and create a controller that simulates that. MSPC has to many copyright
and
other ropes and chains to hurdle plus its largely black box. It's
also an interface
that requires a micro as it's locally intelligent (T-11 used in the past).
But for the moment is a SCSI adaptor that has MSPC (CMD etal) is the
easy way out.
Allison
What makes IDE to Qbus or Unibus interfacing so
difficult? There must be
reasons, otherwise it would have been done by now.
Oddball bus interface chips on
the hardware side, and either
completely emulating an existing DEC (or 3rd party) controller's
registers and functionality or creating a new controller and being
prepared to write drivers for every DEC OS known to man.
-ethan
12:48 p.m.
From: "Ethan Dicks" <ethan.dicks at gmail.com>
Sent: Sunday, October 14, 2012 7:58 PM
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Subject: Re: unibus to modern disk interface?
On Sun, Oct 14, 2012 at 1:42 PM, js at cimmeri.com
<js at cimmeri.com> wrote:
There are plenty of simple boards and they all have the bus driver /
receiver
chips on them. Why not try to de-solder the chips from one of those boards?
After de-soldering you can do a test to see whether all ports are still OK.
Or is there a flaw in this reasoning?
- Henk, PA8PDP
What makes IDE to Qbus or Unibus interfacing so
difficult? There must be
reasons, otherwise it would have been done by now.
Oddball bus interface chips on the hardware side, and either
completely emulating an existing DEC (or 3rd party) controller's
registers and functionality or creating a new controller and being
prepared to write drivers for every DEC OS known to man.
-ethan 
2:36 p.m.
On 10/14/2012 03:48 PM, Henk Gooijen wrote:
There are plenty of simple boards and they all have
the bus driver /
receiver
chips on them. Why not try to de-solder the chips from one of those boards?
After de-soldering you can do a test to see whether all ports are still OK.
Or is there a flaw in this reasoning?
Well:
- you'd be destroying otherwise-potentially-useful boards
- such boards are in limited supply
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
10:58 a.m.
On 10/14/2012 01:42 PM, js at cimmeri.com wrote:
There are a few obstacles. While none of them are "big" ones, they
all add up.
The biggest issue is that the people with enough time to do it seem to
usually not be the people with the required skillset.
Then there's a technical obstacle of bus driver chips that match Qbus
or Unibus specs. There just aren't any ideal choices that are available
now. There's an easy way around that, but then you're back to the
availability of time.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
> >>
[...non-ancient disk on Unibus machines...]
>
> I'm surely not the only collector who would be willing to pony up
> some $$$ for such a project....
I would certainly pony up some $.
I built my own IDE->S-100 interface (with guidance from my amazing
friend, Allison P); it was very easy, hardware-wise.
What makes IDE to Qbus or Unibus interfacing so difficult? There must
be reasons, otherwise it would have been done by now. 
11:39 a.m.
On Oct 14, 2012, at 1:58 PM, Dave McGuire wrote:
On 10/14/2012 01:42 PM, js at cimmeri.com wrote:
There are a few obstacles. While none of them are "big" ones, they
all add up.
The biggest issue is that the people with enough time to do it seem to
usually not be the people with the required skillset.
Then there's a technical obstacle of bus driver chips that match Qbus
or Unibus specs. There just aren't any ideal choices that are available
now. There's an easy way around that, but then you're back to the
availability of time.
Those are exactly my issues. I've been wanting to make a QBUS
version of same for a long time now, and I certainly have the
skills, but my tuit supply is exhausted.
And the driver chips are a BIG problem. Probably the best
equivalents available now are the 74AS640 and 74AS760, but
they're really heavy hitters and would probably cause
unacceptable ringing on a really long bus. They'd most
likely be OK in a small QBUS enclosure, but I think a long
unibus system would be problematic. Anyone have any more
recent experience?
Nothing matches DEC's specs anymore, for probably obvious
reasons. The best I ever saw were some of the later NS
parts, which actually had an integrator on the output to
do slew-rate limiting. You could build something appropriate
out of discretes and op amps, but the amount of board space
you'd burn would murder you.
- Dave
>>> [...non-ancient disk on Unibus machines...]
>
> I'm surely not the only collector who would be willing to pony up
> some $$$ for such a project....
I would certainly pony up some $.
I built my own IDE->S-100 interface (with guidance from my amazing
friend, Allison P); it was very easy, hardware-wise.
What makes IDE to Qbus or Unibus interfacing so difficult? There must
be reasons, otherwise it would have been done by now.
11:52 a.m.
On 10/14/2012 02:39 PM, David Riley wrote:
I don't think so. I've been thinking about this off-and-on for a few
years now. Yes, you'd need to spend some board space, but with more
modern high-integration components for the rest of the functionality (on
the other side of the bus interface) one really doesn't need to have all
THAT much board real estate left over. I think it could be done with a
couple of transistors per line, and using even relatively large SOT-23
packages, one would likely burn less than 1/3 of the board and still be
in the single-transistor-per-package realm.
I really don't think this would be all that tough to do with
discretes, either in terms of technical difficulty or board space
requirements.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
Then
there's a technical obstacle of bus driver chips that match Qbus
or Unibus specs. There just aren't any ideal choices that are available
now. There's an easy way around that, but then you're back to the
availability of time.
Those are exactly my issues. I've been wanting to make a QBUS
version of same for a long time now, and I certainly have the
skills, but my tuit supply is exhausted.
And the driver chips are a BIG problem. Probably the best
equivalents available now are the 74AS640 and 74AS760, but
they're really heavy hitters and would probably cause
unacceptable ringing on a really long bus. They'd most
likely be OK in a small QBUS enclosure, but I think a long
unibus system would be problematic. Anyone have any more
recent experience?
Nothing matches DEC's specs anymore, for probably obvious
reasons. The best I ever saw were some of the later NS
parts, which actually had an integrator on the output to
do slew-rate limiting. You could build something appropriate
out of discretes and op amps, but the amount of board space
you'd burn would murder you. 
11:47 a.m.
-----Original Message-----
From: cctalk-bounces at classiccmp.org [mailto:cctalk-
bounces at classiccmp.org] On Behalf Of Dave McGuire
Sent: 14 October 2012 18:59
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: unibus to modern disk interface?
On 10/14/2012 01:42 PM, js at cimmeri.com wrote:
There are a few obstacles. While none of them are "big" ones, they all
add
>
>> [...non-ancient disk on Unibus machines...]
>
> I'm surely not the only collector who would be willing to pony up
> some $$$ for such a project....
I would certainly pony up some $.
I built my own IDE->S-100 interface (with guidance from my amazing
friend, Allison P); it was very easy, hardware-wise.
What makes IDE to Qbus or Unibus interfacing so difficult? There must
be reasons, otherwise it would have been done by now. up.
The biggest issue is that the people with enough time to do it seem to
usually not be the people with the required skillset.
Then there's a technical obstacle of bus driver chips that match Qbus or
Unibus specs. There just aren't any ideal choices that are available now.
There's an easy way around that, but then you're back to the availability
of
time.
I have heard the problem with driver chips before. I don't know enough
electronics really, but could it be done with discrete components?
My own "plan" is to emulate the raw hard disks instead of the controllers
(certainly for DEC RD53/54 which are the ones I most want to emulate). One
day, when I get time, and when I find someone who can help me with the
hardware design.
Regards
Rob
12:08 p.m.
On 10/14/2012 02:47 PM, Rob Jarratt wrote:
Of course. Anything done with chips can also be done with discrete
components.
-----Original
Message-----
I have heard the problem with driver chips before. I don't know
enough
electronics really, but could it be done with discrete components? My own "plan" is to emulate the raw hard
disks instead of the controllers
(certainly for DEC RD53/54 which are the ones I most want to emulate). One
day, when I get time, and when I find someone who can help me with the
hardware design.
That would also be a tough proposition, but not impossible.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
12:55 p.m.
On 10/14/2012 1:08 PM, Dave McGuire wrote:
On 10/14/2012 02:47 PM, Rob Jarratt wrote:
Of course. Anything done with chips can also be done with discrete
components.
Does the hardware still match the old buses specs? Using thru-the-hole
older components how much under the spec are they since I am guessing
they where developed in the era of 4K core memory and several feet of busing
between rack units. If newer hardware components are used for memory
can a reduced bus spec be developed saving the older hardware for places
that need original components.
Ben.
-----Original Message-----
I have heard the problem with driver chips before. I
don't know enough
electronics really, but could it be done with discrete components?
2:35 p.m.
On 10/14/2012 03:55 PM, ben wrote:
Of course. Anything done with chips can also be done with discrete
components.
Does the hardware still match the old buses specs?
What hardware? We're talking about *designing* the hardware. We can
make pretty much any type of line driver with a couple of transistors.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
-----Original
Message-----
I have heard the problem with driver chips before. I don't know
enough
electronics really, but could it be done with discrete components?
3:01 p.m.
On 10/14/2012 05:50 PM, Eric Smith wrote:
Why? (if you want to go into it)
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
What hardware?
We're talking about *designing* the hardware. We can
make pretty much any type of line driver with a couple of transistors.
Actually, meeting the maximum leakage current spec is quite difficult.
3:34 p.m.
On 10/14/2012 4:01 PM, Dave McGuire wrote:
On 10/14/2012 05:50 PM, Eric Smith wrote:
>> What hardware? We're talking about *designing* the hardware. We can
>> make pretty much any type of line driver with a couple of transistors.
>
> Actually, meeting the maximum leakage current spec is quite difficult.
So how many standard loads will the bus drive with that leakage current,
after buss termination loading.
Why? (if you want to go into it)
-Dave
PS. Dave if I had a PDP-11 rather using a PDP-8 here and there I would know
all this stuff.
4:51 p.m.
On Oct 14, 2012, at 18:01, Dave McGuire <mcguire at neurotica.com> wrote:
On 10/14/2012 05:50 PM, Eric Smith wrote:
Why? (if you want to go into it)
I would certainly like to hear. Last I did the math in my head,
it didn't look that hard to do with discretes on the output
(BJTs) and a fairly high-impedance input.
- Dave
What
hardware? We're talking about *designing* the hardware. We can
make pretty much any type of line driver with a couple of transistors.
Actually, meeting the maximum leakage current spec is quite difficult. 
6:40 p.m.
I wrote:
meeting the maximum leakage current spec is quite
difficult.
Dave McGuire wrote:
Why? (if you want to go into it)
The requirements are basically:
Vol 0.7V max into 70 mA load
Vil max 1.3V
Vih min 1.7V
minimum 5 ns rise and fall times (10% to 90%)
80uA max leakage at 3.8V, 10uA max at 0V (with Vcc from 0.0V to 5.25V)
10pF max capacitance
My attempts to design anything that meets this failed on either the
leakage current, capacitive loading, or both. However, someone who is
more skilled with analog design could probably come up with something
satisfactory.
Even the National DS8641 and DS3662 didn't quite meet the requirements.
It is unclear whether the ones DEC used had been screened to better
specs (either by National or DEC).
15 Oct
15 Oct
6:04 a.m.
On Oct 14, 2012, at 9:40 PM, Eric Smith wrote:
I wrote:
Qbus is at least a little more forgiving (10uA max at low level seems a
bit odd for TTL, given that it's lower than Iih); drivers have a max
leakage of 25uA at 3.8v, while receivers have a max leakage of 80uA
over their input range. That's not impossible to achieve with some
discrete transistors; a 2N4401 fits the bill nicely for the output
stage (and meets the rise/fall time constraint).
I'd be more inclined to use a FET input stage or possibly even a
comparator to achieve the desired hysteresis and threshold voltage,
though a) I haven't thought about what the impedance effects of the
positive feedback would be, b) I've had a hard time finding good
comparators that work in the correct range and have a short enough
propagation delay, and c) a Schmitt trigger made with discretes is
probably a good enough solution.
I'd love to continue this discussion on or off the list if anyone is
seriously interested in developing new Unibus/Qbus boards. A
standard solution that is easily reproducible would help quite a few
people, I think.
- Dave
meeting the maximum leakage current spec is quite
difficult.
Dave McGuire wrote:
Why? (if you want to go into it)
The requirements are basically:
Vol 0.7V max into 70 mA load
Vil max 1.3V
Vih min 1.7V
minimum 5 ns rise and fall times (10% to 90%)
80uA max leakage at 3.8V, 10uA max at 0V (with Vcc from 0.0V to 5.25V)
10pF max capacitance 
11:31 a.m.
On 10/14/12 8:40 PM, Eric Smith wrote:
I wrote:
With a discrete design, the propagation delay is likely to go up. Is there
a maximum prop delay criteria?
meeting the maximum leakage current spec is quite
difficult.
Dave McGuire wrote:
Why? (if you want to go into it)
The requirements are basically:
Vol 0.7V max into 70 mA load
Vil max 1.3V
Vih min 1.7V
minimum 5 ns rise and fall times (10% to 90%)
80uA max leakage at 3.8V, 10uA max at 0V (with Vcc from 0.0V to 5.25V)
10pF max capacitance
My attempts to design anything that meets this failed on either the leakage current,
capacitive
loading, or both. However, someone who is more skilled with analog design could probably
come up
with something satisfactory.
Even the National DS8641 and DS3662 didn't quite meet the requirements. It is
unclear whether the
ones DEC used had been screened to better specs (either by National or DEC).
11:46 a.m.
On Oct 15, 2012, at 2:31 PM, Tom Uban wrote:
On 10/14/12 8:40 PM, Eric Smith wrote:
For Qbus, at least, the drivers and receivers are specced at 35 ns max prop
delay. That's not out of the question for a discrete BJT; a 2N4401 has
a Td of 15 ns, though you'd have to be careful not to saturate in order to
maintain decent switching times.
- Dave
I wrote:
With a discrete design, the propagation delay is likely to go up. Is there
a maximum prop delay criteria? meeting the maximum leakage current spec is quite
difficult.
Dave McGuire wrote:
Why? (if you want to go into it)
The requirements are basically:
Vol 0.7V max into 70 mA load
Vil max 1.3V
Vih min 1.7V
minimum 5 ns rise and fall times (10% to 90%)
80uA max leakage at 3.8V, 10uA max at 0V (with Vcc from 0.0V to 5.25V)
10pF max capacitance
My attempts to design anything that meets this failed on either the leakage current,
capacitive
loading, or both. However, someone who is more skilled with analog design could probably
come up
with something satisfactory.
Even the National DS8641 and DS3662 didn't quite meet the requirements. It is
unclear whether the
ones DEC used had been screened to better specs (either by National or DEC).
6:17 p.m.
On 10/15/2012 02:31 PM, Tom Uban wrote:
On 10/14/12 8:40 PM, Eric Smith wrote:
I understand the specs but, there are boards out there using standard
TTL in the form of LS244,
LS241, LS245 and I've interfaced to Q-bus using those. Whats the issue?
Hint if your building a multibackplane system then it _may_ be an issue.
The H11 boards (IO, memory and storage) use mostly regular parts. Same
for a lot of other non-DEC
vendors.
The key thing here is we are worrying only one board and even is the
leakage is a little high the system
will run as all the other boards are hopefully conforming.
The biggest issue is getting all of it on a quad or even a dual board.
With current modern Flash
and SD and CF devices the actual storage medium is a non issue.
Has any one considered this scsi to Flash/SD/CF memory emulating a
disk. This may be of interest
for those with SCSI and those getting scarce.
Me I planed ahead and kept all the small drives that people didn't want
but still ran from older
MFM and IDE to SCSI. That and old boards even if flagged dead.. they
can be fixed or used for parts.
Allison
I wrote:
With a discrete design, the propagation delay is likely to go up. Is there
a maximum prop delay criteria?
meeting the maximum leakage current spec is quite
difficult.
Dave McGuire wrote:
Why? (if you want to go into it)
The
requirements are basically:
Vol 0.7V max into 70 mA load
Vil max 1.3V
Vih min 1.7V
minimum 5 ns rise and fall times (10% to 90%)
80uA max leakage at 3.8V, 10uA max at 0V (with Vcc from 0.0V to 5.25V)
10pF max capacitance
My attempts to design anything that meets this failed on either the leakage current,
capacitive
loading, or both. However, someone who is more skilled with analog design could probably
come up
with something satisfactory.
Even the National DS8641 and DS3662 didn't quite meet the requirements. It is
unclear whether the
ones DEC used had been screened to better specs (either by National or DEC).
5:56 p.m.
>> Of course. Anything done with chips can also
be done with discrete
>> components.
> a "pentium" laptop ?
On Sun, 14 Oct 2012, Tothwolf wrote:
Since nobody said how big the board could be...
Multiple full AT sized
boards in a backplane for a luggable Pentium "laptop"? :)
battery life?
6:03 p.m.
On 14 October 2012 20:56, Fred Cisin <cisin at xenosoft.com> wrote:
Three fifths of a femtosecond?
>> Of
course. Anything done with chips can also be done with discrete
>> components.
> a "pentium" laptop ?
On Sun, 14 Oct 2012, Tothwolf wrote:
Since nobody said how big the board could be...
Multiple full AT sized
boards in a backplane for a luggable Pentium "laptop"? :)
battery life?
6:49 p.m.
On 10/14/2012 7:03 PM, Christian Gauger-Cosgrove wrote:
On 14 October 2012 20:56, Fred Cisin <cisin at
xenosoft.com> wrote:
Three fifths of a femtosecond?
No! the battery just explodes.
Ben.
>>
Of course. Anything done with chips can also be done with discrete
>> components.
> a "pentium" laptop ?
On Sun, 14 Oct 2012, Tothwolf wrote:
Since nobody said how big the board could be...
Multiple full AT sized
boards in a backplane for a luggable Pentium "laptop"? :)
battery life?
15 Oct
15 Oct
7:41 a.m.
On Sun, 14 Oct 2012, Fred Cisin wrote:
On Sun, 14 Oct 2012, Tothwolf wrote:
I dunno... most P5 based laptops only got what, 30-45 minutes of actual
run-time anyway, and you could fit a couple of decent sized SLAs into a
luggable chassis without too much difficulty, so you should be able to get
at least a half hour or so easy ;)
Since nobody said how big the board could be...
Multiple full AT sized
boards in a backplane for a luggable Pentium "laptop"? :)
battery life?
10:04 a.m.
>> Since nobody said how big the board could
be... Multiple full AT sized
>> boards in a backplane for a luggable Pentium "laptop"? :)
> battery life?
On Mon, 15 Oct 2012, Tothwolf wrote:
I dunno... most P5 based laptops only got what, 30-45
minutes of actual
run-time anyway, and you could fit a couple of decent sized SLAs into a
luggable chassis without too much difficulty, so you should be able to get
at least a half hour or so easy ;)
You are going to need an electric vehicle Lithium Ion battery pack. Maybe
several.
Does it pass Ethan's "laptop" definition if you can't lift the battery?
10:17 a.m.
On 15 October 2012 13:04, Fred Cisin <cisin at xenosoft.com> wrote:
As long as when you strap said battery (or batteries as the case may
be) to your back your spine doesn't implode/exit your body at high
velocity, it can be categorized as a laptop.
>> Since
nobody said how big the board could be... Multiple full AT sized
>> boards in a backplane for a luggable Pentium "laptop"? :)
> battery life?
On Mon, 15 Oct 2012, Tothwolf wrote:
I dunno... most P5 based laptops only got what,
30-45 minutes of actual
run-time anyway, and you could fit a couple of decent sized SLAs into a
luggable chassis without too much difficulty, so you should be able to get
at least a half hour or so easy ;)
You are going to need an electric vehicle Lithium Ion battery pack. Maybe
several.
Does it pass Ethan's "laptop" definition if you can't lift the
battery?
10:38 a.m.
On Mon, Oct 15, 2012 at 1:04 PM, Fred Cisin <cisin at xenosoft.com> wrote:
Does it pass Ethan's "laptop" definition
if you can't lift the battery?
My laptop definition?!? I don't remember supplying one. How about...
o Small enough not to crush the user's lower limbs (weight)
o Doesn't run hot enough to ignite user's pants (thermal issues)
o No longer causes male sterility (EMI emissions)
Any other thresholds to cross?
-ethan
12:46 p.m.
On Mon, 15 Oct 2012, Ethan Dicks wrote:
On Mon, Oct 15, 2012 at 1:04 PM, Fred Cisin <cisin
at xenosoft.com> wrote:
I stand corrected!
It was EVAN who declared that a "laptop" MUST run on batteries.
--
Grumpy Ol' Fred cisin at xenosoft.com
Does it pass Ethan's "laptop"
definition if you can't lift the battery?
My laptop definition?!? I don't
remember supplying one. How about...
o Small enough not to crush the user's lower limbs (weight)
o Doesn't run hot enough to ignite user's pants (thermal issues)
o No longer causes male sterility (EMI emissions)
Any other thresholds to cross? 
1:04 p.m.
New subject: PLEASE CHANGE YOUR SUBJECT LINE (Re: unibus to modern disk interface?)
On 10/15/12 12:46 PM, Fred Cisin wrote:
It was EVAN who declared that a "laptop"
MUST run on batteries.
There were a couple of message I ACTUALLY CARED ABOUT on under this subject
today. Please have the courtesy, if you are going to continue posting
this crap, to CHANGE THE SUBJECT LINE
1:18 p.m.
New subject: PLEASE CHANGE YOUR SUBJECT LINE (Re: unibus to modern disk interface?)
> It was EVAN who declared that a
"laptop" MUST run on batteries.
On Mon, 15 Oct 2012, Al Kossow wrote:
There were a couple of message I ACTUALLY CARED ABOUT
on under this subject
today. Please have the courtesy, if you are going to continue posting
this crap, to CHANGE THE SUBJECT LINE
I apologize for my failure to properly label this tangent into completely
orthogonal subject matter, including the [in my opinion facinating]
discussion of just how impossible it would be to build current technology
(pentium laptop) using discrete components.
8:30 a.m.
On Oct 14, 2012, at 8:56 PM, Fred Cisin wrote:
A car battery should power that sort of thing for a reasonable amount
of time; you'd probably have to carry that in a backpack, but as long
as the major computing portion could fit on your lap (for a dubious
definition of "fit"), you could probably still call it a laptop.
- Dave
>> Of
course. Anything done with chips can also be done with discrete
>> components.
> a "pentium" laptop ?
On Sun, 14 Oct 2012, Tothwolf wrote:
Since nobody said how big the board could be...
Multiple full AT sized
boards in a backplane for a luggable Pentium "laptop"? :)
battery life?
9:44 a.m.
>>>> Of course. Anything done with chips
can also be done with discrete
>>>> components.
>>> a "pentium" laptop ?
>> Since nobody said how big the board could be... Multiple full AT sized
>> boards in a backplane for a luggable Pentium "laptop"? :)
> battery life?
On Mon, 15 Oct 2012, David Riley wrote:
A car battery should power that sort of thing for a
reasonable amount
of time;
for some very quick value of "reasonable".
you'd probably have to carry that in a backpack,
but as long
as the major computing portion could fit on your lap (for a dubious
definition of "fit"), you could probably still call it a laptop.
Is it still a "laptop", when it is tethered to a truck for power?
--
Grumpy Ol' Fred cisin at xenosoft.com
10:26 a.m.
On Oct 15, 2012, at 12:44 PM, Fred Cisin wrote:
Ah, yes, I did the math in my head and may have left off an order of
magnitude or 3. Assuming a 100-Ah battery (not abnormal for an
American-sized car, I guess) and a million transistors running a
steady 10mA each (not out of the question, but may be off by an order
of magnitude if you want it to run at any real speed):
100Ah / 10,000A = .01 hours = .6 minutes = 36 seconds
The real key would be to see whether you could boot to DOS before the
jumper cables set anything on fire.
Also, looking it up, the approximate transistor count of the Pentium
was 3 million, not 1 million, so perhaps it's really more like 10
seconds.
- Dave
>>>> Of course. Anything done with chips can also be done with discrete
>>>> components.
>>> a "pentium" laptop ?
>> Since nobody said how big the board could be... Multiple full AT sized
>> boards in a backplane for a luggable Pentium "laptop"? :)
> battery life?
On Mon, 15 Oct 2012, David Riley wrote:
A car battery should power that sort of thing for
a reasonable amount
of time;
for some very quick value of "reasonable". 
12:58 p.m.
>>>> Of course. Anything done with chips
can also be done with
discrete
>>>> components.
>>> a "pentium" laptop ?
>
> On Sun, 14 Oct 2012, Tothwolf wrote:
>> Since nobody said how big the board could be... Multiple full AT
>> sized boards in a backplane for a luggable Pentium "laptop"? :)
>
A Pentium 166 MMX chip, which was a common chip with mobility features
used in some early Pentium-based laptops uses roughly 4.5M transistors.
A little math (and this is all approximations and done conservatively)
shows what might result.
Such a CPU, using small-outline surface mount leadless transistors on
12x9 circuit boards with relatively tight design rules and multi-layer
boards, would take something like 32 boards just for the transistors.
Add in the overhead of other discrete components and you are looking at
something like 81 boards (assuming roughly 2.5 discrete components per
transistor). Not allowing any room for chassis, backplane, board
spacing (for cooling), cooling, and interconnect, the CPU alone would a
cube roughly 21 inches on a side. Add in overhead for the stuff listed,
you'd probably be looking at a cube 2 feet on each side. The CPU by
itself could probably be packed into some kind of backpack, but it'd be
heavy.
That's just for the CPU.
Then you'd need RAM, ROM, IDE storage interface, keyboard interface,
mouse interface, serial, parallel, floppy disk, a video subsystem, and
LCD panel. Just the electronics for all of these things, assuming the
use of ICs of the time rather than trying to make them all using
discrete components, and it's my guess that the result would be too
large and too heavy to carry...not even considering what it'd take to
power the beast.
If you tried to do everything with discrete components(except the hard
disk and LCD display) -- well...it'd be more like something (a pure
guess) like 12 or so 7-foot 19" datacenter racks full of boards, and the
interconnect would be a real nightmare. Power distribution and cooling
would be "interesting". Hardly laptop, much less "luggable".
1:14 p.m.
> > Of course. Anything done with chips can
also be done with
> > discrete components.
> a "pentium" laptop ?
On Mon, 15 Oct 2012, Rick Bensene wrote:
A Pentium 166 MMX chip, which was a common chip with
mobility features
used in some early Pentium-based laptops uses roughly 4.5M transistors.
Is it supported by current software?
Such a CPU, using small-outline surface mount leadless
transistors on
12x9 circuit boards with relatively tight design rules and multi-layer
boards, would take something like 32 boards just for the transistors.
Add in the overhead of other discrete components and you are looking at
something like 81 boards (assuming roughly 2.5 discrete components per
transistor). Not allowing any room for chassis, backplane, board
spacing (for cooling), cooling, and interconnect, the CPU alone would a
cube roughly 21 inches on a side. Add in overhead for the stuff listed,
you'd probably be looking at a cube 2 feet on each side. The CPU by
itself could probably be packed into some kind of backpack, but it'd be
heavy.
That's just for the CPU.
Then you'd need RAM, ROM, IDE storage interface, keyboard interface,
mouse interface, serial, parallel, floppy disk, a video subsystem, and
LCD panel. Just the electronics for all of these things, assuming the
use of ICs of the time rather than trying to make them all using
discrete components, and it's my guess that the result would be too
large and too heavy to carry...not even considering what it'd take to
power the beast.
If you tried to do everything with discrete components(except the hard
disk and LCD display) -- well...it'd be more like something (a pure
guess) like 12 or so 7-foot 19" datacenter racks full of boards, and the
interconnect would be a real nightmare. Power distribution and cooling
would be "interesting". Hardly laptop, much less "luggable".
Don't forget the interface to the 15 000 floppy drives!
Thank you for doing the math!
--
Grumpy Ol' Fred cisin at xenosoft.com
1:28 p.m.
A Pentium 166
MMX chip, which was a common chip with mobility
features used in some early Pentium-based laptops uses roughly 4.5M
transistors.
Is it supported by current software?
2:38 p.m.
New subject: unibus to Laptops...
On 10/15/2012 04:14 PM, Fred Cisin wrote:
I have a P166/mmx running current linux ( maxed on ram at 512mb)
no problem. Even a 486 runs linux still and XP!.
A 386 would easily fill several racks if discrete and t would clock at
maybe 5mhz.
If you did it the PDP-8 would look small same for the early PDP-8s.
Can we talk about the power supply... nah that would be silly.
Allison
>> Of
course. Anything done with chips can also be done with
>> discrete components.
> a "pentium" laptop ?
On Mon, 15 Oct 2012, Rick Bensene wrote:
A Pentium 166 MMX chip, which was a common chip
with mobility features
used in some early Pentium-based laptops uses roughly 4.5M transistors.
Is it
supported by current software?
Such a CPU,
using small-outline surface mount leadless transistors on
12x9 circuit boards with relatively tight design rules and multi-layer
boards, would take something like 32 boards just for the transistors.
Add in the overhead of other discrete components and you are looking at
something like 81 boards (assuming roughly 2.5 discrete components per
transistor). Not allowing any room for chassis, backplane, board
spacing (for cooling), cooling, and interconnect, the CPU alone would a
cube roughly 21 inches on a side. Add in overhead for the stuff listed,
you'd probably be looking at a cube 2 feet on each side. The CPU by
itself could probably be packed into some kind of backpack, but it'd be
heavy.
That's just for the CPU.
Then you'd need RAM, ROM, IDE storage interface, keyboard interface,
mouse interface, serial, parallel, floppy disk, a video subsystem, and
LCD panel. Just the electronics for all of these things, assuming the
use of ICs of the time rather than trying to make them all using
discrete components, and it's my guess that the result would be too
large and too heavy to carry...not even considering what it'd take to
power the beast.
If you tried to do everything with discrete components(except the hard
disk and LCD display) -- well...it'd be more like something (a pure
guess) like 12 or so 7-foot 19" datacenter racks full of boards, and the
interconnect would be a real nightmare. Power distribution and cooling
would be "interesting". Hardly laptop, much less "luggable".
Don't forget the interface to the 15 000 floppy drives!
Thank you for doing the math!
--
Grumpy Ol' Fred cisin at xenosoft.com
3:01 p.m.
>> Of course. Anything done with chips can
also be done with discrete
>> components.
> a "pentium" laptop ?
On Sun, 14 Oct 2012, Tothwolf wrote:
Since nobody said how big the board could be...
Multiple full AT sized
boards in a backplane for a luggable Pentium "laptop"? :)
battery life? 
4:42 p.m.
Most of the discussion on this that other people have brought up, is
why I liked Brad Parkers "udisk" approach so much. His design goals
were:
Create a low cost unibus adapter card which can emulate a small number
of popular controllers (RL11, UDA50, etc) and use an IDE or CF disk as
the actual media.
Make it easy for others to write personality modules for different
controllers.
Should allow use of a IDE/CF disk to boot a PDP-11 (or vax).
Specifically, I was enamored of the approach that allowed a user to
write their own personality module to change it from acting like a
SCSI controller vs. SDI vs. etc.... all via software. This would seem
to me to be the most functional approach for the most people.
I'll pony up a bounty of $300 to get someone to take those design
goals through to a kit form. Anyone want to add to the bounty? Or take
up the gauntlet? :)
J
5:17 p.m.
On Oct 15, 2012, at 7:42 PM, Jay West wrote:
Most of the discussion on this that other people have
brought up, is why I liked Brad Parkers "udisk" approach so much. His design
goals were:
Create a low cost unibus adapter card which can emulate a small number
of popular controllers (RL11, UDA50, etc) and use an IDE or CF disk as
the actual media.
Make it easy for others to write personality modules for different
controllers.
Should allow use of a IDE/CF disk to boot a PDP-11 (or vax).
Specifically, I was enamored of the approach that allowed a user to write their own
personality module to change it from acting like a SCSI controller vs. SDI vs. etc.... all
via software. This would seem to me to be the most functional approach for the most
people.
I'll pony up a bounty of $300 to get someone to take those design goals through to a
kit form. Anyone want to add to the bounty? Or take up the gauntlet? :)
I'd love to, but $300 is probably about enough to build a single board
in quantity 5 or so. If I do it, it's not going to be for money. :-)
However, something like a Kickstarter would at least be able to
guarantee the availability of funds to manufacture the damned thing,
which is what's hung me up in the past (now it's more the availability
of time, since I have a 13-month-old timesink who refuses to learn how
to solder).
Those are very much in line with my general design goals, though, as
well as a wide variety of media to interface. I'd be very interested
in working with someone to accomplish what I can't myself in a
reasonable amount of time.
- Dave
5:45 p.m.
Dave wrote....
I'd love to, but $300 is probably about enough to build a single board
in quantity 5 or so. If I do it, it's not going to be for money. :-)
My $300
offer was a bounty to get someone to do it, not for my
purchase of the final product. If others join in with bounty-uppers,
then maybe the initial funders get a small discount. All depends on
how the costs work out, but I'm not counting on any "discounts". Just
want to see it made available.
If you check the udisk page at heeltoe.com, you'll find he's got a
schematic and layout and somewhat detailed specs, supposedly already
working for an RL11. My guess is his project only needs some final
debugging/packaging as well as additional code for RK11, UDA50, etc.
The code download link doesn't work, maybe Brad could be convinced to
release it if he's not going to finish the project.
J
5:57 p.m.
On 15 October 2012 20:17, David Riley <fraveydank at gmail.com> wrote:
On Oct 15, 2012, at 7:42 PM, Jay West wrote:
If I can get some more money, I'd be willing to contribute -- for a
QBUS version though; preferably with the ability to be an RH11+disk
controller (workalike) with an RM05 or two.
What I'd really like to see is something that could replace a TM11 or
RH11+9-track tape drive controller and drives with modern CF or SD
cards instead. Would make it easier for those of us who don't have
9-track to install software off of 9-track.
-- C. M. Gauger-Cosgrove
Most of the discussion on this that other people
have brought up, is why I liked Brad Parkers "udisk" approach so much. His
design goals were:
Create a low cost unibus adapter card which can emulate a small number
of popular controllers (RL11, UDA50, etc) and use an IDE or CF disk as
the actual media.
Make it easy for others to write personality modules for different
controllers.
Should allow use of a IDE/CF disk to boot a PDP-11 (or vax).
Specifically, I was enamored of the approach that allowed a user to write their own
personality module to change it from acting like a SCSI controller vs. SDI vs. etc.... all
via software. This would seem to me to be the most functional approach for the most
people.
I'll pony up a bounty of $300 to get someone to take those design goals through to a
kit form. Anyone want to add to the bounty? Or take up the gauntlet? :)
I'd love to, but $300 is probably about enough to build a single board
in quantity 5 or so. If I do it, it's not going to be for money. :-)
However, something like a Kickstarter would at least be able to
guarantee the availability of funds to manufacture the damned thing,
which is what's hung me up in the past (now it's more the availability
of time, since I have a 13-month-old timesink who refuses to learn how
to solder).
Those are very much in line with my general design goals, though, as
well as a wide variety of media to interface. I'd be very interested
in working with someone to accomplish what I can't myself in a
reasonable amount of time.
- Dave
6:46 p.m.
On Oct 15, 2012, at 8:57 PM, Christian Gauger-Cosgrove wrote:
If I can get some more money, I'd be willing to
contribute -- for a
QBUS version though; preferably with the ability to be an RH11+disk
controller (workalike) with an RM05 or two.
I only have a QBUS machine, so I'd be developing for that. However,
Unibus has very similar drivers, and I imagine the circuitry for the
board would be 90% identical. My general plan was for an FPGA or
CPLD for the bus management with a microcontroller for the meat of
the controller (the "personality"), which has the benefits of making
the software separable from the underlying bus and also making
modules writeable by anyone with access to a GCC stack, not just
people with FPGA software licenses.
What I'd really like to see is something that
could replace a TM11 or
RH11+9-track tape drive controller and drives with modern CF or SD
cards instead. Would make it easier for those of us who don't have
9-track to install software off of 9-track.
That's the sort of thing any of these types of systems would excel
at. My end goal is to build a card that can be ANY QBUS card (CPU,
memory, peripheral, etc), but baby steps. Among other things, that
requires a lot more pin real estate on the controller for both
directions of most of the signals. A disk/tape/other peripheral
emulator (like udisk) is a somewhat easier first target.
- Dave
7:09 p.m.
New subject: Amassing components for: unibus^W QBus to modern disk interface?
On 15/10/12 9:46 PM, David Riley wrote:
... My end goal is to build a card that can be ANY QBUS card (CPU,
memory, peripheral, etc), but baby steps. Among other things, that
requires a lot more pin real estate on the controller for both
directions of most of the signals. A disk/tape/other peripheral
emulator (like udisk) is a somewhat easier first target.
So... Did any of the people who want one of these, buy Holm Tiffe's
prototyping blank????????????
"This is the last call for Orders. The Price for the PCBs is down to
21 Euros/PCB." (9 Feb 2012)
(I did. Hope it was a useful investment :)
--Toby
- Dave
8:38 p.m.
New subject: Amassing components for: unibus^W QBus to modern disk interface?
On 15 October 2012 22:09, Toby Thain <toby at telegraphics.com.au> wrote:
On 15/10/12 9:46 PM, David Riley wrote:
Not me, since I can't do anything electronics related except use said
electronics.
Not that I don't want to learn, but I just haven't had the time nor
inclination, yet.
-- Christian
... My end goal is to build a card that can be ANY QBUS card (CPU,
memory, peripheral, etc), but baby steps. Among other things, that
requires a lot more pin real estate on the controller for both
directions of most of the signals. A disk/tape/other peripheral
emulator (like udisk) is a somewhat easier first target.
So... Did any of the people who want one of these, buy Holm Tiffe's
prototyping blank????????????
"This is the last call for Orders. The Price for the PCBs is down to 21
Euros/PCB." (9 Feb 2012)
(I did. Hope it was a useful investment :)
--Toby
>
> 
10:21 p.m.
New subject: Amassing components for: unibus^W QBus to modern disk interface?
what card?
On Mon, Oct 15, 2012 at 10:38 PM, Christian Gauger-Cosgrove <
captainkirk359 at gmail.com> wrote:
On 15 October 2012 22:09, Toby Thain <toby at
telegraphics.com.au> wrote:
On 15/10/12 9:46 PM, David Riley wrote:
Not me, since I can't do anything electronics related except use said
electronics.
Not that I don't want to learn, but I just haven't had the time nor
inclination, yet.
-- Christian
... My end goal is to build a card that can be ANY QBUS card (CPU,
memory, peripheral, etc), but baby steps. Among other things, that
requires a lot more pin real estate on the controller for both
directions of most of the signals. A disk/tape/other peripheral
emulator (like udisk) is a somewhat easier first target.
So... Did any of the people who want one of these, buy Holm Tiffe's
prototyping blank????????????
"This is the last call for Orders. The Price for the PCBs is down to 21
Euros/PCB." (9 Feb 2012)
(I did. Hope it was a useful investment :)
--Toby
>
>
16 Oct
16 Oct
1:29 p.m.
-----Original Message-----
From: cctalk-bounces at classiccmp.org [mailto:cctalk-
bounces at classiccmp.org] On Behalf Of Jay West
Sent: 16 October 2012 00:43
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: unibus to modern disk interface?
Most of the discussion on this that other people have brought up, is why I
liked Brad Parkers "udisk" approach so much. His design goals
were:
Create a low cost unibus adapter card which can emulate a small number of
popular controllers (RL11, UDA50, etc) and use an IDE or CF disk as the
actual media.
Make it easy for others to write personality modules for different
controllers.
Should allow use of a IDE/CF disk to boot a PDP-11 (or vax).
Specifically, I was enamored of the approach that allowed a user to write
their own personality module to change it from acting like a SCSI
controller
vs. SDI vs. etc.... all via software. This would seem
to me to be the most
functional approach for the most people.
I'll pony up a bounty of $300 to get someone to take those design goals
through to a kit form. Anyone want to add to the bounty? Or take up the
gauntlet? :)
J
I think there are actually two approaches, depending on what hardware you
have already.
The first is the udisk approach. That allows you to emulate any card for the
bus that the card is designed for. You would need different cards for Unibus
and for Qbus, and I suspect for some protocols like MSCP it the software
might be hard to write, not well documented etc.
The second is to emulate at the disk interface. For example the MFM
interface for RD53/54 like I am interested in, or SCSI. In this case you
need different cards for different interface technologies but could use
existing controller. I like this approach more because you have more of the
original hardware, but recognise that not everyone will have that hardware
(I have a few RQDX3, one KZQSA, but I don't have, and really want, a KFQSA).
I have a few RD53/54 that will last me a while but when they are gone they
are gone, and I find it increasingly hard to find sub 1GB 50-pin SCSI, so I
want to emulate at that level. Don't have the design ability really but I
may try to breadboard something some day. I think this solution may also be
easier to get parts for, particularly the line drivers, which seem to be
hard for Qbus.
Regards
Rob
2:54 p.m.
On 16 October 2012 16:29, Rob Jarratt <robert.jarratt at ntlworld.com> wrote:
Hmm...
In terms of a "udisk" board, instead of re-inventing the wheel and
trying to rediscover all of the various controller information, could
one not attempt to reuse code from a software emulation of said
device? In other words, doing something like abusing the code of
SIMH's RQ, or RL driver into something usable by the electronics on
the board as a definition of the controller. If that could work, you
could easily cut down on the needing to re-invent the wheel with
regards to figuring out protocols. (Since if the protocol wasn't
written correctly enough for the emulator, software wouldn't run
correctly, or at all.)
Hmm... actually...
This is probably an unworkable idea, but I'll throw it out there any way...
How difficult a job would it be to "rip out" the CPU/bus
controller/memory code of SIMH, and replace it with an interface to a
real bus controller/listener program? This way you could keep the
already written and functional-in-the-eyes-of-the-original-software
device code, and you get a small plethora of devices.
If one wanted to have a nearly "truly universal" controller card, you
could make the card a relatively dumb device, with only the logic to
interface between the program and the QBUS/UNIBUS in the card, while
you have a bastardized SIMH sitting on a separate computer which let's
you have the machine see any controller you so choose to enable (11/83
with DECtape any one?).
Of course, that's just an idea, and probably a lousy one at that. But
I'm just putting it out there, since it popped into my head.
Cheers,
Christian
-----Original
Message-----
From: cctalk-bounces at classiccmp.org [mailto:cctalk-
bounces at classiccmp.org] On Behalf Of Jay West
Sent: 16 October 2012 00:43
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: unibus to modern disk interface?
Most of the discussion on this that other people have brought up, is why I
liked Brad Parkers "udisk" approach so much. His design goals
were:
Create a low cost unibus adapter card which can emulate a small number of
popular controllers (RL11, UDA50, etc) and use an IDE or CF disk as the
actual media.
Make it easy for others to write personality modules for different
controllers.
Should allow use of a IDE/CF disk to boot a PDP-11 (or vax).
Specifically, I was enamored of the approach that allowed a user to write
their own personality module to change it from acting like a SCSI
controller
vs. SDI vs. etc.... all via software. This would
seem to me to be the most
functional approach for the most people.
I'll pony up a bounty of $300 to get someone to take those design goals
through to a kit form. Anyone want to add to the bounty? Or take up the
gauntlet? :)
J
I think there are actually two approaches, depending on what hardware you
have already.
The first is the udisk approach. That allows you to emulate any card for the
bus that the card is designed for. You would need different cards for Unibus
and for Qbus, and I suspect for some protocols like MSCP it the software
might be hard to write, not well documented etc.
The second is to emulate at the disk interface. For example the MFM
interface for RD53/54 like I am interested in, or SCSI. In this case you
need different cards for different interface technologies but could use
existing controller. I like this approach more because you have more of the
original hardware, but recognise that not everyone will have that hardware
(I have a few RQDX3, one KZQSA, but I don't have, and really want, a KFQSA).
I have a few RD53/54 that will last me a while but when they are gone they
are gone, and I find it increasingly hard to find sub 1GB 50-pin SCSI, so I
want to emulate at that level. Don't have the design ability really but I
may try to breadboard something some day. I think this solution may also be
easier to get parts for, particularly the line drivers, which seem to be
hard for Qbus.
Regards
Rob
4:56 p.m.
On Oct 16, 2012, at 17:54, Christian Gauger-Cosgrove <captainkirk359 at gmail.com>
wrote:
In terms of a "udisk" board, instead of
re-inventing the wheel and
trying to rediscover all of the various controller information, could
one not attempt to reuse code from a software emulation of said
device? In other words, doing something like abusing the code of
SIMH's RQ, or RL driver into something usable by the electronics on
the board as a definition of the controller. If that could work, you
could easily cut down on the needing to re-invent the wheel with
regards to figuring out protocols. (Since if the protocol wasn't
written correctly enough for the emulator, software wouldn't run
correctly, or at all.)
That's certainly what I'd planned to do as a start (or at least
use SIMH's MSCP implementation as a guideline if it's not
directly usable).
How difficult a job would it be to "rip out"
the CPU/bus
controller/memory code of SIMH, and replace it with an interface to a
real bus controller/listener program? This way you could keep the
already written and functional-in-the-eyes-of-the-original-software
device code, and you get a small plethora of devices.
Things like that certainly exist commercially (I'd
provide links, but I'm on my phone). It typically requires
something rather low-latency, like an ISA or PCI card
on the host end; something like USB just has too long
a latency to be useful. My proposition for my card is
(for simple devices, anyway) a microcontroller attached
to an FPGA or CPLD which provides a thin QBUS/UNIBUS
transaction layer. This is how a lot of controllers were
implemented back in the day, only somewhat less integrated; the onboard micro responds to
bus transactions as an interrupt service routine. This
allows you to pretty fully decouple the controller logic
from the somewhat-more-static FPGA/CPLD design.
- Dave
16 Nov
16 Nov
11:20 a.m.
New subject: udisk v0.3 up and running (generic unibus disk interface)
I've been away from my addiction^H^H^H^Hhobby for a 3-4 years now, but
this summer I got rid of my
old consulting office and moved everything into my living room
(temporarily :-)
Since the move I've been slowly trying to clean up old projects.
One of them was the udisk disk controller emulator.
In 2006-2008 I build a 4 layer prototype. The PCB had some flaws on the
power plane, so I had to add a lot of wires for power but it basically
worked. It has an ARM (atmel sam7s) and a CPLD on it as well as
"correct" Unibus interface hardware. In 2008 I dabbled with it but
never really got it stable. It would barely boot RT11.
This fall I finally got serious. I dusted off the board and plugged it
into my 11/34a. I used a logic analyzer and an arm jtag pod and really
debugged it. I fixed a bunch of little issues in the CPLD state
machines and cleaned up the arm code to be "correct" and took out all
the hacks. The result is it's stable now and appears to be working
correctly. The bus transactions look correct and clean.
As a result, with RL02 emulation I can now boot all the images I have,
which include RT11, RSTS V7.2, XXDP 2.5 and BSD 2.9. I also did an RK05
emulation, which used to work but I have not tried it again. I will
shortly.
I am itching to try bigger disks, so I might try a MSCP, we'll see.
Those 2Gb CF disks... And I should run the XXDP diags on the
controller. That should be interesting.
I updated the docs on http://www.heeltoe.com and included the source
code for the firmware as well as the CPLD rtl and testbench. I also
updated the schematic pdf.
My plan is to do a little more testing and then fab another 4x PCB's;
Hopefully this time I won't botch the gerbers and the power plane (which
is split 3 ways) wont' be completely disconnected (which is better than
completely shorted, I might add, something I've also done once :-)
It's been a fun project. I was tempted to update it but I think it's
fine as it stands. All of the parts are available via digikey, which is
one of my 'rules'. A lot more could be done with the firmware. The
CPLD has a tiny amount of wiggle room, but it's pretty full.
Going forward I plan to do some interface projects with the "mojo" FPGA
board, like a pertec tape emulator and a RL02 emulator, just for fun,
but I wanted to finish this up first.
Once I have the new boards working, I plan to make up 2 "loaner" boards
- I'll like someone with an older machine like an 11/05 or an 11/70 or
11/45 to try them out if they are game. And if of course I'm willing
to sell them at basically cost if anyone wants them. With small quanity
pcb runs the PCB's tend to be the most expensive part. I think the PCB
+ parts was about $300. As I recall I have new unibus interface chips
for about 5x boards. I also have a number of scrap boards which I think
I can use to "harvest" interface chips. I could also check the gray
market again, who knows.
-brad
11:28 a.m.
New subject: udisk v0.3 up and running (generic unibus disk interface)
On Sat, 16 Nov 2013, Brad Parker wrote:
Once I have the new boards working, I plan to make up
2 "loaner" boards - I'll
like someone with an older machine like an 11/05 or an 11/70 or 11/45 to try
them out if they are game. And if of course I'm willing to sell them at
basically cost if anyone wants them. With small quanity pcb runs the PCB's
tend to be the most expensive part. I think the PCB + parts was about $300.
As I recall I have new unibus interface chips for about 5x boards. I also
have a number of scrap boards which I think I can use to "harvest" interface
chips. I could also check the gray market again, who knows.
-brad
What about someone with an 11/44?
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
12:59 p.m.
New subject: udisk v0.3 up and running (generic unibus disk interface)
On Nov 16, 2013, at 11:28 , Cory Smelosky <b4 at gewt.net> wrote:
What about someone with an 11/44?
From his pictures, it looks like he already has an
11/44, and is looking for older machine owners for compatibility testing. That's just
my guess.
I just got my first PDP-11 hardware very recently: Four 11/44 chassis, with about 1.9
CPU's worth of boards between them. I hope to make one working system out of them. I
would like to mate it up with a real RL02 someday, but this emulation board also looks
like a great option! I think that I'm likely to want to buy or make one when it's
ready for general consumption.
--
Mark J. Blair, NF6X <nf6x at nf6x.net>
http://www.nf6x.net/
19 Nov
19 Nov
5:01 p.m.
New subject: udisk v0.3 up and running (generic unibus disk interface)
On 11/16/13 2:28 PM, Cory Smelosky wrote:
...
What about someone with an 11/44?
(sorry, I've got teenagers; and they make keeping up with cctalk harder :-)
I have an 11/44 as well, so I do plan to test with it. I originally
began my testing on the 11/44 and found that the unibus transactions
were a little "odd" and it was *very* sensitive to bus timing and timed
out very quickly, which was frustrating. I switched to the 11/34a this
time thinking it would be a little more traditional and a little slower.
What I saw on the 11/44 may have all been due to my bugs, however, so I
will have another go at it shortly. My other unibus machine is an
11/730 and I'll give that try as well. If I can get all three to work
then there is hope I can get it to work with a KS-10 (which I don't own)
- my guess is will be the fastest and least forgiving.
I found my cache of new-in-the-tube unibus interface chips the other day
- time to make an inventory.
-brad
6:25 p.m.
New subject: udisk v0.3 up and running (generic unibus disk interface)
From: Al Kossow
Sent: Tuesday, November 19, 2013 5:10 PM
On 11/19/13 5:01 PM, Brad Parker wrote:
> I can get it to work with a KS-10
You'll have fun with that. Weren't 18 bit
Massbus disks the only
supported drives ?
That's correct, but then, you'd expect that, right?
RSX-20F, the version of RSX-11M that ran on the front end of a KL-10
(an 11/40), was pretty much stock for an unmapped system, but the
device handlers have a switch in the code which makes it use 18-bit
rather than 16-bit media. That way, the front end file system can
live on the same disk as the -10 boots from.
Rich
Rich Alderson
Vintage Computing Sr. Systems Engineer
Living Computer Museum
2245 1st Avenue S
Seattle, WA 98134
mailto:RichA at LivingComputerMuseum.org
http://www.LivingComputerMuseum.org/
6:59 p.m.
New subject: udisk v0.3 up and running (generic unibus disk interface)
Al Kossow <aek at bitsavers.org> wrote:
On 11/19/13 5:01 PM, Brad Parker wrote:
TOPS-10 included RX211 drivers (un)support:
http://pdp-10.trailing-edge.com/BB-F494Z-DD_1986/01/10,7/rx20.ins.html
RX20 (un)support package for TOPS-10 7.03
Contents, Installation Instructions, and General Cautions
RX20 (un)support allows TOPS-10 running on a KS20 (2020) system to (un)support
up to 2 RX211 floppy disk controllers, with up to 2 RX02 drives on each
controller. The (un)support provided is that of a non-file-structured device.
Some preliminary utilities are provided which may read DOS (or KLDCP or
RXDP) and RT format floppys.
http://pdp-10.trailing-edge.com/BB-F494Z-DD_1986/01/10,7/rx20.doc.html
CHAPTER 1
FLOPPY DISKETTES (RXA:)
Diskettes are block-addressable devices, each of which
contains 77 tracks of 26 sectors each. No file structure is
defined by the TOPS-10 monitor, although it is possible for
a user-mode program to define a file structure.
http://pdp-10.trailing-edge.com/BB-F494Z-DD_1986/01/10,7/rx2ser.mac.html
Title RX2SER -- RX20 Floppy Diskette Service for KS10s V006
Subttl Timothe Litt 11-NOV-85
http://pdp-10.trailing-edge.com/BB-F494Z-DD_1986/01/10,7/rtflx.hlp.html
RTFLX is a utility that allows a DECsystem-10 to read and write files on
RT-11 floppy disks and DECtapes. RTFLX can translate ASCII, PDP-11
binary, and DECsystem-10 binary files to and from RT-11 format. In
addition, RTFLX can initialize RT-11 media, and can format floppys.
RTFLX supports TD10 DECtapes, and RX20 floppy disks (2020 only).
I can get it to work with a KS-10
You'll have fun with that. Weren't 18 bit Massbus disks the only supported drives
?
7:04 p.m.
New subject: udisk v0.3 up and running (generic unibus disk interface)
On 11/19/13 6:59 PM, Phil Budne wrote:
Al Kossow <aek at bitsavers.org> wrote:
Thanks for being pedantic.
You're not going to run TOPS-10 off floppies.
On 11/19/13 5:01 PM, Brad Parker wrote:
TOPS-10 included RX211 drivers (un)support:
I can get it to work with a KS-10
You'll have fun with that. Weren't 18 bit Massbus disks the only supported drives
?
7:16 p.m.
New subject: udisk v0.3 up and running (generic unibus disk interface)
On Wed, 20 Nov 2013, Al Kossow wrote:
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
On 11/19/13 6:59 PM, Phil Budne wrote:
Not even a very, very tiny monitor?!
Al Kossow <aek at bitsavers.org> wrote:
Thanks for being pedantic.
You're not going to run TOPS-10 off floppies.
On 11/19/13 5:01 PM, Brad Parker wrote:
TOPS-10 included RX211 drivers (un)support:
I can get it to work with a KS-10
You'll have fun with that. Weren't 18 bit Massbus disks the only supported
drives ?
17 Nov
17 Nov
1:48 a.m.
New subject: udisk v0.3 up and running (generic unibus disk interface)
Brad,
first, congrats with this great result.
I read the web page and noticed one line which is not in your post.
It can also act as a boot ROM or generic RAM.
Now, those last two words make the board even more interesting.
With current (static) RAM chip sizes, can you have 256 KW RAM
on the board too? That makes the PDP-11 system even smaller,
because the RL11 and (all) memory boards are just one single
board! (I admit, I have not looked at the PDF or schematics).
256 KW would be too much for the 11/05, and I am not sure it
would work in an 11/70. But it would be nice in an 11/34 or /40.
Given the size of your card, would it fit in an 11/20? That would
be great, because the RL11 does not fit in the CPU box, and
I do not have memory for my 11/20 ...
I hope more people find this sufficiently interesting and order
a board. That would bring the cost down a little ;-)
I am interested, even though I have some 8 RL02 drives ...
All of the parts are available via digikey, which is
one of my
'rules'.
Would you be willing to make a kit for this? As US citizen
ordering with Digikey is easier for me than for non-US chaps.
Funds paid in advance, of course!
Once I have the new boards working, I plan to make up
2 "loaner"
boards - I'll like someone with an older machine like an 11/05
or an 11/70 or 11/45 to try them out if they are game.
I'm sure there are people in the US with these machines in running
state. I just finished moving my collection, so nothing is connected
at the moment, and they haven't run in some 5 years ... My /05 and
/70 were working, the /45 has a cut power cable harness :-/ so that
one needs repair work (next year).
- Henk
5:13 a.m.
New subject: udisk v0.3 up and running (generic unibus disk interface)
On Nov 16, 2013, at 2:20 PM, Brad Parker <brad at heeltoe.com> wrote:
I've been away from my addiction^H^H^H^Hhobby for
a 3-4 years now, but this summer I got rid of my
old consulting office and moved everything into my living room (temporarily :-)
Since the move I've been slowly trying to clean up old projects.
One of them was the udisk disk controller emulator.
In 2006-2008 I build a 4 layer prototype. The PCB had some flaws on the power plane, so
I had to add a lot of wires for power but it basically worked. It has an ARM (atmel
sam7s) and a CPLD on it as well as "correct" Unibus interface hardware. In 2008
I dabbled with it but never really got it stable. It would barely boot RT11.
This fall I finally got serious. I dusted off the board and plugged it into my 11/34a.
I used a logic analyzer and an arm jtag pod and really debugged it. I fixed a bunch of
little issues in the CPLD state machines and cleaned up the arm code to be
"correct" and took out all the hacks. The result is it's stable now and
appears to be working correctly. The bus transactions look correct and clean.
Great work! I really need to get to fabbing my Qbus universal board (and think
about what it'll take to make it truly universal; shouldn't be infeasible to
make it work with Unibus with just jumpers).
I am itching to try bigger disks, so I might try a
MSCP, we'll see. Those 2Gb CF disks... And I should run the XXDP diags on the
controller. That should be interesting.
Yeah, MSCP should get you a lot more capacity, and you'd be able to use it with
the big VAXen as well.
Once I have the new boards working, I plan to make up
2 "loaner" boards - I'll like someone with an older machine like an 11/05 or
an 11/70 or 11/45 to try them out if they are game. And if of course I'm willing to
sell them at basically cost if anyone wants them. With small quanity pcb runs the
PCB's tend to be the most expensive part. I think the PCB + parts was about $300. As
I recall I have new unibus interface chips for about 5x boards. I also have a number of
scrap boards which I think I can use to "harvest" interface chips. I could also
check the gray market again, who knows.
Mine is going to use currently-available devices (comparators and FETs) for the
bus interface. I'll let you know how it goes.
- Dave
21 Nov
21 Nov
12:52 p.m.
New subject: udisk v0.3 up and running (generic unibus disk interface)
On 11/16/2013 12:20 PM, Brad Parker wrote:
I've been away from my addiction^H^H^H^Hhobby for
a 3-4 years now, but
this summer I got rid of my
old consulting office and moved everything into my living room
(temporarily :-)
Since the move I've been slowly trying to clean up old projects.
One of them was the udisk disk controller emulator.
In 2006-2008 I build a 4 layer prototype. The PCB had some flaws on the
power plane, so I had to add a lot of wires for power but it basically
worked. It has an ARM (atmel sam7s) and a CPLD on it as well as
"correct" Unibus interface hardware. In 2008 I dabbled with it but
never really got it stable. It would barely boot RT11.
This fall I finally got serious. I dusted off the board and plugged it
into my 11/34a. I used a logic analyzer and an arm jtag pod and really
debugged it. I fixed a bunch of little issues in the CPLD state
machines and cleaned up the arm code to be "correct" and took out all
the hacks. The result is it's stable now and appears to be working
correctly. The bus transactions look correct and clean.
As a result, with RL02 emulation I can now boot all the images I have,
which include RT11, RSTS V7.2, XXDP 2.5 and BSD 2.9. I also did an RK05
emulation, which used to work but I have not tried it again. I will
shortly.
I am itching to try bigger disks, so I might try a MSCP, we'll see.
Those 2Gb CF disks... And I should run the XXDP diags on the
controller. That should be interesting.
I updated the docs on http://www.heeltoe.com and included the source
code for the firmware as well as the CPLD rtl and testbench. I also
updated the schematic pdf.
My plan is to do a little more testing and then fab another 4x PCB's;
Hopefully this time I won't botch the gerbers and the power plane (which
is split 3 ways) wont' be completely disconnected (which is better than
completely shorted, I might add, something I've also done once :-)
It's been a fun project. I was tempted to update it but I think it's
fine as it stands. All of the parts are available via digikey, which is
one of my 'rules'. A lot more could be done with the firmware. The
CPLD has a tiny amount of wiggle room, but it's pretty full.
Going forward I plan to do some interface projects with the "mojo" FPGA
board, like a pertec tape emulator and a RL02 emulator, just for fun,
but I wanted to finish this up first.
Once I have the new boards working, I plan to make up 2 "loaner" boards
- I'll like someone with an older machine like an 11/05 or an 11/70 or
11/45 to try them out if they are game. And if of course I'm willing
to sell them at basically cost if anyone wants them. With small quanity
pcb runs the PCB's tend to be the most expensive part. I think the PCB
+ parts was about $300. As I recall I have new unibus interface chips
for about 5x boards. I also have a number of scrap boards which I think
I can use to "harvest" interface chips. I could also check the gray
market again, who knows.
-brad
Haven't heard from you in a while...
I have a 11/84 that I've never even powered up because I don't have a
disk drive. If it has a chance of working on that system, I think I'd be
interested in participating. I suppose that every additional PCB board
lowers the cost for everyone.
Let me know the details.
I'm still working on the KS10 FPGA.
Rob.
12:59 p.m.
New subject: udisk v0.3 up and running (generic unibus disk interface)
On Thu, 21 Nov 2013, Rob Doyle wrote:
Haven't heard from you in a while...
I have a 11/84 that I've never even powered up because I don't have a
disk drive. If it has a chance of working on that system, I think I'd be
interested in participating. I suppose that every additional PCB board
lowers the cost for everyone.
Let me know the details.
I'm still working on the KS10 FPGA.
Do a KL10 one next! I never got TOPS-10 to install right on SIMH's
KS10 and running a 2U server for klh10 pulls a bit too much power compared
to an FPGA. ;)
Rob.
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
16 Oct
16 Oct
12:48 p.m.
* On Sun, Oct 14, 2012 at 07:47:45PM +0100, Rob Jarratt <robert.jarratt at
ntlworld.com> wrote:
I have heard the problem with driver chips before. I don't know enough
electronics really, but could it be done with discrete components?
It could be, yes, at the expense of a lot of board space.
One of the biggest issues with the DEC busses nowadays is that they use
open collector drivers. What that means is that the signal lines in the
bus are normally held at something like 3.4V (a logical "on") by
resistors at both ends of the bus that terminate the bus and form a
voltage divider. The chips are all TTL, so if you were to just directly
connect a TTL-level driver to the bus and assert a "high" logic level,
it would try to pull the bus to +5V and you would be in a world of
trouble. The open collector drivers don't ever do that, they can either
pull the line down to ground, or they can act like an open circuit, but
that's it. That's how signaling on the DEC bus works - a bunch of open
collector drivers share the same line, and any of them can pull the line
down to ground, safely.
The old chips that were designed for this purpose also had other
electrical requirements, especially the amount of current they could
sink when pulling the bus to ground.
There are some open collector drivers still made, but not as many as you
would think. And certainly nothing I know of that is in a single
convenient package like the DEC or National or Signetics chips were.
There are some off-the-shelf things that are close but not close enough.
Maybe the best bet would be to use a CPLD with open collector outputs
and +5V tolerant inputs on the other side? Though you'd have to be
careful about current sinking requirements.
Anyway, it's not as easy as I wish it were :) Believe me, I'd love a
QBus card with a CompactFlash or SDCard that knew how to speak MSCP. But
if anyone wants to actually build it, it'll be a lot of work.
My own "plan" is to emulate the raw hard
disks instead of the controllers
(certainly for DEC RD53/54 which are the ones I most want to emulate). One
day, when I get time, and when I find someone who can help me with the
hardware design.
Also hard! Differential signaling on the disk data lines, MFM
encoding/decoding, wicked tight timing requirements. But it has been
done commercially, so it's certainly not impossible!
-Seth
1:02 p.m.
open collector drivers. What that means is that the
signal lines in the
bus are normally held at something like 3.4V (a logical "on") by
resistors at both ends of the bus that terminate the bus and form a
voltage divider. The chips are all TTL, so if you were to just directly
connect a TTL-level driver to the bus and assert a "high" logic level,
it would try to pull the bus to +5V and you would be in a world of
trouble. The open collector drivers don't ever do that, they can either
LVD devices that works with 3.3V as "high"? There is an entire line of
74's made in LVD/LVX flavor :o)
1:26 p.m.
On Oct 16, 2012, at 3:48 PM, Seth Morabito wrote:
* On Sun, Oct 14, 2012 at 07:47:45PM +0100, Rob
Jarratt <robert.jarratt at ntlworld.com> wrote:
Given the size of modern transistors, less than you might think (if you
have a single transistor for output, you're talking about just about 1cm
above the fingers, really).
I have heard the problem with driver chips before. I don't know enough
electronics really, but could it be done with discrete components?
It could be, yes, at the expense of a lot of board space. One of the biggest issues with the DEC busses nowadays
is that they use
open collector drivers. What that means is that the signal lines in the
bus are normally held at something like 3.4V (a logical "on") by
resistors at both ends of the bus that terminate the bus and form a
voltage divider. The chips are all TTL, so if you were to just directly
connect a TTL-level driver to the bus and assert a "high" logic level,
it would try to pull the bus to +5V and you would be in a world of
trouble. The open collector drivers don't ever do that, they can either
pull the line down to ground, or they can act like an open circuit, but
that's it. That's how signaling on the DEC bus works - a bunch of open
collector drivers share the same line, and any of them can pull the line
down to ground, safely.
That's not really the problem. There are plenty of open-collector
TTL chips; the ones that I've found come closest to what you'd want
(for QBUS, at least) are the 74AS640 and 74AS760. They're both
heavy-hitting octal open-collector bus drivers (one is unidirectional,
the other bidirectional). The primary attractive feature to me is
the 64mA of current handling, which comes pretty close to the 70mA
max I've seen in all the QBUS-related material so far. Their min
fall time is a little too short, though. And their thresholds
aren't quite where the DEC chips were, though they're probably close
enough for most systems out there. As Allison pointed out, plenty
of third-party manufacturers used '244s and '245s with success.
The old chips that were designed for this purpose also
had other
electrical requirements, especially the amount of current they could
sink when pulling the bus to ground.
There are some open collector drivers still made, but
not as many as you
would think. And certainly nothing I know of that is in a single
convenient package like the DEC or National or Signetics chips were.
There are some off-the-shelf things that are close but not close enough.
See above. My major issue with them is that they pull down too
fast (QBUS has a minimum of 5 ns).
Maybe the best bet would be to use a CPLD with open
collector outputs
and +5V tolerant inputs on the other side? Though you'd have to be
careful about current sinking requirements.
A CPLD can't sink nearly enough current. A 2N4401, on the other hand,
should do nicely (assuming you keep it from saturating).
Anyway, it's not as easy as I wish it were :)
Believe me, I'd love a
QBus card with a CompactFlash or SDCard that knew how to speak MSCP. But
if anyone wants to actually build it, it'll be a lot of work.
Well, yes. :-)
- Dave
1:59 p.m.
On Tue, 16 Oct 2012, David Riley wrote:
Date: Tue, 16 Oct 2012 16:26:30 -0400
From: David Riley <fraveydank at gmail.com>
Reply-To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at
classiccmp.org>
Subject: Re: unibus to modern disk interface?
On Oct 16, 2012, at 3:48 PM, Seth Morabito wrote:
A bipolar transistor will turn off too slowly for this use, but a little
SOT-23 MOSFET will work just fine (and a series resistor in the gate can
tailor the on/off slew rates) You can get ones with less than 5 pF output
capacitance that will easily sink 100 mA with less than .7V VOL
but discretes would add to the assembly cost...
Peter Wallace
Mesa Electronics
* On Sun, Oct 14, 2012 at 07:47:45PM +0100, Rob
Jarratt <robert.jarratt at ntlworld.com> wrote:
Given the size of modern transistors, less than you might think (if you
have a single transistor for output, you're talking about just about 1cm
above the fingers, really).
I have heard the problem with driver chips before. I don't know enough
electronics really, but could it be done with discrete components?
It could be, yes, at the expense of a lot of board space. One of the biggest issues with the DEC busses
nowadays is that they use
open collector drivers. What that means is that the signal lines in the
bus are normally held at something like 3.4V (a logical "on") by
resistors at both ends of the bus that terminate the bus and form a
voltage divider. The chips are all TTL, so if you were to just directly
connect a TTL-level driver to the bus and assert a "high" logic level,
it would try to pull the bus to +5V and you would be in a world of
trouble. The open collector drivers don't ever do that, they can either
pull the line down to ground, or they can act like an open circuit, but
that's it. That's how signaling on the DEC bus works - a bunch of open
collector drivers share the same line, and any of them can pull the line
down to ground, safely.
That's not really the problem. There are plenty of open-collector
TTL chips; the ones that I've found come closest to what you'd want
(for QBUS, at least) are the 74AS640 and 74AS760. They're both
heavy-hitting octal open-collector bus drivers (one is unidirectional,
the other bidirectional). The primary attractive feature to me is
the 64mA of current handling, which comes pretty close to the 70mA
max I've seen in all the QBUS-related material so far. Their min
fall time is a little too short, though. And their thresholds
aren't quite where the DEC chips were, though they're probably close
enough for most systems out there. As Allison pointed out, plenty
of third-party manufacturers used '244s and '245s with success.
The old chips that were designed for this purpose
also had other
electrical requirements, especially the amount of current they could
sink when pulling the bus to ground.
There are some open collector drivers still made,
but not as many as you
would think. And certainly nothing I know of that is in a single
convenient package like the DEC or National or Signetics chips were.
There are some off-the-shelf things that are close but not close enough.
See above. My major issue with them is that they pull down too
fast (QBUS has a minimum of 5 ns).
Maybe the best bet would be to use a CPLD with
open collector outputs
and +5V tolerant inputs on the other side? Though you'd have to be
careful about current sinking requirements.
A CPLD can't sink nearly enough current. A 2N4401, on the other hand,
should do nicely (assuming you keep it from saturating).
Anyway, it's not as easy as I wish it were :)
Believe me, I'd love a
QBus card with a CompactFlash or SDCard that knew how to speak MSCP. But
if anyone wants to actually build it, it'll be a lot of work.
Well, yes. :-)
- Dave
2:24 p.m.
On Oct 16, 2012, at 4:59 PM, Peter C. Wallace wrote:
A bipolar transistor will turn off too slowly for this
use, but a little SOT-23 MOSFET will work just fine (and a series resistor in the gate can
tailor the on/off slew rates) You can get ones with less than 5 pF output capacitance that
will easily sink 100 mA with less than .7V VOL
You could keep the bipolar from saturating with a Schottky clamp, but at
the expense of even more parts. I like the idea of a FET, but I haven't
looked very hard at the available parts.
but discretes would add to the assembly cost...
Certainly. Or, if one makes a kit, they add to the headache of the
consumer. :-) Some of us don't mind soldering upwards of 40 tiny SOT
parts, but some do.
- Dave
2:32 p.m.
A bipolar
transistor will turn off too slowly for this [...]
You could keep the bipolar from
saturating with a Schottky clamp, but
at the expense of even more parts.
2:58 p.m.
On Oct 16, 2012, at 17:32, Mouse <mouse at rodents-montreal.org> wrote:
Don't single packages containing transistor and clamp exist?
They do. I've been trying to stick to more "standard" devices
(for some nominal definition of "standard") to minimize
both overall cost and the probability of early obsolescence. I
haven't done enough research into integrated Schottky
transistors to see if there are any which approach 2N3904/4401
levels of popularity, but that's all in my queue.
- Dave
A bipolar transistor will turn off too slowly for this
[...]
You could keep the bipolar from saturating with a Schottky clamp, but
at the expense of even more parts.
3:25 p.m.
On Tue, 16 Oct 2012, David Riley wrote:
Date: Tue, 16 Oct 2012 17:24:03 -0400
From: David Riley <fraveydank at gmail.com>
Reply-To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
To: "General Discussion: On-Topic and Off-Topic Posts" <cctalk at
classiccmp.org>
Subject: Re: unibus to modern disk interface?
On Oct 16, 2012, at 4:59 PM, Peter C. Wallace wrote:
A FDV301N is close and would work with 3.3V gate drive from CPLD/FPGA
Peter Wallace
Mesa Electronics
A bipolar transistor will turn off too slowly for
this use, but a little SOT-23 MOSFET will work just fine (and a series resistor in the
gate can tailor the on/off slew rates) You can get ones with less than 5 pF output
capacitance that will easily sink 100 mA with less than .7V VOL
You could keep the bipolar from saturating with a Schottky clamp, but at
the expense of even more parts. I like the idea of a FET, but I haven't
looked very hard at the available parts.
but discretes would add to the assembly cost...
Certainly. Or, if one makes a kit, they add to the headache of the
consumer. :-) Some of us don't mind soldering upwards of 40 tiny SOT
parts, but some do.
- Dave
17 Oct
17 Oct
2:43 a.m.
On Tue, 16 Oct 2012, David Riley wrote:
That's not really the problem. There are plenty
of open-collector
TTL chips; the ones that I've found come closest to what you'd want
(for QBUS, at least) are the 74AS640 and 74AS760. They're both
The '640 is tri-state. You mean e.g. the '642. Only problem: They are
almost unavailable and VERY pricy.
The "ideal" IC solution today would be the SN7438, still produced. It is
almost identical to the SN7439 that DEC used as bus drivers (equal to
N8881). Otherwise just use some SN7406 as drivers; they are adequate in
most Unibus applications today where you don't have bus lengths of several
meters.
See above. My major issue with them is that they pull
down too
fast (QBUS has a minimum of 5 ns).
Is that a real-world issue or just hypothetical? We have a custom
external semiconductor memory expansion for our 11/20 where they used
SN7401 as bus drivers!
Christian
5:18 a.m.
On Oct 17, 2012, at 5:43, Christian Corti <cc at informatik.uni-stuttgart.de>
wrote:
I'm sure it works well enough in practice, especially
on small systems. I think the DEC bus specs are probably
excessive until you get to a many-meter backplane with a
bunch of extensions which add impedance discontinuities;
I imagine then you start to see why their thresholds
are set where they are.
A first pass using commodity chips that "just work" might
not be a bad idea just to get the ball rolling; more
compliant solutions can be devised later, and a
7438 solution isn't going to blow anything up.
- Dave
On Tue, 16 Oct 2012, David Riley wrote:
Uh, yes, that's what I meant. Sorry! In any case, they're
usually fairly available at Mouser, but yes, they're somewhat
pricy.
That's not really the problem. There are
plenty of open-collector
TTL chips; the ones that I've found come closest to what you'd want
(for QBUS, at least) are the 74AS640 and 74AS760. They're both
The '640 is tri-state. You mean e.g. the '642. Only problem: They are almost
unavailable and VERY pricy. The "ideal" IC solution today would be the
SN7438, still produced. It is almost identical to the SN7439 that DEC used as bus drivers
(equal to N8881). Otherwise just use some SN7406 as drivers; they are adequate in most
Unibus applications today where you don't have bus lengths of several
meters.
Those would probably make OK drivers, though I'd
personally prefer something that came closer to the Iol of
70 mA (again, I'm thinking more about QBUS, which
specifies the maximum output voltage when sinking
70 mA).
See above. My
major issue with them is that they pull down too
fast (QBUS has a minimum of 5 ns).
Is that a real-world issue or just hypothetical? We have a custom external semiconductor
memory expansion for our 11/20 where they used SN7401 as bus drivers! 
18 Oct
18 Oct
12:29 a.m.
On Wed, 17 Oct 2012 08:18:26 -0400
David Riley <fraveydank at gmail.com> wrote:
A first pass using commodity chips that "just
work" might
not be a bad idea just to get the ball rolling; more
compliant solutions can be devised later, and a
7438 solution isn't going to blow anything up.
My words. I thought about a
"universal" Uni- / QBus device and CPU
emulator some weeks ago. The bus driver chips are really the smalest
problem. The usual hobyist QBus box is a single BA23 / BA123 / BA213.
In that situation you will get away with somthing thats much lower
speced.
The real problem is to make a complete hardware solution. I.e. design
and _manufacture_ a PCB at an affordable price. AND write all the
software. The later can be a huge task. (MSCP...) If I did it I would
go as far as putting an ARM SOC on the board that runs NetBSD plus a
FPGA as QBus / UniBus glue logic. I'd not go without NetBSD because
that way you get a large software ecosystem. This will ease developement
of software for this beast imensely. (E.g. you can write / prototype
NetBSD kernel device drivers as modules written in the Lua scripting
language.)
Think of a board that runs NetBSD and simh where the peripherals are
partly emulated and partly real QBus hardware. Start an other programm
on that NetBSD board and it starts to emulate a MSCP disk controler for
a real PDP-11 or VAX CPU where the disk image is attached via iSCSI...
--
\end{Jochen}
\ref{http://www.unixag-kl.fh-kl.de/~jkunz/}
16 Oct
16 Oct
3:22 p.m.
Seth Morabito wrote:
One of the biggest issues with the DEC busses nowadays
is that they use
open collector drivers.
The drivers aren't that difficult. The receivers are more of a
problem. The threshold voltage doesn't match anything commonly available.
Maybe the best bet would be to use a CPLD with open
collector outputs
and +5V tolerant inputs on the other side?
CPLDs (or for that matter FPGAs) don't have anywhere near the output
drive. Also their drivers have edge rates that are way too fast.
3:37 p.m.
On Tue, 16 Oct 2012, Eric Smith wrote:
Peter Wallace
Mesa Electronics
(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
(")_(") signature to help him gain world domination.
Date: Tue, 16 Oct 2012 16:22:23 -0600
From: Eric Smith <eric at brouhaha.com>
Reply-To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
To: General Discussion: On-Topic and Off-Topic Posts <cctalk at classiccmp.org>
;
Subject: Re: unibus to modern disk interface?
Seth Morabito wrote:
A good high impedance (48K) RS-422 receiver can do it but would violate the 0V
leakage current (~30 uA vs 10 uA) This may not be an issue since you only
need one of the cards
(one lead tied to 1.5V so 1.5V +- 200 mV and even adjustable if you like)
One of the biggest issues with the DEC busses
nowadays is that they use
open collector drivers.
The drivers aren't that difficult. The receivers are more of a problem. The
threshold voltage doesn't match anything commonly available. Maybe the best bet would be to use a CPLD with
open collector outputs
and +5V tolerant inputs on the other side?
CPLDs (or for that matter FPGAs) don't have anywhere near the output drive.
Also their drivers have edge rates that are way too fast.
6:09 p.m.
On Oct 16, 2012, at 6:37 PM, Peter C. Wallace wrote:
On Tue, 16 Oct 2012, Eric Smith wrote:
For that matter, a good high-speed comparator will do the trick admirably
(throw in a little positive feedback for hysteresis and overdrive and
you're good). Last I checked (which was not a totally exhaustive search
about a year ago), it was hard to find ones that met:
- 35 ns Tpd
- <= 9.35 pf input capacitance
- <= 80 uA input impedance
- < $1 per gate
All the fast ones turn out to be really expensive, and when you're talking
about as many inputs as you need (22 for QBUS' BDAL lines alone, plus a
bunch of others), it adds up quickly.
So I'd like to see what can be done with discrete logic, ideally FETs.
Logic thresholds, especially with FET gates, are a bit out of my league,
but it's one of those things I'd love to learn if only I could find some
good reading material. My initial thought is that you'd at least want
something akin to a cascode arrangement, since the Miller capacitance on
a straight-up grounded-emitter amplifier is likely to be ugly; I might
be over thinking it.
One benefit of doing the bus logic in a CPLD/FPGA is that the polarity
of the data coming in doesn't matter for any practical purpose. If you
were to decompose things into, say, a PAL and some 74xx gates, it can
become a little hairier. In any case, my recollection is that the data
on QBUS is inverted, which makes things easier for single-transistor
drivers (and other inverting logic, which is presumably why).
- Dave
The drivers aren't that difficult. The
receivers are more of a problem. The threshold voltage doesn't match anything
commonly available.
A good high impedance (48K) RS-422 receiver can do it but would violate the 0V leakage
current (~30 uA vs 10 uA) This may not be an issue since you only need one of the cards
(one lead tied to 1.5V so 1.5V +- 200 mV and even adjustable if you like)
14 Oct
14 Oct
12:20 p.m.
On 10/14/2012 11:42 AM, js at cimmeri.com wrote:
What makes IDE to Qbus or Unibus interfacing so
difficult? There must
be reasons, otherwise it would have been done by now.
Lack of driver space in the OS is my guess, looking at the PDP-8.
There you had just one or two pages for the device driver. 256 words
might be the limit of code space permitted.
JS
Ben.
2:40 p.m.
On 10/14/2012 03:20 PM, ben wrote:
We're talking about Qbus and Unibus...nothing at all to do with any PDP-8.
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
What makes IDE
to Qbus or Unibus interfacing so difficult? There must
be reasons, otherwise it would have been done by now.
Lack of driver space in the OS is my guess, looking at the PDP-8.
There you had just one or two pages for the device driver. 256 words
might be the limit of code space permitted. 
16 Oct
16 Oct
11:21 a.m.
On 2012-10-14 19:42, js at cimmeri.com wrote:
Is there really enough interest in such a thing to make boards?
This subject pops up now & then, gets discussed, and disappears again.
I did myself some qbus-ide boards, but never finished the software.
It is simply to easy to buy qbus-scsi or unibus-scsi boards on ebay. You
just have to wait for it.
And if somebody/anybody picks it up again, it won't be cheaper then the
$200 on ebay, so why?
Actually, the only reason I could think is, that we have less and less
working 50 pin scsi drives, so "if" I would do it again, it would be
sd-flash. But what to do with the floppies & tapes ?
Cheers
> >> [...non-ancient disk on Unibus
machines...]
> I'm surely not the only collector who would be willing to pony up
> some $$$ for such a project....
I would certainly pony up some $.
11:41 a.m.
Is there really enough interest in such a thing to
make boards?
It is simply to easy to buy qbus-scsi or unibus-scsi
boards on ebay.
You just have to wait for it.
You also have to be willing to use ebay. Which not everyone is.
And if somebody/anybody picks it up again, it
won't be cheaper then
the $200 on ebay, so why?
(a) I'd be willing to buy from a list regular long before I'd be
willing to find someone to proxy for me on ebay. (Using ebay directly
is just not happening for me. Their terms of service are ludicrous, or
at least were last I looked, and the only interface they provide is a
Web one; either of those would keep me away.)
(b) I'd be significantly more confident the result would actually work.
(c) I'd be supporting someone in the hobby rather than (likely) a
random dealer/scrapper.
Of course, these are all really just facets of a single thing I haven't
come up with a good word for.
Actually, the only reason I could think is, that we
have less and
less working 50 pin scsi drives, so "if" I would do it again, it
would be sd-flash.
I'd rather real disks; if you really don't want to do SCSI (which would
be my own preference - I've got lots of SCA and HD68 and even some
50pin, and plenty of passive adapters), I'd suggest SATA. But I
recognize that that's armchair quarterbacking.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
3815
days inactive
4218
days old
82 comments
32 participants
participants (32)
-
aek＠bitsavers.org -
ajp166＠verizon.net -
ard＠p850ug1.demon.co.uk -
b4＠gewt.net -
bfranchuk＠jetnet.ab.ca -
brad＠heeltoe.com -
captainkirk359＠gmail.com -
cc＠informatik.uni-stuttgart.de -
cisin＠xenosoft.com -
emu＠e-bbes.com -
eric＠brouhaha.com -
ethan.dicks＠gmail.com -
fraveydank＠gmail.com -
henk.gooijen＠hotmail.com -
jkunz＠unixag-kl.fh-kl.de -
js＠cimmeri.com -
jwest＠classiccmp.org -
lists＠loomcom.com -
mcguire＠neurotica.com -
mouse＠Rodents-Montreal.ORG -
nf6x＠nf6x.net -
pcw＠mesanet.com -
phil+ccmp＠ultimate.com -
pu1bzz.listas＠gmail.com -
radioengr＠gmail.com -
RichA＠LivingComputerMuseum.org -
rickb＠bensene.com -
robert.jarratt＠ntlworld.com -
tdk.knight＠gmail.com -
toby＠telegraphics.com.au -
tothwolf＠concentric.net -
uban＠ubanproductions.com