|
|
Post by bob on Nov 29, 2016 9:36:11 GMT -5
Hi,
I've been doing experiments with frame rates for the Vectrex and Vectrex32. It appears that the maximum rate I can get is 45 fps. I'm not sure if that's due to a Vectrex limitation or something in the Vectrex32.
So my first question is, what is the maximum frame rate that people have been able to get from the Vectrex?
If the maximum rate is, indeed, 45 or thereabouts, then how on earth does the 3D viewer work? It runs at 27 rotations per second. In that time, it presents red, green, and blue images to each eye, so that's 6 different images. That would mean the Vectrex has to draw 162 frames per second. How can that be?
Thank you,
Bob
|
|
|
|
Post by christophertumber on Nov 29, 2016 13:24:04 GMT -5
Must be an issue with Vectrex32 or the code you are using (How are you setting and determining the framerate?). The clockspeed of the MC6809 is 1.5 MHZ so the maximum theoretical framerate is 1.5 million per second. For practical purposes, drawing something quick like a single moving dot you should easily be able to generate several thousand FPS.
|
|
|
|
Post by bob on Nov 30, 2016 10:45:02 GMT -5
I'm seeing a minimum frame time of about 10ms. That's including reading the buttons, reading the joystick, and doing a Reset0Ref. If doing those things really takes that long, then the upper limit on frame rate would be 100 fps. But that's before anything is actually drawn.
Is it plausible that reading the controls and resetting the beam would take that long?
|
|
|
|
Post by christophertumber on Dec 1, 2016 12:03:22 GMT -5
Reading buttons and joysticks are very slow operations.
|
|
|
|
Post by bob on Dec 1, 2016 12:21:17 GMT -5
Reading buttons and joysticks are very slow operations. So we come back to my original puzzle: If resetting the pen and reading buttons and joysticks takes 11 ms, and a 3D glasses game requires a frame rate of 180 (5.6 ms per frame), how is it done? - Bob |
|
|
|
Post by christophertumber on Dec 1, 2016 14:00:40 GMT -5
I'm seeing a minimum frame time of about 10ms. That would be 15,000 cycles. I don't have nearly enough information to say what, exactly, but something seems very wrong here. How are you determining the various numbers you're using in this thread? (10ms, 45fps, etc) |
|
|
|
Post by bob on Dec 1, 2016 14:16:44 GMT -5
The Vectrex32 writes 6809 code into dual port memory and sets a flag telling the 6809 to execute it. The 6809 is in a tight loop looking for that flag. The 6809 runs the code, then writes into a special dual port memory location that interrupts the Vectrex32. I'm measuring the time from when the Vectrex32 issued the signal to when it received the interrupt. I'm seeing 10ms.
It's certainly possible that I'm introducing a huge delay somewhere. All I really needed to know is whether this is expected timing from the Vectrex or not. Sounds like it is not, so the problem is somewhere on my end.
Thanks,
Bob
|
|
|
|
Post by christophertumber on Dec 1, 2016 15:17:02 GMT -5
I have no knowledge of the Vectrex32 but these: The Vectrex32 writes 6809 code into dual port memory and sets a flag telling the 6809 to execute it. then writes into a special dual port memory location that interrupts the Vectrex32. Probably aren't free. How long does this take with minimal code (ie; not polling button or joystick, not drawing anything, no reset0ref)? |
|
|
|
Post by christophertumber on Dec 1, 2016 15:22:10 GMT -5
Ok, just watching the Vectrex32 intro video.
1:50
"30 times per second the pic32 writes commands writes commands into the dual port memory".
|
|
|
|
Post by bob on Dec 1, 2016 15:22:29 GMT -5
Less than a millisecond (the Vectrex32 operating system heartbeat is 960Hz, so I can't easily measure less than 1ms). - Bob |
|
|
|
Post by bob on Dec 1, 2016 15:24:38 GMT -5
Ok, just watching the Vectrex32 into video. 1:50 "30 times per second the pic32 writes commands writes commands into the dual port memory". Yeah, that's just because I set the frame rate to 30. There's a function that lets you set the frame rate higher. It works correctly up to 48 frames per second, but after that something is taking too long. - Bob |
|
|
|
Post by christophertumber on Dec 1, 2016 15:39:56 GMT -5
Ok, let's take a step back.
At a very high level my understanding of what you are doing is:
- You have some kind of main loop dedicated to I/O (drawing, polling controllers,sound) running on the Vectrex.
- The PIC periodically writes to this main loop to change what to draw (etc).
- A BASIC program running on the PIC updates the data that needs to be pushed to the vectrex.
The only possible bottlenecks are:
- The loop you have running on the Vectrex
- The speed at which the PIC writes to the Vectrex
- The speed at which the data on the PIC is updated (Speed of BASIC program)
The speed of the BASIC program should be irrelevant - if it's slower than the framerate you should just be pushing duplicate frames.
If you're satisfied the rate data is being pushed to the Vectrex is fast enough then the only thing remaining is your main loop. Have you tried running something super simple like:
main:
jsr intensityto7f
lda #$FFFF
jsr drawtod
jsr reset0ref
jmp main
|
|
|
|
Post by bob on Dec 1, 2016 15:54:13 GMT -5
It's more complicated than that. There's a real time operating system servicing the USB port on one thread, the user's program on another thread, and the Vectrex on a third thread. Both the USB and Vectrex threads interact with the user thread.
There are many opportunities for me to screw up timing in all that!
- Bob
|
|
|
|
Post by christophertumber on Dec 1, 2016 16:59:16 GMT -5
Can you turn the USB thread off for testing once you have some simple test code up and running? (To remove that as a possibility)
How complex is the code running on the Vectrex? (my money is on there being bottlenecks in there)
Is it possible to bypass the BASIC interpreter and push machine code directly to the Vectrex? Or modify the code running on the Vectrex? Depending on how you're handling the Vectrex screen/sound/controller IO there's potential for all kinds bottlenecks there.
|
|
|
|
Post by hcmffm on Dec 1, 2016 17:29:40 GMT -5
I just quickly read through the previous postings. FAIK, reading analogue controller values takes quite a bit of time. Are all controller values determined in each cycle of the loop? Perhaps reading the controller values less often or reading analogue values only if the programmer really wants analogue values might help.
Please note that I'm far from being an expert in Vectrex programming and performance so please do not count too much on my ideas...
|
|
