JavaScriptを有効にすると、ここにメニューを表示します。
2019

ysflight.com

Please enable JavaScript to display links.

YS FLIGHT SIMULATOR Version 20181124

YSFLIGHT.COM内のプログラムはすべてがオープンソースでは無いですが、オープンなものについては、以下のURLからダウンロードできます。

https://github.com/captainys/public

YSFLIGHT.COM内からダウンロードできるプログラムを実行しようとしたとき、コード署名されていないプログラムである、とする警告が出るかもしれません。コード署名は本来セキュリティを向上する目的で発明されたものですが、今は僕のような個人プログラマーを駆逐する目的に使われています。以前は、コード署名は法外に値段が高いだけでしたが、今はいくらお金を払っても個人には発行されなくなりました。プログラムを自由に公開する権利の明らかな侵害ですが、僕には何もできません。できることと言ったらここに何が起きてるのか書くぐらいです。別に趣味プログラムを公開できなくなったとしても、困りはしないんですが、なんともつまらない世の中です。

2019/06/12

YS FLIGHT SIMULATOR 20周年!

10周年記念からさらに10年が経過した。YSFLIGHTはもともと博士候補試験の勉強中の息抜きのために始めたプロジェクトだった。最近はスマホやゲーム機で優れたフライトゲームが多くあるから最盛期ほど盛り上がってないかもしれないけど、一応ゆっくりだけど今でも開発は続けている。

FM TOWNSを使ってた頃は3Dゲームをいくつも作って1000本とかいうオーダーのダウンロードがあった。当時フリーのゲームソフトで1000回ダウンロードされるというのはすごいことだった。だけどYS FLIGHT SIMULATORは世界中からダウンロードされて、ダウンロードカウントだけ見たら100万回のオーダーを超えている。ただ、同じ人が何度もダウンロードすることもあると思うんで、100万人かどうかはわからないんだけど。

アップロードしてみたらユーザが作る機体やマップのクオリティの高いことに衝撃を受け続けた20年でもあった。YSFLIGHTを盛り上げてくれているユーザの皆さんには非常に感謝しているので、ひきつづきYSFLIGHTをよろしくお願いします。心苦しいんだけど機体の作成とかマップのデータ構造に関する質問はほとんど答える時間が取れない。けど既にオンラインでものすごく詳細な解析情報があるから多分僕に効くよりそっちの方が速いと思う。

せっかくだから20周年記念で何か特別なことをしたいのだが、例えば手をつけたままできあがってない新機能をひとつでもふたつでも完成させるというのも手なんだけど、途中で止まってるのはやっぱり理由がある。大体メジャーな理由としては、やってみたら案外難しかった、後方互換性が維持できなくなる、難しくはないんだけど書かなきゃいけない分量が多すぎる、とかいうパターンが多い。少なくとも20周年記念機体データとか作ろうかな。

僕は、最近のソフトウェア開発のトレンドについて危機感を持っている。ソフトウェアが消耗品のように扱われてるのは正しくない。ソフトウェア・アズ・サービスって言いだした奴を絶対許さない。悪いけどソフトウェアはサービスではない。ソフトウェアは製品であると同時に芸術作品としての側面も持っている。傑作は将来まで保存されるべきであって、ティッシュペーパーのように使い捨てられるべきではない。安定したプログラムを書くためには、コードを再利用して、多くの入力を与えて頑強性を高めていくべきだ。そして、プログラムが安定してくると徐々に更新は不必要になってくる。更新が無いのはプログラムが捨てられたからではなくそのプログラムの目的を達成しつつあるからであるべきだ。コンピュータ界には数多くの素晴らしい成長があった。だけど同時に誤った考え方も広がっている。

YSFLIGHTは傑作というほどのものではないかもしれない。だけど僕はYSFLIGHTを誰でもいつでも戻ってこれるプログラムにしたい。誰かが今日YSFLIGHTをプレイするのをやめるかもしれない。だけど、何年かしてその人がまた久しぶりにYSFLIGHTで飛んでみようと思ったとき、YSFLIGHTをダウンロードして飛び上がって簡単にトラフィックパターンを回れるように維持しておきたい。しばらく離れていた人も、「ああ、このプログラムまだあるんだ」と思って久しぶりにダウンロードしてまたちょっと使ってもらえるようなソフトウェアを目指して引き続きメンテナンスしていこうと思ってる。

