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

[Noel Chiappa]

> From: David Bridgham

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

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

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

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

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

Noel

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

[allison]

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

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

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

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

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


Allison

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

[David Bridgham]

On 10/22/2016 12:44 PM, shad wrote:

> What kind of bus transceivers did you used for the QSIC, specially
> because you have
> to go from 5V open-drain logic to 3.3V logic?

To add to Noel's answer, here's a picture of our current prototype board.

http://pdp10.froghouse.org/qsic/qsic-wirewrap.jpg

Coming up from the QBUS, the first two rows of chips are the bus
transceivers.  The next row and a half are the level-converters.  Then
the two large ribbon cables run off to the FPGA module we're using for
development.  The two small ribbon cables go to the indicator panel. 
Just the bus interface takes over half the area of a dual-height board! 
I've played around with laying out what might be the production board
(when I get tired of Verilog and want a mindless break, I doodle with
kicad) and I've got it down to a row of 8641 bus transceivers and a row
or two of the level-converter chips.  It's better but still a good
fraction of the entire board.

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

Now I thought, what if my idea of that two MOSFET bus transceiver would
work?  What would the board look like then?

http://pdp10.froghouse.org/qsic/qsic-smt.jpg

Obviously that could be squeezed down a lot more.  Even another
transistor or two per bus line would still be fairly small.  Doing the
bus transceiver and level-conversion in one step makes a big difference.

For the QSIC, we're going to have sufficient room and we're able to find
enough old bus transceivers to continue on as we're going.  Still, I'd
sure love to have an option that used production parts and took up less
board space.

Re: Unibus disk controller with modern storage

[Noel Chiappa]

> From: shad

> they can run linux for the software side

Maybe it's just me, but running Linux on an interface card strike me as
somewhat grotesque. It's bad enough running a far faster chip than the vintage
CPU, but... a majorly complex operating system to boot?

> I'm trying to figure if an hybrid QBUS / UNIBUS solution is possible.
> Of course one have to switch some jumper to avoid conflicts

Lots and lots and lots and lots of jumpers. The two buses are completely
unlike, pinout-wise.

And the UNIBUS board has to be a quad, and there are some QBUS chassis which
only take duals...

> What kind of bus transceivers did you used for the QSIC

We used a mix of DS8641 quad transceivers (they're still available in
reasonably good numbers for a reasonable price) and AM2908 octal latching
transceivers with a tri-state output (to allow us to have a bidirectional
internal bus for BDAL00-BDAL21 - we were trying to minimize the number of pins
needed on the FPGA to interfaces to the QBUS). But we probably will use a
different FPGA on the production boards, and all DS8641's.

> you have to go from 5V open-drain logic to 3.3V logic?

We do that with separate 74LVC7T245 level converter chips.

Noel

Re: Unibus disk controller with modern storage

[shadoooo]

Hello Dave,
exactly!
But in place of a plain FPGA, nowadays I would choose a FPGA-ARM board, 
for example
the ZedBoard MicroZed or the Myirtech Z-turn, both of them have a Zynq 
onboard,
and they can run linux for the software side and programmable logic for 
the interface side.

Very nice and flexible.

For the development, I'm trying to figure if an hybrid QBUS / UNIBUS 
solution is possible.
Of course one have to switch some jumper to avoid conflicts, but hey, in 
the end you

would have a true universal board.

What kind of bus transceivers did you used for the QSIC, specially 
because you have

to go from 5V open-drain logic to 3.3V logic?

Thanks
Andrea


On 10/21/2016 07:00 PM, cctalk-requ...@classiccmp.org wrote:

You mean, perhaps, something like this?

http://pdp10.froghouse.org/qsic/html/overview.html

Re: Unibus disk controller with modern storage

[shadoooo]

Hello Dave,
exactly!
But in place of a plain FPGA, nowadays I would choose a FPGA-ARM board, 
for example
the ZedBoard MicroZed or the Myirtech Z-turn, both of them have a Zynq 
onboard,
and they can run linux for the software side and programmable logic for 
the interface side.

Very nice and flexible.

For the development, I'm trying to figure if an hybrid QBUS / UNIBUS 
solution is possible.
Of course one have to switch some jumper to avoid conflicts, but hey, in 
the end you

would have a true universal board.

What kind of bus transceivers did you used for the QSIC, specially 
because you have

to go from 5V open-drain logic to 3.3V logic?

Thanks
Andrea


On 10/21/2016 07:00 PM, cctalk-requ...@classiccmp.org wrote:

You mean, perhaps, something like this?

http://pdp10.froghouse.org/qsic/html/overview.html

Re: Unibus disk controller with modern storage

[Al Kossow]

I'd trust the later documents. They went through a lot of pain in the 70's
pushing the limits of what the bus could do.

If it were me, I'd build the stuff on Eurocards with a cable running to a
Unibus paddle.

