New Multicart Design / Math Copro?

Archived from groups: rec.games.vectrex (More info?)

While on the subject of all things Vectrex, I've been talking with a
couple people about making up a new multicart. Since it looks like Sean
Kelly seems to be out of the multicart business (or at least dormant), I
thought maybe I could start producing one.

Unlike a regular multicart, however, I thought it may be interesting to
provide the ability to burn homebrew titles onto the cart on a per cart
basis, and provide royalties to the authors. i.e. the buyer would
specify which titles he wanted, he'd pay the extra cash, and I'd pass it
onto the authors.

Also, I came up with a way to reprogram the carts without opening them up
so updates could be done relatively cheaply.

With the VecFlash out, however, I dunno if there's a market for this or
not. The target price for such a cart would be in the $75 range, which
is a bit cheaper than the multicart from what I recall. The cute thing I
was thinking of too was being able to support/emulate the Dallas single
wire EEPROM used by some of the later homebrews to save scores, etc.

One other little thing too I was thinking of was a math coprocessor chip
for the Vec. It'd be an 8 bit I/O port that sits on the bus and is
mapped into memory somewhere that would perform various math functions
quickly to take the load off of the 6809 in the Vec. You'd for example
feed it your input data and desired operator(s) via the input port, then
you'd read the result on the output port. I can do multiplies, sin/cos
lookups, and other things relatively quickly since the "coprocessor"
could run at 40MHz. The coprocessor could also store data or tables.


