Ways I have made the Vectrex32 crash so far

[Astrosynthesist]

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!

[Vectrex32]

I've reproduced these crashes.

1. When trying to go into lunar orbit, the Vectrex32 does not crash but the Vectrex does. If you have a terminal open, you can Ctrl+C the V32 and get a response. But clearly, the Vectrex is not happy about something. Probably, something in the drawing list is getting compiled to bad Vectrex BIOS command arguments.

2 & 3. If you have a terminal window up when adding tie fighters or moving them too far off screen, you'll see an error message: "At line 57, column 16: Not enough Dual Port RAM memory for all the Vectrex commands". So the BASIC program crashed, but V32 did not. If you enter the commands 'stop' and 'run', Demo3D runs again. However, I'm not sure the dual port RAM has been fully cleaned up.

- Bob

[Astrosynthesist]

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!

[Vectrex32]

The way to handle sprites leaving the screen is to either 1) have your BASIC code remove it from the drawing list (or disable it), or 2) set up clipping so that it gets clipped out and not drawn.

Option 1 is preferable since clipping takes a lot of time. But it's also more complicated to write the code for, and I didn't do that in the 3D demo. Ideally, clipping should only be used to handle the case where an object is partly within the field of view and partly outside. Clipping makes sure the part that's visible is drawn properly.

- Bob

[Astrosynthesist]

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.

[Vectrex32]

I'm wondering that too. I don't have an answer yet; I'll have to investigate.

- Bob

[Astrosynthesist]

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.

[Astrosynthesist]

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.

[Vectrex32]

I have found these bugs and fixed them for version 1.15.

- Bob