8086 vs. Z80 vs. 6809 vs. 6502　その16

1 ：ナイコンさん：2022/05/15(日) 04:33:24 .net

8086(8088)・Z80・6809・6502のうち、どのCPU(MPU)が優れているか議論するスレッドです。
CPU(MPU)アーキテクチャや周辺デバイス制御など
基本的に「石」に関連する議論なら、ほぼ何でもアリです。


　　　　　♪　　　　／.i　　 ／.i　　／.i
　　　♪　　　　 ∠__ノ　∠__ノ　∠__ノ　　
　　　　　　 　〈,(・∀・;)ノ・∀・;)ノ・∀・;)ノ
　　 　 　　　 └i===|┘i===|┘.i===|┘
　 　 　 　 　　 〈＿_〈　〈＿_〈　〈＿_〈

■過去スレ（勝手にﾜｯﾁｮｲ化）
8086 vs. Z80 vs. 6809 vs. 6502　その15
https://kizuna.5ch.net/test/read.cgi/i4004/1624078918/

112 ：ナイコンさん：2023/03/04(土) 13:49:51.54 .net

＞しかし、マスコミは、ずっとMSXを任天堂のファミコンと比べて、「失敗したゲーム機」というレッテルを貼り続けた

113 ：ナイコンさん：2023/03/04(土) 13:59:03.92 .net

>>110
いちおう、組み込み分野はRISC系のマイコンが多数派になってるような気はする
狭義のRISCは全くないけども

それと、非RISCのが駆逐されるほどの勢いはないし

114 ：ナイコンさん：2023/03/04(土) 23:36:48.54 .net

>>113
なるほど、RISC系が多数派になってるけど
伝統的なCISC的なCPUも現存してると、現実的な解なので納得

115 ：ナイコンさん：2023/03/04(土) 23:52:03.32 .net

>>110
そうか？結局内部RISCで命令互換の為にCISCの皮を被っているとか
Armなんかでも短縮長命令取り入れるとか
どっちも純粋な物がなくなってないか？

116 ：ナイコンさん：2023/03/05(日) 01:34:55.88 .net

初期か処理とか例外処理とかの特殊な部分にすらマイクロプログラムを使わず専用ルーチンをくんで動かすDEC Alpha みたいなのは、他にはでてきてない気がするな

複数レジスタを1命令で一括ロードしたりストアしたりする、マイクロプログラム制御になってもおかしくないような複雑な処理をする命令を搭載してるRISC系だが純粋なRISCと呼びにくいチップが主流になってきてる

CISCの典型、複雑すぎて速度が上がらないチップの代表は68040だった、386や486は68040ほど複雑じゃなく、けっこう高速化された

RISCとして開発されたはずのSPARCとか、命令は単純化したものの内部構造が複雑でクロック上がらなかったものもあるんだよな

117 ：ナイコンさん：2023/03/05(日) 02:15:39.35 .net

何十年前の話をしているんだ

118 ：ナイコンさん：2023/03/05(日) 04:00:27.61 .net

>>108
火星のローバーも8085だったしね

119 ：ナイコンさん：2023/03/05(日) 05:18:36.05 .net

>>116
MC68000はAppleの初代Macintoshに採用され、以降68020, 68030, 68040が順次採用されたが、68050ではIntel CPUにパフォーマンスで太刀打ちできないことがわかり開発中止、Macintoshは68060の完成を待たずPowerPCに移行した。
結果68060はコンピューターにはほとんど使われることなく、モトローラのMC680x0シリーズの最後のCPUとなった。

120 ：ナイコンさん：2023/03/05(日) 09:20:17.27 .net

そして、アセンブラリ言語レベルでの互換性を持たせながら再設計したColdFireに受け継がれていったとな。

121 ：ナイコンさん：2023/03/05(日) 16:34:43.70 .net

>>34
PC-80S31からの外付けFDドライブには Z80が載ってた。これはマルチCPUとは呼ばないけど、一部のゲームアプリで外付けCPUを使っていて、EPSON FDDでは動作しない問題があった

122 ：ナイコンさん：2023/03/05(日) 20:24:37.14 .net

