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/

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なんですぜ・・・ｗ
X1（俺)、88、MSX、98のユーザー同士で各家巡回して
あぁ、懐かしい・・・
その頃、時代的に巡回先でベーマガのプログラム10行交代とかで入力してましたからねぇ
その後、自分はDXだけどほとんどX68使ってましたｗ

あ、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
いや、俺はいいですｗ
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で１スキャンライン分の画像生成をしていて、
draw_screen()はその結果を取りまとめているだけだったりします。

326 ：武田 ◆bnZpPXJze51u ：2015/11/22(日) 19:46:01.15 .net

もし非同期化してしまうと、draw_screen()で描画をしている間に、
描画する対象の仮想マシンの対象は刻々と変化してしまいますので、
１画面の中に、複数のフレームの状態が混在してしまうような
変なことになってしまうんじゃないかと思います。

そうならないようにするには、結局フレームの先頭かおけつかで
描画にかかわる内部状態をどこかにストアして、そちらを使って
非同期描画ということになりますが…
そこまでするほど、現状の描画処理は重いかなあというのが本音です。

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の結果を見て頂いてからと思います。
実装ははじめたのですが、ちょっと時間がかかるかもです。

年内にもう１つくらい新機種（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など環境ごとに移植するという形になります。

337 ：片山博文MZ ◆T6xkBnTXz7B0 ：2015/11/29(日) 12:30:42.71 .net

「FM音源をあやつって正しく音を出したい」
OpenAL+ALUTと、ciscさんのFM音源エミュレータ
「FM Sound Generator」を使って、正しく音を出したい。

https://github.com/katahiromz/fmgengen2/blob/master/sample.cpp
https://github.com/katahiromz/fmgengen2

おかしな音が出ます。たぶんFM音源の使い方が間違っています。
修正方法を教えて下さい。よろしくお願いします。

338 ：片山博文MZ ◆T6xkBnTXz7B0 ：2015/11/29(日) 14:12:27.44 .net

たすけて

339 ：ナイコンさん：2015/11/29(日) 19:29:19.78 .net

>>337,338
マルチポストやめようよ

http://peace.2ch.net/test/read.cgi/tech/1181782128/l50
http://hello.2ch.net/test/read.cgi/i4004/1430836648/
https://teratail.com/questions/21294

340 ：片山博文MZ ◆T6xkBnTXz7B0 ：2015/11/29(日) 20:27:27.98 .net

ム板へ移動します。
http://peace.2ch.net/test/read.cgi/tech/1181782128/

341 ：Artane. ◆1o3c8RYIzjU0 ：2015/11/29(日) 20:41:07.12 .net

>>336
お疲れさまです。
この数日ばたばたしてて、今やっとDL出来ました( ；∀；)
これから、中身を見ていきますです m(_ _)m

342 ：武田 ◆bnZpPXJze51u ：2015/11/30(月) 20:26:08.16 .net

>>341
再アップしました。
common/config/fileio周りを弄っています。
この辺りはなるたけ環境によらず纏めておきたいなあと。

Artane.さんのcommon.hの型宣言も、極力取り込んでます。
*_s()な文字列関数は、my_*_s()という名前にして、
VC++以外はcommon.cppの方で標準関数に置き替える実装にしました。
tchar周りの#defineも弄ってます。

config.cppのiniファイルの読み書きのAPIもcommonの方に移しました。
Artane.さんの実装だとQt周り前提になっていますが、
可能でしたらStandardなC/C++にして頂けると取り込みやすいです。
(XM8のようにSDLベースの実装もありますので)
確かGPLなini parserが公開されていたと思うので、
その辺をそのまま組み込んでしまうのが簡単かもしれません。

343 ：片山博文MZ ◆T6xkBnTXz7B0 ：2015/11/30(月) 23:10:57.81 .net

>>338
他力を借りて解決しました。
http://katahiromz.bbs.fc2.com/reply/10466094/34/

