19 Oct
2016
19 Oct
'16
6:48 p.m.
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
19 Oct
19 Oct
7:46 p.m.
On Oct 19, 2016, at 6:48 PM, shadoooo <shadoooo at
gmail.com> 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
20 Oct
20 Oct
4:14 p.m.
On Wed, Oct 19, 2016 at 7:46 PM, Paul Koning <paulkoning at comcast.net> 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
4:27 p.m.
On Oct 20, 2016, at 4:14 PM, Ethan Dicks
<ethan.dicks at gmail.com> wrote:
On Wed, Oct 19, 2016 at 7:46 PM, Paul Koning <paulkoning at comcast.net> 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. :-)
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. 
5:21 p.m.
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.
19 Oct
19 Oct
8:23 p.m.
On Wed, Oct 19, 2016 at 4:48 PM, shadoooo <shadoooo at gmail.com> 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.
20 Oct
20 Oct
4:44 p.m.
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
19 Oct
19 Oct
9:07 p.m.
OH yah
Bill Degnan
twitter: billdeg
vintagecomputer.net
On Oct 19, 2016 6:48 PM, "shadoooo" <shadoooo at gmail.com> 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
9:24 p.m.
On Oct 19, 2016 6:48 PM, "shadoooo" <shadoooo at gmail.com> 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.
10:15 p.m.
On 2016-10-19 6:48 PM, shadoooo 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
11:35 p.m.
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
> 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
20 Oct
20 Oct
2:51 a.m.
On Thu, Oct 20, 2016 at 12:48:18AM +0200, shadoooo 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
9:45 a.m.
On 10/19/2016 06:48 PM, shadoooo 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
4:21 p.m.
On Fri, Oct 21, 2016 at 2:45 AM, David Bridgham <dab at froghouse.org> wrote:
On 10/19/2016 06:48 PM, shadoooo wrote:
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.'
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
4:55 p.m.
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
2841
days inactive
2842
days old
14 comments
11 participants
participants (11)
-
billdegnan＠gmail.com -
dab＠froghouse.org -
ethan.dicks＠gmail.com -
fritzm＠fritzm.org -
jonelson126＠gmail.com -
paulkoning＠comcast.net -
pontus＠Update.UU.SE -
shadoooo＠gmail.com -
spacewar＠gmail.com -
tmfdmike＠gmail.com -
toby＠telegraphics.com.au