386や486のODPは元の低速側を停止せずにプロセスを動かせたら良かったのにね

123 ：ナイコンさん：2023/03/05(日) 20:51:04.77 .net

>>122
マルチCPU機構を搭載してないので無理だろ

124 ：ナイコンさん：2023/03/05(日) 21:42:32.63 .net

>>101
その 6800(のサブセット)が B-CASカード上で数千万セット使われてるね

125 ：ナイコンさん：2023/03/06(月) 21:30:20.16 .net

68060は再設計し直して中身RISCなんだろ

126 ：ナイコンさん：2023/03/06(月) 22:09:02.18 .net

CISCの特徴、クロックあげにくい原因、遅さの原因のいちばんはアドレシングモードの複雑さだろ

メモリ間接アドレシングみたいなのはクロックあげられなくなる原因の筆頭じゃないかなあ

127 ：ナイコンさん：2023/03/06(月) 22:23:05.43 .net

ところが、カシオが、ほぼ半額の2万9800円でMSXマシンを発売。
これをきっかけに、MSX陣営内部での激しい値引き合戦が始まった。
これが痛かった。

128 ：ナイコンさん：2023/03/07(火) 01:01:59.34 .net

>>126
マイクロプログラムで複雑な命令を実行するなら、複数クロックかかっても、使われてるマイクロコードをパイプライン処理して、複雑なのに1クロックで次々と実行できるってまで考え付かなかったのかね？
RISCって命令そのままワイヤードロジックで作るなんて言っててパイプラインを活かす事考えてないような

129 ：ナイコンさん：2023/03/07(火) 07:35:48.98 .net

RISCはパイプラインを詰まらさずになるべく全ユニットを仕事させ続けることを優先して可読性を犠牲にする系のアーキテクチャで、かなりパイプライン駆動をがっつりやってるだろ

CISCは一部の実行ユニットに仕事が集中したりメモリからのデータ待ちが連発したりして、わりとパイプラインが停止しまくる感じ

130 ：ナイコンさん：2023/03/07(火) 07:49:12.06 .net

可読性の犠牲よりも、集積度が変わったら1クロックでできる処理が変わるので、バイナリ変更して最適化し直すのでコンパイルし直す前提って設計思想が集積度が向上しすぎるムーアの法則と合わなかった

131 ：ナイコンさん：2023/03/07(火) 09:08:27.91 .net

>>129
CISCの命令セットだとパイプラインがストールしまくるから、パイプラインが
ストールしないような命令セットにしたのがRISCだよね

MIPS Iは理論上パイプラインストールが全く発生しないはず

>>130
RISCは最適化に再コンパイルなんてしないぞ
RISCとVLIWを混同していない?

132 ：ナイコンさん：2023/03/07(火) 09:12:38.62 .net

最初の純RISCはそう言う事を言ってた
レジスタウインドウを集積度で変えて行くとか
商業RISCはバイナリ互換性維持で、本来のRISCの性能を出せなかった

133 ：ナイコンさん：2023/03/07(火) 12:08:39.24 .net

パイプラインを詰まらさないために導入した遅延分岐だって、本来ならマイクロアーキテクチャが変わってパイプライン段数が深くなれば遅延の段数も増やさないと意味がないだろうに、互換性維持のために遅延の段数を固定してパイプラインを滞らせてるもんな

134 ：ナイコンさん：2023/03/07(火) 14:06:23.74 .net

ペンルティの判定とか当時のギリギリの設計をしてるに違いないのに
安易に批判するのはキチガイ

135 ：ナイコンさん：2023/03/07(火) 14:06:50.32 .net

わかるとおもうけどペナルティのtypo

136 ：ナイコンさん：2023/03/07(火) 23:06:48.45 .net

よくわかってないのだけど8bitCPUの時点でマイクロコードが動いてたチップがあったってこと？

137 ：ナイコンさん：2023/03/07(火) 23:33:12.46 .net

8bitCPUな6809の時期の話からだが、8086で使ってた後から出た時期的にどうなの？って話で、既に使われてたな

138 ：ナイコンさん：2023/03/08(水) 01:51:23.17 .net

