ウクライナに勝利を！
|
YSFLIGHT.COM内のプログラムはすべてがオープンソースでは無いですが、オープンなものについては、以下のURLからダウンロードできます。
https://github.com/captainys/public
ウクライナに勝利を！
昨日、今日のニュース見ててなんとなくわかった気がする。
隔離してでも抑え込まないと、中国のワクチンが効果がまったくぜんぜん効かないってことが中国の市民にバレてしまうのを恐れてたんじゃないか？
嘘を嘘で隠し通そうとする。人々の暮らしや生命よりもメンツを優先する。共産党の通常営業だ。
11月14日のフライトで、ログブック上の着陸回数が2000回になった。もちろん絶対2000回もやってるうちに数え間違いはあったはずだから、実際の着陸回数は2000回前後だろうけど、とりあえずログブック上は2000回になった。ひとつのマイルストーンをクリア。
YSFLIGHTのソースコードをGithubで公開した。 https://github.com/captainys/YSFLIGHT
僕は、オープンソースがすべての問題を解決するとは思っていない。無造作に他のライブラリへの依存を増やした結果崩壊してしまったプロジェクトをいくつか見た。オープンソースプログラムは未来まで使い続けることができるというのは迷信でしかない。
だとしても、最近僕はプロジェクトが多くなりすぎて、過去数年YSFLIGHTの開発ができなかった。この状況では、ソースコードを公開するのがYSFLIGHTパイロットコミュニティにはベストだと思う。と、してももう少しコードをクリーンにしてから公開したかったな。なんせ一番古いコードは1990年ぐらいに書いたライブラリとか再利用してるもんな。
YSFLIGHTは今までにふたつの自分の人生の目標を達成してくれた。ひとつは、自分のフライトシミュレータを書くこと。もうひとつは、世界中で何十万人にも使われるプログラムを書くこと。いつもユーザからの感想のメールを読むのは楽しかった。他のプロジェクトが落ち着いてきたらまたYSFLIGHT開発に戻るつもりだけど、とりあえず今のところ、このソースをフォークして自分のバージョンのYSFLIGHTを自由に作っていただいても良いと思う。
ついに、PCB、部品その他すべて届く。前回はコネクタ以外は普通の貫通穴マウントだったが、今回は本体のメモリカードスロットに収納できるものを作るために、すべての部品が表面マウント。小さな抵抗、コンデンサ、ICなどをはんだ付けする必要があって、前回より難しい。
まだ指先がプルプル震えるほどの年では無いが、手元に焦点が合わない。幸運なことに、僕はまったく遠くを見る視力は衰えていない。が、だんだん近くが見えなくなってきた。眼科検診のとき、保険適用で無料だからというので老眼鏡をくれたのだが、いまいち合ってないというかかけても近くがそれほど見やすくならない。という状況で今回多用したのが、↓
ピンホールメガネ。理屈は簡単で、カメラのF値を高くして絞ることで被写界深度を深くする。理屈はわかるとはいえ、こんなので効果あるの？と半信半疑だったのだが、友達がいらないからというのでくれたピンホールメガネを使ってみたら、なんと、至近距離まで見える。被写界深度を上げるわけだから遠くのものも普通に見える。これ、老眼鏡を超えてない？ ということで、新たな視力を手にした僕は、果敢に表面マウントに挑んだ！
始める前に、PCMCIAコネクタが1.6mm厚のPCBを想定していたが、今回FRAMチップを乗せても確実にスロットに入るように、0.8mm厚PCBを発注した。その分、ピンとピンの間を狭くする必要があった。ここで、期限切れのクレジットカードが役に立つ。ちょうどいい幅にカットして、上からギューと押してピンを平行に曲げることに成功。クレジットカードはそこそこ固くて割と簡単にカッターで切れるので、この用途には適していた。
FM-7/77用RS232Cカード、ジャンパピンによってCOM0/COM1切り替えに成功。PCBなどはここ(githug)。
純正品互換RS232Cカードはこれまで、オンボードRS232Cカードとの競合の問題からFM77AV40以降の機種で使うことができなかった。多分オンボードRS232Cをオフにしておくことで大丈夫だったかもしれないが、 うっかりオンにしたとき何が起こるかわからなかったのでやっぱり使えなかった。しかし、オンボードRS232Cは最高速度19200bps。外付けカードだと38400bpsまで出るので、半分のスピードしか使えなかった。新しいバージョンでは、COM1に設定することにより、I/Oポートの競合が無くなるのでFM77AV40以降の機種でも使えるはず。(まだAV40でテストできてないんだけど多分大丈夫)
RS232CによるリダイレクションはなによりF-BASICたった4行でインストールできるのがメリットで、フロッピーディスクドライブが既にだめになってしまったFM-77などでもある程度ソフトを起動できる。また、テープインターフェースがそもそもついてなくてテープ版ソフトが実行できなかったFM77AV40SXでもテープ版ソフトを起動できてしまう。
新バージョンによって、AV40以降の機種でも38400bpsによる爆速起動や、ディスクドライブよりは遅いけどある程度使い物になる速度のディスクエミュレーションが可能になった。
それに伴って、FM-7シリーズ再稼働ユーティリティも更新。Disk BIOSリダイレクタ, Tape BIOSリダイレクタどちらもCOM0/COM1を自動判別するようにした。COM0, COM1両方存在する場合はCOM1を優先する。
自己解決。いや、完全に自己ではなかったから他己解決かもしれない。
CMakeで作ったプロジェクトがなぜかすべての実行ファイルを必ず再リンクしてしまう問題は、Admin Command Promptに入って、C:\WINDOWS\SYSTEM32\C_1252.NLSをC:\WINDOWS\SYSWOW64にコピーすることで解決できた。
前日、FM TOWNS情報BBSで、同じ問題に困ってる人いないか聞いてみたら、cmakeが32-bit版でC_1252.NLSが見えていないのではないか？というコメントをもらった。cmakeではなかったが、どうやらmsbuild.exeが32-bitな影響で、C_1252.NLSをC:\WINDOWS\SYSWOW64に探しに行くものの、そのファイルは64ビット用のC:\WINDOWS\SYSTEM32に入っているため、発見できなかったらしい。
msbuild.exeがどうやって依存関係を作るのか調べたところ、Tracker.exeというバイナリを使うらしい。Tracker.exe経由でLink.exeを呼び出すと、Tracker.exeはLink.exeが読み込んだファイル、書き込んだファイルのリストを出力してくれる。読み込んだファイルがリンクに必要なファイルで、書き込んだファイルがリンカの出力と判断するらしい。僕はアメリカに住んでるので、英語版WindowsのSystem Localeを日本にして使ってるけど、そうするとなぜかLink.exeはC_1252.NLSファイルを読み込もうとするらしい。Link.exeも32ビットアプリだと思うんで、果たして成功しているのかわからないが、少なくとも読み込もうとしていることはTracker.exeによって検出されてしまうようだ。
ところが、次回のビルドでは、前回のTracker.exeの出力を元に、リンカの出力がC_1252.NLSに依存すると思ったmsbuild.exeは、C_1252.NLSを探すが見つからない。C_1252.NLSは64ビット用システムファイルがあるC:\WINDOWS\SYSTEM32に存在するが、msbuild.exeは32ビットバイナリなので、C:\WINDOWS\SYSWOW64の中を探してしまう。見つからないんだからリンクできないと判定するのが筋だと思うけど、なぜか見つからないからリンクしなおす必要があると思ってしまうようだ。
msbuild.exeがこのファイルを見つけられるようにしてやれば解決するので、単にC_1252.NLSをmsbuild.exeが見つけることのできる場所、C:\WINDOWS\SYSWOW64にコピーすると解決する。ということだった。FM TOWNS情報BBSのコメントが無かったら多分気が付かなかった。世の中にはすごい人がいるもんだ。
とりあえずこれで津軽、YSFLIGHT、仕事用プロジェクトその他普通にビルドできるようになったんで良かったよ。それで、どうも最近ビルドが遅くなったのは、vcpkgをインストールしたからリンク時にライブラリを探す範囲が広がってしまったからではないかと見てるんだけど、詳細は不明なまま。だけど、困らなくなったからまあ放っておくことにした。
cmake_minimum_required(VERSION 3.12) project(project) add_executable(main main.cpp)
CMakeLists.txt
int main(void)
{
return 0;
}
main.cpp
このプロジェクトをコマンドからビルドすると、何も変更しなくても必ずmainを再リンクする。コンパイルはしない。津軽をビルドするにしてもYSFLIGHTをビルドするにしても仕事用コードをビルドするにしても、ありえない以上に長い時間がかかるようになってしまった。
ログを見ると、
Read Tracking Logs:
main.dir\Debug\main.tlog\link.read.1.tlog
Outputs for C:\TMP\CMAKEBUGGED\BUILD\MAIN.DIR\DEBUG\MAIN.OBJ:
C:\TMP\CMAKEBUGGED\BUILD\DEBUG\MAIN.EXE
C:\TMP\CMAKEBUGGED\BUILD\DEBUG\MAIN.ILK
C:\TMP\CMAKEBUGGED\BUILD\DEBUG\MAIN.PDB
C:\WINDOWS\SYSTEM32\C_1252.NLS does not exist; source compilation required.
Inputs for C:\TMP\CMAKEBUGGED\BUILD\MAIN.DIR\DEBUG\MAIN.OBJ:
C:\WINDOWS\SYSTEM32\C_1252.NLS
C:\PROGRAM FILES (X86)\WINDOWS KITS\10\LIB\10.0.18362.0\UM\X64\KERNEL32.LIB
C:\PROGRAM FILES (X86)\WINDOWS KITS\10\LIB\10.0.18362.0\UM\X64\USER32.LIB
C:\PROGRAM FILES (X86)\WINDOWS KITS\10\LIB\10.0.18362.0\UM\X64\GDI32.LIB
C:\PROGRAM FILES (X86)\WINDOWS KITS\10\LIB\10.0.18362.0\UM\X64\WINSPOOL.LIB
C:\PROGRAM FILES (X86)\WINDOWS KITS\10\LIB\10.0.18362.0\UM\X64\SHELL32.LIB
C:\PROGRAM FILES (X86)\WINDOWS KITS\10\LIB\10.0.18362.0\UM\X64\OLE32.LIB
C:\PROGRAM FILES (X86)\WINDOWS KITS\10\LIB\10.0.18362.0\UM\X64\OLEAUT32.LIB
C:\PROGRAM FILES (X86)\WINDOWS KITS\10\LIB\10.0.18362.0\UM\X64\UUID.LIB
C:\PROGRAM FILES (X86)\WINDOWS KITS\10\LIB\10.0.18362.0\UM\X64\COMDLG32.LIB
C:\PROGRAM FILES (X86)\WINDOWS KITS\10\LIB\10.0.18362.0\UM\X64\ADVAPI32.LIB
C:\TMP\CMAKEBUGGED\BUILD\MAIN.DIR\DEBUG\MAIN.OBJ
C:\WINDOWS\SYSTEM32\TZRES.DLL
C:\WINDOWS\GLOBALIZATION\SORTING\SORTDEFAULT.NLS
C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO\2019\COMMUNITY\VC\TOOLS\MSVC\14.28.29333\LIB\X64\MSVCRTD.LIB
C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO\2019\COMMUNITY\VC\TOOLS\MSVC\14.28.29333\LIB\X64\OLDNAMES.LIB
C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO\2019\COMMUNITY\VC\TOOLS\MSVC\14.28.29333\LIB\X64\VCRUNTIMED.LIB
C:\PROGRAM FILES (X86)\WINDOWS KITS\10\LIB\10.0.18362.0\UCRT\X64\UCRTD.LIB
Source compilation required: input is newer than output .
Environment Variables passed to tool:
TRACKER_CONSOLEPAGE=65001
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.28.29333\bin\HostX64\x64\link.exe /ERRORREPORT:QUEUE /OUT:"C:\tmp\cmakebugged\build\Debug\main.exe" /INCREMENTAL /NOLOGO kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib /MANIFEST /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /manifest:embed /DEBUG /PDB:"C:/tmp/cmakebugged/build/Debug/main.pdb" /SUBSYSTEM:CONSOLE /TLBID:1 /DYNAMICBASE /NXCOMPAT /IMPLIB:"C:/tmp/cmakebugged/build/Debug/main.lib" /MACHINE:X64 /machine:x64 main.dir\Debug\main.obj
こうなっている。"Source compilation required: input is newer than output ."と、言っているのだが、問題は、Inputsに挙がっているすべてのファイルはアウトプットよりも古い。ひっかかるのは、"C:\WINDOWS\SYSTEM32\C_1252.NLS does not exist; source compilation required."という部分だが、このファイルは普通に存在している。ファイルが存在しないならダミーファイルでも作っても良いのだが、存在するものをこれ以上存在させることはできないので、どうにもならない。
何か使ってるPCの設定をぶっこわしたのかと思って、別のPCでも試してみたら、そっちも同じになってた。しかし、Visual C++をアップデートした憶えもないし(勝手にアップデートされてたならあるかもしらんが)、CMakeもアップデートしてない。カスタマサポートが一番困る「何もしてないのに壊れた」にはまってしまった。
キーワードとかファイル名で検索しても何も出てこない。
妙なのが、Visual StudioのIDEからコンパイルするとこの問題は起こらない。一度ビルドしたものは変更が無ければ再度ビルドしない。当面GeneratorをNMake Makefilesにして対応しようと思ったけど、そうすると--parallelオプションが使えない。困ったな。
誰か直し方知ってる人、助けて。
FM TOWNS起動用ICメモリカード製造プロジェクト進行中。これに成功すると、初代(+SCSIカード), 二代目、三代目FM TOWNSも本体無改造で救済できる鴨しれない。
ウクライナの人たちを支援するために自分には大してできることは無いが、ウクライナの人たちを支援している団体を支援することぐらいはできる。以下のリンクはNBCの朝のニュース番組Today Showで取り上げていた団体なので、信頼できそうに思う。
https://www.globalempowermentmission.org/mission/ukraine-crisis/詐欺リンクを踏まないために、ブラウザでNBC.comを開いて、その中のTODAY.COMをクリックして、そのページに貼ってあったリンクをコピーしたから、NBCのサイトがハックされていたとか僕のブラウザが既にハックされていたというような場合でなければ、このリンクは本物のはず。
プーチンはソビエト連邦の亡霊について行こうとしているのだろうか？
何やら大昔に作ったスクリーンセーバーが YouTubeで話題 になっていたので、ソースを発掘してWindows用とFM TOWNS用にコンパイルできるようにした。
ソースコード、実行ファイルなどは、以下のURLから:
https://github.com/captainys/FLYBY2
突然4分の1世紀も前に書いたスクリーンセーバーが発掘されて話題に上るとは。
このスクリーンセーバーはどこでリリースしたっけ？と思ったら、アスキーから"3Dスクリーンセーバー開発キットSaber"なる本を出したことがあって、そのCD-ROMにおまけ兼例題として載せたものだった。あのときのスクリーンセーバーはWindows用しか出してなかったと思うから、FM TOWNS版はこれが初リリースかもしれない。スクリーンセーバーではなくただのデモになってるけど。486DX以上が必要で、EXG形式なのでTowns OS V2.1 L31以降から起動する必要がある。FM TOWNSエミュレータ津軽上で動作確認した。まだ実機に持って行ってテストしてないけど。
ほとんどというか、おそらく100％何の役にも立たない情報。株式会社メディアカイトがWindows95/98/98SE/Me/2000/XP用として移植したnamcoの「源平討魔伝」は、インストーラが動作しないようだが、CD内のDISK_1ディレクトリ内のGENPEI.EXEを直接実行するとWindows 10から使用可能。フルスクリーンモードも使えるし、ゲームパッドにも反応するのでほぼ完璧にプレイ可能。ただし、さすがに30年もの歳月で腕が落ちててさすがにエンディングまでは確認できんかったけど。
同じく株式会社メディアカイトがWindows 95/98用にSuper 1500シリーズとして移植したnamcoの「Dragon Buster」は、いったんWindows 95または98にインストールした上でProgram Files下の半角で「ドラゴンバスター」ディレクトリ内のファイルを抜き出して持ってくるとWindows 10から使用可能。ただし、もともとフルスクリーンモードが無いのでMagnifierとか使わないと小さすぎてきつい。それから、設定ダイアログはバグるので、ゲームパッドを有効にしようとするとクラッシュする。また、どうやらアーケードをそのまま移植したようで、本来であればドラゴンバスターは大傑作としてゲーム史に記憶されるはずだったのに、小傑作になってしまった唯一の原因である、4方向レバーで斜めジャンプがほとんどめちゃくちゃ難しくてほとんど不可能という問題をそのまま残している。(プレステ用のNamco Museum、FM77AV版ではこの問題が修正されている。)
Windows 98用だったと思うけど出てたNamco History Vol.1, Vol.2もこの間Windows 10で実行する方法をたしか解明したんだけど、メモどこかやっちゃったなあ。今どき他にも当時のアーケードの名作をプレイする方法はいくらでもあるんで、ほとんどまったく意味が無いんだけど。ただ、開発元が健在で復刻版を出してくれてるところはいいけど、開発元がもう存在しなくて誰も復刻版を出せなくなってるクラシックゲームとかを合法的に保存する方法を考えるべきだと思うんだがなあ。アメリカの著作権法は一歩進んでて、合法的に入手したならという条件付きだけど、クラシックゲームの保存のために解析したりコピープロテクトを解除したりということは合法ということになってる。日本の著作権法もそのぐらいに変えるべきだと思うんだけどな。著作権法は著作者だけではなく、著作物も保護すべきだ。
油断してたら1月19日になってCMUの春学期が始まってしまった！
FM TOWNSエミュレータ「津軽」で「大航海時代」をプレイする
どうして僕はレトロゲームをプレイするのか、と、考えてみると、自分がFM-7、FM77AVを使っていた当時はゲームを買いたくても何本も買うだけの財力が無く、FM TOWNSを使っていた当時は3次元グラフィックスとCプログラミングが楽しくてあまりゲームを買わなかった。楽しそうだと思ったゲームはたくさんあったのだが、遊んでみたいと思ったままになっていたゲームがあまりにも多すぎる。最新のゲームは技術の進歩もすごいし、多分遊んだら楽しいのだろうとは思うが、その前に自分の中でやりのこしたことになっているゲームが多すぎる。
「大航海時代」はそんなゲームのうちのひとつだった。今をさかのぼること30年ぐらい、当時青森県立弘前高校の地学準備室に置いてあったPC8801(だったと思う)で後輩が楽しそうに「大航海時代」をプレイしていたのだが、僕は指をくわえて見ているだけだった。ところが、大学に入ると自分でフライトシミュレータを作りたいという欲求がゲームをプレイしたい欲求よりも上回っていたもんで、「大航海時代」FM TOWNS用が出ていたことすら知らなかった。それが、去年ヤフオクで「大航海時代」を落とすことができたので、そのうちプレイしてみようと思っていた。
とはいえ、プレイを始めたらしばらく時間がかかりそうだから、まとまった時間ができるのを待っていて、ついにこの冬休み、30年の時を経て「大航海時代」を我がFM TOWNSエミュレータ「津軽」上でプレイしてみた。
なお、CD-ROM上のVER.DATによると、Ver 1.00 Rel 1.00、1990 10.31とのこと。プレイしてみて、合計4点のバグに遭遇して、うちひとつはゲーム続行が不可能になる致命的なもので、ひとつはセーブデータから再開すればなんとか回避できそうなもの、残るふたつは誰かが通してプレイテストしていれば発見できたと思われるバグだった。そのうち3か所はパッチを書くことができた。パッチを書けなかった個所は、それほど致命的なものではなく、再現しようとしているのだが、再現できなくなってしまった。 しかし、このレベルのバグが残っているということは、おそらく出荷前に誰もFM TOWNS版の通しテストプレイをしなかっただろうと推測している。果たしてアップデート版が後にリリースされたのだろうか？
(続きを読む)
Comments are welcome.
Send E-Mail to:
 |