27 May
2017
27 May
'17
6:15 p.m.
So I had a random thought in the wee hours this morning and I leave it
to you, the cctalk braintrust, to tell me exactly how stupid this idea is:
I have a VAX-11/750, an Able QNiverter (UNIBUS->Qbus adapter), a 22-bit
Qbus backplane, and a VCB02 (QDSS) 4-bit graphics boardset.
Theory: With an appropriately modified NetBSD driver for the VCB02, such
that it provides only 18-bit addresses to the VCB02's DMA engine, I can
get X running on the VCB02 on the 11/750.
That is, the configuration is: 11/750->Unibus->QNiverter->Qbus->VCB02.
Obviously the console functionality of the VCB02 won't work since that
requires support on the VAX side of things that won't be present, but I
think everything else should work. I've browsed the technical manual
and I don't see anything that should get in the way, I'll just need to
hack up the driver appropriately.
But this is something that randomly popped into my head (I was inspired
by a research paper, "A VAX Based Data Acquisition Computer System at
the Nuclear Structure Research Laboratory" wherein a Matrox QRGB Qbus
graphics board was lashed to an 11/750 in a similar manner...
What say you all?
- Josh
28 May
28 May
2:55 a.m.
My knowledge of Qbus and Unibus is incredibly spars, but I would be
interested in knowing how this pans out. At the very least, I would
expect NetBSD to be able to see a keyboard attached to the VCB02?
Aaron.
Josh Dersch via cctalk writes:
So I had a random thought in the wee hours this
morning and I leave it
to you, the cctalk braintrust, to tell me exactly how stupid this idea
is:
I have a VAX-11/750, an Able QNiverter (UNIBUS->Qbus adapter), a
22-bit Qbus backplane, and a VCB02 (QDSS) 4-bit graphics boardset.
Theory: With an appropriately modified NetBSD driver for the VCB02,
such that it provides only 18-bit addresses to the VCB02's DMA engine,
I can get X running on the VCB02 on the 11/750.
That is, the configuration is: 11/750->Unibus->QNiverter->Qbus->VCB02.
Obviously the console functionality of the VCB02 won't work since that
requires support on the VAX side of things that won't be present, but
I think everything else should work. I've browsed the technical
manual and I don't see anything that should get in the way, I'll just
need to hack up the driver appropriately.
But this is something that randomly popped into my head (I was
inspired by a research paper, "A VAX Based Data Acquisition Computer
System at the Nuclear Structure Research Laboratory" wherein a Matrox
QRGB Qbus graphics board was lashed to an 11/750 in a similar
manner...
What say you all?
- Josh
--
Aaron Jackson
PhD Student, Computer Vision Laboratory, Uni of Nottingham
http://aaronsplace.co.uk/
4:59 a.m.
On 5/27/2017 6:15 PM, Josh Dersch via cctalk wrote:
What say you all?
- Josh
The biggest possible train wreck if I see what you are up to, is if
there are any test and set spin locks for semaphores and the like in the
code. I know Sun had huge numbers of tricks on Sparc to run different
runtimes when there were different Sparc memory behaviors.
I don't know if the PDP 11 code between the buss types had to sense and
alter behavior. And I wonder if the quniverter will do its job with the
timing to grab the copy, and swap or whatever is needed for the operation.
Is the quniverter set up to handle any type of memory no matter what
purpose?
thanks
Jim
5:13 a.m.
On 05/27/2017 09:15 PM, Josh Dersch via cctalk wrote:
So I had a random thought in the wee hours this
morning and I leave it
to you, the cctalk braintrust, to tell me exactly how stupid this idea
is:
I have a VAX-11/750, an Able QNiverter (UNIBUS->Qbus adapter), a
22-bit Qbus backplane, and a VCB02 (QDSS) 4-bit graphics boardset.
Theory: With an appropriately modified NetBSD driver for the VCB02,
such that it provides only 18-bit addresses to the VCB02's DMA engine,
I can get X running on the VCB02 on the 11/750.
That is, the configuration is: 11/750->Unibus->QNiverter->Qbus->VCB02.
Should work with one thing I can think of the VCB02 is Q22 not Q18. Its
22bit.
The VAX hardware is for memory 32bit and for IO only 16bit. ( A 16 bit
segment mapped to IO.)
The bit map is mapped as Q22 memory.
Obviously the console functionality of the VCB02
won't work since that
requires support on the VAX side of things that won't be present, but
I think everything else should work. I've browsed the technical
manual and I don't see anything that should get in the way, I'll just
need to hack up the driver appropriately.
It works in a Qbus microVAX! However starting up you will need a
terminal until it all works.
Part of getting it all working is a NETBSD build for the odd concoction.
But this is something that randomly popped into my
head (I was
inspired by a research paper, "A VAX Based Data Acquisition Computer
System at the Nuclear Structure Research Laboratory" wherein a Matrox
QRGB Qbus graphics board was lashed to an 11/750 in a similar manner...
What say you all?
- Josh
3:47 p.m.
On Sun, 28 May 2017, allison via cctalk wrote:
Depending on circumstances the DMA address space limitation can be
tackled either by avoiding allocating memory for DMA outside the range
supported by the device doing DMA or by using memory remapping, either
with an IOMMU if available, or via software means aka bounce buffers.
Support for the chosen logic will likely have to be placed then in a
device driver for the QNiverter bus bridge.
I suppose NetBSD will have some generic means of support for these
techniques as this has been a common issue with many computer buses, which
have run out of address lines needed to access all the system memory as
DRAM capacities have grown. The bus bridge device driver might then be
able to hook into it appropriately, serving any DMA-capable devices behind
the bridge in a uniform way, without individual device drivers having to
know their wiring.
I have a
VAX-11/750, an Able QNiverter (UNIBUS->Qbus adapter), a
22-bit Qbus backplane, and a VCB02 (QDSS) 4-bit graphics boardset.
Theory: With an appropriately modified NetBSD driver for the VCB02,
such that it provides only 18-bit addresses to the VCB02's DMA engine,
I can get X running on the VCB02 on the 11/750.
That is, the configuration is: 11/750->Unibus->QNiverter->Qbus->VCB02.
Should work with one thing I can think of the VCB02 is Q22 not Q18. Its
22bit.
The VAX hardware is for memory 32bit and for IO only 16bit. ( A 16 bit
segment mapped to IO.)
The bit map is mapped as Q22 memory. > But this is something that randomly popped into
my head (I was
> inspired by a research paper, "A VAX Based Data Acquisition Computer
> System at the Nuclear Structure Research Laboratory" wherein a Matrox
> QRGB Qbus graphics board was lashed to an 11/750 in a similar manner...
>
> What say you all?
By all means do try it!
Although not nearly as complex I have once tried a 24-plane TURBOchannel
SFB+ graphics adapter in a VAXstation 4000/90 with the Linux TGA/SFB+
driver and it worked just fine as the OS console device, despite that I
suppose nobody has actually envisaged such use, and there's nothing
specific to the VAXstation in the TGA/SFB+ driver (originally written for
the Alpha port and the PCI bus). I haven't tried X11, because the port
was too immature/unstable to attempt compiling it, but I suppose it would
just work given that other communication with the graphics hardware did.
FWIW,
Maciej
2765
days inactive
2765
days old
4 comments
5 participants
participants (5)
-
aaron＠aaronsplace.co.uk -
allisonportable＠gmail.com -
derschjo＠gmail.com -
jwsmail＠jwsss.com -
macro＠linux-mips.org