On 10/21/16 12:23 PM, Noel Chiappa wrote:
> > From: Paul Koning
> 
> > 1976 Peripherals Handbook, page 6-4. It specifies the driver output
> > low voltage at 70 mA sink, not 50...
> 
> Differing editions give slightly different numbers. I was looking at the 1972
> edition (which was the one that was closest to hand, no other reason); the
> number I gave is on pg. 204. I haven't checked later ones to see if there
> were further revisions.
> 
> The later 70mA sink spec is probably a slightly more robust number to work
> with.
> 
>   Noel
> 

Re: Unibus disk controller with modern storage

[Pete Lancashire]

To solve the loading problem a division of Tektronix built their own Unibus
repeater.
We not only had a lot of stuff attached to the Unibus but was in multiple
rack instruments.
We also went with round cables the Tektronix made internally. We also made
our own Unibus
cables and added a few LEDs to the paddle boards, power status was one of
them. Can't
remember what the others were far.

A picture of the first generation of the system

http://www.eetimes.com/author.asp?doc_id=1320717_number=1

By the time I ended up at Tek the PDP11 had been renamed CP-1160 and came
in custom
colors of light and dark blue.

The Unibus had to make it from the PDP to a couple of the boxes near the
lower left.

On Fri, Oct 21, 2016 at 11:50 AM, Guy Sotomayor Jr 
wrote:

>
> > On Oct 21, 2016, at 11:41 AM, Paul Koning 
> wrote:
> >
> >
> >> On Oct 20, 2016, at 6:05 PM, Noel Chiappa 
> wrote:
> >>
> >>> From: David Bridgham
> >>
> >>> the right threshold voltage to meet the receiver spec
> >>
> >> The UNIBUS spec says the 4 crucial receiver parameters are input
> thresholds
> >> (high and low), and the input currents (high and low); the crucial
> >> transmitter parameters are the output low voltage (at 50 mA sink), and
> >> the output high leakage current.
> >
> > Where did you find those specs?  I see a Unibus Spec on Bitsavers, but
> it doesn't appear to mention the electrical specs.
> >
>
> They exist in various DEC handbooks.  I don’t recall which one had them.
>
> The specs are fairly stringent in order to meet the max unibus bus lengths
> (my 11/40 is close to max).
>
> TTFN - Guy
>
>
>

Re: Unibus disk controller with modern storage

[Paul Koning]

> On Oct 21, 2016, at 2:50 PM, Guy Sotomayor Jr  wrote:
> 
> 
>> On Oct 21, 2016, at 11:41 AM, Paul Koning  wrote:
>> 
>> 
>>> On Oct 20, 2016, at 6:05 PM, Noel Chiappa  wrote:
>>> 
 From: David Bridgham
>>> 
 the right threshold voltage to meet the receiver spec
>>> 
>>> The UNIBUS spec says the 4 crucial receiver parameters are input thresholds
>>> (high and low), and the input currents (high and low); the crucial
>>> transmitter parameters are the output low voltage (at 50 mA sink), and
>>> the output high leakage current.
>> 
>> Where did you find those specs?  I see a Unibus Spec on Bitsavers, but it 
>> doesn't appear to mention the electrical specs.
>> 
> 
> They exist in various DEC handbooks.  I don’t recall which one had them.

Found it.  1976 Peripherals Handbook, page 6-4.  It specifies the driver output 
low voltage at 70 mA sink, not 50...

paul

Re: Unibus disk controller with modern storage

[Guy Sotomayor Jr]

> On Oct 21, 2016, at 11:41 AM, Paul Koning  wrote:
> 
> 
>> On Oct 20, 2016, at 6:05 PM, Noel Chiappa  wrote:
>> 
>>> From: David Bridgham
>> 
>>> the right threshold voltage to meet the receiver spec
>> 
>> The UNIBUS spec says the 4 crucial receiver parameters are input thresholds
>> (high and low), and the input currents (high and low); the crucial
>> transmitter parameters are the output low voltage (at 50 mA sink), and
>> the output high leakage current.
> 
> Where did you find those specs?  I see a Unibus Spec on Bitsavers, but it 
> doesn't appear to mention the electrical specs.
> 

They exist in various DEC handbooks.  I don’t recall which one had them.

The specs are fairly stringent in order to meet the max unibus bus lengths (my 
11/40 is close to max).

TTFN - Guy

Re: Unibus disk controller with modern storage

[Paul Koning]

> On Oct 20, 2016, at 6:05 PM, Noel Chiappa  wrote:
> 
>> From: David Bridgham
> 
>> the right threshold voltage to meet the receiver spec
> 
> The UNIBUS spec says the 4 crucial receiver parameters are input thresholds
> (high and low), and the input currents (high and low); the crucial
> transmitter parameters are the output low voltage (at 50 mA sink), and
> the output high leakage current.

Where did you find those specs?  I see a Unibus Spec on Bitsavers, but it 
doesn't appear to mention the electrical specs.

