i thought of letting the pc drive the screen scan, a controller costs around 280$-300$ , so i started looking for a way to get a straight IO from a PC(specificly - output is all i need) at around 3-6MB a second.
i thought of interfacing the PCI slots. developing a pci board and pci-controlling chip is expensive soi though of connecting the address bits of the pci slot to the 8-bits of the lcd screen , windows driver will "write" or try to access an "address" in the card , while this will trigger the pci-addr pins that will actually connected to the data of the lcd and trigger the pixels accordingly.
the first problem of that is , for each "request packet" that the bridge asking a card for , the card need to reply with some kind of "ack" bit(it has a timeout , but relaying on timeout will result in extreamly low data-rate). i figured this can be solved with some passive logic that will wait some ns duration(according to pci-spec) and trigger the ACK bit from the slot's power source.
the truely problem is card-identification and registration. this cant be achieved without implementing a lot of PCI's standard , even if i take a 8051 that will controll the meta-data negotiation (pci is async , you need to listen to see if the bridge is talking to you or some card near you).

so pci idea is kind of rejected.

parallel can give that , but parallel(LPT) overkills the CPU and rest of the media application will be hanged (like when you are printing with an LPT printer).

david.