Vectrex side processor in the 2K shared space.

[crcasey]

I am making some assumptions here since I have not seen this in the documentation.

You are loading some functions as standard into the 2K of shared ram that allow the 6809 and Vectrex hardware to act as a display list processor.

You turn the basic display into an optimized instruction list that call on board ROM calls in the 8K space the internal Rom has to do the drawing, and read controller status into the shared ram per hardware frame.

You can change these shared ram updates dependent on how fast the 6809 can do the draw commands.  And you idle the 6909 the rest of the time.

Is there a rule of thumb of how many vectors you can fit into the 2K and still make them run in one frame?  That would seem to be the way to run it, and the calculate the frame rate and the music rates back from that.

Does that make sense? 

-Cecil

[Vectrex32]

In some frames, you might draw a lot of lines. In other frames, you might draw only a few. And yet it's important that the frame rate be constant (otherwise the apparent brightness of the lines would vary). So even if I could look at a drawing list and figure out how long the 6809 will take to draw it (which would be a very difficult thing to do) it would not be a good idea to adjust the frame rate based on that.

- Bob

[crcasey]

In some frames, you might draw a lot of lines. In other frames, you might draw only a few. And yet it's important that the frame rate be constant (otherwise the apparent brightness of the lines would vary). So even if I could look at a drawing list and figure out how long the 6809 will take to draw it (which would be a very difficult thing to do) it would not be a good idea to adjust the frame rate based on that.

- Bob

When you are in a break is there a way to inspect or decompile the  6809 state?  Like getting a load level reading on the Vectrex?
That way you could see how heavy you are stressing the shared memory or vector drawing?  Maybe having the option of interleaving the 6809 display processing?

-Cecil

[Vectrex32]

There's 2K of shared memory. Subtract a bit for overhead and assume three bytes per vector or pen movement, and you've got maybe 500 lines. You need to refresh at 30 frames per second or better to avoid flicker. So that's 15,000 lines per second. I'm pretty sure the Vectrex analog circuitry is nowhere near fast enough to do that.

I don't think the sort of analysis and optimization you're thinking of is really necessary (and of course, I wouldn't expect typical BASIC programmers to want to get into that sort of stuff).

- Bob

[Vectrex32]

Is real space time curved?  Yes, it has virtuial particals stored in it.  The larger mass you have the more virtual particles you can store on short time frames.  Thus gravity comes from increased density of virtuial particals creating extra energy in local fields.  But if they don't effect the magnetic field then you can find a splitting.

I don't know how late it is in your part of the world, but I think you're getting a little punchy. Time to log off and go to bed. ;-)

- Bob

[crcasey]

On the bright side for you I have asked the questions I wanted to ask for now.

Thank you so much for taking the time to answer me.

-Cecil

[Vectrex32]

But there are a lot of line drawing series optimizations you can do on the server side.

I wouldn't want to try that in Vectrex32 code. If the user has two lines in a sprite, they are guaranteed to be joined at an endpoint. If you split those lines apart in an attempt to optimize, that connection will not be perfect. Also, to avoid pen drift, you need to return the pen to the origin periodically.

It's certainly something you can experiment with in BASIC (same for your raster graphics idea) but I wouldn't implement it in firmware.

- Bob