The weather movement algorithm is pretty simple. Weather always originates from [27, 0], with a velocity of [+5/8, +4/8]. (+5/8 means it takes 8 tics to move 5 pixels.) On any given tic, there's a 1-in-10 chance of modifying the weather's velocity. If the algorithm decides to adjust the weather velocity, it picks a direction (N/S/E/W) and increments the velocity by 1/8 in that direction. If the weather moves off screen, it gets deactivated.
It turns out that the fixed starting location/velocity and the deactivate-on-exit behavior lead to a pretty stable distribution of "likely weather" areas. Furthermore, the right island seems to get more weather than the left island, on average, if my simulation is accurate.
Below is my "heat map". Every four bands in the color spectrum represent a factor of 10 difference in likelihood that pixel seeing weather. Two adjacent bands in the color map are approx a factor of 1.78 apart.
As you can see, the right island gets more rain on average than the left, with the buld of the benefit concentrated in the northwest corner of the island. The entire west coast of the right-hand island gets a pretty good bit of rain. The left island has a more concentrated set of raininess along its east coast. Overall, it's dryer.
I suspect this ends up making the right hand island easier to get started with, while both islands are agrarian and just getting established. In the long run, though, since all weather follows these trajectories (rain, tropical storms and hurricanes), the right island will also see more damaging weather events.
Now, I did experiment with the parameters a little bit, to see how sensitive the model is to that initial velocity. It turns out it's quite sensitive. Here's what it looks like with [+5/8, +5/8] as the initial velocity:
And here's what it looks like with [+4/8, +5/8]:
As you can see, slight changes in that initial velocity really shift the distribution around, even though most of the motion is a random walk. You have an extreme sensitivity to initial conditions, and I think it's reinforced by the fact weather deactivates when it reaches a screen boundary, so you can't average behavior over an unbounded amount of time.
I suspect this bit of code was intended to reduce the bias a little by shifting the weather entry point occasionally:
MVII #$0003, R0 ; 51EB \_ Random 0..2 JSR R5, X_RAND2 ; 51ED / TSTR R0 ; 51F0 \_ If non-zero, done spawning BNEQ L_51F8 ; 51F1 / weather INCR R2 ; 51F3 \ MVII #$001B, R1 ; 51F4 |_ Set X coord to 27. SWAP R1, 1 ; 51F6 | (But, it should already be 27!) MVO@ R1, R2 ; 51F7 /
But, as my disassembly comments indicate, this picks between a starting X coordinate of 27, or with 1-in-3 chance, selecting 27 instead. That is, no matter what, you're starting at [27, 0].
You can see my quick and dirty code here: http://spatula-city....weather-track.c