7 Aug
2009
7 Aug
'09
1:54 p.m.
Philipp Hachtmann <hachti at hachti.de> wrote:
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
Reading your other messages... Without Unibus memory you'd be restricted
to only interrupt-driven single byte transfer devices, since you have no
solution to manage DMA devices on the Unibus.
For DMA, you need either to allow the Unibus to get access to the PCs
memory (that would imply a Unibus map, which by the way wasn't just used
by a VAX. Large Unibus PDP-11 systems also have a Unibus map). A Unibus
map is nothing magical by the way. It's just a way to remap the 18-bit
Unibus address of a DMA transfer into a larger address of the host. It's
usually a simple addition of the Unibus address with a large constant
that can be written by the host (usually you have several separate map
registers, so that multiple DMA transfers can proceed in parallell.
I don't know what you mean by "Unibus mapping to PC's memory". Would
that be a Unibus map, or are we just talking about a way for the PC to
read data from arbitrary addresses on the Unibus?
Interrupt stuff is usually a bit more complicated than what you seem to
envision above. You have the interrupt request line, the interrupt
grants, which is followed by the vector at the interrupt acknowledge,
and then you have the interrupt dismiss stuff, which cause the device to
remove the interrupt request, and allow other devices at the same
priority, but farther from the bus arbiter to get their interrupt through.
And what about Unibus memory? There is nothing special about Unibus
memory. It behaves the same way as any other thing on the Unibus, with
the additional "restriction" that memory can never be bus master. But
that just makes it easier. If you implement enough to communicate with a
device on the Unibus, then you will have done enough to talk with memory
as well.
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.
Why do you even bother with questions about how a driver would present
the data in a specific OS? That is definitely software that you can
change any number of times. You need to figure out how to construct the
hardware so that it will work, and after that you can play with software
as much as you want to without problem.
Oh, and not everything is software. There are some things that are very
demanding for precise timing considerations. Software is usually not a
good solution for those cases...
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol