FPGA

G'day Clay (and folks),

A while back I looked at putting the whole Cinematronics board onto a
single FPGA. However two obstacles that I ran into were the RAM and the
I/O pins. In your letter down below, Clay, you said that SRAM chewed up
alot of the FPGA. Does that hold for dynamic RAM like the 256 words by
12 bytes of RAM on the Cinematronics board?

With all the digital video output, control panel input and sound card
interface, I also felt that I'd run out of I/O pins even with the
largest package (4020, at the time).

Right now, I'm looking at duplicating the Cinematronics Exercisor with a
FPGA and making a universal translator for all Cinematronics control
panels. These tasks seem better suited for FPGA. Much more gate
intensive rather than register/RAM/IO.

                Steven S Ozdemir
                sso@dsc.com

ps - These PIC intrigue me....how do they compare to FPGA for quick/easy
implementation?

>----------
>From: Clay Cowgill[SMTP:clay@supra.com]
>Sent: Sunday, October 05, 1997 6:12 PM
>To: vectorlist@goonsquad.spies.com
>Subject: Re: programmable logic
>
>>The problem I have with going with the AVG design are the integrators
>>themselves. They can only zero'd, and not preset to any random value.
>>This makes it hard to emulate the Sega, Cinematronics and old Atari DVG
>>systems. If I were to go with an analog design, I'd be tempted to use the
>>Cinematronics design. It gets around a lot of the problems of the
>>integrator.
>
>True, but remember the trick about the slew rates on the WG and Amplifone
>color monitors... That Atari method of needing to zero the integrators to
>get to the center point kinda forces you to return to the center of the
>screen, so you tend not to have the big delta's of a parallel load (like
>Sega) which the WG and Amplifones can't keep up with. You can get around
>it by ordering your display list carefully though...
>
>>I like the digital design for a couple of reasons:
>>
>>1) You never have to worry about lines meeting up. All the analog designs
>>use critically time vector lengths to line up correctly, and they never
>>really line up exactly.
>
>Yup, although I think Atari's AVG is pretty good. The Vectrex (by
>contrast) is pretty bad, but it's going from an 8-bit DAC though too...
>
>>2) This might be over kill, but by using somewhere between 2 and 4 meg of
>>ROM (or possibly RAM) as table lookups between the counters and the DACs,
>>you can do all the pincussioning and linearity control digitally. So it's
>>a lot of ROM, but ROMs are not *that* expensive, and it's not like I'm
>>going into high quantity production. And once again it allows you to set
>>the *excact* pincussioning and linearity needed by the monitor, no
>>drifting, ever.
>
>That would be cool. I decided to cut the size of the Sega Multigame PCB
>and just use a single 27C040. It's only $6 from JDR... No worth the
>boardspace and decode logic to support '010's and '020's...
>
>>My design differs a bit from the Atari DVG and the Sega (though I haven't
>>fully deciphered the Sega) in that I've designed the Bresenham's algorithm
>>into some really simple hardware. The catch is that register values must be
>>pre-calculated by the PC, an option Atari and Sega didn't have. (Since
>>they were both background VGs and didn't have there own processor, to speak
>>of.) I control the line draw speed on a clock by clock basis to assure all
>>angles are drawn at the same speed. The TTL design looks very workable but
>>uses something like 20 ICs! (Why are all TTL devices only 4 bits!)
>
>That's pretty cool. You know, the TI 34010 graphics processor had some
>hardware instructions that made Bresenham's a snap. It was damn fast too--
>plus dual-port DRAM control... Too bad it's obsoleted. :-(
>
>>Most video cards with built in line draw use the bresenham algorithm, since
>>there is no rounding error regardless of the line line, unlike the clocking
>>method used by Atari (though it's pretty miniscule).
>
>Yeah, still though, even with 10bits of D/A I think even the slight errors
>in Atari's method is probably pretty small compared to what can be resolved
>on the display.
>
>>Even if you overclock the PICs they still divide by four. To run a PIC at
>>the speed of the SX part (when programmed to the no divide mode) you would
>>have to run them at 200mhz!
>
>True. I dunno what kinda MIPS you're after.
>
>[ISP]
>
>>I went to there home page and have been looking at the isp parts. I'm
>>wondering if you could program one of these to do the whole VG and
>>eliminate any processor (Since my ZIP drive claims a 20mb transfer rate
>>through the paralled port, I'm assuming I can talk to the VG at the 800k
>>rate I believe I'm going to need. To bad, I wanted to use the serial
>>port...)
>
>Guts-iest move I ever saw, Mav. :-) Are you planning on using the ECP or
>EPP (or whatever the hell they're called) modes? I always thought that the
>"stock" parallel port was limited to around 100-150Kbytes/sec. (Maybe that
>was with an older processor driving it though...)
>
>I decided to use an auto-incrementing counter into my VRAM array for
>loading memory off the ISA bus. Just like the Super Nintendo. :-) (/WR
>auto-increments the memory pointer to the next address in VRAM.)
>
>>The parts are expensive, but if it was nearly the whole design it wouldn't
>>be so bad.
>
>You can get 2032's and 1016's pretty cheap in quantity, but I think the
>onesy-twosy stuff if steeper. The only time I was looking at them was to
>redo the Tempest vector generator in a single device. The main problem was
>the number of IO's. There was plenty of gates on even really small
>devices, but I ran out of I/O pins. :-/ Then again, I was trying to
>accomodate the 12 bit datapaths for the SRAMs still. You don't want to
>integrate SRAM cells in the FPGA. Eats WAY too much space. :-)
>
>As an aside, Cypress (I think it's Cypress) makes some 8-bit counters with
>preset and clear. (Kind-of a 74193 on steroids.) Might be hard to just
>buy off the shelf though.
>
>-Clay
>
>Clayton N. Cowgill Engineering Manager
>_______________________________________________________________________
>/\ Diamond Multimedia Systems, Inc. clay@supra.com
>\/ Communications Division http://www.supra.com/
>
>
>
Received on Mon Oct 6 08:58:13 1997