On Thu, 2004-09-16 at 15:20, Marc Nicholas wrote:
> On Thu, 16 Sep 2004, Herbert Graf wrote:
> 
> > On Thu, 2004-09-16 at 14:15, Philip Pemberton wrote:
> >> That's effectively what I'm doing now - grabbing 1024 bytes, blasting them to
> >> the host, then grabbing another 1024 bytes (8 rows). I haven't tried doing
> >> the imaging cycle like that, though. I'll have to try that :)
> >>
> >> The other option, of course, is to hook up a 16k RAM (62128?) and a pair of
> >> 4040 counters - use one 8-bit port to read/write the data lines, then use
> >> another five I/O lines to run /CS, /RD, /WR, COUNTER_CLK and COUNTER_RST.
> >> Blast the data into the RAM (framebuffer), then come back and read it out
> >> later.
> >
> > This sounds like something that a CPLD would be perfect for. Let the
> > CPLD generate the addresses and write pulses for the SRAM. Have a look
> > at my logic analyzer project:
> 
> Or an FPGA as I mention....especially as devices like Altera's Cyclone are 
> so versatile and cheap now, seem pointless to use a CPLD when you can use 
> an FPGA that costs the same as a PIC ;-)

Depends on your definition of "pointless". Had a look at that part,
nice, except for two things (which is sadly common of most FPGAs and is
the reason I've never used them in a hobbyist project):

1. requires extra chips to program at powerup (programming proms),
annoying to deal with considering a CPLD doesn't need that, and cost
extra.

2. HORRIBLE packages from a hobbyist's point of view. PLCC = easy for
hobbyist, TQFP = not easy. Let's not mention BGA.

I'm not saying an FPGA is a bad idea, I'm saying, for the op's
application, a CPLD is more then enough. 
 
-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist