月別アーカイブ: 2018年9月

ミサイルコマンド

I/O 1981年3月号掲載。多部田氏の投稿作品の１つ。当時のFORM使いでプログラムもテクニカルな手法が多く使われている。ミサイルの軌跡が結構綺麗に描写できてるのには関心しました。ゲームもなかなかうまく移植されてます。

TANK DEFENDER

I/O 1981年8月号掲載。アーケードゲームのタンクバタリアンのアレンジ移植です。敵の動きが甘い感じがしますけど、それなり遊べる一本です。

ヤフオク被害

久々にヤフオクで馬鹿な出品者にあたってしまった。
今回はプレステソフトのカテゴリで、入札件数が１のまま終わりそうになると取り消す馬鹿に遭遇。こちらの落ち度はないし、取り消せる規定の「やむを得ぬ事情」も該当せず。一方的に取り消されるものだった。この出品以外は、プレミア価格での出品がいくつかあり、価格が気に入らなっかったのと思われます。それなら最落をつけるなり、価格を上げてだせばいいだけなのに。
ちなみに、その出品は平然と同じ内容で出てます。システム的に自分が悪くて取り消されるとか、出したけど商品にならないので取り消すならわかる。しかし、何事もなく取り消され、そのまま継続してるのを見るとむかつく。こういう金の亡者とは取引したくないから結果的に良かったと思うけど、世の中にのさばってるのがむかつく。こういう奴が率先して世の中から消えて欲しいよ。社会のごみでしかねーよ。

以前、落札後に連絡なしで一週間くらい放置され、入金後にさらに放置された出品者が居た。当然悪い評価を入れて早く送るように催促したら評価を戻さない限り送らないとか脅される始末。評価を戻して送ってもらい、品物を受け取ったら、当然悪い評価を入れると悪いをつけられたという。世の中にはこういう粗大ごみが存在するので本当にむかつく。何度も言うが、自分は手順を守り、期日を守り、何も悪いことはしていない。何なんだ？って思って当然でしょ？

そもそも問題なのは、欲しいと思ったゲームソフトが１本でも発売元が取り扱わないのなら、コピーフリーにして欲しいと思う。著作権・・・というか、ミッキーマウス保護法に縛られていつまでたってもパブリックドメインにならないのが問題だと思ってる。権利を主張するなら義務を果たしてからと思うのは自分だけか？権利ばかりが尊重される世の中ってどうよ？って思う。
発明の権利を保護するのは問題ないと思うが期間が長すぎると思うし、発売してすぐ扱いを止められ、レア化してしまったものはどうなの？と思う。

ネズミトリ・ゲーム

マイコンゲームの本２掲載。上の巣穴から出てくるネズミが降りてきたところを狙って倒すゲーム。床下のチーズを全部持っていかれるとアウト。ペスト菌も触れるとアウトです。キャラに味があっていい感じです。

VOSでHELLO WORLD

PL/Iで提供される表示機能にput命令がありますが、これらの機能はいろいろなルーチンを経由し、最終的にVOSネイティブなs$write_codeというルーチンに置き換えられます。結局ネイティブなルーチンになるのなら直接記述したほうがメモリ節約、スピードアップに繋がりますので、PL/I機能を使わない方が有効と思われます。最終的な仕様・ルールは現場に従うしかないのですが。

s$write_codeはシンプルなルーチンで、第一引数の文字列を出力するだけです。第二引数は出力時のエラーコードです。出力先は、標準出力にあたる端末画面です。start_processされた常駐プロセスでは、起動時に指定される.outファイルというシーケンシャルファイルへ出力されます。厳密にいうと、端末ではTERMINALという名前のポート（通常、ポート番号５番）、.outファイルはs$attach_portされたファイルのポートへ出力となります。まあ、出力はとどのつまりポートへの出力なのです。
出力される文字列は、asciiコードのテキストで、バイナリの数値は文字列変換しないとバイナリコードのまま出力されます。バイナリデータの出力は、別途用意されているs$dump、s$dump_portを使うと16進ダンプをテキスト出力することができます。（dump_recordコマンドで出力される形式と同じ。dump_record自体がs$dump_portを使ってると思われます。ちなみに、dump_recordsというコマンドは自分が考案したコマンドで、マルチファイル、ロッキングモードを自動で合わせるコマンド。会社の業務とは別に個人の時間で作ったものなので所有権・著作権を主張できるけど、十分報酬をもらったと思うから置いてきた。）

call s$write_code(‘Hello, world’, error_code);

このように記述すれば、端末画面にHello, worldと表示されると思います。
ちなみに、s$writeというエラーコードがないAPIもあります。こちらの方が手軽なのですが、エラーが発生したときにコアダンプしますので、あまりお勧めしません。エラーコードの戻り先がないので、エラー情報を出して停止シグナル処理されてしまうのです。エラーが出る典型例としては、X.25やダイヤルアップして接続された端末で出力がポーズなどで停止している時にバッファオーバーフローなどで出力できない場合に発生します。telnet上ではエラーを見たことがないですが、通信上何らかのエラーが発生した場合に起こりえます。まあ、個人的なツールなどでは考慮しなくてもいいと思いますけどね。それに、画面出力でエラーが出たからと言ってそのあとの処理をどうするかとか判断が難しいと思います。大抵は通信エラーで、通常では発生しませんし、メイン業務でのエラーの方が問題になると思いますので。なので、通常、エラーが戻されたら無視するのがいいかも。ある意味、s$writeを使って、エラー時はコアダンプする方がもしかしたら安全なのかもしれません。