2019/05/19

富士通純正品互換FM-7用RS232Cカード38400bps駆動の改造

このあいだ製作に成功したFM-7用純正品互換RS232Cカードは、実は38400bpsまで行けることが判明した。

富士通純正品は19200bpsが最大ということになっている。純正品は82年ごろ製造のIntel 8251Aチップを使っている。多分、8251Aは本当に19200bpsが最大なのだと思う。

これに対してOKIの互換チップ82C51Aは38400bpsまで保証している。また、Intel製でも手元にある82C51Aチップは90年製造で富士通純正品のRS232Cカードが生産されてから8年も経過しているようだ。これなら実はIntel製P82C51Aも38400bps行けるのではないかと思って実験してみた。

(続きを読む

2019/05/13

富士通FM-7用FM音源カードの再生産に成功!


 

2019/05/06

ナイアガラに飛ぶはずがただの計器飛行の訓練になった

なお、上空で真空パックする作戦は失敗したので、あきらめて真空パック機を買ってきた。上空で済むなら$80節約できると思ったのにな。(ちなみに、飛行機レンタルは1時間で$150ぐらい。飛行機操縦する理由を探してただけだろうって言われるとその通りなんだけど。)

この週末、もうすぐ日本に帰国される訪問研究員の人と我が妻の友達とその息子さんを乗せてナイアガラの滝に飛ぶはずだった。離陸地のビーバーの天気は曇り。しかし、最近Garmin 1000搭載のセスナに乗るようになって、雲が500ftもあればIFRアプローチで降りる自信がある。最初G1000は難しいと思っていたけど慣れてしまったらなんとアプローチの撃ちやすいことか。最近、G1000のセスナ以外が空いていないこともあって気が付いたら最近G1000しか操縦してない。

ナイアガラ付近の天候は快晴。風も穏やかでまったく着陸に支障はない。

ヤングスタウン、アクロン、はやや雲が低いものの離陸時刻までには上がってくるとの予報。万が一ダイバートが必要になった場合もGPSアプローチで降ろす自信があった。

(続きを読む)

2019/05/03

死の淵から蘇るFM-7

RS232Cカードは成功したものの、自分はハードウェアの素人であることに変わりはない。FM-7に煙を吹かせてしまった場合に備えて、FM音源カードの再生産を前に、FM-7を一台増強することにした。

ヤフオクで5000円ぐらいで動作品と称するFM-7を落札した。それが届いた。よほど几帳面な人が使っていたのだろう。綺麗にGRAPHキーのシールが貼ってあって、プラスチックの黄ばみも無い。ミゾにホコリが貯まっていさえしない。綺麗なハードだった。これが動かないはずが無いだろう、と、思いながら電源を投入してみたのだが状況が良くない。

(続きを読む)


 

2019/04/18

セスナ172はレトロPC用ゲームを救えるか?(失敗)

これ、実際トライしたのは去年の年末のことだけど。

YSFLIGHT.COMのトップを見てくれてる人だったら、僕が趣味で富士通製レトロPC、FM-7シリーズとFM TOWNSシリーズの動態保存に取り組んでるのは知ってると思う。もともと数枚だけなぜかずっと保存してあったフロッピーディスクが手元にあったけど、最近アメリカからでもヤフオクから買えるようになったんで、結構レトロゲームを落としている。

最近そういうゲームの復刻版が出ていたり、メジャーなタイトルだと少し検索すれば著作権的にどうかと思うけどディスクイメージがダウンロードできるものもある。ただ、復刻版にしても著作権者に無断でアップロードされてるイメージにしても、元のソフトウェアを完全に再現していない可能性が高い。とくに、コピープロテクトは解除済みである可能性が高い。僕としては当時のコピープロテクトも貴重な技術資料だと思うので、できればコピープロテクトを含めて昔のタイトル、せめて思い入れのあったタイトルだけでも保存しておきたいと思っている。できればそのうちコンピュータの歴史を保存してるようなところで恒久的に保存してもらえるといいんだけど。日本では、ゲーム保存協会 (あ、今年の分の年会費+募金しなきゃ)ががんばってるけど、こういう資料は各地に分散して多数保存するのがいいので、アメリカにも保存の拠点ができるといいとか思っている。

(続きを読む)

2019/04/16

空からお花見

ピッツバーグでは日本人・日系人の有志がNorth Parkに桜の植樹を続けている。今年で10周年とのことで、先々週セレモニーがあった。そのときはまだ桜が咲いていなかったのだが、ぼちぼち咲いたろうというタイミングで空から花見に行ってきた。四季の移り変わりを空から見ることができるのはパイロットの特権と言える。(続きを読む)

富士通レトロPC:

FM-7用FM音源カード、リバースエンジニアリング&再生産プロジェクト開始!

FM-7用Delphis勝手にジョイスティック対応化パッチ

FM-7用Emergency勝手にジョイスティック対応パッチ

2019/04/05

富士通レトロPC: 大技!RS232C経由でFM-7実機でディスク版ソフトを起動!

時には昔の実機を使おう

まさか成功すると思わなかったのが成功した。始めてから起動するとこまでたった4日でできると思わなかった。その後サーバーのパラメータとか追加するのでさらに4日ぐらいかかったけど。(続きを読む)

富士通レトロPC: FM77AVキーボードエミュレータも更新

なお、FM77AVキーボードエミュレータがコンソール無しモードでコンパイルするとなぜか大半のキーを送り損ねるという問題が発生したので、コンソール付きモードでコンパイルしなおしたやつをアップロードした。

BONDIC

この間買ってきて既に首振りフラワー2個の修理に成功。多分接点を絶縁する目的とかにも使えると思う。

AA

ボーイング737MAX-800

これまでに聞いた話でいくつか気になった点。

という話を聞いたけど、自動操縦にフィードするのに迎え角センサーが二個しかなかったのか?初めてコンピュータコントロールを本格的に導入してデジタルフライバイワイヤを実現したのはF-16だったけどコンピュータを3台搭載していた。そして3台それぞれに対気速度をフィードするセンサーがあった。AOAはどうだったか知らんけど。一台が故障しても多数決で出力を決めることで自動操縦の信頼性を高めていた。だけど、737Maxではそんな大事なMCASに入力を与えるセンサーが2個?パイロットが見るための情報だったらどっちが間違ってるか判断できるからいいんだけど。我々は計器をクロスチェックしてどの計器が壊れてるか識別するように訓練受けてるんで。2個だと片方ダメになったときどっちを信用すればいいかわからないので、自動操縦としては冗長性は無いに等しい。このデザインはどうかと思うなあ。ますますボーイングらしくない。

というか、左右の入力が違ったら自動操縦は自主的に切れるべきかもね。

今、プログラミングのトレンドで非常に危惧していることがある。いい加減なプログラムを公開してあとからアップデートすればいいという風潮がプログラミング界をむしばんでる。断言するけど誤ったやりかたと言える。いい加減なプログラムを公開して、しばらくユーザを実験台にして不具合報告が上がってきたら対応するようなアプローチは、一般ユーザが使うプログラムでもするべきではない。風潮というのは恐ろしい。こんな誤った考え方が航空機メーカーのソフトウェア開発部隊にまで広がっているのだとしたらこの先次々に墜落事故が起こる鴨しれんね。そうでなくてこの機種だけ、たまたまだったらいいんだけど。

2019/03/12

ボーイングらしからぬ事故?

昨日事故が起きたばかりだからエチオピア航空の737-300MAXの事故原因がライオン航空の事故原因と同じものであるかどうか、まだ調査を待たなくてはならないけれど、ただ、仮に違う事故原因だったとしても背景にはこれまでのボーイングらしくない設計思想があるかもしれない。

インドネシアのライオン航空事故で思い出したのは、1994年にあった名古屋空港での中華航空のエアバス300-600Rの事故だった。あの事故の原因は明らかなエアバスによる設計ミスだった。ゴーアラウンドモードで、自動操縦はピッチトリムをコントロールするが、パイロットはエレベータをコントロールできてしまった。1994年4月26日、無意識にゴーアラウンドレバーを引いてしまったパイロットは、自動操縦が機首を上げたので、着陸を続行するために操縦輪を押して機首を下げようとした。ところが、エレベータの機首下げ入力のため機首を思うように上げることができない自動操縦はエレベータトリムをどんどん機首上げに向けてしまった。ある時点でパイロットの入力では対応できなくなり、エアバスはパイロットがどれほど操縦輪を押しても機首を下げられなくなった。で、ストールして墜落。パイロットの入力と自動操縦の入力が混ざる状態に入る場合があるというのが事故原因だった。

一方、設計ミスと思われたくないエアバスは先手を打ってパイロットエラーであると発表した。エアバスは一貫して、パイロットはミスを犯す可能性があるから、緊急時は自動操縦の判断を優先するべきである。従ってこの事故はエアバスの設計に起因するものではない、と主張した。

工学博士号持ってなくても、エアバスの主張がおかしいことは理解できる。緊急時にパイロットの判断を優先するか、自動操縦の判断を優先するか、これには議論の余地がある。自動操縦もパイロットもどちらもミスする可能性があるから、最後はどっちかに賭けるしかない。我々は事故を完全にゼロにはできない。できるのは事故の発生確率をゼロに近づけることだけだ。だから、エアバスは自動操縦が正しい方に賭けた、というのであれば、設計ミスとまでは言えない。

まあ、仮にエアバスが正しいとしよう。だとしても、だったらパイロットからの入力を混ぜたらダメだろ。パイロットの操縦ミスによる事故を防止するのが目的であればパイロットからの入力は遮断するべきで、逆にコンピュータの動作エラーによる事故を防止したいならパイロットからの入力があった場合は自動操縦を遮断するべきであった。だが、ゴーアラウンドモードでは混ぜてしまった。だから、明らかなエアバスの設計ミスだった。

なぜか、事故調とかもその宣伝を受け入れてパイロットによる操作ミスで訓練を徹底するのが今後の事故防止に必要という結論を出してたんじゃなかったかな。ちょっとちょっと、Ph.D Mechanical Engineeringとして言わせてもらうとただの設計ミスだから。エアバスの責任がかなり高いから。コンコルドの飛行を継続しておけばよかったものを。(時系列無視)

多分事項調査委員の誰かが金持ちになったんだと思う。そしてエアバスは知らないところでこっそり改修を加えたかなんかしたのかもしれない。この事故後同様の事故は起きていない。

←アメリカAmazonからなんか買うときはよかったらこのAffiliate Link使ってください。

この名古屋空港の事故に対して、ボーイングの反応はこうだった。ボーイングは緊急時はパイロットを信用する。ボーイングの機体はパイロットからの強い機首下げ入力があったのであれば自動操縦を解除するようになっているから名古屋空港中華航空機事故と同様の事故はボーイングの機体では発生しない。

はずだった。

実際学会とかでボーイングの人と何度か話したことがあった。ボーイングはパイロットが大好きだから緊急時にはパイロットを信頼する。パイロットはエアバスがやってるみたいなサイドスティックが嫌いだからやっぱり操縦輪が正面にあった方がいい。ボーイングの機体は操縦輪に強い力が加わると自動操縦は解除されて機体はパイロットの入力に従うようになる。ボーイングは常にパイロット中心で考えてる。とかいう話を聞いた。

だけどライオン航空の事故が起きた。そのときのボーイングの反応は、まるで中華航空機事故のときのエアバスとそっくりだった。パイロットの訓練を徹底するように。いや、違う。ただし、これは設計のミスとまでは言い切れない。緊急時はパイロットがエラーを起こすかもしれないから一貫して自動操縦を優先するというのであれば、それ自体は正しいのだが、問題は制御コンピュータが間違っている場合もあるということだ。

プログラマーとして言わせてもらうと、プログラマーもミスを犯すんで、自動操縦システムのプログラムにエラーがある可能性は十分高くて、したがって自動操縦を信用すれば大丈夫とはぜんぜん言い切れない。人間だと緊急時に対応して違った対応を取ることもできるが、自動操縦のシステムが間違ってたら地上に降りてくるまで更新できない。いや、上空にワイヤレスで更新プログラム送って更新するって怖くてできんでしょ。機械学習?機体が遭遇した未知の飛行状態が、既知の飛行状態のインターポレーションであれば割とよく対応すると思うけど、エクストラポレーションだったらどんな挙動するかわからん。

だから僕は昔のボーイングの設計思想の方が正しいと思ってた。

ところが、このライオン航空の事故では、パイロットが必死に操縦輪を引いて機首上げ操作をしているにも関わらず、自動操縦が強行に機種を下げた。飛行機は、自動操縦から機種を下げろと言われ、パイロットからは機首を上げろと言われた。実はストール寸前などではなくて自動操縦が間違ってるのかもしれない。でも、パイロットがストール寸前なのに間違って機首を上げようとしているのかもしれない。航空事故史にはストール寸前の飛行機の機首をさらに引き起こそうとして落ちた事故は数多い。飛行機は自動操縦を信じた。というか、信じるように作られていた。結果的に自動操縦の根拠となったストール寸前の状態では無くてパイロットが間違っていた。運が悪かった。

だから、必ずしもこれは設計ミスではない。自動操縦とパイロット。どっちもエラーを起こす。どっちを信用するのかは、デザインフィロソフィによって違うので、パイロットより自動操縦が信用できると思ったなら、そういう設計は「ミス」とまでは言えない。僕は嫌いだけど。

かつてのボーイングのパイロット中心のデザインンフィロソフィであればライオン航空の事故は起きなかったのではないかと思う。ボーイングが、自動操縦優先、パイロット軽視に変化しているのだったら、僕は残念な気がする。

2019/03/03

YSFLIGHT Demo for Androidをリリースしようと思ったが

YSFLIGHTカーネルをAndroidで走らせることに成功したのは数か月前だから、試しにデモだけバージョンでも.APKファイルをリリースしようと思った。

Android Studioの新しいバージョンをインストールしたら、予想通り前のバージョン用に作ったプロジェクトはコンパイルできなくなっていた。旧バージョンで作ったプロジェクトをビルドするユニットテストもしてないんだろうな。まるで大学院生のような開発の仕方だ。

最近、バージョンを頻繁に上げるのが良いことであるという風潮があるけど、超新星爆発寸前の赤色巨星並みの巨大な間違いで、頻繁に何か変えなくちゃならないのは何かが悪いからだ。機能が洗練されてきて当初の目的の達成に近づいたプログラムは安定するからアップデートする必要が無い。したがって、頻繁にアップデートを繰り返す上に何も安定しないAndroid Studioはゴミと言える。

Android Studioだけじゃないんだよね。もう「アップデートするな!」とメガホン持って叫びたい。十分な時間をかけて安定して頻繁なアップデートを必要としないコードを書くべきだ。最近の、作りかけでリリースして頻繁なアップデートでごまかす風潮は有害と言える。今の無茶苦茶な開発の仕方は僕が習ってきたやり方ではない。僕の考え方が時代遅れなのかもしれないけれど、いい加減なソフトウェアをリリースすることが流行なんだったら時代遅れで結構だ。

エラーメッセージを検索して解決が見つかったのでビルドはできるようになった。Googleには迅速にエラーメッセージから解決を探せるようにするのではなく、もともとこの問題を作らないでほしかった。

が、デバッグモードだから異常に遅い。リリース版APKファイルを作ってみたら -unsigned.apk というのができてしまって実行時にサインされてないと文句を言う。またCode Signatureだよ。とにかく、セキュリティの名のもとに個人開発者にプログラムを書かせなくするための仕組みだからな。

一応、開発用シグネチャを作ってコンパイルすることができたのだが、試してみようとすると何度やっても -unsigned.apk を実行しようとする。強制的に -unsigned.apk を削除してみたが、ファイルが見つからないと言い出す。同じディレクトリにお前がたった今ビルドした ysflight_release.apk があるのがなぜ見えない?

というところで今日は11時過ぎてしまったので断念。後日再度トライする。

2019/03/02

ナイト・ソロを追加。飛んだのは既に一か月前だけど。

久しぶりに単独の夜間飛行に出た。ログブックによると2013年の11月30日以来の夜間単独だったようだ。

本当は我が妻を乗せて飛ぶはずだったのだが、我が妻は風邪でダウン。フライトをキャンセルするかとも思ったのだが、我が妻の風邪はほぼ回復してきたようだったので、とりあえず単独で飛んできた。

自家用操縦士免許を取ったら夜間飛行に出てもいいことになっている。だけど本当にナイトに自信がついたのは計器飛行証明を取得してからだった。夜間飛行はかなり計器飛行に近い。地平線見えないし。だけど、今だったら計器だけに頼って夜でも飛べる自信がある。

(続きを読む)


2019/02/23

Sanyoのデータレコーダを修理しようとするが失敗

去年駿河屋からFM-7用Plazma Lineを買ったとき、リストアするためにヤフオクでSanyoのデータレコーダMR33DRを落とした。そのときの記述によると、データレコーダはモーターが回るもののそれ以上の機能は確認できなかった、とのことだったのだが、データレコーダが故障すると言えば大体モーター回りのようなので、モーターが回るなら大丈夫だろうと思って手に入れて、例によってBuyee.jpによって太平洋を越えた。

で、届いて試したところ、確かにモーターは回る。だが、音が出ない。スピーカーからもイヤフォンジャックからも音が出ない。予想外であった。仕方ないのでPlazma Lineは、WAV録音した波形にフィルターをかけてデータを抽出して再現に成功したのだが、もしもデータレコーダが使えたならもっと楽だっただろうになあ、と、思ったままその後何本も同じプログラムでテープ版ソフトの抽出と実行に成功してきた。

しかし、ここ最近RS232Cカードを作ってみたりハードウェアをいじくったり結構やってきたので、今なら修理できるかもしれん!と、思って再挑戦してみた。スピーカーもイヤフォンジャックも音が出ないということは、テープの磁気ヘッドに近いところに問題があるに違いない。この手のハードウェアでモーターの次に壊れそうな部品と言ったら、稼働部品であるボリュームレバーの半固定抵抗ではないか、と、見ていた。実は、今のホンダフィットに乗る前、日産セントラ(日本でいうところのサニーらしい)に乗っていたとき、空調ファンが全力だと回るけど、その手前の強度1〜4だと回らないという現象が起きたことがあった。まさに半固定抵抗が電気を通さなくなってしまって、抵抗をバイパスする全力モードだけ回っていた。

(続きを読む)

2019/02/15

エアバス380生産中止なのか。そんなもん作らずにコンコルド近代化改修するべきだったな。コンコルドを無理やり引退させたバチが当たったんじゃ。

渋々LinuxのVMをUbuntu 16にアップデートしようとしたらデスクトップがぶっ壊れた。アイコンもメニューも出なくなりCtrl+Alt+TでTerminalも開かなくなった。コンソールモードに入って設定をいじって直せるほどLinuxは詳しくない。バックアップのUbuntu 14に戻してもいいんだけど、Ubuntu 16にしようと思ったら全消し再インストールするしかなさそうだ。定期的にこの余計な手間が発生するのはなんとかならんもんなんだろうか。

Linuxは相変わらず脆い。いつまで経っても脆い。更新に失敗して簡単に壊れるんだから、そもそもOSを更新してほしくない。セキュリティの更新はしてほしいけど、メジャーバージョンアップはしてほしくないんだよね。誰かOSの新バージョンを楽しみにしてる人がいるんだろうか?僕はそういう人を一人も知らない。OSのメジャーバージョンアップは、ときどき不必要にドライバモデルを変えてまったく問題なく動作しているハードウェアを使えなくするわ、頼みもしないカーネルの更新でソフトウェアを殺すわ、何もいいことが無い。ハードウェアに革新があったならそれもやむを得ないと思うけど、ここ数年なんかあったっけ?基本的に同じハードが速くなってるだけだと思うんだけど。OSのメジャーバージョンアップは僕にしてみりゃただの嫌がらせだ。ユーザに嫌がらせを続けてたらそのうち誰も使わなくなる。

2019/02/06

FM-7/77実機でRS232CからT77形式のテープ版ソフトを読み込んで実行(セーブもできる)ユーティリティ更新。オプションで8バイト先読みバッファを使ってFM-7/77実機にテープ版ソフトを5倍速ぐらいで送り込んで実行できるようになった。まさにテクノロジーの無駄遣い。

2019/01/29

FM-7/77実機でRS232CからT77形式のテープ版ソフトを読み込んで実行(セーブもできる)ユーティリティ公開。

2019/01/24

FM-7/77シリーズ用純正品互換RS232Cカード製作プロジェクト成功

案外あっさり成功。実機FM-7で動作も確認できた。

実は、カードの制作に成功だけでなく、BIOSをオーバーライドしてRS232C経由でテープ版ソフトを起動することにも成功した。BIOSオーバーライドコード、サーバーコードは間もなくYSFLIGHT.COMで公開予定。

 

2019/01/15

YSFLIGHT SIMULATOR 20181124バージョン公開!

お待たせしました!

富士通FM-7/77用RS232C経由ディスクイメージ書き戻しユーティリティ

なお、今日FM77AV40で動作を確認した。

FM77AV/AV20/AV40実機用赤外線ワイヤレスキーボードエミュレータ更新

実機でF-BASICのプログラムをタイプさせてみたら一行入力するたびにWAITを入れないと次の行の行番号を取りこぼすことに気が付いたので、F-BASICプログラム入力用に別のボタン [Auto-Type (BASIC)]を追加してみた。

2019/01/13

YSFLIGHT SIMULATOR 20181124バージョン公開!

実はDownload.comの方には早々に公開されていたようなのだが、Vectorの方にやっと登録された。

YSFLIGHTユーザの皆さまには、実行時に署名されていないプログラム云々という警告メッセージが多分Windows 8になったあたりから、出ていたと思う。表向きの理由は、セキュリティを高めるためということになっている。誰が書いたプログラムなのか、その後誰かの手によって改変されていないか、それが確認できないプログラムは実行させないという趣旨だった。

情報セキュリティは非常に重要な問題で、実行ファイルの出どころをはっきりさせること自体は良いことだ。悪意のあるプログラムを実行したことによって被害を受ける事件は後を絶たない。そのような事件の責任は当然悪意のあるプログラムを書いた本人にあるべきで、僕はそんなやつは一生刑務所に入っていればいいと思う。

だがセキュリティ問題を利用して利己的な目的を達成しようとする者がいたとしたら、もっと軽蔑してもいい。残念ながらコード署名を発行する認証オーソリティは、誰の利益のためにそうしているのかなんとなくわかるけど、セキュリティ問題を利用して個人プログラマーを排除しようとしている。

コード署名はもともと年間500ドルとかいうレベルでとても手が出なかった。しかし、長いことYSFLIGHTを使ってくれているユーザから懸念のメールをいただいた。実際自分としてもできることならコード署名が欲しいと思っていたので、ときどき手の届く値段でコード署名を買うことができないか探していたのだが、今回COMODOという認証オーソリティが年間$179でコード署名を発行してくれることがわかった。そこで申し込んだのだが、返ってきた返事は、コード署名は個人開発者には発行しないということだった。

他の主要な認証オーソリティも調べたのだが、どうやら認証オーソリティは結託して個人開発者へのコード署名を発行しないことにしたらしい。だから、仮に僕が思い切って年間数百ドルを支払ってコード署名を買おうとしても、買うことができない。何故こんなことが許されるのかわからないけど、認証オーソリティはすべて個人プログラマーを意図的に排除しようとしている。

そのようなわけなので、残念ながらYSFLIGHT.COMからダウンロードできるプログラムに署名することができない。そして、僕にはできることが何もない。残念だけど、奴らの思い通りに個人でフリーソフトを書いて発表するようなプログラマーは絶滅するだろう。 できることと言ったら、ここに現状を書いて知ってもらうぐらいしかできない。

2019/1/6

YS FLIGHT SIMULATOR 20181124バージョンがなぜかVectorに登録されない現象発生中。

飛行初め

ビーバーから飛んできた。


FM TOWNS内蔵SCSIコネクタのピン配列

富士通FM TOWNSを動態保存してる人で、SCSIハードディスクあるいはハードディスクエミュレータを内蔵しようとしてる人、ちょっと待った!

内蔵SCSIアダプタケーブルを噛ましているだろうか?FM TOWNS 20F以降の機種では本体内に内蔵SCSIハードディスクを接続するためのコネクタが出ている。まるで標準のSCSIコネクタであるかのような50ピンだ。

しかし、このコネクタにSCSIデバイスを直結してはいけない!直結したら多分煙を吹く。

昔はたくさんあったSCSIケーブルも最近は入手するのも難しい。SCSI2SDみたいなハードディスクエミュレータだとターミネーターパワーで駆動するから電源ケーブルを接続しなくてもいい。だったら内蔵コネクタに直結したくなってくるが、この一見標準SCSIコネクタに見えるコネクタ、実は標準SCSIコネクタのうち使われていないGNDライン8本を詰めて、1ピンから8ピンに電源を出している。標準SCSIコネクタの2,4,6,8ピンはデータピンだから、そこに12ボルトかけたら煙を吹く可能性がある。

(続きを読む)

 

 

Comments are welcome.  Send E-Mail to: 

Back to http://www.ysflight.com