|
EX68 掲示板 バックナンバー
|
|||
|---|---|---|---|
| bbslog.lzh <--テキスト形式での全ログのダウンロード | |||
|
掲示板 EX68 |
bbs0.htm 000-199 97/05/22..97/06/26 bbs1.htm 200-399 97/06/26..97/08/29 bbs2.htm 400-599 97/08/30..97/10/31 bbs3.htm 600-799 97/10/31..97/12/13 bbs4.htm 800-999 97/12/13..98/01/15 bbs5.htm 1000-1199 98/01/15..98/02/04 bbs6.htm 1200-1399 98/02/04..98/02/22 bbs7.htm 1400-1599 98/02/22..98/04/12 bbs8.htm 1600-1799 98/04/12..98/05/22 bbs9.htm 1800-1999 98/05/22..98/08/10 bbs10.htm 2000-2199 98/08/10..98/10/17 |
bbs11.htm 2200-2399 98/10/20..99/01/20 bbs12.htm 2400-2599 99/01/20..99/05/23 bbs13.htm 2600-2799 99/05/24..99/11/21 bbs14.htm 2800-2999 99/11/22..00/04/08 bbs15.htm 3000-3199 00/04/09..00/05/06 bbs16.htm 3200-3399 00/05/06..00/06/26 bbs17.htm 3400-3599 00/06/26..00/07/25 bbs18.htm 3600-3799 00/07/25..00/11/08 bbs19.htm 3800-3999 00/11/08..01/05/13 bbs20.htm 4000-4199 01/05/13..01/09/25 bbs21.htm 4200-4224 01/09/26..01/11/09 |
|
システムファイル -> HUMAN.SYS COMMAND.X等
>ＥＸ６８を起動すると、ディスクから起動できません。 >正しいディスクをセットしてください。という風に >でてきてしまうがどうしたらいいんやろか？ >ほんま、こまってます。 システムファイル（MS-DOSのIO.SYSやMSDOS.SYSみたいな物） の入ったディスクイメージをＥＸ６８でセットしないと 起動できませんので、まず実機の方でシステムディスクのイメージ を作成してください。 詳しいことは、ＥＸ６８に同梱されているマニュアルを参照してください。 さらに詳細のことは、以下のURLをご覧ください。http://amo.fys.ku.dk/~osada/ex68faq/index-jp.html
ＥＸ６８を起動すると、ディスクから起動できません。 正しいディスクをセットしてください。という風に でてきてしまうがどうしたらいいんやろか？ ほんま、こまってます。
実機で、ハードディスク持ってなかったので、EX68でハードディスク使える！！ とよろこんでいたんですけど、どこ探してもhumanのディスクが見つからない。 とりあえず、ロムの吸出しとかはhumanの入ったゲームディスク（ヴァリスだったり(^^;） で済ませました(笑) しかし、システムコマンドswitch.xとかformat.x無いのでハードディスクが使えない！！ せっかく押し入れから68引っ張り出してきたのに．．．夢やぶれる(T_T) しかし、９８から引っぺがした５インチドライブがこんなところで役立つなんて(笑)
MMXの演算はあまり有効とは思えないのですが、64bitレジスタが8つも 使えるので、テンポラリレジスタとして結構使えるかもしれません。 ただVC++がV4.1でMMX命令が使えないので、まだ試してません。 >些細なことですが、v030 までの動作オプションの設定項目の >ウィンドウズ・サイズ可変の部分にスペルミスがありますね。 あ。winodwsになってますねぇ。 ここはPentium系の局所最適化に大変参考になります。http://www.csl.sony.co.jp/person/fnami/pentopt.htm
>私の環境でも Diamond 製のドライバ時に比べて高い設定になりましたが、 >モニタが追従できる範囲内でした。 800x600 では 63kHz/100Hz、640x480 >だと 51kHz/100Hz です。 ドライバの .inf ファイル内に Refresh Rate >の設定らしき項目がありましたので、もしかしたら変更できるかもしれません。 リフレッシュレートは、変更できました。 レジストリエディタで、 NV3をサーチ。いくつかあるけど、その中で、 RefreshRateというのを見つけたら -1 から 1 に変更。 それで、大丈夫みたいです。でも、今度はリフレッシュレートが 低く設定されるようで目に厳しいです。 EX68と関係なくてすみません。
＞でも、シャープのCZモニタを、なぜ60Hzにせずに55Hzにしたのかわかりません。 ＞あのモニタは、15kHzの時は60Hzで、24Hzの時、31kHzの時は55Hzなんですね。 24kHz モード時は 31kHz 時に比べて若干低い 52〜53Hz のようです。 これと 60Hz が（自動）選択できるといいかもしれません。 効果のほどはわかりませんが..... ＞ただ問題は、リフレッシュレート。Windowsサイズ可変にすると、小さい画面 ＞になったときにWindowsの画面も小さくなりますが、リフレッシュレートの設 ＞定が勝手に変わっているようで、モニターが追従できず画面が表示されません。 私の環境でも Diamond 製のドライバ時に比べて高い設定になりましたが、 モニタが追従できる範囲内でした。 800x600 では 63kHz/100Hz、640x480 だと 51kHz/100Hz です。 ドライバの .inf ファイル内に Refresh Rate の設定らしき項目がありましたので、もしかしたら変更できるかもしれません。
>X68kのCZ6xxシリーズの「ディスプレイの仕様」で31.5kHzモードだと55Hzなんですよ。 詳しい説明ありがとうございます。 X68Kというと あのディスプレイ＝テレビ と思い込んでしまっていました(^^; そっか、ではVSYNC待ちでタイミングを取るゲーム（ほぼ全てのゲームかな）は、 15kHzモードと31kHzモードでは速度が違ってしまうんですか・・・ (そういえば、X68Kは(X68Kだけかどうか詳しくないのですが)ディスプレイから VSYNC + HSYNC 信号が出てましたね。) ここら辺、現在のEX68ではどうなっているのでしょうか？ 投げやりな質問ですいません(^^;
ええと。昔、Oh!Xで書いたかもしれないんですが……。 X68kのCZ6xxシリーズの「ディスプレイの仕様」で31.5kHzモードだと55Hzなんですよ。 でも、15kHzモードではNTSCとほとんど同じなので、60Hzなんです。 本体のハードウェアの仕様ではなくて、CZモニタの仕様だというのがミソです。 結局、IOCSのディスプレイモードの仕様が55Hzになっているというわけです。 #同様の理由でX68kのアスペクト比が1:1でないというのも、本体の仕様ではなくて、 #CZモニタの仕様なんです。 だからX68kのゲームは、31kHzで表示することが大半だったけれど、 15kHzモードにすると、1割ぐらい速くなったんです。 #ついでに、31kHzモードよりも15kHzモードのほうが、ディスプレイのブランキング時間が長いので、 #VRAMのアクセス速度が平均的に上がるってのも、ある。 でも、シャープのCZモニタを、なぜ60Hzにせずに55Hzにしたのかわかりません。 あのモニタは、15kHzの時は60Hzで、24Hzの時、31kHzの時は55Hzなんですね。 NEC98も24kHzモードのとき、55Hzだったんですが、こちらの理由は、 ドットクロックをそのままあげると、 31.5kHz/70Hzになるってわけで、VGAにちかくなります。 NEC98の24kHzモードは、VGAのドットクロックの遅いやつバージョンなのですが、 でもVGAよりたぶんNEC88の400ラインモード(24kHz/55Hz)の方がさきのようなきもするし、 このへんの細かい理由はわかんないです。 その時代のブラウン管の質にもよるのだろうけれど。
＞それからこれも憶測なのですが、画面合成部等に MMX インストラクショ ＞ンを使うメリットは無いでしょうか？ MMX 以前に x86 のアセンブラ自 ＞体に全く馴染みが無いので、良くわかっていないのですが..... あと、 ＞MS Visual C++ の MMX サポートというのは相変わらず「アセンブラが MMX ＞命令を理解できる」程度なんでしたっけ？ コンパイルオプション一つで ＞C++ コードから MMX 対応版ができるならば良いのですが。 MMX自体は２〜８つ算術論理演算を１インストラクションで行える 程度のものですから、Visual C++で作るテのアプリには必然性が 低く、インラインアセンブラを使ってゴリゴリとプログラムを書く 人用って事でいいと思います。 でも、Packed AND とか Packed XOR などは結構エミュ向けな 気もしますね。 Callus(アーケードエミュ)ではMMXインストラクションを使ってます。
ところで、55f/s についてですが、なぜ 55f/s なのでしょう？ X68Kのビデオ周りはNTSC規格なので、60f/s(59.8?)だと思うのですが・・・ FAQだったらすいません。 (Frame/秒 ですよね？)
＞ 手元のPWR128の場合で横320,400,480,512...縦は200,240,300,260,384,400が ＞ ありますので、解像度切り替えをDirectDrawを使えば等倍転送で済みますね。 ドライバ次第だとは思いますが、512x512 等が可能になればより実機に 近くなりますね。 ただ、その場合は描画更新速度を 55f/s 以外にもで きた方が良いと思うのですがどうでしょうか？ あと、TSC の計測値や 全体の負荷値等から、フレームスキップの頻度が自動的に変化するよう にできると快適だと思います。 それからこれも憶測なのですが、画面合成部等に MMX インストラクショ ンを使うメリットは無いでしょうか？ MMX 以前に x86 のアセンブラ自 体に全く馴染みが無いので、良くわかっていないのですが..... あと、 MS Visual C++ の MMX サポートというのは相変わらず「アセンブラが MMX 命令を理解できる」程度なんでしたっけ？ コンパイルオプション一つで C++ コードから MMX 対応版ができるならば良いのですが。 ＞ とりあえず解像度切り替えにDirectDrawのオプションを追加しました。 些細なことですが、v030 までの動作オプションの設定項目のウィンドウ ズ・サイズ可変の部分にスペルミスがありますね。 ＞「テクスチャをたくさん使うアプリは最大８０％速くなる」 どうも拡大する領域全体をテクスチャと見なして、拡大作業を全て HAL というかテクスチャエンジンに任せているようですね。 テクスチャの バッファをメインメモリ上にとれる RIVA128 ならではの技でしょうか。 そうすると、あのアンチ・エイリアス現象は、最近の Anti-Alias サポー トの影響ではなく、Texture bi-linear filtering の結果だと考えた方 が良さそうですね。 これは TWEAK ユーティリティでは操作できないの ですが、アプリケーションが Direct3D に指示する事で解除できるはず です。 ＃nVidia 製のβドライバですが、その後β２と呼ばれる版が非公式に ＃登場し、さらなる速度アップ（主にバス転送速度）と Texture tri- ＃linear mapping がサポートされました。
>nVIDIA が最近リリースしたOpenGL 対応のベータ版コア・ドライバがかなり >怪しい事をしているようで、Diamond の正式ドライバが X68000 サイズで >14mS 程度なのに対し、β版ドライバでは「拡大しない」と「X68000 サイズ」 >の速度がほぼ同じ（5mS 前後）になります。その代り以前報告したように >アンチエイリアスが強制的に効いてしまうのですが、それも妥協できるく >らい速さが圧倒的に違います。 >（このドライバが PWR128 で使えるかはわかりません） さっそく、PWR128P/4VCで試してみました。 結果。画面モードが小さくなっているもの（主にゲームなどで256*256モード） は、速さは「拡大しない」「ノーマル」「X68000 サイズ」「最大化」の順に遅くなりますが、どのモードを使っても、1xで十分な速度が得られました。画面描写 に関しては実機とほぼ同じといっても良いです。アンチエイリアスが勝手にかか るのはDiamondと同じですが、このスピードにはかえられませんね。「テクスチャ をたくさん使うアプリは最大８０％速くなる」ってreadmeに書いてありますが、 ホントに速いです。 内部処理などは、完全に実機を超えています。起動時間などが、ほぼ一瞬ですから （P2 416Mhz使用） ただ問題は、リフレッシュレート。Windowsサイズ可変にすると、小さい画面に なったときにWindowsの画面も小さくなりますが、リフレッシュレートの設定が 勝手に変わっているようで、モニターが追従できず画面が表示されません。 リフレッシュレートのかえ方、どこにも載ってないし。そういう訳で、このドラ イバをインストールしたら、Windowsサイズ可変のチェックは外しておきま しょう。 昔、カノープスが「他社と同じぐらい不安定で良いのなら、ベンチマーク用の 速いドライバもある」と豪語したとどこかでよみましたが、そういうドライバ があるなら使ってみたいもんだ。
>えー、OKIのＡＤＰＣＭ変換はちまたに出回ってる方法だと12BitPCMとなります。 正確には、 「展開差分を前回の値に足してそれを12bitにリミッティングしなければならない」 です。 そうしないと、DCoffsetが発生します。（波形全体が+または-方向にシフトします）
えー、OKIのＡＤＰＣＭ変換はちまたに出回ってる方法だと12BitPCMとなります。 ので、その結果を4bit左にシフトすれば16bitになると。そういう事です。 ちなみに、ちまたに出回ってるstep値はなにやら「そのもの」の値っぽいです。 かなり昔に、ADPCM合成再生ドライバを作った時に、常に再生しっぱなしな仕様にしたんですが、 ぜんぜん問題無く再生できました。（DCoffsetはでなかったと思う） 蛇足 そういえば、ちょっと詳細は忘れましたが、compactとそれ以前の機種でADPCMチップのリセットの仕方が違った だかなんだかそんな感じの事実がありました。（詳細忘れたんで事実もくそもないですが（笑）） なんだっけなぁ、ほんとに詳細が思い出せない．．． あと、初代の68にはハー○バ○くさい仕様があって、これも詳細を忘れましたが、どっかの割り込みベクタの どっかのビットが時間とともに落ちて行くという現象もありました。 でも、たしか、このベクタってなんかのエラー割り込みだったきがします。（ので普通関係ない） XVIのVRAMアクセスにもなんだかあった気もしますね。そういえば。 いや、ぜんぜんＥＸ６８に関係ないですね。（笑）
>>私の使っているＦｕ上からWinドライブにアクセスするとファイルが>表示される >>ものの「ディスクを入れてください」などのメッセージが >>Ｆｕ上から表示されてアクセス出来なくなります。うーん。これもパラメータの >設定間違いか、用途を間違っているかかな。 すみません、なんか今Ｆｕ上からアクセスした所正常にアクセス出来ました ということで、なんかうまく動くようになりました(^^; ＰＳ．Win98にしたら家のMillennium IIでも画面解像度を自動切り替え してくれるようになりました(^^
X68kでよくあったADPCM→P16の式をそのまま利用すると、 現実に16ビットのPCM装置で再生するとたいてい音が小さくなってしまいます。 具体的なことはちょっと覚えてないのですが、ADPCMの重み換算の式の上で、 一応値が16ビット範囲になることはあっても、実機上は内部で10だか、 12ビットで行われているらしいので、すなおに68のADPCMをWAVに変換して しまうと、WAVでもともと取られた音よりも小さくなってしまいます。 で、具体的に何杯にすればいいか、覚えてないんですが、 適当に、2とか4とかで、中心からの絶対値で倍率をかけてやると、 それっぽくなったような気がします。 まぁ、でもまぢで音圧図るよりも、 tada.wavとgradiusの死んだ音を聞いてみて、耳で聞いて適当なら、 それがいちばんいいのかもしれません。
をやっとすることが出来ましたので一応報告します。 ９５上で動かすより動作が少し速いので結構うれしいです。 44KHz版OPMエミュONでもなかなか軽快 まだインストールしたばかりでＥＸ６８しか動かしてなかったりする(^^;
＞ディスクメディアの形式ですか。パラメータの割り当てを間違ってるのかなぁ。 Human 3.02 で普通に SUBST/mount された仮想ドライブの場合は、元のドライブ のメディアバイトが継承されるのですが、WINDRV の場合は元が不明なので(?)、 メディアバイトがランダムに変化してしまうようです。 （どなたか mount.x/umount.x/devno.x のソースをお持ちの方いませんか？） ＞5.0msはノーマルサイズの場合でしょうか、PCIが33MHzなのにPWR128より速いですね。 あの数字は X68000 サイズの場合でした。 nVIDIA が最近リリースした OpenGL 対応のベータ版コア・ドライバがかなり怪しい事をしているようで、 Diamond の正式ドライバが X68000 サイズで 14mS 程度なのに対し、β版ド ライバでは「拡大しない」と「X68000 サイズ」の速度がほぼ同じ（5mS 前後） になります。その代り以前報告したようにアンチエイリアスが強制的に効い てしまうのですが、それも妥協できるくらい速さが圧倒的に違います。 あと、このドライバにしてから、HAL が 15bit でも 16bit でも同じ速度に なってしまったようです。以前は 15bit だったのですが、EX68 の自動判定 でも 16bit が選択されるようになりました。実に不思議です。 （このドライバが PWR128 で使えるかはわかりません）http://www.rivazone.com/drivers/index.html#nvogl
> 現在のEX68では実機での320x256モード等を BltStretchを使用して拡大していると思われますが、これを拡大ではなく、 > 画面モード320x240等を利用すれば良いのではないでしょうか？ DirectX5SDKのddcaps.exeでサポートしているサイズがいろいろ見られます。 手元のPWR128の場合で横320,400,480,512...縦は200,240,300,260,384,400が ありますので、解像度切り替えをDirectDrawを使えば等倍転送で済みますね。 他に、オフスクリーンバッファに等倍転送して拡大はHALに任せる案もありますが とりあえず解像度切り替えにDirectDrawのオプションを追加しました。 >リモートドライブのアクセス時に、サブディレクトリの階層が増えると検 >索に失敗する場合が多いようです。 また、mint.x でディレクトリを移 >る度にのディスク・メディアの形式表示が [CDROM] になったり、[2HT] >になったり次々に変化してしまいましたが、原因はよくわかりません。 ディスクメディアの形式ですか。パラメータの割り当てを間違ってるのかなぁ。 >AMD K6 と RIVA 128 カードを使っていますが、手持ちのソフトで最も >画面合成が複雑な餓狼伝説 SPECIAL では、だいたい >5.0mS 200f/s BitBlt、15.5mS 64f/s V.Gen、3.8mS MPU.Em 5.0msはノーマルサイズの場合でしょうか、PCIが33MHzなのにPWR128より速いですね。 V.Genは時間かかってますね。このあたりはメインのDRAMの速度が効いてきますね。 >それからちょっと古い話題ですが、先週ようやく Cyrix 6x86L で EX68 >を動かす機会を作る事ができました。 6x86L の PR166+ に、Intel の >430VX チップセットマザー、そしてビデオカードは S3 Trio64V+ という >やや古い環境でしたが、MPU エミュレーションも画面まわりも Pentium >の 166MHz に比べて特に遅いと言うことはありませんでした。 PFM586.G32を走らせて見たところL1キャッシュのWBがWTになってるような感じです。 コンパイルオプションを変えたりしてみてもEX68の速度に特に変化もなかったので、 古いChipだからなのかマザーのBIOSなのかわかりませんが、私のところの環境に 原因があるようですね。 >毎回思うんだけど、ADPCM->WAV出力の変換式の途中で、 >音を上げたりするボリュームがほしいなぁと思うのですが。 一度変換後の波形をチェックしてみないといけないですね。 元々はX68000でADPCMエディタを作っていた時の変換ルーチンを使っていますが、 今回バグを見つけて直したので、当時の波形とは違っているかもしれません。 >私の使っているＦｕ上からWinドライブにアクセスするとファイルが >表示されるものの「ディスクを入れてください」などのメッセージが >Ｆｕ上から表示されてアクセス出来なくなります。 うーん。これもパラメータの設定間違いか、用途を間違っているかかな。 >K6-233 Viper-V330(RIVA128) ファンタジーゾーン使用 >BitBlt 4.8msくらい >V.Gen 16.2msくらい >MPU.Em 10.0.msくらい >といった感じでした。 >全部足すと55f/sにはとても間に合わない数字となります。うぅ。悲しい。 V.Genを減らさないと無理ですね。 スプライト系の合成はキャッシュの効果が出ますが、グラフィックやテキストVRAMは 駄目ですね。 > そこで，どこかにWindows用の26Kドライバが無いかと探してみたところ， >Win3.1に有るのを発見し，インストールしてみたところ >見事動きました。(パフォーマンスは良くないと思うケド．．) EX68では26Kのドライバは呼び出して無いのですが、ドライバをインストールしたことで Win95によってIOポートの割り当てが行われたのでは無いでしょうか。（未確認ですが） とするとポートアドレスをシステムのプロパティで確認しておいてドライバーを はずしても動くかもしれません。 >あと、FuからWINﾄﾞﾗｲﾌﾞのH:へ移動すると、「特権命令を使用しました」 >と白窓が出ます。 このあたりになるとまだ見当もつかないですね。
EX68をかなり前から使わせてもらっていまして、 色々なマシンで動かしてみました。 Pentium166とATI3DRageのマシンでも、実機よりちょっと遅い くらいで動きます。 MMX-Pentium233とNM2160のノートパソコンでは、動作は十分 でも、BGMが若干テンポが遅い程度でした。（OPL3） MMX-233とCT65550のノートパソコンだと、グラフィックの描画に 時間がかかるのか、上のP166＋3DRageよりも遅かったです。 ですが、Hi-COlorじゃなく256色にして、さらに拡大なしにすると 実機くらいのスピードとなりました。 今まで色々なソフトを使いましたが、256色モードとHigh-Colorモードで これほど速度差の出るソフトは初めて体験しました。 このEx68は、CPUの性能も要りますが、グラフィックチップの性能も そこそこ要るのですね。 以上、使用レポートでした。
厳密に言うと、EX68を使ってはいけないことはないが、ROMを違法な 手段で入手することは許されない、つまり実質的にX68000シリーズの 実機を持っているユーザーのみが対象、ということです。（よね？） それから、「たく」さんの書き込みですが、 >FDO.XDFて、x68Disk system ROM じゃないんですか？ この「FD0.XDF」は、実機のX68000でブート可能なフロッピーの イメージファイルの事を指します。言い方を変えると、ブートする イメージはHumanである必要はなく、かつフロッピーでなくてHDD でもいいわけですから、他のフリーなOSならば(BSD for X68Kとかを HD0.HDFとして入手する等)合法的に入手することも可能だと思います。 （ただしこの場合EX68上でHDD起動に設定したSRAMイメージが必要に なるので、話がややこしくなるかもしれませんが。） X68関係の市販製品を合法的に、かつ安価に入手する方法としては、 Nifty等の掲示板で「X68買います」と書いたり、秋葉原の中古 ショップを廻って、捨て値（失礼!）で置いてあるX68を見つけ出す などすれば良いのです。これはソフトでも同様です。X68用のゲームの パッケージなど（残念ながら）ショップの片隅に追いやられていて、 ひとつ１００円などで売られているのをしばしば見掛けます。 いずれにしても正規ユーザーになるためにそんなにお金のかかる ことではありません。きちんと正規ユーザーになりましょう。
以前のﾊﾞｰｼﾞｮﾝではｱﾄﾞﾚｽｴﾗｰで動作すらしなかった同級生が、Ver0.30で 動作しました。（x1でXVI相当と思う） ただ、FMが鳴らないです。 あと、FuからWINﾄﾞﾗｲﾌﾞのH:へ移動すると、「特権命令を使用しました」 と白窓が出ます。
こんにちは，EX68使わせて頂いてます。 FAQだったらすいません。 いまさらですが，26音源を試しましたので簡単に報告させてもらいます。Option設定上は26/86と明記してあるので，26音源も当然 対応していると思い，早速死蔵してあった26K(サードパーティ品)を実装してみました。ところが，Win95には26K用のドライバは無く いやな予感がしたのですが，やはりOptionで設定をしたところで"音源が みつかりません"というようなメッセージが表示されあえなく野望は打ち砕かれたのでした。I/Oアドレス等を変更すると動くかと も考えたのだけど，説明書にも余り詳しく載って無かったので，諦めました。 そこで，どこかにWindows用の26Kドライバが無いかと探してみたところ，Win3.1に有るのを発見し，インストールしてみたところ 見事動きました。(パフォーマンスは良くないと思うケド．．) PC9821Xa(PCM音源は使用しないに設定)+EX68Ver029で，2〜3の同人ソフトで試しましたが，(CPUパワーが無いから？)間延びは していましたが，それなりに音は出ているようでした。 ＃但し，JOYCARDは手元に無かったので試してません。 あと，Win3.1用のドライバをインストールする時には，ハードウェアウイザードでインストールを行った直後，他の作業を行う前に必ず 立ち上げ直しを行わないと，何故かうまくいきませんでした。
DISK SYSTEM ROMって書いてる時点であなたx68ユーザーじゃありませんね。 某所にそういう名前でSYSTEMDISKがアップロードされているのを見かけたこ とがありますのでそっちからROM拾ってきたんじゃありませんか? ROMとOSにはSHARPの著作権が有りますからX68本体のユーザー以外はEX68を 使用してはいけません。
「たく」さんの言われているDisk system ROMとFD0.XDFは別物です。 フロッピーディスクのイメージファイルがFD0.XDFとかに当たります。 ドキュメント等を良く読めば分かると思いますが・・・。 ・・・あ、申し遅れました。はじめまして。ECCHANと言います。 Ex68に感動しています。まだX68000自体現役で使っていますが Ex68もなかなか侮りがたい存在になってきたので、これから 色々チェックしていこうと思います。
どうも、はじめまして。 ＥＸ６８とＣＧ．ＲＯＭ，ＢＯＯＴ．ＲＯＭ X68Disk system ROMはそろえたんですが、これでは動きません。 同じファイル内にもあるのですが、何か足りないんでしょうか？ FDO.XDFて、x68Disk system ROM じゃないんですか？ 誰か教えてください。
うちのマシンでも調べてみました。 K6-233 Viper-V330(RIVA128) ファンタジーゾーン使用 BitBlt 4.8msくらい V.Gen 16.2msくらい MPU.Em 10.0.msくらい といった感じでした。 全部足すと55f/sにはとても間に合わない数字となります。うぅ。悲しい。 DirectXに関して 今日（なぜか）家にあったDIrectX5オフィシャルマニュアルをみてちょっと勉強してみました。 でもまぁ、実際にDIrectDrawのコードを書いたことはないので勘違いしてたらごめんなさい。 （ようするに「しったか」状態ってことです。(^^;） 現在のBitBltの代わりに、DIBをサーフェイスに対して転送する場合は確かに速度は変わらないと思います。 んで、ちょっと大変だとは思いますが、バックサーフェイスをロックし、そこに直接合成処理し、Flipかけると 結果的には現在より速くなったりとかするんではないでしょうか？？ （実際それができるかどうかの検証はしてないですが．．） ついでに DirectDrawのサーフェイスはメインメモリに作ったほうが速いビデオカードが多いようですよ。 （それ系の掲示板とかでそんな話をよく耳にします） まぁ、そんなふうにちょっと感じただけですんで、ご参考までに。
MMDSP.R上から音楽データを読み込む事が出来るようになりましたが ファイラーなどのツールがうまく動作しなくなりました 私の使っているＦｕ上からWinドライブにアクセスするとファイルが 表示されるものの「ディスクを入れてください」などのメッセージが Ｆｕ上から表示されてアクセス出来なくなります。
>ところで RIVA 128 カード（Diamond Viper V330）に最新の nVIDIA 製 >コア・ドライバを入れて 3D 時の「アンチ・エイリアス機能」を有効に >したところ、EX68 の拡大画面モードまでアンチ・アイリアスがかかるよ >うになってしまい、戻せなくなってしまいました。 これは EX68 だけ >でなく、他の画素拡大を行っているソフト（真サムスピ for Win95等） >でも発生するので、ドライバの仕様なのだと思いますが、RIVA128 ユー >ザの方で同じ現象が起こっている方いらっしゃいますか？ これは自分もそうですが、あきらめてます。すでに。 NV3 Tweak Utility を使って色々いじって見たけど全然ダメです。 ただ、５倍拡大からはボカシ入らなくなります。 （MeGaZoomにて確認済み） これがどうしてもいやじゃ！と言う場合はRevolution 3Dに変更するのも 手です。 あれはﾄﾞﾗｲﾊﾞｰでｼｮｰﾄｶｯﾄｷｰ拡大をｻﾎﾟｰﾄしてるのでいいです。
>グラディウスがちょうどいい音になると、Windowsが音を鳴らすときは、爆裂する >んですよね。これって皆さんはどうやって回避してます? GUSとAWE64G共に全ての値を最大設定にして使っています。 SB16系のカードは、４枚ほど持っているんですがAWE64Gから最大値設定が Win95とDOS上では、丁度いい音量になったようです（NT4だと今までの SB16シリーズと同様に音量がデカイです） GUSは、PROシリーズからある値を除いて最大値が丁度いい音量になったようです。 ＰＳ．８６ボードで全ての値を最大値にして使うとOPNAがEX68上で再生すると かなり大音量で鳴ります＜前だれかが言っていたような
＞ グラディウスがちょうどいい音になると、 ＞ Windowsが音を鳴らすときは、爆裂するんですよね。 ＞ これって皆さんはどうやって回避してます? うちでは EX68、Windows95、DOS ソフト、全てちょうど良い音が出ていますよ？ ヴォリュームのプロパティはほとんどいじったことがありません。
いや、うちでも爆裂してます。（笑） 夜中とかだとすげーびっくりします。
おつかれさま。 要望です。 毎回思うんだけど、ADPCM->WAV出力の変換式の途中で、 音を上げたりするボリュームがほしいなぁと思うのですが。 グラディウスがちょうどいい音になると、 Windowsが音を鳴らすときは、爆裂するんですよね。 これって皆さんはどうやって回避してます?
大した技術的バックグラウンドのない私でさえ、思ったことをちょっ と書いてみただけで、これほどまでに熱い論議を交わされているとは、 （良い意味で）ちょっと驚いています。 もちろん私が書かなくてもいずれ行われていたであろう論議だとは 思いますが...これが地方のローカルBBSだったら私はこの掲示板を 気づくことができませんでした。ここに気づくことができたのは、 インターネットという基盤とWeb上でのBBSサービスと検索エンジンの 合わせ技です。クローズドBBSでは味わえない、インターネットの 真の力をまざまざと見せつけられてた気がしています。 EX68の本題の話でなくてすみません。これからもがんばってください。 →yamamaさん そしてみなさん
＞結果は 1.8msでした。これは逆算すると69.4MB/Secになります。 内部のデータ転送は、こんなに高速だったのですね。いまさらながら、 自分の考え方が過去のものになってしまっていることを痛感しました。 それ以上に、最近のハードってそれほどまでに進歩してたんですね。 ＞やはり画面合成に一番時間がかかっていたのですね。 画面合成での処理は、確かに重いようです。 動作しないとばかり思っていたジオグラフシールが、実は合成処理が 全く追いつかないために表示できないだけだったようです。 タイトルの時点でメニュー選択が異常に重く、なぜかＭＩＤＩ／ＦＭ の選択ができないなど、なかなか変な現象を見ることができました。 どうやら、あのポリゴンの一部はスプライト（ＢＧ含む）のようです。
リモートドライブのアクセス時に、サブディレクトリの階層が増えると検 索に失敗する場合が多いようです。 また、mint.x でディレクトリを移 る度にのディスク・メディアの形式表示が [CDROM] になったり、[2HT] になったり次々に変化してしまいましたが、原因はよくわかりません。 ＞ v030でperformanceとpentium TSCをチェックするとこの表示を見ることが出来ます。 ＞ ただし互換CPUの一部では使えないようです。NTでは未チェックです。 AMD K6 と RIVA 128 カードを使っていますが、手持ちのソフトで最も 画面合成が複雑な餓狼伝説 SPECIAL では、だいたい 5.0mS 200f/s BitBlt、15.5mS 64f/s V.Gen、3.8mS MPU.Em という値になりました。 体感速度でも x1.5 でちょうど実機と同じく らいか少し速いぐらいでしたが、やはり画面合成に一番時間がかかっ ていたのですね。 ところで RIVA 128 カード（Diamond Viper V330）に最新の nVIDIA 製 コア・ドライバを入れて 3D 時の「アンチ・エイリアス機能」を有効に したところ、EX68 の拡大画面モードまでアンチ・アイリアスがかかるよ うになってしまい、戻せなくなってしまいました。 これは EX68 だけ でなく、他の画素拡大を行っているソフト（真サムスピ for Win95等） でも発生するので、ドライバの仕様なのだと思いますが、RIVA128 ユー ザの方で同じ現象が起こっている方いらっしゃいますか？ それからちょっと古い話題ですが、先週ようやく Cyrix 6x86L で EX68 を動かす機会を作る事ができました。 6x86L の PR166+ に、Intel の 430VX チップセットマザー、そしてビデオカードは S3 Trio64V+ という やや古い環境でしたが、MPU エミュレーションも画面まわりも Pentium の 166MHz に比べて特に遅いと言うことはありませんでした。
＞ switch.xでメモリーを12Mbにしたのに、何故か1.2Mbになってしまうのは何故でしょう？ メモリが 1.2MB というのは Human68k ではあり得ない値ですよね.... 一部の SWITCH.X では EX68 でメモリを増やす事ができない場合があり ますが、Ver 2.xx の SWITCH.X のメニューモードならば問題ないはずで すし、SRAM 内のアドレスの $ED0008.L の値が #$00C00000 になっていれ ば問題ありません。 ＞ それと、mint.xもしくは、stfを作動させるのには無理があるのでしょうか？ TF.X から mint.x に移行したので、STF は使ったことがありませんが、 私の環境では mint ver.2.25 がほぼ問題無く動いています、というか これがメイン環境だったりします。 テキストブラウザで『速くスクロー ルさせるとハングする』という不具合を除けば快適に使用できています。
>foxbareのfpsも拡大時に半分以下になるので、似たようなものになると思われます。 とのことですが、 現在のEX68では実機での320x256モード等を BltStretchを使用して拡大していると思われますが、これを拡大ではなく、 画面モード320x240等を利用すれば良いのではないでしょうか？ yamamaさんの言われる「foxbareのfpsも拡大時」というのは x2 モードのことだと思われますが、 これは画面モード640x480に、320x240のバックバッファ画像を2倍拡大するもので、 画面モード320x240なら拡大無しで転送できるので、速度アップが期待できると思います。 (というより拡大による速度低下を防げるというのかな) もし私の勘違いで、320x240モードで速度が落ちたという場合、 それはリフレッシュレートによるものだと思われます。 PWR128Pであれば、320x240モードのリフレッシュレートを変更できると思うので、 是非試してみてください。 こうなってくると、画面モードの切り替えのタイミングですが、 オプションで現行の処理とフルスクリーンを切り替えることができるようにすれと、 それぞれのニーズに合わせて切り替えて使えば便利だと思います。 512x512以下のモードになると自動的に切りかえる、というのも あったら便利かと思います。 ちなみに、ここで言いたいことは、 DirectXの画面モード切り替え機能だけ使えば、 320x240等の画面モードでも拡大せずに大きくなる、ということです(^^;
>こういう高速化の論議ってのは、ゲーム関係のプログラムに関わってるとさんざん付きまとう >んですよねぇ。 >たのしいんだけど、面倒でもありますね。 >プレステとかの単純なハード構成だと割合「答えは１つ」に近いんですが。（笑） アーケードの場合は回路図もあって全部自前のコードだったりしたので、 処理速度は予測どうりというか、完全にコントロール出来るので安心出来ました。 プレステあたりは途中にライブラリがあって、ちょっと霧がかかってる感じでしょうか。 Windowsの場合はまだプログラムしてみて試行錯誤というところです。 で、DirectXで速くなるのかもう少しベンチを取って調べてみました。 256x256のゲームでbitbltの処理速度をQueryPerformanceCounterを使って計測しました。 画面モードは16bppなので256x256x2=128KByteの転送になります。 PCIバスは37.5MHzでPWR128P/4VCを使っています。 結果は 1.8msでした。これは逆算すると69.4MB/Secになります。 一方DirectXの場合。今月号のinsideWindows付録のDirectX5 SDKの中の memtime.exeでsystem->videoのdword転送速度を計測してみました。 結果は70.9MB/Secでした。 (表示は74.35..MB/Secだけどソースを見たら/10000000で割っていた(インチキ!)) この結果からはDirectXの導入では速度向上にはならないことになります。 また拡大表示はEX68が6.4ms、mmtime.exeはエラーが起きてわかりませんが foxbareのfpsも拡大時に半分以下になるので、似たようなものになると思われます。 しかし拡大時の転送時間6.4msは55f/sに取ってはつらい値です。 １フレームは18msなので1/3は転送時間に取られてしまいます。 ここで気になるのはvideo合成の処理時間です。 これは表示するプレーン数に比例するのでエミュレーションするプログラムによって 変わりますが、手元のプログラムで速いもので4ms、遅いもので20ms程でした。 グラフィックやテキストプレーンの合成は特に遅い原因になっているようです。 高速化としてはvideo合成の最適化が必要ということになります。 ちなみに55f/sでは18msからbitblt転送時間とビデオ合成の時間を引いた時間が MPUエミュレーションに割り当てられています。 仮にこの時間が6msぐらいだったとするとMPUエミュレーションは実機の3倍ほどの 速度が出ないと処理落ちすることになります。 v030でperformanceとpentium TSCをチェックするとこの表示を見ることが出来ます。 ただし互換CPUの一部では使えないようです。NTでは未チェックです。 >ＴＯＰページのリンク情報の リンク切れてたのを直しました。どうもありがとうございます。 >switch.xでメモリーを12Mbにしたのに、何故か1.2Mbになってしまうのは何故でしょう？ ちょっと半端な値ですね。memfree.xでの表示でしょうか？
switch.xでメモリーを12Mbにしたのに、何故か1.2Mbになってしまうのは何故でしょう？ それと、mint.xもしくは、stfを作動させるのには無理があるのでしょうか？
NTの場合、NT5になってもDirectにはならないと思う。 まぁ、個人的にはなってもらうと、NTの価値がぐっと下がると思うけど、 いくら速くても、不安定なOSは使いたくないし。 ゲームであるならなおさら、ちょいと思う時にちょっとやって、 さっくりやめたいし。 ちなみにいまは、よく、EX68で悟りをやってまする。
ＴＯＰページのリンク情報の >別のX68000エミュレータ >VX68000 現在準備中 404 Not Found らしーです >68000エミュレータ達 >FELLOW AMIGA エミュレータ 移転してます >UAE AMIGA エミュレータ 移転してます >STonX ATARI ST エミュレータ 唯一健在 でした。 一応報告だけ・・・
>実行すると、ディスクから起動できませんなどといわれてしまい、起動できないの>ですが、おそらくfd0.xdfというファイルが無いからだと思われるので、 下のURLに行くとわかるかもhttp://amo.fys.ku.dk/~osada/ex68faq/index-jp.html
前NT4.0をインストールした時にサービスパック３を適応して グラディウスDXPやMAME32を動かしてみたんですけど 結構重いですね（MAME32が特に重かった） まだソフトウェアエミュレーションだからなのかなぁ（よくわかんないけど(^^;） でも、デスクトップに戻ってきた時の画面の復帰などは、９５よりよかった
結構、条件が限られます。 NTでDirectXを使って動作するソフトとかは、たとえばDiabloとかは動きます。 Diabloの場合、95だとよくOSさりハングしますが、NTだと問題なく動くことが多く、 また、95だとALT+TABで別タスクに移動すると、OSがむちゃくちゃ重い状態なのに、 NTだと結構作業が出来ちゃうほど動きます。 DirectXはNTだとサポートされている数があって、 多分バージョンチェックで引っかかったりするんだとおもいます。 でも肝心のDirect3DはSP3でサポートされてたりと、 わりと、謎も多いです。 なんなんでしょうね。
実行すると、ディスクから起動できませんなどといわれてしまい、起動できな いのですが、おそらくfd0.xdfというファイルが無いからだと思われるので、こ ういった事は書いてはいけないのかもしれないですが、fd0.xdfというファイル の入手方法を教えてもらえませんでしょうか?
すみません。これで最後にします。 先ほどまでの私の話はすべて、1pixel単位で処理を進行することを基本に考えていた事であり、 数pixelのパック処理が前提ならばまた話がちょっと違ってくるでしょう。 ま、つまり、時と場合によるわけで．．． この手の話をソースも見ずにあれこれ論議しても始まらないと思いますんで、この辺にしておきます。 何かのご参考になれば幸いです。 私感ですが、WindowモードでのDirectDrawはあんまりbitbltと変わんない気がするんですがどうなんですかね？ あいや、あくまで気がする程度です。（実際にDirectDrawで書いたことないんで(^^;） ついでに、 >僕の環境では、ＤｉｒｅｃｔＸ対応の市販ゲームがまともに動作した試しが >無いので、全く信用できないものになってます。 ゲームでよく使われるmodeX(320*200/240*8)が使用できないカードが結構あるようです。 この辺のトラブルをよく耳にするので お〜たさん の環境もこの辺で引っかかってるのでは？？？
それはあまり関係ないことだと思います。というのは、データの長さではなくて >データの量を減らす、ということを言っているからです。 >転送するデータ量が半分になれば、その転送に必要とする時間も半分になる > のでは？ という発想です。 あいや、私は当然最終的なスクリーンバッファ（ま、いわゆるＤＩＢですね）はメモリに作成されて、 そこに各種合成処理を行っていると思っていたので（事実そのようですね）、「転送速度」という モノはbltなりstretchbltの段階だけの問題だと認識してた訳です。 だもんで、「８bitモードも16bitモードもあまりかわらない」という発言が出たわけです。 事実milleniumあたりだとほぼ変わらないわけです。（GDIアクセラレータの性能によります） んで、メモリ間転送という意味合いにおいては、昨日の発言のとおり、境界をまたがなければ 速度は変わらないはずだというわけです。（PCIバス通ってるわけじゃないですから） なので、バッファサイズの問題は昨今のマシン環境においてはあまり関係ないと思ったわけです。 こういった高速化手法ってのは、常にハードと込みで考えないとならん事だけに、PCの場合キツイ っすよね。(^^; 人によってぜんぜん環境ちがいますから。ただ一つの正解が無いに等しいわけで。 まぁ、この話はこのへんでもういいんですが。一応。(^^; 蛇足 こういう高速化の論議ってのは、ゲーム関係のプログラムに関わってるとさんざん付きまとう んですよねぇ。 たのしいんだけど、面倒でもありますね。 プレステとかの単純なハード構成だと割合「答えは１つ」に近いんですが。（笑） yamamaさんがんばってくださいね。
＞必要なプレーンにたいして処理が終わった時点でWindowsの15/16bitDIB形式の画像が作られます。 早い話が、僕が書いたことは既にやっている、ということだったんですね。 ということは、３２Ｋ色とフルカラーでパフォーマンスの差が出るのは、 ＷＩＮＤＯＷＳのＡＰＩが原因、ということになるんでしょうね。 ＞PENTIUMの場合8BYTE境界をまたがない限り、charだろうがwordだろうがlong wordだろうがかかるwaitサイクルは同じはずです。 それはあまり関係ないことだと思います。というのは、データの長さではなくて データの量を減らす、ということを言っているからです。 転送するデータ量が半分になれば、その転送に必要とする時間も半分になる のでは？ という発想です。 ＞NTだとDirectDrawをつかっても、GDI出力にマップされるんで、安定度も速度も変わらないですけど。 僕の環境では、ＤｉｒｅｃｔＸ対応の市販ゲームがまともに動作した試しが 無いので、全く信用できないものになってます。 少なくとも、かなりのビデオカードに制限が出ると思います。
v0.29ですが・・・同じ階層にx68opmemu.dllが入っているのに、「x68opmemu.dllがありません」と怒られてしまい、セットできません。 x68opmemu.dllの容量が84,286byteの場合ファイルが壊れているようです。 m_puusanが*.zipにアーカイブし直してアップされたみたいなので 取に行ってみては、どうでしょうか ＰＳ．私もよく起こりましたので(^^;
>題名とは関係ないですが、Ｗｉｎｄｏｗｓ自体の画面描写を、640*480以下にして>しまう事は、できないのですか？ そうすれば、256*256のゲームなんかは、 >より見やすくなると思うのですが。 これはDirectX化の利点ですね。私のビデオカードでは(WindowsのAPIで)640x480以下は設定出来ないようです。 >をしてもらえると嬉しいです。現用のハードが壊れた時のことを考えると恐くて寝られません(^^;。 うちでは今月になってCRTが壊れました。いまは切り替えて使ってますが、もう31kHzしか使えません。 >WindowsモードのDirectDrawで転送のみが速くなるのかどうか。 このあたりは今でも転送の負荷の大きいビデオカードでは効いてくるかも。 RIVA128のドライバーの更新でフレームレートに影響するほど変わったのを考えると。
DirectXの実装による高速化の期待が大きいようですが、 実のところEX68でどの程度有効かはよくわからないため優先度が低くなっています。 ここでEX68での実装ですが今ここで仮に、MPUのエミュレーション、 ビデオ画像の合成、Windows画面への転送の３つにわけます。 （１）最初に、ビデオ画像の合成の時点でWindowsのBitBlt等のAPIは使っていません。 各プレーンの合成はメインメモリ上でx86CPUが行っています。 ここは実機でのVRAMからRGB出力までのハードのエミュレーションに相当します。 主な仕事はX68000のpixel形式からWindowsのビデオ形式への変換ですが、 他に座標変換とパレット変換とRGB変換、特殊プライオリティ、 インデックスカラーでの透過とRGBでの透過判定などになります。 ラスタースクロールやスプライトダブラもラスターの記録を元にこの時点で処理します。 他に高速化するためのredraw line、blank lineの検出なども含まれます。 必要なプレーンにたいして処理が終わった時点でWindowsの15/16bitDIB形式の画像が作られます。 （２）次はWindows画面への転送になりますが、更新された領域を等倍転送でBitBlt、 拡大を含むときはStretchBltをSRCCOPYモードで使用しています。 転送元が15/16bitDIBですのでハイカラーモードではそのまま、24bitや32bitカラー ではWindowsがRGBのフォーマット変換をすることになります。 8bitカラーについてはビデオ画像の合成の時点から8bitDIBを作成していますが、 現在はコードのアップデートをしていませんのでやや不具合のあるまま使っています。 利点が無いのでいずれ削除するか簡略化したいと思っています。 ここでDirectXの利用を考えてみると。 （Ａ）最初はWindows画面への転送をDirectDrawに変更する場合。 WindowsモードのDirectDrawで転送のみが速くなるのかどうか。 全画面モードのDirectDrawでは転送は速くなりそうですが、Dialog等不都合が。。 （Ｂ）あるいはビデオ画像の合成からDirectDrawを使う場合。 コード変更が多いのが難点ですが、さらにピクセルフォーマット変換や パレット処理はCPUの分担かとなると速くなるのかどうかわからない。 という感じです。 優先順としては（１）のビデオ合成の修正 次に（Ａ）転送にDirectDrawを追加というところでしょうか。
callusっていうDOSのCPS1のエミュレータ CPS1は68000を使用して、FM音源を実装していますが かなりの速度で動きます。 EX68もこのエミュレータみたいな処理をすれば速くなるんじゃないでしょうか？
どうも、ＥＸ６８いつも有り難く使わせて頂いています。 v0.29ですが・・・同じ階層にx68opmemu.dllが入っているのに、 「x68opmemu.dllがありません」と怒られてしまい、セットできません。 また、常駐時に解除してから再度マークすると、「ＰＣＭが使えません」と いうエラーメッセージが出ます。 原因が分からないので何とも言えませんが・・・・取り敢えず報告まで。
下の「個人的には」の投稿、RS232Cがサポートされているように読めますね。すいません。
ゲーム関係だと速度は重要ですけど、最近サポートされたWinのドライブへのアクセスやRS232Cなど、機能の実装 をしてもらえると嬉しいです。現用のハードが壊れた時のことを考えると恐くて寝られません(^^;。 と、アイデアを出し合っているところに水を差すようになってしまいごめんなさい。 この辺、速度・安定度・機能実装、と、どこに手を入れるのが手応えがあるか、というところはyamamaさんの着目 しだいだと思うので、どれが先でも楽しみです(^^)。 というなんの手伝いもできず期待ばかり大きい人なのですが、変なプレッシャーに感じたりしたらすいません(^^;。
Direct Drawだけでもむずかしいのかな? NTだとDirectDrawをつかっても、GDI出力にマップされるんで、 安定度も速度も変わらないですけど。 DirectDrawだとおもしろい事ができるのかもって、 詳しいことは全くわからないのですが。
ちなみに、newでメモリ確保した時のアライメントは言語系に依存すると思いますので、 その場合GlobalAllocを使った方が良いかもしれません。 これは一応、8byteアライメントな事が明記されてますんで。（但し確かめた事は無い（笑））
PENTIUMの場合8BYTE境界をまたがない限り、charだろうがwordだろうがlong wordだろうが かかるwaitサイクルは同じはずです。 さらに、昨今のビデオカードは8bitモードでも16bitモードでもbltのスピードは大差無いとも思います。 それを考えると、いろんな処理しながら８bitに落としても速くならない気もしますが？？？ それに、8bitじゃ半透明できないっすよ。(^^; 結局の所、私は作者じゃ無いんで内部構造知らないんでほんとのところは分かりませんが..... 個人的にはＤＯＳに一票。（笑）
長文ですみません。 たびたびＤｉｒｅｃｔ−Ｘを採用して高速化・ＤＯＳ（ＶＧＡ）で 高速化、というようなのを見かけますが、基本的に僕は賛成できません。 というのは、目先の速度によって安定性が失われてしまうかもしれない からです。少なくとも、現在よりも環境が限定されるでしょう。Ｄｉｒｅｃｔ −Ｘ自体もまだ発展途上にあり、まだ様子を見た方が良いと考えます。 以前、少しだけ書きましたが、バッファのデータそのものを少なくする 方法が良いと考えています。 具体的には、現在Ｇ−ＲＡＭ（画面表示用バッファ）には、Ｗｉｎｄｏｗｓ で使用している画面モードでＸ＊Ｙドット分の領域を確保しているかと思います。 ２４ビットカラーであれば、３バイト＊５１２ドット＊５１２ドット分です。 １６ビットカラーなら、２バイト＊５１２ドット＊５１２ドット分で、２／３ のデータ量ですみます。 それなら、いっそのこと１バイト（２５６色）でも良いと思います。ほとんど の場合、２５６色しか使っていないでしょうから。 複数画面を合成した場合、２５６色で不足する可能性もありますが、最も近い 色に変色してしまっても、さほど問題にはならないでしょう。 画面イメージを２５６色ＢＭＰとして扱うと、あとの処理はＷｉｎｄｏｗｓが やってくれるでしょう。 ＃Ｗｉｎ９８では、画面周りが異常なまでに最適化（高速化）されているよう で、若干パフォーマンスが良かったようです。
自作のゲームで、ＣＲＴＣを直接いじって224x288にしてるのがあるんですけど、 スプライトが縦に２５６ドットを超えたとこで表示が消えてしまいます。 下記ＵＲＬにディスクイメージを置いときますんで、良かったら表示されるようにしていただけませんか？(^^; http://www.kanazawa-net.or.jp/~fnew/mcha.lzh 大きさは385312バイトあります。
確かにDirectXを使えば高速に描画できますが、恐らく半透明の処理等が逆に実装しにくくなってしまうと思われます。 しかも描画ロジックが全くといいほど変わってしまいますので、その負担を考えると...http://www.geocities.com/Tokyo/Garden/4362/
誤)ちゃんと意図した通りに再生してくれるのがベストです。） 正)貧力な環境でも、ちゃんと意図した通りに再生してくれるのがベストです。） 修正します。
>音がやたらと間延びしていました(非常に間抜けなことをしてしまった)。 >29日版では一応直しておきました。でも、音自体はやっぱりかなり悪いですね。 前より音質良くなりましたね 22KHz版だとかなり軽くて家のマシンだと快適です（今裏でMDX鳴らしてます(^^;） >重くしたつもりはなかったのですが、間違って重くなっていたようです。今度のは>逆に少し軽くしたつもりなのですが、どうでしょう？ 工夫次第で、実機と同様のテンポで再生出来るようになりました。 家の環境は、サウンドカード２枚差しでADPCMも発音してくれるのですが 軽くなったおかげで、ADPCMと同期再生していないことが明らかになりました （少しズレてますねしょうがないんだけれど(^^;） ＰＳ．22KHzモードは個人的には、賛成ですね（音質は、落ちるんですが ちゃんと意図した通りに再生してくれるのがベストです。）
最近思っているのですが、EX68自体の複数起動を考慮しなければ、 描画にDirectXを使うことでかなり軽くなるのではないかと思って いるのですが、いかがでしょうか。少なくとも今のようにBitblt をパワーでごり押すよりは良いのではないかと思うのですが。
v0.28ではmdxが再生されませんでしたが（Z-MUSICは大丈夫だった）、 v0.29では無事再生され、昔作ったものを一通り聞いています。 音色面では、実機と聞き比べても遜色ないどころか低音、高音増強できたり 周波数変えられたりするので、ある意味オリジナルを超えてますね。 が、テンポがあいません。P2の416Mhzを使っているのですが 55f/sec の x1 だと、実機よりもテンポが遅く、 55f/sec のチェックを外すと 無茶苦茶速くなってしまいます。 ゲームによっても、テンポが全然合ってくれないものと、ちゃんとあってくれる ものとあります。どうすればいいでしょうか？ 題名とは関係ないですが、Ｗｉｎｄｏｗｓ自体の画面描写を、640*480以下に してしまう事は、できないのですか？ そうすれば、256*256のゲームなんかは、 より見やすくなると思うのですが。
>ですけど、音の劣化が結構激しいので、無理して44KHz版を使用してます(^^; 22kHz版ですが、44kHz用のエンベロープをそのまま使ってしまい、 音がやたらと間延びしていました(非常に間抜けなことをしてしまった)。 29日版では一応直しておきました。 でも、音自体はやっぱりかなり悪いですね。 >ＰＳ．さらに重くなったみたいね 重くしたつもりはなかったのですが、間違って重くなっていたようです。 今度のは逆に少し軽くしたつもりなのですが、どうでしょう？ >ちょっと疑問があります。OPM EMUのDLLですがMMX対応しているんでしょうか? >対応していないと仮定してMMXに対応した場合どれくらい軽くなるもんでしょうか? 3月に入ってから開発を始めたので、とてもMMX化までできません。 ADPCM再生等まだやらなければならないことがたくさんありますし。 内部の計算はほとんどテーブルを使った計算ばかりなので、 MMXよりCPUの１次キャッシュの量の方が重要かな？
考えてみればdimかxdfにしておけばすぐに使えますね。 windrvはまだディレクトリのアクセスがおかしいときがあるみたいで このあたりがちゃんとしないと、書き込みは危ないですね。
ちょっと疑問があります。OPM EMUのDLLですがMMX対応しているんでしょうか? 対応していないと仮定してMMXに対応した場合どれくらい軽くなるもんでしょうか?
yamamaさんwindrv.sysは、*.dimファイルにして同梱した方が 効率がいいような気がしますけどどうでしょうか？ *.dimならX68やEX68でも手軽に読めますし
早速試してます。verupご苦労様です。感謝してます＞作者の方々 前のverですと、まーくん２さんも指摘されてましたがファイルが読めたり読めなかったり していたのですが今のところおかしいところはないようです。 ただKowindowが起動しなくなってしまったようです(v0.28から) ドライブ認識のところでエラーがでるようです(windrv.sysを外せばok) mintも問題なく使えているようです(ver1.81 hikaru14) x68opmemuですがやっと音か出るようになりました(^^; 今まではハングアップして使えませんでした。 22KHz版で試してますがうちではこれが限界ですね(p54-166) ゲームはスピード的に無理みたいですがmdxとか聞くだけなら問題ないみたいです。 なんかex68&opmemuの為にマシンpowerupのキッカケが発生しそうです。
私の使っているファイラー(Fu.X)にてWinドライブ -> X68ドライブのコピーが正常出来るようになりました(^^ GORRYさんのFA.Xも試しましたがバッチリコピー出来ました Winドライブに置いてある*.MDXをプレイヤーにて読み込んでみたところ しっかり演奏してくれました(^^ ● 手持ちで正常動作しなかったツール MMDSP.R ドライブにアクセス出来てサブディレクトリは、表示されるものの ファイルが表示されない（当然ドライバは、常駐済み） FF.X(FileFinder) Winドライブが表示されない Winドライブからファイルをもってこれるようになったので Mint等の他のファイラーやツールもいろいろ試してみたいと思います。 ＰＳ．書き込み可になれば、プログラム作成やデータ作成も本格的に 出来るようになりますね(^^
>一応、強引に22kHz再生にしたものも作ってみました。 いただきました。 ですけど、音の劣化が結構激しいので、無理して44KHz版を 使用してます(^^; ＰＳ．さらに重くなったみたいね
yamamaさんにOPMエミュDLL化に対応して頂いたので、 早速OPMエミュの方もバージョンアップしました。 以前は全体的に音に変調がかかりすぎていたようなので、 変調度を少し下げてみました。 いかがなものでしょう？ >ここに書くのも何ですが・・・OPMえみゅなんですが出力を >22MHに対応すればEX68Kの動作が軽くなると思うのですが・・・・ 一応、強引に22kHz再生にしたものも作ってみました。 22kHz用の音の調整は一切していないので、音的にはいまいちです。 ただ、やはりかなり負荷が軽くなります。 22kHzだとウチの環境ではEX68上のドラスピが描画更新速度x1でちゃんと動きます。(^^) OPMエミュの最新版は次のリンク先にありますのでご利用下さいませ。http://www.venus.dti.ne.jp/~mpuusan/opmemubody.htm
ここに書くのも何ですが・・・OPMえみゅなんですが出力を 22MHに対応すればEX68Kの動作が軽くなると思うのですが・・・・ （ならないかな？？）どうなんでしょうか？ あまりその変のことは無知なのでわからないのですが他の えみゅでも22MHのオプションとかを選ぶと軽くなりような ものもあるようなので・・・
m_puusanさんのOPMエミュレータのDLL化に対応しました。 リモートドライブの読み込みのいくつかのバグに対処しました。 >何故か１０ｍｂもメモリ指定してるのにメモリ不足と出てｒａｍとかつかえませんなぜ？？？？ これはバグの様ですが、まだ原因不明です。XCでもメモリ不足でリンクが出来ないみたい。 キーコードはJISキーかUS101キーかの違い、またはキーエミュレーションの 方法を選択するオプションによって変わります。 JISキーならSCC割り込みを使うか、AT2X.KEYを書き直してIOCSで使うかになると思います。
: ”:”と”^”が入れ替わってません？ optionのキー割り込みエミュレーションにチェックが入ってませんか? 一度調べてもらえるとありがたいです。 # それよりも私はWindows95を大きいフォントでつかっているんで、 # option画面の文字列が欠けてしまう方が気にはなります : ウエイトをかけるなりして実機以上のスピードにならないように : できないものなのでしょうか？ 描画更新速度等の設定は適切ですか?
ＦＭエミュすごいです。 感動しました。 で、ちょっと気になったんですけど ”:”と”^”が入れ替わってません？ コマンド打ってドライブ切り替えるとき気になるんですけど。 一度調べてもらえるとありがたいです。 あと、家で実以上のスピードがでて困るときがあるのですが ウエイトをかけるなりして実機以上のスピードにならないように できないものなのでしょうか？
どのようなときですか? Humanは実機(x68kで)つかったことありますか? メモリ不足ですというエラーはアプリケーションがだすのか、 それとも、シェルがだすのか、システムがだすのかで、 意味が全然違います。
何故か１０ｍｂもメモリ指定してるのにメモリ不足と出てｒａｍとかつかえませんなぜ？？？？
ASKでは、Shift+'i'で、「ィ」が入力できます。 他の小文字も同じ方法で入力できます。
WINDOWSだと "x", "i" や "l", "i" とキーを打つと、小さいイ（”ィ”）が入力できますが X68で、ィ（小さい”イ”）をローマ字入力するには、どのような組み合わせになるのでしょうか？http://www.lares.dti.ne.jp/~nicole
X680x0用ツールでHD.HDFをドライブとして扱う ソフトありませんでしょうか？
早速、Ver0.28を使わせて頂きました。 FMの再現率すごいですね。ZMUSICとMDXのサウンドファイルがほぼ完璧。 ただ、PCMが鳴らないのが･･･
今のところツールによってドライブ内の見え方が違いますね(^^; ドライブ自信が巨大なファイルになってたり＜FF.X ファイルが全く見えなかったり＜MMDSP.R ファイルコピーツールでイメージ内にコピーしようとすると 「ファイルが見つかりません」のエラーが出たり コピー出来たとしてもボリューム属性が付いていたり(^^; ネットワークドライブ扱いだからかなぁ ＰＳ．COMMAND.XのCOPYコマンドは、正常に動作しました。
>用のジョイスティックの動作確認しました。 >スティク・Ａ・Ｂ・ＳＴＡＲＴ・ＳＥＬＥＣＴ全て正常に動作しています。 動作確認ありがとうございます。 >サウンドカード２枚差し環境だと >ADPCM+OPMエミュでちゃんと鳴ってくれるようです。 現在はADPCMのWAV出力とX68kOPMEMの出力は同じデバイスを別々に使うので 普通は同時に指定出来ないのですが、カード2枚なら別々に割り当てて動作してるのですか。
「悟り」ってあの延々弾をよけ続けるあれっすか？ あれはいいですね。某Ｚ社のＴ氏の名作です。 ってちがうヤツだったりして。（笑）
>やはり鳴りませんでした。パラメータを軽目にしたり重目にしてもだめです。 >さらに、UAEが起きるようになってしまいました。少なくとも以前のバージョンではUAEは発生していませんでした。現在のNT上での問題点を列挙します。 >命令のアドレスは毎回0x00407ba9で参照しようとしているアドレス >は0x60431xxxから0x60432xxxあたりで変化しています。VCでア >タッチして見てみましたがdsplay.exe内のようです。（DLL内ではない！） 早速動作確認ありがとう御座います。 これでだいぶ原因が絞れてきました。 私のホームページに掲示板を作りましたので、詳しいことはそちらでお願いします。http://www.venus.dti.ne.jp/~mpuusan/bbs/bbs.html
さっそく新たなdsplay.exe試させていただきました。 しかしながらPRO2改氏と同様Application Errorが発生するように なってしまいました。 命令のアドレスは毎回0x00407ba9で参照しようとしているアドレス は0x60431xxxから0x60432xxxあたりで変化しています。VCでア タッチして見てみましたがdsplay.exe内のようです。（DLL内では ない！）
初めまして。いつもＥＸ６８は、お世話になっております。 ＶＥＲ０．２６ｂで作成したＨＤのイメージなんですが、０．２８ にバージョンアップしたと聞いたので、アーカイブファイルをその 使用しているディレクトリにそのまま展開したのですが、何もさわ っていないはずのＨＤ０．ＨＤＦが、読めなくなってしまいました。 正確には、ＯＳ（ＨＵＭＡＮ）は起動できるのですが、階層ディレ クトリいかにあったすべてのファイルの、アクセスできなくなって しまいました。イメージ中の、使用しているディスク容量は前のま まなので、まだ復活の手だてはあると思うのですが、どうしたらよ ろしいでしょうか。
動作確認ゲーム表ってあるんですか? 最近うちでは「悟り」をリヴェンジしてプレイしています。 float2.xのver1を探すのに手間取ってしまったけど、 見つけたら若いときに作ったリプレイが見れて感動しました。 いやぁ、昔はシューティング、うまかったんだなぁ。
いままで使っていたＩＳＡのカードからＰＣＩのものに変えたら うまく音が鳴らなくなりました。 何故でしょうか？ 鳴ることもあるのですか、その時はスピードを何にしても曲自体の 速さは変わらず速いままだったり音が変な音色になったりします。
>ところで、NTで使えるPCIのサウンドカードって、誰かいいもの知りま >せん? うーん現状だと難しいかもしれませんね 高級なカードになるにしたがってNTは、対象外になってるみたいだし クリエイティブブランドで、今度新サウンドカードが発売になるようですよ （PCIバス用）クリエイティブならNTも期待出来るかと >SBAWE64はNTだといまいち使いづらいです。 >私だけかもしれないけれど。 私は、64Gなんですが、それは言えてますね（ちゃんとしたドライバ 作ってほしい）２枚目のGUSも例外じゃないけど(^^; ということで5.0&98のWDMドライバに期待してます。 ＰＳ．いじる物がサウンド関係が大多数なんだけどNTでサウンドを満足に 扱えないので乗り換えられないっす（5.0に期待）
サウンドカード2枚かぁ。 ところで、NTで使えるPCIのサウンドカードって、誰かいいもの知りません? SBAWE64はNTだといまいち使いづらいです。 私だけかもしれないけれど。
サウンドカード２枚差し環境だと ADPCM+OPMエミュでちゃんと鳴ってくれるようです。 ＰＳ．書き込み見ていると１枚の環境だとならないようで 全然気づかなかった(^^;
すみません下記文中で改行入れ忘れました。 読みづらい文章になってしまいました。失礼しました。。。
やはり鳴りませんでした。パラメータを軽目にしたり重目にしてもだめです。 さらに、UAEが起きるようになってしまいました。少なくとも以前のバージョンではUAEは発生していませんでした。現在のNT上での問題点を列挙します。 （１）音が鳴らない。 （２）PCM出力を手放さないことがある。（正常な終了後であっても他のアプリケーションから使えなくなることがある。） （３）UAEが発生する。（最新版の3/23版において選曲してから１秒から２秒後くらいで発生） なお、環境はP2-300+RAM128MB+NT4W+SP3です。 ちなみにx0.28の方は上記の理由でMMX-200MHzの95環境で試しましたが、速度は遅くテンポも少々おかしいものの、音色の再現性には感動しています。CPUパワーさえ許せば現状で最高の選択肢といえると思います。
: ｎＶＩＤＩＡ二月二日付のドライバーをいれたところ、ドラゴ さっそくゲットしてインストールしました。 : いけるようになりました。ＲＩＶＡ１２８ユーザーはおすすめです。 そうですね。へぇー、本当はこんなに速かったんだ、と感心させられます。 ko-windowやSX-Windowも以前はもたついて、まぁエミュレーションだし しょうがないか、とあきらめてたんですが、どうやらドライバの方が 足を引っ張っていたようです。今では結構サクサクと動いてます。 ちょっと使ってみた感じではACEよりも速いような… 私のところでは(PentiumII-300MHz+64MB+RIVA128AGP)、OPM関係を 使っていると(mxdrv等、OPMEMU利用)重くなりますが、実機のACEと 体感上は変わらぬ速度でEX68は動作しているようです。だんだんと 実機のX68kでなければできない事というのが減ってきているようで、 うれしいようなちょっと淋しいようなそんな気持ちです。 今後の発展を応援します。
yamamaさんにX68kOPMエミュを組み込んで頂いたので早速いろいろなゲームの音を聞いてみました。 ドラスピだけでここまで音の調整をしましたが、結構いい線いっているのではないでしょうか？ ただ私は、全体的にちょっとFM変調がかかりすぎているような気がするんですが、どんなもんでしょう？ あと、サウンドカードやアンプのトーン調整(高音と低音)をすると結構実機に近い音になるようです。 ウチのSoundBlaster16PnPの場合、Volume Controlの「トーン」ボタンで、 低音のつまみをちょうど真ん中に、高音のつまみを真ん中より一目盛り高くすると 結構実機に近くなるような気がします。 それから皆様、いろいろと動作報告ありがとう御座います。 >m_puusan氏のOPMエミュはWindowsで提供されている機能を使用して音を鳴 >らしているので鳴るのではないかということでしょう。 >実際、最初のVer（dsplay.exe）では鳴っていたので・・・。 この件ですが、ウチにはNTはないので、原因が全く分かりません。 考えられる原因を思いつくままに書くと 1.LFOに対応したため処理が重くなった。 2.演算精度を高めるために主要な計算テーブルを2倍の大きさにした。このため処理が重くなった。 3.マルチメディアタイマーの割り込み間隔を 10ms から 5ms に変更した。 4.単純にエンバグした。 5.その他 このくらいしか思いつきません。 皆さんの話をうかがっていると、1.や2.ではなさそうです。 また95環境では問題なく動いていることから4.ではなさそうな気もしますし。 そこで、ちょっと確かめていただきたいのですが、 先ほど私のホームページのdsplay.exeを改変しました。 この新版のdsplay.exeではOPMの発音数と割り込み間隔を指定できるようにしました。 これをNT上で >dsplay.exe 2 10 くらい（発音数2、割り込み間隔10ms）で実行したら動きますでしょうか？ 是非御報告下さい。参考にします。
NTでは皆さんが書いてあるとおり、OPMが動かなかったみたいです。 95ではうまく動きました。 こういうのこそ、SMP対応だったりすると、すごいいいですね。 ところで、-oオプションを指定したとき、セーブするのは、-oで指定した ファイルなんでしょうか? デフォルトのx68.cfgが書き込み禁止のネットワークドライブにあったとき、 ローカルのドライブにx68.cfgをつくって、そこで読み書きしたいんですけど、 技とかってありますかねぇ?
> ＮＴでは、音源の制御を直接行うことができないので、アプリケーション >エラーが発生します。 > つまり、ＮＴでのＯＰＭエミュレーションは、実行できません。（ｏｐｔ >ｉｏｎ．ｔｘｔにも記述があります。） 0.27以前からあるSB直接駆動のＦＭ音源を鳴らす機能は確かにI/Oをダイレ クトに行っているようなのでＮＴでは動作しませんが0.28で追加された m_puusan氏のOPMエミュはWindowsで提供されている機能を使用して音を鳴 らしているので鳴るのではないかということでしょう。 実際、最初のVer（dsplay.exe）では鳴っていたので・・・。 最初のVerのようにＮＴでも鳴るようにしていただけるととってもうれしい です。＞m_puusan氏、yamama氏
＞さっそく試してみました。しかし0.28で組み込まれたOPM Emulationが ＞うまく行きません。 ＮＴでは、音源の制御を直接行うことができないので、アプリケーション エラーが発生します。 つまり、ＮＴでのＯＰＭエミュレーションは、実行できません。（ｏｐｔ ｉｏｎ．ｔｘｔにも記述があります。） この状況を回避するには、過去にどい氏が紹介してくれた、totalioという ドライバを使用しなければなりません。 ただ、このドライバーを使用すると、ＮＴがせっかく保護してくれている システム領域を勝手に操作できるようにしてしまうので、システムが破壊される 可能性があります。実際、このドライバーを使用中にコマンドプロンプトを 使用すると、画面表示がおかしくなり、ブルーのダンプ画面を拝むことに なりました。
ＣｙｒｉｘＭ２の８３＊２ＭｈｚとＲＩＶＡ１２８で物凄く おそくて（ドラゴンスピリットでさえフレームスキップ＊４、 幻影都市にいたっては＊＊＊）あたまを痛めていたところ、 ｎＶＩＤＩＡ二月二日付のドライバーをいれたところ、ドラゴ ンスピリットならば＊２で、ストライダー飛竜では＊１でも いけるようになりました。ＲＩＶＡ１２８ユーザーはおすすめです。 win95_131.zip http://www.riva128.com/
さっそく試してみました。しかし0.28で組み込まれたOPM Emulationがうまく行きません。具体的には音が鳴らないのと、いくつかの場面でUAE（ワトソン博士、つまりWin95で言うところのGPF)が出ます。 (1)OptionでOPM EMUを選んでＯＫを押した瞬間。 (2)(EX68の)Resetを押した瞬間。 (3)AC Plugや「Porwe」ボタン、(Win標準の）「×」ボタンを押した瞬間。 (1)を選んで死ななかった場合でも音は出ず、かつ(2)(3)の操作で確実に死にます。この音が出ない件ですが、以前の書き込みで「どい」さんがdsplay.exe（OPM EMUの評価ソフト）についてＮＴで音が鳴らなくなった（最初のバージョンだけ鳴った）旨を書かれていますが、私も同様の症状です。この事から、音が出ないこと自体は多分ドライバ自身の問題ではないかと思っています。 私はＮＴユーザーなので、環境に依存しない（PCMさえ鳴れば動く）OPM EMUに期待しています。yamama氏、m_puusan氏に敬意を表します。がんばってください。
はじめまして。 Windows98 Preview版が届いていたので、早速新規インストールして EX68(Ver0.28)を少し使ってみましたが、特に問題なく動作しました。 ところで、最近なかなか更新されないなと思ってたら、 こういうことだったんですね。お疲れさまでした。
用のジョイスティックの動作確認しました。 スティク・Ａ・Ｂ・ＳＴＡＲＴ・ＳＥＬＥＣＴ全て正常に動作しています。 なお動作確認には、手元にあった TNB製作所のMJIC4.X Ver.4.01を使用しました。 でも、このジョイスティックが本来のジョイスティックなんですよね(^^; ＰＳ．これで私の９８上でもまとも(?)にゲームが出来ます(^^
久しぶりに書き込みます。 0.28なんですが・・・ＦＭ音源の音色は満足です。お気に入りのFLASH FLASH FLASHも聴けますし凄いの一言です。 あとはテンポの調整とAD-PCMの同期さえすればOKなのではないでしょう か？ ちなみにP55C-233MH+PowerWindow R128Pですが・・・重いです。 やはりPentium2は必修なんでしょうか？ では頑張ってください。応援します。
うわぁもう組み込まれたんですか(^^; 速いっすねー 早速使っているんですが、Pentium 200 MMX程度のマシンじゃ かなりきついですね 現状の最低条件は、Pentium 266MHzぐらいパワーがないと 結構きついですぅ OPMエミュの方の最適化に期待ですね ＰＳ．でも、さすがに音は、いいですねー(^^)凄いっすまさに驚異
>>Human3.02以上でwindrv.sysを登録します。 >もってないっす（泣） リモートドライブを使えるのがこのバージョン以降らしいのです。残念。 >ロングファイルネームが見えません（VTwentyOne常駐していてもだめだった） そか。VTwerntyOne使えばWin95仕様のファイル名を渡せるのですね。 >私も期待したいです。 >でもADPCMが鳴らせない現状のOPMエミュレータじゃ載せてもしょうがないかな。 ADPCMにも期待してますので。
m_puusan氏のX68kOPMエミュレータを組み込みました。 テンポがずれるのはEX68の駆動タイミングがずれてるためです。
PenPro166MHzのNT4.0上でテンポ落ちなどもなく鳴っています。 ・・・っていうか鳴ってました。 一番始めに置いてあったやつでは鳴るのですが、3/21と3/22更新分では まったく何も鳴らなくなってしまいました。CPUパワーは前と同じように 食ってるので処理そのものはやっているようですけど・・・。 しかし、再現性はいいですね。完璧ではないけどこんだけ再現できれば ほとんどの人が満足できるのでは？
ＥＸ６８頂きました。ありがとうございます。ＣＤ−ＲＯＭまで動作するということでやっと電クラのＣＤが日の目を みました。ｏｖｅｒｔａｋｅをやってみようとしたのですがｄｉｓｋの入れ替えのところで入れ替えができなかったですね。 仕様なのかな？まだ過去ｌｏｇまではみてないので確認してみまーす。 pentII300Mhz DELL dimensionにて動作
はじめまして。 Cyrix 6x86L-200+でも正常に動作致しました。さすがに負荷が大きいですが、 テンポ落ちもほとんどなかったです。再現度の高さに感動しました。 EX68に搭載される日を心待ちにしております。http://www2r.meshnet.or.jp/~j-mossan/
しかし・・・ >Human3.02以上でwindrv.sysを登録します。 もってないっす（泣） もともとバリバリ使ってたんじゃなくて、すぐにお蔵に入っちゃった機械なんで・・・新しいOSなんか無いっす（泣）
とうとうＡＴ上のドライブにアクセス出来るようになりましたね(^^) まだ、テキストファイル読むぐらいしか試してませんけど いやーこれでこれから便利になりますね ロングファイルネームが見えません（VTwentyOne常駐していてもだめだった） がこれから対応するんでしょうね 以前から某プレイヤーの為にＡＴ上のドライブにＭＤＸデータを多数 持って来てあるんですけど、今後これらがさらに生かせるようになります。 Yamamaさんどうもありがとうございます。
早速頂きました。ありがとうございます。 なんか凄いですね。mo,cd-romともにアクセス出来ました(^^; vdtもcdrom上から再生出来てます。 益々実機に近づいている感じです。 これはex68用にHDDのパーティションを切り直す必要がありそうですね。 またいろいろ試してみます。
がＥＸ６８に搭載されたら 素晴らしいとしか、言いようがないですね(^^) 早速最新版使わせていただいてます。 ＯＰＭエミュですけど、前の版より少し重くなっている気がします ＰＳ．m_puusanさんホームページにＢＢＳ開かれては、どうでしょうか？
>うちのdos/vはbase66MHzのPentium166MHz相当ですが >たまに遅くなる程度で特に気にもなりませんでした（ただし >演奏中は他のウィンドウはほとんど動かせなかった(^^;))。 Pentium166でも動きましたか。 >家のマシンはPentium200MHz(MMX)です。たまに >テンポ落ちすることはありましたが、マシンに負担は（あまり）かかっていない >ようでしたし、テンポ落ちもそれほど気になるものではありませんでした。 MMX-200ぐらいで十分そうですね。 ホームページでの動作必要条件の記述も低くしました。 ウチのPII-300だと、演奏しながらEX68でドラスピがちゃんと遊べます(描画更新速度はx2)。(^^) 先ほど、X68kOPMエミュレータの本体(ライブラリ形式)をホームページにアップしておきました。 あと、LFOもサポートしました。よろしかったらお試し下さい(ちょっと重くなっているかもしれない)。 >EX68に搭載される日を待ってます。。。 私も期待したいです。 でもADPCMが鳴らせない現状のOPMエミュレータじゃ載せてもしょうがないかな。http://www.venus.dti.ne.jp/~mpuusan/x68opmemu.htm
OPMエミュレータ、使ってみました。凄い！ 細かい所を突いていくと色々あるんだと思いますが、取り敢えず再現率の 高さに震えました。家のマシンはPentium200MHz(MMX)です。たまに テンポ落ちすることはありましたが、マシンに負担は（あまり）かかっていない ようでしたし、テンポ落ちもそれほど気になるものではありませんでした。 家ではSound BlasterのEmuが正常動作しない（というか音が一切鳴らない） ので、このエミュレータはとても期待が大きいですね。EX68に搭載される日を 待ってます。。。
ちゃんと動きますよー。再び不老不死キャラづくりに はげみましょー(笑)。
早速使わせていただきました。かなり再現率はいいと思います。 うちのdos/vはbase66MHzのPentium166MHz相当ですが たまに遅くなる程度で特に気にもなりませんでした（ただし 演奏中は他のウィンドウはほとんど動かせなかった(^^;))。 こいつは個人的に期待が大きいです(かつてのmcdrv開発陣の一員として)。
ＭＭＸ−２００＋ＶＩＲＧＥという普通の環境ですが、友達が大好きな スーパーマリオをやらせてあげました。 あと、Ｐａｎｉｃも見たけど、ちょっとパワー不足 ｍｉｎｔは、怪しい割り込みを多用しているせいか、動きませんでした。 でも、カスタマイズの方法を忘れてしまったので、あきらめ・・・・
YS1(不気味じゃない方)とYS2が凄まじい速度で動きました。 又、桃太郎伝説もかなり良好。あと、Z's staffも重いながら正常動作。 動作環境は、pen2 300MHz RIVA128 でWin95です。
前から拝見＆ダウンロードはしてましたが初投稿です。 ADPCMが鳴る場合と鳴らない場合（ゲーム等）がある以外は快適です。 98PP上で、グラディウス１が55f/s､x1で快適です。 （ちょっと速いかもしれず） これからも頑張って開発を続けて下さい。
最初に実行したのはPenII300(NT)だったんですけど、 いまは結局Windows95マシン、MMXPentium225(75x3)、Mystiqueで 動かしてまする。ケースバイケースだけども、 ゲームするにはこっちのほうが速いのかもしれない。 NTマシンはサービスたくさん動かしてるし、 いつも巨大なアプリが走ってるので(お仕事マシンだから)、 わかんないんだけど。 DirectDrawとか使ってるのかな? NTってDirectDrawはGDIエミュレーションだから、 画面描画は微妙におそいかもしれないなぁ。 16ビットカラーにしたら、Graidus、R-TYPEが1syncで動いて、 感動しました。
>マシンはPentiumII 300MHz (440FX)、Millennium 2つさし、WindowsNT4.0で >す。 うわぁ凄まじいパワーのマシンをお使いで(^^; やっぱりエミュの動作無茶苦茶速いんですか？ ＰＳ．pcmplay今でも、たまに使ってますよー
動作確認してみました。 とりあえず動いのたを見て、 思わず胸が、きゅ〜んとなってきてしまいましたね。 ああ、わが青春の日々ってかんじです。 マシンはPentiumII 300MHz (440FX)、Millennium 2つさし、 WindowsNT4.0です。http://www2f.biglobe.ne.jp/~kohju
現在、X68k OPM エミュレータを作成中です。 エミュレータだけ作っても演奏ドライバがないと鳴らせないので、 とりあえずX68kドラゴンスピリットの演奏ドライバを移植してみました。 ドラゴンスピリットを持っていて、かつCPUパワーがある人は、 是非鳴らしてみて下さい。 結構近い音が出ていると思います。http://www.venus.dtinet.or.jp/~mpuusan/x68opmemu.htm
ADPCMってまだちゃんとemulateされてないのか、ならないのもありますね。 まだ最後までプレイしてませんが、ちゃんと動くと思われます。 (古い書き込みと重複があればお許しを） ボスコニアン、源平討魔伝、はADPCMがちゃんとならない程度です。 テラクレスタは曲が正常になりません（こっちのDOS/Vの設定が悪いかも)。 スターウォーズも正常になりません（これは、まいましんが遅いからかも）。 ドラスピはゲームスタート後、自機は動かせるけど背景、敵が現れません。 動作確認リストなんかあればいいかなぁと･･･
ファンタジーゾーンで遊んでいるのですが、ｓｈｏｐに入らなければ 思っていたほど違和感なく遊ペます。 ところでｓｈｏｐに入るとアイテムや、カーソルが表示されないのは しょうがないのでしょうか？
先日、Ｗｉｎｄｏｗｓの画面モードを変えて、それぞれの色数での ＥＸ６８の動作速度を比較してみました。 ベンチマークなどは一切行わなかったので、数値データはありませんが、 ３２７６８色のときがもっとも高速のようでした。 おそらく、画面イメージをそのままｗｉｎｄｏｗへと転送されている ために、色数によってデータ量が変化するもの、と推測しました。 フルカラーや、３２ｋ色では、実際には色コードの上位ビットには ほとんどデータが入らないものと思います。そこで、このデータ量を 減らすことができれば、大幅なパフォーマンスアップが期待できると 思います。 また、音源の再生や画面描画で処理が重いような場合でも、別タスク は案外サクサク動いていました。このことから、ＥＸ６８でマルチスレッド 処理を実現できた場合、画面処理のウェイト音源処理の割り込みなど の負荷を軽減できる、と思います。 ほとんどに当てはまらないと思いますが、マルチスレッドになると、 ＳＭＰ（マルチＣＰＵ）環境では、パフォーマンスの向上が確実に実現でき ます。 詳細は、まとまり次第投稿します。
＞以下のURLに作成したエントリをレジストリエディタで保存したものを置いて ＞おきますのでダウンロードして使ってみてください。ファイルをダブルク ＞リックすればレジストリにエントリが追加されると思います。 遅くなりましたが、うまく登録できました。ありがとうございました。 現在、仕事中なので音楽の再生品質については全く分かりませんが、 音源がなっていることは確認できました。 どういった状況でどんな弊害が発生するかはまだ分かりませんが、 特に問題がないようでしたら、ＮＴでの音源再生に威力を発揮するものと 思います。
ジオグラフシール、かなり不安定ですが動きました。 SYSTEM DISK から PCMDRV.X を削除（笑）して、オープニングとミッション 説明を ESC でスキップすれば、一応ゲームがスタートします。 でも、すぐバスエラーで止まってしまいます。運良く進んでも、1面のボスまで でした。 あまり役に立たない動作報告ですみません。
X68Kソフトが復活する。夢のようなソフトの登場がうれしいです。 悪魔城ドラキュラでＭＩＤＩの設定後に絵が表示されないこと以外は(汗) というわけでこれからもがんばってください。メール下されば差し入れします(笑) ｐｓ・・・昨日の｢ウルトラマンダイナ」で使われているアナログスティックは・・・あふたばな２の頃発売になった。あれですよえ。http://home.intercity.or.jp/users/aupon001
サラマンダのステージ３はプロミネンスが派手で当時(アーケード版)は 評価が高かったゲームですね。 あのプロミネンス(上下の炎も含む)は、低クロック６８ｋで遊ぶと分かりますが ほぼ全ての炎を毎回書き換えているので、遅くなるのだと思います。 もともと６８でのステージ３もかなり遅くて炎を書き換えてるのがわかる位 だったし･･･。 ＥＸ６８のグラフィック書き換えはまだまだ遅い方だと思いますので。。。
初めて書き込ませていただきます。 ＥＸ６８大変有意義に使わせて頂いています。 日ごろWindowsでプログラムできないのでヒマな時にはEX68でアセンブラ などできるので大変便利です。 いろいろ動くということなのでお気に入りのAFTERBURNER2なんか 起動してみました。 うちのマシンはP6-166なのでちょっとぎこちないですが、 ほぼ完璧に動きました。 「ほぼ」というのは、ご存知の通り、ＡＢ２はマウス動作のゲームです。 派手に遊んでてＥＸ６８画面からカーソルが飛び出るとコントロールが 効きません(笑)。 非常に難易度が高いゲームに化けたので、皆さんも一度お試しあれ(笑)。 （ただし、画面拡大なしですること(^^;)）
初めての書き込みです。 ＥＸ６８楽しく使わせてもらっています。 このＢＢＳのもっと前の方に書いてあったら申し訳ないのですが、 テキスト表示が１０２４＊７６８とかにＣＲＴＣをいじって変えているときに どうも画面ドット数がおかしくなります。 横は対応させようとしているようなのですが、ｗｉｎｄｏｗだけ大きくなって クライアント領域が大きくなっていないとか。 インターレースの１０２４ｘ７６８ですが、こういうのは今まだ対応していない のでしょうか？
> # ってことは、キーボードだけでは連射出来そうにないんですね? いえ、そういう事を言ったつもりではないのですが・・・ キーリピートのエミュレーション部分をキーカーソル＋ＺＸに搭載すれば実現できそうな気もしますし。 （素人考えですが。） > それから、OverTakeのオープニングは、プロテクト掛かってなかった > と思うんですけど、私の思い違いでしょうか?(^^;。実機でコピーを そう言われると、昔のことですのでちょっと自信ないです。 私自身、まだEX68でオーバーテイクの動作確認をしていないので、今度自宅に戻ったときに調べてみます。
のにーさんの書き込みの前に書いた文章です。 Win95で86ボードのジョイスティックで以前いろいろ情報を調べてみましたが、 標準では対象外になっているようです。でも、安藤信明さんが制作されている ファミコンエミュレーター”パソファミ”ではtxtから抜粋させていただくと、 ＞ ９８シリーズにサウンドボード（８６ボード）を増設している場合は ＞ 汎用ジョイスティック端子がありますが、ここに市販されているＭＳＸ仕様 ＞ のジョイスティックまたはジョイパッドが接続できます。 現在のＵＲＬ http://www.vector.co.jp/authors/VA005758/ と、あります。実際にパソファミ/Direct-X Ver2.3faで付属しているデモを 実行したところ認識してくれてます。ので、プログラムの方で対応しているのだと 思います（たぶん、自信なし）。ので、yamamaさん、いつか対応をお願いします。 要望ばかり（しかも長文）ですみません（汗）。
８６ボードに使えるジョイスティックは９８とかMSX用のになりますよね、確か＜ATARI仕様D-SUB９ピンのやつでしょ？ だからWindowsでは使えないと思われます（DOS窓では使えるかも←EX68では意味無いけど） ↑間違ってるかも（＾＾；
はまさん、どうもありがとうございました。 JOYKEY6を導入してみたところ、ちゃんと操作できるように なりました。感謝m(__)m ところで、86ボードってジョイスティック用のドライバが付属 しているのでしょうか？それとも、Win95に標準でドライバが 付属しているんですか？WaveMasterには、それらしいもの が付属していなかったんですが・・・
動いたし、ＭＩＤＩもテンポはおかしいながらも鳴ってくれてる。 でもなんかボスキャラがバグる。これってうちのが遅すぎるから でしょうか？
初めての投稿です。一つ教えてください。 サラマンダを動作中、どうしても３面でものすごく重くなります。 （ほぼ停止状態・・・・・）
山田浩司さんへ、”ファイルを開く”のウィンドウの一番下に”読み取り専用 ファイルとして開く”というのがあるのでもしかしたら見過ごしていませんか？ チェックしていたらすみません。 これでディスクイメージにライトプロテクトがかかるようになったと思いますが？
うちの６８にはハードディスクがないのでＰＣ−９８＋８６ボードで ＥＸ６８でＳＦＸＶＩやってますが、やはりジョイスティックが使えないので 現在ベクターさんに登録されている"JOYKEY6"というのを使わせてもらってます。 http://www.vector.co.jp/vpack/browse/software/x68/game/sn022064.html これを"SFXVI6BI"の代わりに組み込めばテンキーとＺＸで操作できると思います。 ６ボタンでは操作できないみたいですが（たぶん）。これを使えば"AT2X.KEY"を 書き換えないでキーボードで操作できます。 でもＥＸ６８で、８６ボードのジョイスティックには対応できないしょうか？ パソファミでは対応しているようなのでＷｉｎ９５でもたぶん使えると思います。 できたら対応をお願いします。開発がんばってください。
初めて投稿します 現在かなり使わせていただいていますが 一つ困ったことがあります やはりプロテクトのかかったソフトはうまくディスクイメ−ジが作れません そこでバックアップツ−ルのディスクイメ−ジをとってみたのですが 「ライトプロテクトをかけてください」のメッセ−ジが ディスクイメ−ジの為どうしてもライトプロテクトはかけられません そこでex68k本体にライトプロテクトをかけるスイッチを つけることはできないでしょうか？ どうかお願いします
今、SFXVIにはまってるんですけど、ジョイスティックを キーボードでエミュレーションすると、上、右、下の方向 を選択したときにポーズがかかってしまいます。 ジョイスティックを使えばいいんでしょうけど、私の持っている サウンドカード（WaveMaster）は、Win上でジョイスティックが 使用できないみたいなんです。というか、使用方法が分かり ません。８６互換のポートをもっているみたいですが、DOS上 で使えても、Win上では認識してくれないんです。 なんか、ドライバがいるのかな？ ちなみに、使用機種は 98です。
こんにちは。 ジョイスティックをつなぐカードですが、 Ｉ・Ｏデータから、Joyカードとかいうのが、5000円くらいで出ています。 私も使ってますが、問題なく使用できます。これでカードスロットを一個 つぶしてしまうのがちょっと困ることもあるのですけれど。私は大阪に住 んでますので、日本橋にあるのは確認しました。
くばたさん、レスありがとうございました。 ジョイスティック繋げるPCMCIAカードがあることは知りませんでした。 探してみます。 # ってことは、キーボードだけでは連射出来そうにないんですね? それから、OverTakeのオープニングは、プロテクト掛かってなかった と思うんですけど、私の思い違いでしょうか?(^^;。実機でコピーを 取った記憶がありますので...。 # ロットでも違うのかな?私の買ったのは発売日だったはずなので、 # 初期ロットに当たりますけど...。
CRTC設定資料 written by Seafy from ftz-nethttp://park.org/Japan/128KTTH/ngy012/arc/comp/monitor/crtc/0d/crtc.dta
ノートパソコンにゲームポートを増設するためのPCMCIAカードが市販されているので、 これとAT用ジョイスティック（連射付き）を購入すれば大丈夫だと思いますが… オーバーテイクのオープニングにはプロテクトが掛かっていたと思うのですが、 チェッカは潰してあるんですよね？
リブルラブルの「バシシで固まる」事象について調べたところ、以下のコードでループしている様です。 move.b #$70,$e8801d ; タイマD停止 move.b #$9c,$e88025 ; タイマDデータ書込み move.b #$72,$e8801d ; タイマD始動 L1: cmpi.b #$80,$e88025 ; $80未満なら次の処理へ bcc.s L1 MFPのタイマDデータポートに設定した値がカウントダウンされていないため、無限ループになってしまいます。 また、v026bでB_DRVCHKの修正にについて確認してみたのですが、悪魔城ドラキュラの該当コードでは v025とおなじく $86 が返されているようです。
>Ｘ68ｋ上でIBMフォーマットなんだったか？のコマンドでフォーマットしたはずなんですが・・・・ >誰か方法を教えて下さい! >パソ通のBBSのPass等のデータがあるんです! ここには初めて書き込みます。体裁がわるかったらゴメンナサイ。 私も以前同じような症状で悩みましたが、WinNTなら読み込めたと思います。 方法としては、WinNTでIBMフォーマットしたダミーのMOを用意して、 ディスクアドミニストレータを起動します。ここで、１度ダミーのMOを認識させて MOドライブのウィンドウを開きます。 その後に、NT側でイジェクトせずに、ドライブのイジェクトボタンなどでMOを吐き出し、 68でIBMフォーマットしたMOを挿入するとNTが勘違いして読み込んだと思います。 この方法でも出来なかった場合は・・・方法が思い付きません。 なお、記憶が定かでないのですが、WindowsはNeXTなどでIBMフォーマットしたMOも 読めなかった気がします。
動いたのは確認しています>V-Ball。ちゃんと12MB分認識してますし...。 質問したかったのは、「ジョイスティックエミュレーション」でのキー ボード使用時に連射が可能かどうかを知りたかったんで...(^^;。 これって不可能なのでしょうか?>キーボード上で連射エミューレート
>おはよ さんへ およよ さんの間違いでした。 すいません。
>0.26bを試してみたらV-ballが動きました。 >あとはOvertakeのオープニングが動けば思い残すことはありませんが... >(^^;。 おはよ さんへ 私のPCでは、ちゃんと動いていますよ！！ 多分、RAMの設定が２Mになっていないんだと思います。 やってみてください。
0.26bを試してみたらV-ballが動きました。 あとはOvertakeのオープニングが動けば思い残すことはありませんが... (^^;。 # MIDIチェックまでは行くんですけど、そのあと黙ってしまい、Zoom # ネコが出てきてくれません。 ゲームをしていて思ったのは、どなたもキーボードでJoystickエミュレー ションなさっている方がいないのかな?と思いました。自分は68では連射 スティックを使っていたんですが、EX68上ではせっかく動いても、AT用の ジョイスティックが使えない(ノートパソコンですから...)私は殆ど遊べ ません。皆さん、目を吊り上げてキーボードを叩いていらっしゃるんでし ょうか? 何か対応策があればご教授頂けると幸いです。 これからも開発、頑張って下さい。
> さっそく試してみましたが、アーカイブの中にそれっぽい説明が無かった >（分からなかった）ので、うまくいきませんでした。 > ドライバの組み込み方はご存じでしょうか？ 添付のドキュメントによるとDDKに付属のコマンドで登録するようですが私は そんなの持ってなかったのでレジストリに手動でドライバのエントリを作成 して動かしました。 以下のURLに作成したエントリをレジストリエディタで保存したものを置い ておきますのでダウンロードして使ってみてください。ファイルをダブルク リックすればレジストリにエントリが追加されると思います。 追加後にTotalIOっていうデバイスが増えているのでコントロールパネルの デバイスで起動してやってください。（その前にたぶん再起動が必要だと 思いますけど。）http://skc.joho-kyoto.or.jp/~doi/totalio.reg
＞私の日本語 Windows95 環境では両方とも多くのソフトで正常に動作 ＞していますが、NTは使っていないのでわかりません。 ９５での動作を確認できました。たしかに正常に動作しているようです。 もしかすると、ＮＴではＭＩＤＩは認識できても、ＦＭ音源のエミュレー ションの関係でデバイスにアクセスできなくなったのかもしれませんね。 ＞ＮＴ環境でFM音源を鳴らす手段として禁断のドライバを使用するという ＞手もあります。 さっそく試してみましたが、アーカイブの中にそれっぽい説明が無かった （分からなかった）ので、うまくいきませんでした。 ドライバの組み込み方はご存じでしょうか？
＞私の日本語 Windows95 環境では両方とも多くのソフトで正常に動作 ＞していますが、NTは使っていないのでわかりません。 ９５での動作を確認できました。たしかに正常に動作しているようです。 もしかすると、ＮＴではＭＩＤＩは認識できても、ＦＭ音源のエミュレー ションの関係でデバイスにアクセスできなくなったのかもしれませんね。 ＞ＮＴ環境でFM音源を鳴らす手段として禁断のドライバを使用するという ＞手もあります。 さっそく試してみましたが、アーカイブの中にそれっぽい説明が無かった （分からなかった）ので、うまくいきませんでした。 ドライバの組み込み方はご存じでしょうか？
こんにちは。yamamaさん、ＥＸ６８いつもお世話になってます。 >使ってみて気になったのですが、スピード設定の幅がもっと >あった方がいいと思いました。 >個人的には１と２の中間あたりがあると丁度いいです。 １と２の中間ですか、いいですねー。私の場合、４では遅く、８では速いと いうくらいなのかな。やっはりＸ６８の画面まわりはエミュレートには酷、 なのでしょうね。ですので、その間があればとてもうれしいです。もし可能で あれば、１から１５くらいの間を１ずつ調整できればと思いますが、どんなも んでしょうか。
＞ＯＳ標準のＯＰＭドライバですが、私の環境では、OPMDRV.X Ver1.01、 ＞Ver1.02共に動作していません。Ｘ−ＢＡＳＩＣ上でＭＭＬコマンドで ＞音を出してもみましたが無音でした。 やはりそうですか。何が原因なんでしょうね。あいにく、僕は音源周りは 全く分からないので、全然予想すらできないのですが。 ＞よく見たら、Z-MUSIC のホームページや Z-MUSIC 推進委員会のページに、 ＞実行形式やライブラリのアーカイブと一緒に Ver 2.0x や Ver 3.0x 用の外部 ＞関数ファイルが含められていました。 情報ありがとうございます。これでＺＭＵＳＩＣに完全移行できるわけですね。 さっそくためしてみることにします。 ＞個人でNTを使用していて普段32bitアプリしか動作させないような環境 ＞であればほかのプロセスは一切IO操作は行わないはずなので、体制に ＞影響はないようです。 残念ながら、ここは会社の中で、しかもいくつかの業務サーバも肩代わり していますので、ちょっと危険な感じがします。ただ、面白そうなドライバ だとは思いますので、実験してみたいと思います。
EX68使わせてもらいました。 あのX68000がWin95上で動くなんて信じられない気分です。 使ってみて気になったのですが、スピード設定の幅がもっと あった方がいいと思いました。 個人的には１と２の中間あたりがあると丁度いいです。
>ＭＯへ移動した分はあるんですが、何故かＤＯＳ/Ｖ機では読込めないんですよ!なんじゃコリャの状態っす。 >Ｘ68ｋ上でIBMフォーマットなんだったか？のコマンドでフォーマットしたはずなんですが・・・・ >誰か方法を教えて下さい! >パソ通のBBSのPass等のデータがあるんです! それならDOSまたは、DOSモードを使ってＤＯＳ用SCSIドライバで、アクセスしてみたらどうでしょう お使いのSCSIボードにSCSI ASPIドライバが付属していたらそれとDOS用MOデバイスドライバ を使用すれば読めるかもしれません フリーのＭＯドライバ持ってますのでメールください。
> ＮＴ環境ではＦＭ音源を再生できないので、ＭＩＤＩモードで再生してゲームを>遊んでみたりするわけですが、以前はテンポズレで再生されていた >のに、今は無音になってます。 ＮＴ環境でFM音源を鳴らす手段として禁断のドライバを使用するという 手もあります。以下のURLの中にあるtotalio.sysをNTで動作させると すべてのプロセス上でIO操作ができるようになります。一見非常に デンジャラスなのですが個人でNTを使用していて普段32bitアプリしか 動作させないような環境であればほかのプロセスは一切IO操作は行わ ないはずなので、体制に影響はないようです。 ＃ただし、当然の事ながらこのドライバでなんらかの被害を被ったと ＃しても当方では何の責任も負えませんのであしからず。ftp://ftp.leo.org/pub/comp/doc/magazine/dr_dobbs/1996/1996.05/directio.zip
ＯＳ標準のＯＰＭドライバですが、私の環境では、OPMDRV.X Ver1.01、Ver1.02共に動作して いません。Ｘ−ＢＡＳＩＣ上でＭＭＬコマンドで音を出してもみましたが無音でした。 他のドライバやゲームなどでは、ちゃんとＦＭ音源の出力があるので不思議です。 かなりハードに依存した組み方してるのかな・・・。
>大量のファイルをMOVEなどのファイル移動コマンドでファイルを移動した 場合ファイルの復活は、難しいのでは？ サブディレクトリの内容は、諦めたほうがいいかも(^^; なんとかＭＯへ移動したファイルをもう一度Ｘ６８のＨＤＤへ戻せません？ まーくんさんへ ＭＯへ移動した分はあるんですが、何故かＤＯＳ/Ｖ機では読込めないんですよ!なんじゃコリャの状態っす。 Ｘ68ｋ上でIBMフォーマットなんだったか？のコマンドでフォーマットしたはずなんですが・・・・ 誰か方法を教えて下さい! パソ通のBBSのPass等のデータがあるんです!
＞Oh! X Books から出ている「Z-MUSIC システム ver.2.0」の綴じ込み付 ＞録に X-BASIC 用外部関数ライブラリ "MUSICZ.FNC" が付属しています。 よく見たら、Z-MUSIC のホームページや Z-MUSIC 推進委員会のページに、 実行形式やライブラリのアーカイブと一緒に Ver 2.0x や Ver 3.0x 用の 外部関数ファイルが含められていました。 Z-MUSIC Homepage：http://www.z-z-z.gr.jp/zmusic/ Z-MUSIC推進委員会：http://www.asahi-net.or.jp/~PT6N-MTO/
＞ＯＳ標準のＯＰＭドライバは動作するようになったのでしょうか？ OPMDRV.X Ver1.02 は動作するようですが、OPMDRV3.X Ver1.11 の OPM 部は動作しないようです。PCM 部は動作しますが、MIDI 部については未確 認です。(Windows95 & SB16PnP 環境) ＞Ｘ−ＢＡＳＩＣでもＺＭＵＳＩＣ等が使用できれば良いのですけど。 ＞外部関数作るしか無いんでしょうか。 Oh! X Books から出ている「Z-MUSIC システム ver.2.0」の綴じ込み付 録に X-BASIC 用外部関数ライブラリ "MUSICZ.FNC" が付属しています。 ＞ 話題はちょっと変わりますが、ＦＭ音源が再生できるようになってから ＞だと思いますが、ＭＩＤＩが鳴らなくなったように思います。 私の日本語 Windows95 環境では両方とも多くのソフトで正常に動作して いますが、NTは使っていないのでわかりません。
そういえば、音源のエミュレート機能が搭載されて、大抵のものは 再生されるようになったようですが、（ＮＴでは再生できないので 詳細はわかりませんけど）ＯＳ標準のＯＰＭドライバは動作するように なったのでしょうか？ Ｘ−ＢＡＳＩＣでもＺＭＵＳＩＣ等が使用 できれば良いのですけど。外部関数作るしか無いんでしょうか。 話題はちょっと変わりますが、ＦＭ音源が再生できるようになってから だと思いますが、ＭＩＤＩが鳴らなくなったように思います。 ＮＴ環境ではＦＭ音源を再生できないので、ＭＩＤＩモードで再生して ゲームを遊んでみたりするわけですが、以前はテンポズレで再生されていた のに、今は無音になってます。
>最初に９８上で動かしてみました。 >OPNのPANバッチリ直ってますね(^^ 動作確認ありがとうございます。 >聞いた話では、256色モードを基本にして > 32色4画面スクロール > 疑似色加算半透明 >といった事が実現されています（自分でも確認しました）。 うーん。これはまた。。。。 >X68000実機での動作をいろいろと調べてみた結果、実はかなり複雑な扱いになっているようです。 >詳しい透明色の扱いについては説明が長くなってしまうので、 >私のホームページに書いておきました(http://www.venus.dti.ne.jp/~mpuusan/X68toumei.htm)。 解析とレポートありがとうございます。 結構複雑になってますね。 >（EX68って、プライオリティの低い面から順に上書きして表示しているんですよね？） 1つのバッファに上書きしてるので、いまのままでは表示出来ないのがありますね。 InsideX68000に半透明のロジック図がありますが、 色$0000のプライオリティもここで選択されると思いますので、 パレットアドレス$0のプライオリティはそれ以前に選択されている必要がありそうです。 素直に組むとGraph,SpriteとTextでそれぞれバッファ上に作成して、最後に半透明合成かプライオリティによる選択を行って バッファを作成するというところでしょうか。結構重そうですね。
>以前、パレットの扱いについて報告したときは、標準の Sprite > Text > Graphic >という優先順位の場合の、Text と Graphic の部分しか調べていませんでした。 >中途半端なレポートで、申し訳ありません。ビデオコントローラのプライオリティ 制御機構ってこんなに複雑だったんですね。 私もパレットコード$0以外でも色コードが$0000なら透明色として扱われる場合があるとは、言われるまで全然知りませんでした。 で、よくよく調べてみたら、なんとまぁ複雑怪奇なこと。 >プライオリティの６通りの各組み合わせに、それぞれ専用の描画ルーチンを用意す >る事ぐらいしか思い付かないのですが、ビデオコントローラ内部ではなんらかのロ >ジックにしたがっているはずですよね。 6通りもルーチンを用意するのって、結構しんどい作業ですよね...。 あと、プライオリティ設定「Text>Sprite>Graph」の「Text色$0000」などは、 SpriteはGraphより必ず手前に表示されるはずなのに、なぜかSpriteを通り越してGraphだけが表示されるなど、 かなり特異な表示で、こういうのをエミュレートするとなると結構大変そうです。 （EX68って、プライオリティの低い面から順に上書きして表示しているんですよね？） >しかし、この優先順位機構の上にメモリモード≠色モード時の処理や半透明もエミュ >レートするとなると、とんでもなく重くなりそうですね。 あと、Graphic面の特殊プライオリティ機能なんていうのもありますし...。 >もっとも、常にエミュレートする必要は無いのですし、 >ユーザーがエミュレートレベルを選択できるようにもすれば、 >現在快適に動かせるソフトが重くなる事は無いと思います。 こうなってくれるといいですね。 ただ、完全にエミュレートするのはかなりしんどいと思うので、 とりあえず透明色の扱いは現状維持で、 うまく表示されないソフトは個別にパッチを当てた方が楽という気もします。
>X68kのHDDは既に全て移動してしまったので、もぬけのからになってしまったのです・・・ >フォーマットもかけていませんし、何らかの書き込みもやっていないので、ファイル復活のツールがあれば >助かるんです・・・ 大量のファイルをMOVEなどのファイル移動コマンドでファイルを移動した 場合ファイルの復活は、難しいのでは？ サブディレクトリの内容は、諦めたほうがいいかも(^^; なんとかＭＯへ移動したファイルをもう一度Ｘ６８のＨＤＤへ戻せません？
＞ v026では、以前ここで取り上げられた「テキストはパレットコードに関わらず ＞ 色コードが$0000である場合のみ透明になる」ということに ＞ 対応されたものだと思われますが、 ＞ X68000実機での動作をいろいろと調べてみた結果、実はかなり複雑な扱いになっているようです。 以前、パレットの扱いについて報告したときは、標準の Sprite > Text > Graphic という優先順位の場合の、Text と Graphic の部分しか調べていませんでした。 中途半端なレポートで、申し訳ありません。ビデオコントローラのプライオリティ 制御機構ってこんなに複雑だったんですね。 ＞ このような透明色の処理をEX68でまともにエミュレートしたら ＞ めちゃくちゃ速度が遅くなってしまいそうですよね。 ＞ なにかいい方法はないでしょうか。 プライオリティの６通りの各組み合わせに、それぞれ専用の描画ルーチンを用意す る事ぐらいしか思い付かないのですが、ビデオコントローラ内部ではなんらかのロ ジックにしたがっているはずですよね。 しかし、この優先順位機構の上にメモリモード≠色モード時の処理や半透明もエミュ レートするとなると、とんでもなく重くなりそうですね。もっとも、常にエミュレー トする必要は無いのですし、ユーザーがエミュレートレベルを選択できるようにも すれば、現在快適に動かせるソフトが重くなる事は無いと思います。 ＃MC68000 エミュレーション部分は、AMD K6/233MHz 程度でも REDZONE(24MHz) 並 ＃の速度が出るのですが、やはり X680x0 は各種専用カスタムチップが高性能の要 ＃だったんですねえ、と今ごろ実感しています。
『あにまーじゃんＶ３』ですが、v025cでは途中まで表示されていたスプライト&ＢＧ面が、 （途中でプライオリティ$E82500.bに$34を設定した時点で表示されなくなりますが） v026以降は最初から全く表示されなくなってしまいました。 というか、実際には表示されていますが、テキスト画面の透明色が透明になっていないため、 隠れて見えなくなっています。 v026では、以前ここで取り上げられた「テキストはパレットコードに関わらず 色コードが$0000である場合のみ透明になる」ということに 対応されたものだと思われますが、 X68000実機での動作をいろいろと調べてみた結果、実はかなり複雑な扱いになっているようです。 詳しい透明色の扱いについては説明が長くなってしまうので、 私のホームページに書いておきました(http://www.venus.dti.ne.jp/~mpuusan/X68toumei.htm)。 基本的に、テキストの色コード$0000はグラフィック面に対しては透明色として機能しますが、 スプライト面に対しては透明色として機能せず、 テキストのパレットコード$0がスプライト面に対して透明色として機能するようです。 また、プライオリティ設定によってはテキストのパレットコード$0(色コードが$0000以外でも) がグラフィック面に対しても透明色として機能する場合もあり、非常に複雑怪奇です。 このような透明色の処理をEX68でまともにエミュレートしたら めちゃくちゃ速度が遅くなってしまいそうですよね。 なにかいい方法はないでしょうか。http://www.venus.dti.ne.jp/~mpuusan/X68toumei.htm
それならDEDITっていうツールで復活できると思いますぅ。
あのーーーお願いがあるんです。 なに？かというとX68k上でのファイル復活ツールがありましたらメールで送って下さると有り難いんです。 なぜか？は・・・ 私は、今年に入ってWindowsマシンを購入したのですが、X68k上でHDDからMOにファイルをバックアップ しようと思ってX68k上でIBMフォーマット形式でフォーマットしたＭＯに移動コマンドで全て移動させたＭＯを Winマシン(DOS/V）で読込ませようとしたらパラメータエラーが出てしまい、読めないのでした。 X68kのHDDは既に全て移動してしまったので、もぬけのからになってしまったのです・・・ フォーマットもかけていませんし、何らかの書き込みもやっていないので、ファイル復活のツールがあれば 助かるんです・・・ 何らかの解決方法があれば、教えて下さい。
遅くなりましたが、お返事ありがとうございました。 >私は電脳倶楽部 Vol.76 までしか購入しなかった（しかも TAKERU 版）のです >が、この号の電脳画廊では上記の部分で VIDEOC の半透明処理を使っ >ています。（EX68 はまだ半透明処理を実装していないはずです） あの処理は、半透明を利用していたんですね。それなら、電脳倶楽部が 全然読めないわけではないので、実機とうまく使い分けて、しばらく がまんすることにします。
>これはちょっと実際に使われた事があるとは思えないのですが、特殊な画面モード>特集と言うことで、通常モードの変わった使い方です。 >65536 色モード時にグラフィックスクロールレジスタを操作することで、『４プ >レーン』を独立スクロールさせる事ができます（実機のみ） DIVE ON で使ってるそうです。 4面の巨大ボスと最終面で特殊な使い方をしています。 聞いた話では、256色モードを基本にして 32色4画面スクロール 疑似色加算半透明 といった事が実現されています（自分でも確認しました）。 EX68上ではまだ確認してませんが、再現は出来てないでしょう。 しょうがないですかね(^^;;;
>SFXVI を立ち上げようとしたところ Zmusic の常駐のの所で止まってしまいました 0.26bではまた動くようになりましたね 有り難うございます(^^;) >SFXVIのZmusicでの停止 投稿者：ぴぴぴ☆ 投稿日：02月27日(金)12時05分21秒 あ ぴぴぴ☆さんだ こんにちはー（ってここに書くなよ(^^;)）
>SFXVI を立ち上げようとしたところ Zmusic の常駐のの所で止まってしまいました Ver0.26bならだいじょぶです。http://www2.osk.3web.ne.jp/~pipipi/
最初に９８上で動かしてみました。 OPNのPANバッチリ直ってますね(^^ エミュレーション速度も速くなってるようですね あとADPCMのPANにも対応したらかなりうれしいかも（音に迫力でますし） 最近私のホームページを大幅更新しまだ貧弱ではありますがＥＸ６８ボードも 出来ました 以前ディレクトリに置いていたツール＋αで、ページからのダウンロードが 可能になってます。 これからいろいろ充実させていく予定ですので皆さんよろしくお願いしますm(__)m 以下のURLで行けます（トップページです(^^;）http://home.interlink.or.jp/~markun2/ma-net/index.htm
バグレポートありがとうございます。 とりあえずDMA転送終了時の割り込みバグに対処しました。 >また、今度 Cyrix 6x86L を使う機会ができそうなので、低速化現象が >再現できたら報告します。 あまりに遅いのでCPUよりマザーボードか、ISAのカードが悪いような気がします。 DMAを使うカードなのでキャッシュがクリアされるとか。単に負荷が大きいのか。 残像はメモリの書き換え検出がうまくない為に起きていると思います。 デバッグ版は http://www.kumagaya.or.jp/~yamama/emul/ex68d026b.lzh
＞ウチの環境(Windows95+PWR128P)でも残像(スクロール時に長い尾を引く)が残るようです。 単にビデオカードが遅い為なのかな？と思ってました(^^; 他にも同じ現象が出るものがあったのでわかって良かったです。
>ドラスピ、タイトルちゃんと表示されてます(T-T >ゲームもエンディングまで確認しました(ザウエル苦戦しました) >エンディングのスタッフロールで残像？が残る以外はおかしい所は見あたりませんでした。 ウチの環境(Windows95+PWR128P)でも残像(スクロール時に長い尾を引く)が残るようです。 v025cでも残像が残ります。 残像を再現するプログラムを作ってみました。 .include doscall.mac .include iocscall.mac BGCOL equ $00 clr.l -(sp) dos __SUPER addq.l #4,sp move.w #10,d1 * 256x256(256color) iocs __CRTMOD iocs __G_CLR_ON lea.l $C00000,a0 move.l #512*512,d0 clear: move.w #BGCOL,(a0)+ * 背景を指定の色で塗り潰す subq.l #1,d0 bne clear lea.l circle_arg(pc),a1 move.w #20,d7 * y lp1: move.w d7,2(a1) move.w #20,d6 * x lp2: move.w d6,(a1) iocs __CIRCLE * 円をいっぱい描く add.w #30,d6 cmp.w #256,d6 bcs lp2 add.w #60,d7 cmp.w #512,d7 bcs lp1 clr.w d7 scroll_loop: wait1: btst.b #4,$E88001 beq wait1 wait2: btst.b #4,$E88001 * V-DISP Wait bne wait2 move.w d7,$E8001A * Graphic Page0 Scroll move.w d7,$E8001E addq.w #1,d7 move.w #$00FF,-(sp) dos __INPOUT addq.l #2,sp tst.l d0 beq scroll_loop dos __EXIT circle_arg: dc.w 0,0,10,255,0,360,256 このプログラムを実行すると、ウチの環境では円の底の部分が尾を引きます(見ててカッコイイですが(^^;)。 また、背景のパレットコード(BGCOL)を $00 以外にすると、残像は残らないようです。
早速、v026頂きました。バージョンアップお疲れさまです。 v025cと比べるとずいぶん速くなっています(VTUNEの効果もあるのかな？)。 v025cでは描画更新速度を x2 にしないと遅くてゲームにならなかったゲームが、 v026では x1 で十分遊べるようになったものが結構ありました。 やっぱり x1 だと動きがなめらかで美しいです。 私が確認したところでは、『ドラゴンスピリット』は全く問題なく 画面が表示されるようになりました。 また、『サイバリオン』は問題なく起動できるようになりました。 『V'BALL』もv025cでは起動しませんでしたが、 v026では起動するようになりました。 >EX68の約3割のメインルーチンの改善で全体が５から１０％程度改善しましたが、>UVのペアよりもL1キャッシュのヒット率を上げることが一番効果があるようでした。 よく「RISCにして命令の同時発行数を増やしたところで、 L1キャッシュを効率的に利用できなければ性能は向上しない」と言われますが、 やはりそうなんでしょうね。
v026 で DMAC の IOCS ワークがクリアされない問題ですが、どうやら DMAC 転送終了時の割り込みがかかっていないことが原因のようです。 Human68k では MC68000 のユーザー用割り込みベクタの $68 番、つま りベクタテーブルアドレス $0001A0 を DMAC#2 の正常終了、ベクタ番 号 $69 ($0001A4) を異常終了の例外ベクタに割り当てています。 1987/05/07 版 Version 1.00 の ROM ではそれぞれ $FF0F74、$FF0F62 が設定され、ここで例の $000C34 ワークをクリアするようになってい ました（異常終了時は $000C35 にエラーステータス） EX68 で IOCS $8A 〜 $8C を呼び出すと、転送自体は正常に行われるの ですが、終了時に上記のベクタが呼び出されず、$000C34 に最後に実行 された DMAC#2 転送関係の IOCS コール番号が残ってしまうため、次に IOCS で DMA を操作するコードが実行されたときに IOCS 内で無限ルー プが発生してしまうのです。 とりあえず安易な解決法として DMAMOVE、DMAMOV_A、DMAMOV_L のワー クチェッカ部分を NOP で殺すパッチを当てた IOCS-ROM のイメージファ イルで EX68 を動かしているのですが、DMAMODE を使うプログラムなど には通用しないはずですし、転送が終了する前に次の転送を要求してし まう場合もあると思いますが、ZMUSIC は正常に動くようになります。
拡張ジョイスティックのボタン設定追加ありがとうございました。これ で SideWinder の START ボタンを START ボタンとして使うことができ るようになりました。動作確認の為にわざわざ各種ジョイスティックを 購入して下さったそうで、本当にありがとうございます。 テキストパレット０の修正もサンプルで確認いたしましたが、後述する ZMUSIC と DMAC ワークの不具合により、餓狼伝説 SPECIAL での誤描画 への効果はまだ確認できていません。 速度面では、EX68 内部で計測するタイプのベンチマークで 25% 程高速 になったという結果がでました。 AMD K6 Stepping 2 を使っています。 また、今度 Cyrix 6x86L を使う機会ができそうなので、低速化現象が 再現できたら報告します。 それから、今回から DMAC 関係の IOCS フックが解除されましたが、ど うも幾つかのプログラムへの影響がでているようです。 ZMUSIC V2.0x の常駐時に、例の $000C34 にある IOCS ワーク（DMAMODE の戻り値） が 0 になるのを待ち続けてしまうため、固まるようになってしまいまし た。 まだまだ見落としていてチェックしていない部分もあると思いますが、 とりあえずの報告です。
v026頂きました。 ドラスピ、タイトルちゃんと表示されてます(T-T ゲームもエンディングまで確認しました(ザウエル苦戦しました) エンディングのスタッフロールで残像？が残る以外はおかしい所は見あたりませんでした。 当時コレの為に６８購入したクチなので今更ながら非常にうれしいです。 yamamaさん、ありがとうございます。 あとイメージファイトも何故か音は出ませんが画面は表示されているようです。
SFXVI を立ち上げようとしたところ Zmusic の常駐のの所で止まってしまいましたhttp://www.sakuraweb.com/~la-vista/
動作レポート、テストプログラムありがとうございます。 レポートを頂いた中からとりあえずいくつかのバグに対処しました。 >ちょっと使ってみたくなりました。 >使ってみて効果の方はいかがなものでしょうか？ EX68の約3割のメインルーチンの改善で全体が５から１０％程度改善しましたが、 UVのペアよりもL1キャッシュのヒット率を上げることが一番効果があるようでした。 デバッグバージョンは以下に http://www.kumagaya.or.jp/~yamama/emul/ex68d026.lzh
テラクレスタには確か、海外モードと日本モードがあったと思うのですが、 その選択方法ってどうすればよいのでしょうか。知ってる方いますか?
マウスカーソルをテキストに表示しているソフトで、テキストスクロールレジ スタが使用されていて、なおかつ EX68 側で位置補正されているものは、スク ロールしている分 Windows 側のカーソルとの位置がずれてしまいます。 ９８からの移植ソフトなどでテキストのみを 640x400 モードを使っているも のは、画面をスクロールでずらせている場合が多いのですが、これらのソフト で不具合がでてしまいます。 ほとんどのソフトはテキストの空きプレーンをマウスカーソルの表示に使用し ていると思うので、マウスカーソル位置の補正にスクロールレジスタの値も係 数として加えていただけないでしょうか？ カーソルにテキスト以外を使用し ていて、なおかつテキストをずらしているソフトでは今度は逆に困ってしまう かもしれませんので、オプション指定でも良いのですが、どうでしょう？ libc 用サンプル：（マウスは SCC 割り込み） #include#include #include void main(){ int x,y,cur; _iocs_ms_curon; _iocs_scroll(8,64,48); while (!(_iocs_ms_getdt() & 0x0000ffff)) { cur = _iocs_ms_curgt(); x = cur >> 16; y = cur & 0x00ff; printf(" (%d,%d) \r",x,y); } _iocs_scroll(8,0,0); printf("\n"); }
これはちょっと実際に使われた事があるとは思えないのですが、特殊 な画面モード特集と言うことで、通常モードの変わった使い方です。 65536 色モード時にグラフィックスクロールレジスタを操作すること で、『４プレーン』を独立スクロールさせる事ができます（実機のみ） .include iocscall.mac .include doscall.mac start: movea.l #0,a1 IOCS __B_SUPER moveq.l #12,d1 * 512x512x64k IOCS __CRTMOD IOCS __G_CLR_ON lea.l $c20000,a2 * Graphic RAM move.l #511,d1 move.l #$ffffffff,d0 loop: move.l d0,(a2)+ dbf d1,loop move.w #16,$e8001a * Graphic Scroll Y0 move.w #32,$e8001e * Graphic Scroll Y1 move.w #48,$e80022 * Graphic Scroll Y2 move.w #64,$e80026 * Graphic Scroll Y3 IOCS __B_SUPER DOS __EXIT .end ＃こんな使い方をするソフトはまず無いと思うので、EX68 でのサポート ＃の必要は無いと思います。半透明並に重くなりそうですし....
特殊な画面モードと言えば、 Text＆Graphic面は512x512で表示して、Sprite&BG面は512x256で表示する （つまりSprite&BG面だけ縦方向に２倍に引き延ばして表示する）という 画面モードがあります。 これは実際にX68k版『サイバリオン』で使われている画面モードで、 やり方は、画面モードを512x512にして $EB0810.w に $0011 を書き込むだけです。 『サイバリオン』ではこの画面モードでBG面を縦方向にラスタスクロールさせたり しています。 EX68ではこの画面モードはサポートしていませんので、 Sprite&BG面が縦方向につぶれて表示されています （つぶれながらも、ちゃんとラスタスクロールは出来ているところは凄い！）。 『サイバリオン』は私の大好きなゲームの内の１つなので、 いずれはEX68でこの画面モードがサポートされるといいなぁと思います（でもエミュレートは難しそうですね）。 一応、この画面モードのサンプルプログラムです(もちろん実機用)。 何かゲームを起動して、スプライトが表示されたところで一度リセットして下さい。 そして、このプログラムを実行すると、 Textは512x512で表示されているのにスプライトは縦に引き延ばされて表示されるのが分かると思います。 .include doscall.mac .include iocscall.mac clr.l -(sp) dos __SUPER addq.l #4,sp move.w #12,d1 * 512x512x6万色 iocs __CRTMOD iocs __SP_ON * スプライト表示 move.w #$0011,$EB0810 * Sprite&BG面を512x256で表示 dos __EXIT
OPMの動作としては、タイマーを回し始めてからタイマー時間が過ぎるまでは オーバーフローは降りたままで、時間経過後は上がりっぱなしになるはずです。 またタイマーが動作しているときに再度開始しても、その開始指示は無視され るということが知られています。ですから飛翔鮫のルーチンもこう書けます。 move.b $e90003,d0 ; OPMステータス参照 move.w d0,-(sp) btst.l #0,d0 beq @f bsr timer_a @@: move.w (sp)+,d0 btst.l #1,d0 beq @f bsr timer_b @@: move.b #$14,d1 ; OPMレジスタ=Timer制御 move,b #$3f,d2 ; A・Bリセット、A・B共に割込み許可、動作開始 bsr.w L4 ; OPMアクセスルーチン .....
実際には、ラスタ開始から画面中央に走査線がきたころをみはからって、 タイマ割り込みをかけて、表示プレーンを切り替えることによって 実現してますよね。 エミュレートされているプログラムから見れば、走査線が左から画面中央まで 移動する時間は０ですから、現状だとどうやっても無理じゃないですかね。 ラスタ毎に、画面左から２／３あたりまで表示して、一旦割り込みの チェックとかかければ、実現可能かもしれませんね。 それか、いっそのこと、EX68側で、Forceモードのオプションをつけてもらうとか。
＞HANIM.X がこの画面モードにするメリットを考えてみたのですが、 ＞よくよく考えてみたら、これってまさに絶好の画面モードですね。 なるほど、高速書き換えを必要とする場面ではうってつけの画面モード だったわけですね。 とりあえず v025c でも HANIM.X に /m2 オプショ ンを与えて 65536 色モードにすれば正常に再生されるのですが、どうい うわけか一度でも HANIM.X を実行すると、次にリセットするまで EX68 の I/O 関係のアクセス速度が低下してしまう現象が発生しています。 ところで特殊な画面モードといえば、GORRY 氏作 APICG.r や H.ATA 氏 作 MAGH.X などで採用されている 768x512 モードでの 256色表示、いわ ゆる Force モード(*)もありますね。 Force モードはタイミングが結構シビアなようで、実機でも私の ACE-HD では画面中央の切り替えを行っているあたりにわずかなノイズが乗って しまいますが、これも EX68 ではうまく表示されません。 (*)ご存知ない方もいるかもしれないので APICGLIB.DOC から要約です： Force モードは 768x512x8bit の画像を横 256 ドットずつに分割して、 ページ０に左側と中央の部分画像を、ページ１に右側と中央の部分を配 置し、ラスター割り込みによって走査線が左側にあるときはページ０を 表示し、走査線が右側にあるときはページ１を表示させる事によって、 擬似的に 768x512 モードで 256 色表示を実現させる手法です。 （ページ切り替えを行わないと[左][中][左]という 768x512 表示になる）
はじめまして。小林と申します。 ＥＸ６８．凄いですね。Ｗｉｎマシン上でHumanが動くなんて。 私の環境（Pentium120+32MB)では動作が重いものの、 正常に動いています。 今度、ソフト関係の動作報告でもします、