PCエミュレーター統合スレッド Part6

古き良き、1970年代〜90年代のマイコンエミュレーター統合スレッドです。
基本、開発・人柱・新バージョンの報告や話題等で進行をお願いします
たまには上記の延長線上での脱線も可

※家庭用ゲーム機器は板違いです。（ぴゅう太はOK）
※ジェネレーターや其れに準ずる質問等はスレが荒れる原因になるので華麗にスルーして下さい
※上記の事柄に反応した場合その人も同じ池沼扱いされますので決して反応してはなりません
※このスレは如何にスルーできるか問われるスレですので肝に銘じておいて下さい
※禿しく空気読め

前スレ：PCエミュレーター統合スレッド Part5
http://ikura.2ch.net/test/read.cgi/i4004/1326469824/

QEMU/9821でWIN1.0〜WIN98まで動かしてみた。
http://www.nicovideo.jp/watch/sm20456675

外部描画フィルター整理
rpiフィルタを使えるdll添付

XM7Dash翼
ttp://www1.axfc.net/uploader/so/2851095
p:FD0D

>>3
乙です。何点か質問。

>明るさはSetFilterで後から調整も可能なのでマウスホイールで調整とか
対応してみたんだけどSetFilter呼ぶだけじゃダメだった。
まぁいろいろやってみる。

>hMainWnd代入タイミング(for w32_cfg.c:RestoreFrameWnd())
タイミングによってhMainWndがNULLの状態でRestoreFrameWnd()が呼ばれるケースが
ありえるってことかな。とりあえずNULL対策だけ入れた。

>TranslateAccelerator()以下のHWNDが無効のハンドルで呼ばれる場合がある
これって以前指摘されたときはdashも一応暫定対策入れてたけど、
本家側でOnDestroy()からはhMainWndをNULLにする処理が外され、
OnQuit()って関数が追加されてループからbreakするタイミングで
hMainWndをNULLにするようになったので
TranslateAccelerator()をNULLで呼ばなくなったと思って
暫定対策は消したんだけど、別のケースかな。

>>3
ちょっと気になっている点が…。
WtCalというフリーのデスクトップカレンダーソフトを使ってるんだけど、
このカレンダーソフトでデスクトップにカレンダーを描画した領域の
上に相当する所へDLLで描画すると、稀に書き損じる？ことがある。
ただし普通に描画されている状況で書き損じることはない。

一番簡単に症状を確認するには、
1.WtCalでカレンダーを表示しているところと重なるようにdashを実行
2.dashを最小化→最大化
3.dashのWindowメニューを表示(裏にカレンダーが表示されているところなら
　どれでもよい)→メニューを閉じるか隣のWindowメニューに移動
症状：カレンダーソフトのカレンダーと重なる箇所の画像が復帰しない。
※ただしエミュレータ側が常時画面を書き換えていれば大丈夫。
エミュレータ側で同じ画面が継続している状態でテストすると症状が確認しやすい。

ソフトの相性の問題なのか、カレンダーソフト側の問題なのか、
判断がつかなかったので、とりあえず報告。
個人的にはどうもカレンダーソフト側がなにかやってるようにもみえるんだけど、
DLLを使わない場合は発生しない問題なので、対策の手段はあるかもしれないかなと。
まぁ、どうしようもなさげであれば、相性の問題、ってことでFAでもOK。

おまけ。
デスクトップカレンダーはしののん氏のが一番使いやすくて、
WindowsXpの時まで使ってたんだけど、
Windows7にしたら何故か使えなくなっちゃったので、
いろいろ調べて一番似た使い方が出来るWtCalにしたんだ。

>>4-5
すみませんSetFilter修正してみました
無効ハンドルで呼ばれてもFALSE返ってくるだけだから放置でもいいかも
潰していくならウィンドウハンドル使うAPIの前に必ずチェック入れてみたり
書き損じはOnSizeの中とかでドローウィンドウ再描画で対処とかは

フイルタのみ再
ttp://www1.axfc.net/uploader/so/2853414
p:filter

ちゃんとテストしてんのかよ

>>7
すいませんぜんぜんてすとしてませんでちゅたしね

XM6でもrpi使えるかどうかのテスト含めてフィルタ更新追加

XM6+XM7dash
ttp://www1.axfc.net/uploader/so/2854427
p:filter

商売で作ってるんじゃないソフトで「テストしてるのかよ」とか…
個人が趣味で作ってるものに何「使ってやってる客」ぶってんだよ

うわあ

>>6
>SetFilter
処理後描画ウィンドウへWM_PAINT投げとけばOKですた。

>無効ハンドル
dashで追加したロジックにおける箇所は対応しときました。
本家からのロジックは本家に任せようかと…

>書き損じ(というか復帰し損じ)
OnSize()呼んでる訳じゃないので…、とりあえず調査した結果、
メニュー閉じるときWM_UNINITMENUPOPUPメッセージが飛んでくることがわかったんで、
このときに描画ウィンドウを再描画することに。
描画ウィンドウへWM_PAINT投げるのが一番適切なんだけど、
ソレだと一瞬書き損じてるのが見えちゃうんで、仕方なく直接OnPaint。
書き損じはなくなったんだけど、dashを終了したとき「書き損じてたはず」の領域だけ、
デスクトップにdashの描画ウィンドウの跡が残った。
…これはもう、カレンダーソフトとの相性としかいえないなｗ

>>9
乙です。また見てみるよー

>>9
dashでのみ確認。
○stretch.dll
×2xRpi.dll
○2xRpi+.dll
ですた。
2xRpi.dllも、>>6の時は動いてたんだけどな。
あ、2xRpi.dllも2xRpi+.dllも、同じプラグイン使ってる。

まだdash側の内部動作チェックはしてない。
なんかあればまたコメントしとく。

フィルタ修正しました

XM6+XM7dash東郷
ttp://www1.axfc.net/uploader/so/2855591
p:filter

>>13
乙です。
とりあえずどれも動作中。2xRpi.dllの問題も解決。

ところで復帰し損じ(+終了時の書き残し)の件、
2xRpi.dll, 2xRpi+.dllでは生じなかったので、
どうもstretch.dllだけの問題っぽい。
ま、stretch.dllでもWM_UNINITMENUPOPUPで再描画させとければ
イィんだけど(終了時除く)、とりあえず情報として一応報告。

終了時はInvalidateRect(NULL,NULL,TRUE);とかは

>>15
OnClose()のメインウインドウを一端消した直後でCALLすると消し損じる。
OnDestroy()のINIファイル書き込み後位まで待たないとダメっぽい。
ただここまで待ってCALLすると、明らかに消し残しが目に見えるｗので、
ちょっと…ねｗ

とりあえず、WM_UNINITMENUPOPUPの方も含めてデフォルトでは入れず、
XM7.iniにフラグ入れてONの時のみ処理するようにしとく。
さしあたり、WtCalってカレンダーソフト使ってなければ発生しない症状だしね。

追記
終了時の消し残しは、
XM7dash以外のソフトでも(エミュレータじゃなくても)発生した。
というわけで、あまり気にしない方がいいかもしれない。
一応>>16の対応は入れとくつもり…。

そういえば、dash V1.2L13, V2.9/V3.4L52aR130409のドキュメントには
>明るさはSetFilterで後から調整も可能なのでマウスホイールで調整とか
をネタに放り込んだマウスホイールで明るさ調整の件を書かなかったのでこちらへ。
・マウスホイール↑で明るく、↓で暗くなります。
マウスモード切替にホイールを設定していた場合は明るさ調整できません。
これはstrech.dll専用の機能であり汎用性がないので隠し機能ってとこで。

>>18
すばらっ
外部音源dllで動かないものはCreateせずにMixが呼ぶのに対応していないから
genpfmで音が変になるのはプリスケーラ変更に対応していないからでした
np2fmなんかも結局対応していないので動いても意味が無いけど
LoadMenuしたらDestroyMenuしたほうが良いかも

外部音源DLLセット
ttp://www1.axfc.net/uploader/so/2865336
p:9801

MZ-2000＋16bitボード
ttp://takeda-toshiya.seesaa.net/article/354697912.html

emuz-2000 tf 0.92.0のソースどっかにないですかねぇ。

>>19
乙です。

>genpfmで音が変になるのはプリスケーラ変更に対応していないからでした
なるほどー。そこまではGetCapsでとれませんよねぇ。

>LoadMenuしたらDestroyMenuしたほうが良いかも
DestroyMenu抜けてた…V2/V3はもう更新しないつもりだったけど
バグ放置する気もないので、こっそり差し替えますた（笑
表向き変化無いので、V/L/R番号は変えてません。
ついでに最新の音源DLLセットでgenpfmやnp2fmで落ちなくなってたので、
複数chip可能チェックは最初の1回だけに戻しときました。
まぁ、>>プリスケーラ変更（ｒｙのせいなかはわかりませんが、
どちらにしろ鳴らないのでサポート範囲は
相変わらずfmgen.dllとmamefm(2).dllのみで。

fmgen.dllは内蔵のと同じだけど、昔話題に上ってた
「最新のfmgen」で聞きたい人向けかな。SSGも対応したし。

>>22
>複数chip可能チェックは最初の1回だけに戻しときました。
なんか変だな…。
複数chip可能フラグがOFFの時のDLLを使用しない制限を解除しといたので、
標準FM音源カードのパートのみDLLを使用するようになってる、ってことで。

genpfmやnp2fm、np2fm+をテストするのにどうぞ、って感じで。
まぁこっちでやんなくてもソース弄れるでしょうから別にいぃのだろうけどｗ

そう言えばDLL(V1)のdllの外部公開関数の仕様ってどこかに公開されてたっけ？
DLL作ろうと思ったけどgetcupsとかがない古い仕様しかわからなくて作れん

XM7DASHのソースfmdll.hを見て推測。

一番多く関数を実装してあるfmgenのラッパー部のみだけど参考になれば
PSGやリズムの音量設定の機能等も組み込んであります
未だにアバウトな仕様なのですがこれが基本という事で

fmgen wrapperソース
ttp://www1.axfc.net/uploader/so/2866773
p:wrapper

>>25ありがとうできた
でもfmしか使ってないソフトばっかりでだめだ、レジスタ出力もフィルタされてるし

mamefmのソースってありますか？

あるんじゃねーの

>>27
SSGでよければdashの最新版が対応してるよ。

88でも対応したの上がってた

>>26
とりあえず現状わかる範囲で仕様書っぽいの作ってみた。
ttp://tomatoma.s54.xrea.com/pc/fmdll.html
まだindex.shtmlとのリンクとかは張ってない。

fmdll.hからのコピペだし、チェックとかまだ全然だけど、
各DLLの使用可不可○×は各DLLの中身みて確認したからあってるはず。

おお凄い
>>26のfmdll.hはバグってて使いものにならない状態だったようです

>>33
とりあえず>>26のfmdll.hをdash用に加工したモノ
ttp://tomatoma.s54.xrea.com/data/fmdll_xm7dash.zip

>>26のバグって、追加されたAPIの一部のAPI存在フラグチェックかな。

>>34
リンク先まちがえたｗ
ttp://tomatoma.s54.xrea.com/xm7/data/fmdll_xm7dash.zip
こっちで〜。

ちがった、関数ポインタとGetProcAddressだけ//で消してるんだけど、
実処理側が消してないので、多分そこでコンパイルが通らないんだね。
無効化してある関数ポインタとGetProcAddressの//をとっちゃえば
コンパイル通るよ。

>>36
CSMをCMSと間違えたりもしてました
独自に拡張してXM7dashのレベルメータ対応dllなんかも作れます
あまり独自にしすぎるとカオスになりますが

豆FMV
ttp://www1.axfc.net/uploader/so/2868353
p:fmv

>>37
ちょｗ
レベルメータはrbufを直で見てるからどうしようもないだろうな〜
と思ってたのに、まさか独自拡張してくるとは…ｗ

またこっそり差し替えとこうかなと思ったけど、
今度はデバッグじゃないのでさすがにアレかなと思ったので、
次回更新分にいれときます。
本家最新版が出る前には公開するつもり…。

でもせっかくなので、とりあえず使いたい方は↓どうぞ。
ttp://tomatoma.s54.xrea.com/xm7/data/xm7dash_130414.zip
バージョン・レベル・リリース番号とか更新日時とかｗ変えてません。
β版扱いということで。

% 個人的に…普段はmamefm2.dllで鳴らしてるので、
mamefm2+mamefmvのmamefmv2.dllみたいなのあると泣いて喜ぶかも？ｗ

mamefmv2追加してみました

豆FMV(2)
ttp://www1.axfc.net/uploader/so/2868608
p:fmv

>>39
マジキタコレｗ
…ありがと！
今後はデフォこれにするわ〜ｗ

ttp://tomatoma.s54.xrea.com/pc/fmdll.html
一応修正しといたけど、このページの扱いをどうするか考察中。。。

*v.dllから取得するデータは実際に再生する音量計算後のデータなので
XM7dashのrbufに格納されるデータより小さくなります
あとXM7dashは特殊的にレジスタ0xffをタイマーA起動用に使っているので
dll側がCSMに対応していない場合は自前で実行した方がいいかも
pFmDll->SetReg(pOPNA[*], (uint8) reg, (uint8) dat);
の部分を
if (reg == 0xff) {
　if (!(pFmDll->GetCaps(pOPNA[*]) & SUPPORT_CSM)) {
　　pFmDll->SetReg(pOPNA[*], (uint8) 0x28, (uint8) 0x02);
　　pFmDll->SetReg(pOPNA[*], (uint8) 0x28, (uint8) 0xf2);
　}
} else
　pFmDll->SetReg(pOPNA[*], (uint8) reg, (uint8) dat);
みたいに

>>41
対応してみた。β版その2
ttp://tomatoma.s54.xrea.com/xm7/data/xm7dash_130416beta.zip

ディスプレイの音量補正は擬似的に掛けてみたけど、
音量設定-10未満まで下げるとさすがにダメっぽい。
まぁデフォ設定で使うレベルなら気にならない感覚かなと…。

openmsxで使えるジョイパッドて日本で売ってるのかな

面白そうなので試しに外部音源DLLを作ってみたぞ
ただし音源の機能は無い魔法は尻から出る

ttp://spoiler.shiteyattari.com/pStereo.zip

>>44
M88だとfmgen以外は一部の音が発生されませんでした
x88x17に内蔵されてるpStereo機能だとfmgen以外でも問題なかったです

>>45
外部音源をステレオ化するものなので仕様

>>46
pStereo.dllとx88x17内蔵のpStereo機能は同じ仕様ですか？

しらんがなw

擬似ステレオ機能は同じものだぞ
おまけでpStereo.dllにはLPF機能が付いている
新しい外部音源がアップされてたから機能追加しないといけないな

blueMSXの作者てGoogleの社員になってるね

スカウターでも開発してるのかのう

ストリートビューの車の運転手じゃなかろうか

Software Engineer となってるから、車の運転手ではないだろw

PC6001V v1.19

どっかでROM買えないすかねぇ

買えたとしたら違法品

昔はアキバ行けば路地裏でCD買えたのにね