paul

Re: Unibus disk controller with modern storage

[David Bridgham]

> Oh that blinkenlights panel is excellent! All emulators should have
> one! :-) 

Yeah, isn't that fun?  Once I got it running, I just sat and watched it
for about fifteen minutes while it ran our disk exercising program.  And
then I noticed a bug.  It apparently wasn't causing a problem but the
address line 00 was lighting up each time it did a DMA.  That didn't
seem right.  I looked through the Verilog and figured out what was going
on.  It probably wouldn't have caused a problem, maybe, but I got to fix
it anyway.  See?  'Dem blinkenlights are useful!

> I'm not really into Qbus much but would probably buy a
> production example anyway. I'd certainly fork out for several Unibus
> devices if you make them!

Our plan was to do a Unibus version of the same thing as a follow-on. 
It ought to be reasonably straightforward.
 
> One tip from someone with same issue in a parallel endeavor (IBM
> System/360 panel): they look much better and more authentic with 'warm
> white' LEDs. These are the ones I'm using:
> https://octopart.com/l5-n55n-fuv-sloanled-29855005

Yeah.  You can see in this picture that the LEDs I picked have this
yellow lens.  I was hoping that would warm up the output but obviously
it didn't.  I looked through the list of 1206 and 0805 LEDs on DigiKey
and didn't find any that were obviously what I wanted.  I'll take
suggestions from anyone.  Or, I suppose, I could re-spin the board for
through-hole LEDs.  I've actually come to prefer surface-mount though
and I'm hoping that one of these days I'll have my own pick and place
machine (or I'll talk our soon to exist MakerSpace into getting one).

http://pdp10.froghouse.org/qsic/indp.jpg

Re: Unibus disk controller with modern storage

[Mike Ross]

On Fri, Oct 21, 2016 at 2:45 AM, David Bridgham  wrote:
> On 10/19/2016 06:48 PM, shad wrote:
>>
>> One of my retrocomputing dream is to design an Unibus universal board,
>> probably based on FPGA because of precise timing requirements,
>> to emulate one or more disk/tape interfaces, and possibly something more.
>> The real storage could be based on SD card
>
> You mean, perhaps, something like this?
>
> http://pdp10.froghouse.org/qsic/html/overview.html

Oh that blinkenlights panel is excellent! All emulators should have
one! :-) I'm not really into Qbus much but would probably buy a
production example anyway. I'd certainly fork out for several Unibus
devices if you make them!

One tip from someone with same issue in a parallel endeavor (IBM
System/360 panel): they look much better and more authentic with 'warm
white' LEDs. These are the ones I'm using:
https://octopart.com/l5-n55n-fuv-sloanled-29855005

Mike

http://www.corestore.org
'No greater love hath a man than he lay down his life for his brother.
Not for millions, not for glory, not for fame.
For one person, in the dark, where no one will ever know or see.'

Re: Fwd: Unibus disk controller with modern storage

[Noel Chiappa]

> From: David Bridgham

> the right threshold voltage to meet the receiver spec

The UNIBUS spec says the 4 crucial receiver parameters are input thresholds
(high and low), and the input currents (high and low); the crucial
transmitter parameters are the output low voltage (at 50 mA sink), and
the output high leakage current.

Noel

Re: Unibus disk controller with modern storage

[Mark Linimon]

On Thu, Oct 20, 2016 at 05:32:07PM -0400, Noel Chiappa wrote:
> For Unix, tweaking the RP11 driver to handle the extended RP11 should
> take all of 12 minutes, tops! :-)

well played.

mcl

Re: Unibus disk controller with modern storage

[Noel Chiappa]

> From: Paul Koning

> That's fine if your target is an OS for which you can write drivers. It
> wouldn't help RSTS users.

Right, they're stuck with exact clones of DEC controllers. (For Unix, tweaking
the RP11 driver to handle the extended RP11 should take all of 12 minutes,
tops! :-)

> Q22 disks .. RL02 also, if I remember right.

Oh, right, the RLV12 - forgot about that. Still, it would be nice to be able
to run RK11's and RP11's in 22-bit mode! :-) Especially since there will be
replicas of DEC's indicator panels for them, whereas an RL11 indicator panel
would definitely be... an anachronism! ;-)

> A possible answer for a lot of this is to do the actual emulation
> algorithms in software, in an embedded CPU inside the FPGA. For MSCP
> that's obvious, but it would work for the others as well I suspect.

Dave B is a wizard with Verilog, so until it gets to the complexity level of
MSCP we'd probably do it all in Verilog.


> From: Jon Elson

> I did **ONE** board with some kind of gold flash that a PCB house 
> recommended. ... it was a colossal disaster. You had to lift the pin
> ... Since then, I have used pure tin HASL, and had little trouble.

