MSX3 Part9
※スレ立ての際、>>1の本文1行目に
!extend:checked:vvvvv:1000:512
を入れてください
西和彦のサイト
http://nishi.org/
前スレ
MSX3 Part8
https://kizuna.5ch.net/test/read.cgi/i4004/1699974182/l50
VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured >MSX2ならライン引くのはVDPコマンド一発でいけるから、
遅いんじゃなかったっけ？ >>2
CPUに描かせるのと大差ないにせよ、CPUとは並行して処理できるが
VDPの描画が終わるまでボケッと待っているだけのクソコードしか掛けない奴にはわからんかこの領域（レベル）の話は ターボRならVDPが描くより速く描けるだろうけど
CPU側で描いたビットマップをVDPの細くて遅いI/Oでえっちらおっちら転送してたらどうだろうな
ビットマップに描いてI/Oする分のCPU時間の方が多分勿体無い >>6
並行して処理できるメリットを最大限に活用してスターウォーズみたいなゲーム作れそうだな やっぱ丸なんかワープロソフトやグラフィックツールみたいプログラムでしか使わないよね
線だったらテグザーくらいしか思いつかないｗ
まぁ普通使わんやろ 知らんけどturboRにSylpheedのOPを勝手移植したやつはVDPでラインなんか引いてないだろ WebMSXでpmext使ってHITECH-Cを解凍中
めちゃめちゃ展開が遅くてノスタルジーに浸れる >MSX2みたいな低解像度の環境なら、円なんて32角や64角の頂点間を直線補間、つまりライン引いときゃ充分じゃねえの？
そこそこ細かくしてくと、たくさんのラインよりちゃんと計算して該当バイトに書き込む方が速くなるかもね。
あとペイントとの絡みもある。１ドット外すと塗りつぶせない、なんてことがおきる。 サークルにだってブレゼンハムのアルゴリズムはあるよ
整数の足し算シフト条件分岐だけで綺麗なサークルが描ける MSX的には移動ルーチンだろう
任意の座標に任意の半径で円を描きたいような場面はないよ 敵をゆっくり滑らかに円(楕円)状に動かす時は必要になると思うよ
荒く動かすならサインテーブルを用意して、角度から位置を計算すればいいだろうね 円状に動かすには計算はするだろうけど、描く必要はないのでは？ 円や線をCPUで描いたりするならArduinoのLCD用のライブラリを参考にしてもいいね
Arduinoで使われてるLCDは点や矩形を描画する機能しかないのがほとんどなので
ライブラリ側で円や線を描いてるからね
ライブラリ全体を移植するのではなくて、円や線を描いてるところだけを参考にできる >>0012
Z80 の x8 とか、R800の x2 を試すと面白いかも。
MSXPLAYer の ∞ のほうが早いかもだけど。
>>6
CIRCLE の件だけど、MSX-View の動画を見る限り、楕円を4分割して書いてるっぽいね。1/4だけ書いて反転コピーとかかな。
https://www.youtube.com/watch?v=gMQYP4RxReE
VDP コマンド的には、どのへんの組み合わせが良いかな。塗りつぶしは、LMMV など？全部 LINE で円描くより高速化するテクニック希望。
http://ngs.no.coocan.jp/doc/wiki.cgi/TechHan?page=6%BE%CF+VDP%A5%B3%A5%DE%A5%F3%A5%C9%A4%CE%BB%C8%CD%D1%CB%A1 CPU側にバッファ持って、必要な部分だけデータ転送するのが一番速いのでは。
塗りつぶしたいのなら、内接する四角の塗りつぶしがコマンド使えそうだけど。 こういうのって自分で試行錯誤中して高速化するのが楽しいんじゃないの？
実装する気も無いのに技術だけ聞こうとする奴って何なのだろう。。。
描画する円のサイズや近似の角数によって変わってくるだろうけど
連続でLINE命令発行して待ち続けるのって遅くないかね？
その間CPUで大したこと出来るわけでもなさそうだし
CPUでRAM上に描画して一気にVRAM転送した方が速いとか普通にありそう >>0024
CIRCLE もいいのですが、実装としては、スプライトも PCG も使わない方針での VDP 高速描画テクニックに興味があります。
MSX2 の YS3 の多重スクロールみたいな実装の議論がここでできるといいかな。タイル的にメインRAMから変更点のみVRAM側に VDP で転送という方針になるでしょうけど、YS3 は、場所によってはかなり高速だったり、ものすごく背景処理が重いところもあり驚きます。
MSX3 世代なら V9990 使えば、そういうテクニックも不要な程度に高速なのかもですが。 自分で試行錯誤するのもいいし既にあるアルゴリズムを利用するのもいい
どっちも正しいしどっちかが間違っているわけでもない >>24
＞CPUでRAM上に描画して一気にVRAM転送した方が速いとか普通にありそう
16bitパソコンでもそれはきつそうだけどね
Raspberry Pi PicoやESP32とかの
32bitのArduino互換機とかで320x240のLCD相手なら簡単にできるけど
昔のパソコンにはきついね
Raspberry Pi PicoだってPentium90MHzくらいの性能ありそうだし 9821で低解像度グラフィック（320x240x256 や、288x224x256）を描画するときはRAM上の仮想VRAMに描いてフリップの時に実ＶＲＡＭへ拡大転送してたよ
（拡大処理が最終転送時のみになるので速い）
とはいえ、9821だとDOSの16ビットコードでも32ビット分類になっちゃう？ 16bitコードだからといって486はキャッシュも積んでるし
普通に32bitのバースト転送でメモリアクセスしてそうだけどね Dhrystoneだけで比較するのはよくないけど
以前、Raspberry Pi Picoで計測したらDhrystone 2.1で111DMIPSあったわ
ここのサイトのDMIPS値みるとRaspberry Pi Picoってかなり優秀なんだな
https://netlib.org/performance/html/dhrystone.data.col1.html まあ、今のARMのGCCは性能いいから単純に比較はできないけどね Dhrystone 2.1でMSXは0.25DMIPSくらいだかな
turboRでさえ0.85DMIPSくらい
性能では486との差がものすごいよね
RISC CPU登場後と登場前でCPUの性能が全然違うね turboRの結果は乗算命令使わない場合だからturboRの乗算命令使えば
turboRはもうちょっと速くなるかも >MSXは0.25DMIPSくらいだかな
>turboRでさえ0.85DMIPSくらい
それしか差がないのか!？
>turboRでさえ0.85DMIPSくらい
>MC68000でも1DMIPS行けばいい方だしな
それしか(以下同文 Dhrystone 2.1(sdcc 4.2.0) int型16bitの時
MSX2+で0.13DMIPSくらい
turboRで0.83DMIPSくらいだった
Dhrystone2.1(sdcc 4.2.0)のintをlong型の32bitに修正したバージョンは
MSX2+で0.037DMIPSくらい
turboRで0.25DMIPSくらいだった
int(16bit)をlong(32bit)にすると3.5倍くらい遅くなるね
そして、Dhrystone 2.1だとMSX2+比でturboRは6倍くらい速いね
MC68000の1DMIPSというのは intが32bitの時の値だと思うので32bit演算は68000が速いね
参考までに
エミュレータXM6typeG 311L15でクロック10MHzでのDhrystone 2.1は
XC v2.11だと0.47DMIPS
GCCだと0.84DMIPSでした
XC v2.11遅い MSXの結果は完全保存版3のMSX Playerな まあ、エミュの結果とはいえ、
486とは比較にならないほど遅いわけ tR出たとき、286に勝ったり負けたり、だったはず。 tRではVDPアクセスに8μsのウェイトがかかったはずだから、連続メクラ転送でも１バイトに8μs以上かかる。
とすると、たとえば1/60割り込みで送るとして、2KBしか送れない。SCREEN8だと４ライン。 EMMYのエロい画像がちゃんと表示されなくなるぞw
実際SCREEN8だったのか分かってないけど ビジュアルシーンだけとかじゃなくてSCREEN8の綺麗なゲームもあったような？ ＞ いやあ、僕はそもそもゲームが好きじゃありません。なぜなら楽しくないから。 ネオジオにそっくりだ
なぜこの形でここに印刷したのか？？
こういうこと>>45書いてるヤツらには絶対にわからんのだろ？
どうでもいいことよりこっちの方が大事だ
カセットの背面に印刷するパターンは少ない 背面タイトルの印刷なし
コピペや思いつきのデタラメのクソ情報はいらんぞ
最近レトロゲーム界隈で暴れてる基地外だからさわらん方がいい ＞ いやあ、僕はそもそもゲームが好きじゃありません。
> なぜなら楽しくないから。 探偵が殺人犯に代わって動機をしゃべっているようなものだ
おまえらのニワカ知識 「MSXでわざわざゲームやってるっていう人はね、」 ハッピーセットのおもちゃで遊んでろ そのレベルのはずだ >>48
Screen8のコプロ機能をV9958で標準搭載すべきだった >>74
ふーん、パレットを拡張できるのか。
他に何ができるのかワカランけど、サンプル出荷で１万円じゃMSXには使えんね。
9958の自然画なんかは、このパレット拡張が付く部分にYJK回路を付加したんだろうね。
たしかSC8-SC12を切り替えると４ドットぐらいズレたはず。SC8の出力をコンバートして映像出力にしてるんだろう、と想像した記憶。
MSX1に外付けパレットもつけれるんじゃね、なんて妄想したこともある。全機種RGB出力があれば、挑戦したかもしれない。 >>75
なんで使えないって決めつけるんだか
それ言ったらV9938も使えないけど現実にはMSX2用に採用されたでしょ
本来V9978に組み込もうとしたけど新規開発とん挫したからV9958でお茶濁したんだし
結局金がなくて新規開発が無理でしたって話でしょ >>76
9938はMSX用に開発した9918上位互換VDPだから、たとえ多少高くても使う。
コプロ付9938が9978ではありえない。
大丈夫か？ 金が無くて開発出来なかったってことにしたいだけの奴なんだろ
製造販売した場合の価格競争力とかすっぽり抜けてるとか大丈夫？としか >>74
キャプテンシステムと自動車オークション用か Z80が強要されてたパチンコ業界に食い込めれば、未来はいくらか変わっていたかも パチンコ業界にMSXそのまま食い込むのは無理
ROMもRAMも容量制限されてるしプログラムそのものも審査対象なので素人の審査官が理解できるようにプログラム書かなくちゃ弾かれる パチンコ全くやらないけど、
埋め込みの小型ブラウン管が使われ始めた頃に、これ表示にV9958使ってんだろうなってやつを見かけた記憶はあるな。
「演出制御基板」の方のプログラムをしていたらしい人が講演に使ったパワポがなかなか興味深い。
ttps://swest.toppers.jp/SWEST24/program/pdfs/s1b_public.pdf MSX3に話を戻すと、V9990 の予習をしたいね。
MSXgl や、Fusion-C など、V9990 をサポートする
ライブラリもあるが、それ以外で参考になるソースや
資料などあれば教えて下さい ↑世界にウソは不要
昨日紹介されてたラリーXも中央固定だぞ
F-1スピリットも、位置はちょっと下の方だけど固定なんだな >>0092
ありがとう。
Video9000 Manual: ここの BASIC 例いいね。 http://map.grauw.nl/resources/video/v9manual.pdf
ところで、15.7KHz の出力はどのような接続で確認しているの？
HDMI 変換で切替器とか？15.7KHz だと今どきのものでは入らないよね？ >MSX-Cのマニュアルで、一例としてline()が挙げてあって、その実はMAIN-ROMの非公開のルーチンを呼び出してた、と記憶。
>>https://kizuna.5ch.net/test/read.cgi/i4004/1699974182/989
>BASIC内部ルーチンってダイレクトに呼び出して大丈夫なもんなのかね?
奇特な方がファイル名を教えてくれたので確認できたよ。
奇特な方：https://kizuna.5ch.net/test/read.cgi/i4004/1704863708/773
line.c：https://imgur.com/eViSKJe.jpg
BIOSにcalbasってエントリがあるくらいだから、一般には非公開のエントリがいっぱいあるんだろうね。
大枚はたいてdatapack買ったのに・・・金返せ！ Datapack買ったのパソ通も十分でなかった当時じゃなくって今？
もう完全に解析されてオープンなのに情弱すぎへんか 買ったのは当時だよ。
>もう完全に解析されてオープンなのに情弱すぎへんか
何がオープンなのかはよくワカランのだけど。
解析したところで、公式のエントリなのかどうかはワカランしね。 メーカー公開レベルなのかねぇ?
だったらdatapackで公開しても良さそうなもんだけども MSXgl も良いと思うけど、MSX-C ライブラリやソースは資料として今でも価値があると思うね。HITEC-C 環境でも互換ライブラリが作られているし、高機能もいいがシンプルなライブラリの良さもあるのだ 
