[過去ログ] ファミコン等の限界について語るスレ Ver.6 (1002レス)
1-

このスレッドは過去ログ倉庫に格納されています。
次スレ検索 歴削→次スレ 栞削→次スレ 過去ログメニュー
40
(3): 2021/12/30(木)23:41 ID:SuhugDE60(1) AAS
あー、ROMが対応してない云々は確かに眉唾
だって初期のスーファミのソフトを改造でオーバークロックした本体で動かしてるのあるもの
動画リンク[YouTube]

それに実カセットを使うレトロ互換機でも動かすのがFPGAでもエミュでもオーバークロック設定できるがちゃんと初期のカセットも動くでしょ
41
(1): 2021/12/31(金)00:27 ID:nDBDyYVU0(1) AAS
ROMによりCPU速度が〜っての元ソースはこの人でしょ
外部リンク[html]:www.wizforest.com
バイトでサブプログラマーしていたっていう人の話

…よくよく改めて読むとどうなのかな?
安いROMだと帯域が低いのでアクセス速度が低くなるっていう当たり前の話のなかでCPUの速度が変わる〜って書かれてるけど…
帯域が低い部分、高い部分が別個にあったところで、そこへアクセスするのにCPUのクロックを上げ下げしないといけない理由ってあるの?

まぁ何か理由があったところでこれはROMデータへアクセスする場合の話だから通常は普通に最高クロック(3.58MHz)で動いてるんでは?
42
(1): 2021/12/31(金)00:30 ID:MDsnraik0(1) AAS
>>40
バグってるやん
43
(1): 2021/12/31(金)00:44 ID:EJMNeZr+0(1) AAS
>>40
オーバークロックして動いてるから眉唾ってのはアホ過ぎる
製品レベルでマージンすらない設計って方が非現実的であり得ない
44: 2021/12/31(金)00:59 ID:GbWVMt3O0(1/2) AAS
なんかねじ曲がって伝わってない?
俺が聞いたことある話だと、SFCのCPUは言われているほど遅くはないっていう開発者の話があってその中で、
なぜ遅いと言われるかというと、コスト低いROMのアクセス速度が遅くて特にSFCの音源関連のRAMとのやり取りの中で問題が発生しやすいって話と、
CPUの16bit命令が思ってる以上に遅くてここがネックになってたというもの、中期以降はここを工夫してメインループは8bit命令だけで構成したりして処理速度を稼いだという話
45
(1): 2021/12/31(金)01:01 ID:GbWVMt3O0(2/2) AAS
>>42-43
そりゃあプログラムの側で完全に対応してないとバグることはあるでしょ
この当時のプログラムなんてクロックでタイミング決め打ちで処理しているようなのあるし
でもオーバークロックでちゃんと読み込めて動作しているってことはROMが高クロックに対応してないっていうのは無いと判断していいかと
っていうかそんな話どこから出たんだ?
46: 2021/12/31(金)01:08 ID:MwMPYM5B0(1) AAS
ファミコンのBGとスプライト(3色+背景色)にもう1色ずつパレット(4色+背景色)があればなぁ
移植ものとかでもっと豊かで忠実な表現が出来たろうに
47: 2021/12/31(金)01:18 ID:QYoBmTAK0(1/3) AAS
>>45
> でもオーバークロックでちゃんと読み込めて動作しているってことはROMが高クロックに対応してないっていうのは無いと判断していいかと

マージンってなんだか知らないアホ。そんなのは判断材料にはならん。

> っていうかそんな話どこから出たんだ?

>>40 というアホレスが発端だろ。
48: 2021/12/31(金)03:26 ID:QYoBmTAK0(2/3) AAS
>>34
> MSX,ファミコン、PCエンジン、メガドライブ、GB、GBA、DS…ROMカセット側の都合で本体のCPUクロック制限がでるようなもの一つもないのに

DSだけはROMカセットと言っても、SDカードなんかと同様のストレージなので
同列にしてる時点で根本の問題が判ってないのが丸わかり。

