>> > > Another problem is that I will need some kind of buffering, probably the
>> > > entire frame, since the PC-parallell port is pretty slow.
>> > > Maybe using ripple counters to address some kind of memory will do the
>> > > trick? The PIC would of course control everything.
>> > >
>> > > I'm planning to use (and don't you dare laugh :-))  the 16C84 in this
>>  project,
>> > > mostly
>> > > because I don't have a programmer that supports anything else.
>> > > (My programmers are both the PICBlaster and the AN589 type. I've been
>> > > using the PIP-02 software for the PICBlaster and different types of
> software
>> >  for
>> > > the AN589)
>> > >
>> > > Any suggestions, good ideas etc?
>> > >
>> > > Cheers
>> > >
>> > >  -Oyvind
>> >
>> > I think you need buffering the entire frame. If you use DRAM then page
>> > mode is fast enough. It is possible to use the build in memory refresh
>> > counter, but it is more slow than page mode. I suggest that you use two
>> > memory banks, write four times to the first bank (page mode) while you
>> > refresh ( with internal counter ) the other. The timing is more fast than
>> > PIC16C84 handles and you need some external logic or a PLD to do it.
>> > PIC16C84 is fast enough to handle the high column adresses.
>> >
>> > Regards,
>> > Jens Dyekjaer Madsen
>>         Hi,
>> It-s good idea but any of IBM likes PC do not handle this data stream
>> on Centronix Port...You must have a frame bufer (H X Res X ver_lines)X8
>> bites capacity.
>>         Best regards,
>>                 Saras.

>I think about using external DRAM's as 514256 (used on most standard DRAM
>modules). They has a CAS before RAS refresh counter test cycle which
>read/write data sequential into the memory. To make it fast enough,
>improve this cycle with reading more columns as in page mode. This
>methode does not need Row / collumn multiplexers since it use the build
>in counter for row addressing. Page mode manage 40ns cycle time on 70 ns
>DRAM's, or about 25 MHz. It is possible to sample color bursts and do
>color sampling too.

Lots of static RAM chips also has more than fast enough access times.
Remember, if 400 samples is to be taken within 64 uS the needed
access time is 160 nS. (A little less to allow address updates etc)

>When entire frame is stored at high speed - then transmit it at low speed
>during the parallel port.

I'm not sure how fast it will be possible to transmit data over the parallell
port, anybody knows?

I've been using the parallell port for different things earlier, but that was on
an old PC, and the port was not bidirectional. 
To write a byte on the port I used the function outportb(port,data) in C.
My current PC has a bidirectional port, but I don't know how to read it.
Is there some kind of direction bit I can set from my C program so that I can
use the inportb function?

-Oyvind