ナウはX1も弄ってくれ('A`)ﾉ

クソみたいなエミュしかないから、ナウには一から作ってほしいな

eX1*が結構良い感じに仕上がって来てるんじゃないか

エ〜〜〜、まじ

どこ見ての意見よ、それ

88とX1は、武田氏のエミュが一番再現性が高い

ただ、使い勝手がいまいち

どこが悪くてどうして欲しいのかを伝えないことには改善されないままだからな

実機をいじった事の無いヤツは>>61みたいな意見なんだろな

実機どころか、エミュも触ってないだろコイツ

PC-100のエミュについてココで話できます？
それとも100のスレに行った方がいいですかね？

ここでいいんじゃないですか？

PC-100のエミュなんてねーだろバカかｗ

自分で作る

>>68
いやTAKEDAの話が出てたでしょ

うちのPC-100model30がそろそろ維持限界で
グラフィックが怪しい表示をするようになってしまった

その本体の保存も大事な案件なんだが
実はウチにはPCゲーム史上、まぁ結構有名（だろう？）なCGデータが1つあってな
(それがＰＣ-100で描かれている)　本体がダメになると、そのデータも無意味なものになってしまう

・・というわけなんですわ

今、ウチの環境では何も出来ません。
ePC-100も動かなければ、2ＤのＭＳ-ＤＯＳｗのデータを読む事もできないが
とりあえず、ココにヘルプを出してみるかと。　そういうことです

エミュも動かないディスクのイメージ化も出来ないんじゃどうしようもないがw

2D->2HD への移動なら俺がやってやるがどうよ

マジでやってくれんの?
2Dのドライブでまともに動くの持ってる?
てかWinでは無理だから実機で2Dと2HDコンバートするしか無いけど
そんな機種はないから2D>2DDにしてから
2DD/2HD機種で更に移さないと多分無理だよ
2DDなら5インチのドライブがないではないけど殆どの場合3.5インチになる
つまり3.5インチで2Dは存在しないから2DDにする時点で3.5インチにしなきゃならない
まあ2Dを直読みさせながらパラレルで送れるなら一番簡単だけど

98とか88のディスクドライブならジャンパー切り替えでAT機に接続して2Dディスク(論理フォーマットは問わない)もイメージ化できるんだが
Windows機なら
・5インチドライブ
・マザーボード側のBIOSにfloppy 2D,360KBの項目がある
・Image化ソフト
でイメージ化までするとデータは根性で取り出し変換できる
PC-100実物あるってことは5インチドライブあるってことで、PC-100のインターフェースとかジャンパ周りの写真があれば手がかりが

5インチなPC-98上でMAKE_HDでいいんじゃないの？

98で吸い出した方が楽でイイネ
動くうちにBIOSも吸い出した方がいいかもな
PC-100から吸い出す方法もその必要があるかも知らんがw

PC/ATなWINDOWSでもBIOSを5インチFDにすれば2Dが読み書きできる場合がある

本体とFDDが生きてるならトラックやセクタ単位で読んでシリアルに垂れ流しでもいいんでない？

記憶が曖昧だけど
98（5インチ）とかでもMS-DOSＤ上で2Dのデータを読めたんじゃないかな？
ウチの98DAが、まだ辛うじて1ドライブだけ動いたはずだから
上手くいけば2D→2ＨＤへのコンバートは出来ると思う。
今度、実家に戻ったら試してみます

あ、あと、そのPC-100のCGデータは
アスキーの「エアーブラシ」で描かれてます。

1985年頃？からゲーム雑誌に掲載されたCGなんだけどね
もう、データの保管と維持を真剣に考えないといけないと思ったもので。
自分のマシンが不調になってなおさら、と

頼むから全半角混ぜるのやめてくれ

不可抗力

NISE386　が手に入らない（×_×）

>>73
遅レスでスマソ

PC-9801F+1MB_FDDインタフェースボードがあるので
５インチ2D、2DD、2HD、3.5インチ2HDの間でファイルの移送が可能っす
よろしければステアド晒しておくれよ

3.5インチ2DDが落ちてた

それなら別途MS-DOSが必要になるが、自前でイメージ化できるんじゃね。

make_hdは使えないからmahalitoあたりを使うのか

イメージ化にはメモリ最低360KB必要だから9801Fでは厳しくないか？
AT機に5インチドライブつけてnditt使った方が

5インチ用意できるならがその方が確実だが、ありもので済むならその方が良くね
イメージ化するプログラムにもよるけど精々1Track分のバッファに読み込みながらファイルに書き出していくから
MS-DOS2.11にも対応しているMAHALITOなら問題ないだろ。
MAHALITOから別フォーマットに変更しないとエミュでは使えないかもしれないが。

XM6 TypeG (version 3.10)

質問ですけど、M88ってwindows8で動きますか？

やってみたらいいんじゃないですか？

出来ませんでした

7だと64Bitでも動くけどね

XPmodeとかってどうなった訳？

>>90
Windows8.1 x64でもDirectX9.0c入れたらM88もXM7も動いたよ。
9.0ｃはWindows8以降は正式対応してないから自己責任になるけどね。

Fx702p

2211

質問です
88の2HDを98でファイル化したものは88EMUで動く？

dcuとかだと動かない（そもそもエミュ本体が対応してない）けど、ベタイメージなら動くんじゃない？

ファイル化といってもいろんなフォーマットがあるわけで、
ファイル化する機体は88だろうが98だろうが問題ではない。
使うエミュレータが対応しているフォーマットでファイル化すれば動く。

もちろんプロテクトなどが掛かってないことが前提だけどね。

>>98
88の2HDを98でファイル化して88EMUで使ってるが。
ファイル化時にこのメディアは2HDだと指定してやる必要はあるけど、
そういう事はツールのマニュアルに書いてあるからちゃんと読むこと。

XM6 TypeG v3.12 L30
某所で久々に更新情報を知ってページ見に行ったら何もかも以前と変わってたけど
結構前にソース厨が噛み付いてた頃はgoogleのみでの配布とかやってたし
なんかこの作者も方々逃げまくりで残念な事になってる感じね
口先から動くタイプの人間は言う事とやる事の整合性が保ちきれないから
結局同じ結末が待ってる

使うだけ使ってなにもしなかった奴には残念なことだろうね

X68Kは大学時代に所属してたサークルにおいてあったから当時多少かじった程度。
MXDRVとかZMUSICとかを結構いじった位かな。
なんで、XM6系にリクエストとかできるほど知識はないし、FM-77ほどの思い入れもない。

ソース構成がどちらもPI.さん作ということもありXM7と似たところがあったので、
デバッグウィンドウとかXM7改造の元ネタとしては利用させていただいた程度。
いつかソース公開することがあれば、
よくわからない点も含めてXM7へ移植できるんじゃないかなぁと
期待してた時期もあったけど、まぁ仕方ないよなｗ

で、ここまでが前置きで、
XM6のデバッグウィンドウのバグめっけたのでコメントしとく。

GUIメニュー⇒表示(V)⇒プロセッサ(P)⇒メモリ(M) で表示されるメモリウィンドウ、
表示した際のサブウィンドウタイトルは
「メモリ [x] ($xxxxxxxx - $xxxxxxxx)」
なんだけど、一度アイコンや非表示にして復帰すると、すべてのサブウィンドウが
「メモリ」
になっちゃう。

原因は、mfc_cpu.cppのCMemoryWnd::OnPaint()関数で、
キャプションをSetWindowText(m_strCaption);にしてるせい。
たぶん、SetWindowText(m_strCaptionSet);にでもすれば直るんじゃないかと予想。
MFC環境が無いんでビルドして確かめられないんだけどさｗ

Twitterは一応やってるけどほとんど放置してるし、
この話だけのためにgimons氏をフォローするのもどうよ？と思ったので
まぁたぶんみてはいるんじゃないかと踏んだのでここにコメントしとく。
type Gの最後のWeb公開版でも同じ症状でてたんで、気が向いたら直しといて。
…とは言っても修正されても私は入手できないんだろうけどｗ

長文スマン^^;

ほんと長文うざいね
許してあげない

>>104
作者さんが対応してくれたよ

GIMONS @kugimoto0715 ・ 21 時間

L50では某掲示板で教えていただいた修正等も含んでいます。
修正内容その�@
・メモリウィンドウのタイトル更新バグの修正
・ADPCMの更なる安定化(ボスコニアン)
・GVRAM/VC/SPRITEのメモリにノイズを乗せる対応

>>106
おつかれさまです。
って伝えといて。

XM6 TypeG最新はXPで動かないようだなランタイム最新にしても
有効ではないアプリと出る

TypeGはとっくにXpをサポート外にしてたが

なんかTypeG作者がただの痛いかまってちゃんに成り下がってて辛い
サイト時代ソース厨から逃げ回って自分からTweitterに篭って配布もこそこそやってる割には
WinX68Kより人気がないとかEmuCRに転載されるのにキレてたりとか
使って欲しいのか使って欲しくないのかはっきりしろよ・・・
落とした奴等全員がTwitterで褒め称えないといかんのか？
あんなのをありがたがらないといけないX68Kエミュ界隈は悲惨だな

そんなことよりemuz2000ttが復活してて嬉しいぜ

もうソフトが残ってないんだよな…
ミステリーハウスとかグリーンモニタでやりたいわ

デジタルRGBモニタを動態保存している酔狂な人もいるみたいね

> EmuCRに転載されるのにキレてたりとか
これはツイッターに篭って配布もこそこそやってる点と共通だね。

> WinX68Kより人気がないとか
ここ出典どこ？ツイッターでは確認出来なかったが。

PI.氏がXM6のドキュメントに書いてた
また会ったことのない、メールをやりとりしたことのない人がユーザとして増えることは
負担こそあれ、嬉しいことは何ひとつありません。
もっと言うとXM6は私が個人的に、私が使うために作った、私のためのソフトウェアです。
他の人がどのように感じようが、私が満足できればそれで良いのです。
これが全てなんじゃないか？
XM6系に限った話じゃ無いと思うがね。

>>114
＞出典
上から4つ目

>>114
あと人の言葉を流用して代弁した気になるのはよくないな
言いたい事があるなら自らの言葉で発するべき事だし
そんなことは常識でもなんでもないから

> WinX68Kより人気がないとか
あったあった。確認できた。

つーか、何ツイート細々チェックしてんだ？ｗ
で、気に入らんと2chへ愚痴かよｗｗｗ
本人に直接リツイートしてやれよｗｗｗ

おまけに2ch「匿名」カキコで
> 言いたい事があるなら自らの言葉で発するべき事だし
ってのも大爆笑だなｗｗｗ

まぁ、結局はwebでフリーウェア公開を続けられるかどうかのキモって
こういうアホをスルーできるかどうかなんだろうな。

作者がTwitter利用しているからと
こちらもわざわざ垢を取ってtwitterを利用しなければならないなんて道理は何処にもない
もともとこのスレ住人だっただけだから

今回の事にしたってEmuCRに更新情報が載ってたから
ソースから更新情報でも見ようかと思いそこでTwitterに誘導されただけで
相手の揚げ足を取るためだけに態々ツイートを拾いにいくなんてのもありえない
流石に今回はDLもしなかったからこれっきりで目にすることもないし
もうこんな事を書くこともないんで安心していい

あと俺はあくまで俺の言葉をここに愚痴として書いているが
お前は作者本人でもない上作者の心情の想像を
さらに他の作者の言葉で代弁したのだから
これは明らかにお門違いでPI氏にしてみれば傍迷惑な話
お前の言う大爆笑はちょっとずれすぎ
まぁこれでTypeG作者本人だとしたらさらにイカれた話になるんだけどな

＞まぁ、結局はwebでフリーウェア公開を続けられるかどうかのキモって
＞こういうアホをスルーできるかどうかなんだろうな。
お前は結局これが言いたかっただけだから
最初からこれだけ書いていればよかった

おっさんどうしなんだから仲良くしろ
殺伐としたいなら、びっぷらでガキ共と同レベルでやってろ

俺は実機触った事がなくてエミュで初めてX68K使ったよ。
エミュも実機の設計も良く出来てるなと思った。ただAT互換機みたいな細かい基本設計複雑すぎは難点。
BASIC、エディタ、デバッカ標準搭載も良いしOSの設計もよく考えられてる。
C言語を前提としたDOSでUNIXみたいなところもあって開発する人にとっては使いやすいマシンだなというのが第一印象。
IBM-PCがMC68Kを採用してたらこうなってたというようなマシンだな。

たぶんレトロPCも伝統芸能化してゆくんだと思う。
伝統芸能のこけしを作り続ける爺いみたいな。
俺的にはありだと思うけど。
そういう伝統とか民芸品こけしとかマトリヨシカみたいなのに文句いっても始まらないし。
電子楽器みたいなのもそうだと思う。楽器はそもそも歴史古いし。

既にブリキのおもちゃレベル。
この前やってたナイトスクープのサンダーボーイと変わらないレベル。

EMUがエミュレートしてるAgat-7とかのPCが何か知らんので調べたらソ連製かい。
道理で知らんはずだ。

>>120
Linuxその他のPOSIX準拠OSが広く使われているのに、敢えてX68k褒める理由って何だろう
「仮想環境にLinux入れれば良いんじゃん」で済みそう

Windowsが9xメインの頃は犬信者で「Windowsなんて、Winアプリのためにしか使わないよﾌﾟｷﾞｬｰ」だったけど
Windows NT5.0（内部でね）以降なら変な不安定さも無くなったからゲストOSにLinuxとかUSBメモリとかで良いんじゃないかと

以上、ネットブックではLubuntuを現役使用中のアラフォーの戯言
吊るしで使ってるのでAtom N270/Memory 1GBじゃVista以降はキツいかな
2GBとかに増設すれば32bit Windows8なら使えるかもだけど（激安フェアのときにライセンス入手済）

まともに移植できなかったlinuxの出る幕こそ無い気がする。
国産機に移植は皆無じゃないけど、どれも現行エミュでまともに動く気がしない。

>>124 です

もちろん、実機の資産を活用するためにエミュを使う意義はあるんだろうけど
そのエミュをLinux対応にするか否かは、ライセンス次第だけど基本的には原・作者のさじ加減
（MITライセンスその他のオープンソースなら別問題）

アレな話題で良く出て来るsnes9xはLinuxでも動くし


なにより >>124 の発言が >>120 を受けてのものだというのは考えてみて欲しい
あとMC680x0系アーキテクチャ上で動くPOSIX準拠のOSとしてはNetBSDも…（Linuxの対応状況は知らない）

動かないものを褒める理由ってなんだろう？

> 開発する人にとっては使いやすい

と書いてあったのを受けてるんだが

だから使いやすけりゃ移植されてるだろ？

>>129
意味わからんぞ

http://xm6i.org/download.html

NetBSDやCentOSで動くじゃねえか

>>125はlinuxの話しかしていないが、何が言いたいの？

何が言いたいかさっぱり分からんから質問・批判の趣旨を聞いてるんだが
全く要領を得ない

…まさかX68k実機でLinuxがｳｺﾞｶﾅｰｲとか言ってるんじゃないよね

実機でもエミュでも動かんだろうが

Linux「は」動かないがNetBSDなら動く
POSIX準拠OSとしては問題ない

…それを知って批判しているのかな

じゃあ
＞「仮想環境にLinux入れれば良いんじゃん」で済みそう
って何が済むんだよ？

>>120 の「開発する人にとっては使いやすいマシンだな」に対するコメント

linuxは移植できないくらい扱いづらい
以上。

>>137
それって20年以上前の議論なんだけど

むしろ386がサポートできなくなる位悪化してるんじゃないかと？

>>139
386をサポートするバージョンの配布物使えば良いだけの話
1FD Linuxとか知らないの

文章読めてないな〜。私が爆笑したのは、
「お前」が「言いたい事があるなら自らの言葉で発するべき事」と
「匿名掲示板」で主張してる点だ。
フリーウェアに関する点はどこにもない。


> こちらもわざわざ垢を取ってtwitterを利用しなければならないなんて
垢なくても普通にWebブラウザで作者のTwitterみられるぞ。
俺がそうしてるし。なので、道理もクソもない。

>なんかTypeG作者がただの痛いかまってちゃんに成り下がってて辛い
匿名掲示板に愚痴を垂れてる時点でお前も充分「ただの痛いかまってちゃん」だな。

> WinX68Kより人気がないとか
がどっからの引用かわからなかった時点でTypeG作者本人であるわけがないのに、
> まぁこれでTypeG作者本人だとしたらさらにイカれた話になるんだけどな
とか、まぁ妄想乙としかいいようがないな。

作者が気に入らなければその作者の作るフリーウェアなんて使わなければいい。
「フリー」なんだし。

フリーウェアをWeb公開すると、こういう自己中な輩に使用される可能性がある点が
最大のデメリットなんだろうなぁ。

で、そこから過去Web公開をやめた他の作者の公開中止につながっていったことが
推測出来る。で、その参考としてXM6付属テキストからの引用を出したわけだが…

匿名で愚痴るクセに「言いたい事があるなら自らの言葉で発するべき事」とか
矛盾する主張をする輩には、ここまで書かないと通じないのか。
それともここまで書いても理解出来ないのか。
まぁ、どっちでもいいけどな。

>>140
だったら20年前がどうしたんだよ？

>>142
"Linux is obsolete" の議論も知らない奴がLinuxの移植性を騙るな

動かないのは事実だろ。
誤魔化すなよ

>>144
つか、移植する香具師がいなかっただけだろ。
当時は68K自体へのLinuxの移植が組み込み向けとして始まったばかりだったし。

こういうのは開始したての頃の方が居るもんだろ。
だから居なかったという事はありえない。
居たら動くと言うものでもないけど。
んで、マイクロカーネル論争から２０年経って今ならできるかと言えば、
ソース極端に肥大化してる癖に何故かサポート斬りまくりだし、
カーネル自体肥大化して１FDなんて何も入らなくなるから古いので止まっている。

そんな状況で何を褒めるんだよ？

98版のマージなんて、現役終息前後で今更というタイミングだけど、
逆に考えればハードの更新が無くなって保守は楽な筈で、
熱心な人が大半を完了させたのでパッチキットも随分小さくなって、
後は決断するだけのラスト１マイルというところで放置だからね。

結局誰も保守できなかった訳で、
それは構造上無理があったって事なんじゃないの？

68k Mac用Linuxだって存在する

68kへの移植性自体問題なかった証左
NetBSDにマンパワーが割かれて人がいなかっただけじゃね

じゃあやってみろよって話だな。

68kどころかh8だってあるんじゃないの？
たまたま移植した人がすごかっただけなのか、
本当に開発しやすいのか、
人が居ないんじゃなにも言えない筈。

ハードないしWindows機で困ってないから
わざわざLinux for x68kを作る気にならん…

多分「NetBSDあるしコレで困ってないから、わざわざ(以下省略)」って感じだったんじゃん？

そんな奴がわざわざ昔のPC板に来てlinux勧めるとは思えんね。

>>144,146
linuxってもともとはx86アーキテクチャに依存する部分が非常に多くて他CPUへの移植性を全く考慮してなかったわけじゃん

いつの頃からかx86以外のCPUへの移植も行われるようになってARM版から派生でandroidとかも出たわけだけど、
68000はそれより以前に衰退してたんだから、移植しようってヤツが少数派で作業が進まないのが当然だろ?

>>153
たとえ一人だとしても>>138の言うように20年以上あったわけだから
結論として>>137でいいんじゃないか？

X68Kには、OS-9が実装された。
10MHz,16MHz　このクロックですよ。ウェイトも入ってるし。
決して速いマシンでは無かった。
os-9/68000で良かったのです、でも広がらなかった。
それが早すぎた、時代がMS-DOSで、マルチタスクが理解されなかった。

>>155
早すぎたからじゃなくて高すぎたんじゃないか?
たしか10万ほどの値付けだっただろ?

MinixってLinuxじゃないのか
ずっとLinuxだと思ってた

>>157
違うはず
minix の方が古いんじゃないかな

Minixは教育用途の有料ソフトだよ〜
その代わり8086でも動く（Linuxは古いのでもi386以上必須、最近の配布物だとpentium3でも怪しいのばっかり）

PC-UNIXの件だが…。

NetBSD/x68kの移植開始は1993年、1996年NetBSD 1.2にて公式リリースに含まれるようになる
http://www.jp.netbsd.org/ja/ports/x68k/

要するに「これでPC-UNIX環境は整ったから、コレ使おうず」って感じでマンパワーもここに集中しちゃったのが大きいだろ…。


一方Linuxの側は…68k Macで見ると…
http://www.mac.linux-m68k.org/docs/faq.php
古いDebianでは68k Mac用の2.2.25カーネルバイナリがある模様
ただし推奨しない模様

NetBSD/mac68kはNetBSD 1.0の公式リリースに含まれていた模様(1994年)
http://www.jp.netbsd.org/ja/ports/mac68k/

ftp://www.dnsbalance.ring.gr.jp/pub/linux/kernel.org/kernel/v2.2/
2.2.25カーネルは2003年のリリースの模様（これが68kアーキテクチャなり68k Macなりでそのまま問題なく作動するか不明）


そしてX68k対応の配布物は…あるの？
という訳でLinuxの68k対応自体がアレゲだったので仕方ないし、
その頃にはNetBSDが普及していてx68kへの移植にはマンパワー不足だったのは想像に難くない

>>159
＞要するに「これでPC-UNIX環境は整ったから、コレ使おうず」って感じでマンパワーもここに集中しちゃったのが大きいだろ…。
いやちょっとまて、今でもXM6i相当の実機でしか動かないんだから整ったとは言えんだろ。
linuxもサブセット移植ならば8086でも動くわけで、動作環境の話が出る度に紹介されている気がするんだが、
それを国産機に対応させたという話は聞かないね。

>>160
誰か完動実機をおいらに（相応の価格で）おくれやす
勉強しつつ頑張ってみる

理論上はx86/amd64環境でもクロスコンパイルすれば行ける筈だけど
実際どうなん？

長く続くならLinux板かx68kスレ行くけど


じつはx68kは所有したことないの
「良いなあ」と思ってナイコンしてたクチ
その後Windows 95ブームに乗って自作したさ…

あ、良心的なショップの紹介でもokよ
コンデンサの問題で電源がヤバいとwikipediaに書いてあったけど…アレって自力でハンダゴテ握ってどうにかなるレベルとは違うのかいなあ

>>155
理解してたよ。マルチタスクは使い物にならないぐらい遅いって。

>>159
NIFTYにあった　NetBSD For X68000

まあ今なら、とりあえずエミュレータで動くようにしてから
それを実機で試したほうが楽だと思うけど、
やっぱり実機の有無で気合いの入り方違ってくるのかな？
こういうのって。

>>163
それはなんかおかしいんじゃないの？
たとえタスク当たりの処理速度が十分の一になったとしても
MMR動作中の8bit並なら充分使える筈。

>>156
OS-9/X68kが安かった。　29,800円　
同時代のMS-DOSと比べると高価ではあった。

>>165
らじゃ
とりあえずはエミュでやってみる

>>166
全く使えない。OS-9が証左。

>>169
なんで8bit並で使えないのか説明してよ。

遅いからと何度言ったら・・・

だからなんで8bitより遅いのか説明してよ

え？

8bit並に動くなら「全く使えない」とは言えないででしょう。

結局、仮想化してマシンを集約とか言い出すようになるまでは、
早すぎたのかもしれないな。

16bitCPUで8bit並なら使えないと同じでしょう。
16bitCPUで単独ハード直叩きですら演算性能が全然足りない時代だったのに。

8bitPCが全く使えないものだったら当然売れないわけだから、
PCが発展することもなかったと思うよ。

最初は8bitPCでもセットで20万以上してて我慢して使ってたんだよ。

私がDOSからマルチタスクOSに移行したのは32bitCPU 400MHz超えてからだった。
それまではマルチタスクなんてオーバーヘッドでかすぎて使い物にならなかった。

K6 166Mhzでも（疑似）マルチタスクは問題なかったお

Windows 95 OSR2.1/Memory 32MBで、Windows用アプリを動かすとき以外はLinux-2.0.x/2.2.xを常用
最初はSlackwareのちのVine

オーバーヘッドがあってもその分安ければ何の問題もないと思うけどね。
１０台分の性能が２割食われて８台分の仕事しかできなくても
８台分の値段じゃないならいい筈なんだけど、
結局使うのは一人だから、ちょっとでも時間が掛かる方が
性能が悪いと錯覚しちゃうんだろうね。

1982年頃 FM-7のOS-9が動いていた。8bit/2MHzであった。
1989年頃 X68000のOS-9が10MHz 1Mbyteで動く
1995年頃にLinuxが出てくる。パソコンが100MHz程度

UNIX系が処理が重い。
GUI、X-Windowが重い。
Linuxにフリーソフトが多かった

実際に8bitのBBSマルチ回線を実現していた。 BBSくらいしか利用価値が無かったともいえる。

OS-9/X68000なつかしいな
興味だけで購入して書籍のデータベースプログラム入力したりしたけれど
結局遊び程度の使い方しかしなかった
verup版やCコンパイラも購入したのに宝の持ち腐れだったかな

当時よく通ったパソコン屋のFM-11はいっつもOS-9走らせてたな〜なつかしい

マルチタスクをホストＰＣ（サーバー）として使えば、非常に簡単にＬＡＮが実現できる、
現代の社内ＬＡＮと同じ機能。
そういった使い方に慣れてない時代だから流行らないかっただろう。

　また、X68000がマニアによるゲーム機に固定してしまったのも良くなかった、
PC9801のような素人な一般人向けを目指すべきだった。　

>>183
FM11とOS9のエミュがありますよ

>>176
そういう用途にOS-9を使ったのが間違いなんじゃ…
プログラム開発とか制御系とかでしょう。

>>178
i386の16MHzでLinux使ってましたが。
初期の初期のLinuxでも、パソ通とゲーム以外はDOS使う意義を見いだせないくらい使いやすかったのですが。
あ、エロ画像のローダが出来るまでは意義あったかw

>>181
Xが重かったのは、当時のメモリでは小さすぎて、スワップしまくっていたからだよ。
新しいマシンがCPUはP5の75MHzなのに、メモリ64Mとか積んだら一気に使いやすくなって激ワラタ記憶がある。

>>185
マジですか！？
知らないのですm(_ _)m

少しだけ、昔話を。誰かバレそうだが、夜中なので、許せ(´・ω・｀)

最初のパソコンを買ったのが84年とかで、当時はピーコがグレーゾーンだったから同じようなオタの先輩とやり取りしてたんだな。
で、その先輩がOS-9/6809を持ってきたことがあって、自分が何かに使うかといえばろくに使わないのだけどカルチャーショックを覚えたんだわな。
マルチタスクで、しかも、ヘタな汎用機よりも使いやすい環境って一体…みたいな。
更に９０年代の頭。パソ通覗いてたらLinuxとかいう新しいOSを移植したよ。と言う人が現れたので、新し物好きだった自分は飛びついた。
回覧で貰って、中古マシンに付いて来てた小さなハードディスクにインスコして、使ってみたが、あまりの使いやすさに驚いた。
当時は、Xもろくろく移植されておらず、Emacsがメインだったんだけど、これはミニコンとかOS-9並の使いやすさだな。と。
確かに多少重いかも知れないけど、コンパイラやアセンブラを別コンソールで回しながら、文書や別のプログラム書けるというのは、作業効率が違いすぎた。
そういう一連の経験をしてなければ、プログラマ稼業に本腰入れることはなかった位の物がある。
あの当時、素直にWindows使ってたら、嫌になって全く異種の稼業選んでいたろうね。

>>189

tp://nanno.dip.jp/softlib/man/fm11/

>>191
ありがとう！

>>157
比喩的には「おじさんと甥」みたいな関係じゃないかな？

>>159
アスキー版買ったよ、説明本（記憶がおぼろげですまんがPC-UX向けのをminix対応した本だったはず）も買った。
実用できるものじゃなかったけどパソコンの勉強にはいいソフト・本だった。

日経mixの方は知らないごめん。

>>188
それこそエミュレータで検証してみるのも一興だよな。
実機でもブートオブションかなんかでメモリ制限できたような気はするけど、
まあエミュレータの設定でするほうが確実でしょう。

あとはディスクのアクセスタイムとかの違いだけど、これはどうしようか？

おれも大学の頃、マルチタスクOSには衝撃を受けた。たしかACOSだったかな。
授業でみんながエディタを使うだけでカーソルやスクロールに数秒〜数十秒かかるのだ。
同じ端末でDOSなら高速スムーススクロールできるのに。

20世紀のSunOSベースのメールサーバ＠大学では
3,000人宛のメール一発で大混乱に陥ってたっけ
sendmailかどうかは知らん

何も知らずに不満を送り主に返信しようとして
全3,000人に送ってしまう奴が連発してな
サービスの処理遅延かどうかは知らん

…って大学バレそうだなｗ

＞＞194
今は仮想マシンがあるから、当時のディストリと数ギガバイトのディスクの空きがあればかなり再現できると思う。
流石に、クロック75MHz相当は難しいかもだけど。

>>195
それに関してはCPUじゃなくネットの帯域が原因のような気がするんだが?

レトロPCの写真が満載、「懐かしのホビーパソコンガイドブック」が発売
http://akiba-pc.watch.impress.co.jp/docs/wakiba/find/20141030_673892.html

ちょっと読んでみたい

立ち読みしに行ってこよう。

>>199
ありがとう！
Amazonで売り切れになってたわ
ポチっといたけど読むの楽しみだ

なにげに上記のWebサイト読んでみたが、
> 当時のパソコンを知りたい若い世代
なんているのか！？と思ってしまった。
この文だけはちょっと無理があるなぁ…。

当時のパソコン雑誌を持ってるオレでも楽しめるのかコレ

無理があるだろうな

過去のコンピュータの歴史を振り返ることによって学ぶこともある。
今の時代では、いきなり64bitCPUを使って、マルチコア、マルチスレッドCPUを扱わないといけない。
いきなり　だから難解である、順に沿って手順を踏んで学べば理解される。
つまりだ、歴史を振り返ることにより、4bitCPUから始めれば さほど難しくは無い。

始まりのCPUは、日本が造った。
もし、i4004が無ければ、歴史が大きく違っていた。

日本が作ったというのはさすがに語弊があるぞ

>>205
PICとかarduinoとかあるから、そちらでなんとか…

>>206
正確には、日本からアメリカに移住した技術者がアメリカの会社で。だよね。
青色LEDになっても変わらない構図。

「日本が作った」じゃなくって「日本人が作った」ならまだ…移住の時点でもう日本人じゃないとか言われそうだがｗ

嶋先生移住したのか…

というのはともかく4004本7500円って高価すぎない？
http://www.amazon.co.jp/dp/400006021X

>>209
古本だからだろ。

X1やPC88エミュで表示サイズを2倍とか3倍にできるのはないんだろうか。
フルHD液晶だと画面が小さすぎるし、全画面だと大きすぎるし。

ない

コモンなんとかの奴はソースあるんだからなんとかならんの？

88ならM88改があるじゃん

ソフトウェア板のエミュスレにあるようだね
ただ、CPU使用率がかなり上がっちゃうな・・・

Direct3Dに対応してるやつならそんなに負荷かかんないじゃねーの
ttp://spoiler.shiteyattari.com/q88x3.zip

負荷は変わらないけど？！

>>216
これ画面が眠たいな
ボヤけてる

PC98とかX68とか16ビット機のエミュは画面倍にして
画質向上させるフィルタかけても負担低いのに
8ビットのエミュはなんでこんなに重くなるんだろう

Z80でエミュってんじゃね？

GDI+Vista以降だからだろw

TAKEDA氏のなら拡大できるしDirect3Dに対応してるから負荷も気にならない

ステートセーブが無いのは論外

openmsxのステートセーブは論外
まだpacセーブ機能つきのものの方がマシ

付けりゃいいんでない？
なんか問題あるの？

だれかテーマ画像つくって。
blueMSX 無理やり4倍出力。
ttp://www1.axfc.net/u/3359131

>>222
表示サイズ以上になるよう整数倍に拡大してから縮小してるんで、
サイズが大きくなると幾らかの負荷はあります。
Direct3D任せで拡大すると、環境によってはライン抜けしてしまって。

StretchBlt()よりは高速に拡大できるように配慮はしてますので、
Core2クラス以降ならそこまでの負荷ではないかと思います。

blueMSXでキーボードの不具合何とかならんかねぇ
Direct Inputで具合が悪いって公式でも言ってるけど進歩ないし・・・

武田氏のもステートセーブつけてくれんかのぅ

ステートセーブはホント必要

そこまで必死にクレクレするほど必要か?

うん

ｸﾚｸﾚするほど必要ではないのは、代わりがあるからだがな
再現性の高いエミュは、少し弄ってうなずいてそれだけ
只でさえ昔のUIなんだから、今更ステートセーブなしで居られるかｗｗｗ

vmwareとか使えば、武田エミュでもステートセーブ出来るじゃん。

そこまでして武田エミュを使うべきなのか問う

マイナー機種の存在意義を聞いてるのと同じじゃないかそれ。

何気に武田氏のエミュ再現性良いんだよな
8801MAにしたってX1turboにしたって
テープの扱いに関してもM88よりマシ
んなだけにステートセーブが欲しいところ
88MAでSB2切り離せないとか個別機種なだけに不都合もあるけどさ

正直新OSで古き良きエミュを苦労して動かすより、
ゲストOSの箱庭で昔構築済みのエミュ環境動かすほうがいいよね？
引越しも簡単だし。

XPはまだ現役です

苦労上等な人なら、wine上でエミュ動かしてみるのもお勧めしてみたい。
実デバイスの代わりにイメージファイルのシンボリックリンクを置けば
怪しげな仮想デバイスの助けを借りなくても済むかもしれない。

wineでX milleniumは動いたと思う
wineと連携しだしたReact OSの今後に期待したい

あれを再現性がいいって実機を触ったことがないROM厨だろ

>>241
POKE &H01A2,&HB7

当時のX1ユーザーなら知ってるおまじない入れてあげたのに・・・

8/16bit機で動くものは無いの？

日本語の不自由な方はお帰り下さい

32/64bit機用ばかりだな。

Win8.1にしてMZ2500やX1のエミュ動かしたら、最初はいいんだけどすぐにフレーム落ちし始めて10fpsくらいになる
なんでだろ？

XP機でやるという手は無し？

>>247
私のエミュレータについては、10/26にその問題を修正しています。
最新版試してみてください。

>>249
作者御本人でしたか！
さっそく最新版と差し替えたところ、常時フルフレームで安定しました
ありがとうございます！！

俺のPCじゃMS-DOS Player起動しないな・・・
何が問題なんだろ・・・

>>251
環境の問題に決まってるやん

Win8.1でそんなに大きな仕様変更ってあったっけ？

>>251
8.3形式のファイル名を無効にしている環境だと、まともに動かない気はします。
他はちょっと思い当たらないです。

>>254
おれの注意不足でした。
blogを読むとcmdから直に起動してるようですね。
88VAのDOSエミュやX68のDOSエミュやS-OS SWORDみたいに。

環境だったら思い当たらんですｗ
Win7 SP1 64Bit、マザボintel純正。　ランタイムくらいしか・・・ｗ

>>255
ほぼ意味の無い環境さらす人って何なの？

非オマ環アピールはいいとして、
むしろ笑いどころがわからん。

>>256
おま、からかわれてる事解らんのか？

>>258
ニヤニヤ

情報交換したいのか撹乱したいだけか正直わからない書き込みってあるよな。

>>252に対して適当に環境なんていうから
このド基準ともいえる環境で思い当たらないわ
(他のエミュで)よくあるランタイムとかその手が足りないとかくらいじゃね？ｗ
の意

>>261
なるほど、ランタイムが悪いかも？と疑問に思ったことを日記がわりに書いただけで、
質問してる訳じゃないんだな。
ランタイムが悪いかもと思いつつ、インストール済みの
ランタイムを晒すわけでもなく、ほぼ意味の無いosとかマザボ晒すくらいなんだから。

おまえ性格最悪だな…

とりあえずドマイナーなwineで動かしてみれば何かわかる？

自分のことを棚にあげるお前最悪だな…

ここは最悪板じゃないので名無しで最悪言い合っても始まりませんよお二人さん。
何か調べて気づいた点や心当たりがあれば情報提供お願いします。

ダブルクリックして起動させようとしてるから動かないというオチで
コマンドプロンプトから使うってわかっててそれでも動かないという事なのか

何を動かしたいんだろうか？

>>266
何が問題なんだろ？->環境に決まってる->ランタイムしか思い浮かばないw->入れてるランタイムやバージョン書かなきゃ意味無い
で、止まってる。
そもそもこっちから積極的に推測する必要なんて無いだろ。
情報出してきてからで良い。

そもそもランタイムが不要…

>>269
そこは情報提供していただかないと不明のままでしょうね。
まあ環境に問題がないという主張であれば、誰かが追試すればはっきりするわけで。

>>262
イマイチ違うなぁ・・・
ランタイムが悪いかも？じゃなく、(ソフト全体を含め)あとはランタイムくらいしか環境で問題になることはないんじゃね？
(まぁ、武田氏のはその手を要求するのは見かけないかし問題ないだろう)の方向
ランタイムを晒すも何も、その必要無いOS、マザボなんだったら、(武田氏のに限らず)それくらいだろうの意味だってわかれよ・・・ｗ
揚げ足取るタイプだと面倒だから(DirectXとかSDLとかその他の類も「とか」で含めてな

もともと、適当に環境なんか言ってるから、そのあんたが意味のない環境という、環境で
「これが何か？」的に言われてると気付こうよ・・・ｗ

どうでもいいけど、あんたら・・・
>>266、>>267、>>271
もうすでにコマンドプロンプトからってのは解決済みやん・・・
解決してるのに何を情報提供しろと・・・

そもそも動いたという情報自体がない件について

>>272
最初(>>255)は「ランタイムくらい」だったのに、次(>>261)は
「ランタイムとか」って後出しはもう良いよ。
ま、作者のところで動いて、お前のところで動かないんだから、
環境が問題なのは間違いない。

>>274
起動方法が違ったということで、そこは解決やん
次に動かんならそれは別の話だろ・・・

>>275
あぁ、書き方からするとそうだな。
結局揚げ足取りかｗ

お前、アホだろ？
そこの時点のステップはcmd動作で解決してるだろ

>>255って実は動作報告だったの？

blog見て使い方というか正常動作の挙動は把握したが、うまく行かない
って事なのかと思ってた。

【レガシー】三保電機、生産ライン向けに「ＰＣ―９８００」エミュレーションソフト [2014/12/19](c)2ch.net
http://anago.2ch.net/test/read.cgi/bizplus/1419166067/
http://www.nikkan.co.jp/news/nkx0220141219hhas.html

　三保電機（鳥取県米子市、小松忠司社長）は、
「ウィンドウズ」を搭載したパソコン用エミュレーションソフトウエア「ｅＭＤ―１」を発売した。
同ソフトをインストールしたパソコンで、
ＮＥＣ製のパソコン「ＰＣ―９８００」シリーズで使っているソフトを引き続き使用できる。
同シリーズを生産ラインの制御に使っている各種メーカーに、
低コストで現行システムの延命を図れる手段として訴求する。
価格は４５万円（消費税抜き）。

　同シリーズの機種から抽出した必要なソフトを、ｅＭＤ―１をインストールしたパソコンに導入して使う。
従来のソフトをそのまま使え、最新版ソフトを新しく開発するより安く作業環境を構築できる。

　ＰＣ―９８００シリーズは１９８２年の発売以降、一時は日本市場で９割以上の占有率を占め、
生産ラインの制御にも多く採用された。
「現在も約１０万台が使用されているが、もう新型機が出回っておらず、
　中古機の出回る数も減って修理対応も困難になっている」（坂本一登東京営業所長）。

移行できないのはCバスでリアルタイム制御してるのばかりだろ。

最近のPCはシリアルポートさえ無いというのに

内容がよく分からんのだが、Cバスをエミュレートするようなハードウェア部分があるような感じには見えない
http://sdk.jpn.com/welcome-to-sdk/%E3%82%BD%E3%83%AA%E3%83%A5%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%81%AE%E6%8F%90%E4%BE%9B/nec-pc-98-%E3%82%92windows%E7%92%B0%E5%A2%83%E3%81%AB%E7%B0%A1%E5%8D%98%E7%A7%BB%E8%A1%8C%EF%BC%81/

BIOSとかの権利部分でNECとトラブルにならん様になんらかの契約を取りつけてるとかならいいんだが、どうなんだろうな。

5inchが変換コネクタでUSB接続できたらなぁ

インテリジェントな奴をUSB-パラレル接続するとか？

FDDの話だよね？

8255の先に繋がってる奴ね

意外とFDユニットごと接続したって話は聞かないのな。
ドライバ作れる人が居なかったんだろうか？

3.5インチのはあるんだよね

要するに88のFDサブと同等のもの？
同様に拡張すれば2HDとか繋がらんのかな？

XM7のページ、なにこれ？
>一部ユーザによるライセンス違反が確認されましたので、配布を一時停止しています。

勝手にソース改変して公開したんだろうな

>>283
KryoFlux

>>292
ラムドライブ搭載機に乗っけたら不毛そうでcoolかも？

ボードだけで14000円かよ…win98機の中古買ったほうが安いかも

>>290
勝手に日本語化した外人がいた
後、MESSが一部ソースコードをパクっていたが、作者に連絡すらしてないでやらかしてるらしい
勝手に日本語化してた外人は作者に英語で連絡したが、話がこじれた後だったから日本語じゃないと作者は受け付けない云々となってる。

>>295
>勝手に日本語化
「勝手に英語化」じゃね…？

>作者に連絡すらしてないで
パクっといて(C)表示がどこにもない点が問題

正直じゃぱにーずおんりーの垂れ幕ってどこが悪かったんだ？
スタッフルーム私語禁止で結構じゃない。

>>296
間違えた

>>298
競技場に外人も在日外国人も来ないなら、問題にはされないよね。
現実は真逆だけど。

喫煙家がきても禁煙の表示はなにも問題ないだろう。

旧型のFDDケーブルつかったら、ATの内蔵3.5インチ用のコネクタで5インチの内蔵用ドライブを付けることは可能なはず

VFOの有無の違いがあるから9801用内蔵ドライブの流用とかは、普通は無理だったはず

>>302
何をもって普通と言ってるのか知らないけど、
正確には「AT互換機に流用出来る98内蔵ドライブもある」じゃね？

RA21のFDを繋げて使えてたし

>>295
・ソースコードをmessへ流用しといて(C)非表示
・外人によるバイナリレベルの英語化
これって今回の公開停止以前からの問題だよね？

今回12/23のL63公開以降、公開停止に至るトリガーってなんだったん？

>>305
新しいバージョンを英語化した人が、配布せずにスクショアップしたの。
本人は配布しないと英語で言ってるのに。

いや以前から、英語化は不正流用してたのに
なんで今切れたの？って話だろ
作者のサイトに、スクショ直接うｐしたのが原因なんかいな？

>>307
作者のサイトBBSに英語化したSSアップしたのは2年くらい昔の話だよね？

>>306
海外のどこかのエミュレータBBSにL63を英語化したSSアップされたってこと？

>>308
英語化した外人が、土曜日にツイッターにL63のスクショアップしてたよ。
配布するともしないとも言わずに。
で、作者たちがブチ切れてサイト閉鎖。
英語化された物は、見える範囲では配布されてない。

どうやら、その外人は日本語喋れないから、数ヶ月前に英語で作者たちに釈明メールしたらしいが、作者たちがその時もキレてなんだかんだあったみたいだ。
日本語で寄越さないと読まない的なことツイートしていたな。

>>309
サンクス。やっぱりそうか。

>>310
問題なのは、英語化した外人よりも、作者たちのような気がする。
MESSで無断使用された上にMESSチームが抗議を無視し続けてるどころか居直りすらしてるから神経質になるのはものすごくわかるんだけどね。

エミュ元のマシンを後世に残す資料として作った的な事を言ってながら、外人が英語化したら日本語でメール寄越さないと読まないとか色々暴言に近い事言って拒絶したり、サイト閉鎖したりしてるのは行き過ぎではないかと思えるんだけど、変かな？

>>307
多分バイナリーの書き換えで英語化して、元の配布先を明示した上で配布するのは無断使用や無断転載とは言いにくい感じがするよ。
もにょるというか。

>>311
意固地と言えばそうかもしれないが
そもそもの発端がMESSチーム側の対応にあるんだし仕方ない

彼らにしてみれば日本語のライセンスなんか読めないだろうし
MESSはソースも公開してるから問題ない程度の認識だろうけどね
残念ながら日本の開発者には挨拶が必要だったって事なんだし
文化圏の違いはあれど流用するなら相手を立てるのは当然の事

某漫画の騒動での出版側と権利側の話に似てる
あの件の出版側にあたるのがMESSチームって感じだよ
いくら大きな集約プロジェクトと言えど何をしてもいい訳ではない

>>313
みたいなものが積もり積もったのもあって
英語化した外人への怒りとして表に噴出したんだろ
こういう人たちは国を問わずへそを曲げると面倒だからな

逆に考えて外人に日本語で謝罪メールなんてしないだろ？
お前ら何様なんだよ、って感じでキレたとしたら、俺は解る

いやそれでキレるならキレるで結構なんだけどさ
キレた上で他人様のもの拝借しっぱなしってのは通らないよ
それただの泥棒だから

「messへソースコード流用して(C)無し」の方は100%流用した輩が悪いと思う。
で、mess側で日本語わかるヒトが代表としてXM7作者とコンタクト取ったっぽいことは
ツイッターログが残ってたのだが、途中からメールのやりとりに変わったようで、
どういう結論に至ったかまではわからない。

未だにmessに該当コードが残っているのであれば、
1.決裂した
2.納得して流用したメンバーへ警告したが聞いてくれない
のどちらかなんだろうけど、可能性としては1.の方が大きい気がする。
だとするなると、作者側から見ればmess関係者=悪、という構図に見えてくるんじゃないか？

>>314
で、英語化した外人も、一応messの関係者なんだよ。
とは言ってもコードを書く人じゃなくて、コンタクトの中継みたいなことしてる人っぽいんだけどね。
なので、作者側から見れば同類に見えるのはある程度は仕方ないとは思う。

>>311
> エミュ元のマシンを後世に残す資料として作った的な事を言ってながら
これは初代作者のセリフ。一緒くたにすべきじゃないと思うが…。
> 外人が英語化したら日本語でメール寄越さないと読まないとか
最初は英語で応答してたっぽいよ。
しかし、さすがに何度も翻訳させられ続ければ疲れるんじゃね？
作者側に得るモノでもあれば別だろうけど、ぶっちゃけ得るモノないだろ？
XM6 type GがWeb公開辞めた理由も似たようなモノだったみたいだし。
ちなみにtype Gが公開辞めた時の起爆剤になった人って、
XM7英語化した外人と同一人物だよ。

まぁ作者側からみたら仕方ないよな
どちらが作者で主導権握ってるのか分からないような状態で扱われたら
たとえ日本人でなくてもヘソを曲げるよ
かなり過去の話になるけど海外のエミュでソース流用に腹を立てて
同じ様に公開停止した物はあったしね

残念ながらこの状況で作者に不満を向けるのは
騒動に巻き込まれて入手が出来なくなった不満を言葉の通じる日本人作者に向けて
対応を緩める事を期待してる様に見える

つーか、messこそ日本語対応汁
対象の中に国産マシンがかなり増えてるのに日本人は誰も使ってないどころか
実装状況自体把握していない気がする。
一緒に名前が出てくるmameはかなり認知度高くて日本人作者による派生も多いと思うんだが、
この差は一体なんなんだ？

対応設定の多いPC、コンシューマを
messのようなマルチエミュでなんかやってらんない
それにあれ、ほとんど読み込みオンリーじゃね？
機能性は全く考えていないんだか・・・
アーケードならまだしも、ソフトの管理もしづらいしな
messと同じだと思うけど、もうファイル名指定されてる時点でね

>>318には同意だな。

単にXM7最新版欲しいだけだったら、
作者にXM7最新版くださいってメール送れば送ってくれるんじゃね？
いや、知らんけど。
ただ、ソースコードに対する対応はそうする、っていうような旨のこと
書いてたはずだから、バイナリも同様なんじゃないかって思ってさ。
モチ最低限の礼儀さえ守っていれば、だろうけど。


mess側は最低限の礼儀としてどこかに(C)表記を付加すべきだと思う。
READMEにはソース再利用時の条件としてそう記述してあるわけだしね。
それだけでもまだ現状よりマシになると思うのだが。
まぁたぶんXM7作者はもうそんなことじゃ納得しないだろうけど。

たけがみりうも結構なDQNだから、話がややこしいんだよな

この作者って確かdashのときも大人げない理由でキレてたよね
挨拶がなかったとかそんな感じでHP上で名指し批判
この一件耳にしても、またかとしか思えかったな

外野が推測で議論したって詮無きことだよ
黙って見守ろう

2chで名指し批判されてもなあ。
どうせ必要な人はとっくにダウンロードしてるんじゃないの？

別にXM7の最新版が欲しいとかじゃなくて
作者の行動に疑問を感じてる人がいるんだろう

>>317
英語化した人はmess方面から排除された可能性がある。
仲介を試みたが、排除されたのならまだいいのだが。

>>326
それこそ忘れられる権利とかなんとかで大人気ないんじゃね？

>>327
「英語化した人」と「mess側で日本語わかるヒト」は別人だよ。

エミュ自体がパクリなのに何を言っているんだか

パクリという日本語を理解していないキミは在日だね

またヤーヤー言うから消えたじゃないですかw

微妙に私の方にも飛び火してたり（苦笑）

>>333
すいません、後日目処が立った時点で正式にご連絡しますが、私の方でFM-7を適用させて下さいな。
後、非Win32化とかもやります（というか、こちらがメインになりそう）
よろしくお願いしますm(_ _)m

パクった側が黙殺続けてるのも腹立たしいが、パクられた方の態度もアカンなぁ。という感じですね。
一から作り直すつもりでいたりとかOpenMSXの枠組みを使おうかとか検討したけど、
武田さんの作られた枠組みを使ってLinuxなどに移植するのが一番スッキリ書けて穏当かな？とかとか。
それにしても、リリース秒読み状態にまで一年以上かけてやっと持ち込んだのに、これかよ('A`)という感じがふつふつと。

>>334
了解です、よろしくお願いいたします。
差支えなければ、私のソースに統合させていただけますと幸いです。
また、統合後、私の方で弄らせていただくことがあるかもしれません。
その点ご了解いただけますと幸いです。
（FM-XとかFM-Xとか、あとFM-Xとか。I/Fとソフト入手できれば。）

仮想マシン側の統合については、ご了解いただければ問題ないと思いますが、
非Win32化については、ソース統合できるかは、見てから判断ということで
お願いいたします。

ちょくちょくWin32側のソースも弄ってますので、私自身の作業の足かせ
（表現が悪くてすみません）になりそうな形だとちょっと難しいです。

Linux対応で気になる点としては、Win32 APIの置き換えと、
エンディアン対応かなと思います。

Win32 APIの置き換えについては、以前たなむ様が、SDLかQt化して
Andoroidに移植された実績がありますので、ご参考ください。

エンディアン対応は、common.hのpair構造体のように、気にしてる
部分もありますが、全然気にしてない部分もありそうです。
GCCだと、__BIG_ENDIAN__マクロを使って判定すればいいのかな？
私の方でも、気が付いた部分はGCCに合わせて修正しておきます。
（VC++/Intel CPU環境だと、意味のないコードになってますし）

ちょっと先走りし過ぎですね（苦笑）

ご連絡いただけるのを楽しみにお待ちしております。

よくわかんないけどコモンソース側でFM対応が進んでると考えていいのかな？
いっそR系で最新linuxが動いたりするのを期待してはいけないだろうか？

>>340
今朝から始めました(；´Д｀)
XM7/SDLとゆうかなりピーキーなXM7をやっていて、
Windows考えなければ来月中には1.0だせる所に来ていたのですがー(;¬_¬)
今回の騒動で厭になったというか、ソースコード出さないのが特に厭になったというか。
色々考える所があってこちらをやる事にしましたよ。
独自のデバイスをどうするかが問題ですが。

よりによって、一番トラブルになってるプロジェクトに乗り換えるなんてｗ

>>342
簡単にソースコード非開示になるわ、外国とロクな揉め方しないわよりはマシです(；´Д｀)
パクった方が悪いというのだけではすませにくい物を感じましたから(；´Д｀)

GPLで公開されていれば、何かトラブルになってもなんとか出来ますから（FM-7に限るならばですが。他はやらないかも知れない）
仮に致命的なトラブルがあって、プロジェクト自体がなくなったとしても、GPLで配布されていたのを基にする限り、
トラブル起こしたパートと後は問題ない所を流用して一からでなく作り直すとか出来ますからねー。
XM7ではそれが出来ない。

今回も、色々頭おかしい事を考えておりますので(；´Д｀)
とりあえず、私のGithub使って移植準備始めてますので。
どれか一つが動くの、１ヶ月以上かかるかなー（遠い眼）

そうそう、開示が続いていたらMess方面の説得のやりようもあったんですがね（ﾎﾞｿ
日本語以外云々とか、問題解決する気がないのかと（ﾎﾞｿ

そもそもなにか対応に変化でもあったのかな？
開発版等の限定公開なら古今東西よく有る話で
騒動というより情報不足による疑心暗鬼の過剰反応なのでは？
例えばブログ公開品なんかは容量等の都合でリンク切れしてない方が
ラッキーな感じがするんだけど？
ミラーサイトなんかも、開発版とか移植とかは元々カバーできてないし
規模が小さくて一番参考になりそうな初期の奴が結構消えてて、
板的には残念の極みなのとかも多いなあ。

>>345
多分対応は前と変わりない。

けどねー、パクられました、元は公開止めました。
で、オープンソース界隈の連中を説得出来るか。
といったら、一次公開先が対応するならまだしも、横から入って移植の許諾取ってるだけの私には無理ですねー。

ソースとか向こうに渡してよくない状態で、しかも昔のソースも非FOSSだから引き出して余り良くないのに、
具体的にどこをこうパクっているから早急に直せ。なんて言える程私は肝っ玉太くないっす(；´Д｀)
ま、後は日本語（ry

お互いのために海外でも通用するライセンスを明記した方がいいと思うけど
それが無理ならソース公開やめるしかないかね

>>346
後、mess界隈はガン無視臭いですね。
とある外国人が向こうに連絡取ったら、罵倒された末にmessコミュニティー追い出されたみたいな事を言っていたし（私は英語下手だから間違えてないと言い切れないけど…）

>>347
私は、そう思いますよ。
FM-7ってポルトガルだかスペインでも販売されたらしいですし、せめて英訳は必要だったと思いますよ。
ま、覆水なんとやらな状況ですがね(；´Д｀)

貢献者が複数居るコードなんかは当事者でも連絡つかない事も多いから
ありのままの形態以外で配布となると結構大変なんじゃないの？
只の潰れたアプロダのライブラリ引越しでさえ二の足踏む人多いのに。

ここ最近の活動中心がエミュではなくレトロDTMになってるdashの人です。

>>Artane氏
ちょっとArtaneさんのツイートを拝見させていただき、
Justin氏、Anna氏によるmessへのアクションと反応の箇所を読ませていただいたんですが
（ただし英文翻訳面倒だったので最後のJustin氏の文章しか読んでないが）
このツイートの件(反応がなかった件)って、りう氏に伝わってるんでしょうか。
伝わった上で今の状態な気もしますが…。

なんというか、現状ソースパクったmessの開発者一人勝ちって状況がなんとも腹立たしい。
これは今りう氏がソース非公開したところで解決する問題ではないですよ。
既にL62のソースは流れてるわけで、不正な形で流用する(身も蓋もない言い方をすればパクる)ような人にとっては
なんの弊害にもなっていない。
今まさに「正直者がバカを見る」状態になっているのがなんとももどかしい…。

この漫画家さんですか？
http://blog-imgs-19.fc2.com/m/a/n/mangabruce/TOMA-barairo.jpg

正直者がバカを見るというか、そもそも関係者の名前は降臨含めて色々出てるのに
肝心のやらかした奴の名前が出てない件について。

昨今話題のセキュリティーホールなんかも、無保証ライセンスのせいなのか、
誰のチョンボとかって話は聞いたこと無いな。

＞不正な形で流用する(身も蓋もない言い方をすればパクる)ような人に
キチンと非難の言葉を掛け続けましょう。

怒って公開停止も理解出来るけど
サイト自体を見れなくしてもトマ氏も言われてるように
「正直者がバカを見る」状態ですし
サイトはそのままでLink先の物をサーバーから削除
するだけで良いと思う
若しくはサイトそのものに顛末と非難の声明を表示させれば良い

そんな面倒臭い事させられること自体がバカらしいワナ。
まあ作者の考えはわからないけど、沈黙というのはむしろ猶予に思えるけどね。
筋さえ通せばとりあえず収まる話ではないだろうか？

通すのは向こうで、向こうは通すつもりが全く無いみたいだけどな。

>>347,349
XM7/XM6ライセンスの英訳明記が必要かどうかという点は、あればあるに超したことはないが、
無いからといってライセンス違反が正当化するわけではないよね。

まず、XM7/XM6のREADMEを見ると、バイナリ・ソースそれぞれ再配布条件が異なり、
・バイナリは「無償かつ書庫を改変しない場合に限り」認めているが、
・ソースは「無断転載を禁じ」ている。
で、ちょっとググれば出てくる外国エミュサイトいくつかみたところ、バイナリの転載は無数に見かけるけど、ソースの転載は見たことがない。
ソースに関しては必ず公式サイトへのリンクになってた。（少なくとも私の見た限りは）
外国語サイトでソースを転載しているところがない点からREADMEが日本語のみでも正当な主張になってると思うんだ。

>>354
> キチンと非難の言葉を掛け続けましょう。
どんなに「非難の言葉を掛け続け」たところで
「パクったmessの開発者」がシカト続けている限り
「非難の言葉を掛け続け」る側の負担になっているに過ぎない。
>>356
> そんな面倒臭い事させられること自体がバカらしいワナ。
自分に得るモノがないのに、わざわざ自分の意志を英語に翻訳してコンタクトとること自体、
価値が感じられなければ正直なところ負担でしかないと思う。

XM7も(ぶっちゃけXM6 type Gも)結局はここに負担を感じて閉鎖になったんだと思う。
それが正しいかどうかは別として、理解は出来るよ。
ぶっちゃけ、りう氏、GIMONS氏、Artane氏にこの負担を負いつづける義務は無いと思う。
非難されるべきはmess側だし、りう氏に指摘する点があったとしても、外部はmess側を非難すべき。

連投失礼。

ただ、私個人の活動としては、Artane氏の>>341に近い弊害感はあるので
ぶっちゃけL63以降はソース非公開でいいんでL62のソース公開は継続してほしい、っていうのはある。
私自身が欲しいとかそういう問題ではなく、ウチのサイトに記載してる
> 後続の開発者・協力者が現れるのに期待
出来なくなるのがもどかしい。ここが一番の理由。

Artane氏の移植が完了したら、dash部の移植に協力出来るかなぁとか考えてた点も
あったので、ぶっちゃけすっげー残念過ぎる。
こういう所まで全て含めて「正直者がバカを見る」なのです。

>>358
結局のところ、原著作者のライセンス条件がそれで、継承した立場である以上
勝手にライセンス変更許可するわけにはいかないでしょうなあ。
（GPLで）再公開してほしい箇所があるのならば、それにメリットを感じる人が
その部分の作者を見極めた上で個別交渉する必要があると思われ。

そういや、なんかのエミュでたまにソースのバージョン1つズレとか見かけるな
そういう意味もあるのかな・・・

>>361
それは単にソースは1個前の公開するってスタンスじゃないの？

実験版ソースだと破棄する可能性があるから、それでパッチとか貰うと逆に面倒だったりするんじゃない？
評判が悪くないのを確認して清書版ソースに盛っていくタイプとか？

逆に過去は振り返らないタイプだと、最新版に当たらないパッチは放置されたりして、
パッチ投げるほうは賽の河原でしんどそうだよね。
結局チキンレースで、使われない古い機能はズタズタで劣化しまくるオチ。

>>359
どうもです。
トマさんみたいな方がいらっしゃってくださるようなので、当面（ペースは落ちるでしょうが）XM7/SDLの開発は継続しますか。
1.0を出した後のことは未だ考えませんが…
とりあえず、dash部分の取り込みは、時期を見てやっていきます。検証環境をどうするかが頭が痛いですが、場合によっては1.0を出す前に現行のコードをマージしてみることも考えます。

多分ですが、Common Source Projectの方では最初から必要な実装を入れて出すことになるでしょうね(^_^;
2HDはともかくプリンターなどは(^_^;
後、トラック部分やID部分に色々情報書いてるディスクと言うのが少なからずあるので、そこらを忠実に記録できるフォーマットを作りたいなという気もしてます。
PC/ATのFDCはMB8877系と相当違うので、kyrofluxがないと意味がないでしょうけど…（そして、未だアレを買えてない）
実機が動かせて何らかのコピーツールが行きていれば意味があるか。

FDC抜きでマイコンでサンプリングして、
後からPCで処理しようってのが何処かのサイトであったっけ？

プリンターは専用DLLにデータを投げ渡す事にして、
そっちのDLLの中でプリンタの挙動をエミュレートしてもらう設計にして、
エミュ本体(XM7)の方はプリンタがつながっていないときの挙動を返すだけのダミーDLLを付けるとか、どうでしょう?

プリンタが必要と思う人が自分たちでプリンタの挙動を実装してくれよってスタンスで。

っていうかそれこそコモンと共通化すればいいんでないの？

88の増設FDユニット単独のエミュレータとかあったら面白そうだな。
エミュ本体からは仮想パラレルとして繋ぐとか、そのままFD実機がつながるとか。

>>364
なんか継続要求したような形になってしまってすみません（汗

> 後、トラック部分やID部分に色々情報書いてるディスクと言うのが少なからずあるので、
> そこらを忠実に記録できるフォーマットを作りたいなという気もしてます。
一応SFDC対応とかバブルメモリ対応とかしてる関係でfdc.c/hに関してはだいたい把握できてるので、
仕様さえはっきりすればお試し版という形でdashへ先行実装する形などで協力出来るかもしれません。
仕様考察自体への協力でもいいですが(^^;

>>369
いえいえ。
1.0を出さずに終わらせるというのは私も心苦しかったので…状況が状況だから終わらせるのもやむないか。と諦めかけていたので。
まぁ、色々とやりますが、Common Source ProjectのWindows依存部分を別のツールキットに移植するのとFM-7(77やAV系はあとまわし？）をとりあえず動くようにするのが先になりますが。

後、業務連絡
https://github.com/Artanejp/common_source_project-fm7
まだまだビルドでコケますが、暇を見て作業したものを、こちらの方にミラーしていきますので…これは、XM7/SDLも同じ。
もし、何か弄った物があればpull request出してみてください。只、作業的にgitのマージ作業は慣れてないので反映できるかどうかは微妙ですが。
最初に動くターゲットはX1を想定していますが、果たしてどのくらいで出来るやら。

>>369
ついでに。
>仕様さえはっきりすればお試し版という形でdashへ先行実装する形などで協力出来るかもしれません。
>仕様考察自体への協力でもいいですが(^^;

ぶっちゃけると、トラックデータをシャドーで持たせるのでもいいのかなと思うんですよ。一個のイメージファイルが1MB近くになりますが。
これには、FM-7だったらFM-7でファイラーを書けるコピーツールが事実上必要になる訳ですが（もしくは、kyrofluxなどが吐いたデータからでっち上げるソフトが必要になる）、
・インデックスホールから一周分のトラックイメージとバイト数
・各セクタのIDのインデックスホールからのバイト・ビット単位の位置（絶対位置と称するか？）
・セクタのID→セクタデータインデックスのサイズ
・可能ならば、各セクタのサイズ（これは、途中でセクタをぶった切って次のセクタやデータ無しのIDを入れるというフォーマットが結構あったから）
・データCRC
・すべてのセクタが終わった後の領域の大きさ（これは必要か？）
があればどうにでもなるんですよね。
ビットずれ系（コロコロとも呼ばれてた）のデータは再現を期待しないということで割りきって、後はどう効率よくトラックデータを圧縮する表現を設定できるか？ではないかと。

タイム情報というか、インデックスホールからのオフセットに相当する
ウェイト情報を持たせればどうだろう？

>>371
＞ビットずれ系（コロコロとも呼ばれてた）のデータは再現を期待しないということで割りきって

まあ、コピープロテクト以外では使わない機能なわけで、再現できなくていいとは思うのです。と横レス。
1MB近くのサイズになるってのは、2Dの320kB（または360kB）ディスクの場合ですよね。
他機種の、たとえば2HD1.2MBのディスクだと約3MBになるぐらいでしょうかね?

kyloが密林あたりで安くてに入れば欲しいな…

>>366
まー、プリンターの線の挙動を見てcupsなりwinprintなりファイルなりにビットマップをリダイレクトする何かを作るとか言う辺りですかね。

dllは別に作るようにして…コモンソースプロジェクトのライセンスと被らないようにダミー作りますか（但し優先度はかなり低くしますが）

>>375
一部の機種ではプリンタインターフェースに他の周辺機器つなぐ用途があるものもあった気がするので、
もしかすると万が一、そういう機器のエミュレートを求める人が出てくる可能性が……たぶんいないか。

大半の機種はプリンタインターフェースは出力専用で、それ以外の周辺機器の接続ができないんだけど、例外的な機種もあったはず。

というか、普通にプリンタをつなぐ動作のエミュレートでも需要は極めて低いと思うので、せっかく作っても需要がない可能性はあるんだけど、
将来の拡張の余地がある方が無難な気がするので。

双方向セントロを扱えるデバイスって今時のモダンOSにはなかったりするの？
んじゃFT245エミュとかになるんだろうか？

>>376
確かに、FM-7だとジョイスティックとかつなげられましたね。仕様は知らないけど。
そう考えるとDLL化というのは結構有利かもしれないですね。

ついでに、X1のスクショを投下しときます
http://i.imgur.com/QSuXTbe.jpg
まだまだ問題含みでまともなものではないですが。

FM-7の電波新聞社ソフトには必須でしょう
プリンタポートのジョイスティック

>>377
AT互換機の大半は双方向セントロ（ただしピン数削減の「準拠」版）だけど、
エミュレート対象の古い機種で出力専用で片方向の機種が多かったんじゃないかと

8255でセントロI/Fを実装してる機種なら基本は双方向だけど、X68000含め、片方向の機種が。

それは釈迦に説法だと思うけど、 >>375の話だと
なんかもっと高次の話をしているような気がしたんで。

昨夜コメントしようとしたら[昔のPC]全体がめっさ重くて無理だた…

>>371
似たような仕様考察はしてました。
% トリップ消えてたけど、>>369は私です（言うまでもなさげだけど汗）

最初の32バイト+各トラックへのFAT部はD88(D77)同様で、
各トラック部はトラックデータをそのまま持つ、の形がスマートですね。

ただ、D88でいうセクタヘッダの6〜7byte目(deleted_markとstatus)のような
セクタテーブル前にヘッダを置いておくなど、細工できる余裕を
用意しておいたほうが、後々のことを考えた場合都合がいいかもしれませんね。
トラックヘッダが必要かどうかは要検討ですが。

とりあえず考察点として思い当たるのは
・deletedマーク含んだステータス
・PRE AMBLE/POST AMBLE
ってところかと思ってますが、
POST AMBLEはGAP4しかないので、
「トラック情報の余ったところ=GAP4」という仕様にしておけば、
実際のGAP4が0バイトでもイケるはず、とか思ってます。

とりあえず、D88を拡張する形から試行錯誤してみようかなと思います。

武田さん、GitHubあたりでコード管理をしてくれないものかしら。
ソースに手を加えたいんだけど、修正作業よりメールでやり取りする
労力の方が高コストなのです。

でも、基本的に自分一人で開発を進めたいというのであれば
手は出さずにバグ報告だけしていきたいとおもいます

報告や修正しても採用するかどうかは大本の匙加減だかんなー
結局バグは自分で治してそれでいいやで終了w

>>381
仮にどこかの誰かがプリンタを実装したいと考えた場合に、
生データだと出力先の挙動がプリンタ制御コマンドに依存するので（もちろん現存プリンタとの互換性がない）
このプリンタならこういう挙動、みたいなのをエミュ本体じゃなく外部に実装して、周辺機器つなぎかえのごとく入れ替えたらいいって思っただけなんです

必要になった人が必要な機種の制御コマンドのマニュアルとか見てプログラムできるかもしれないし、
必要ないならデータ受け取って無視する（ハンドシェークだけ実行する）ダミーDLLでいいし、
プロテクトがわりのドングルを付ける機種があったりするならドングルのエミュを実装してみてもいいけど、
そういう部分はエミュ本体から切り離した方がいいんじゃないかなあと。

エミュでプリンタを使いたい人がいるとしたら、接続先プリンタの挙動を模してビットマップ化して画像ファイル化するか、
作ったビットマップをプリンタに送りつけて印字するかどっちかの挙動をさせたいことが多いんだろうけど、
それ以外の用途がありえなくもないかなと。

>>386
要は>>368のプリンタ版だよね。
っていうかFMPR自体はwin2k3辺りでも普通に使えてた気がするけれども。

漢字ROM抜くのは面倒だからスキャナで読み取るとかになるんだろうか？

Git使うなら勝手に更新してもリクだけ上げて
あとは本家が取り込んでくれるかの様子を見ればすむけど
設定したければコーディングルールも設定すればいい

ただ取りまとめ作業に手をとられる時間も確実に増大していくから
本家が更新する時間がとりにくくなったりすることもあるし
待ちきれずに派生が出まくるってものこれまた面倒だったりするから
全てがいいとも言えないんだけどね

スクショ貼っておくよ
http://i.imgur.com/qhu1bau.jpg
音がなんとかなった。
絵周りで特定のタイミングで落ちたり固まったりする。
後、ズームが手動ｗ

>>389
こっちが落ち着いて、なおかつXM7が1.0に出来たら、パッチまとめるのこっちでやってもいいかなと書いてみるテスト。
後、コモンソースコードの方だけでもGUIにAgarじゃなくてQtでも使ったほうがいいのかなぁ(；´Д｀)
GUI Toolkitを変更するのって面倒くさいからアレだけど、Agarはバグ多いからなぁ(；´Д｀)
やるなら今のタイミング以外では厳しい気がしてならないし。と言うか、面倒くさくなってやらなくなるの確実だし(；´Д｀)

…20MB位アップできるうｐろだってaxfc位なのかな、そう言えば。

XM7の配布再開されたのに、なんでまだtakedaのクソソースを弄ってるの？

XM7作者の機嫌に振り回されるのとどっちがいい？

他人のフンドシで相撲とるやつはクソ

へのつっぱりはいらんですよ

GitHubへの移行はちょっと勘弁してください。
作業のやり方を変えたくないというか、新しいツールの使い方を覚えるのがおっくうというか（苦笑）
年取っちゃったかな、ちょっと踏み出しにくいです。

パッチは大歓迎です。

はじめましてだとか時候の挨拶だとか、メールのマナー的なことはうっちゃって、
パッチ（diffでも修正したファイルそのものでも可）と、修正の意図と、
出来ればどの版からの修正かと、更に出来ればテスト方法を箇条書きにでも
書いて送っていただければ、後はこちらで作業します。

あ、history.txtにthanks書くときに、どんなお名前を記載すればいいかも
書いていただけると助かります。

ただ、送っていただいたパッチをそのままの形で取り込めるかというと、
こちらで弄らせていただく場合もありますので、その点はご了解ください。

各ペリフェラルなど共通モジュールに個々の機種固有のコードを入れるなど、
他の機種のエミュレータが動かなくなってしまうような修正とか、
ちゃんと動いてはいるけど、元々の設計思想や仕組みを無視した実装とか、
（例えばデバイス間の信号のやり取りとかイベント処理などを、
既存のやり方を無視して独自のやり方で実装しちゃうとか）

そういった箇所があったら、私の方で勝手に弄らせていただいてから
取り込む、という場合もあるかもしれません。

>待ちきれずに派生が出まくるってものこれまた面倒だったりするから

派生するはむしろ歓迎です。

現在、Common Source Code Projectでリリースしているバイナリは
74個なのですが、これだけの機種を、１つのソースで破綻せずに
実装するために、かなり苦労してたりします。
それでも一部の機種が壊れてるのに後から気付くことも割とあります。

そういう苦労に付き合っていただくのも申し訳ないです。

ある特定の機種（今回の場合はFM-7）のために派生していただいて、
他の機種のことは気にせずがんがん開発していただいて、
ある程度開発が落ち着いてきたら、私の方に声をかけて頂いて、
そうしたら私の方で整理した形で取り込ませていただく。

これくらいのゆるーい感じで同期をとるくらいがやり易いです。

えと、>>397は、新しい機種の実装の場合の話です。
リリース済みの機種に対するパッチについては、もっと細目に
投げつけて頂いてもOKです。というかプリーズ。

ただ、即日反映を期待していただくと、ちょっと困ります。
家族が増えたのと、本業がめっさ多忙になってきた関係で、
作業時間が中々取れなくって。

>>391
武田氏のは既に一部動いたけど、
そんなに酷いコードじゃないよ。
というか、私の趣味（？）的には武田氏のコードの方が出来良く見えるよ。
何より、構造がわかりやすいから、バグを仕込み難いのがいい。
たけがみ氏のは、動くものとしては、確かに出来がいいんだけど、一歩間違えるとクライン空間にハマりかねないシビアさがある。
ま、今はQtというGUIで武田氏のを動かせるようにするのに注力してますが。
これが上手く行って、最低限のバグをなくせて、ある程度のマシンが使えるようになれば、たけがみ氏の方を進めます。
今まで6年弱XM7をやって、私の作業範囲がぐちゃぐちゃ過ぎて改善がまともに出来なくなってるから、出来れば可能な範囲で（QtとSDL前提で）書き直してもみたいですし。

>>395
えっと、私の作業については、Githubで続けてかまわないですよね？
なるべく、本家に影響しないようにかいていますし、Githubをバックアップに使っていますので、どうか、そこはお許しいだだきたく思いますm(_ _)m

takedaのソースは回りくどくてキモいんだよ

ソースも読めない奴がw

（かなり読みやすい部類に入るよね・・・・・・）

>>400
あくまで私はgithubを使わないと思います、というだけの話ですので、
もちろんOKです。
というか、既にちょこちょこbug fix系は取り込ませていただいてます。m(_ _)m

>>399
業務連絡。
_assume(0);とか_TCHAR関係とか、VC++固有の処理について、
VC++以外の環境のための作業を私の方でも進めています。
結構もりっと書き換えてます。
Artane.様の方の作業とぶつかってしまいましたら御免なさいです。

＃コードが読み易いか否かについてはノーコメントですが、
＃回りくどいのは否定できないかなあ。
＃色々と抽象化されてるので、コードだけ眺めてても、どこを起点に
＃どのように処理が進むのか、追っかけにくいかもしれません。

>>405
# やっと書き込めた。最近、DDoS酷いから…
了解です＞武田さん
バッティングしたとしてもお気になさらずに…

何はともあれ、こちらで都合が悪くなった所からとりかかってるので、そんなにお気になさらずに…逆に気がつくことのほうが多いと思います（私が）

# 最近暇に任せて突貫工事でやってるので意味不明な文章だったら申しわけないですm(_ _)m

抽象化は確かに凄いですが、一度腰を据えて読み直したら結構スッキリしてたので驚きました。
沢山勉強になりますです（元々組み込みとかの方だったので泥臭いコードばかりやってきてたと言う）。

これはひとりごとでもあるんですが。と言うのも、
こちらがバグ仕込んだか・もしくはQtのキー入力体系がリアルタイムに向いてない事から来てる可能性が低くないどころか高そうだから微妙なんですが、
キーボードガンガン押してるとevent.cppの296行辺りで無限ループ（なのか？）にハマるってQt側全体が刺さる事が結構あるんですよね。
やっぱり、キー入力もSDLに任せたほうがいいのかなぁ(；´Д｀)
出来ればQt側からスレッドを廻したいけど、QThreadの使い方が上手く行ってないので、SDLのスレッド機構で強引に廻してますから…

後、リセットボタンを押してる時間がシビアなようで、X1だと頻繁にリセットが速すぎるから電源入れなおせメッセージが出ますね。
あ、今の所X1 TurboZでしかビルドできないのでそこです。

ひとりごと序でにもう一つ。
Agarを使ってる訳じゃないんだから、SDLはVersion2にしてもいいことに今更気がついたので、そちらの方向で行きます。
SDLはジョイスティックと、必要ならばキー入力。マウスも巻き込まないといけないとなると厄介ですが、どうせ音声はSDLでしか出しようが無いですし。
ではでは、つまらん話をして申し訳ございませんでした m(_ _)m

あ、そうそう、現状ではQt4とOpenGLが必須になってます。
色々作業したうえで、DirectX9をWindowsでは（多分、SDLかQt経由で間接的に？）叩ける用にします。
非Windowsの場合はSDLかQtのサーフェースで。
今までXM7で書いてきた非GL向けのコードを捨てるのも勿体無いですし。
それと、FM-7の実装に入ったら、（とりあえずFM-7に関しては）GL+OpenCLの選択肢も提供しますよん。
PCGやテキストVRAMやスプライトを持ってるマシンとかのほうが、コードが書ければOpenCLの恩恵は大きいはずですから、枠組みをこちらで作成するのは無駄にならないでしょうし。
今後は、比較的性能の低いCPUコアに、そこそこのGPUを統合する機械が普通になるでしょうしね。

基本的にシングルスレッドで動いているので、
仮想マシンを１フレームだけ回して、
キー入力とかメニュー操作とかを受け付けて、
が交互に動くことが前提になってます。

UI側がマルチスレッドになっていて、仮想マシンが動いている間に
キー入力とかメニュー操作とかを受け付けちゃって、
それが原因で、イベントのチェーン操作中にevent::insert_event()が
呼ばれて、チェーンが矛盾した状態になってしまった、とか。

vm->run()の処理の実行中に、emuクラス側からvmクラスを弄ると、
多分おかしなことになるかと思います。

＃ちなみに、turboZは開発用にvcprojを入れてますが、まだ実装中です。
＃固有のレジスタは実装したけど、新しい画面モードの描画処理が
＃全然入ってなかったりします（を

オマケ。
ttp://www1.axfc.net/u/3391979.7z
特にパスワード等は付けてません。
ビルドは、Debian GNU/Linuxの"sid"でやってます。
後、.ascと言うファイルは、GNUPGで署名されてるファイルですので、必要に応じて。

>>409
ありがとうございます。
確かに、キー入力部分（とUI側からの干渉）は非同期になってます。
だとすると、SDL_semかもしくはQtのセマフォかmutexでロックしてるのを拡大したほうが良さそうですね。
（実際、既にリセットシーケンスの時にはemu->run()はセマフォで保護してるので、それを危なそうなところにも適用するだけですが）
その部分は、こちらの方でぼちぼちやっていきますね。

>>409
キー入力で刺さる件、仰るとおりの理由だったようです。emu->LockVM() ・emu->UnlockVM()という構造で、
emu->run()の間のロックを取っておくようにしました。未だ、ファイルとかそこら辺への適用が出来ないですけど。

X1はテンキー側の'='(イコール)どこかにマッピングしないか
アスピックの高速モード切り替えぐらいにしか使っていないが

テンキー側の','(カンマ)の使用例は知らない

>>413
そこがすごく悩ましい所で、キー入力をQtに頼んでる間はテンキーとフルキーの区別がつかないんですよね。
Qtはあくまで、「何の文字を入力したか」を吐いてるので、「何のキーをおしたか」ではい。
で、それを解決するのに生のスキャンコードを取れる関数が用意されてるんだけど、これを下手に使うと移植性がなくなってしまう。

なので、キーボードに限ってはQt任せをやめてSDLに受け持たせる事ができるかどうか検討しますね。
この部分は下手に手を出すと、QtとSDLでキーコードの取り合いになってあばばばば…となってしまうか、逆にキーコードを全く拾わなくなるので。

但し、結構調べないと難しいので、メニューを実装し終わってからにしようと思ってますので、若干の間お赦しを…m(_ _)m

いっそキーエンコーダーのエミュレータ作っちゃえばどうだろう？
対象をソフトウェアキーボードで表示してクリックしたところに対応させたいキーを押して
スキャンコードを登録出来れば、別にどんなキーコードでも大丈夫なのでは？

いっそ皆で死んじゃえばどうだろう？
でも皆まだ死にたくないだろうから、オレだけ死のう
死ぬる

オレが死ぬる

こいつはたまらん

とりあえず、8801MAもビルドできるようにしたよヽ(´ー｀)ノ
後、ジョイスティック使えるようにしたヽ(´ー｀)ノ
Qthreadの使い方がよくわからないので、SDL_Threadですが。
とりあえず、100日間で消されるけど
ttp://www1.axfc.net/u/3392556

乙、と言いたいんだけどは期間限定ロダに投棄というのは、
>>335でアカンと言ってた削除と具体的にどう違うのかよくわからんな。
予告汁ってこと？

周辺機器って、現物接続を基本にすればいいんじゃないの？
それをエミュレーションする形の仮想デバイスドライバ付けてみるとか。

>>418
単純に、スナップショットのビルドで、とりあえず動くというもので、色々追加や変更されていくのが確定してるからです。バイナリは、評価用段階というか…
要は、まだまだこれから頻繁にアップするというレベルの出来なんで、固定させるのもおこがましいかなとかそういう程度の軽い気持ちです。
拙ければ、今度から無期限にしますよ。

>>419
それは考えてなくはないけど現物云々というのがハードルが高いから当分無理ですねー

現物と言っても当時の純正骨董品より、
実機で対応可能な現在も入手或いは製作可能な代用品とかが
同様に動けばそれでいいんちゃう？
いっそ現行機器対応化を支援できるようなエミュレータがあれば面白いかも？

とりあえず本家の1/14版に（一応追随）ヽ(´ー｀)ノ
あと、MZ二つヽ(´ー｀)ノ
ttp://www1.axfc.net/u/3393059

で、仕事をお留守にしすぎてたので、一週間か二週間くらいペース落とすと思います。

>>422
それはそうなんですが、エミュレーションをある程度やってからにしたいです。と言うか、移植性の壁にぶつかるので優先度低いですねー、個人的には。
生データをデバイスドライバ等に投げるというと…とりあえずはプリンタよりもシリアルポートを偽コンソールとかパイプにつなげられるようにするのは、優先度低いけどやってみたい所です。

後、＞武田さん
この書き込みのリンク先の中にあるドキュメントにも書きましたが、一部の物理フォーマットをエミュレーションした（セクタサイズが1024バイトとかかな？）仮想ディスクやソフトでデータ書くとバグりますね。
多分、(FDCではなく）diskのエミュレーションが特殊なフォーマットに対応出来てないか、もしくはZ80で実装できてない未定義命令（があるかどうかわからないですが）に絡んでそうな感じです。
デバッガが実装できてればお助けできると思いますが…

パイプレベルだとわざわざ移植とか考えなくても正直wineにお任せでいいような気も。
UARTでUSARTのエミュレートは難しいだろうし、マトモにやるなら実はシリアルの方が大変じゃないかな？

>>423
ディスク書き込みで拙いのは、どの機種のスタークルーザーのユーザディスクでしょうか？

セクタIDのNを弄って、実際のセクタ長より長く見せかけているディスクがあって、
（MZ-2500の九玉伝など）
トラックイメージを作るときに、本来のNの値を推定するための処理があるのですが、
こいつが何か悪さしてしまう場合があるのかな、という気がします。
例えば、１トラック内に異なる長さのセクタが混在してる場合とか。

とりあえず、Qtの生スキャンコードでキーボードをなんとかしてみた
ttp://www1.axfc.net/u/3393652
109キーボード以外だと不都合出るかも…

>>425
機種は、X1とPC88です。
他のエミュだと書けるのですが…

>>425
追伸。
仕事仕上げてからになりますが、ディスク関連は私の方でも見てみたいと思います。
セクター長混在やFDC騙して色々データを書くのは、あの時代のソフトでは普通にあった感じですから、
今後の事を考えると、色々機能を追加するのは避けられないでしょう。
（個人的にはMB8877しか知らないですが、詳しくは）
コ◯ーボーイ7の作者が書いた（特殊ディスクフォーマットと8877系FDCについての）小冊子があればかなり捗るとは思いますが、行方不明…

>>424
なんでパイプかとゆうと、とりあえずパイプとゆうかmkfifoか何かで作ったパイプファイルで相手と繋いでしまえば、
繋いだ先はなんでも良くなるので。
ハンドシェーク線はダミー動作にして、キャラクターがきたらこうで、送るときはこうする。
というエミュレーションだけを作ればいいから、要はOSで作法が違うデバドラ意識しないで済むかな…と。

武田さんに要望なんですが
配布してるコモンソースコードプロジェクトのバイナリを
機種別にフォルダに入れてくれませんか？
自分でやれと言われたらそれまでなんですが

各マシンのROMファイルが同じフォルダに並んでるのが嫌なのわかるｗ

そのへんは、武田さんじゃなくて手が空いてる人が
フォルダ作成+バイナリをフォルダにコピーするだけの
バッチファイルでも作るのがいいんじゃ。

>>430
既にQt移植版には入っているので、これをWindowsにも拡大すればおkかと。

>>430
ソースアーカイブの方に入っているbuild8.batをちょっと書き換えてみてください。

>>428
.wine/dosdevices/com1とかに好きなリンク貼れば、何も考えずにシリアル開けばいいと思うよ。

問題は同期通信なんだよな。

devenvって、/upgradeスイッチあるの今気づいた。
いちいちVS2010で開いてウィザードで変換してたよー。
デフォでdirectxをインクルードしてライブラリ検索するようにVS2010の設定ファイル追記してと。
おお、一括プロジェクト変換batと一括コンパイルbatできた。
ソースいじんなきゃ、べつにいらないか。

あと、VS2010のdevenvってrebuildスイッチの場合、
フォルダ内の前のexeファイルも消しちゃうのね。これも気づき。

>>433
同期通信が必要なデバイスって、普通の人は使わない以前に持っていないし、余程の理由がないなら、
PICか何かでホスト側のインタフェースをエミュレーションして、こちらと向こうを中継させた方が融通効くのではないかと…今となっては。
デバイスファイルのioctl叩けばやれなくはない気もしますが…まだまだその域には至れないですねー、私は。

クロック本体供給なら機器側は簡素化できるし、逆に外部供給なら高速化しやすいし
MIDIのような半端なクロックにも対応できるからね。
勿論そんなものは無理せず専用IFでホストに繋いで今のアプリ使った方が便利だろうが、
逆に言えば当時の対応ソフトは出番がないという事だし、規格なきゃ今のアプリ自体無いだろうね。

>>436
そうか、MIDIがありましたね！
とりあえずはtimidityのようなソフトウェアMIDIシンセサイザを呼び出すようにする辺りは考えますね。
MIDI音源の機械は持ってないので、どうしたものか…

暇な人がいたらここらへんを取っ掛かりにしてお願いしますm(_ _)m
http://linuxjf.sourceforge.jp/JFdocs/MIDI-HOWTO.html#toc8
要は、USARTが同期通信モードの時に、相手がmidiシーケンサと見做してごにょごにょするインタフェースという感じで。
WindowsとLinuxと*BSD系でやるべきことが違ってくるだろうけど。
ここにカキコするか、私のGITHUB（コモンソースの方）にpullリクエスト投げて頂けるとなお良いです。
私は当分、本業の仕事と他のパートのことで動けなくなるので…仕事自体はエンジンがかかれば一週間掛けないで仮納品できる分量なんですがね、エンジンがかからない(´・ω・｀)

えっと、MSX1がビルドできるようにしました。
githubを見てください。（仕事がすすまない息抜の筈が色々やって、疲れたのでバイナリはアップするのあとまわしかもしれません））
で、Qtだとdirectなんたらとか使えないし、レーザディスクに関しては出来ればlibavcodecの類を使いたいので、後回しにしました。
要は、何の変哲もないMSX1をビルドできるようにした（但しQtのみ？）。

後、これは業務連絡なんですが、EMUクラス経由で、
VMが使ってる画面モード・要はEMU::/VM::screen云々で（仮想VRAMへの）スケーリングもScanlineもしないでやれるような、
単純にRGBA変換するか外部のレンダラにVRAM読んでまる投げしちゃうAPIがEMU::にあるといいなと思うんですがどうでしょうかね？
要は、OpenGL前提でやってるのでスキャンラインとかその他の事の多くをOpenGLに投げれるのにもったいないかな。と…
# まぁ、OpenCLやGLSLでなにかやる場合は、各マシンのVMの中でHookをしたほうがいいかも
例えば
・今使用してる画面モードの拡大・縮小しない（ここ重要！）、実際の幅ドット数,縦ドット数をEMU::経由で読めるようにするAPIの追加
・画面表示をOpenGLなどか（後はOpenCLやGLSLでやるか）DirectDrawでやるかを選択する事をVMに知らせるAPI
後者は、ダミーでもいいですが。

整備されたら（ひょっとしたら何か作れるかも）、結構OpenGLとかに投げられることが増えて、VMのCPU使用量を減らせるんですよね。
ま、先に私がなにがしか書くかも知れませんので、武田さんの優先度はあんまし高くなくてもよさげですが。

脳味噌ウニってるので、イミフだったら申し訳ありません。

VMクラスは表示する内容を作る側、
EMUクラスはそれを実際のWindowに表示する側、と切り分けてるので、
その文脈に則った形でやっていければと思っています。

そういう意味では、レンダラはやっぱりVMクラス側かなと思います。
OpenGLを使うかDirectXを使うか、とか、そういったホスト環境の都合を
仮想マシン側に意識させたくないなあと。

ただ、現在スキャンラインはVMクラス、CRTフィルタはEMUクラスと
ごっちゃになってますので、まずスキャンラインの処理を汎用化して
EMUクラスに移動してしまうことを考えています。
後はPC-100でだけ使ってる画面回転の汎用化をしたいなあと。

＃youkanPのMZ-1500版ドルアーガ用、とも言います（笑）

ぶっちゃけ、現状でCPUの使用率は数％程度なので、
OpenGLでレンダラを高速化するために、余り構造を大掛かりに
弄るのもどうかなあ、という気持ちはあったりします。

＃本業がCADソフトの開発側で、特にintelのチップセット内蔵の
＃VGAのドライバのOpenGLには色々と痛い目にあってて、ねえ。

一応、VMクラスからEMUクラスに、現在の仮想マシンの解像度を
通知する関数は用意されています。
JXなんかで、ハイレゾモードに移行するのに使ってたりします。

Qtのよくわからない挙動で痛い目をみてるので同じく。

VMクラスはエミュレート対象機種の仮想環境一式、
EMUクラスは実行機種依存部一式、
ってわけじゃないん？

投下しておく
ttp://www1.axfc.net/u/3398671.7z

>>442
了解です。
ちょっと、善処策を考えましょう。

レンダラはVM側だというのには、同意します。（と言うか、それしかやりようがないでしょう）。他の処理をどうするかは…まぁ、拡大処理やスキャンラインの設置処理をVMがやるべきかどうかだと思います。
全てのレンダリングを仮想フレームバッファにRGB(A)で置くというやり方を壊すのは良くないかも知れないな。（機種単位でHackする場合を除いて）と、お読みして思いました。

その上で、仮想マシンの持ってる画像情報を、RGBAの仮想フレームバッファに単純レンダリングするという部分はVMで、その他をEMU側に投げれて、尚且つ今の仮想フレームバッファに書き込むときのVMの属性情報（幅や高さなど）を取れれば。とは思いますが。

>>443
最近GTKが迷走気味だからとQtにして失敗したかも…と思いつつ、まぁ、Agarをすててここまでやってしまったんだから、しょうが無いな。と諦めています。
これでも、Agarを使ってるよりは若干安定してる。バカなバグとか余り無いし、問題なのは、特にQthread周りの意味不明な挙動なので。
一とおり作業が一段落したら、XM7/SDLを（当初はGLだけで?)AgarからQtに移転しますね。
大体、やるべきことは把握できた。

あ、後、今回のビルドから？SDLがSDL2になっています。SDL2をインスコしてないよいこのみなさんは、インスコしてからお試し願います m(_ _*)m

>>442 追記しますが、JXのソースコードを、後で（仕事がもう数日で上がるのでその後くらいに）読み込んでみますね。

エミュってフレームバッファ以外何か必要なの？
GUIとか正直htmlでもいい気がする。

そう思うなら、自分でやってみたら？

何のやり方がわからないの？

>>448
それはある意味理想だし、どこぞのサイトはそういうエミュを作って公開してる（多分バックエンドはmame)けど、
そういうアプローチは余り食指動かないですねー。

midiといえばjackdだろうかと思ったけど、
win版どうなってるのかなこれ。

X1のニュートロンですけど拡張子が.nullになってます
どうすればいいんでしょう？

自分で吸い出したファイルの拡張子なのに、何がわからないんだ？

tronを付け足せばいいんじゃないの？

色々やってのアップロードﾉｼ

ttp://www1.axfc.net/u/3400599.7z

因みに、前回のはヤバいバグがあるんで（マトモなOSなら落ちるだけで済みますが）、こちらに入れ替えてくださいませ。

業務連絡＞武田さん他

disk.cpp と言うかmb8877.cpp ですが、Write TrackでF5,F6,F7をそのまま書いてますね。
この3文字は、MB8877では特別な意味を持っています。(どれがどれだったかは忘れたので後で調べます）
後、disk.cppの方も、track writeしたあとに、セクタを再構築するのがうまく出来てない感じですねー。
一度track write (uPD765の場合はフォーマットでしたっけ？）した場合は、
・セクタテーブルを再構築する必要があります。
・具体的には、フォーマット中にデータIDが来たら、そこからCRC文字や次のIDまで（もしくはCHRNのNで示されるバイト数)の間のトラックデータで、セクタデータを上書きする。
・セクタサイズが元と違う場合は、memmove()でイメージデータ全体を移動する

件のスタ○ルの場合は、多分、セーブ時にオンデマンドで(しかも、非標準の）フォーマットしてるんじゃないかと思います。
要は、非標準のフォーマットをトラック単位でやった後で、セーブデータを書き込んで、しかもベリファイかなんかしてるから、固まっちゃう。

とりあえず、脳味噌死んでる所で読んだので、間違ってたらすいません。
ちょっと、こちらの方でもアイデア絞ってみますm(_ _)m

倍密限定（単密ではまた別）だと
F5=ID/DATAアドレスマーク(A1*3バイト)
F6-INDEXマーク(C2*3バイト)
F7=CRC2バイト
のはず。

セクタの再構築が出来てないってことは、
トラックデータからのセクタテーブル構築はイメージ化ツールで処理、
エミュ自体はディスクの初期化には未対応って感じなんですかね？

Write ID実装されてないしな

業務連絡：
FDCですが、MB8877のWrite Track実装が不完全なんで、時分秒コードについて仮実装しました。
github の　commit ce574213769b2685ead0df84c81f193e519d3906　をお読みください。
多分、uPD765のWrite IDも同じような何かでしょう。

只、注意が必要なのは、ディスク側の対応処理が出来てないことで、これはdisk.cppにDISK::insert_sector()
という、中身が未だ実装できてない関数でセクタの位置更新やらID更新やらなんやらやらないといけない（勿論、急いで実イメージにライトバックしないといけない）ことです。
だから、ここが実装できるまではあんまし意味がないのです(^_^;

ちょっと、バッファハンドリング的にややこしいので、少しお待ちを。

そうそう、これはスレ違いかも知れないけど、MB8877はN=3(1024バイト)のセクタまでだけど、uPD765系は1ビット拡張してあって、8192バイトのセクタが出来ちゃあうとか、
これはFM-7のア○ス２だったと思いますが、なぜかN=3のセクタが6つ並んでいたりする（勿論、コピーできない）んですすよね。
そういうアカントラックのものがまれにあるようですねー

JACKd的に部品間を繋いで自分だけのエミュレーター作れる奴が欲しいな。

>なぜかN=3のセクタが6つ並んでいたりする
GAPを削って増やしてたんでしょうかね。
一部回転速度を落として容量増やしてた、とかいうのもあったそうですが。

昔FM-77でC-DOS7のBUBRFでフォーマットしたディスクがPC-98x1で全く読めなくて、
理由調べてたらBUBRFはN=5でフォーマットしてて
FM-7系(というかMB88xx系)のN:3bit目は無視されるのでN=1と同じようにRW出来るけど、
98のFDCでは有効なため256バイト以上RWしてCRCエラーになるという話を知った当時は
目が点になりましたｗ
その後BUBRFのロジックにパッチ当ててN=1でフォーマットするようにして使ってた…
なんて、遠い昔の記憶がありますｗ

単密だとF7は倍密と同じだけどF5とF6は禁止らしい。
他のコントロールバイトは単密倍密共通らしい。
又聞き情報なので確定情報ではないけど。

>>460
ありがとうございます、参考にさせていただきます。
diskクラス側については、こちらで対応しようかと思います。
（多分diskクラス内だけじゃ済まないので）

面倒が多い割に使う機会がないので、ライトトラック系は
全然実装してなかったんですよ。
スタークルーザーで使ってるなら、対応しないと。

「買ってきたばかりの未フォーマットのディスク」
しか手元に無いのに、セーブするときに
「フォーマット済みのディスクを入れてください」
と言われてどうしようも無くなる。

を避けるためには、必ずライトトラックを使うはずなので、
使用頻度が低いってことは無いと思う。

ただユーザーディスクやセーブディスクの作成は実機でやってからイメージ化するというなら、
たしかにライトトラックが使われるケースは少ない、もしくはライトトラックを無視しても問題が無い
ケースは多そう。

そのスタクルの場合もイメージ化のところで（ある意味）失敗しちゃってるだけの可能性もあるんでは？

>>463
所謂「回転数プロテクト」だったんですよ。
もう時効だから書きますが、レンタル屋で借りて知人の家でコピーを試したのですがダメだったので、コピーツールで解析したら、ギャップの値は普通でN=3なセクターが6つ(^^;
ドライブのケースの蓋を開けて、何らかの方法で回転数を弄ってギリギリまで回転数を落とす必要があったけど、流石にそれは無理だった。

>>464
ありがとうございます。
Write trackの実装としては不完全ではありますので。要は、一部の、
・IDに時分秒が入った場合
・セクタデータの途中でF7が入った場合
・SYNCバイトが2ビット以下の場合
などのレアケースへの対処が出来てないので。
あと、deleted dataの実装も真面目にやってない。
完璧を期すならば、トラックイメージに、そのオフセットのバイトでSYNCビットが立ってるかどうかのフィールドを別個設けるとか、トラックサイズを明記すると言うことが必要になると思います。
そこまで行くと、大規模な改造と言うか全く違うディスクの実装になるので、武田さんの作業が目処が立ったら、私の方でほそぼそといじってみたいと思っています。

>>465
F-BASICのユーティリティで初期化するときなんか出てたのを思い出した。

ライトトラックのパラメータ設定の内容によっては、トラック1周分より多いデータを指定できるわけで、
それで1周分を超えるデータを書き込んでトラック先頭部分を上書き破壊するプロテクトとかもあったんじゃなかったっけ?

その辺を再現しだすとディスクイメージの作りから考え直さないとだし、
吸い出し方法もフランスだかどこかの国の人がやってる機器を使わなきゃだし。

そしてプロテクト外しちゃえばどーでもいいし。

http://homepage3.nifty.com/takeda-toshiya/00tmp/write_track_test.zip

MB8877のWrite Trackと、uPD765AのWrite IDのテスト版です。
X1のHuBASICと、PC-88のN88-BASICで、アンフォーマットなイメージに対して
物理フォーマットとディスクコピーができることを確認しました。

>>460
ベタなトラックイメージから、各セクタを確実に拾えるか怪しかったため、
F7とF8/FBをトリガにして、IDとデータを書き込むようにしました。
結局、せっかく実装していただいたのに、全然別物になってしまいました。
非常にごめんなさいです。

DISKクラス内で、ディスクの内容をD88フォーマットで管理していますが、
将来的には、常にベタなトラックイメージの集合として扱って、
各FDCは、DISKクラスから垂れ流されるベタなトラックのストリームから、
GAP/SYNC/AMを検出してセクタを探すようにしたいなと思っています。
そのときには、今回実装していただいた内容が役立つ筈です。

ただ、これはより正確にハードウェアの動作を表現できるというだけで、
実用上は殆ど意味がありません。
少なくとも、ここ２〜３年は手を付けないだろうなと思います。

>>469
まあトラック一周より長い物理データは意味なんてないわけで、
厳密に再現すること自体は無意味ではあるよね

ただ、トラック先頭部分を上書き破壊するフォーマット自体は、
破壊された部分を生データとして書き出せば充分な再現だとは思う、一部セクタでヘッダが上書き消去されてること以外に意味ないでしょ?
違ったか、ええとあれ、ｺﾞﾒﾝ忘れた

>>470
ありがとうございます！
とりあえず、まっさらなディスクイメージのフォーマットはOKだと思います。
が、DISK::trim_buffer() するときになんか、びみょーですね。
複数枚重なったd88を扱う場合に、track 160相当の所でおかしなデータポインタになって吹っ飛びます。

あと、D88をopenした時には、まだtrim_requiredしなくてもいいと思います。
あくまで、Write track / ID write / format したあとにだけ、trimが必要という感じですかね。
これ以外では、IDフィールドも、セクタの大きさも変わらないので…

>>470
追伸。
ディスクの方は、こちらでも、別の作業の合間にちまちまやっていきますよ。
もう少し、大胆な方法を取ろうと思うので、別のファイルにしていこうかと。

>>471
個人的には回転数とシークタイムで定義して動画コンテナ的な奴で扱えんものかと思う。

>>474
シークタイムで切るのはどーかな？とは思います。
イメージ化を考えた場合、
・トラック数もセクタ数や大きさも決め打ちにして、とにかくダンプしちゃう(2d形式とか)
・セクタ単位でデータを積み重ねていく(D88/D77など)
・トラックデータにデータマークやsyncの属性を付加してデータ化する(kyrofluxがこれか？)
で、柔軟性から行くと一番最後がいいのは事実。相当な変態フォーマットでも損傷なく記録やエミュでの再現が出来ますので。
反面、データ領域がたくさん必要になる。
だから、今の「セクタデータとID情報から擬似的にトラックデータを生成する」ってやり方は、基本的には妥当なんですよ。

今考えてるのは、3つめのイメージ化とかトラックデータのそのままの保存は次の段階として、セクタデータとIDについては、各個独立したオブジェクトにして、IDフィールドとリンクさせるというものです。
要は、
・エミュ上のディスクデータは、読み込むときに、各トラックごとに独立したオブジェクトにして、そこへのポインタの配列として再構築する。
・トラックのデータは、
　　�@各セクタデータ及びIDへのオブジェクトのポインタのリストと、その他最低限の属性情報を持っている
　　�A必要ならば、ベタデータへのポインタ等も用意しておく
・セクタのデータは、基本的に大きさとCRC、あとはDDM属性をヘッダとして、それと、実データの領域へのポインタを持っている。
・IDのデータは、基本的にCHRNとCRC、必要ならギャップの大きさというかギャップの生データ
上記2つは、トラック内の相対位置を持っている
こうすることで、C++のリスト型を使えるようになりますし、セクタ長やIDが変わった場合も、必要最低限の移動で済ませられる。
行数制限危なくなってきたので続きます(^^;

要は、「どーせC++ベースのプログラムなんだし、内部でデータ持つときに限っては、vector型やリスト型でデイジーチェーンしちゃえばいいじゃない」。と言う話です。

その上で、D88などに絞って考えると、美しくないかも知れないけど、
・ID書き替え/Track writeがあったトラックの前まではサイズが変わらない
・ID書き替えだけがあった(要は、トラック内のセクタ数と個々のサイズの変更がない場合）トラックは、サイズが変わらないけどセクタデータとIDが変わったということで、書き換える
・それらが変わったトラックは、元のサイズとの差分を求めて、その次のトラックからの位置をずらして再書き込みする
・で、最終的に仮想ディスク1枚のデータサイズが変わった場合は、ライトバック時にその後の仮想ディスクのデータを移動して、当該トラックは上書きする。
・もしくは、ライトバックのタイミングで、全トラックを再構築して書いてしまう。
・複数のイメージ繋げてる時は、テンポラリのファイルに一枚分書きだした上で、別のテンポラリに一枚分づつ読み込んだ上で、全体を再構築する。
と言うアルゴリズムで行けるんじゃないかなと思っています。
これは、ベタトラック持たせる場合は又違う話になるでしょうけど。

あ、これらは私の方で作業していきますので、武田さんはお気になさらずに。

ちょっと見切り発車ですが、新バージョンをリリースしました。
PC-88とX1の両方で、スタークルーザーでセーブ、ロードできることを
確認しました。

>>472
複数ディスクの問題ではなく、D88の空きトラックのオフセットの指定の
問題なんじゃないかなと思います。
通常、空きトラックのオフセットは0を指定しますが、もしかしたら、
-1で空きトラックが指定されていたんじゃないかと。

今晩のリリースで、トラックのオフセットの値の妥当性チェックを
強化していますので、多分クラッシュすることはないと思います。

なお、trim_buffer()では、tmp_buffer[]を作業領域に使っていますが、
これはstaticで宣言されていますので、複数のDISKのインスタンスで
共有されています。
例によって、GUI絡みで、複数のスレッドから同時に各ドライブに対して
trim_buffer()が実行されると、酷いことになりそうです。

>>475
シークタイムは切るんじゃなくてセクタのオフセット
RAWだと結局FDCに依存してしまってチップの挙動差が再現できないんじゃないかな？

>>476
エミュレーション精度の向上が目的というわけではなく、
DISKクラス内のデータの持ち方を改良する、という方向でしょうか。

機能的には、現状の実装で特に困っているという訳ではないので、
よりシンプルな実装にできて、将来の開発がし易くなる方向だったら、
といった感想です。
色々操作しても、データ構造が破綻しない堅牢性が前提ですが。

＃C++をちゃんと体系的に勉強してないので、vector型やlist型を
＃よく分っていないのがアレですが（苦笑）

ざっとソースを流し見ですがトラック部オフセットが0x2b0固定と、複数イメージの時のライトプロテクト有無混合の場合の動作がまずくないかい?

>>480
柔軟性と堅牢さを確保するために、データ構造を変えていこうという感じです。
その上で、将来的な拡張に備えられるようにしていこうかと。

eX1がニュートロン一番操作しやすいな
これ以外は操作しずらい

>>481
D88フォーマットの規格として、ヘッダ＋164トラック分のオフセット情報で
0x2b0となっています。
この部分は私のエミュレータでも固定となっています。

読み込んだD88ファイルが、最初のトラックのオフセットが0x2b0以外に
なっていても問題はないようになっています。（多分大丈夫）

もし、最初のトラックのオフセット位置まで、164以上のトラックの
オフセット情報が記録されているような独自拡張が存在するとしたら、
164以降のトラックは無視されてしまいます。

プロテクト情報については、ドライブ毎にDISKクラスのインスタンスが
作られるようになっていていますので、問題はないかと思います。
連結したD88ファイルでも、指定した番号のイメージをbuffer[]に
読み込んでからプロテクト情報を取得していますので大丈夫です。

ただし、Windows上でイメージファイルが書き込み禁止になっていると、
強制的にライトプロテクトがかかっているとみなすようになっています。

返答し忘れ。

>あと、D88をopenした時には、まだtrim_requiredしなくてもいいと思います。
>あくまで、Write track / ID write / format したあとにだけ、trimが必要という感じですかね。
>これ以外では、IDフィールドも、セクタの大きさも変わらないので…

特に必要という訳ではないですが、トラックデータ部に隙間があったり
順番がきれいに並んでないようなイメージの場合に、整形してから
保存するようにしようかなー、という程度の理由です。

通常のイメージでは、trim_buffer()をしても変化はありませんが、
特に重たい処理という訳でもないので、まあいいかなと。

あんな汚いソース、よく流し読みで理解できるな

ソースを自分の好みにしたいだけ？

相手が問題ないと言ってるのに、自分の好みで全面書き換えなんて、プロジェクト乗っ取るつもりでないなら、止めとけば？
好みにあわないからボツって言われても泣かないならいいけどさ。
だいたい、将来の拡張の方向なんて、プロジェクトリーダーの決めることだろ。

アクティブなメンバーに主導権を奪われる典型パターンだね

>>480
>＃C++をちゃんと体系的に勉強してないので、
なるほど、だから武田さんのソースはC++なのに、
C言語のcast使ってたのか。
先日初めてソース見たんだけど、何かこだわりでも
あるのかと思ってた。納得。
っていうか、vc++ではold castって警告出ないんですかね。

リリース版を弄りましたが、8801MAでかなりのディスクがV2モードでブートしないですねー。
理由はまだ調べてないですが。

>>488
んーと、こちらの趣味なので…ボツになればなったで仕方ないとは割り切っています。
（ディスクに関しては）一旦枝分かれさせて、使える所は取り込んでね。程度の考えです。

まぁ、FM-7を作ってからにしますが(；´Д｀)
後、XM7の再移植ね(；´Д｀)

＃雑音は気にしない。いつものことです（苦笑）

>>490
はい、文字列操作がstr*()なのも、メモリ確保がmalloc/freeなのも、
単にC言語のころから知識が更新されていないだけです。

というか、プログラムの教育って受けたことないなあ。
大学は機械系で、旋盤とフライス盤と半田ゴテの生活だったし。
今の本業も、ほとんどVB.NETとC言語だし。

自分なりの工夫と、他の方のソース見て「この書き方いいな」というのを
真似してきた積み重ねが、今の私のプログラミング技術のすべてです。

なので、Artane.さんのコードを見て、「お、この書き方いいな」、
「この設計いいな」って思わせて頂ければ、プログラミングの幅が
拡がって有難いです。（ちょっと偉そう）

>>491
あれ、ほんとだ（汗
今日は娘ともう寝るので、明日にでも調査します。

至急、1/31版のご使用は中止してください。
ディスクイメージが壊れる場合があります。

出来るだけ早く、修正したバージョンをリリースします。

全ビルド中の待ち時間にご報告だけ。

D88フォーマットの公式な規格は、ぶるー牧場のサイトに掲載されている
内容のものになるかと思います。

http://www1.plala.or.jp/aoto/tech.htm

これによると、トラックのオフセットは164トラック分保存されている
ことになっています。

しかし、これが160トラック分しか記録されておらず、0x2a0から
最初のセクターが記録されているイメージが存在するようです。

1/31版では、トラックオフセットは0x2b0以降に存在するものとして、
0x2a0にあるトラックを無視してしまっていました。

規格外の不正なイメージだと言ってしまえばそれまでなのですが、
0x2a0にあるトラックを削除した状態でディスクイメージを上書きして、
イメージを破壊してしまうのは、如何にも拙いバグでした。

ちょい前に固定まずいいわれてたじゃんw

トラック数が少ないイメージがあるなんて想像せんかったのよｗ

新しい版をリリースしました。
1/31版をお使いの方は、こちらに置き換えをお願いいたします。

D88は色々な実装解釈ができるから仕様書不備な部類

>>498
お疲れ様です

只今動作確認中です。
一応、（N=2とか3とかのセクタが大半なのでアレしてたソフトの）ブートや動作はしますね。
書き込みですが…当時のメジャーなコピーツールにあった、ファイラーを書くための簡易言語の文法を忘れてしまった(笑）
手元にマスターと取説があるのはプロテクトがすごくて立ち上がらないコ○ー○ーイ7だけだし…

>>500
そういうことです。できれば、独自にディスク周りを再実装したいというのは、そこら辺の多重解釈がされないような物に内部構造をしておかないと、予想外のバグに悩まされかねないな。と思ったのがあります。
と言うか、それとkyrofluxが手に入ったあとの（って、$200近くするのでいつ買えるかわからんですが（汗））事とか、
あとは、実機からコピーツール経由でトラックイメージを含めたデータを取り込める＆＆今のD88の仕様ではイメージ化しても動かないソフトをどうにかしたい状況の人向けにD88拡張したいなと思ってるのがあるので…
だから、今動いてるものはそのままに、別系統にしてのんびり書いていこうかと…

伏せ字のタイトルが気になる…

一応、なんだ。使うのやめとこ。

kyrofluxのエミュレータ作ればいいじゃん

密林で売ってくれよ…

>>502
なんとなく雰囲気的に、コP某イ7 と書いてあるような気がするが、聞いたことのない名前なので分からん。

D88拡張するなら1D/1DDの正式対応とかその他マイナーメディアについても考慮してほしいなあ

最近のビルド
ttp://www1.axfc.net/u/3403637

>>503
やらないといけない工数をやるのに手間がかかってるだけですので…多分大丈夫な感じはしますが…

>>506
それで間違いないですが…マイナーなツールなので。

ユーザーが多いと、一つバグを出すのも一苦労だな

>>501
そういえば、金色の表紙のプロテクト解説本で載ってたツールがそれだったような記憶が…。
本での表記自体はたしか「○ーヤ」だったけど。

私が持ってるのはエ○ス○ー○FMで、マスターと取説もあるはずだけど、どこかに埋もれてます（笑）

とりあえずD88/D77の＋αで対応するおつもりなら、
おそらく0x001Bのtypeにベタイメージの2D/2DD/2HDを追加されると思うんだけど、
とりあえずMSB(0x80)は既にバブルカセットに使用したので対象外にしていただけると
ありがたい。
※「バブルイメージとは別でしょ」と言われてしまえばそれまでなんだけど…
　一応アレも最初の32バイトをD88形式と共通にできるよう設計したので^^;

私がこちらで考察しているところでは、とりあえずこんな感じ。
　0x00: 2D, 0x10: 2DD, 0x20: 2HD　※既存のD88
　0x80: 32KB BUBBLE, 0x90: 128KB BUBBLE　※XM7/XM7dash v1のバブルカセット
　0x01: 2D(ベタ), 0x11: 2DD(ベタ), 0x21: 2HD(ベタ)
※1D/1DDを考察するなら
　0x08: 1D(D88型), 0x18: 2DD(D88型)
　0x09: 1D(ベタ), 0x19: 2DD(ベタ)
こんなとこ？
※※※もしもロービット0〜3に別の意味があるなら全部NGなんだけど^^;

どうせだから考察中のネタ全部書いとく。私が考察してるベタイメージのフォーマットはこんな感じ。
┌────────────┬──────┐
│ディスクヘッダ　　　　　│0x02b0バイト│
├────────────┴──────┤
│　　　　　　　#0トラック　　　　　　　│
│┌───────────┬─────┐│
││トラックヘッダ　　　　│　16バイト││
││セクタヘッダ×セクタ数│　16バイト││
││トラックベタデータ　　│　 nバイト││
│└───────────┴─────┘│
├───────────────────┤
│　　　　　　　#1トラック　　　　　　　│
├───────────────────┤
│　　　　　　　　　：　　　　　　　　　│
└───────────────────┘
○トラックヘッダで持つ情報
　・トラック内のセクタ数
　・密度（単密・倍密）
　・トラックサイズ
　（必要ならGAP0/1/4のサイズ？など）
○セクタヘッダで持つ情報
　・IDフィールドへのオフセットアドレス(※1)
　・DATAフィールドへのオフセットアドレス(※2)
　・セクタサイズ
　（必要ならGAP2/3のサイズ？など）
※セクタヘッダはトラックヘッダの直後に集結させて、
　ベタデータをちょん切らない。
※1/※2は各フィールドへのオフセットにするか、D88と共通化するためにIDやDATA直へのオフセットにするかで迷うとこなんだけど、
　D88に惑わされないことを前提とするならば、
　各フィールド先頭までのオフセットにしておいて、SYNC/アドレスマークのバイト数を加算して求めるように設計する方が
　どちらかというとベターかな、とか。

ぐは、表の形が崩れた…orz

とりあえずdashで対応するとして、対応必須関数は
static void FASTCALL fdc_make_track(void)
static void FASTCALL fdc_makeaddr(int index)
static BOOL FASTCALL fdc_writetrk(void)
static BYTE FASTCALL fdc_readsec(BYTE track, BYTE sector, BYTE side, BOOL sidecmp)

実際はイメージディスクファイル作れないと×だから、

BOOL FASTCALL make_new_userdisk(char *fname, char *name, BOOL mode2dd)
のディスクフルイメージ対応版も作る。

こんな感じかな。

読み返してないけど、皆さん頑張ってるのは
プロテクト込のイメージでも起動させちゃうぜ的な仕様を目指してるん？

プロテクトとは別に（またはプロテクトの一種かもしれんけど）
隠しデータを埋め込むことも想定しうるでしょ、特殊フォーマットつかって。

単なるセーブデータでも、その部分だけ特殊フォーマットで書き込むゲームがあったはずだし。

個人的にはHDDでもBDでも何でもござれな汎用フォーマットを考えてみたい。

以前、openMSXが「DMKフォーマットに対応したよ！」って言ってたけど
DMKとD88とではどっちが強い？

データ全部をRAW形式で連続して配置して、オフセットデータとセクタIDデータをヘッダとして
くっつけるか別データで持つ方がいいんじゃないの？
データとヘッダを挟み込む意味は無くない？

>>513
最低でも私はそうですねー。
・セクタの外（GAP領域の中とかデータフィールドの後ろとか）にデータを書いてるディスク
・IDだけ連続してあるとか、セクタが不正な大きさのディスク
・不当にセクタ数が多くて、6250bytes(2D/2DDの場合)を超える大きさのディスク
位は、何とかしたいなとは思ってます。ビットずれとなると難しいですが。

>>511 個人的には、こんな感じを考えています。
全体のヘッダ：
・マジックワード(0xffffで始めてD77/D88と識別できるようにするか？）:8bytesくらい
・フォーマットタイプ・トラック数: byte,WORD
・ヘッダ自体のサイズ：WORD
・イメージ全体のサイズ:DWORD
・トラックデータへのポインタ：DWORD
各トラックイメージ：
・識別ワード:DWORD?
・ヴァージョン: 00 = セクタデータのみ、10h = トラックデータを含む、20h = SYNCビットの位置情報あり
・セクタ数:WORD?
・各セクタ/トラックデータへ相対ポインタ（トラックデータのヘッダからの位置）：DWORD
→ [0] :トラックデータ(ない場合は0x00000000) [1] - [セクタ数] : 各セクタへのポインタ
・トラックデータ/セクタデータの連続体
トラックデータは：
・ヘッダ： 0x00 = ただのバイト列…
・バイト数：WORD?
・（拡張されてる場合は）拡張ポインタ領域
[0]: バイトデータ [1]:SYNCビットの位置データ...
・実データ

セクタデータは：
・マジックワード(DWORD?)
・ID : CHRN + CRC
・実データサイズ
・実データ

セクタのデータとIDには、＊読み込んだ時の＊CRCを付加する。
あと、deleted dataかどうかの識別や全体ヘッダへの書き込み許可／不許可フラグも必要でしたね。
で、
・何らかの方法でデータを作る場合は、Write track/Write ID等で意図しない限り、CRCエラーがないことと見做す。

ここまでしつこいことをやってるのは私の性格ですが（特にMAGIC設けてる辺りは）、
それと同時に、セクタの大きさの変更があった場合に、なるべく高効率でデータを書き換えたい。最低でもエミュレータ内部では。と言うことがあります。
要は、今までのセクタのみのエミュレーションにするとして、セクタをリスト管理して、大きさが変わった場合には
・当該セクタをリストから削除
・新しい当該セクタを作る(mallocとか）
・出来上がったら、リストの当該位置に挿入
・必要に応じて書き戻す
と言うシーケンスで済ませたいなと思ってまして。

>>513
私の場合はとりあえず、ベタトラックフォーマット対応を目指してたり。
プロテクト込みのイメージ対応はあくまでもその副産物扱い。
その第1段階としてとりあえず現在のDiskR/W関連をベタフォーマット対応してみようかと…。

>>518-520
なるほどD88とは別のフォーマットで、トラック毎に
「トラックデータをそのまま持つ」「(D88みたいな)セクタデータの集合」
から選択出来るようにする形式を確立するんですね。
私はD88を拡張する形で考えてました。(その方が設計が楽なので^^;)
この場合確かにトラック毎にフォーマットを替えられるようにしにくい
(出来ない訳じゃないけどD88との関係上めんどくさい)
ですね。

まぁD88のディスクヘッダにフォーマットを示すアトリビュートが
0x001bの1バイト(8ビット)しかないので、
追加追加で対応していこうとしたらビット不足で破綻する可能性もありますね^^;;

将来的な圧縮を考察するにあたりさしあたり対象として思いつくのはGAPなんだけど、
SYNCの12バイト(単密でも6バイト)も結構邪魔といえば邪魔ですね〜。
ただ部分的な圧縮を考慮するくらいなら、いっそのこと、Artane氏の示すような、
トラック毎に異なる形式をおけるようにするか、もしくは
そういった拡張性を残すような設計をした方がよさげですね。

%%%いんたーみっしょん%%%

>>496を読んで、
XM7/XM7dashでディスクヘッダ部が0x02a0しか用意されていなく、
0x02a0からトラック0が開始するD88ファイルをアクセスした場合の動作を
ソースから検証してみた。

結論から書くと、XM7は「最終トラックの判断」を「次トラックのオフセットが0」
であることで判別しているため、
ディスクヘッダ部の全てのトラックオフセットにトラックが割り当てられていた場合に
最終トラックの判断が出来なくなる(実証はしてないので「たぶん」に過ぎない)。

表題(ヘッダ0x02a0)の問題時、2Dはまぁ問題ないが、
2DD/2HDの場合159トラックのアクセス時に支障をきたす（同じく「たぶん」）。

また、ヘッダが0x02b0の通常イメージでも、オーバートラック含めた164トラック全てに
有効データが割り当てられていると最終トラックの判断が出来ない（…「たぶん」^^;）。
これはヘッダのトラックオフセット群の最後に「オフセット0のポインタ」が
存在することを前提に組まれているため。

まぁ、書き込まなきゃたぶん大丈夫。(^^;

対策はfdc_readbuf()関数内のmax_trackとlenの設定箇所で
0トラックのオフセットアドレスから求められる有効トラック数を割り出して
最大トラック数(84,164)より小さければmax_trackを差し替え、
最終トラックの判定条件にtrkside+1 >= max_trackの場合も当てはまる
ように修正しとけばOK…のハズ。

とりあえずdashは対策しといた…が、
fdc_readbuf()関数を追っただけなので、実際は別箇所でカバーされてて問題はおきないのかもしれない。

>>522
問題点だけ書いて問題ない点を書かなかった（汗

XM7/XM7dashでディスクヘッダ0x02a0のイメージファイルを使った場合、
トラック0〜158までのアクセスしかしなければなんの問題もない。
ディスクヘッダ自体は決めうち0x02b0で読み込んでいるが、
トラックデータはあくまでもポインタの指す位置へSEEKした上でRWしており、
トラック0が0x02a0から始まっていればそこから読み書きするため。

ヘッダが0x02a0しかない上にトラック159をアクセスするようなモノなんて早々ない気がするので、
よっぽど問題にはならないとは思う。

お久しぶりです。

今、FM-7の構築をちんたらとやってます。FM-7だけの実装にすればいいものの、何故か77AV以降の機能も実装してしまうのでなんだかなー。と言うか予想以上に時間がかかっています。
そもそも、かなりいきあたりばったりで全体の設計をやってしまったので、色々つんではくずしでちょっと難儀してる部分も。

所で、幾つか業務連絡。
・PC-88でセクタ書き込みができてないようです。N88-Basicのディスクで起動して、フォーマットはうまく行ってるようですが、いざシステムディスクをコピーしようとすると何も内容がコピーされてない。
x1ではできてるので、多分upd765a かpc8031の何かかと。
・CPU速度の変更をリアルタイムで反映出来るようにしてみました。GitHubの方にあるコードの、
vm/ : event.cpp / event.h
vm/pc8801/ : pc8801.cpp / pc8801.h (だったかな？)
vm/pc9801/ : pc9801.cpp / pc9801.h (だったかな？）
辺りの、23日辺りからの変更をご参考にしてください。

で、後、PC-9801系のエミュレーションで、ディスクのアクセスができてないでディスクからブートしないのは、吸い出しイメージの問題でしょうか？(^_^;

もう一つ。
一応と言うレベルですが、カセットテープの音を出せるようにしました。
今さっき更新したGithubをお読み下さいませm(_ _)m
かなりデカい変更になりました。
eventとdatarecを中心に、configにも項目を追加(；´Д｀)
サンプルは、X1とMZ80/700辺りに。

パルス幅はいい加減鴨試練（自信ない）

一応、PC88も仮の実装しましたが…これは、更にアカンかもしれませんので、仮ね(^_^;)
と言う事で、疲れたので離脱(；´Д｀)

あ、鳥がなくなっていました、前の書き込みは、私です(^_^;)

ついでに。
真面目にFM-7やろうとすると、実装避けられない機能から先に作っております。
クロック切り替えは不安定な挙動ではありますが、初期のソフトを動かす場合に7だと速すぎて問題が出るとか、まー、色んな理由にて。

>>524
98のディスクイメージから起動できないってのは、もしかしたらトラック0が単密度になっていて、
吸い出したマシンが単密度アクセスに対応してないものだったとか？

98BASICディスクって、それじゃなかったっけ？

>>529
そうそう。あとはFM-11のF-BASICとか。
フォーマットが8インチ2Dに由来しているからっぽい。

>>530
FM-77+1MB FDCでも同様ですね。
FM-11とFM-77の場合、たぶんF-BASICに限った話ではないと思います。
Track1以降のフォーマットに関係なく、Track0は単密128バイトになっている感じです。
ブートROM上で、IPLとしてSector1〜4を128バイト固定で読み込んでるので。

>>528
通りすがりの者ですが。
古いエプソンの９８互換ＤｉｓｋＢａｓｉｃの５インチ２ＨＤのディスクも
０トラック、サーフェース０が正にそのようです。

流れを読まずに恐縮ですが、ＡＴ機でＤｉｔｔを使ってのイメージ化が、正常に出来ないのです。
以下、個人的問題ですが、
ソース修正して単密、１２８バイト対応するようにしたいのですが、
手持ちコンパイラではコンパイルが通らず、どうしようかと思案しているところでした。

マシン自体は対応出来るようなのですがねえ。

FM,MFM混在でもイメージ化できたと思うけど
ドライブとの相性かも

>>533
おや、そうなんですか？
ソースの読み込みが足りなかったのかな。見直してみます。

ところで、ネット上からは最近Ｄｉｔｔのソースが見つからなくなってるようですね。
幸い、別のマシンにコピーはあるのですが。

ホントだ…だれか転載して〜

DITTのソースは1.40なら今でもダウンできるけど

どこで？

つか、コンパイル出来ないならそっちをなんとかしろよ。

>>532
環境晒せばヒント位は書けるかもしれません。
武田さんヴァージョンは、多分Visual Studioが使えれば何とかなります。
私の方は、
・Qt4
・CMake 2.8（たぶん）以降
・SDL2（1ではない）
が最低必要ですね。
後、多分gcc4.8以降。llvmやgcc4.7以前では確認してないです（ひねくれたコードじゃないから、4.4以降ならなんとかなるのではないかと）

>>539
あ、後忘れていましたが、QtはOpenGL対応である必要があります。
全面的にOpenGL使ってるので、私の方の表示系は。

ビルドしたいのはdittじゃないの？

>>539
どうも、初めまして。532です。
問題なのは、５インチ２HDで０トラック、サーフェス０が単密度（FM）、１２８バイト／セクタの
部分がDITTを使用して正しくイメージ化出来てないことです。

上の方で可能なはず、との事なのでソースを見直して見たところ、
確かに、対応してるようにも読めました。

なお、DITTの動作環境は、ＰＣ−DOS 6.3/VでAT機に１１５５Dを取り付けてます。

より理解するためにデバッグコードを埋め込んでデバッグしてみようと思い立って
さて、と言う所で。コンパイルが通って、かつ１６ビットDOS用コードを出力出来るのはどれ？
となって止まった状態です。

DITTのソースって、Makefileを見るとｂｃｃのようだから
Ｂｏｒｌａｎｄ　C++　４．０だか４．５だと、そのままコンパイル出来るのかな？

問題はインストール出来る環境で、そのバージョンは、７や８にインストールして大丈夫ですかねえ。

>>542
心配ならば、開発環境をVirtualBoxか何かの仮想化マシンにFreeDOSをインストールして云々でなんとかなるかと。
使い古しのXPか2000のライセンスがあれば、仮想化マシンにそれを入れても（自信ないけど）問題ないかも。
Windows方面は詳しくないですが、XP互換モードで、なおかつ32ビット環境ならば、そこまでしないで済みそうですが…

>>543
どうもです。
物置でＢｏｒｌａｎｄ　C++　４．５とおぼしきCD−ROMを見つけたのでトライしてみようと思います。

16ビットアプリだからな

9821NEXTでイメージ化してみてはどう?
あとからNFD->D88にするとか

>>524
返答が遅くなってしまい申し訳ありません。

１点確認ですが、FM-7/77では、起動中に、CPUクロックを動的に変更する
ことがあるのでしょうか？
現状でも、CPUクロックの設定を変更して、リセットを掛けることで、
即反映することはできるようになっています。
（VMクラスのインスタンスを破棄＆再生成します）

PC-88ですが、DISK BASICのdskut2.j88で、アンフォーマットなイメージに
対して問題なくディスクコピーを実行することができました。
PC-98の方も、各機種ともディスクからの起動は問題ありませんでした。

PC-98の方は、一般的な98エミュと違って、正にその機種から吸い出した
ROMイメージを使わないとまともに動作しないので、もしかしたら
その辺が影響してるかもしれません。

>>547
御返事有難うございます。
>１点確認ですが、FM-7/77では、起動中に、CPUクロックを動的に変更することがあるのでしょうか？
FM-7に限ってですが、動的に変更することがありえます。（FM-77以降にはクロック切り替えスイッチがないので）

例えば、デルフィスというシューティングゲームの草分け的なのがあるのですが、これがFM-8でも動くように作られていて、
FM-7だとゲーム速度が速くなりすぎてどうしょうもないので、裏のクロック設定ディップスイッチを切り替えて…ということが結構ありました。
しかも、ボーレートの関係があるので、FM-7のROMを積んだ機械でLOADする場合には、高速クロックモードでやったほうが安定して読めたりもしていて…
# FM-8/7系では、カセットをメインCPUのポーリングで読んでるので、BIOSの中にウェイトがハードコーディングされている

他にも、FM-7初期のゲームとかFM-8のゲームをやるばあいには、 この「裏ワザ」のお世話にならないとどうしょうもないことが結構あります。
なので、他機種…例えばPC-88でクロック設定を間違えて起動してしまった時のリカバーとか…の事も含めて、何某かあるといいのですが。と思い、eventに一個関数を試験的に追加してみた次第でして。

>>548
まず、セクタライトの件ですが、こちらで用意したラッパールーチン(__min/__max)の問題でした。
申し訳ございません。

>commit f2762ba504f31f376e908bdc03d4b3f31b6e6ceb
>Date: Tue Mar 3 05:00:47 2015 +0900
> [BUG][VM][Qt] upd765a.h : Fix wrapper functions for Qt/Agar/SDL.
をご参考までに。

あと、PC9801のディスク関連のROMの件ですが、
・PC9801とPC9801Eは、最低でもメインの2HDドライブについては読み込めている
・VMはうまく読み込めてない
・UとVF,DOについては今ひとつ読み込めてないと言うか、こちらで用意してるイメージの問題なのかは不明ですが、起動がうまく行ってない
という状況です。

>>547
>１点確認ですが、FM-7/77では、起動中に、CPUクロックを動的に変更する
> ことがあるのでしょうか？

FM-7 手動で切り替える。
FM-77,FM77AVシリーズ MMR有効時に1.6MHzに落ちる。
FM77AV20EX/40EX/40EX はMMR有効時でも2MHzのままにできる。

>>551
TWR($7C00-$7FFFのテキストウィンドウ)有効時もMMR有効時と同様だよ。

>>551
補足です。
FM77AV40/20 MMR使用時は1.6MHzのままですが、MMR使用の有効・無効とは別にDRAMリフレッシュ頻度を減らせる
FM77AV40EX/20EX/40SX MMR使用の有効・無効にかかわらず2MHzノーウェイト動作

某ダメエミュレータのソースを読んで試してみた感じではこんなものでしょうか？

>>524
イベントクラスの確認できました。
CPUのクロックの変更については、次回更新時に取り込みます。

ただし、クロックの変更は２番目以降のCPUのみに制限します。
（イベントの基準クロックを動的に変えると色々破綻しそうなので）
クロックの変わらないCPUがあれば、そちらを先にイベントクラスに
登録するようにしてください。
全CPUがクロック可変の場合は、dummyをCPUとして登録してください。
device::run()が、1を返すように修正しておきます。

データレコーダのサウンドについては、ちょっと考えてみます。
基本、データレコーダが動いているときはスキップするように
なっているので、その辺との兼ね合いをどうしたものかなあと。

あぁ、データレコーダーってリセット後でなければマウントできないですよね。
マウントしたままリセット掛けれればリセットしてまたマウントって動作をしないで済むんですけどね。
まぁ、巻き戻しとか機能がないのであまり意味がなさそうですが

今までgccとQtでビルドできている機種について、llvm/clangでコンパイルできるようにしてました。

>>554
ありがとうございます。その方向でFM-7のコードを直していきますね。
ところで、「dummyのCPUを登録」って、適当なCPU（例えばZ80）をnew()した上でeventに登録して、速攻でSIG_CPU_BUSREQか何かで動作を止めてやればいいという感じでしょうか？

サウンドについては、event.cpp(だったかな？）に加えた改変のように、「configを見て、音を出すときはスキップしないようにする」でいいんじゃないかと思いますよ。
エミュレータでカセットテープといえば、やっぱし音がないと寂しすぎますから、例えばt88やn80のように音を出すのが困難なフォーマットは出さなくても仕方ないですが、それ以外…mztとかt77とか…は選択的に音が出るといいんじゃないかと思っています。
# t77は、一応コンパイルが通せて音もXM7と変わらないレベルで鳴らせるものをdatarec.[cpp|h]に実装してあります。

後、もう一つ業務連絡。
相当前にやった作業ですが、mc6809.[cpp|h]に、未定義命令とSIG_CPU_BUSREQを実装しておきました。
基本的には、私がやったXM7/SDLでのCPUコアのmameコア切り替え作業の時に、こちらでmameコアに追加に実装しておいてあったものの、mc6809.cppへの再実装なんですが。

これらは、FM-8/7系では絶対に必要になる機能なので。
BUSREQについては、メインCPUがサブCPUを止めたり、拡張スロットに刺したZ80カードにメインCPUを切り替えたり、果ては表示系でCRTCがサブCPUを一定期間止める場合があるなど、物凄い頻繁に使いますから。
後、未定義命令については、I/O誌が解析記事を掲載したのもあって、使ってるソフトウェアがかなりありますので。
反映よろしくお願いしますm(_ _)m ＞武田さん

よくわからないけど、原発を基準クロックにするわけにはいかないのかな？

よくわからないなら黙ってろ

説明できないなら黙ってて

黙りません、勝つまでは

>>556

dummy = new DEVICE(this, emu);で作ったdummyインスタンスを、
そのままプライマリのCPUとして追加する感じでOKです。
int run(int clock)が、与えられたクロック数を返すようになっていれば、
CPUクラスでなくても構いません。

テストできてないので、ソースだけ仮アップしました。
http://homepage3.nifty.com/takeda-toshiya/00tmp/source.zip

データレコーダの音を再生する機能を実装しています。
音の再生が有効になっている場合は、フレームスキップが無効になります。

mc6809の取り込みは、また後程。