Messages

Easy to replicate technique for vectrex32 crash in Demo3d:

Hold Button 3
Hold stick left

The first tie fighter should whizz off to the left and in a matter of a few seconds the vectrex32 will crash (I get ejected from my terminal session), then the vectrex/vectrex32 will reboot with the typical vectrex32 title screen (but interestingly with a highscore of 0 appearing as well), and it functions as normal again.

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.

As a quick update I have made the 3d demo run out of memory in the manner you specified (being able to still communicate over the command line and recover) but I have also made the vectrex32 crash - it involved generating about 5 fighters, pressing buttons 2 and 3 at the same time (and moving the stick up, zooming in), then rotating them off the screen to the left, not even very far off frame. The Vectrex32 crashed and I was ejected from the terminal session. I will work on a technique to reliably replicate that crash in the near future.

In your docs you mentioned that heavy computation might slow down the frame rate... next time I play around with it I'll start removing blocks of code here and there until I find whether or not the limiting factor is one particular call or a combination of everything that's causing the slowdown. I'll probably be playing with it again on Saturday or Sunday.

Okay, thank you

Has anyone successfully adjusted the frame rate for LL?

I tried calling setFrameRate(120) at the beginning of the code, which did speed up the text and stop the text from flickering, but then when the game starts everything runs very slowly (as in the timing seems to be wrong: rotations are slow, gravity is slow, etc, but the unit itself is running at the correct speed) and the flicker is still present. I'm wondering if I'm missing something.

Thanks

In my case I'm specifically referring to LL; supposing the LEM gets removed from the drawing list above the top of the screen, (making the moon image static), what possible way could the Vectrex32 produce a bad command that crashes the Vectrex (if it can already produce the moon landscape successfully) unless it is still trying to draw the LEM as its altitude increases.

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.

Interesting. I hadn't crashed it while connected to a terminal yet but it's very interesting that they look similar even though they're completely different.

What happens when a sprite leaves the scope of the screen? Does it still send draw commands to the Vectrex (making the vectrex attempt to draw outside the edges of the screen)? I'm not too sure if the assembly supports that or not... if that's what's happening though maybe it's possible it exceeds some size limit for the command (and the Vectrex can't deal with it). When dealing with something like MineStorm, how does the Vectrex determine the edge of the screen to wrap objects? Maybe you could use that convention to remove any sprites from the draw list that exceed those limits (or wrap them depending on the game).
Thanks!

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

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 always like to stress test things to find their limits... I only have three things to report so far.

Firmware 1.14:

1. In lunar lander. If I decide I want to be facetious and leave lunar orbit rather than land, I find that reaching 20,000 feet the Vectrex screen starts to flash at approximately 10-15 fps. From there, up to about 24,000 feet it continues to flash and then finally crashes (screen goes black, unit is unresponsive). Requires a hard reset to operate again.

2. In 3d Demo, adding too many crafts makes the screen flicker again (about 5) and they have to be in frame. If 5 crafts are generated and then some are excluded from the frame, it is fine. Eventually with too many in frame at once the unit crashes as above and requires a hard reset to operate again. I originally thought it was too many lines but that doesn't explain why the unit crashes. Also it slows down to about 10-15 fps and doesn't slow down proportionally with every new craft added, so it's hard to explain from my end. I have not looked into the code for the 3d Demo yet.

3. Also in 3d Demo I can move the crafts off screen far enough to crash the Vectrex32 like before. Pressing buttons 2 and 3 together produces undocumented behaviour that I can't really explain as well (zooming functinos it appears).

That's all for now. I'm having a lot of fun so far. Thanks for all your hard work!

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.

Haha, yes I know the Vectrex32 runs standalone. What I'm saying in that poor example is case: Download program from Vectrex32 with Vectrex off, modify program with Vectrex off, upload to Vectrex32 with Vectrex off. Turn off computer. Go eat dinner, come back later, turn on Vectrex and use program uploaded earlier. Something more like that. It's not a significant difference in my life but it would make me feel better than having to turn on the Vectrex just to download a file from the Vectrex32. Now, yes, you could argue I should keep copies of everything on my computer anyways, but I'm only trying to impress the point that it would be preferred to do Flash operations at the very least without needing to power on the Vectrex.

It's moot because the idea of using USB independently from the Vectrex is being explored in the other case we're discussing right now. If usb access speed is an issue then for pure testing purposes a user adjustable frame buffer would probably be more than adequate to compensate, and 4 or 5 buffered frames would cause noticable lag indeed, but for testing purposes it would probably work out fine. And the lower latency the system is, the less lag would be present over the usb connection.
I'm assuming the Vectrex32 generates the machine code frame by frame and writes every frame to the dual port memory as a batch. In this case each batch could be redirected to USB and if the framerate is higher than 30 fps then that allows for a larger buffer without noticable effect. Especially if input (fed from the computer by USB) is always changed at a fixed rate, say 30 reads/second regardless of frame rate.

Ah, yes. I had forgotten about VIDE. I'll give it a go as it seems to be more than adequate and already implements some of the ideas I had like the graphical sprite generating and stuff.

With regard to the USB side of things, I would say that just because we might not have an idea why it would be useful now, doesn't mean the capability might not be useful in the future. As it stands, the ability to make small revisions to a program with the vectrex off and upload it to the flash and then not having to boot my computer next to the vectrex later when I want to run it would be nice. I admit this is a poor example but my point is who knows?

Even more interestingly, if it could auto-sense being plugged into a Vectrex, when it's standalone it could potentially funnel the machine code it generates through USB so that an emulator like the one in VIDE could actually work in conjunction with the Vectrex32. Now, I don't know whether USB 2.0 is fast enough to do that, but I'm pretty sure 480 Mb/s should be fast enough to do that.

That is obviously a fantasy at this point but I think it's doable... iff the Vectrex32 will even turn on from USB power of course. (Since VIDE is open source fiddling with the emulator can't be too hard. If you think this is feasible over USB I can look into that end).