I think gold came into the discussion in the context of the contact fingers
where the board plugs into the backplane. I've never seen a QBUS/UNIBUS board
with tin fingers, although they were common on SIMM memory cards; no idea
if tin would work for QBUS/UNIBUS - although now that I think about it,
SIMM cards didn't slide into position, but kind of rotated, so maybe tin
would work there.

Noel

Re: Unibus disk controller with modern storage

[David Bridgham]

On 10/20/2016 04:27 PM, Paul Koning wrote:

> I would treat this as an analog problem, putting some op amps and comparators 
> to work.  It doesn't seem to rise to the level where D/A devices are needed.  
> :-)

Clearly op amps and comparators could do the job, probably really
nicely, but it seems like you'd end up with a rather large and expensive
bus interface.  I've wondered if this might be solvable with just a
couple FETs.  I'm thinking something like in this schematic.

http://pdp10.froghouse.org/qsic/drivers-drivers.pdf

The resistor to the base of the driver FET is to limit the slew rate
(depending on the gate capacitance of the FET and maybe current limiting
from the FPGA).  An appropriate FET would have to be found, having the
right threshold voltage to meet the receiver spec, also a small enough
gate capacitance (one friend suggested that a series resistor on that
side too might help with that).

> Right.  I meant an existing non-MSCP non-RL device.  Most other disks have 
> extremely straightforward register command sets; RK05, RP06, the details 
> differ but the general approach is very easy.

I'd planned to implement an RK first, followed by an RP.  I didn't
realize the RL was any more complex than those but I'll come asking
questions of you if/when I get to that.

> Any non-DEC disk would be a problem.  Writing drivers is a pain if it's even 
> possible; for some operating systems like RSTS it flat out isn't supported.

Our plan was to first emulate the DEC disk controllers as closely as
possible.  Well, as closely as people tell us is necessary (like, do we
have to insert delays to slow our "disks" down to match the real
ones?).  Then we'd have options for various extensions like 22-bit
addresses and larger disk sizes for those people who were able to take
advantage.

Re: Unibus disk controller with modern storage

[Jon Elson]

On 10/19/2016 07:23 PM, Eric Smith wrote:
I prefer NOT to use ENIG, as I find HASL tin-lead better for hand 
assembly, though the lead is a problem due to RoHS regulations in much 
of the world (but not in USA). I haven't tried HASL lead-free. 
I did **ONE** board with some kind of gold flash that a PCB house 
recommended.
If the solder on the board didn't flow, it was a colossal disaster. You 
had to lift the pin, scrape the black crud down to bare copper and 
re-tin, then solder the lead back down.


Since then, I have used pure tin HASL, and had little trouble.

Jon

Re: Unibus disk controller with modern storage

[Ethan Dicks]

On Thu, Oct 20, 2016 at 4:31 PM, Paul Koning  wrote:
> Q22 disks existed on MSCP, of course.  And RL02 also, if I remember right.

There is the 2 board RLV11, which is 18-bit, and the preferred 22-bit
single-board RLV12.  I have both.  I started with a BA11-N box in 1986
and didn't mind one bit paying $100 for an RLV11 and taking up two
slots (the RLV12 was still full price at the time).  For any MicroVAX
or a MicroPDP in a BA23, can't beat the RLV12.  I have one in a bag
waiting for me to have some time to build up an RL02 image slurping
box (having recently repaired the line filter caps in a BA23).

-ethan

Re: Unibus disk controller with modern storage

[Paul Koning]

> On Oct 20, 2016, at 4:27 PM, Noel Chiappa  wrote:
> 
>> From: Paul Koning
> 
>> I'd suggest the Massbus series, they are just about as simple as
>> anything and that's where you find the largest capacities short of MSCP
>> devices. 
> 
> If you want to exactly emulate only DEC controllers, yes. (Of course, such a
> project should do that, for binary compatability.)
> 
> However, as I think I have mentioned before, I'm actually enamoured of taking
> a very simple controller like an RP11, which has lots of spare disk address
> bits, and defining an 'RP11-E' which maxes out the virtual drive size without
> changing _anything_ about the register format other than using unused bits in
> the cyclinder address register. That will produce disks with 2^28 blocks, or
> 2^36 bytes, or 64GB. That's most of a large SD card... :)

That's fine if your target is an OS for which you can write drivers.  It 
wouldn't help RSTS users.

