Further Testing Required - Potential controller read errors

[Astrosynthesist]

Hello,

I'm using firmware 1.14 on my Vectrex32.

As we're all aware lunar lander has a scaling issue - the terrain widens and shrinks in accordance to Joystick 1 Y position. The greater the Y value, the wider the terrain. The lower the Y value (including to negative values even though the code excludes them immediately when assigning the value joyY) the more shrunken the terrain. After assigning joyY the code never references controls[1, 2] again, and since negative values of Joystick 1 Y still affect the terrain scale, then the bug cannot be in the code for Lunar Lander.

With that in mind I decided to then change the Lunar Lander code such that it relied only on Joystick and controller 2. This is where further testing is required. I have never tested my Joystick 2 port as I have no multiplayer games nor a second compatible controller. When I set up Lunar Lander to use controller port 2 some peculiar things happened:
The terrain scale issue disappeared.
The buzzing of my Vectrex changed in pitch with the vertical movement of Joystick 2  (up made pitch rise, down made pitch fall) which normally means something should be changing on screen however I could not see any visual effects
The controls[2, 2] value would not update, it was always stuck at 0

So for me Joystick 2 Y is permanently assigned the value 0 (in digital mode as well)
I decided to try Joystick 2 X for thrust instead.

Once again no terrain scaling issues. The X values functioned as expected and I was able to play but with a new bug (I haven't actually recorded this effect explicitly, I can only describe the effect right now)
At full thrust (Joystick 2 X full right) the game produced full thrust.
At full thrust (Joystick 2 X full right) and button 2 pressed, the game rotated the craft and reduced thrust so that it was not at maximum thrust.
At full thrust (Joystick 2 X full right) and button 3 pressed, the game rotated the craft and reduced thrust so that it was less than when button 2 was pressed.
I did not record the actual change in values but once again this was almost definitely due to a bug in the WaitForFrame function as this would imply that the value in controls was incorrectly assigned.

In summary:
1. Somehow Joystick 1 Y affects terrain scale
2. Joystick 2 Y is only assigned a 0 from waitForFrame() (but affects the pitch of the buzz for some reason)
3. Joystick 2 X value is affected by Joystick 2 buttons 2 and 3 from waitForFrame()

I have also managed to make the Vectrex32 crash in a few different ways. I'll make a separate thread for that.

[Vectrex32]

As we're all aware lunar lander has a scaling issue - the terrain widens and shrinks in accordance to Joystick 1 Y position.

We are? It does? I was not aware that LL has a scaling issue. Who else is aware of this? No one told me.

When you get close to the ground, the scale changes so you can see the ground more clearly. The original arcade game did this too. Is that what you're referring to?

- Bob

[Astrosynthesist]

Apologies, I figured it was generally known  as I experience it with my Vectrex and I noticed it in the background of VectrexRoli's video on the Vectrex32 (two is not everyone, so my bad). So what happens is on the left side of the screen the terrain stays anchored at the correct spot but the terrain expands to the right in relation to the position of the Controller 1 Y value. So when the stick is all the way up the terrain stretches out to the right with the vectors on the right side of the screen expanding most. If I move the stick down, the vectors all shrink such that the right hand side of the screen appears to move to the left. This is specifically in relation to the postiion of the controller 1 Y value, and only when the controller is actually being read by the waitForFrame function.
The lander however does not have this scaling issue, and neither does the text at the top of the screen.

[Astrosynthesist]

https://youtu.be/wfow8xKGZZ0
Skip to 11:19
It appears as though I have the expansion/contraction directions backward - up = shrink to left as seen in the video

[Vectrex32]

https://youtu.be/wfow8xKGZZ0
Skip to 11:19
It appears as though I have the expansion/contraction directions backward - up = shrink to left as seen in the video

Wow, that's stunning. I never noticed that before but if I look for it on my Vectrex, I can see it. I  have no clue why it would be happening.

- Bob

[Astrosynthesist]

It is strange indeed, but I'm glad at least I'm not crazy.

I'm also interested to know if my controller 2 port is broken or not, no rush but when you have a chance can you duplicate the controller 2 issues in LL? All I did was switch "controller1" to "controller2" and update the references for controls[1, *] to controls[2, *], and later when Y didn't work changed controls[2, 2] to controls [2, 1] (and found that buttons affect the X values of controller 2). Again, not trying to rush you but I just want to be sure that my Vectrex isn't broken.

[Vectrex32]

I can confirm that Controller 2 doesn't seem to be working right.

[Astrosynthesist]

Okay, thank you

[Astrosynthesist]

Out of curiosity I tried something tonight with interesting results.
I stopped all running programs and entered these lines into the shell:

while true
buttons = waitforframe(2,3,3)
call clearscreen()
call TextSprite(buttons[1,1] + " ")
endwhile

It works, and when I change the frame rate the frame rate indeed does change.
Here are the peculiarities:
Moving the joystick left and right changes the values of the digits on screen
Moving the joystick up and down changes the sound of the buzz that the vectrex makes and also moves the text on screen ever so slightly.
This is weird as I would have expected the raster font to not be affected by the vertical position of controller 1.

[Vectrex32]

I found the bug in my code that prevented the V32 from reading the Y axis of controller 2's joystick. It will be fixed in the next firmware release.

- Bob

[Astrosynthesist]

Awesome!

Any luck with the weird Controller 1 Y axis behaviour?

[Vectrex32]

Any luck with the weird Controller 1 Y axis behaviour?

You mean where the terrain shrinks? The short answer is "beats me".

I played with it a little.  If I draw the same LEM regardless of the joystick (i.e. the same amount of thrust coming out the rocket bell), the problem still occurs, so it's not that the LEM drawing is affecting the terrain drawing. If I read the joystick as digital instead of analog, the terrain problem doesn't happen.

There's only one digital-to-analog converter in the Vectrex and it's shared between the joystick and the vector drawing. So my hypothesis is that reading an analog joystick affects the D/A converter which affects the screen. I asked Malban about it and he didn't have any experience with it. He said he'd look into it, but he might not be able to get to it immediately.

- Bob

[Astrosynthesist]

Now that you've fixed reading controller 2 Y axis, does it exhibit the same behaviour?
If not, could it be some kind of memory conflict?

[Vectrex32]

No, controller 2 doesn't exhibit the same behavior.

- Bob