それにDS以外はSFCと同じ縛りは存在するけど。なんでないって言ってるんだ?
49
(2): 2021/12/31(金)09:07 ID:nXP/UBhv0(1/5) AAS
当時のシステム知らない人多いみたいだけど昔はバススピード固定
あるデバイスが1.79MHzにしか対応してなきゃ当然CPU側も1.79MHzに落とす
これはRAMでもROMでも同じ
無理やり使って動く場合もあるけど運悪けりゃ暴走する
当時のOC記事なんかでも壊れても自己責任ってしつこく書かれてた
MSXturboRの例出してる人いるけどあれはシステムチップがROMアクセスする時に強制的にウェイト入れるから高クロック設定でも動く
SFCがこういう機能持たせてたって話聞かないから一律でクロック落とす方法にしたんじゃないの
システムチップ起こすよりソフトの方で対応すれば安く済むし
50
(1): 2021/12/31(金)09:13 ID:zDVn24690(1/2) AAS
>>49
バススピード固定なんか当たり前
むしろ当時で可変のほうが無いわ
51
(1): 2021/12/31(金)09:18 ID:nXP/UBhv0(2/5) AAS
>>50
今みたいにCPU高クロックのままで遅いデバイスにアクセスできると思ってる人が多いんで書いた
52
(2): 2021/12/31(金)09:23 ID:zDVn24690(2/2) AAS
>>49
> SFCがこういう機能持たせてたって話聞かないから一律でクロック落とす方法にしたんじゃないの
> システムチップ起こすよりソフトの方で対応すれば安く済むし

メモリアクセスする時に細かく可変してるってだけなら一緒だろう
問題は>25の言うようなROMの全メモリが低コスト版の時にメモリアクセス時以外もずっとCPUが最低クロックのままなのか?だ
53
(1): 2021/12/31(金)09:36 ID:nXP/UBhv0(3/5) AAS
>>52
それはプログラム次第だから分からんな
メインプログラムがROM側にあれば低クロックのままだろうし、高速化したければRAMに展開して速度稼ぐだろうし
最悪なのは手抜きプログラマーがクロック変更なんて面倒くせえって低クロック決め打ちのまま出す
遅いって叩かれてるのはほとんどこれじゃないの
54
(3): 2021/12/31(金)09:46 ID:TNj0df2/0(1/2) AAS
>>51
出来るわ
ただ非同期アクセスのメモリだと非効率で高クロックが”活かしきれない”だけ
いい加減なこと書くでないわ

あとスーパーファミコンでメモリアクセスでROMこ都合でCPU可変にしてたなんか聞いたことない
41のがソースだとしたらそいつが間違ってるだけだろ
おそらく音源チップのメモリアクセスの部分が低帯域かつ音源チップの独立したプロセッサのクロック1.024 MHz.のものと混同したんじゃないか?

スーパーファミコンの時代でROMのメモリが3.58 MHzにも対応してないものなんかあるわけない
55
(1): 2021/12/31(金)09:48 ID:nXP/UBhv0(4/5) AAS
>>54
出来ないよ
実際当時のパソコンで普通に暴走した
いい加減なことは書いてない
56: 2021/12/31(金)09:51 ID:TNj0df2/0(2/2) AAS
>>55
暴走したとしたら他の要因
そもそもOSのプログラムが高クロックで誤作動するとか
57: 2021/12/31(金)09:55 ID:nXP/UBhv0(5/5) AAS
一応補足
高クロックのまま低速デバイスにアクセスする際にはウェイトを入れる
各デバイス毎にタイミングは決まっててそれに合わせてプログラムを書く
こうすれば高クロックのままでも動く
逆にこれやらないと変な動作したり暴走したり最悪壊れる
58: 2021/12/31(金)11:12 ID:WO/sRRkH0(1) AAS
当時の開発者の証言が複数あるのに
今さら覆したいなら
しょぼい推測じゃなくて
さっさと証拠か証言でも持って来いよ
偉そうにいっているんだから簡単だろ
59
(2): 2021/12/31(金)11:27 ID:cpcm9GqD0(1/3) AAS
パッチでROM読み取りを高速化して処理落ち減らすプロジェクトもあるんだし無知ってのは怖いねぇ

外部リンク:github.com
1-
あと 943 レスあります
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ AAサムネイル

ぬこの手 ぬこTOP 0.066s