> 
> Not too useful to those without the ability to tweak drivers, but...  there's
> another issue with the older controllers, which is that they only support
> 18-bit addressing, and for use on QBUS machines, where one would really like
> to be able to do DMA to anywhere in the 22-bit space (for Unix, this would be
> for swapping, and raw I/O - buffered I/O would be fine with 18 bits). So maybe
> an updated version of those old, simple controllers would actually have some
> use. (I'd certainly want them for my Unix boxes.)

Q22 disks existed on MSCP, of course.  And RL02 also, if I remember right.

> 
>> Apart from MSCP, avoid RL emulation also.
> 
> Why avoid RL's? Not the greatest controller, I agree, but it is a 'lowest
> common denominator' drive for a certain era of gear.

Significantly uglier program interface, so more complex emulation compared to 
RK05 or RP06.  Not nearly as hard as MSCP, of course.

A possible answer for a lot of this is to do the actual emulation algorithms in 
software, in an embedded CPU inside the FPGA.  For MSCP that's obvious, but it 
would work for the others as well I suspect.  The main trick is to have the 
register side effects done right.  That can get complicated, as the DMC-11 
example illustrates.

paul

Re: Unibus disk controller with modern storage

[Paul Koning]

> On Oct 20, 2016, at 4:14 PM, Ethan Dicks  wrote:
> 
> On Wed, Oct 19, 2016 at 7:46 PM, Paul Koning  wrote:
>> Actually, Unibus has very straightforward timing.  It certainly should be a 
>> breeze with an FPGA, but the original designs (nicely spelled out in the 
>> back of the early Peripherals Handbooks, or later on in the Unibus Handbook) 
>> take just a handful of MSI ICs.
> 
> Then there's the interminable wrestling with "what driver ICs to use".
> I have an abundance of the real thing (DC013 and NS8641, because I
> used to make a peripheral), but modern equivalents all fall short in
> one way or another.  You _can_ get away with a variety of
> substitutions, but the question then becomes when those compromises
> sum up to bite you.

I would treat this as an analog problem, putting some op amps and comparators 
to work.  It doesn't seem to rise to the level where D/A devices are needed.  
:-)

> 
>> Yes, a non-MSCP disk would be a good choice.  I'd suggest the Massbus 
>> series, they are just about as simple as anything and that's where you find 
>> the largest capacities short of MSCP devices.
> 
> With widespread driver support (because who wants to write a wad of
> drivers for different operating systems and different _versions_ of
> operating systems - VMS4 vs VMS5 w/SMP anyone?  Done that already!).
> 
> The worst thing about rolling your own  controller is needing to write
> all the drivers, thus the interest in something universal, like MSCP -
> the interface to the bus, the register model, is all set and somewhat
> clear.  Implementation details are invisible to the bus or OS.  OTOH,
> rolling your own MSCP device is hardly a starter project.

Right.  I meant an existing non-MSCP non-RL device.  Most other disks have 
extremely straightforward register command sets; RK05, RP06, the details differ 
but the general approach is very easy.

Any non-DEC disk would be a problem.  Writing drivers is a pain if it's even 
possible; for some operating systems like RSTS it flat out isn't supported.

paul

Re: Unibus disk controller with modern storage

[Noel Chiappa]

> From: Paul Koning

> I'd suggest the Massbus series, they are just about as simple as
> anything and that's where you find the largest capacities short of MSCP
> devices. 

If you want to exactly emulate only DEC controllers, yes. (Of course, such a
project should do that, for binary compatability.)

However, as I think I have mentioned before, I'm actually enamoured of taking
a very simple controller like an RP11, which has lots of spare disk address
bits, and defining an 'RP11-E' which maxes out the virtual drive size without
changing _anything_ about the register format other than using unused bits in
the cyclinder address register. That will produce disks with 2^28 blocks, or
2^36 bytes, or 64GB. That's most of a large SD card... :)

