Archived from groups: rec.games.vectrex (More info?)
On Wed, 19 May 2004 02:52:11 GMT, in msg <uZzqc.114307$Ik.9401312@attbi_s53>,
"Clay Cowgill" <clay@yahoo.com> wrote:
>"Christopher Tumber" <christophertumber@rogers.com> wrote in message
>news:40a98a65.131978174@nntp.slnt.phub.net.cable.rogers.com...
>> - My point was that the real, hard and fast limiting factor is not
>> math, it's the amount of time it actually takes to draw the screen.
>
>That makes no sense as a general statement. (no offense intended) Maybe as
>a specific statement to a specific application, but not in the general
>sense.
>
>I can *guarantee* I could use more math just making 'neat' looking effects
>than the Vectrex is capable of pushing every frame. ;-) Having a
>coprocessor is the difference between making it possible or not...
You guys don't seem to be taking into account that the Vectrex monitor is a very
slow monitor. All the CPU cycles in the world is not going to change that.
I haven't calculated how slow, but it's quite a bit slower than the WG6100.
I think a co-processor can really help with some special effects (line removal,
3D calcs, etc), but as far as refresh rates, and number of vectors drawn per
refresh, I'm betting your real limit is going to be the Vectrex monitor itself,
not the CPU power behind it.
>> As per my final guestimates, 50-4 sided polys should be doable, even
>> if we're only calc'ing 25 polys per frame. Simple transforms
>[...]
>> Hidden line removal is pretty unlikely, though we can probably fudge
>> hidden face removal from within objects without too much trouble.
>
>Right-- again, the coprocessor could just do it. No muss, no fuss. Just
>hand the vectors to the 6809 to render. Probably even do it in C on the
>co-pro...
I was talking with a guy (through email) that worked at Rock-o-la, at one time
they were talking about releasing some new games based on the CCPU, however the
processor was too slow, so they decided to go with a co-processor. They ended
doing just what you're talking about. They wrote a simple vector rendering
engine for the CCPU that they talked to through the control panel input port.
The "co-processor" was really the processor that all the game code ran on, it
simply handed off the vectors to the CCPU as needed.
The reality of the system was the CCPU was made the vector engine co-processor,
while the main processor was the one just added.
If you were to add a co-processor, I think Clay's idea of running all the game
code on it would be a great idea. The Vectrex's 6809 would become the
Vector/Sound co-processor. You could write some nice vector generator code,
with a nice instruction set for the 6809 that would make displaying vectors a
breeze for the new processor. Since the 6809 would be completely dedicated to
drawing vectors you could do things like change the DACs on the fly for things
like circles and variable vector shading and stuff (I haven't done this, but I
assume this is what's being done to draw curved vectors). It'd be kind of a next
generation AVG instruction set. You could do something similar for sounds.
You could communicate between the two using memory mapped ports. It all seems
very do-able. But would it sell?
-Zonn
---------------------------------------------------
Zonn Moore Run MAME's vector games on a real
Zektor, LLC vector monitor using the ZVG!
www.zektor.com More info at: www.zektor.com/zvg
Remove the ".AOL" from email address to reply.
On Wed, 19 May 2004 02:52:11 GMT, in msg <uZzqc.114307$Ik.9401312@attbi_s53>,
"Clay Cowgill" <clay@yahoo.com> wrote:
>"Christopher Tumber" <christophertumber@rogers.com> wrote in message
>news:40a98a65.131978174@nntp.slnt.phub.net.cable.rogers.com...
>> - My point was that the real, hard and fast limiting factor is not
>> math, it's the amount of time it actually takes to draw the screen.
>
>That makes no sense as a general statement. (no offense intended) Maybe as
>a specific statement to a specific application, but not in the general
>sense.
>
>I can *guarantee* I could use more math just making 'neat' looking effects
>than the Vectrex is capable of pushing every frame. ;-) Having a
>coprocessor is the difference between making it possible or not...
You guys don't seem to be taking into account that the Vectrex monitor is a very
slow monitor. All the CPU cycles in the world is not going to change that.
I haven't calculated how slow, but it's quite a bit slower than the WG6100.
I think a co-processor can really help with some special effects (line removal,
3D calcs, etc), but as far as refresh rates, and number of vectors drawn per
refresh, I'm betting your real limit is going to be the Vectrex monitor itself,
not the CPU power behind it.
>> As per my final guestimates, 50-4 sided polys should be doable, even
>> if we're only calc'ing 25 polys per frame. Simple transforms
>[...]
>> Hidden line removal is pretty unlikely, though we can probably fudge
>> hidden face removal from within objects without too much trouble.
>
>Right-- again, the coprocessor could just do it. No muss, no fuss. Just
>hand the vectors to the 6809 to render. Probably even do it in C on the
>co-pro...
I was talking with a guy (through email) that worked at Rock-o-la, at one time
they were talking about releasing some new games based on the CCPU, however the
processor was too slow, so they decided to go with a co-processor. They ended
doing just what you're talking about. They wrote a simple vector rendering
engine for the CCPU that they talked to through the control panel input port.
The "co-processor" was really the processor that all the game code ran on, it
simply handed off the vectors to the CCPU as needed.
The reality of the system was the CCPU was made the vector engine co-processor,
while the main processor was the one just added.
If you were to add a co-processor, I think Clay's idea of running all the game
code on it would be a great idea. The Vectrex's 6809 would become the
Vector/Sound co-processor. You could write some nice vector generator code,
with a nice instruction set for the 6809 that would make displaying vectors a
breeze for the new processor. Since the 6809 would be completely dedicated to
drawing vectors you could do things like change the DACs on the fly for things
like circles and variable vector shading and stuff (I haven't done this, but I
assume this is what's being done to draw curved vectors). It'd be kind of a next
generation AVG instruction set. You could do something similar for sounds.
You could communicate between the two using memory mapped ports. It all seems
very do-able. But would it sell?
-Zonn
---------------------------------------------------
Zonn Moore Run MAME's vector games on a real
Zektor, LLC vector monitor using the ZVG!
www.zektor.com More info at: www.zektor.com/zvg
Remove the ".AOL" from email address to reply.
Facebook
Twitter
Instagram