Re: C64 GRAPHICS CARD

From: Christopher Phillips (shrydar_at_jaruth.com)
Date: 2004-11-03 12:51:19

On 3 Nov 2004, at 18:48, Hatch wrote:

> Wow, you sure seem to know your stuff, I know very little about 3D so
> your input and advice will be very helpful.
*blush*

I just noticed you've got an aussie email address - where do you live?
I've just "deemigrated" - after nearly eight years in the UK I've moved 
back to Perth, Western Australia.

>  A lot of this stuff is more
> complex then what I will be designing.  My cct is going to be very low
> spec.  A couple of easy to implement features such as the on the fly
> screen filler and the byte filler.  As far as assisting in 3D 
> calculations
> I was looking at something a bit simpler, like a 16 bit divider or
> something. What simple calculations would you suggest or do you think 
> would be
> the most helpful in speeding up 3D?
>

*nod*
A 32bit/16bit -> 16 bit result divide would be really useful.

Even better would be if you also had a 16bit*16bit->32 bit multiplier, 
whose result could be automagically placed into the input for the 
divider, to give A*B/C to 16 bit precision with a 32 bit intermediate.



>  also if I go for a chunky display,
> which way should the graphics data be displayed? 200 rows? 320
> columns? other?

If you did a chunky display, you would really need to provide hardware 
assist with filling - either a simple XOR fill, or preferably a 
triangle fill.  A 1MHz 6502 will be seriously underpowered for dealing 
with 64k of VRAM.

As for layout, you could argue either way.  320 columns would let you 
have a <1page memory mapped EOR buffer though, so I'd probably lean in 
that direction - then a 3d plotter could scan-convert from left to 
right rather than top to bottom, and could still use indexed addressing 
for plotting the edge events into the buffer.

Christopher Jam/Shrydar


       Message was sent through the cbm-hackers mailing list

Archive generated by hypermail pre-2.1.8.