Re: programmable logic

On Sun, 5 Oct 1997 17:12:45 -0800, you wrote:

>>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...

Of course you can center a DVG anytime you like. But what you can't do
with an Atari AVG is jump around the screen like the Cinematronics and Sega
games do. If you want to write your own games you can control the order of
your list, but if you want to run emulated games (more my goal) you don't
have that kind of control.

>>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...

I just picked up a Asteroids Caberet this weekend, and this is the first
DVG game I own (well I have a non-working Omega Race) so I looked it over
pretty carefully. It looks like they never did get the draw speed quite
right since some angles are definitly brighter than others. But I really
like the way the lines connect *perfectly*. You just can't get the Tempest
AVG to do that -- I'm talking perfect!

Of course if you're controlling the vector time in software (using the PIC)
you could probably add fudge factors based on the length of the lines and
get a better lineup than the AVG.

>>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.

Yeah, I doubt if you could even measure the error. The thing about the
Breseham algorithm is that it appears to be less complicated, and I believe
I can control the draw speed precisely so that the intensity for any angle
will remain the same. But the increment test registers must be
pre-calculated in software or the design would end up be much more
complicated than the simple *step rate* registers used by Atari.
>
>>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.

Using PIC instructions I was able to write a Bresenham line draw loop in
about 12 instructions. So if I want to drive the WG monitor at it's rated
slew rate I figured I needed to upate a 10bit DAC at a 3.33mhz rate, so I
need a CPU with a 25ns instruction time. That would be a standard PIC
running a 160mhz. The new SX could do it with a 50mhz clock since it can
run an instruction on every clock (no internal divide by 4), giving it a
20ns instruction time.

It's very tempting to just wait for this processor...

>[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'm not sure what the speed is, or how ZIP calcuted their spec, but
currently this is the unknown part of the equations and I'm not going to go
ahead with any design until I figure out how I'm going to get the data to
it fast enough. My caclulation was on worst case data using a standard
DVG. 10 bit starting and ending X/Y data, and a 12bit color - 800k per
second (wince!). That assumes 500 vectors 40 times a second. On the
Cinematronics games most only generate around 200 vectors 38 times a
second, Sundance being the largest at 430+ vectors per frame.

>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. :-)

Yeah, to save a lot of I/O I was thinking of using seperate counters and
only running the clock pulse lines out of the isp1016.

-Zonn
Received on Mon Oct 6 11:23:27 1997