８０年代当時は、プログラミングと言えばＢＡＳＩＣの事を指すというくらい、名前にＶｉｓｕａｌ等の付かない “素の” ＢＡＳＩＣが流行っていました。主な８ビットパソコンに搭載されたＢＡＳＩＣでは、書いたプログラムをＥＸＥファイルやＣＯＭファイル等の実行ファイルに変換（コンパイル）せずに、そのまま使用します。まずＢＡＳＩＣ本体を立ち上げて （大抵の機種では、システムの入ったフロッピーを入れずに電源を入れれば立ち上がる）、保存しておいたプログラムを読み込んで走らせれば、そこで１行ずつコンピュータが理解できる機械語に翻訳して実行するのです（インタプリタ方式）。
　ＢＡＳＩＣ本体がＯＳとして起動している上でプログラムを実行するので、プログラムに間違いが有っても殆どフリーズしたりせずにエラーを出して中断しますし、プログラムは書いたときのままですから、その場で簡単に修正も改造もできます。その半面、常に翻訳しながら実行するので動作速度は遅めです。

さて、Ｚ８０をはじめとする８０年代の８ビットＣＰＵが一度に使えるメモリは６４キロバイト （６５５３６バイト） です。それ以上メモリを載せていても、８ビットＣＰＵは一度に６４キロしか把握できないので、スロット切り替えの（例えば１６ｋずつメモリを入れ替えて使う）ような機械的な仕組みが必要です。ＢＡＳＩＣを使う場合はその６４ｋの中にＢＡＳＩＣソフト本体が入るので、機種によって違いますが、プログラムに使えるのは４０〜２０ｋ程度になります （いわゆる裏ＲＡＭを入れず、６４ｋ内で）。
　また、ＰＣ−８８０１ｍｋＩＩＳＲやＭＳＸ２など後期の８ビット機になるほど機能が増える分、大きくて重い（遅い）ＢＡＳＩＣが搭載されました（注１）。ちょうど、Ｗｉｎｄｏｗｓのバージョンが上がるほど高機能化して、大きく重くなるのと同じ理屈です。例えばＭＳＸでは、８ビット機用『Ｍｉｃｒｏｓｏｆｔ Ｂｕｓｉｎｅｓｓ ＢＡＳＩＣ』の当時の最新版 （Ｖｅｒ．３（Ｍｉｃｒｏｓｏｆｔ社の標準ＢＡＳＩＣ第４．５版）に、ＭＳＸ仕様の改造を加えたもの） を搭載している為、 「内部十進演算・有効数字１４桁（倍精度８バイト）」 という、８ビット機には重い設定が標準の状態となっています（注２）。

というわけで、メモリが限られスピードの遅い８ビット機搭載ＢＡＳＩＣ用プログラム必須事項は

となります。ＢＡＳＩＣプログラミングの教本で説かれるような、見た目が綺麗で分かりやすくて、構造化されていて・・・というプログラムは、メモリやスピードの都合で１６ビット機以上でないと、（当時のパソコンに対する要求レベルに対してすら） あまり実用的ではありませんでした。

なお、Ｃ言語等と違って（Ｖｉｓｕａｌ等の付かない素の）「ＢＡＳＩＣは構造化できない」 とか 「オブジェクト指向にならない」 と一般に思われているようですが、それは多くのパソコンに採用された 『マイクロソフトＢＡＳＩＣ』 系がそうなのであって、ＡＮＳＩ規格に沿った 『ＴｒｕｅＢＡＳＩＣ』（注３）や、ＪＩＳに沿った 『十進ＢＡＳＩＣ』（注４）は、初めからＡＮＳＩのＣ言語同等の構造化機能を備えています。
　『マイクロソフトＢＡＳＩＣ』 は、プログラミングに於ける根本的かつ重要な一部の機能を端折って、７０年代後半の８ビットパソコン上でも、インタプリタ方式で走るように軽量化し、大手メーカー各社に採用されて普及しましたが、それを引きずったままバージョンアップしていったため、ＢＡＳＩＣという言語に汚名を着せてしまったのです。

Ｎ８８−ＢＡＳＩＣ系やＭＳＸＢＡＳＩＣといった、マイクロソフト系を祖とする “素の” ＢＡＳＩＣは、変数が全てグローバルであり、且つ、制御関連命令で引数が使えない （つまり、サブルーチンでも関数でも、すべてグローバル変数で受け渡しする） のが、実際、一番の問題点だったりします （＝オブジェクト化不可能？）。
　『ＴｒｕｅＢＡＳＩＣ』『十進ＢＡＳＩＣ』等、ちゃんと規格に沿った「素の」ＢＡＳＩＣでは、この問題は有りません。

１９８５年にマイクロソフトが発売し、アメリカではかなり使用された『ＱＵＩＣＫ ＢＡＳＩＣ』は、９１年の『Ｖｉｓｕａｌ ＢＡＳＩＣ』に繋がるものですが、「Ｃ言語をＢＡＳＩＣっぽくしたという方が適切」（マイコンＢＡＳＩＣマガジン１９９２年１月号付録より） という感じです。当時のユーザーを惹きつけるためにＢＡＳＩＣを名乗りましたが、ＢＡＳＩＣの規格を全く無視しているので、ＢＡＳＩＣ一族か？というと、ちょっと違う気がします。「８５年度マイクロソフト製の新言語、内緒だけど当時流行のＩＤＥ付Ｃ言語のパクリ仕様で、コマンド名がＢＡＳＩＣ風味」 という感じで、血の繋がってない遠縁の者くらいでしょう。（はぁ？）
　ビルゲイツ氏は自分を世に出したＢＡＳＩＣ（という名？）にとてもこだわりが有って、９１年の『Ｖｉｓｕａｌ ＢＡＳＩＣ』発売の際には「これはＢＡＳＩＣじゃないから名前を変えましょう」 という案を蹴ったそうです。

