5 Aug
2009
5 Aug
'09
9:59 p.m.
Hi folks,
what do you think about a Unibus to PCI bridge?
I think such a device - if well done - could be real fun. There has been a commercial
approach
somewhere - but it doesn't seem to be available anymore.
Hardware needed: A PCI board with an FPGA and full Unibus connection.
Possible features:
* Unibus mapping into PC address space.
Makes Unibus devices and memory directly visible to the PC. Porting of old Unix drivers
for RK, RP,
TC, and friends could become possible.
* Unibus bus arbitration (if no CPU with arbiter on the bus)
* Unibus memory implementation
* Unibus->PCI interrupt forwarding
With those features (arbiter and memory only if not already present on the bus) it should
be
possible to use ALL Unibus peripherals from the PC. Make memory dumps of a running system
(Unibus is
multi master capable). It would even become possible to integrate real peripherals with
SIMH :-)
Possible addons:
* QBus interface
* Unibus mass storage device implementations (using a storage card on the FPGA board or
the PC)
I'm thinking of this because I got a whole bunch of Unibus stuff (CPUs and
peripherals) in unknown
condition.
Comments welcome!
Best wishes,
Philipp :-)
--
http://www.hachti.de
6 Aug
6 Aug
4:39 a.m.
On Thu, 06 Aug 2009 03:59:24 +0200
Philipp Hachtmann <hachti at hachti.de> wrote:
Possible features:
You will need an IOMMU, a
"UniBus map", also. UniBus has 18 address
bits, QBus 22. UniBus and QBus peripherals use bus master DMA to move
data into main memory. But with only 18 / 22 Address bits these
peripherals can't access the whole main memory. You would need ugly
hacks like DMA bounce buffers and double memory copies to work around
that. Therefore you need a programmable I/O memory management unit in
the bus bridge that translates UniBus to PCI addresses. Have a look at
the QBus / UniBus map / IOMMU on VAXen... Keep in mind that todays
PeeCees are 64 bit...
* Unibus->PCI interrupt forwarding
Most
likely you will need some sort of slave interrupt controller.
And when you do it: Make it UniBus or QBus selectable.
--
tsch??,
Jochen
Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/
7 Aug
7 Aug
1:29 a.m.
Hi Jochen,
Hm. Of course. The interrupts could be directly passed on to
the PC. But for the vectors, there must
be built a small interrogation circuit. But... Every FPGA you can buy today has more
capacities than
it needs to do all that, even more, and containing a complete VAX implementation plus a
pdp11 plus a
pdp8....
You will need an IOMMU, a "UniBus map",
also. UniBus has 18 address
bits, QBus 22. UniBus and QBus peripherals use bus master DMA to move
data into main memory. But with only 18 / 22 Address bits these
peripherals can't access the whole main memory.
Do I? I don't even know
what you mean! I would map the entire 18/22 bit address space into the PC
address space. From a PC point of view, the complete Unibus address space will be visible
with a
certain address offset (defined by the PnP Bios and friends, who assign the addresses).
The Unibus side will not be able to look into the PC. But.... see nex paragraph.
You would need ugly
hacks like DMA bounce buffers and double memory copies to work around
that.
What about simply some memory on the Unibus (I don't mention Qbus for
saving keypresses)? Everything
on the Unibus can see memory on the Unibus. And the PC as well. That makes thinks quite
easy.
Yes, there is a performance impact this way because your Unibus peripherals cannot copy
their data
*somewhere* into the PC address space. But I simply don't mind :-)
The Unibus memory could also be integrated into the controller. That would probably that
what you
call DMA bounce buffer. But that's no black magic, I suppose.
Therefore you need a programmable I/O memory
management unit in
the bus bridge that translates UniBus to PCI addresses. Have a look at
the QBus / UniBus map / IOMMU on VAXen... Keep in mind that todays
PeeCees are 64 bit...
As stated above, I will luckily live without :-)
When I read a block of data from a device, the device *slowly* fills a buffer somewhere it
can see.
Then I take it out. I don't mind the time I need to pull/push that data.
With a fast buffer, the PC can initiate a new transfer, service the buffer, and wait for
hours until
the next portion of data has been processed by the Unibus peripheral!
*
Unibus->PCI interrupt forwarding
Most likely you will need some sort of slave
interrupt controller. And when you do it: Make it UniBus or QBus selectable.
Yes, that's a good idea. Must get a card that can interface to both. The rest is
software.
Best wishes,
Philipp
--
http://www.hachti.de
8 Aug
8 Aug
3:37 a.m.
On Fri, 07 Aug 2009 07:29:19 +0200
Philipp Hachtmann <hachti at hachti.de> wrote:
If
we take a 18 bit PDP like the PDP-11/34 everything lives on the
UniBus. Everything has at max. 18 bit addresses. No DMA problems here.
Every UniBus master can reach all memory when doing DMA.
Now imagin somthing like a PDP-11/70 or a VAX. The CPU has more then 18
address bits and memory lives on another bus then the UniBus. The OS
needs the data somewhere in memory. If the bus bridge does no address
translation a UniBus peripheral can reach only the lower 256 kB of RAM.
So if output has to happen the OS needs to copy the data somewhere into
the lower 256 kB RAM. Then it needs to initiate the I/O. If this has
finished (interrupt) it needs to copy possible input from the lower 256
kB to somewhere else in RAM where the OS needs it.
This is ugly. All data needs to be touched twice from the CPU. The OS
has to reserve a region of _continious,_physical_ RAM that can be seen
by the UniBus. This may be difficould to archieve for the OS or its
memory management.
What 22 bit PDP-11s and VAXen do is somthing like this: The UniBus
bridge has an I/O Memory Management Unit build in. DEC calls it the
UniBus map. The UniBus map has a page table. If a UniBus master
initiates a memory access the UniBus map takes the addess issued by the
bus master. It splits the UniBus address in a lower and upper part to
construct the CPU side address. The lower part is 9 bits (= 512 bytes,
the VAX page size). These lower 9 bits are copied 1:1 from the UniBus
address into the CPU side address. The upper 9 bits of the UniBus
address are used as an index into the IOMMU page table. The page table
entry contains some permission bits (read, write, ...) and the upper 23
bits of the 32 bit CPU address. This way a 18 bit UniBus address is
translated into a 32 bit CPU address.
This is very elegant. If I/O has to be done the OS programms the UniBus
map with the apropriate translation and initiates the I/O. Due to the
address translation, that happens invisible to the UniBus device, a
UniBus master DMA can reach the full range of the 32 bit CPU address
space. It also enables scatter gather DMA for UniBus peripherals that
don't support it. The UniBus peripheral may see only a single
continious UniBus DMA memory target. But the UniBus map can split up
this into several regions.
If there is no valid entry in the page table of the UniBus map main
memory is protected against UniBus peripherals go amok, because the bus
bridge will not allow access from any UniBus device into main memory.
UniBus access must be granted explicitely and can be limited to ceartin
regions.
Therefore: If you design a PCI-UniBus bridge _*PLEASE*_ implement a
proper IOMMU / UniBus map. Everything else will be a ugly kludge.
Just copy the VAX UniBus map and you are done. It does exactely what
is needed.
That would be a
DMA bounce buffer in hardware. This is still ugly and
defeats the reason for DMA.
You
will, as it simplifies your hardware design. But it will be a
nightmare to the OS programmer that has to fight with it writing a
device driver for it. PeeCees suffered from this in the ISA bus era.
Now PeeCees suffering from the same problem as PeeCee CPUs have gone
64 bit but PCI is still 32 bit and there is no proper IOMMU in a PeeCee
PCI host bridge. Have a look into Suns or Alphas. They have PCI host
bridges with IOMMU build in.
--
tsch??,
Jochen
Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/
You will need
an IOMMU, a "UniBus map", also. UniBus has 18 address
bits, QBus 22. UniBus and QBus peripherals use bus master DMA to move
data into main memory. But with only 18 / 22 Address bits these
peripherals can't access the whole main memory.
Do I? I don't even know
what you mean! I would map the entire 18/22 bit address space into the PC
address space. From a PC point of view, the complete Unibus address space will be visible
with a
certain address offset (defined by the PnP Bios and friends, who assign the addresses).
The Unibus side will not be able to look into the PC. But.... see nex paragraph. You would need
ugly
hacks like DMA bounce buffers and double memory copies to work around
that.
What about simply some memory on the Unibus (I don't mention Qbus for
saving keypresses)? Everything
on the Unibus can see memory on the Unibus. And the PC as well. That makes thinks quite
easy.
Yes, there is a performance impact this way because your Unibus peripherals cannot copy
their data
*somewhere* into the PC address space. But I simply don't mind :-)
The Unibus memory could also be integrated into the controller. That would probably that
what you
call DMA bounce buffer. But that's no black magic, I suppose. Therefore you
need a programmable I/O memory management unit in
the bus bridge that translates UniBus to PCI addresses. Have a look at
the QBus / UniBus map / IOMMU on VAXen... Keep in mind that todays
PeeCees are 64 bit...
As stated above, I will luckily live without :-)
7:19 a.m.
Salut again,
Yes.
Now imagin somthing like a PDP-11/70 or a VAX. The CPU
has more then 18
address bits and memory lives on another bus then the UniBus. The OS
needs the data somewhere in memory. If the bus bridge does no address
translation a UniBus peripheral can reach only the lower 256 kB of RAM.
So if output has to happen the OS needs to copy the data somewhere into
the lower 256 kB RAM. Then it needs to initiate the I/O. If this has
finished (interrupt) it needs to copy possible input from the lower 256
kB to somewhere else in RAM where the OS needs it.
This is ugly. All data needs to be touched twice from the CPU.
Na und? *g*
From a performance point of view, this may be a bit (not too much) ugly.
But from the usability point of view, I don't see any great problems.
Usability means to be able to hook the real Unibus to a PC style machine.
What 22 bit PDP-11s and VAXen do is somthing like
this: The UniBus
bridge has an I/O Memory Management Unit build in. DEC calls it the
UniBus map. The UniBus map has a page table. If a UniBus master
initiates a memory access the UniBus map takes the addess issued by the
bus master. It splits the UniBus address in a lower and upper part to
construct the CPU side address. The lower part is 9 bits (= 512 bytes,
the VAX page size). These lower 9 bits are copied 1:1 from the UniBus
address into the CPU side address. The upper 9 bits of the UniBus
address are used as an index into the IOMMU page table. The page table
entry contains some permission bits (read, write, ...) and the upper 23
bits of the 32 bit CPU address. This way a 18 bit UniBus address is
translated into a 32 bit CPU address.
Ok, it's an MMU for DMA. Would be no real
problem to add such a feature.
But I still don't see the real value - except some theoretical satisfaction.
It would be easy to install a bus mapper between the Unibus and the PCI
master interface. Just some more work.
This is very elegant. If I/O has to be done the OS
programms the UniBus
map with the apropriate translation and initiates the I/O.
No! That's not
elegant. A workaround. A kludge!
Therefore: If you design a PCI-UniBus bridge
_*PLEASE*_ implement a
proper IOMMU / UniBus map. Everything else will be a ugly kludge.
Just copy the VAX UniBus map and you are done. It does exactely what
is needed.
For whom? Who will actually *use* that? The BSD drivers on the PC? If
yes, it would be worth a thought. Otherwise: No way. I'll be glad to
have a stable interface to the Unibus. Bus master access Unibus->PCI is
simply not planned for the first version. I have to define achievable
milestones. And this feature is simply far beyond my needs. I want to
access the Unibus. And I don't have a VAX that should be able to program
my PC. Only 18 bit CPUs and peripheral controllers.
Worst case example:
Assume the most stupid access method on PCI: 8 bit single transaction
read access. That costs 4 cycles per byte. Let's add another cycle for
the sake of a bad implementation on the card. Makes 5.
Then we come to a read transfer rate of approx. 6.3 MByte/s on the bus.
This would allow for roughly 25 complete Unibus memory dumps per second.
Now a slightly more optimistic calculation:
We read the memory with 32 bit, 128 beat bursts (PCI's address
auto-increment feature seems to allow endless bursts).
Then we need one clock for four bytes and three extra clocks (address,
driver pause, transaction spacing). Makes 128+3=131 bus clocks for 512
bytes. Transfer rate is then 123MByte/s. For a complete Unibus memory
readout, it would take about 2ms. Or 492 complete Unibus reads/s.
So you have to add 2 ms to every full 256k portion of data transferred
by an Unibus DMA device. Assume a real fast device which continuously
holds the bus master during operation and doesn't pause, which is
capable of 40MB/s (all this is FAR beyond reality!), it would fill the
memory in 6.25msec. You would have to add 2 msec for that. So the all
over performance would go down to 8.25msec per Unibus fill, that means a
transfer rate of 30MByte/s. Wouldn't be acceptible for me.
Now let's look at a *real* Unibus disk drive, far faster than any RP,
RK, RL, TC, TM: RA81.
According to http://docs.freebsd.org/44doc/papers/diskperf.pdf, it can
transfer up to 2.2 MByte/s. And has a minimum seek time of 6 msec. As it
has 456 MB on 1,248 tracks, one track has a capacity of roughly 1.5
times the Unibus capacity. If you now split one cylinder into two
portions, you will add at most 1ms extra tranfer time/track.
Simply said: Forget about performance issues!
That would be a DMA bounce buffer in hardware. This is
still ugly and
defeats the reason for DMA.
Yes, I would even do PIO on the Unibus.
As stated
above, I will luckily live without :-)
You will, as it simplifies your hardware
design. But it will be a
nightmare to the OS programmer that has to fight with it writing a
device driver for it.
As you read above, I see no reason to avoid copying data in
the driver.
The driver has to fight something like
driver_read(...,buffer*, size){
...
int res=get_data_from_somewhere(*some_unibus_address);
memcpy(buffer, some_unibus_address+unibus_base, max(res,size));
...
}
Perhaps I have a too much simplified view on the topic. In that case,
I'm grateful for enlightenment!
Best wishes,
Philipp :-)
11 Aug
11 Aug
3:56 a.m.
On Sat, 08 Aug 2009 13:19:30 +0200
Philipp Hachtmann <hachti at hachti.de> wrote:
[real DMA vs. DMA bounce buffers]
"It
isn't done until it is done proper."
I have seen far to much bad engineering. Especially in the PeeCee area.
I don't wane spend my time with PeeCee crap.
Without bus master support the
bus bridge will be almost useless.
As explained in an other post even an interrupt is a bus master
transaction. Most storage devices use bus master DMA. You can't do
without DMA.
[...]
This is ugly.
All data needs to be touched twice from the CPU.
Na und? *g*
From a performance point of view, this may be a bit (not too much) ugly.
But from the usability point of view, I don't see any great problems.
Usability means to be able to hook the real Unibus to a PC style machine. It would be easy to install a bus mapper between the
Unibus and the PCI
master interface. Just some more work.
Then please do it.
On the other side: The glue logic will be implemented in a FPGA. So it
is software. Software is easy to change. I sugest that you first get
the hardware going. Get some PCI-FPGA card, build an add on card with
UniBus drivers, connect it to a real UniBus that contains only some
memory and try to access this. If you got that far we can continue to
fight about a proper IOMMU / UniBus map. The later is just a matter of
software that is loaded into the FPGA. The real hard part is the
hardware.
Therefore: If
you design a PCI-UniBus bridge _*PLEASE*_ implement a
proper IOMMU / UniBus map. Everything else will be a ugly kludge.
Just copy the VAX UniBus map and you are done. It does exactely what
is needed.
For whom? Who will actually *use* that? The BSD drivers on the PC? If
yes, it would be worth a thought. Otherwise: No way. I'll be glad to
have a stable interface to the Unibus. Bus master access Unibus->PCI is
simply not planned for the first version. I have to define achievable
milestones. And this feature is simply far beyond my needs. I want to
access the Unibus. And I don't have a VAX that should be able to program
my PC. Only 18 bit CPUs and peripheral controllers. Worst case example:
Assume the most stupid access method on PCI: 8 bit single transaction
read access. That costs 4 cycles per byte. Let's add another cycle for
the sake of a bad implementation on the card. Makes 5.
Then we come to a read transfer rate of approx. 6.3 MByte/s on the bus.
This would allow for roughly 25 complete Unibus memory dumps per second.
The
problem here is that the whole system is staled at UniBus PIO
accesses. The CPU is utilized 100% just to move data around. If you use
DMA the UniBus device handles the data transfer at its own. No CPU
intervention is required and the CPU can do other things (like
servicing user tasks). When DMA is ready the CPU gets an interrupt and
that is all.
But it will be
a
nightmare to the OS programmer that has to fight with it writing a
device driver for it.
As you read above, I see no reason to avoid copying data in
the driver.
The driver has to fight something like Perhaps I have a too much simplified view on the
topic. In that case,
I'm grateful for enlightenment!
The problem here is that the driver becomes
dependent on your
particular implementation of the UniBus bridge. E.g. NetBSD is save
from this as it abstracts all bus access through
bus_space(9) anyway.
So the DMA bounce buffers have to be implemented in the
bus_space(9)
backend. But then you still have the problem that the whole system is
staled at UniBus transactions. The CPU needs to do PIO read / writes
and spends lots of wait states. You can't even shedule an other user
process. The whole machine hangs inside the kernel as the CPU is
spinning wait states.
--
tsch??,
Jochen
Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/
6 Aug
6 Aug
10:48 a.m.
On 6 Aug 2009 at 3:59, Philipp Hachtmann wrote:
what do you think about a Unibus to PCI bridge?
I think such a device - if well done - could be real fun. There has
been a commercial approach somewhere - but it doesn't seem to be
available anymore.
Are you sure that you're not thinking of the Osprey ISA QBus/UniBus
adapters from Strobe Data?
http://www.strobedata.com/home/products.html
--Chuck
12:23 p.m.
On Thu, 6 Aug 2009, Chuck Guzis wrote:
On 6 Aug 2009 at 3:59, Philipp Hachtmann wrote:
There are/were PCI adapters as well. Someone like John Wilson would have
details on them.
Zane
what do you think about a Unibus to PCI bridge?
I think such a device - if well done - could be real fun. There has
been a commercial approach somewhere - but it doesn't seem to be
available anymore.
Are you sure that you're not thinking of the Osprey ISA QBus/UniBus
adapters from Strobe Data?
http://www.strobedata.com/home/products.html 
8:26 p.m.
Zane H. Healy wrote:
On Thu, 6 Aug
2009, Chuck Guzis wrote:
On 6 Aug
2009 at 3:59, Philipp Hachtmann wrote:
what do you think about a Unibus to PCI bridge?
I think such a device - if well done - could be real fun. There has
been a commercial approach somewhere - but it doesn't seem to be
available anymore.
Are you sure that you're not thinking of the Osprey ISA QBus/UniBus
adapters from Strobe Data?
http://www.strobedata.com/home/products.html 
10:46 p.m.
On Thu, August 6, 2009 8:26 pm, Jerome H. Fine wrote:
The real question is why you want to make use of the
bridge hardware.
About the only reason is that you have VERY unique Unibus hardware
that is not emulated by Ersatz-11. Can you specify what that hardware
does? That hardware might be easier to emulate than you think.
I'd have a hard time getting data off of my thirty or so RK07 packs
using an emulated RK07+RK611..
If the question is rhetorical, then until there is a
specific need, the
cost of
development of new hardware is probably not worth while.
I'd buy a few..
-Dave
--
Dave McGuire
Port Charlotte, FL
7 Aug
7 Aug
1:49 a.m.
Hi Dave :-)
Your're serious? That could make the thing at least affordable to build.
The most important (and difficult for me) part is to design a PCB with an FPGA that plugs
into the
PCI bus. The other ugly part is the cabling from there to the Unibus/Qbus. The rest is
programmable.
Those are the features to expect in an early version:
* Unibus mapping to PC's memory
* Interrupt forwarding to PCI INTA-INTD
* Interrupt vector interrogation mechanism
Later then:
* Unibus arbitration
* Unibus memory
* QBus
Software would initially consist of a "do nothing"-driver for Linux. It would
simply find the card
and then export the base address into the kernel name space. Other drivers then could use
that.
Probably also some code for interrupt handling.
I am a bit reluctant to register the bridge as a /proc/bus/unibus thing. That would
probably only
work without much use, as there are no PnP things on the Unibus.
Best wishes,
Philipp
--
http://www.hachti.de
I'd have a hard time getting data off of my
thirty or so RK07 packs
using an emulated RK07+RK611..
Full Ack! I only don't have a RK07 yet :-)
Perhaps I could wind a DECTape around my PC to get it into one of the simulators?
If the
question is rhetorical, then until there is a specific need, the
cost of
development of new hardware is probably not worth while.
I'd buy a few.. 
8 Aug
8 Aug
11:10 a.m.
Date: Fri, 7 Aug 2009 07:49:58 +0200
From: hachti at hachti.de
To:
Subject: Re: UNIBUS <-> PCI bridge
Hi Dave :-)
Hi Philipp,
I have five RK07's (!), want to keep just three of them.
I would trade two of them for something else, or some euro's.
But you would also need to find the RK611 controller (9 slot
backplane with some 5 or 6 modules in it) and the interconnect
cable (looks like RL02, but one or two more wires in the cable).
I saw on your website that you are looking for RK05 disk drives.
I have several of those, and one RK05 is for sale or trade. It is
missing the big sticker on the front that shows the drive number.
I have not checked or looked inside the drive, could do that if
you are interested and apply power to spin up. I can also shoot
a few pictures.
I guess the biggest problem is the distance. You are in Bremen
(according the website) and I am in Helmond (near Eindhoven) NL.
have a nice weekend,
- Henk
www.pdp-11.nl
I'd have a hard time getting data off of my
thirty or so RK07 packs
using an emulated RK07+RK611..
Full Ack! I only don't have a RK07 yet :-)
Perhaps I could wind a DECTape around my PC to get it into one of the simulators?
7 Aug
7 Aug
1:41 a.m.
Hi Jerome,
I suggest that the first thing you decide when you use
a Unibus <=> PCI
bridge is which CPU will be used to run the code.
Which code? The PC runs PC code,
the pdp11 runs its own code. And both at once, if they like!
The real question is why you want to make use of the
bridge hardware.
What a question!
About the only reason is that you have VERY unique
Unibus hardware
that is not emulated by Ersatz-11.
Can you specify what that hardware
does? That hardware might be easier to emulate than you think.
HA HA HA!!!!!
Ersatz-11 and SIMH can NOT emulate real hardware! Where can I put my RK05 pack into one of
them? How
do I use them to make a Unix installation tape that can be read in by the 11/45 via TU10?
How do I use them to test my RC11 controller?
I (and not only I!) am a user and collector of real hardware. My goal is definitively not
the
simulation. I want the bridge as a bridge to the "new world". To make things a
bit easier. If I
wanted to emulate everything, I would not spend $$ (only two Dollar signs!) and time for
hauling
tons of heavy gear all over the country!
I love SIMH for development and test purposes. But in the end, everything goes to real
iron....
If the question is rhetorical, then until there is a
specific need, the
cost of
development of new hardware is probably not worth while.
This is a hobby. As such it doesn't need any justification. There is no reason.
Best wishes,
Philipp
--
http://www.hachti.de
6 Aug
6 Aug
12:56 p.m.
Chuck Guzis wrote:
On 6 Aug 2009 at 3:59, Philipp Hachtmann wrote:
There were also adapters made by Bit 3, which was bought by SBS Technologies.
They had a common 10 pin serial interface between the different adapters, and
also had an option for a shared RAM on the card.
what do you think about a Unibus to PCI bridge?
I think such a device - if well done - could be real fun. There has
been a commercial approach somewhere - but it doesn't seem to be
available anymore.
Are you sure that you're not thinking of the Osprey ISA QBus/UniBus
adapters from Strobe Data?
4:17 p.m.
On 6 Aug 2009 at 9:56, Al Kossow wrote:
There were also adapters made by Bit 3, which was
bought by SBS
Technologies.
They had a common 10 pin serial interface between the different
adapters, and also had an option for a shared RAM on the card.
There's also this thing but it looks fairly involved due to the
required "option modules":
http://www.comwaretech.com/VAX/Bqp2300a.pdf
Cheers,
Chuck
7 Aug
7 Aug
1:51 a.m.
Hi Al,
There were also adapters made by Bit 3, which was
bought by SBS
Technologies.
There *were*....!
And all commercial stuff is most probably far out of my horizon of affordability :-(
Best wishes,
Philipp :-)
P.S.: Did you get my last email a few days ago?
--
http://www.hachti.de
6 Aug
6 Aug
1:47 p.m.
Chuck Guzis wrote:
On 6 Aug 2009 at 3:59, Philipp Hachtmann wrote:
As others have said, there were PCI-> qbus/unibus cards. In fact, here
are the specs:
http://www.dectime.se/images/BCI-2104%20Qbus%20adapter.pdf
http://www.dectime.se/images/BCI-2004%20Unibus%20adapter.pdf
And the company homepage saying they are discontinued :(
http://www.logical-co.com/Pci/genpci.htm
I have contacted the Swedish resaler and asked if they have any in
stock, but I doubt it.
If anyone has some in their garage, I'm in the market for one of each :)
/P
what do you think about a Unibus to PCI bridge?
I think such a device - if well done - could be real fun. There has
been a commercial approach somewhere - but it doesn't seem to be
available anymore.
Are you sure that you're not thinking of the Osprey ISA QBus/UniBus
adapters from Strobe Data?
http://www.strobedata.com/home/products.html
--Chuck
7 Aug
7 Aug
1:52 a.m.
Hi Pontus,
As others have said, there were PCI-> qbus/unibus
cards. In fact, here
are the specs:
http://www.dectime.se/images/BCI-2104%20Qbus%20adapter.pdf
http://www.dectime.se/images/BCI-2004%20Unibus%20adapter.pdf
And the company homepage saying they are discontinued :(
http://www.logical-co.com/Pci/genpci.htm
That's the page I've seen as well
:-(
If anyone has some in their garage, I'm in the
market for one of each :)
Would you be interested in a homebrew version as well?
Best wishes,
Philipp :)
--
http://www.hachti.de
3:14 a.m.
Hi Hacthi,
Well, yes, it could make bringing my 11/750 back a bit easier and
driving a TU77 without an big honking pdp/vax sounds fun. I'd be more
interested in a unibus bridge.
I have no PCB-making nor FPGA skills at all, but if I can contribute,
I'll try.
Cheers,
Pontus.
If anyone has
some in their garage, I'm in the market for one of each :)
Would you be
interested in a homebrew version as well?
20 Aug
20 Aug
5:02 p.m.
Pontus wrote:
http://www.logical-co.com/Pci/genpci.htm
I have contacted the Swedish resaler and asked if they have any in
stock, but I doubt it.
I got a late reply today, it was possible to order an unused Q-bus
adapter for no less than four thousand (4000) dollars. Well out of my
budget :)
/P
7 Aug
7 Aug
1:30 a.m.
Are you sure that you're not thinking of the
Osprey ISA QBus/UniBus
adapters from Strobe Data?
http://www.strobedata.com/home/products.html
--Chuck
Hm, perhaps... But those are ISA and probably very expensive. I even think
of PCIe....!
--
http://www.hachti.de
4:09 a.m.
On Fri, 07 Aug 2009 07:30:04 +0200
Philipp Hachtmann <hachti at hachti.de> wrote:
I even think of PCIe....!
This would be a big +.
I am afraid that PCI is going to die like ISA
did. (In case of ISA its death was good and should have happened far
earlier then it did.) So if you design a PCI card today you may have
trouble to find an old PeeCee with PCI slots tomorow.
On the other side: Plain old PCI is a + as PCI cards can be used in
e.g. UltraSPARC machines like a U10 or DEC Alphas.
Have a look at e.g. http://www.opencores.org/
There are several PCI based projects. Maybe you can use an existing
"FPGA on PCI(e) card" design. Probably you can by a readyly made PCI
card. So all you need is a doughter card with proper UniBus / QBus
transceivers.
If you get the hardware done I will volunteer to write a NetBSD bus
driver. (NetBSD does a very good job in abstracting device driver buss
accesses. If I write a single PCI to UniBus / QBus bus bridge driver
all UniBus / QBus device driver will just work with it. There is no
modification of the device drivers needed.)
--
tsch??,
Jochen
Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/
5450
days inactive
5464
days old
21 comments
9 participants
participants (9)
-
aek＠bitsavers.org -
cclist＠sydex.com -
hachti＠hachti.de -
healyzh＠aracnet.com -
henk.gooijen＠hotmail.com -
jhfinedp3k＠compsys.to -
jkunz＠unixag-kl.fh-kl.de -
mcguire＠neurotica.com -
pontus＠update.uu.se