Is II counter? or do you want to count just 200 times? If so, please try II>199(or II>=200) instead of II>200. I guess that initial value in II is zero.

The former is better for me, but of course the decision is in your hands.

私も、条件式演算は頻繁に使います。昔のBASICではどういうわけか、IF分岐より条件式演算の方が高速と信じられていたので、それが習慣化されているんですよね。 例えば、カウントアップして1000でカウンターを止めたいときは、 C=C+(C<1000) または INC C,C<1000 カウントダウンして、0でカウンターを止めたいときは、 C=C-(C>0) または DEC C,C>0 なんてやります。 ところで、SmileBASICでは、条件「真」は「1」ですが、昔のパソコンのBASICでは、条件「真」は「-1」だったのです。（機種にもよるかも知れませんが、少なくともMSX BASICではそうでした） ゆえに、条件式演算は全て符号を逆にして考える必要があり、ちょっとだけややこしかったんですよね。

クリスマスソング、いいですねー。時期ですからね。 私が小学生の頃、クリスマスの日の給食には、骨付きもも肉とアイスケーキが出ましてね、それが超楽しみだったことを思い出します。 まぁそれはそれとして、残念ながら「あわてんぼうのサンタクロース」は、MMLを作った人がいたとしても、公開は難しいと思います。私は著作権法には疎いので、正確なところは分かりませんが、少なくとも権利者の存命中は、権利者の許諾なく楽曲を使用するのは不可だったと思います。この曲の作曲者（小林亜生さんでしたっけ？）はご存命（ですよね？）なので、公開NGでしょう。

プチコン３号はユーザーが使えるメモリーが潤沢にあるので、プログラムを短くできないからと言って悩む必要はないと思いますが、一方で、長かったプログラムを、努力や工夫の末に短くできると、テトリスがうまくハマるのに似たカタルシスが得られるんですよねー。

あら、みむさんすみません、かぶっちゃいました。

SPSCALEで指定する倍率がマイナスになっていませんか？ 倍率がマイナスだと、SPSCALEはout of range（範囲外）エラーになります。 倍率をMとしたとき、 SPSCALE 0,M*(M>=0),M*(M>=0) のようにして、マイナスの倍率が設定されないようにするのも手です。

I'm glad that it has been resolved by yourself. I cannot wait the release!

I'm sorry for lack of my previous explanations. As everyone has already said, GOTO and GOSUB are completely different and the GOSUB without RETURN wastes stacks.

I recommend you not to use deep nest subroutine call. A subroutine should be called after another subroutine has returned over. SmileBASIC's stack must not be so deep. Actually, I'm looking forward to the completion of this game. I'd like to support you as much as I could in order to fix the problem. Is it possible to show us line 349 of your code?

XSCREENにそんなハマリポイントがあるとは知りませんでした。自作ゲームでXSCREEN 4を使う機会がなかったもので・・・ （それどころか、下画面を滅多に使わない・・・）

From the above, The newer is not necessarily better then I have kept previous one in the same project.

The size of available area for scroll is nine times as large as previous one instead. (128x128 to 384x384) And new one is a little bit customizable. "MD7B" command has three arguments. 1st and 2nd arguments are coordinates on the scroll map (0 to 383) and 3rd argument is direction angle (0 to 359).

Choppiness and distortion will be clarified on the new algorithm, because it has only sixteen directions. (previous one had forty-eight directions) I'm looking for methods to reduce choppiness and distortion.

お菓子、果物、野菜、鮮魚など、世界中の子供たち垂涎のクリスマスプレゼントを、落っことさないようにキャッチする、あの名作ゲームの続編ですか。これは期待大ですね。 中心軸からズレすぎると、積み上げたプレゼントが崩れる（または倒れる）などすると、よりゲーム性が増すような気がします。高い位置に積むほど、中心軸からのズレ量が小さくてもすぐにバランスを崩すようにすると、より低い位置に横に広げて積むようになるけど、そうすると16tを避けにくくなるので、ゲームに戦略性が出てくると思います。ぜひ、ご一考を。

1÷1＝1 1÷0.1＝10 1÷0.01＝100 1÷0.001＝1000 ･･･というように、割る数をどんどん小さくしていくと、計算結果はどんどん大きくなっていきます。 じゃあ、0で割ったらどうなるのか？は、上の計算の延長で考えると、とてつもなく大きな値になりそうなのはわかりますよね？ つまり、計算結果が大きな値になり過ぎて、コンピューターで処理しきれないため、エラーになるのです。

I've made the new mode 7 demonstrator. Please try "HNZMD7B" in this project. BTW "HNZMD7" in the same project is previous one.

I'm sorry I'm closing this topic in order to introduce my new mode 7 algorithm which has evolved a little. See you later.

Please don't worry. I'm going to keep it on server at least for a month. And please don't expect too much.

Please check the following points. Don't you escape from a subroutine without "RETURN" after you have jumped to the subroutine with "GOSUB"? Isn't the nest of recursive function call too deep?