ページのＴＯＰへもどる

ファミコン用のファミリーベーシックは、用意された１６種類のキャラ（スプライト）、８×８ドットの１０４種類の背景パーツ、カタカナとアルファベットと数字、を組み合わせてゲーム （とは限らないけれど、２バイト整数型しか数値を扱えないし、文字列は最大３１文字だし、ゲーム以外の用途には・・・） を作る、機能限定なＢＡＳＩＣシステムです。ＢＡＳＩＣ本体の名称は 『ＮＳ−ＨｕＢＡＳＩＣ』 で、ハドソンがパソコン用に作った 『ＨｕＢＡＳＩＣ』 の改造サブセットです。名称の頭のＮＳは、任天堂とシャープの頭文字らしいです。でも、別売りのデータレコーダは、松下製品の一つと同じ形状 （で機能省略？） の色・ロゴ違いだったと記憶しています（？）。

ファミリーベーシックは、カセット内蔵のＳＲＡＭにメモリの内容（打ち込んだＢＡＳＩＣプログラム部と背景の並べ方）を１回分保存できるが、上書きすれば当然前回の記憶は消えるし、電源を入れたまま標準品より２倍の高さが有るカセットの上部前面に有るスイッチを操作して保存処理をするため、本体との接触不良でデータが飛んでしまう事故が頻繁に起こる。そのためマトモに使うには、データレコーダが必須であった。
　別の所にも書いたが、ファミコン＋ファミベー＋レコーダーを買うくらいなら、ＭＳＸを買った方がずっと実用的だったと、超暇人ＭＳＸとしては思う。ゲームで遊ぶならファミコン、プログラミングで遊ぶならＭＳＸである

ファミリーベーシックでは、プロが作った背景パーツやキャラを組み合わせてゲームを作るので、パッと見にはＭＳＸ１のＢＡＳＩＣで作ったゲームより良さそうに見える事も多いのですが、ファミコン最大の武器である 「背景スクロール」 は不可能ですし、プログラムに使えるメモリーが初代 （ＶＥＲ１．０、ＶＥＲ２．０、ＶＥＲ２．１） は２ｋ弱、新型 （ＶＥＲ．３．０） は４ｋと超少なく、効率の良いメモリー使用は正に必須で、かなり工夫しても、とても単純なゲームしか作れません （単純なゲームがつまらないとは限りませんが）。

　そのファミリーベーシック用の 『オリジナルゲーム集２５』（ナツメ社） という本によると

が、良いプログラミング方法だそうです （激怒するプログラマーが居そう(^^;)）。これを私なりに解説すると

という感じです。このほかに私の知る高速化は 「複雑な数式をバラして単純な式の連続として書く事」 です。ただしその分メモリは消費します。また、ほかの私の知るメモリ効率化は 「同じ変数（名）を色々な所で使い回しにする」 「同じ作業をする部分をまとめてサブルーチンにしてしまう事を徹底する」 です。ただしサブルーチンを多用すれば速度は遅くなります。メモリ使用量を減らす事と高速化は、両立することも、トレードオフ関係となることもあります。
　ああ、まだありました。インタプリタが解析する際には１文字ずつ順にＡ、Ｂ、・・・と比較していくので、変数名をＡにすると一番速いのです。Ｘ、Ｙ、Ｚより、Ａ、Ｂ、Ｃが速いのです。

参考
　下左はファミリーベーシックの『ＢＧグラフィック』モード ＝ マップデータを入れる画面。キー操作で下部に順繰りに表示されるパーツを見て探して、同じくキー操作で座標を表示して入れていくらしい。右はファミリーベーシックの全背景パーツ

ページのＴＯＰへもどる

私の経験から言うと、８０年代８ビット機に搭載のＢＡＳＩＣでは、上記の高速化Ａ〜Ｅと複雑な式のバラしを全て行えば、１．５倍程度速くなる事があります。上記メモリ使用の効率化１〜３とサブルーチン徹底化や変数の使い回しを全て行えば、２〜３割サイズが小さくなる事があります。その代わりこれらを行えば、可読性の低いとてもメンテナンスのし辛いプログラムになります（注４）。つまり、８ビット機のＢＡＳＩＣでは、少しでもメモリの使用量を減らす／高速化するための苦肉の策として上記１〜３やＡ〜Ｅの様な方法をとりますが、難読化する副作用があるわけです。
　私の拙作 『マジンナースＢ』 のＢＡＳＩＣ部分を覗いた方は 「なんと読み辛い分かり辛いプログラムだ！」 と思われたかもしれませんが、別にパクられないように難読化したワケではなく （パクる人も居ないでしょうし(^^;)）、作っていく内にどうしてもメモリが足りなくなって、メモリの効率化をせっせと行った結果です。（ゲームの途中でディスクを読まないようにしたいと、なんとなく思ったので、詰めるだけ詰めたのです。）

では、そういう副作用の少ない 「メモリ使用の効率化」 や 「実効速度を高速化」 する手段はあるでしょうか？　コンピュータサイエンスの本には 「アルゴリズムを見直せば１００倍も速くなる、サイズも３分の１になる」 みたいな話がよく書いてあります。ですが自分で自分のプログラムを見直して、より効率的なアルゴリズムを編み出すというのは、根気と時間と数学っぽいセンスとオツム（と運）が必要で、なかなか大変なことなのです（いや、私には）。本来そうあるべきなのでしょうが。

ページのＴＯＰへもどる

このページは、1024×768画面に合わせて作りました。ちゃんと見えなかったらスミマセン