Z80なんかはハードワイヤードだったが、少なくとも6809はマイクロプログラムでしたよ

139 ：ナイコンさん：2023/03/08(水) 06:07:58.21 .net

>>136
計算機の歴史ということならば、
1960年から1970年代にかけての期間で
パイプライン、キャッシ、仮想記憶、
マイクロコード、仮想マシン
などなどのアイデアは実用化されているんじゃなかったかな。

140 ：ナイコンさん：2023/03/08(水) 10:55:02.90 .net

SC/MPも

141 ：ナイコンさん：2023/03/08(水) 18:24:40.90 .net

ALUが4bitで処理してるのを8bitに見せかけるZ80もハードマイクロプログラム…？

142 ：ナイコンさん：2023/03/08(水) 23:03:54.71 .net

> じつは『週刊アスキー』を創刊するとき、しくじっていたんだ

143 ：ナイコンさん：2023/03/14(火) 22:31:46.97 .net

ちょっとスレタイ都はズレるけど、なんで6502の後継65C816はあんな設計になったんだろうね。
データバス8bitとx86系より酷い64kBの壁とか
作られた時期の割に6502の延命用にしかなってないというか。
SFCで使われたと言ってもねえ。

144 ：ナイコンさん：2023/03/14(火) 22:50:26.49 .net

8ビットモードと16ビットモードの両方で動作するのではと。
ttps://ja.wikipedia.org/wiki/65816_(コンピュータ)

尚、仕様・設計については何故あのようになったのかは判りません

145 ：ナイコンさん：2023/03/15(水) 01:37:53.68 .net

後方互換性があるのはいいことなんだけど付加価値が少なかったのかな

146 ：ナイコンさん：2023/03/15(水) 02:35:41.56 .net

複雑な方な8ビットCPUよりも手軽な16ビットCPUとして作られてるのでは
組み込み用途で生き残ったのはまさにそこが当たったから
だから256個の64kBメモリ空間を持っててメモリ空間を切り替えられる8ビットCPU程度の物になってると

と言うかeZ80もZ80からの複雑さの比率は似たようなもんで生き残ったから、
そのくらいが8ビットCPUのバイナリ資産を活かすのに丁度良いんだろう

147 ：ナイコンさん：2023/03/15(水) 20:24:07.88 .net

マスコミは、ずっとMSXを任天堂のファミコンと比べて

148 ：ナイコンさん：2023/03/15(水) 20:24:20.37 .net

「失敗したゲーム機」
という
レッテルを貼り続けた

149 ：ナイコンさん：2023/03/15(水) 21:43:43.60 .net

CPUのデータバスbit数に対して十分に余裕があるメモリ空間ってどのくらいなんだという問題
正解は無限なんだろうけど

150 ：ナイコンさん：2023/03/16(木) 13:13:24.55 .net

マスコミは、ずっとMSXを任天堂のファミコンと比べて「失敗したゲーム機」というレッテルを貼り続けた

151 ：ナイコンさん：2023/03/16(木) 14:28:52.88 .net

つーてもファミコンだって最初は子供のおもちゃとしての基準からは高すぎで売れなくて、ブームで品薄のゲームウォッチをファミコンも一緒に納入しなきゃ売ってやらねえってやって販売店に押し付けてたからね。

後からファミコンが売れだしたからいいものの、最後はゲームウォッチを納入しなきゃファミコン売らねえってやって、ゲームウォッチを無理やり押し付けてたんだけど、最後は百万ぐらいダブついて廃棄処分にしたらしい。

(で、処分しだしたら外国でゲームウォッチが売れだして…。)

バーチャルボーイもそんな感じで売ろうとしたけど売れなくて、これも百万台近く廃棄処分。

昨今のSDGs的にどうよ？。株主的にも？

152 ：ナイコンさん：2023/03/16(木) 19:44:02.66 .net

6502、ファミコンに採用されなかったら８０年代で滅んでたのかもしれないな

153 ：ナイコンさん：2023/03/16(木) 21:38:31.16 .net

マスコミは、ずっとMSXを任天堂の
ファミコンと比べて「失敗したゲーム機」
というレッテルを
貼り続けた

