From: Hatch (
Date: 2004-11-03 15:44:47

I'm in Brisbane, good to be talking to another aussie.
Them calculations are more like what I had in mind.
My idea for the chunky fill is to do pretty much the
same as EOR but with bytes instead of bits.  A
triangle fill? Besides it being a triangle that's been
filled, can you go into this any further? Is every
thing on the screen made up out of triangles?

----- Original Message ----- 
From: "Christopher Phillips" <>
To: <>
Sent: Wednesday, November 03, 2004 9:51 PM
Subject: Re: C64 GRAPHICS CARD

> 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

       Message was sent through the cbm-hackers mailing list

Archive generated by hypermail pre-2.1.8.