344 ：ナイコンさん：2015/11/30(月) 23:43:28.18 .net

ところでアル種さんって読むの？

345 ：Artane. ◆1o3c8RYIzjU0 ：2015/12/01(火) 13:09:20.87 .net

>>342

お疲れ様です。
作業内容了解しました。
とりあえず、必要最小限のマージをした上でQt依存部分を共通部から追い出していきますね。
デバッガの対応は少し後になりそうですが。

>>344
アーテンですね(^_^;
古いハンドルネームだから(^_^;

346 ：Artane. ◆1o3c8RYIzjU0 ：2015/12/01(火) 19:08:35.97 .net

とりあえず、Qt (多分Windows以外）で最低限のビルドが可能なようにしました。
githubのbabe250a86799b3b8bfd6f221239e2cf2dfc7ba4で。
・デバッガを統合できてません
・幾つかの関数をEMUに追加してありますが、#if defined(_USE_QT)で括ってて、
尚且つ関数の場合はかなりがQtのオブジェクト間通信に置き換わります。
　置き換えられない関数は数えるほどになる…筈。
・とりあえず、Get/WritePrivateProfile*()はEvilな事をやってラッパをでっち上げました。
　もう少しEvilさをなくしたい。
・source/src/*.cpp から、Qt依存部分を(emu.cpp内で他のクラスとの兼ね合いでなくせないもの以外は）たぶんすべてなくしました(^_^;
　基本的に、C++の標準ライブラリに置き換えた。

現状、FM77AV40EXがビルドできて基本的な動作はなんとかなってます。が、バグが潜んでると思うので排除していきます(；´Д｀)
FM7系以外は未だビルド定義が不十分です(；´Д｀)
でも、疲れたよパトラッシュ…(´・ω・｀)

347 ：Artane. ◆1o3c8RYIzjU0 ：2015/12/01(火) 22:59:37.24 .net

BABBAGE2ndやBMJr,MASTER SYSTEMなど幾つかのVMが動くようにしましたが、X1系が起動時にスイッチをゆっくり入れろと出てきますね。
githubの d89562f93404aa069216098692567cf9b41844ce

348 ：ナイコンさん：2015/12/02(水) 03:10:44.83 .net

あぁ、X1の例の表示かぁ...

349 ：武田 ◆bnZpPXJze51u ：2015/12/06(日) 23:56:03.86 .net

>>347
お疲れ様です。
こちらの大規模変更でお手数おかけして申し訳ないです。

１週間の長期出張から帰ってきました。
ぼちぼち取り込み作業に取り掛かります。

350 ：Artane. ◆1o3c8RYIzjU0 ：2015/12/10(木) 19:35:59.47 .net

Linux版 Common Source Code Projectリリースしました
http://github.com/Artanejp/common_source_project-fm7/releases/tag/SNAPSHOT_20151210
未だ、Windowsはビルドすら出来てませんが (^_^;

351 ：ナイコンさん：2015/12/12(土) 17:47:56.96 .net

テスト

352 ：Artane. ◆1o3c8RYIzjU0 ：2015/12/12(土) 19:56:44.07 .net

>>348
なんとか解決できました(；´Д｀)

353 ：武田 ◆bnZpPXJze51u ：2015/12/16(水) 00:46:38.13 .net

>>350
お疲れ様です。
今晩のリリースで、2015/12/13のコミットまで取り込みました。

各VMのNOT,ANDクラスのインスタンス名をnot,and以外に変更しました。
（変数名の名前空間の都合で、Artane.さんとは違う名前にしています、すみません）
また、min/maxの型キャストを取り込みました。
ld700.cpp, mc6809.cpp, upd765a.cppをMSVC以外向けに修正しました。

config, common, fileioをMSVC以外向けに修正しました。
_WIN32と_MSC_VERの使い分けが不適切だった箇所を修正しました。
common.hでboolean, byteの型の定義を追加しました。
なお、common.cppのget_file_path_without_extension()は、
ファイル名のみ取り出すのではなく、フルパス中の拡張子のみ取り除く関数です。

win32では実際には使っていませんが、emu/osdのlock_vm(), unlock_vm()を
ネストする場合を想定した実装にしてみました。
また、深いネストから一気に抜けるために、force_unlock_vm()を追加しました。

354 ：武田 ◆bnZpPXJze51u ：2015/12/16(水) 00:48:23.12 .net

そろそろ、一旦ソースの同期を取れないかと思っています。

特に各機種の仮想マシン周りのソースで、意味のない差分が発生しています。
変数の型やmin/maxなど、common.hで解決ついている（筈？の）問題の修正とか、
#ifdef _MSC_VERで括られている__assume(0);の削除とか、
コメントアウトされて、もう元に戻されるあてがなさそうな過去の変更とか、
空白や改行位置などの単純な差違とか、etc,etc

＃勿論、改行コードの違いは現状のままでいいかと思います。

お時間に余裕があるときで構いませんので、この辺りの作業も少しずつ
進めて頂けますとうれしいです。
DIFFで差分も取りやすくなりますし、お互いのバイナリで挙動が違う、
という問題も、より発生しにくくなるかと思います。

ソースの同期のために、私の方で必要な変更がありましたらお知らせください。
common/emu辺りも、出来るだけArtane.さんにとって統合に抵抗がないような形で、
かつ出来るだけシンプルに纏めていければと考えております。

355 ：武田 ◆bnZpPXJze51u ：2015/12/16(水) 00:51:43.51 .net

eFM7/77/77AVですが、set_vm_screen_size()の使い方を修正しています。

第1,2引数はVMの描画画素数、
第3,4引数は表示するときの画面サイズ（アスペクト比込み）、
第5,6引数はウィンドウサイズの基準サイズ、
となります。

元のコードだと、ウィンドウが横長になったり小さくなったりするので、
第3〜6の値を変更しています。
また、display_modeの値と、set_vm_screen_size()で指定した画面サイズの
整合性が取れない場合があるので、draw_screen()の処理内で、
毎回set_vm_screen_size()するように修正しました。

＃数日ほど2chに書き込めなかったため、自サイトの方に書きましたが、
＃念のためこちらでも投稿しておきます。

356 ：Artane. ◆1o3c8RYIzjU0 ：2015/12/16(水) 06:42:52.69 .net

>>354
お疲れ様です。
とりあえず、少しお時間下さい…同期を取るのにはコードを見直さないと拙い気がしますので。
確かにcommonやemuがカオスになりつつありますし、対策は打たないといけないですね。
基本的に、FM-7の方には当分これ以上は手を入れない（バグフィックスや微調整とFM-8対応を除く）つもりではいますので、
色々と考えて行きたいと思います。
問題の叩くAPIが違う部分は、極力武田さんの方に合わせます。

確実に欲しい構造としては、
・音を出すデバイスについて、write_signal()で左右の音量を調整するAPIをデフォルトにする。
・VM/OSDから、EMUに任意のenum型のコマンド（システムコール）とvoid *型かva_list型での引数を打てるようにするAPIを構築する。
と言う所でしょうか。　

後は、現状最新のコミットにあるように、デバッガに関して、スレッド立ち上げてループ廻しても廻さなくても出来るようにして頂けると非常に助かります。
と言うのも、マルチスレッドかつイベントドリブンのUIと、今のデバッガの構造って相性悪いんですよね。
コマンドインタプリタ本体とコマンドをコンソール等から受け取る部分が分離されてると、問題がほぼ解決出来ますので。

357 ：武田 ◆bnZpPXJze51u ：2015/12/17(木) 00:49:58.62 .net

ソースの同期の件ですが、ちょっとお待ちください。
OS依存処理のうち、エミュレーションに関係ないサービス的なものを、
EMU/OSDからCOMMONに移すことを含めて、
ちょっと大規模なソースの整理を先にやりたいと思います。

ソースの同期については、Artane.さんに変更をお願いする点も
多くなるかと思いますので、先に方針の摺合せを出来ればと。

358 ：武田 ◆bnZpPXJze51u ：2015/12/17(木) 00:51:38.24 .net

原則として、VMクラス内では、Win32かQtかSDLかで処理を分けないようにします。

byteやbooleanなど変数の型の宣言、TRUE/FALSEなど値の宣言、
ld700.cpp内のstricmp()の置き換えなどは、common.cpp/hで吸収します。

例えば、tms9918a.cppのdraw_screen()で、_USE_QTの場合はスーパーインポーズの処理を
スキップするようになっていますが、こういったケースでは、
emu->osd_qt->get_video_buffer()の処理を空にするなど、OSDクラスで吸収してください。

＃OPN(A)/OPMのmamefm.dllのサポートは例外として残っちゃいますが（苦笑）

EMUクラスも、例えばEMU::EMU()のように、環境毎にインタフェースが変わったり、
特定環境向けのインタフェースが（#ifdefで括って）用意されているのはOKですが、
変数（host_cpusなど）や具体的な処理は、OSDクラスの方で実装してください。
環境依存の#includeや#defineなども、emu.hではなくosd.hで宣言してください。

359 ：武田 ◆bnZpPXJze51u ：2015/12/17(木) 00:52:52.96 .net

VM::tape_position(), VM::set_disk_protected()は、USE_TAPE, USE_FD1が
宣言されていれば、標準で実装するようにしました。
USE_TAPE_PTR, USE_DISK_WRITE_PROTECTは廃止の方向でご検討ください。

SCREEN_WIDTH/HEIGHT_ASPECT, WINDOW_WIDTH/HEIGHTが#ifndefの場合に、
SCREEN_WIDTH/HEIGHTと同じ値に#defineする処理は、vm.h内でやってますので、
各仮想マシンの(vm name).hで宣言しなくてもOKです。

実解像度640x400を640x480で表示する件については、dot by dotとアスペクト比と、
どちらを重視するか、人によって好みが分かれるところです。
VM側で#define SCREEN_HEIGHT_ASPECT 480を宣言するやり方ではなく、
configにオプションを追加して、EMU/OSD側で処理するようにしたいと思いますので、
その辺の宣言も廃止の方向でお願いします。

360 ：武田 ◆bnZpPXJze51u ：2015/12/17(木) 00:54:10.54 .net

サウンドのボリューム調整は、write_signal()ではなく、専用のvirtual関数を用意します。
近々ひな形を用意するので、しばらくお待ちください。

なお、データレコーダの音ですが、PC-88など、SIOでバイナリデータを読み書きする
タイプについては取り込みを保留とさせてください。
DATARECクラスでt88ファイルから音の波形を生成して、それをI8251クラスや
Z80SIOクラスがガチンコでシリアルデータとして解釈するのが本筋かなと思います。
（実際にやるのは遠い将来ですが）

デバッガについてはちょっとイメージがわかないです。
VC++向けのコードもArtane.さんに弄って頂いて、それをこちらで取り込む形で
作業するのがいいかもしれません。

361 ：武田 ◆bnZpPXJze51u ：2015/12/17(木) 01:03:32.49 .net

細かい要望として、共有部分では、関数名などの名前空間は既存のコードに
あわせていただけると嬉しいかなーと思います。
（setMousePointer() -> set_mouse_pointer()など）

後、ソースの全比較をして、個別に気になった点ですが。

disk.cppの、special diskの判定部分が、diff/patchを機械的に
あてはめた結果か、変なことになっているみたいです。
また、get_track_size()ですが、ディスクが抜けた状態なのに、
挿入されているディスクの種類をチェックしているのは変かなと。

こういったことに気付く機会にもなるので、更新時の差分だけ
見るのではなく、時々はお互いのソースの全比較をするのも
必要ではないかなあと思います。
そのときの作業の手間を省くためにも、有意でないソースの違いは
なるたけ同期して無くしておきたいなあというのが、今回のお願いの
きっかけだったりします。

362 ：武田 ◆bnZpPXJze51u ：2015/12/17(木) 01:10:32.44 .net

取り敢えず、ソースの同期の作業については、適当なタイミングで、

私の方で（有意でない差分が発生している）対象のソース一覧を用意して、
Artane.さんの方で、そのまま取り込みが可能か判断をして頂く、

という形で進められればと思います。

363 ：Artane. ◆1o3c8RYIzjU0 ：2015/12/17(木) 13:17:43.44 .net

>>357
よろしくお願いします(＾ω＾)
場合によっては私の方のソースコードにあるアドレスまでメール下さいませm(_ _)m

364 ：ナイコンさん：2015/12/17(木) 21:45:04.91 .net

新しい機種が増えるたびに vm/vm.h や res/resource.h に追記しないといけないのは面倒っぽい気もするのですが
うまい解決法は無いものですかね

365 ：Artane. ◆1o3c8RYIzjU0 ：2015/12/17(木) 22:58:57.42 .net

>>364
スクリプト使うとか…暇見て試してみますわ。

366 ：武田 ◆bnZpPXJze51u ：2015/12/17(木) 23:29:43.10 .net

面倒ってほど機種数が増えるかなあ（苦笑）
というか、common source code projectにかかわってくださる開発者が
そんなに増えるかなあ…増えると嬉しいなあ。

今晩の更新で、application_path(), bios_path(), create_date_file_name(),
get_host_time()を、EMU/OSDクラスからcommon.cpp/hに移しました。

OS依存の処理だけど、エミュレーションに関係ない処理を、
EMUクラス経由で実行するのがどうにも違和感があったのと、
EMUクラスが初期化される前にiniファイルのパスを取得するために、
winmainの方でもapplication_pathを取得しているのがアホらしくって。

で、こういうインフラを変更すると、全仮想マシン側でも修正が必要で、
大量のソースに変更が入って、Artane.さんに迷惑をお掛けする、と。

こっちの方が余程面倒ですよね、ごめんなさいです。

367 ：武田 ◆bnZpPXJze51u ：2015/12/17(木) 23:36:03.47 .net

今晩の更新で、というか、今バイナリのビルド中なので、
今晩予定の更新で、というのが正しいですね（を

そういえば、プリンタ周りも現在はEMU/OSDクラスに入れていますが、
やっぱりVM側に戻すことになりそうです。

仮想プリンタで、ビットマップやフォント作ったり、という処理が入るのと、
プリンタDLLをとっかえひっかえ、とか考えるとOSDっぽいんだけど。
でも、プリンタというマシンのエミュレーションをすると考えると、
やっぱりVM側だよなあと。

ビットマップの生成やファイルへの出力とかフォントの生成とか、
そういうサービスをEMU/OSD経由で呼び出せればいいんだし、
DLLを使うのも、mamefm.dllという前例があるんだし、という感じで。

368 ：Artane. ◆1o3c8RYIzjU0 ：2015/12/18(金) 19:50:42.55 .net

>>358-362
大まかに変更を取り込みました。
まだ、構造的に差異が出てきてそれを潰す作業が続きそうですが…
最低限、FM-7系だけはビルドできるようにしておきました
commit 26f3ced80a6b679371975e68318d3348697e2fe6
disk.cppの重複部分はなくしました。

但し、以下は未だ残してあります（変更要件が固まった時に移行する）。
・音量をwrite_signal()で調整する機能
・ダミーデバイスでLEDを表示できるようにするDUMMYDEVICE クラス（要は、入出力の終端を表現している訳です）
他にもあった気がしますが、まぁ、後からやっていきます（かなり頭が疲れてる）。
とりあえず、ソースコードをきちんと見直していくにも、一定程度動かせないと捗らないので…(^_^;

369 ：Artane. ◆1o3c8RYIzjU0 ：2015/12/18(金) 20:00:33.69 .net

>>366
>で、こういうインフラを変更すると、全仮想マシン側でも修正が必要で、
>大量のソースに変更が入って、Artane.さんに迷惑をお掛けする、と。
>こっちの方が余程面倒ですよね、ごめんなさいです。

いえいえ全然…最終的にそういうのはお互い様というか、私の方でも色々使いやすくすると称して訳のわからない機能を突っ込んだりしてる訳ですから…

>>367
プリンターの件、了解です。
DLLを使う前提にするか、どうするかはおいおい考えていきましょう。

>>364-365
この件ですが、仮想クラスで（要は殆どの関数をvirtualで定義しちゃう）VMを定義してメタクラスとして、
それぞれの仮想マシンの実体（？）は、そのメタクラスを継承するクラスにしたらどうでしょうね。
↓みたいな感じ
class METAVM → class FOO : public METAVM
で、METAVMには必要最低限かつ多くのVMで共通化出来そうなVM機能を入れる。
# 但し、こうしておくと、gnu ldでのリンクが厄介になりそうな気がしなくもないのですが…はてさて。

## リンカでの.aファイルの相互依存関係の解決ってなんでこんなややこしいんだか…
## ここだけは、VCが羨ましいです(；´Д｀)

370 ：ナイコンさん：2015/12/21(月) 14:54:48.29 .net

http://akiba-pc.watch.impress.co.jp/docs/wakiba/find/20151221_736240.html
http://akiba-pc.watch.impress.co.jp/img/ah/docs/736/240/mx68000xvihd1.jpg
http://akiba-pc.watch.impress.co.jp/img/ah/docs/736/240/mx68000xvihd5.jpg
http://akiba-pc.watch.impress.co.jp/img/ah/docs/736/240/mx68000xvihd3.jpg
http://akiba-pc.watch.impress.co.jp/img/ah/docs/736/240/mx68000xvihd7.jpg
http://akiba-pc.watch.impress.co.jp/img/ah/docs/736/240/mx68000xvihd8.jpg
http://akiba-pc.watch.impress.co.jp/img/ah/docs/736/240/mx68000xvihd9.jpg

保存状態良好でワラタ

371 ：ナイコンさん：2015/12/21(月) 15:23:40.47 .net

キーボード別売りという足元見てんなぁ

372 ：ナイコンさん：2015/12/21(月) 15:36:54.92 .net

おつかれさまです。
>>368続き
12/17のヴァージョンと、ほぼ同期をとりました。
今の所、CMakeの同期を取ってるのがX1とかFM7とかEX80とかBABBAge2nd程度です。

>>360
>サウンドのボリューム調整は、write_signal()ではなく、専用のvirtual関数を用意します。
>近々ひな形を用意するので、しばらくお待ちください。
わかりました。

雛形が出来しだい、移行していきますね。

>なお、データレコーダの音ですが、PC-88など、SIOでバイナリデータを読み書きするタイプについては取り込みを保留とさせてください。
>DATARECクラスでt88ファイルから音の波形を生成して、それをI8251クラスやZ80SIOクラスがガチンコでシリアルデータとして解釈するのが本筋かなと思います。

了解です。
基本的にこちらでもコメントアウトしておきました。

現状は、githubの a3901d1d33172ad63008d79dcc2cbc1d734c1c1aです。
幾つか独自の変更点を>>368で書いた事以外に残してあります。

・X1でCG(PCG)とテキストVRAMをレンダリングするとき、
　1Lineごとにシャドー領域に仮レンダリングして、それを
　draw_screen()で合成するようにしてみた。
　→非同期描画モデルだと、PCG/文字が非常にちらつくので。
・PC8801では、ダミーCPUを登録してダミー側のクロックを落としている。
　→そうしないと、HOST CPU側のCPU使用量が跳ね上がるので、
　　なるべく落とすようにした。

373 ：Artane. ◆1o3c8RYIzjU0 ：2015/12/21(月) 15:46:46.46 .net

>>372 は私でした。
デバッガですが、私の側のsrc/debugger.cpp を参照願います。
　基では、debugger_thread()の中でデバッガの
コマンドインタプリタをスレッド立ちあげて廻してるのですが、
これを、コマンド処理部分をdebugger_command()に廻してます。（作業中）
こうする事で、Qtのようにイベントドリブンかつ元々マルチスレッド保障のUIからデバッガの
コマンドを呼び出すときに、
[Widget:テキスト入力イベント]→[デバッガ側受け皿]→[デバッガコマンド実行]→[VM側での解釈]→[Widget:入力待機]
と言う感じの流れでも動くようになります。
# と言うか、Widgetはテキスト入力イベントを投げたら、すぐに入力待機してリプライ文字列の表示待ちになりますが。

Qtでいろいろ管理してると、pthreadでのスレッド立ちあげ/終了と言うのは却って使い勝手が悪いのですね(^_^;
こういう流れは、コマンドコンソール上でデバッガ廻す分には*全く*要らないのですが、
GNU/Linuxや(多分)BSDなどのデスクトップ環境だと、別プロセスでターミナルを立ちあげて、
そこで何かやる。と言うのは却ってややこしいんですよね。mkfifoしてターミナル側でダミープログラム立ちあげて入出力任せて…みたいな。
# もしくは、ターミナルウイジェットを新しく作るか(；´Д｀)

374 ：Artane. ◆1o3c8RYIzjU0 ：2015/12/21(月) 22:42:13.41 .net

>>373のように書いてしまいましたが、撤回します(^_^;
なんとか、独立したスレッド内のループでデバッガ廻せるように出来ました。
もし、作業に取り掛かられていたら、お詫び申し上げます。＞武田さん

375 ：Artane. ◆1o3c8RYIzjU0 ：2015/12/22(火) 22:41:06.13 .net

Common Source Code Project のQt版、武田さんの12/17版を基に2015-12-22-1としてリリースしました。
https://github.com/Artanejp/common_source_project-fm7/releases/tag/SNAPSHOT_20151222
WindowsとLinux (AMD64)のバイナリへのリンクがあります。

376 ：武田 ◆bnZpPXJze51u ：2015/12/23(水) 01:25:33.72 .net

お疲れ様です。

統合を進める前に色々やっておこうということで、またモリッと書き換えてます（苦笑）
今回はUNICODEでビルドしたときの問題を色々修正しました。

プリンタ向けのEMU/OSDの実装も、今回で概ね一段落です。
基本的には、Win32のDIBSection,FONT,PENにラッパを被せただけです。
できれば年内に、MZ-1P17辺りを実装できればいいなと思っています。

377 ：武田 ◆bnZpPXJze51u ：2015/12/23(水) 01:26:40.66 .net

プリンタ向けのサービスの使い方はこんな感じです。

bitmap_t bitmap;
font_t font;
pen_t pen;

emu->create_bitmap(&bitmap, 64, 64, 255, 255, 255);
emu->create_font(&font, _T("Mincho"), 8, 16, false, false);
emu->create_pen(&pen, 3, 255, 0, 0);

emu->draw_line_to_bitmap(&bitmap, &pen, 63, 0, 0, 63);
emu->draw_text_to_bitmap(&bitmap, &font, 0, 0, _T("MZ太郎"), 6, 0, 0, 0);

emu->write_bitmap_to_file(&bitmap, _T("misoko.png"));

emu->release_pen(&pen);
emu->release_font(&font);
emu->release_bitmap(&bitmap);

378 ：ナイコンさん：2015/12/23(水) 15:33:59.31 .net

>377
昔のプリンターのような画像を出力しようと思ったら、小さい黒丸か塗りつぶした正方形のような描画が必要だと
思うのですが、それはpenとlineでやっちゃえ、ということでしょうか。
小さいfontで●や■を書くのは何か間違ってますよね。