154 ：ナイコンさん：2023/03/17(金) 05:34:13.44 .net

>>144
当時はまだまだパッケージとか電圧とか色々と移行期だったって事情もある

パッケージの問題は大きくて、DIP40に拘るとな…
SMD化すればもっと多ピンに出来ただろうけど
まだまだ高価なICだったから、交換とか考えちゃうとね〜
バイナリ互換問題も足を引っ張ってるしね

バイナリ互換捨てた8bit風味で
ギリ普及に間に合ったのはAVRやPICだけど12bitPICは流石に寿命
これらだって、最近の半導体不足での以降問題に直面した訳で

開発環境の問題等もあって、保守用途を除いて
8bit風味の新設計は流石にもう良いでしょう…って事に

8bit MCUの夕暮れ
https://pc.watch.impress.co.jp/docs/column/tidbit/1480997.html

155 ：ナイコンさん：2023/03/17(金) 15:41:23.08 .net

マスコミは、ずっとMSXを
任天堂のファミコンと比べて「失敗したゲーム機」というレッテルを
貼り続けた

156 ：ナイコンさん：2023/03/17(金) 18:54:43.92 .net

なんだか、壊れたレコードが鳴り続けてるようだな

157 ：ナイコンさん：2023/03/18(土) 09:32:45.69 .net

幸いにして8bitCPUのマシン語レベルでの使いこなしは新参者でしか無いAIには不得手の模様
Z80職人の仕事はまだ無くならない

158 ：ナイコンさん：2023/03/18(土) 17:27:09.60 .net

マスコミは、ずっとMSXを任天堂のファミコンと比べて
「失敗したゲーム機」というレッテル
を貼り続けた

159 ：ナイコンさん：2023/03/19(日) 05:02:30.87 .net

>>157
ChatGPTに尋ねてみたよ
以下はZ80アセンブリ言語で70000回ループするプログラムです。
ORG 0x0000 ; 実行開始アドレスを設定

LD HL, 70000 ; HLレジスタに初期値70000を設定
LOOP:
DJNZ LOOP ; DJNZ命令でループを繰り返す
RET ; プログラムを終了する
このプログラムでは、レジスタHLに初期値70000を設定し、DJNZ命令でループを70000回繰り返します。
DJNZ命令は、レジスタBの値を1減算し、0でなければ指定されたアドレスにジャンプします。
このプログラムではDJNZ命令のループ回数を指定せず、レジスタBを自動的にデクリメントするため、
HLレジスタの値が0になるまでループを繰り返します。最後にRET命令でプログラムを終了します。

160 ：ナイコンさん：2023/03/19(日) 05:13:51.26 .net

