Accessing PCI bus on a computer - how?

[Offensive username removed]

If you don't need to access PCI bus you could buy a PCI-USB card, then solder your device to one of USB ports and mount its PCB to USB card with hot glue.

[Yansi]

Alex Eisenhut, go away, I have really no interest of continuing conversation with you.
Who told you it was simple? Me! And I also emphasized the goal of this project.
What is it you don't understand? You have done no research, demonstrated no understanding, and no willingness to listen.
I ask A and you aswer B. None of you answered A, no wonder I am pissed when you bitch about things I haven't asked for!
You simply slapped things together and then loudly complained, and demanded answers from people that owe you nothing.
If you have a problem with free help, why are you visiting this forum? One must owe you something to get relevant answer from you?
Answer your own questions from now on.
Sure I will, because in this thread still I got no answer for my main question. 

nctnico, thank you for nice explanation. Now I owe you something :-) I just cannot understand why others are not willing to help. I will try to correct my design in the next version, if there will be any. Now I will just test what I've made in accordance with ChaN's experiment. Not much worse than ChaN's, so hope it to work. The PLD I've used is fast enough and PCI 66 compliant. But there's the catch with the levelshifters' prop delays, which I tried to count with.
If I will make another version, I probably will use 5V capable PLD (MAX7k or XC95?) to get rid of the levelshifting stuff.

HardcoreAnalFisting - That looks interesting idea.

[Alex Eisenhut]

Alex Eisenhut, go away, I have really no interest of continuing conversation with you.
Who told you it was simple? Me! And I also emphasized the goal of this project.

So you believe that your goal changes the physics of the signals.

What is it you don't understand? You have done no research, demonstrated no understanding, and no willingness to listen.
I ask A and you aswer B. None of you answered A, no wonder I am pissed when you bitch about things I haven't asked for!

We have no idea what you are asking because you toss a bunch of stuff at us, run away when you don't like the answer, then change the subject.

If you have a problem with free help, why are you visiting this forum? One must owe you something to get relevant answer from you?

Typically, people are friendlier and calmer than you. Pleasant, in fact. You, are not.

Answer your own questions from now on.
Sure I will, because in this thread still I got no answer for my main question. 

What *IS* your main question? Can you stick to maybe one specific thing at a time? Maybe post a schematic? Not pictures of commercial boards?

nctnico, thank you for nice explanation. Now I owe you something :-) I just cannot understand why others are not willing to help.

We can't understand why you can't see we are helping.

HardcoreAnalFisting - That looks interesting idea.

Direct contradiction of your initial stated goal.

"If I wanted to make a IDE device or USB one, I will ask that, not PCI."
"1) I will not make USB device here. I want PCI. For whatever reason..."
" Everyone has a hobby. So why to bitch around that? And also  again no for USB. "

Can you see that you're difficult to follow? 

"PCI experimenting here. Going to study it myself the hard way."

You certainly are.

[Yansi]

Yes, I am complicated. So is stopping your spam injection in my thread.

Is that readable or not?

I have recently come across this very interesting project: http://elm-chan.org/works/pci/report_e.html
... ...
But how to communicate with the card? Possibly also under Windows environment? 

I have already found some fragmentary info, how to do that. I have discovered the $0CF8 and $0CFC  IO mapped registers, and stuff like so...  This possibly shoud be done in DOS or other direct port access granting system... The really big question is, how to deal it under windows. 

It would be nice, if such thing like "libusb" existed for the PCI bus. Or does it?

[rob77]

i just noticed this thread....back in time, i've been developing linux kernel modules (aka. device drivers) for several custom PCI cards.

my few notes

1. make a PCI is not trivial/easy
2. yes it's perfectly doable as DIY, but be prepared for way too many man-hours invested.
3. PCI card can be 2 layer - no problem at all, but things are more reliable with 4layers with a dedicated ground plane
4. you have to have a driver in OS - simplest approach is to have a small memory region mapped from your PCI card and write a driver which will present that region as a character device - then you can use starndard read & write syscalls from userspace to communicate with your PCI card.
5. you need a PCI vendor ID/product ID to make it work - if you're planning just to play at home with it, the you can use any vendor/device ID.
6. Xilinx Spartan3 is good enough to make the PCI interface in FPGA, but any modern better/faster FPGA will do as well.

[Alex Eisenhut]

Yes, I am complicated. So is stopping your spam injection in my thread.

Is that readable or not?

I have recently come across this very interesting project: http://elm-chan.org/works/pci/report_e.html
... ...
But how to communicate with the card? Possibly also under Windows environment? 

I have already found some fragmentary info, how to do that. I have discovered the $0CF8 and $0CFC  IO mapped registers, and stuff like so...  This possibly shoud be done in DOS or other direct port access granting system... The really big question is, how to deal it under windows. 

It would be nice, if such thing like "libusb" existed for the PCI bus. Or does it?

You obnoxious pest.

[rob77]

Hi
I have recently come across this very interesting project: http://elm-chan.org/works/pci/report_e.html
The HW side of the PCI bus looks straightforward and is relatively well described through the internet. But I have found very difficult to find any information, how to access the PCI bus. Or to be exact here - how did he possibly made read or write transactions with his diy PIO card?

had a look at that webpage with the "PCI card" you linked above  - please forget that web page... you'll save yourself a lot of frustration. the author of that page got absolutely no clue about PCI specs... he was trying to approach it like the ISA bus.. but things don't work like that with PCI.

[LaurentR]

had a look at that webpage with the "PCI card" you linked above  - please forget that web page... you'll save yourself a lot of frustration. the author of that page got absolutely no clue about PCI specs... he was trying to approach it like the ISA bus.. but things don't work like that with PCI.

This is obviously an incredibly narrow view of PCI, and non-compliant in so many ways, but it can be made to work within a very specific scope. If that's the OP's only goal, then why not.

[Alex Eisenhut]

i just noticed this thread....back in time, i've been developing linux kernel modules (aka. device drivers) for several custom PCI cards.

my few notes

1. make a PCI is not trivial/easy
2. yes it's perfectly doable as DIY, but be prepared for way too many man-hours invested.
3. PCI card can be 2 layer - no problem at all, but things are more reliable with 4layers with a dedicated ground plane
4. you have to have a driver in OS - simplest approach is to have a small memory region mapped from your PCI card and write a driver which will present that region as a character device - then you can use starndard read & write syscalls from userspace to communicate with your PCI card.
5. you need a PCI vendor ID/product ID to make it work - if you're planning just to play at home with it, the you can use any vendor/device ID.
6. Xilinx Spartan3 is good enough to make the PCI interface in FPGA, but any modern better/faster FPGA will do as well.

PCI cards also often have their own BIOS so that you use those system calls to use the card's hardware. Lots of programming required!

[nctnico]

ROMs on a card only work in x86 backward compatibility mode to augment the system's BIOS during startup. Useless for any virtual mode OS.

[rob77]

exactly... BIOS is not used anymore to communicate with hardware (it was used for that back in the times of DOS), that's the reason why you need to have a driver in OS which is handling all the communication between the hardware and userspace application(s). the BIOS is only "configuring" the hardware before control is passed to OS loader and is providing basic access to the boot device (bios drive #80) for legacy OS loaders.
BIOS is being replaced by UEFI nowadays.