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.