■ このスレッドは過去ログ倉庫に格納されています
PCエミュレーター統合スレッド Part7
- 1 :ナイコンさん:2015/05/05(火) 23:37:28.05 .net
- 古き良き、1970年代〜90年代のマイコンエミュレーター統合スレッドです。
基本、開発・人柱・新バージョンの報告や話題等で進行をお願いします
たまには上記の延長線上での脱線も可
※家庭用ゲーム機器は板違いです。(ぴゅう太はOK)
※ジェネレーターや其れに準ずる質問等はスレが荒れる原因になるので華麗にスルーして下さい
※上記の事柄に反応した場合その人も同じ池沼扱いされますので決して反応してはなりません
※このスレは如何にスルーできるか問われるスレですので肝に銘じておいて下さい
※禿しく空気読め
前スレ:PCエミュレーター統合スレッド Part6
http://hello.2ch.net/test/read.cgi/i4004/1364603890/
- 237 :ナイコンさん:2015/09/13(日) 05:09:38.70 .net
- >>236
Avast(笑)って良くレスされるくらい誤爆で有名だから仕方ない感じだね
除外リストに登録でいいんじゃね
- 238 :ナイコンさん:2015/09/14(月) 09:48:47.16 .net
- Avastてウィルスだったのかw
- 239 :武田 ◆bnZpPXJze51u :2015/09/15(火) 01:39:04.42 .net
- 物理フォーマット周りは後日見直してみます。
イメージファイルに反映されるのはイジェクト時か終了時ですが、
オンメモリでは直ぐに反映されている筈なんだけどなあ。
物理フォーマットして、システムディスクをセクタコピーして
システムディスク作成とか出来てたような気がするし。
- 240 :武田 ◆bnZpPXJze51u :2015/09/15(火) 01:52:40.75 .net
- ディスクの速度ですが、セクターの読み書きの速度そのものは、
ディスクのトラック長と回転数から算出しているので、概ね正確です。
問題は、リードライトのコマンドが発行されたときのヘッド位置から
セクタが発見されるまでの時間の算出かと思います。
現在の実装では、IDフィールドのSYNCより前にヘッドがないと、
もう一周回転してからアクセスするようになっていますが、
実際はID ADDRESS MARKの直前まで大丈夫なんじゃないかなーと、
(ディスクイメージがスキューファクターを再現できているか、
という問題も勿論あるのですが)
- 241 :ナイコンさん:2015/09/15(火) 02:11:39.91 .net
- FM-77の3.5フロッピーのゲームを吸い出ししたいんだけど
どうやるのか優しく教えてください。
- 242 :ナイコンさん:2015/09/15(火) 06:28:30.56 .net
- >>241
3.5フロッピーをBIOSで認識できるマシンならDOSで起動してDITT使えば出来るよ
- 243 :ナイコンさん:2015/09/15(火) 07:21:11.12 .net
- >>242
DITTはFDCのI/Oに直接アクセスするのでBIOSのレガシーエミュレーションでアクセス出来てもUSB-FDDはダメです。
- 244 :ナイコンさん:2015/09/15(火) 09:06:47.50 .net
- レガシーエミュレーションが何かさっぱり出来ないお子様の模様
- 245 :ナイコンさん:2015/09/15(火) 12:13:06.26 .net
- DITTとはなんでしょうか?
- 246 :ナイコンさん:2015/09/15(火) 12:48:57.50 .net
- 同上
- 247 :ナイコンさん:2015/09/15(火) 15:27:33.45 .net
- >>245
http://retropc.net/cisc/m88/dl/Ditt150.lzh
- 248 :ナイコンさん:2015/09/16(水) 04:25:44.86 .net
- そもそもタイミングをイメージデータとして持てばテープだろうがCDだろうが
単一形式化できないものかな?
- 249 :ナイコンさん:2015/09/17(木) 11:27:11.90 .net
- >>248
正確に読めない事を利用した不安定プロテクトとか有るから全ては無理だな
- 250 :ナイコンさん:2015/09/17(木) 19:22:08.13 .net
- >>249
正確に読めないということはズレてる訳だから、それが検出できる精度で記録すればいいのだろうか?
- 251 :ナイコンさん:2015/09/17(木) 21:41:50.13 .net
- 物理的なランダム性のエミュレートだろうな
- 252 :ナイコンさん:2015/09/18(金) 01:58:34.30 .net
- 1つ前のスレッドで、プリンタ部分をDLL化するとかいうネタがあったけど
32bitのDLLにしてしまうと64bitのEXEやLinuxネイティブバイナリからは使えないよね
openMSXではTclを使って色々出来るみたいだけど、LuaでもSquirrelでもいいから組み込んで
外部のスクリプトファイルを読み込むとかで何かうまいこと処理できないもんかな
- 253 :ナイコンさん:2015/09/19(土) 03:55:51.46 .net
- っていうか、別プログラム起動でパイプなりソケットで渡すとなんか問題あるの?
- 254 :ナイコンさん:2015/09/19(土) 20:24:25.96 .net
- >>250
検出出来ちゃったら不安定では無いことになるから話が違うぞ
- 255 :ナイコンさん:2015/09/19(土) 20:29:10.33 .net
- >>253
別プログラムの場合、複数のエミュレータを同時起動させたときのことを考えると面倒じゃないかなあと思ったんだけど
最低限「切断」と「接続」を切り替えできるようにしておけばいいのかな
2つのエミュレータでそれぞれ別々に印刷できる仕様ならば「切断」/「プリンタ1と接続」/「プリンタ2と接続」な感じ?
- 256 :ナイコンさん:2015/09/20(日) 00:16:00.33 .net
- むしろケーブルのエミュレータがあればいいのかもしれないな。
端子から端子へ丸投げする只のエコーサーバ的な。
- 257 :Artane. ◆1o3c8RYIzjU0 :2015/09/20(日) 14:21:16.56 .net
- 色々バタバタしててちょっとストップしてます。連休後半再開予定。
>>256
UnixのFIFOのように汎用性の高い(リダイレクトしたり双方向通信出来る)ネームドパイプって、Windowsにありましたっけ?
確かにRS-232CやMIDIやプリンターの実装をやるモチベーションにはなるので。
- 258 :Artane. ◆1o3c8RYIzjU0 :2015/09/20(日) 14:24:20.08 .net
- >>255
FIFO作る所までがエミュレータの責任で、そのFIFOに読み書きしてエミュレータと通信するのは何でもいい。とか。
こうすると、ダム端末エミュレータからエミュレータと通信出来るし、なんかのプログラムと繋いで印刷イメージをレンダリングしたりしてプリントアウトするのもやりやすくなる。
- 259 :ナイコンさん:2015/09/20(日) 16:18:50.84 .net
- 汎用というとUSB?
仮想USBドライバの作り方とかは知らないけど。
- 260 :ナイコンさん:2015/09/20(日) 17:01:46.38 .net
- usbipとかが利用できれば面白そうなんだけど、
まともな成功例が見当たらないから改造が必要かもな。
- 261 :ナイコンさん:2015/09/20(日) 17:46:16.32 .net
- >>258
emu_oldpcA.exeとemu_oldpcB.exeが両方走っている時にemu_printerZ.exeを起動させたら
printerZはoldpcAとoldpcB、どっちと接続すればいいのかという問題が出てくるのではないかと。
(DLLみたいに同じプロセス内で動くんだったら関係ない話なんですが。)
同時に2つのoldpcと繋がってしまう、は発生しない仕様として。
先に起動したoldpcでしかプリンタが使えないとか、起動順に依存するのは使い勝手が悪い気がします。
ということで、別プログラムにする場合は\\.\pipe\emu_ptrcable1だの\\.\pipe\emu_ptrcable2だのを
oldpcとprinterそれぞれのプロセスからユーザーが任意のタイミングで(または、Resetのタイミングで一緒に)
CreateだかOpenだかCloseできるようにするのがいいのかな?と。
Windowsの名前付きパイプでうまい具合に実装できるかどうかは知りませんけど。
と思ったけど、起動順に依存するのであれば「emu_oldpcA.exeは\\.\pipe\emu_ptrcable1に繋がってるよ」
「emu_oldpcB.exeは\\.\pipe\emu_ptrcable2に繋がってるよ」というのが容易に判別できれば済むという
ことですかね。あとはprinterのほうだけ起動時に接続制御すれば良い、と。
(oldpcの電源を後から入れるような周辺機器や、oldpc同士の通信を考えるとまた別の話になりますが。)
- 262 :Artane. ◆1o3c8RYIzjU0 :2015/09/20(日) 22:47:26.77 .net
- >>261
Unix系だと、mktempなどでプロセスIDなどをベースとした、
一見ランダムな名前の一時ファイルを作れるので、それとmkfifoでパイプを作るのを組み合わせて、
プロセスユニークなパイプが作れます。
それを、何らかのシステムコール(多少考えてる)でファイル名読み出して、
その名前をパイプの向こう側のプログラムの引数かなんかに指定してプログラムをexecすれば…
とゆう感じがいいかな。と。
もう少し高度なIPC手順を乗せてもいいですが。
その辺りは、少し実装考えてみますね。
Unix依存も良くないからどうしようかなとは思いますが。
- 263 :Artane. ◆1o3c8RYIzjU0 :2015/09/20(日) 22:51:19.65 .net
- 後、エミュレータ同士を繋ぐなら、どちらを先に立ち上げてもいいように、
エミュ1⇄パイプ1⇄ソケット接続するサーバー、クライアント?⇄パイプ2⇄エミュ2
みたくするとか。
UPnPの機構みたいのがあるといいのかもですが…そこまでやるべきかどうか。
- 264 :Artane. ◆1o3c8RYIzjU0 :2015/09/20(日) 22:56:01.14 .net
- >>252
tclとかpythonのインタプリタ(可能ならば流通してるライブラリーも使えるようにする)やそれをエミュレータと接続するためのバインド系を組み込むとかですかね?
そこまで行くと複数プログラム間で共通のライブラリーにしないと膨らむなぁ…(;´Д`)
今ですら、gccだとリンク時最適化しないとデカいのでどうしよう…(;´Д`)
- 265 :ナイコンさん:2015/09/21(月) 01:27:53.26 .net
- >>264
・バイナリに内蔵で固定の処理ではなく、処理内容を柔軟に変更可能 開発ツールでの再ビルド不要
・プラットフォームに依存しない作りに出来る
という利点がスクリプトにはあるんですけど、プロセス間通信(またはDLL等)でやると決めたら
スクリプト無しでいいですよね
というわけで、以下の話は余談。周辺機器以外にも利用価値があるはずなので一応。
数年前、VC++で作ったプログラムでテキストボックスに入力したスクリプトを処理できるように
Luaのソースを無変更でほぼ丸ごと組み込んだときはバイナリのサイズが150KBほど増えてたかな……
数十個のバイナリそれぞれに組み込んだら無駄が多いかもしれない
やっぱりLua部分だけDLLみたいな別バイナリにするべき?
あるいは、プリンタエミュレータのEXEにLuaを組み込むという手法もあり? EXEが一種類だけで済むかも?
別に、Luaじゃなくてもいいんですけど。
あと、GPLと混ぜて大丈夫なライセンスのスクリプトかどうかもチェックしないと駄目ですよね。
- 266 :ナイコンさん:2015/09/21(月) 01:33:30.45 .net
- マクロならアセンブラでよくね?
- 267 :ナイコンさん:2015/09/21(月) 22:22:18.25 .net
- メインルーチンやメニュー辺りを丸ごとスクリプト化したらエミュレータツクールができるんだろうか?
MIND辺りで書かれてたらちょっと面白いかも?
- 268 :Artane. ◆1o3c8RYIzjU0 :2015/09/23(水) 15:20:48.44 .net
- >>266
一から起こすのはとても面倒臭いじゃないですか(・∀・)
- 269 :Artane. ◆1o3c8RYIzjU0 :2015/09/23(水) 15:24:46.77 .net
- >>267
エミュレーション機械ごとに#ifdefで区切られてる辺りを、変数で分岐するように組み替える、とんでもない手間とスタブ付けが必要になりますが、
スケジューラーはそれが出来るようにはなってますね。
VM初期化段階でなんかのスクリプト言語でスケジューラーに仮想デバイスを宣言していくというのは、多分出来るんじやないかな(当面はやらんですが)
- 270 :ナイコンさん:2015/09/23(水) 17:53:11.90 .net
- ある意味、武田さんのプロジェクトは
「自分でソースをビルドしたりC++のソースを理解や改造できる人向けのエミュレータツクール」
に近い存在じゃないのかな。
自分でソースをビルドする必要がない物に関して言えば、
vdmgr:www.geocities.jp/g_lsluk/vdmgr.html
モジュールさえあれば、iniファイルの記述次第で色んなハードウェア構成を実現できるらしい。
あと、MAMEやMESSはエミュレーション対象によらず共通バイナリだから、動的にハードウェアを
構成してるんだよね? 新しい構成を作るにはソースを変更する必要があるんだろうけど。
- 271 :Artane. ◆1o3c8RYIzjU0 :2015/09/26(土) 03:12:49.16 .net
- とりあえず、武田さんの9/23版をマージして、その他色々やったのをアップロードしました。
https://github.com/Artanejp/common_source_project-fm7/releases/tag/SNAPSHOT_20150926
FM77AV40/EXもほぼ動くところまで持ち込みましたが、SXの入門ディスクの描画に問題がある所があります。
後、キーボードエンコーダの隠しメッセージを早い段階で実装してますが、その反面、相変わらずリアルタイムキースキャンには難があります。
まだまだ問題含みではありますが。
- 272 :武田 ◆bnZpPXJze51u :2015/09/26(土) 11:19:30.88 .net
- お疲れ様です。
こちらの作業もそろそろ一段落つきそうですので、
適当なタイミングで取り込ませていただきます。
- 273 :ナイコンさん:2015/09/26(土) 15:44:27.62 .net
- よっ犯罪者
息してたか?
- 274 :ナイコンさん:2015/09/27(日) 10:31:16.15 .net
- ePC-9801VM/Doってディスク読み込みます?
- 275 :ナイコンさん:2015/09/27(日) 15:34:53.07 .net
- >>274
読み込むよ。
本当のVM0(初期型)またはDO(DO+はNG)のBIOSじゃないとダメよ。
ちなみにMESS向けのはCRC違いの別物。こっちはもしかしたらVM21系のかもね。
- 276 :ナイコンさん:2015/09/28(月) 05:05:29.36 .net
- つーかBIOSってなにが違う訳?
エプソン機が載せようとして揉めたって話だから基本的には互換あるのかと思ってた。
- 277 :ナイコンさん:2015/09/28(月) 11:15:12.32 .net
- >>275
VM2やVM4じゃダメなのけ?
まぁ、どのみちDXから抜いたと思うけど
- 278 :武田 ◆bnZpPXJze51u :2015/09/29(火) 01:27:52.85 .net
- >>271
SNAPSHOT_20150926までの変更を取り込みました。
FM77AV40とFM77AV40EXが追加ということでよろしかったでしょうか?
>>277
VM2ならいけると思います。
>>276
同じPC-9801といっても、ハード的には各機種別物だったりします。
載ってるCPUも色々だし、ディスク周りも2DDのみ/2HDのみ/両対応とか、
ノートの様に電源周りなどの特殊仕様もあったりとか。
で、ハードが違えば初期化の仕方も操作の仕方も千差万別でして。
そういった違いを、各機種ごとにカスタマイズされたBIOSが頑張って
吸収してくれるから、ソフトから見たら全部同じPC-9801だったという話。
- 279 :武田 ◆bnZpPXJze51u :2015/09/29(火) 01:30:13.61 .net
- >>277
補足すると、UやVFのBIOSでもいけます。
#いや、普通の人はそんな不遇機持ってないって(苦笑)
- 280 :武田 ◆bnZpPXJze51u :2015/09/29(火) 03:48:41.79 .net
- >>271
あー某女史に指摘されてるなあ(苦笑)
私がビルドしたeFM77AV40/EXのメニューの件は明晩にでも修正します。
#新機種追加するたびに、resource.hの修正を忘れてしまう(苦笑)
- 281 :ナイコンさん:2015/09/29(火) 10:29:34.38 .net
- ハードは別物別物ってよく言うけどさあ、本当に別物でBIOSで互換取れるんだったら、
抜いちゃダメボード移植してBIOS書き換えてこれが新しい98ですとか誰かやってると思うなあ。
- 282 :ナイコンさん:2015/09/29(火) 10:55:36.92 .net
- BIOS書き換えたら何でも出来るとお考えか?
- 283 :Artane. ◆1o3c8RYIzjU0 :2015/09/29(火) 17:01:49.07 .net
- >>278
はい。AV40と40EXです。
ありがとうございます。
>>280
よろしくお願いします。
- 284 :ナイコンさん:2015/09/30(水) 06:55:15.46 .net
- >>279
一番なじみのある98が友達の家のVFなんですぜ・・・w
X1(俺)、88、MSX、98のユーザー同士で各家巡回して
あぁ、懐かしい・・・
その頃、時代的に巡回先でベーマガのプログラム10行交代とかで入力してましたからねぇ
その後、自分はDXだけどほとんどX68使ってましたw
あ、U・・・UX21ならそこに転がってるんですけどね・・・
- 285 :ナイコンさん:2015/09/30(水) 06:56:29.97 .net
- ちなみにVMも持ってたけど、VFの友達にあげました
- 286 :ナイコンさん:2015/09/30(水) 15:50:46.62 .net
- つーか、未実装機能の初期化でコケてるだけなら、適当にNOPで潰せば抜けられないものだろうか?
そういえばFMには逆に旧機種ROMで動かす力技があったけど、あれは使えてるのかな?
- 287 :ナイコンさん:2015/09/30(水) 16:44:50.34 .net
- >>223
ぱっと見ST3は違ってるし書き込み失敗する事もあるからどっかおかしいな
- 288 :ナイコンさん:2015/09/30(水) 20:38:44.04 .net
- >>732
魚さんに頑張ってもらって妹経由で情報流してもらうしかないな。
- 289 :ナイコンさん:2015/09/30(水) 20:48:21.62 .net
- 猫さんでも姉でも使えるものはなんでも使おう
- 290 :Artane. ◆1o3c8RYIzjU0 :2015/10/01(木) 14:28:37.42 .net
- 昨日、なんとか、PX7を除く全ての仮想マシンをQtに移植しました。
PX7は、どういう形でバックの映像表示を実装するか考えないといけないので、優先度低くしてます。申し訳ない。
で、cppcheckでコードチェックして修正したら、77AV40系がビミョーなことになりました(;´Д`)
今日明日は別件(複数)で殆ど時間が潰される上に、
XM8がWindows XPで初期化に失敗してるのをなんとか出来ないかという話があって、ソースコード見ないと
拙そうな状況に追い込まれたので、その後になるかも…と言うか、SDL_Joystickの初期化に失敗した
時のフォールバックが実装されてないんですよね、XM8。
SDL_JoystickがXP(ひょっとしたらVista以前)でなんで初期化に失敗するかも謎だし…
- 291 :Artane. ◆1o3c8RYIzjU0 :2015/10/01(木) 14:33:51.11 .net
- 余談:
PX7,libavを直接叩くと面倒くさくてしかもlibavはAPIが頻繁に変わる邪悪さなので、
Qt::MultimediaかGstreamerで実装します(;´Д`)
これから、お勉強しないといけないけどその前にやることが沢山ある(;´Д`)
- 292 :ナイコンさん:2015/10/01(木) 19:24:59.59 .net
- wineにお任せとかってできないの?
- 293 :Artane. ◆1o3c8RYIzjU0 :2015/10/01(木) 19:30:13.82 .net
- >>292
ところがですねー、WineでXM8動かすと同じ事起こるんですよ奥さん(´・ω・`)
で、CSPの方に関しては、まぁ、私がLinuxで殆ど廻してるので(´・ω・`)
と言うか、Windowsは仮想化マシンでしか使わんのですよ(´・ω・`)
どうも、Linuxと較べて融通が効かない気がするので使う気が余り起きない(´・ω・`)
もう、23年位Linux使ってるから…
- 294 :ナイコンさん:2015/10/01(木) 19:39:37.96 .net
- エミュでなく、ライブラリとしてのwineってどうなのかな?
- 295 :ナイコンさん:2015/10/01(木) 19:44:17.41 .net
- >>290
XM8の1.40がXPで動かないという問題は、VisualStudio2013で
ttp://blogs.msdn.com/b/jpvsblog/archive/2013/04/17/visual-studio-2012-windows-xp-visual-c.aspx
と同じことをするか、EXEファイルのヘッダを書き換えてMajorSubsystemVersionのあたりを6から5に変更
すれば済む話ではないかと思いますですじゃが、ジョイスティック部分にも問題あり?
- 296 :ナイコンさん:2015/10/01(木) 20:19:44.92 .net
- そういえばwin3.1版HSP1.1をwineで動かして見たんだけどコンパイルができないんで
おかしいなと思って単体起動させようとしたらスプリプトコンパイラがDOSアプリだった。
dosbox使えと言ってくるのを無視してmsdos.exe経由で起動させたら今度はコンパイルできた、便利だなあこれ。
デモプログラムは擬似スプライトで箱が動いてるんだけど、確かにスクリプトでもなんか作れそうな期待がもてる感じだなこれは。
- 297 :Artane. ◆1o3c8RYIzjU0 :2015/10/29(木) 19:23:46.30 .net
- お久しぶりです。
とりあえずリリースしてみました。武田さんの10/27版ベース。
https://github.com/Artanejp/common_source_project-fm7/releases/tag/SNAPSHOT_20151029-1
今回、↑からリンクしてるバイナリは、GNU/Linux (AMD64)向けのみです。(Windowsを年末以降に買うまではWindows版を出せないかも…)
FM-7〜AV40EXまで、殆ど動くようになりました(自信がない)。
FM7系にもステートセーブが追加されました。
Qt固有の機能も拡充して、ドキュメントをプログラムに組み込んだりしました。
まだまだ色々やるべきことはありますが、FM-7系についてはここまで(GITのログを見たら去年の12/30に着手してる…)なんとか来たな。と言う感慨が。
- 298 :ナイコンさん:2015/10/30(金) 11:52:09.83 .net
- windows版よりむしろwine版でいいからsse無し検証用バイナリが欲しい所
- 299 :Artane. ◆1o3c8RYIzjU0 :2015/10/30(金) 13:45:23.85 .net
- >>298
Windows8のお試し期間がもうすぐ終わってしまうので、8か売ってなければ10の正規品を購入する予定(は未定)
とりあえず、FM-7系だけSSEなしでビルドしてみますね。しばしお待ちを。
# しかし、SSEが使えないマシンってどのくらいあるのでしょうかね。
# 今時のスティックPCですらSSE2は標準だった気が。
- 300 :ナイコンさん:2015/10/30(金) 15:56:59.52 .net
- SSE使わなきゃ非x86の展開もありえるのかな?
- 301 :Artane. ◆1o3c8RYIzjU0 :2015/10/30(金) 15:57:36.76 .net
- >>298
とりあえず、FM-7/77/AV/AV40EXだけビルドしました。SSEなしで。
https://github.com/Artanejp/common_source_project-fm7/releases/tag/SNAPSHOT_20151029-1 から。
只、右シフトが個別に認識されない問題が解決できてません(上流との兼ね合いで右シフトをシフトと見做してる上に空きキーがないので)
- 302 :Artane. ◆1o3c8RYIzjU0 :2015/10/30(金) 16:00:23.64 .net
- >>300
とりあえず、GUIがQtでよければ、ARMなどでも(必要があればNEONのようなSIMD付きで)ビルドできるはずですよ。試してないけど。
- 303 :武田 ◆bnZpPXJze51u :2015/10/31(土) 01:03:28.15 .net
- >>297
お疲れ様です。
今晩のリリースで10/29までのコミットを取り込みました。
Paste機能が壊れていたのを修正したのと、
vm->key_down/up()に、VK_SHIFTでなくVK_LSHIFT/VK_RSHIFTを
通知できるようにする仕組みを追加しました。
#define NOTIFY_KEY_DOWN_LR_SHIFT
が宣言されていると、VK_LSHIFT/VK_RSHIFTが通知されます。
宣言されていないと、従来通りVK_SHIFTが通知されます。
VK_CONTROLやVK_MENUも同じ要領で左右の区別が可能です。
- 304 :ナイコンさん:2015/10/31(土) 04:47:41.27 .net
- >>302
いや、俺はいいですw
SSEなしだとそうのもあるのかなと・・・
ラズパイのビルドあったら興味ありますけど
- 305 :Artane. ◆1o3c8RYIzjU0 :2015/11/06(金) 03:10:50.28 .net
- >>303
お疲れ様です。
対処ありがとうございました。
こちらで組み込んで確認しましたが大丈夫そうです。
- 306 :Artane. ◆1o3c8RYIzjU0 :2015/11/06(金) 03:15:00.04 .net
- で、またリリース掛けました。
http://www1.axfc.net/u/3561759
https://github.com/Artanejp/common_source_project-fm7/releases/tag/SNAPSHOT_20151105
Windowsでも、mingwとQtでビルドできるようにしました。多くのVMが未だビルド出来ないというか、型定義の問題で処置が必要な状況ではありますが…
描画周りを相当書きなおして、GLSLでレンダリングしたりするようにしました(と言うのも、WindowsのOpenGL関連が色々問題があったのでう)。
今回は、Windows版Qtをバンドルしたので異常に大きくなってます。
今後は、Qtはバンドルしない方向にしたい…
- 307 :ナイコンさん:2015/11/06(金) 20:58:45.45 .net
- >>306
Win32-Qtのバイナリ、うちではダメみたいです。
libs.for.CSP.with.QtWindows.7zの中身を全部展開してexeと同じフォルダに置いてexeを実行してみたら
>This application failed to start because it could not find or load the Qt platform plugin "windows".
>
>Reinstalling the application may fix this problem.
>
>This application has requested the Runtime to terminate it in an unusual way.
>Please contact the application's support team for more information.
でした。
exeだけ入ったフォルダで実行してみたら
>コンピューターに Qt5Core.dll がないため、プログラムを開始できません。この問題を解決するには、プログラムを再インストールしてみてください。
なので、dllの置き場所が間違っているわけではなさそうです。
- 308 :Artane. ◆1o3c8RYIzjU0 :2015/11/06(金) 22:09:34.33 .net
- >>307
んー、やっぱり、横着しないでttp://qt.io からQt5.5.1のコミュニティ版をインストールして貰って、付属のコンソールから起動して貰わないとダメかも知れないですね。
パッケージングするいい方法を探さないと…昨日公開したのはキーコードの問題もありますし、暫しお待ちを。
それとも、スタティックリンクするか…
- 309 :ナイコンさん:2015/11/07(土) 01:57:48.56 .net
- ─☆─ [ X | I.I.T. ] COURANT DE CONSOLE ◇TXFAX7cidQpG
コンソールってこれじゃダメですか?
- 310 :Artane. ◆1o3c8RYIzjU0 :2015/11/15(日) 04:16:09.22 .net
- 又、リリース掛けました。
https://github.com/Artanejp/common_source_project-fm7/releases/tag/SNAPSHOT_20151114
今回、Windows(MinGW32)版はQtで必要なものだけバンドルしてあります。
Windows10では動くのですが、WindowsXPだとVCのランタイムとの相性で動かない可能性があります (@_@)
画面が出ない人は、ドキュメントのTIPSを参考にしてみてください。
- 311 :umaiboux:2015/11/15(日) 20:55:50.31 .net
- >>310
MSX1とMSX2、Windows7の64bitで起動しました。XPでは起動しませんでした。
とりあえず気付いた点だけ書いておきます。
・Copy/Pasteが動作してない。
・MSX1を起動すると、描画領域の右に余分な領域がくっついている。Screen Size x1の場合は500ドット以上余分。MSX2のほうは、起動時に余分な領域が表示されて一瞬で消えている?
・MSX2の色がおかしい:v99x8.cppの72行目あたりで色の定義を勝手に決めているのが原因でしょうか。だとすれば私のせいですスミマセン。
・Altキーを押すと、時々メニューバーのほうが反応してしまって仮想マシンに入力されない?
あと、動作には関係ありませんが、HELP→AboutのtanamさんのところにはMSX1も書いておいて下さい。
私も一部ソースの修正やブログへのコメントはしましたが、最初にMSX1を動かしたのはtanamさんです。
むしろ、「(c)tanamはMSX1とMSX2の両方、(c)umaibouxはMSX2だけ」でもおかしくないかもしれません。
- 312 :Artane. ◆1o3c8RYIzjU0 :2015/11/15(日) 22:05:58.21 .net
- >>311
ありがとうございます!
・Copy/Pasteの問題は、一応認識していて未だ動いてない。と言うのが現状です。とりあえずクリップボードからエミュへの取り込みはできてるので、もう少しイジっていきます。
・余計な領域に関しても、要修正ということで一旦先延ばしにしていましたが認識してます。
画面の大きさを大きくすると消えるのではありますが、多分下のステータス表示欄がわるさしてる。
・色に関しては、これから確認します。
・右AltはQtの側が先に取ってしまってるので…左Altはどうでしょうか?
Creditsに関しては、修正します。
後、XP対策はちょっと考えていきます。
- 313 :umaiboux:2015/11/15(日) 23:34:52.15 .net
- >>312
右Altも左Altも同じ現象のようです。
ちょっと訂正。
単独でAltを押下すると、仮想マシンに押下が反映されます。そのままAltを放すと、メニューが反応します。なので、それ以降のキー入力が仮想マシンに反映されません。再びAltを押下して放せば元に戻ります。
Altを押下した状態で他のキーを押下してから、どちらかのキーを放せば大丈夫?
- 314 :Artane. ◆1o3c8RYIzjU0 :2015/11/18(水) 03:02:57.96 .net
- 又リリースしました。
https://github.com/Artanejp/common_source_project-fm7/releases/tag/SNAPSHOT_20151117
>>311と>>313で指摘されてた問題に関しては、ほぼ解決できたと思います(但し、AUTO KEYで貼り付けると何故か小文字になっちゃう問題が積み残しで確認済み)
XPでも、大抵は動くようになってるはずです。ひょっとしたらダメなのがあるかも。と言う所までは持ち込めました。
とりあえず、おやすみなさい m(_ _)m
- 315 :umaiboux:2015/11/18(水) 21:52:00.64 .net
- >>314
MSX1とMSX2を試しました。Windows7の64bit、およびXPで特に問題なく起動しました。
私の不具合も含めて全部修正されているみたいですね。ありがとうございます。
Copy/Paste、MSX1とMSX2では半角アルファベットの大文字と小文字はきちんと区別されています。ただし、改行は無視されます。
ちなみに武田さんのバイナリだと、2015/10/27版では改行が無視されます。2015/10/31版では改行が反映されます。
ファイルをオープンするようなダイアログでキー入力した場合、20151114版ではダイアログの操作になったけど20151117版では仮想マシンへのキー入力になる。という違いがありますね。
- 316 :武田 ◆bnZpPXJze51u :2015/11/18(水) 23:33:22.52 .net
- >但し、AUTO KEYで貼り付けると何故か小文字になっちゃう問題が積み残しで確認済み
こちらは、起動時のCAPS LOCKの状態依存です。
SHIFT+アルファベットで大文字になるか小文字になるかは、
USE_AUTO_KEY_CAPSを宣言するか否かで指定できるようになっています。
大文字小文字の区別がない機種ではUSE_AUTO_KEY_NO_CAPSを宣言します。
詳細はwin32_input.cppのEMU::start_auto_key()をご参照ください。
- 317 :武田 ◆bnZpPXJze51u :2015/11/18(水) 23:40:38.16 .net
- 今晩の更新で、vm::get_tape_ptr()とvm::get_tape_play()を取り込みます。
なお、他の関数との名前空間の兼ね合いで、vm::tape_position()と
vm::tape_playing()という名前にさせていただきました。
vm::tape_recording()もついでに追加しています。
これらの関数は、USE_TAPEが宣言されていて、
TAPE_BINARY_ONLYが宣言されていない機種では実装が必要です。
要は、DATARECクラスを使って、テープの波形を扱う機種ですね。
なお、TAPE_BINARY_ONLYは、MULTI8やPC-8801みたいにバイナリを
直接I/Oで読み書きするような機種で宣言しています。
- 318 :武田 ◆bnZpPXJze51u :2015/11/18(水) 23:48:35.46 .net
- ついでに気になった点について。
_s()な文字列関数ですが、出来ればそのままにしておいて頂ければと思います。
VC++以外向けに、common.cpp/common.hに代替関数も用意していますので、
実用的には問題ないかと思います。
あと一部クラスでmin/maxを宣言していますが、common.h内での宣言で
何か問題がありましたでしょうか?
- 319 :武田 ◆bnZpPXJze51u :2015/11/18(水) 23:54:40.90 .net
- 細かい修正ですが、マルチバンクなD88イメージを開いたときに、
イメージを開いたまま(つまりバク選択のメニューを残したまま)
ディスクを抜くことができるようにしました。
バンクの一番おけつに、0: (Disk Ejected)が追加されていますので、
これを選択してください。
従来はイメージを閉じる必要がありましたので、
いったんディスクを抜いて、それから他のバンクを選択する操作が
しにくい問題がありました。
(イメージを閉じて開きなおすと、最初のバンクが挿入されてしまう)
なお、従来でも、違うバンクを選択した場合、内部的には
0.5秒(だったかな?)程度はディスクを抜いた状態を維持して、
それから新しいバンクを挿入するようになっていましたので、
仮想マシン上で動いているプログラムが、ディスクの交換に
気付かないということはないようになっています。
- 320 :武田 ◆bnZpPXJze51u :2015/11/20(金) 00:29:13.21 .net
- >Artane.さん
EMUクラスをもりっと整理することを考えてます。
main側とVMクラス側のインタフェース周りと、
画面周りやサウンド周りや入力周りの汎用的な実装と、
上記のOSまたはライブラリ依存な実装を整理・分離して、
QtやSDL対応、描画周りのOpenGL対応などを実装しやすくしたいなあと。
作業に取り掛かれるのがいつになるのかわかりませんが、
そう遠くない将来(年内または年度内?)にはと思います。
- 321 :Artane. ◆1o3c8RYIzjU0 :2015/11/20(金) 01:58:01.06 .net
- >>320
お疲れ様です。
改変の件、了解しました。
# 今、最新版を取り込んだ物をビルドしています。
- 322 :Artane. ◆1o3c8RYIzjU0 :2015/11/20(金) 16:59:00.72 .net
- 11/18版を反映したリリースかけました。
https://github.com/Artanejp/common_source_project-fm7/releases/tag/SNAPSHOT_20151120
>>318
>_s()な文字列関数ですが、出来ればそのままにしておいて頂ければと思います。
>VC++以外向けに、common.cpp/common.hに代替関数も用意していますので、
>実用的には問題ないかと思います。
XPのヴァージョンによっては*_s()な関数がない。とエラー吐いて終わるようです。大半は解決できましたが。
>あと一部クラスでmin/maxを宣言していますが、common.h内での宣言で何か問題がありましたでしょうか?
あの定義だとLinux等ではよくてもwindows向けのバイナリを作ってるMinGWだとエラーになります。
基本的に、gccの場合は(そして、多分LLVM CLANGでも)関数とdefineを厳密に分けていて、
・#ifndefで関数や変数型が定義されてるかどうかを調べようとしてもスルーされるので、型衝突を起こす
・#defineで関数的なマクロを定義した場合、既存の関数があるとオーバライド出来ない。
と言う動作をしています。
なので、
・typedef fooについては、結局コンパイラやOS環境をコンパイラから知らせてくる定数の#ifdefで切り分けて行く
・min/maxは(C++のオーバライドを悪用して) static inline intで定義する→common.hに纏めました。が、型検証が厳密なので、一部のデバイスではキャストしています。
と言う形になりますね。
現状、私の書いたのだとcommon.hとemu.hがかなり煩雑になってるので、(切り分けが容易な)common.hはcommon_(os名).hを別に定義してcommon.hから#includeするようにしたほうがいいかも知れません。未だ着手してないですが。
- 323 :Artane. ◆1o3c8RYIzjU0 :2015/11/22(日) 10:36:52.29 .net
- >>武田さんはじめCommon Source Code Projectの開発者の皆さん
幾つか、今の時点で思いつく希望事項を書いておきます。
・EMU::draw_screen()とその他のEmuの関数や変数が非同期で動く可能性を考慮して頂けるとありがたいです。
何を言ってるかというと、draw_screen()の部分はリアルCPU時間を結構喰うということと、実際にテクスチャやサーフェースに書き込むという事もあって独立したスレッドにしてエミュレーション本体の時間を稼ぐことが可能です。
当然そうなると仮想マシンのVRAM等の書き込みと非同期になるので、V/H SYNCを必要とする場合は、VBLANK期間に突入した瞬間にバッファにコピーして、そこからレンダリングしてやるように用意してやる必要が出ます。
vm/fm7/の display.cpp と vram.cpp・特にdisplay.cppのevent_callback()関数や、土曜未明に私のGITHUBにcommitしたx1/display.cppの変更部分を参考にして頂けると幸いです。
- 324 :Artane. ◆1o3c8RYIzjU0 :2015/11/22(日) 10:59:20.91 .net
- つづき
・エミュレーションの状況を画像や動画で記録するときに、EMU::を廻してるスレッド側からコールバックを登録するようなフレームワークがあると助かるのですが…
void foo(uint frame_number, void *data, int bytes)みたいな感じの関数ですね。
これとToolKitのキューイング機能を使うことで、音声・動画の記録や画像のスナップショットを、非同期かつOS非依存でなおかつスレッドセーフに出来ます。
# で、キューを読む先以降をOS/ミドルウェア依存にする。
・最近のグラフィック周りはDirectXやOpenGLにせよ、描画ミドルウェア側での拡大縮小がサポートされています。
なので、今のようにdraw_screen()等で書き込み画面サイズを固定して、draw_screen()側でライン補間やフィルタリング・回転をするよりも、
何らかの方法で、ミドルウェアのレンダラ側が現在のエミュ側の画面サイズと仮想VRAMアドレスをQueryして、後はミドルウェア(と言うかレンダラ)に
まる投げしちゃうほうがいい場合が大半だと思います。
ここら辺は、Qt版で限定的ですが先行対応しています(エミュ側の仮想VRAM構造に手を突っ込まない形で)。
- 325 :武田 ◆bnZpPXJze51u :2015/11/22(日) 19:42:50.41 .net
- draw_screenの非同期化はちょっとどうかなあと。
実機でも、実時間の経過と同期してスキャンライン毎にVRAMの内容を
CRTに送り込んで画面が表示されている訳で。
エミュレータでも、例えばX1とかMZ-700みたいに、スキャンライン毎に
VRAMの内容やパレットが変わるソフトがある機種では、
event_vlineで1スキャンライン分の画像生成をしていて、
draw_screen()はその結果を取りまとめているだけだったりします。
- 326 :武田 ◆bnZpPXJze51u :2015/11/22(日) 19:46:01.15 .net
- もし非同期化してしまうと、draw_screen()で描画をしている間に、
描画する対象の仮想マシンの対象は刻々と変化してしまいますので、
1画面の中に、複数のフレームの状態が混在してしまうような
変なことになってしまうんじゃないかと思います。
そうならないようにするには、結局フレームの先頭かおけつかで
描画にかかわる内部状態をどこかにストアして、そちらを使って
非同期描画ということになりますが…
そこまでするほど、現状の描画処理は重いかなあというのが本音です。
- 327 :武田 ◆bnZpPXJze51u :2015/11/22(日) 19:58:24.31 .net
- >VBLANK期間に突入した瞬間にバッファにコピーして、そこからレンダリングしてやるように用意してやる必要が出ます。
あ、この辺は織り込み済みでのご提案ですね。
んー、ちょっと考えさせてください。
draw_screen()は単にVRAMやパレットなどの状態をストアするだけの
トリガにして、それとは別に、別スレッドから呼ばれる関数で
ストアした状態を描画する、といった感じでしょうか。
すべての仮想マシンがそのインタフェースをサポートすべき、
となると困ってしまいますが、FM7など特定の仮想マシンで、
現状のやり方と両立できる形であれば、あり得るかなと思います。
- 328 :武田 ◆bnZpPXJze51u :2015/11/22(日) 20:04:57.79 .net
- >>324
こちらのご提案は、>>320の結果を見て頂いてからと思います。
実装ははじめたのですが、ちょっと時間がかかるかもです。
年内にもう1つくらい新機種(EX-80かFM16βかJR-200辺り?)を
やりたいので、そちらの工数との兼ね合いになりそうです。
- 329 :Artane. ◆1o3c8RYIzjU0 :2015/11/23(月) 16:03:47.66 .net
- >>327
>draw_screen()は単にVRAMやパレットなどの状態をストアするだけの
>トリガにして、それとは別に、別スレッドから呼ばれる関数で
>ストアした状態を描画する、といった感じでしょうか。
基本的にはそういうことです。
私がコードを読んできての解釈ですが、
・VM内部の、例えばDISPLAYクラスがVM内VRAMへの書き込みを行う
・VM::draw_screen()は、VM内VRAM等のデータを、表示側が解釈できるデータ=パックドピクセルの仮想VRAMに書き換える
・(武田さんのだと)win32_screen.cppで表示
と言う流れだと思います。
VMとEMUの構造もあって、リアルタイム性が保証されるにはそれなりのマシンパワーが要求される所で、
とはいえ、(低クロックであっても)マルチコアもしくはマルチスレッドのCPUが普通になってきてますから、構造を変えなくても分離できるところは積極的に別スレッドに追いだそうと言う話です。
>すべての仮想マシンがそのインタフェースをサポートすべき、
>となると困ってしまいますが、FM7など特定の仮想マシンで、
>現状のやり方と両立できる形であれば、あり得るかなと思います。
全ての仮想マシンでは適用はいらないと思います。
例えばX1のPCG/CGのようにVSYNCやHSYNCに同期してパックドピクセル化をやるようなものは、多重バッファが必要になると思います。(VSYNC/HSYNCのタイミングで裏VRAMに転送する)
未だコードを読んでないのですが、ひょっとしたらスプライトを実装してるマシンでは必要になるかも知れないですね。
- 330 :ナイコンさん:2015/11/24(火) 01:19:10.91 .net
- 98x1でもタイマーでパレット切り替えて空のグラデを描画しているゲームがあったりラインごとにパレットを切り替えて多色表示するプログラムがかつてありましたね
コード未見ですが実記でもCRTでしか使えない特殊画面モードの再現まで考えるといろいろと難しそうですね
(GDCの設定いじるとリフレッシュレート100Hz超とか出せましたし)
- 331 :ナイコンさん:2015/11/24(火) 02:25:39.04 .net
- >>330
ほう。結構いろいろ出来るんだな
- 332 :ナイコンさん:2015/11/25(水) 13:57:42.36 .net
- ドラッケンの41色とか売りにしてたね
- 333 :ナイコンさん:2015/11/25(水) 14:40:17.78 .net
- ドラッケン好きだったな
- 334 :武田 ◆bnZpPXJze51u :2015/11/27(金) 01:26:30.82 .net
- >Artane.さん
>>320の件の作業中のファイルを以下にアップしました。
http://homepage3.nifty.com/takeda-toshiya/00tmp/source_osd.zip
OSDクラスを新規追加して、EMUクラス中のOS依存のコードを
OSDクラスの方に移動しています。
pc8801maとmz2500とpx7のみビルドが通るようになってます。
まだまだ修正が入りますので、現時点ではご参考程度ということで、
取り込みは暫くお待ちください。
- 335 :ナイコンさん:2015/11/27(金) 02:03:42.27 .net
- >>334
ありがとうございます。
私の方も別件でぐちゃぐちゃしてるので、当面は暫定的にしか動けないと思いますのでお気遣いなく。
- 336 :武田 ◆bnZpPXJze51u :2015/11/28(土) 02:37:03.82 .net
- 全機種でビルドが通るようになりました。
テストをして特に問題なければ、今後のリリース用のソースにします。
http://homepage3.nifty.com/takeda-toshiya/00tmp/source_osd.zip
EMUクラスから、Windows依存の処理を一掃しました。
具体的な環境依存の処理はOSDクラスにまとめてありますので、
これをQtやSDLなど環境ごとに移植するという形になります。
総レス数 1000
355 KB
新着レスの表示
掲示板に戻る
全部
前100
次100
最新50
read.cgi ver.24052200