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 Sun Oct 5 17:12:33 1997