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 effectsThe controls[2, 2] value would not update, it was always stuck at 0

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

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.

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.

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

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.