Comments? Suggestions?
26 answers Last reply
More about multicart design math copro
  1. Archived from groups: rec.games.vectrex (More info?)

    >One other little thing too I was thinking of was a math coprocessor chip
    >for the Vec

    I'd like to see this - will it fit in a cart case with the game EPROM ?

    Or be a pass-thru type thing ?

    What sort of price would it be + what chip are you using ?


    Richard H.
  2. Archived from groups: rec.games.vectrex (More info?)

    "Richard Hutchinson" <richard.hutchinson@dsl.pipex.com> wrote in
    news:4097d663$0$20510$cc9e4d1f@news-text.dial.pipex.com:

    >>One other little thing too I was thinking of was a math coprocessor chip
    >>for the Vec
    >
    > I'd like to see this - will it fit in a cart case with the game EPROM ?

    Yeah it could be on the PCB with the EPROM. It'd be 28 or 44 pin surface
    mount.
    >
    > What sort of price would it be + what chip are you using ?

    It'd be a PIC18Fxx series part running at 40MHz. As for cost, dunno..
    might add $12 to the cart.
  3. Archived from groups: rec.games.vectrex (More info?)

    > One other little thing too I was thinking of was a math coprocessor chip
    > for the Vec. It'd be an 8 bit I/O port that sits on the bus and is
    > mapped into memory somewhere that would perform various math functions
    > quickly to take the load off of the 6809 in the Vec.
    [...]
    > Comments? Suggestions?

    http://tinyurl.com/ytxwn

    then a little later...

    http://tinyurl.com/247qe

    I had finally settled in on a Scenix 50MHz part (just using the stock
    Microchip math library functions). Eric Smith and I even went a couple
    rounds discussing it, but the general lack of interest here didn't make it
    too interesting. There were only a few people writing home-brews at the
    time, so author support would have been minimal. Maybe people would be more
    receptive to it now though...

    -Clay
  4. Archived from groups: rec.games.vectrex (More info?)

    Q: from a non-developer type...

    Would this help much??

    Would you be able to get alot more on the screen at once or is there a
    limitation on the screen or video hardware?

    As a developer, are there times that you thought "this would be much nicer
    if I could do this extra math, but there's not enough CPU time?"

    Just wondering..

    desiv

    "Clay Cowgill" <clay@yahoo.com> wrote in message
    news:5e0mc.25591$TD4.3736650@attbi_s01...
    > > One other little thing too I was thinking of was a math coprocessor chip
    > > for the Vec. It'd be an 8 bit I/O port that sits on the bus and is
    > > mapped into memory somewhere that would perform various math functions
    > > quickly to take the load off of the 6809 in the Vec.
    > [...]
    > > Comments? Suggestions?
    >
    > http://tinyurl.com/ytxwn
    >
    > then a little later...
    >
    > http://tinyurl.com/247qe
    >
    > I had finally settled in on a Scenix 50MHz part (just using the stock
    > Microchip math library functions). Eric Smith and I even went a couple
    > rounds discussing it, but the general lack of interest here didn't make it
    > too interesting. There were only a few people writing home-brews at the
    > time, so author support would have been minimal. Maybe people would be
    more
    > receptive to it now though...
    >
    > -Clay
    >
    >
  5. Archived from groups: rec.games.vectrex (More info?)

    "desiv" <villaesc@comcast.not> wrote in message
    news:ZNOdnXepvIx2FQTdRVn_iw@comcast.com...
    > Q: from a non-developer type...
    >
    > Would this help much??
    >
    > Would you be able to get alot more on the screen at once or is there a
    > limitation on the screen or video hardware?
    >
    > As a developer, are there times that you thought "this would be much nicer
    > if I could do this extra math, but there's not enough CPU time?"

    The main thing I was after was a good way to do "real" 3D transforms
    quickly. That's a lot of matrix multiplies which are pretty compute
    intensive. (My plan was to do a BattleZone port with true hidden line
    removal.)

    Lots of effects that look really cool on a Vectrex display just soak up lots
    and lots of the 6809 cycles-- particle systems, 3D transforms, etc. Ideally
    the coprocessor would basically free up all the Vectrex CPU. The Vectrex's
    6809 would then just be a full time rendering engine (and control reading
    and sound generation). All the 'heavy lifting' would be done with the
    coprocessor-- even up to running the actual game if you wanted to...

    -Clay
  6. Archived from groups: rec.games.vectrex (More info?)

    On Sat, 08 May 2004 02:38:49 GMT, "Clay Cowgill" <clay@yahoo.com>
    wrote:

    >Lots of effects that look really cool on a Vectrex display just soak up lots
    >and lots of the 6809 cycles-- particle systems, 3D transforms, etc. Ideally
    >the coprocessor would basically free up all the Vectrex CPU. The Vectrex's
    >6809 would then just be a full time rendering engine (and control reading
    >and sound generation). All the 'heavy lifting' would be done with the
    >coprocessor-- even up to running the actual game if you wanted to...
    >
    >-Clay
    >

    Would this be cost effective to add to a game cart (like the extra
    chip on mario kart for the snes)? That way you would be able to avoid
    the system upgrade needed. No one wants to buy the upgrade if there
    is no software and nobody wants to write the software if there is only
    a few poeple who own the upgrade. Sega proved a few times that
    upgrades don't work. I know John Dondzilla was thinking about this at
    one time. Just imagine the number of vectors you could have on the
    screen at once.

    Chris
    If life seems jolly rotten
    There's spmething you've forgotten
    and thats to laugh and smile and dance and sing!
  7. Archived from groups: rec.games.vectrex (More info?)

    "Chrisr" <crex@notalotofunwanted.bellatlantic.net> wrote in message
    news:22oo90p7n35622fogikmm3t1sk1djp3e9l@4ax.com...
    > Would this be cost effective to add to a game cart (like the extra
    > chip on mario kart for the snes)? That way you would be able to avoid
    > the system upgrade needed. No one wants to buy the upgrade if there
    > is no software and nobody wants to write the software if there is only
    > a few poeple who own the upgrade. Sega proved a few times that
    > upgrades don't work. I know John Dondzilla was thinking about this at
    > one time. Just imagine the number of vectors you could have on the
    > screen at once.

    Yeah, it's not a new idea-- Starpath did pretty well with the Supercharger
    on the the 2600 back in the day... (My original posting regarding a Vectrex
    version was about 8 years ago-- it'd be more like a DSP assist in StarFox on
    the SNES though. Built into every cartridge... Kinda like an extra POKEY
    in the Atari 7800 Ballblazer, or the extra sound chips in NES games and the
    like.)

    Anyway... If you assume that the 'average' number of clock cycles per
    instruction for 6809 is maybe ~4 and the Vectrex 6809 runs at 1.6MHz... The
    Vectrex is pushing roughly 0.4MIPS. (If there's lots of multiplies, those
    are ~11 cycles each, so you'd *never* get more than ~145,000 MUL
    instructions per second-- remember the Vectrex still has to draw the screen,
    execute game code, scan controls, update audio, etc.)

    Now then, take something simple like an Atmel ATMEGA16 microcontroller.
    $4.71/ea in qty 100. It has 16K of internal flash memory, and is 16MHz.
    It's average clocks/instruction is closer to 1, but let's call it 1.5 to be
    safe. It'll push maybe 10.5MIPS, or roughly 27 times the processing power
    of the Vectrex. It has a hardware multiplier that can do an 8x8 multiply in
    2 cycles too, so from a multiplication performance standpoint it's about 55
    times faster than the Vectrex.

    Once you take into consideration the fact that the 6809 still needs to drive
    the Vectrex display, read the controls, etc... There's really only a
    fraction of the total 0.4MIPS available for the game logic, plus whatever
    math you do.

    The bottle neck is really the 6809's speed of reading and writing to the
    coprocessor. Doing something like reading two values from a table (say that
    you want multiplied), writing them to a memory mapped port (to the
    coprocessor), and then reading back an answer (from the coprocessor) isn't
    going to be a huge benefit. But doing something like writing two bytes to
    the coprocessor (maybe for battlezone-- shape #, angle of rotation) and then
    reading back from mapped memory all the vectex data for a transformed and
    hidden-line removed enemy tank would be pretty smooth. :-)

    I stongly suspect that you could connect an ATMEGA16 directly to the
    cartridge bus on the Vectrex without any glue-- worst case under $0.50 worth
    of logic for a fully decoded port implementation. So, if you didn't
    need/want to charge a premium for it, there's not too much of a reason why a
    coprocessor would need to add anymore than ~$5-6 to the price of a cart.
    There's much more variation in cart pricing than that now simply based on
    who's making the cart, so I suspect that the market would bear it OK...

    -Clay
  8. Archived from groups: rec.games.vectrex (More info?)

    "Clay Cowgill" <clay@yahoo.com> wrote in message news:<UPvnc.14308$z06.2397352@attbi_s01>...
    <major snippage>
    > But doing something like writing two bytes to
    > the coprocessor (maybe for battlezone-- shape #, angle of rotation) and then
    > reading back from mapped memory all the vectex data for a transformed and
    > hidden-line removed enemy tank would be pretty smooth. :-)
    > -Clay

    Clay or others:

    Has anybody ever come up with a working Battlezone game for Vectrex ?
    I checked the archives and there was a lot of talk but no results.

    It would be really cool if it had a "double controller" option. So, you could
    hook up 2 controllers to have two joysticks simulating the real arcade game.
    I know - hitting the "fire" button would be a pain...

    I don't really care if it has hidden lines removed - would just like to play
    the game like the original arcade was.

    Tempest would also be nice, but without a color CRT and the big spinning
    knob - it just woudldn't be right. But maybe it could be written for the
    3-D glasses ! That would be a treat - to play color and 3-D !! I might even
    be ok using the joystick.

    :-)
    Peteski
  9. Archived from groups: rec.games.vectrex (More info?)

    peteski@my-deja.com (Peter W.) wrote in message news:<b2412277.0405092210.2df42b19@posting.google.com>...
    > "Clay Cowgill" <clay@yahoo.com> wrote in message news:<UPvnc.14308$z06.2397352@attbi_s01>...
    > <major snippage>
    > > But doing something like writing two bytes to
    > > the coprocessor (maybe for battlezone-- shape #, angle of rotation) and then
    > > reading back from mapped memory all the vectex data for a transformed and
    > > hidden-line removed enemy tank would be pretty smooth. :-)
    > > -Clay
    >
    > Clay or others:
    >
    > Has anybody ever come up with a working Battlezone game for Vectrex ?
    > I checked the archives and there was a lot of talk but no results.
    >
    > It would be really cool if it had a "double controller" option. So, you could
    > hook up 2 controllers to have two joysticks simulating the real arcade game.
    > I know - hitting the "fire" button would be a pain...

    This would be no problem using Clay's PSX adapter with a few tweaks to
    the adapter software... all that needs to be done is to map the X and
    Y of the analog stick to the vertical axis of each analog stick. Even
    a Saturn Virtual On stick would work with some appropriate hacking.


    > I don't really care if it has hidden lines removed - would just like to play
    > the game like the original arcade was.

    it might be more worthwhile to look into the adpatations that have
    been done to make a Vectrex display MAME output. Turn the Vec on its
    side and you have battlezone.

    keep in mind that Battlezone used a horizontal monitor configuration,
    so porting the game to a vertical monitor is a tremendous compromise
    in screen real estate (and IMO in the 'feel' of the game).

    I find it ironic that while the Vec has a vertical montior 'just like
    an arcade' the developers chose to licence mainly HORIZONTAL monitor
    games for the system: Rip off, Star Castle, Pole Position, Star Hawk,
    etc. Cosmic Chasm is a special case since the game was developed on
    the Vec first and became a coinop later.


    > Tempest would also be nice, but without a color CRT and the big spinning
    > knob - it just woudldn't be right.

    The Atari driving controller (not to be confused with the paddle) has
    been adapted to run on the Vectrex, and a few homebrew games use it.

    > But maybe it could be written for the
    > 3-D glasses ! That would be a treat - to play color and 3-D !! I might even
    > be ok using the joystick.

    The biggest limitation to writing new games for the 3D imager is the
    fact that the most economical solution for the majority of people to
    play the 3D games does not use colour. This may change in the future
    if the price of transmissive colour LCD displays comes down in price,
    but it will be a LONG while before anything happens. It's taken 10
    years for someone to really figure out how the imager workes and
    another 10 for us to have a workable approximation that was cost
    effective -- and that only does half the job!

    The second is the vector limitation/cpu cycles. The 3D process
    requires you to gobble up precious CPU cycles by drawing everything
    twice (and in some cases up to 6 times if you need to change colours).
    This is where I think the math coprocessor would really shine. There
    is no standard development kit for the 3D games and it would be nice
    to present the start and end conditions for movement in 3D space to
    the math copro and have it work out what the final vector set should
    be to change perspective on an object and remove hidden lines. The
    present way of programming 3D games tends to restrict the game action
    to planes that are parallel to the vectrex monitor, so as to keep
    things simple. The coprocessor would allow for much more complex 3D
    games to be programmed.

    And lastly would you want to play Tempest in only 3 colours? ;-)
  10. Archived from groups: rec.games.vectrex (More info?)

    Ocelot wrote:
    > And lastly would you want to play Tempest in only 3 colours? ;-)

    Well a Tempest cabinet is big, unreliable and expensive.

    And MAME isn't really using vectors.

    So Tempest wouldn't be so bad on the vectrex, however as a Tempest 2k addict
    I doubt I could go back to the original.

    Now if someone could do a good Star Wars....

    On a side note I tried Star Wars through MAME on an 8ft projector screen
    using a gyration mouse (you wave it in the air rather than needing a flat
    surface) the other night whilst sitting on my couch. Most excellent, if a
    little tricky.

    Cheers
    Marc
  11. Archived from groups: rec.games.vectrex (More info?)

    "Marc Goldman" <marc@countinghouse.co.uk> wrote in message news:<7kOnc.93$5a.81@newsfe1-win>...
    > Ocelot wrote:
    > > And lastly would you want to play Tempest in only 3 colours? ;-)
    >
    > Well a Tempest cabinet is big, unreliable and expensive.
    >
    > And MAME isn't really using vectors.

    Ahh but there are extensions to MAME that will drive a vector monitor.

    > So Tempest wouldn't be so bad on the vectrex, however as a Tempest 2k addict
    > I doubt I could go back to the original.
    >
    > Now if someone could do a good Star Wars....

    I'm still puzzled why people keep asking for ports of of the same
    vector arcade games that can be played in their original form
    elsewhere. Alex Herbert has the right idea in that he's ported games
    that you *wouldn't* think of putting on the Vectrex. There's plenty
    of relatively unknown games that are begging for a vector
    reinterpretation... how about Harmony (aka E-motion), or some
    oft-neglected Spectrum games, even something along the likes of
    Paradroid in theme or gameplay would be a refreshing change.

    > On a side note I tried Star Wars through MAME on an 8ft projector screen
    > using a gyration mouse (you wave it in the air rather than needing a flat
    > surface) the other night whilst sitting on my couch. Most excellent, if a
    > little tricky.

    I love the Gyration mice! My only quibble is that they eat their
    battery power fast and the current 'hold two buttons at the same time'
    scheme to concerve power is a bit cumberson. That being said, I keep
    wondering what I did without it. I'm sure someone will come up with a
    pointer device that sits on your index finger like a sewing cap with
    the same gyroscopic technology in a few years.
  12. Archived from groups: rec.games.vectrex (More info?)

    ....or tac/scan ? ;-)
  13. Archived from groups: rec.games.vectrex (More info?)

    Not to mention that there pretty much is a Tempest (Tsunami) and Star
    Wars (Star Fire Spirits) for the Vectrex.


    ---
    Manu
  14. Archived from groups: rec.games.vectrex (More info?)

    "Ocelot" <rob_ocelot@hotmail.com> wrote in message
    news:36249131.0405100819.40cd1cee@posting.google.com...
    > This would be no problem using Clay's PSX adapter with a few tweaks to
    > the adapter software... all that needs to be done is to map the X and
    > Y of the analog stick to the vertical axis of each analog stick. Even
    > a Saturn Virtual On stick would work with some appropriate hacking.

    It's entirely possible it's already supported... I had it in there at one
    time for UTG... I'll have to look at the source to see if I kept it or not.
    ;-)

    -Clay
  15. Archived from groups: rec.games.vectrex (More info?)

    "Ocelot" <rob_ocelot@hotmail.com> wrote in message news:
    > > Ocelot wrote:
    > > Well a Tempest cabinet is big, unreliable and expensive.
    > >
    > > And MAME isn't really using vectors.
    >
    > Ahh but there are extensions to MAME that will drive a vector monitor.

    But they are quite an expensive solution! But it is a good point.

    > > Now if someone could do a good Star Wars....
    >
    > I'm still puzzled why people keep asking for ports of of the same
    > vector arcade games that can be played in their original form
    > elsewhere. Alex Herbert has the right idea in that he's ported games
    > that you *wouldn't* think of putting on the Vectrex. There's plenty
    > of relatively unknown games that are begging for a vector
    > reinterpretation... how about Harmony (aka E-motion), or some
    > oft-neglected Spectrum games, even something along the likes of
    > Paradroid in theme or gameplay would be a refreshing change.

    I disagree. I want vector based games on a vector based system.

    If I want raster based games I can play them on a million different formats
    in their original form. Don't get me wrong, I love YASI and Protector and
    think Alex has done a brilliant job, but there are clearly more accurate
    ways to play Space Invaders or Defender.

    I want something within my reach where we can see the classic vector based
    games recreated, the Vectrex is potentially that system.

    > I love the Gyration mice! My only quibble is that they eat their
    > battery power fast and the current 'hold two buttons at the same time'
    > scheme to concerve power is a bit cumberson. That being said, I keep
    > wondering what I did without it. I'm sure someone will come up with a
    > pointer device that sits on your index finger like a sewing cap with
    > the same gyroscopic technology in a few years.

    I haven't had it long enough to know how the batteries cope and I am using
    the MCE remote. Which is nice even though I don't have XP Media Center
    Edition.

    Cheers
    Marc
  16. Archived from groups: rec.games.vectrex (More info?)

    Thanks to all of you for replies. I still don't have an answer if
    there
    ever was a Battlezone for Vectrex...

    I only occasionally lurk on this nwesgroup and I don't play with my
    Vectrex too much.
    Nowadays, I don't do much video gaming at all.
    So, I'm not up on all the current technology and terminology.

    I do agree with one of the posters: I would like to see other vector
    based
    games ported to Vectrex. I do have Atari Classics Batlezone game on
    my PC
    and it is an emulator of the real game. Still - Vectrex version would
    be
    welcome.

    Also - Tempest in 3-color 3D would be quite nice. Much better than if
    it was in
    B&W.

    And if the math co-processor became a reality - a 3D Tempest would be
    possible.


    Peteski
  17. Archived from groups: rec.games.vectrex (More info?)

    The Closest approximation to BZ is Chris' UTG title.

    That "game" (more of a demo) also requires a link cable. The appearnce of
    your opponent looks very similar to a BZ tank.

    But a full BZ replication has not yet been done.

    Chris


    "Peter W." <peteski@my-deja.com> wrote in message
    news:b2412277.0405111916.9c3bf5f@posting.google.com...
    > Thanks to all of you for replies. I still don't have an answer if
    > there
    > ever was a Battlezone for Vectrex...
    >
    > I only occasionally lurk on this nwesgroup and I don't play with my
    > Vectrex too much.
    > Nowadays, I don't do much video gaming at all.
    > So, I'm not up on all the current technology and terminology.
    >
    > I do agree with one of the posters: I would like to see other vector
    > based
    > games ported to Vectrex. I do have Atari Classics Batlezone game on
    > my PC
    > and it is an emulator of the real game. Still - Vectrex version would
    > be
    > welcome.
    >
    > Also - Tempest in 3-color 3D would be quite nice. Much better than if
    > it was in
    > B&W.
    >
    > And if the math co-processor became a reality - a 3D Tempest would be
    > possible.
    >
    >
    > Peteski
  18. Archived from groups: rec.games.vectrex (More info?)

    "Chris Romero" <nospamto-CROMERO-please-@ROMERO-dot.ORG> wrote in message news:<pSqoc.47608$UC6.25279@newssvr29.news.prodigy.com>...
    > The Closest approximation to BZ is Chris' UTG title.
    >
    > That "game" (more of a demo) also requires a link cable. The appearnce of
    > your opponent looks very similar to a BZ tank.
    >
    > But a full BZ replication has not yet been done.
    >
    > Chris
    >
    >

    Thank you Chris !
    Peteski
  19. Archived from groups: rec.games.vectrex (More info?)

    Clay Cowgill wrote:

    >Now then, take something simple like an Atmel ATMEGA16 microcontroller.
    >$4.71/ea in qty 100. It has 16K of internal flash memory, and is 16MHz.
    >It's average clocks/instruction is closer to 1, but let's call it 1.5 to be
    >safe. It'll push maybe 10.5MIPS, or roughly 27 times the processing power
    >of the Vectrex. It has a hardware multiplier that can do an 8x8 multiply in
    >2 cycles too, so from a multiplication performance standpoint it's about 55
    >times faster than the Vectrex.

    I'm hate to say it, but I think you're playing lances vs windmills...

    1.5Mhz at 20 fps = 75,000 cycles per frame

    Assuming 140 cycles per vector drawn at scale 127 ($7f) which includes
    the 127 cycles actually spent drawing as well as any loop/index
    overhead and the actual code needed to start/stop drawing - Which is
    probably conservative.

    If 100% CPU time is spent just drawing vectors, this yeilds a scene
    with a maximum of 535 vectors. This would occur if your copro did all
    calculation and just returned at display list for the Vectrex to draw.

    As far as scenes go, the best case is a scene which can be drawn as a
    single sequence of vectors, without ever having to turn the pen off or
    reposition the pen. In this case you would actually be able to get 535
    visible vectors.

    This is the equivalent of 133 4-sided polygons, 107 5-sided polygons,
    etc.

    This case will never happen, if only because of drift. It also implys
    a scene with only one, highly complex, object. Or a scene where all
    objects overlap. The former is of limited pracical use. The later
    can't be counted on all the time.

    The worst case scenario is one where the pen must be positioned to
    strat drawing a vector, draw the vector, reset0ref, and then be
    repositioned for the next vector. That is, none of the lines are
    touching each other.

    This too will never happen, however, it results in 267 visible lines
    in a scene.

    So, if the 6809 is tasked only to drawing vectors, the theoretical
    limits 535 visible lines and 267 visible lines.

    But what of practical limits?

    Assume a scene composed entirely of n-sided polygons. Each polygon
    will take 140+n*140 cycles to draw.

    So, for a scene composed of:

    4-sided polygons (700 cycles), results in 107 polygons which is 428
    visible lines.
    5-sided polygons (840 cycles), results in 89 polygons which is 445
    visible lines.
    6-sided polygons (980 cycles), results in 76 polygons which is 456
    visible lines.
    etc.

    Obviously this is going to depend upon how your scene is composed,
    what kind of polys your objects are made up of. It's also going to
    depend upon your copro's software and it's ability to optimise the
    sequencing of vectors to be drawn. Hidden line removal will help this,
    has will eliminating drawing vectors more than once - For examples, a
    cube is six 4-sided polys. However, if you draw all six of those
    polys, you wind up drawing all the lines twice, all of which count
    towards your totals. If your code can eliminate most of that
    duplication you're looking at a big performance boost. In addition, if
    any objects overlap you may be able to gain some more by drawing more
    complex shapes all in one go. As limited by drift.

    I think it's safe to say you're looking at a maxamium 450-460 visible
    lines.

    Now, on the other hand. What if there's no copro and we just deal with
    the Vectrex's limitations as is?


    What's a reasonable number of cycles to budget to our video driver vs
    the game engine?

    Well take the Atari 2600, which is the only system I'm really familiar
    with that has the same relationship with the video hardware as the
    Vectrex. Namely that the display must be serviced in real time. You
    don't get to just write to some registers whenever you have a chance
    and let the video hardware take care of things. And more importantly,
    the video hardware doesn't stay "live" until you change it, in the
    2600 and Vectrex if you don't service the hardware on time your
    display is pooched. (you know all this, I'm including this kind of too
    much information for everyone else who's reading)

    The 2600 runs at 1.19Mhz. Each frame, 14592 (76*192) cycles are spent
    drawing the video while 5320 (76*70) cycles are available (in the
    overscan and vertical blank) to run program code.

    If we assume that same ratio (73% video) on the Vectrex, then we have
    54961 cycles for drawing and 20039 cycles for game code.

    Using the previous metrics, our theoretical best case is 392 visible
    lines and a worst case of 196 visible lines.

    And a scene composed of:

    4-sided polygons (700 cycles), results in 78 polygons which is 312
    visible lines.
    5-sided polygons (840 cycles), results in 65 polygons which is 325
    visible lines.
    6-sided polygons (980 cycles), results in 56 polygons which is 336
    visible lines.
    etc.

    So you're likely looking at 330-340 visible lines.


    Comparing the two, you're looking at at 36% performance boost with the
    copro.


    Okay, okay, I can hear the objections already - 2600 games tend to be
    far simpler than a real 3D engine so that ratio is not realistic. True
    enough, however because of the different framerates, we actually have
    almost four times as many cycles available per frame. And we have a
    much more powerful CPU. And we have a lot more RAM. So I think those
    specs are, in fact, realistic. I've also been a little loose with my
    numbers, essentially assuming "zero friction" like a high school
    physics problem, with no overhead from a main loop, joystick input,
    &etc. Whatever, we're in the right ballpark.

    Assume our scene has 65 5-sided polys (some polys will be 4-sided,
    some will be 6-sided, some more, for the sake of argument figure an
    average of 5).

    We have 20039 cycles to deal with everything. That's 308 cycles per
    poly. That's 61 cycles per point or vector (depending upon how we
    express them).

    Simple left/right/up/down/foreward/back movement is no big deal, the
    tricky stuff is of course rotation and:

    y' = (cos(theta) * y) - (sin(theta) * z)
    z' = (sin(theta) * y) + (cos(theta) * z)

    Is looking pretty tight! But, if we only update 1/2 the polygons every
    second frame, we have 616 cyles per poly and 122 cycles per
    point/vector. Worst case if we move 1/4 of polys every 4 frames we
    have 1232 cycles per poly and 244 cycles per point/vector.

    Hidden line removal is a big, big problem. We don't have near enough
    RAM to do a nice, simple z-buffer. So we're looking at more maths -
    intersection of a line and a plane. But on the other hand, hidden line
    removal could simplify the scene which needs to be drawn and may "pay
    for itself". Though the only hidden line removal we can cound on is
    the back faces of objects. We can't always cound on two objects being
    in front of each other (unless we fix it that way, or course). But of
    course we can simply our hidden line removal if we just remove hidden
    faces. Umm, anyway...

    So, IMHO, it's doable (true hidden line removal may or may not be).
    I've long wanted to do a Torque for the Vectrex. It's just a matter of
    doing it. I've been easing back into Vectrex, but time is a serious
    concern right now so I dunno if I'm going to be up for it any time
    soon. And I still have several 2600 projects that really need
    finishing up.

    The big problem with UTG is it cheats too much. The maths are 8 bit
    which leads quickly to rounding errors. The tanks are not 3D objects,
    they're precalculated flat sprites and the Vectrex scale property is
    used, which is inherantly flawed and not linear so the tanks don't
    really rescale right which leads to more visual problems.


    Chris...
  20. Archived from groups: rec.games.vectrex (More info?)

    Christopher Tumber wrote:

    >much more powerful CPU. And we have a lot more RAM.

    In addition, we can recover some of the cycles used while waiting for
    the pen to draw. If we can recover even 110 cycles per line, in a
    scene with 330 lines, that's more than 36,000 cycles (more than
    doubling our available cycles!)

    Now that I think of it, going back to a display engine that uses 100%
    CPU time just to draw. If we ONLY use "recovered" cycles for our game
    code and we're displaying 450 lines. That's about 49,500 cycles
    available to game code.

    Again, 110 cycles per line for transforms. Our double that if we
    update 1/2 every other screen. Or...

    Yeah! Yeah! Yeah! That freak'n rules!

    Maybe I can call in sick this week...


    Chris...
  21. Archived from groups: rec.games.vectrex (More info?)

    Christopher Tumber wrote:

    Actually messing around with some code, 190 cycles per vector drawn is
    a more realistic figure and something around 50 4-sided shapes (polys)
    drawn is near the practical limit. You could achieve more complex
    looking scenes using polys with more sides and hidden line removal but
    somewhere around 250 lines (visible and invisible) is close to a real
    maximum. You can get around this with some trickery, for example in
    drawing grids by turning the pen on and off as a long line is drawn
    but as far as being able to draw arbitrary vectors that's about it.


    Chris...
  22. Archived from groups: rec.games.vectrex (More info?)

    "Christopher Tumber" <christophertumber@rogers.com> wrote in message
    news:40a79893.4517168@nntp.slnt.phub.net.cable.rogers.com...

    (Methinks you have *way* too much time on your hands Chris. ;-)

    You're making a couple of oversights in your assumptions which are probably
    influencing your analysis a bit too much.

    Two main things:

    * you're assuming that the bulk of the 'work' is just in the scene rendering
    (ie, simple 'kernel' type games)

    * you're assuming 20fps

    The first one alone is a killer. The coprocessor could:

    a) run realtime physics-type number crunching-- throw a bunch of
    gravity/acceleration/rules at, say, a particle emitter/system. The vectrex
    draws the dots, the co-pro does *all* the rest. Or mass/gravity
    calculations for a more involved spacewar type game, or the balls in a
    billiards game, etc...

    b) collision detection-- the co-pro could handle true polygon-to-polygon
    collision detection for 3D, or vastly improved point-in-polygon 2D collision
    detection.

    c) scene rendering-- the co-pro could do all hidden line removal, backface
    culling, visible surface determination, etc. (Maybe even optimize some of
    the resulting display list for more efficient drawing on the Vectrex as you
    mention, although that's a tricky "find the shortest route" problem.)

    d) music/synthesis-- the co-pro could generate realtime waveforms to be
    played by the Vectrex DAC. (The Vectrex gets a 256 byte buffer every frame
    to play by timer interrupt or something.)

    The second part is obvious...

    Run the display faster to get rid of some of that nasty flicker. If you
    shoot for 30fps updates, your available cycles might do more like 50,000 per
    frame. That's probably right around your calculated practical limits for
    max vectors in a scene anyway. (Plus you still need sound and inputs and
    the like.)

    Add in the possibility of the new 3D glasses being used and things get even
    more interesting-- you could increase the framerate to reduce flicker and
    keep the vectors/field up and enhance the 3D effect while letting the co-pro
    pick up the heavy lifting of creating the more interesting scenes while the
    Vec handles the improved display.

    I think the co-pro would be about improving the overall potential of the
    games as much as anything. Running real 16 bit unit vector math on a co-pro
    with a hardware multiplier would be pretty efficient I'd think...

    On the other hand, trying to do a real matrix multiply with 16 bit precision
    just to transform each point in a polygon on a 6809 with only 122 *cycles*
    per point sounds pretty dicey to me. For six degrees of freedom with each
    object and the POV we're talking like 9 multiplies per point or something,
    plus the adds, plus the trig? (I dunno, I haven't done 3D stuff from
    scratch since college in '92!) Even if you get the trig answers from table
    lookups that's probably still another 9 lookups? Seems like we're talking
    well in excess of 27 instructions (assuming you could do 16 bits in one
    instruction on all the required operations). With general purpose
    multiplies taking ~11 cycles/ea and 16 bit table lookups at ~5? We're
    around 144 cycles without any adds, or stores or anything. After that you
    still have perspective, clipping, hidden surface/line determination/removal,
    etc... I think there's a reason there's not much 'real' 3D running on
    6809's. ;-)

    Maybe you have a really fast/clever multiplier routine and trig stuff to
    help get that down-- otherwise you have to start limiting the game/scene
    behaviour to fit what the Vec can do 'native'. Getting around the 'native'
    limitations of the Vec is sort-of what a co-processor would be all about.
    :-)

    Too bad the Vectrex didn't bring out DMA/BREQ/BS/BA out to the cartridge
    port. The cart could've just taken over as a bus-master and driven all the
    Vectrex hardware directly!

    -Clay
  23. Archived from groups: rec.games.vectrex (More info?)

    Clay Cowgill wrote:

    >(Methinks you have *way* too much time on your hands Chris. ;-)

    I wish!! Then I'd have the thing actually written, instead of just the
    design specs.

    - 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.
    And this hardware restriction limits the number of possible polys to a
    small enough number that we should be able to (mostly) handle it
    through conventional means.

    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
    (up/down/left/right/in/out) is easy, some adds.
    Rotation is the bitch - The trig is all going to be look-up tables,
    nobody's going to actually code real Since and Cosine functions, so
    rotation about any 1 axis is 4 multiplies and 2 adds. Around all 3
    axis is 12 multiplies and 8 adds. Which is prety painfull, so only
    move one axis per frame. No big deal. Rendering the 3D scene into 2D
    is a couple divisions. If the "camera" is movable, which is pretty
    much has to be then that's either some transforms at render time, or
    we express it as transforms on all objects. Which means more rotations
    on a different axis. All a big pain in the ass, but that's why no
    one's done it yet. And then we have to do clipping.

    Hidden line removal is pretty unlikely, though we can probably fudge
    hidden face removal from within objects without too much trouble.

    - 30 fps doesn't make any real difference (And given that pretty much
    everything to date is 20 fps I don't really see the added frame rate
    being all that significant). At 30fps you only have 50,000 cycles to
    draw you whole scene, regardless of how it's been calculated. So
    you're going to have time to draw only 2/3 as many polygons. So while
    you don't have as much time overall to do your calcs, you still have
    just as much time per polygon as before.

    - The 3D glasses also don't make any difference. Since you have to
    draw the screen twice per frame, you're only going to be able to have
    half as many polys onscreen. And while you need to do the 3D to 2D
    projecttion twice, once for each view, that's the easy part. You
    only need to do the transforms and rotations once - Things actually
    get easier with the goggles!

    - Unless you're doing speech synth, a music routine doesn't eat a lot
    of cycles - You're just reading from a buffer and pushing into the
    registers. Which is exactly the same thing you'd be doing from the
    copro cart.

    If you want to go and design some cool custom hardware, I'm obviously
    not going to stop you. I'm just strongly suggesting you make a serious
    cost/benefit analysis.

    Hidden line removal and real poly collision detection (versus bounding
    box or bounding sphere) I don't really see as "killer aps".

    >Too bad the Vectrex didn't bring out DMA/BREQ/BS/BA out to the cartridge
    >port. The cart could've just taken over as a bus-master and driven all the
    >Vectrex hardware directly!

    You could do something almost as good - A cartridge that has 2K RAM
    which can be addressed directly by a program running on the Vectrex
    (address it as one of the Shadow RAM locations) and by either a
    program running on a copro on the cart, or a VecRAM-like cable to a
    real PC. The program running on the Vectrex would simply continuously
    read that 2K buffer and draw the appropriate vectors (and maybe make
    the appropriate writes to the AY for music). The copro or PC would
    feed the values right into the RAM on the cart. You might need some
    way for the main program to signal the copro/PC (ie: joystick input)
    but that's about it.

    Chris...
  24. Archived from groups: rec.games.vectrex (More info?)

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

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

    > - 30 fps doesn't make any real difference (And given that pretty much
    > everything to date is 20 fps I don't really see the added frame rate
    > being all that significant). At 30fps you only have 50,000 cycles to
    > draw you whole scene, regardless of how it's been calculated. So
    > you're going to have time to draw only 2/3 as many polygons. So while
    > you don't have as much time overall to do your calcs, you still have
    > just as much time per polygon as before.

    I sure can see a difference in display quality, maybe I'm just special. ;-)
    I think the main reason most games run slower is because they have to, not
    because they want to. If you can run a 30fps display with the coprocessor
    (having the co-pro run the bulk of the game even) then virtually all those
    50K cycles can go to drawing...

    > - The 3D glasses also don't make any difference. Since you have to
    > draw the screen twice per frame, you're only going to be able to have
    > half as many polys onscreen. And while you need to do the 3D to 2D
    > projecttion twice, once for each view, that's the easy part. You
    > only need to do the transforms and rotations once - Things actually
    > get easier with the goggles!

    Huh? If you render with goggles at a higher frame rate, flicker will be
    reduced. Similarly, if the Vectrex has more free cycles available per frame
    (as the result of the co-processor taking more of the load), the Vectrex can
    render a more complex scene. (more lines)

    > - Unless you're doing speech synth, a music routine doesn't eat a lot
    > of cycles - You're just reading from a buffer and pushing into the
    > registers. Which is exactly the same thing you'd be doing from the
    > copro cart.

    That's kind-of the point. You could feed raw wave data. For example, a
    single NAND flash chip (or MMC/SD Card) hanging off the co-pro could
    provide tons of sampled music loops for the game... Or just use the co-pro
    to generate FM sounds on the fly to get away from the 8910 waveforms for
    sound/music all the time. Or like you said-- let the co-pro to phonemes and
    send the digital data to the Vectrex to play through the DAC. (VecVoice
    built into the cart, and no need for an external speaker! ;-)

    > If you want to go and design some cool custom hardware, I'm obviously
    > not going to stop you. I'm just strongly suggesting you make a serious
    > cost/benefit analysis.

    The long and short of it is that there is a 'level' of games that could
    *not* be done on the Vectrex now without hardware assist. Sure, you can cut
    corners by limiting the number of transforms per frame, or limiting the
    scene rendering to be what the Vectrex *can* pull off... But that's the
    whole point of putting a co-processor in! (just like Atari's decision to
    augment the 6809 in Star Wars with the Mathbox). ...to get around existing
    limitations. Like you said-- the 3D math stuff is a bear to implement, but
    if there was a generic cart that had a co-processor in it that just had a
    nice little API that "did it for you" there might be some interesting new
    games developed, if only because it was suddenly easier to do!

    (Kinda like the difference between having to develop code with an eprom
    emulator vs a PC hosted software/system emulator. There was a huge boost in
    home-brews once the emu was working just because the barrier to entry was
    much lower. I see a co-pro as lowering the barrier to entry for 'true' 3D
    and more sophisticated visual/audio effects. ;-)

    > You could do something almost as good - A cartridge that has 2K RAM
    > which can be addressed directly by a program running on the Vectrex
    > (address it as one of the Shadow RAM locations) and by either a
    > program running on a copro on the cart, or a VecRAM-like cable to a
    > real PC. The program running on the Vectrex would simply continuously
    > read that 2K buffer and draw the appropriate vectors (and maybe make
    > the appropriate writes to the AY for music). The copro or PC would
    > feed the values right into the RAM on the cart. You might need some
    > way for the main program to signal the copro/PC (ie: joystick input)
    > but that's about it.

    Yeah, my original plan was just to use the available PIA bit (PB6) on the
    cart port as a "ready" signal to the processor that a shared memory space
    was free to access. (Kinda like signaling that video memory is "safe" for
    the CPU to access during VBLANK on a raster-based system without true dual
    ported memory.) At the time I was thinking you could just put the "OK for
    co-pro access" inside wait_recal or somewhere in the code when the shared
    RAM definitely wouldn't be accessed.

    OTOH, just a read/write port would be a lot easier/cheaper to implement.
    (just have the co-pro act as an auto-incrementing pointer to its own
    internal SRAM-- more like the video memory ports on a SNES or something)
    Writes to address 'A' go to the coprocessor filling a memory array with
    auto-increment. Reads from address 'B' pull from a read pointer. Writes to
    'C' reset the read pointer, writes to 'D' reset the write pointer.

    I suppose if you *had* to, you could have a location or two to write a byte
    to that sets the top eight bits of the read/write pointers, although I bet
    you could work around it...

    -Clay
  25. 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.
  26. Archived from groups: rec.games.vectrex (More info?)

    "Zonn" <news-zonn@zektor.AOL.com> wrote in message
    news:mlbna092o0vfso9rrotbvn0qnr8ugbbtcj@4ax.com...
    > 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.

    Hmmm, quite possible... I supose the thing to do might be to just take a
    really 'complex' scene (like convert a vector list from the arcade Space
    Duel or something) and turn the Vectrex loose just rendering the vectors as
    a static image. See how far into it you can draw in ~15-20-25-30fps. Be
    kinda cool. :-)

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

    Heh-heh. Cool. :-)

    > You could communicate between the two using memory mapped ports. It all
    seems
    > very do-able. But would it sell?

    Yeah, that was why I was thinking to try to keep it sub ~$5-7 COGS adder to
    a cart. Kind of like the EEPROM in the Protector carts-- it's just in there
    as a cool feature and the price is absorbed in the price of the cart. We
    have home-brews selling in the $15 range and we have homebrews selling in
    the $30+ range and the COGS is not *that* different between them, so you'd
    think you could take a $15 game, add the coprocessor, sell it for $25 and it
    could still sell. Or couse the author's not making any more money really
    for it, but it would have the 'gee whiz' factor which is a nice perk. ;-)

    -Clay
Ask a new question

Read More

Console Gaming Video Games