Not too useful to those without the ability to tweak drivers, but...  there's
another issue with the older controllers, which is that they only support
18-bit addressing, and for use on QBUS machines, where one would really like
to be able to do DMA to anywhere in the 22-bit space (for Unix, this would be
for swapping, and raw I/O - buffered I/O would be fine with 18 bits). So maybe
an updated version of those old, simple controllers would actually have some
use. (I'd certainly want them for my Unix boxes.)

> Apart from MSCP, avoid RL emulation also.

Why avoid RL's? Not the greatest controller, I agree, but it is a 'lowest
common denominator' drive for a certain era of gear.


> From: Toby Thain

> Isn't Noel working on something related?

I think Dave B gave a pretty good update.

In addition to what he mentioned, I'd like to mention the indicator panels
(like the DEC ones for the RF11, RP11, etc). Dave has designed the new
indicator PCB, and we have a couple of prototype PCB's in hand, stuffed and
working. I think there's a video clip of it doing its thing on the Web page he
pointed to.

Our concept is that we'll be able to drive more than one of these panels, by
connecting them together serially - that way a machine could have, say, both
RK11 and RP11 indicator panels, driven from a single QSIC board. That will
slow down the refresh rate a bit, but our numbers indicate it should still be
acceptably fast.

Noel

Re: Unibus disk controller with modern storage

[Ethan Dicks]

On Wed, Oct 19, 2016 at 7:46 PM, Paul Koning  wrote:
> Actually, Unibus has very straightforward timing.  It certainly should be a 
> breeze with an FPGA, but the original designs (nicely spelled out in the back 
> of the early Peripherals Handbooks, or later on in the Unibus Handbook) take 
> just a handful of MSI ICs.

Then there's the interminable wrestling with "what driver ICs to use".
I have an abundance of the real thing (DC013 and NS8641, because I
used to make a peripheral), but modern equivalents all fall short in
one way or another.  You _can_ get away with a variety of
substitutions, but the question then becomes when those compromises
sum up to bite you.

> Yes, a non-MSCP disk would be a good choice.  I'd suggest the Massbus series, 
> they are just about as simple as anything and that's where you find the 
> largest capacities short of MSCP devices.

With widespread driver support (because who wants to write a wad of
drivers for different operating systems and different _versions_ of
operating systems - VMS4 vs VMS5 w/SMP anyone?  Done that already!).

The worst thing about rolling your own  controller is needing to write
all the drivers, thus the interest in something universal, like MSCP -
the interface to the bus, the register model, is all set and somewhat
clear.  Implementation details are invisible to the bus or OS.  OTOH,
rolling your own MSCP device is hardly a starter project.

>  ... Apart from MSCP, avoid RL emulation also.

While RL emulation is complex, one advantage is that the OS support
for the RL is nearly ubiquitous.

> How small is the smallest possible Unibus DMA card?  Quad, if I remember 
> right, because of where the NPR/NPG wires live?

The RX211 (M8256) is a quad-height card that does DMA.  There are
various quad-height tape controllers that should too, IIRC.  Mostly,
DMA peripherals are hex height because they can be and there's plenty
of silicon to fill a hex card, but that's about real estate not about
reaching certain Unibus pins.

-ethan

Re: Unibus disk controller with modern storage

[william degnan]

>
>
>> From what I understand, there could be a great demand of a such
>> interface here around?
>>
>
> Been thinking about this for more than 10 years :-(
>
> Isn't Noel working on something related?
>
> Btw, MSCP isn't really as complex as its reputation... While I'm not an
> expert, the hard parts of this project seem to be the boring bits -- the
> mechanical interface, the drivers/transceivers, and all that. Once that's
> taken care of, the software/fpga is the fun bit. Imho, etc.
>
> --Toby
>
>
>
>>
a starting point might be simH, carving out the drive/storage component
from there and building some sort of stand-alone simH drive using a
Raspberry Pi or something.  That's what comes to mind if it were me making
a drive for a UNIBUS system.  A card to interface with simH as a real drive
would, not just a serial port.

b

Unibus disk controller with modern storage

[shadoooo]

Hello,
I read several posts about Unibus disk interfaces and emulation.
One of my retrocomputing dream is to design an Unibus universal board,
probably based on FPGA because of precise timing requirements,
to emulate one or more disk/tape interfaces, and possibly something more.
The real storage could be based on SD card, so very easy to be moved
to a PC for imaging and data transfer.
Probably a low level emulation would be quite easy, while a more complex
solution (MSCP) could be more difficult.
The board itself wouldn't be cheap at all, because PCB would be big,
and because FPGA aren't cheap either.
Probably it would be anyway cheaper than an MSCP-SCSI, and it would be 
far more

flexible.

From what I understand, there could be a great demand of a such 
interface here around?


Andrea

Re: Unibus disk controller with modern storage

[william degnan]

OH yah

Bill Degnan
twitter: billdeg
vintagecomputer.net
On Oct 19, 2016 6:48 PM, "shad"  wrote:

> Hello,
> I read several posts about Unibus disk interfaces and emulation.
> One of my retrocomputing dream is to design an Unibus universal board,
> probably based on FPGA because of precise timing requirements,
> to emulate one or more disk/tape interfaces, and possibly something more.
> The real storage could be based on SD card, so very easy to be moved
> to a PC for imaging and data transfer.
> Probably a low level emulation would be quite easy, while a more complex
> solution (MSCP) could be more difficult.
> The board itself wouldn't be cheap at all, because PCB would be big,
> and because FPGA aren't cheap either.
> Probably it would be anyway cheaper than an MSCP-SCSI, and it would be far
> more
> flexible.
>
> From what I understand, there could be a great demand of a such interface
> here around?
>
> Andrea
>
>
>

Re: Unibus disk controller with modern storage

[David Bridgham]

On 10/19/2016 06:48 PM, shad wrote:
>
> One of my retrocomputing dream is to design an Unibus universal board,
> probably based on FPGA because of precise timing requirements,
> to emulate one or more disk/tape interfaces, and possibly something more.
> The real storage could be based on SD card

You mean, perhaps, something like this?

http://pdp10.froghouse.org/qsic/html/overview.html

Noel and I started working on this project about a year ago.  I've been
away all summer, working in the wilds in Alaska, so the project stalled
for the last six months.  I'm home now and getting back into normal life
so it's time to restart.  Here's a quick status report on how far we got.

Noel wire-wrapped two prototype boards with the bus drivers and level
converters.  We have those cabled to a ZTEX FPGA module for
development.  I was working on the Verilog in the FPGA.  We got to the
point where we had all the basic QBUS bus cycles working: device
register reads and writes, bus grant, DMA reads and writes, and
interrupt cycles.  We hacked up a quick and dirty RK11 using just
internal FPGA memory for the "disk" storage and wrote some C code to
exercise all those QBUS operations.  It seems solid.  The short video of
the indicator panel on that website above is running that exerciser program.

Where we're sitting now is that the next step is to wire up an SD card
and start writing the Verilog to access it.  It's a little daunting
though not as daunting as implementing the USB protocols in the FPGA. 
I'm hoping that doing the SD card will pave the way for more complex
things like USB.

Dave

Re: Unibus disk controller with modern storage

[Pontus Pihlgren]

On Thu, Oct 20, 2016 at 12:48:18AM +0200, shad wrote:
> 
> From what I understand, there could be a great demand of a such interface
> here around?
> 

I think so yes, not everyone is so lucky as to have massbus or SDI disks 
lying arround. Loose CPU boxes seems far more common.

/P

Re: Unibus disk controller with modern storage

[Fritz Mueller]

On Oct 19, 2016 6:48 PM, "shad"  wrote

Hello,
I read several posts about Unibus disk interfaces and emulation.
One of my retrocomputing dream is to design an Unibus universal board,
probably based on FPGA because of precise timing requirements,
to emulate one or more disk/tape interfaces, and possibly something more.
The real storage could be based on SD card, so very easy to be moved
to a PC for imaging and data transfer.
Probably a low level emulation would be quite easy, while a more complex
solution (MSCP) could be more difficult.
The board itself wouldn't be cheap at all, because PCB would be big,
and because FPGA aren't cheap either.
Probably it would be anyway cheaper than an MSCP-SCSI, and it would be far
more
flexible.


A good way to go on this might be just a small paddle card with Unibus 
drivers, level conversion, and some shift-register chains, which could 
then be interfaced easily to any number of off-the-shelf FPGA 
prototyping boards (the latter having the advantage of being quite 
cheap, with many integrated peripherals like ethernet, SD slots, USB 
serial, etc. and having tool chain support out of the box).


I've seen a few projects started like this out in the wilds, but none 
seem to have made it past the debug stage.


It would be super useful -- you could emulate all sorts of peripherals 
as well as memory, or you could configure it as a Unibus analyzer, or 
emulate a CPU to debug peripherals.


--FritzM.

Re: Unibus disk controller with modern storage

[Toby Thain]

On 2016-10-19 6:48 PM, shad wrote:

Hello,
I read several posts about Unibus disk interfaces and emulation.
One of my retrocomputing dream is to design an Unibus universal board,
probably based on FPGA because of precise timing requirements,
to emulate one or more disk/tape interfaces, and possibly something more.
The real storage could be based on SD card, so very easy to be moved
to a PC for imaging and data transfer.
Probably a low level emulation would be quite easy, while a more complex
solution (MSCP) could be more difficult.
The board itself wouldn't be cheap at all, because PCB would be big,
and because FPGA aren't cheap either.
Probably it would be anyway cheaper than an MSCP-SCSI, and it would be
far more
flexible.

From what I understand, there could be a great demand of a such
interface here around?


Been thinking about this for more than 10 years :-(

Isn't Noel working on something related?

Btw, MSCP isn't really as complex as its reputation... While I'm not an 
expert, the hard parts of this project seem to be the boring bits -- the 
mechanical interface, the drivers/transceivers, and all that. Once 
that's taken care of, the software/fpga is the fun bit. Imho, etc.


--Toby




Andrea

Re: Unibus disk controller with modern storage

[Eric Smith]

On Wed, Oct 19, 2016 at 4:48 PM, shad  wrote:

> The board itself wouldn't be cheap at all, because PCB would be big,
>

True. From a Chinese vendor such as PCBway, a DEC quad size double-sided
PCB without ENIG (immersion) gold surface finish but without hard-gold edge
fingers costs $15.10 each in quantity 10, and a hex side PCB costs $20.40
each.  However, the ENIG gold is quite thin and won't withstand very many
backplane insertions.  The cheap PCB vendors don't offer hard gold edge
fingers. Jon Elson pointed out that E-TekNet in Arizona does offer hard
gold at better prices than some fab houses, but still a lot more than the
cheap Chinese PCBs.

I prefer NOT to use ENIG, as I find HASL tin-lead better for hand assembly,
though the lead is a problem due to RoHS regulations in much of the world
(but not in USA). I haven't tried HASL lead-free.


> and because FPGA aren't cheap either.
>

Xilinx XC6SLX9-2TQG144C is probably big enough for such things, and only
costs $16.52 in quantity 1 from Digi-Key.  It's in a TQFP, so not *too*
difficult to deal with. It has essentially 11,440 logic cells (5-LUT with
FF)*,  32 block RAMs of 18 Kbits each, and 102 3.3V I/O pins. It's not 5V
tolerant, but no modern parts are. 5V tolerance can be achieved in many
cases by the use of series resistors, but I like using the TI
SN74CBTD3861DGVR bus switch/voltage clamp, which can make 10 I/O pins 5V
tolerant at a cost of $0.62 in quantity 1. The bus switch is advantageous
over series resistors because it doesn't add much series resistance to pins
that are being used as outputs, and it has a maximum propagation delay of
0.25ns.

If you need more FPGA capability, the XC7A15T-1FTG256C has substantially
more resources, and costs $25.69 in quantity 1.  It's in a 256 ball BGA, so
somewhat harder to deal with, and needs at least a four layer board,
possibly even six layer.  However, it has 20,800 logic cells (5-LUT with
FF), 25 block RAMs of 36 Kbits each, and 170 3.3V I/O pins.

If you need more resources than that, it turns out that the XC7A15T,
XC7A35T, and XC7A50T are actually all the same die, just factor-programmed
with a different device ID. The 35T and 50T have double and triple the
logic cells and block RAMs of the 15T. The Vivado FPGA toolchain
artificially limits the resource usage of the two smaller parts, but
doesn't actually restrict which specific logic cells and block RAMs are
used, which means that the 15T and 35T have silicon that passes the factory
testing for ALL resources, not just 1/3 or 2/3 of them. It's been verified
that one can change the device ID in the bitstream, disable bitstream CRC
checking, and use the smaller part as a larger part. I don't like disabling
the CRC, because it serves to protect the FPGA from damage if the bitstream
has been corrupted, so I wrote a program that can both change the device ID
and recompute the CRC. I don't yet have a board with a 15T or 35T to test
with, but I'll release the program as open source once I do.

Because going to a 4 layer or 6 layer board is quite expensive when the
board size is large, e.g., DEC quad or hex size, I think it makes sense to
put the FPGA, its configuration flash, voltage regulators, and the bus
switches for 5V tolerance on a daughterboard. I've been working on such a
design, with two 96-pin DIN connectors for connection to the main board,
and at least 160 GPIOs available. The main board can then be just
double-sided, and possibly even 100% through-hole, for people that don't
want to hand-assemble boards with surface-mount components. The drawback is
that it will occupy more than one backplane slot due to the height.

There's still the problem that no current production bus interface ICs meet
Unibus, Qbus, or Omnibus specifications. Surplus DS8641 chips are
technically the best choice. With modern chips, it's necessary to use
separate drivers and receivers, and still difficult to meet the full specs.
Compromising the specs is possible but may make things unreliable in a
large system (multiple backplanes with cables, and many other cards).

Eric

* Xilinx has some other confusing definition of a "logic cell" for
marketing purposes, which is not the same as a LUT+FF. Oddly enough, their
marketing logic cell count is actually lower than a sensible accounting,
which is the opposite of how FPGAs used to be rated in exaggerated gate
counts, which we derided as "marketing gates".

The 6-series and 7-series actually have 6-LUTs with 2 FF each, but they can
be used as two 5-LUTs with 1 FF each, which is how I count them for
assessing the FPGA's logic capacity.

Re: Unibus disk controller with modern storage

[Paul Koning]

> On Oct 19, 2016, at 6:48 PM, shad  wrote:
> 
> Hello,
> I read several posts about Unibus disk interfaces and emulation.
> One of my retrocomputing dream is to design an Unibus universal board,
> probably based on FPGA because of precise timing requirements,
> to emulate one or more disk/tape interfaces, and possibly something more.
> The real storage could be based on SD card, so very easy to be moved
> to a PC for imaging and data transfer.
> Probably a low level emulation would be quite easy, while a more complex
> solution (MSCP) could be more difficult.
> The board itself wouldn't be cheap at all, because PCB would be big,
> and because FPGA aren't cheap either.
> Probably it would be anyway cheaper than an MSCP-SCSI, and it would be far 
> more
> flexible.

Actually, Unibus has very straightforward timing.  It certainly should be a 
breeze with an FPGA, but the original designs (nicely spelled out in the back 
of the early Peripherals Handbooks, or later on in the Unibus Handbook) take 
just a handful of MSI ICs.

Yes, a non-MSCP disk would be a good choice.  I'd suggest the Massbus series, 
they are just about as simple as anything and that's where you find the largest 
capacities short of MSCP devices.  And even an RP07 fits comfortably on a small 
SD card.  Or 8 of them, for that matter.  Apart from MSCP, avoid RL emulation 
also.

SD is actually the hardest part, at least the initialization.  If there's off 
the shelf IP that handles that state machine, the rest is simple.  
Alternatively, is CompactFlash still around?  That's just an ATA interface, 
really easy.

How small is the smallest possible Unibus DMA card?  Quad, if I remember right, 
because of where the NPR/NPG wires live?

paul