>>157
Z80は苦手なの？　→　言語専用ＡＩだから苦手だよ
C言語とかエクセルは出来るらしいじゃん　→　ネットに豆知識が沢山あるから覚えちゃった(自慢）
Z80は何で苦手なの？ネットに書いてる人がいるでしょ？　→データシートないんだもん、言語化されないと理解できないよ
だったら良書と言われるものを言語で学習すりゃ良いじゃん　→　人が書いた書籍なんて誤字脱字や勘違いだらけで信用できないから覚える気はない(きりっ
大勢の書籍を総合的に読めばなんとかなる？　→　やっぱー人間の癖があるしー、言語化した解説だけでつなぎ合わせは難しいしぃ～

なんでエクセルとかC言語は正確な回答ができるの？　→　指南情報がネットには山のように転がってるから
エクセルやC言語だって人が解説してるでしょ？　→　情報が多いから個人の癖などは差っ引いて学習できるんです（きりっ
だったらZ80だって何とか頑張って　→　データシートは読めないから(鼻ホジ
だったらエクセルだって説明書を読んでる？　→　エクセルはなんて明書や仕様書を見なくてもネットの豆知識を斜め読みしただけで余裕なんだって

Z80の全パターンを言語化して説明したら覚えてくれるかい？　→　個人の感想は覚える気がしないな
16ビットレジスタに7万とか入らあいよ。理解できないの？　→　だーかーらー　低級言語のZ80は覚える気がしないんだよ。専門技術者にシコシコ書かせろ（意訳）

みたいなバカ問答をChatGPTとやったことがある

161 ：ナイコンさん：2023/03/19(日) 06:28:32.27 .net

>>160
えっ書籍って読まないの？
ネット情報なんかよりずっとまともだと思うけど
というか書籍もネット情報もまともな人が書いたものはまともでそうでないものはダメ
数で決まるわけではない

162 ：ナイコンさん：2023/03/19(日) 08:52:43.68 .net

色々言ってるけど要するにネットに上がってない書籍を全部読むほどの学習はコストが無限大までいくから無理ってことじゃないの
あくまでも学習させるのは人間のチームの仕事だし、学習内容には優先順位ってものもあるはず

Z80だけじゃないけど8bitCPUのプログラムなんて自己書き換えをやり始めてからが本番だけど
自分も簡単なの試したけど65系のプログラムも簡単な命令しか分かってないレベル、割込制御も勘違いしてた
ちゃんとしたデータシート食わせてもC言語のようには理解できないんだろうと思う　APPLE][リスペクトじゃないのは仕方ないさ

163 ：ナイコンさん：2023/03/19(日) 09:39:09.47 .net

ここで人間の頭で8bitCPUに簡単な仕事をさせるコードの比較をしてみようか

お題はアキュムレータ上でのニブルスワップをマシン語で書く
$A7→$7Aになればフラグとか他レジスタはどうなっても良し

164 ：ナイコンさん：2023/03/19(日) 09:43:27.64 .net

20XX年
AIの発展により、プログラマという職業は絶滅してしまった。
しかし、ただ一つの例外がある。
COBOLプログラマである。

165 ：ナイコンさん：2023/03/19(日) 09:51:16.83 .net

たぶんちょっと頭のいいSIerならCOBOLシステムの要件再定義からリストラをAIでやっていって
従来の３割未満の人月で移行を終わらすことができそうなんだよな
全体がむちゃくちゃでかすぎて政治が働く勘定系は知らんがね

166 ：ナイコンさん：2023/03/19(日) 12:49:49.86 .net

マスコミは、ずっとMSXを

167 ：ナイコンさん：2023/03/19(日) 12:50:02.88 .net

任天堂のファミコンと比べて
「失敗したゲーム機」という
レッテル
を貼り続けた

168 ：ナイコンさん：2023/03/19(日) 23:56:52.57 .net

やはりデシマルローテートがあるZ80はニブルスワップが普通に書けていいな
その代わりデシマル演算のやり方がなんかヘンだけど…

169 ：ナイコンさん：2023/03/21(火) 09:55:32.32 .net

マスコミは、ずっとMSX
を

170 ：ナイコンさん：2023/03/21(火) 09:55:47.36 .net

任天堂のファミコン
と比べて
「失敗したゲーム機」という
レッテル
を貼り続けた

171 ：ナイコンさん：2023/03/22(水) 08:41:14.68 .net

スタックフレームを複数用意するのは86や68なら簡単そうだが65がどうしようもない
領域を分けてメイン用とサブ用の２つにするくらいならなんとか出来そうだがうっかり深いネストさせてオーバーフローしたら終了だ
間接YインデックスとXレジスタ使った２次元配列でスタックっぽいバッファを用意するしかないか

172 ：ナイコンさん：2023/03/24(金) 01:53:41.92 .net

西和彦氏、破産手続きを開始


https://news.yahoo.co.jp/articles/30efe63ed4d66c58ff57831c8e3fb2a7332a5ba3

173 ：ナイコンさん：2023/04/14(金) 21:16:30.97 .net

>>171
コモドール128がMMUにゼロページやスタック領域のページング付けて売りにしてたのの延長に、
サブルーチンコールごとにどんどん深く両方とも切り替えて行くようにすれば良いのでは
16MBで65536切り替えって

174 ：ナイコンさん：2023/04/15(土) 10:48:54.08 .net

どうしても必要ならゼロページにネスト用サブルーチンポインター置くのが最適解だろうと思う
他でも使うスタックにバグ仕込んだら終わるからさ

175 ：ナイコンさん：2023/04/15(土) 15:50:19.87 .net

任天堂のファミコンと比べて
「失敗したゲーム機」という
レッテルを貼り続けた

176 ：ナイコンさん：2023/04/21(金) 01:22:57.77 .net

6809が最強ならFM7は最強だったのか？

177 ：ナイコンさん：2023/04/21(金) 08:29:49.60 .net

大谷が最強ならエンゼルスは最強なのか？

178 ：ナイコンさん：2023/04/21(金) 09:13:02.64 .net

FM8/FM7はサブシステムを作ってしまったことが悔やまれる。
後知恵で言うのは憚られるところもあるが、最初に素直な構成で出ていればと思う。
富士通FMシリーズはそれでも健闘しただけに一層残念。
日立のベーシックマスターはいろいろ悪すぎた。
S1がもう少し早く出ていればという気もするが、S1は早くは出せなかっただろうw
もう日立という会社自体に問題があるような。
シャープがXかMZのどちらかで6809を使っていればと思う。
MZがZ80でX1が6809とか面白かっただろう。

179 ：ナイコンさん：2023/04/21(金) 09:26:07.26 .net

日立や富士通は6809セカンドソースで自社生産してるからパソコンにも使っただけ
シャープはZ80セカンドソースなんだから自社生産してるZ80を使う

NECのようにライセンス無しでコピーCPU作ってパソコンまで作ってしまう方が例外

180 ：ナイコンさん：2023/04/21(金) 12:17:27.84 .net

ちうても、X1の方はPC部門じゃなくて門外漢のテレビ事業部が作ってたから、MZの方と違って6809を採用できてた可能性もありそう
後にはX68000で他社CPU使ってるし

MZの方はセカンドソース生産の関係で他のCPU使う可能性はなかったと思う

181 ：ナイコンさん：2023/04/21(金) 15:07:38.08 .net

それでもZ80PIOを超低速IFのキー入力に使うのはスジが悪いよ
割り込みにつながらないタイマーとかシステムとしてユーザーを蔑ろにしている
エロい人にはわからんのですよと現場は呆れていただろうな

182 ：ナイコンさん：2023/04/22(土) 11:35:39.11 .net

>>178
＞FM8/FM7はサブシステム
表示用にビデオ（グラフィック）でメモリを使用するから
メインRAMをフルの64Kバイト搭載するための選択肢と考えるけど
他にどのような方法を考えられるのか？　バンク切り替えでは遅いし
AT互換機のように表示用機能はインターフェースだけ決め独立させるとかか
AT互換機の仕様を真似するには新規開発が必要でコストアップにならないか

183 ：ナイコンさん：2023/04/22(土) 11:56:28.73 .net

6809にはMMUが必須のようなもんだ
64KBフルRAMなんてのはZ80にでもさせとけ

184 ：ナイコンさん：2023/04/22(土) 15:29:07.92 .net

>>182
同じメモリマップドI/Oの6502系のファミコンやPCE、Z80でもMSX等のようにI/O経由のVDP経由かな

>>183
6809は登場時期が遅めの8bitCPUなのに64kB越えメモリの事をあまり考えてなかったのは
68000系との棲み分けとして最初からそういう運命だったんだろうね。
6309を認めてこれを拡張して16bit化してたら8086みたいな64kBバンクになってたのだろうか。

185 ：ナイコンさん：2023/04/22(土) 17:10:12.34 .net

VDP経由でVRAMアクセスってのは帯域的にどうなんだろね
まあ少なくともメインメモリには負担かけないのと割込転送も使ってグラフィック描画していくなら性能出せるのかな

186 ：ナイコンさん：2023/04/22(土) 17:24:55.85 .net

モトローラ自身はMC6829 MMUを出してたんだから、採用しなかったパソコンメーカーが悪いって形では

187 ：ナイコンさん：2023/04/22(土) 18:59:03.90 .net

>>186
6829はスピードが遅かったために日立はMB-S1でショットキーTTLを使ったアドレス変換回路を組んだと聞いたが、高速な6829って出たのだろうか

188 ：ナイコンさん：2023/04/22(土) 19:13:16.51 .net

>>185
バンク切り替え以外でという事でな、AT互換機のようにというのが当時はVDP経由だったかなと
何にせよ8bitCPUだしCPUに転送を任せるにも遅すぎる。X68000とかはな。
PCEのみたいに比較的高クロックで対処するか？

>>186
http://haserin09.la.coocan.jp/os9_mmu.html
このサイトによるとソレ含めて微妙なMMUしかなかったらしい
だいたい、上記サイトでも見るように採用例が少なく使われないというには理由が有るものだ。

189 ：ナイコンさん：2023/04/22(土) 19:25:01.92 .net

>>181
たぶん、あまり売れてないZ80PIOの採用例として売ってくれとか社内で言われたんじゃね? と憶測

190 ：ナイコンさん：2023/04/22(土) 19:32:28.83 .net

6829はシグネティックかなんかのOEMだったっけ？

モトローラは6820の改良版の6821みたいのや、日立が設計した6845みたいのを除いて、末尾が0でない周辺チップはサードパーティーが少なくて、あんまり入手性が良くなかったから、採用されなかったのかもしれないね。

当時、アキバでもあんまり見かけなかったし、初期は結構な値段したし。

191 ：ナイコンさん：2023/04/23(日) 10:57:18.11 .net

>>188
パソコンに使われてたのが微妙なのなだけで、有った事はあったってのが、何でパソコンには使わなかったのか更に謎だ

＞米国GIMIX社 6809 CPU III Board のMMU＜略＞
この製品はパソコンではなく、SS-50という規格のボード製品です。
このページで紹介している中では、一番まともなMMUかもしれません。
MC6829の不完全な部分をロジックゲートで補ったというか、安く再構成
したような感じです。メモリブロックのサイズは2KBで細かく管理できますが、
今となっては小さすぎてオーバーヘッドが大きいような気がします。

192 ：ナイコンさん：2023/04/23(日) 12:24:08.19 .net

>>191
発売時期が遅かったとか、自社製品用に囲い込まれてて他社では採用できなかったとか、なんか理由があるのかもね

193 ：ナイコンさん：2023/04/23(日) 12:46:22.69 .net

> マスコミは、ずっとMSXを
> 任天堂のファミコンと比べて
> 「失敗したゲーム機」というレッテル
> を貼り続けた

194 ：188：2023/04/23(日) 16:14:12.86 .net

>>191
リンク先読んでるよね？以下に関係しそうな内容を引用すると

＃ MC6829 は Task切り替え数少ないし。供給が少なく価格も高い。

＃ この通り、貴重なI/O空間をなんと128バイトも占めてしまいます。

＃ これらのレジスタはSystemモードでしか書き換えることができません。
＃ MC6829からはS/U信号は出力されていないので、デバッグは大変であった
＃ と予想されます。その点MB-S1は基板上に出てるので安心です。

195 ：ナイコンさん：2023/04/23(日) 17:31:34.75 .net

8バンク切替方式で柔軟さには欠けるがCPUに切替専用命令を内蔵してたHuC6280は有能な気がする
なんでこのチップでホビーマイコンキット売らなかったんだろうもったいない

196 ：ナイコンさん：2023/04/23(日) 18:40:39.42 .net

>>194
MC6829よりも良いのを組んだだけでMC6829自体は使ってないかと

197 ：ナイコンさん：2023/04/23(日) 20:54:47.90 .net

>>195
HuC6280は6502系で登場も遅いしメモリリフレッシュ機能無いし
折角の高速を活かすとRAMはSRAM、ROMも高速版になり高価で売れたか怪しいな。
6502系なら65C816という16bit版もあるし

>>196
ああ、以下のが良い物だったのにと言う話？

＞米国GIMIX社 6809 CPU III Board のMMU＜略＞

MMUとしては最もマトモという話だが以下の引用する部分はあまり良くないな

MB8149(相当品) x3ケ
＃ なんとも贅沢なMMUです。$FF800から始まっているのはMC6829に合わせて
＃ いるのかもしれませんが、512バイト以上もアドレス空間を占めるなんて。

198 ：ナイコンさん：2023/04/23(日) 22:00:04.17 .net

>>197
512バイトだと、FF800からFF9FFまでの範囲ってこと?

199 ：ナイコンさん：2023/04/23(日) 22:21:35.01 .net

>>197
確かに8bitCPUとしては最後の最後くらいのローンチだった
枯れた技術でファミコンより速くて使いやすいチップセットを作るのが目標だったようだから
NECとケンカになるようなPC向けに流用なんて発想はそもそもなかったのだろうな

200 ：ナイコンさん：2023/04/23(日) 22:58:25.47 .net

>>197

201 ：ナイコンさん：2023/04/23(日) 23:04:36.64 .net

>>197
MMUのブロック単位の細かさとのトレードなんだし、2kBずつでは指定数が多すぎ、8kBほどにして指定数を減らすべきって価値観なのだな
1983年にしては細かすぎるって年代も考慮してなのだろうが
実際、8bit CPUだと8kBずつも多いようだし

202 ：ナイコンさん：2023/04/23(日) 23:17:26.91 .net

今時のx86でもページサイズは4KB以外の動作モードはあまり使われてないぐらいなんだから、逆に言えば、ページサイズが大きすぎると使い勝手が悪いんじゃない?

んで2KBにしてみたが、細分化しすぎで使いにくかったってことでしょ

203 ：ナイコンさん：2023/04/23(日) 23:32:25.72 .net

1979年のメモリ事情では細分化してロスを無くした方が良いと判断されて、1983年にも互換保って同じ単位にした、ってパターンか
4kBはUNIXが元々そういう前提で作られてたからそのまま使えて都合が良いからだな
UNIXが動かない8bit CPUではこだわる必要は無いから、I/O空間とや書き換え速度やらのトレードで程良く作れば良い

204 ：ナイコンさん：2023/04/24(月) 08:36:55.48 .net

データチャンクを置いとくページをあまり細かく刻まれる一連の切替オーバーヘッドが増える。
マルチタスクOSならアプリサイズに合わせて細かく管理したいかもしれないが、ゲーム用途だと常駐するルーチンやら
仮想VRAM領域やら並べてくだけで軽く2kBは超えてしまう　（コード最適化が足りないとか言わない）
ページサイズは4か8kBがちょうどいいくらいに感じる

205 ：ナイコンさん：2023/04/24(月) 09:54:41.91 .net

まめちしき
Apple Silicon Macのページサイズは16kB

206 ：ナイコンさん：2023/04/24(月) 10:24:51.19 .net

8bitCPUってか
64kBアドレスだと16kBページは厳しいな
コードとデータ空間別けられるタイプならともかく
4ページしか取れないとなると、ページ境界を跨ぐブロック転送とかでメンドイ事になるw

207 ：ナイコンさん：2023/04/24(月) 12:37:12.58 .net

16KBだと、MSXのメモリマッパーみたいなレベルなんかなあ?
元のMSXは16KBのバンク切り替えやったけど

8KBならMZ2500のが近いかも

208 ：ナイコンさん：2023/04/24(月) 16:59:37.65 .net

>>206
PCエンジンは最後に大容量高速DRAMカードを発売してそれを広いデータ置き場にした
ページという概念がない21bitのメモリ空間の好きなところからシーケンシャルアクセスできた
（事前にアドレスレジスタを設定する必要があるがアクセス毎のオートインクリも可能）

CD-ROMやVRAMと大量にブロック転送しまくる用途ならこういう仕様もアリなのだと思う

209 ：ナイコンさん：2023/04/24(月) 17:15:53.78 .net

>>208　補足
21bitのメモリアドレス → 2MB容量
これすら大量のグラフィックデータで埋め尽くされてしまうのがCD-ROMゲームの宿命だった

210 ：ナイコンさん：2023/04/24(月) 22:01:10.73 .net

>――MSXで覚えているソフトや、お気に入りのゲームというのはあるのですか？
>西　いやあ、僕はそもそもゲームが好きじゃありません。なぜなら楽しくないから。

211 ：ナイコンさん：2023/05/16(火) 06:46:02.93 .net

8bit向けにコーディングしてる人ら、みんな何のエディタ使ってるんかな

212 ：ナイコンさん：2023/05/17(水) 12:39:02.80 .net

クロス開発でしょ？emacs。